Skip to content

Conversation

@to268
Copy link
Contributor

@to268 to268 commented Oct 21, 2025

Previously, the handling of the cleanup attribute had some checks based on the type, but we were deducing the type after handling the attribute.
This PR fixes the way the are dealing with type checks for the cleanup attribute by delaying these checks after we are deducing the type.

It is also fixed in a way that the solution can be adapted for other attributes that does some type based checks.
This is the list of C/C++ attributes that are doing type based checks and will need to be fixed in additional PRs:

  • CUDAShared
  • MutualExclusions
  • PassObjectSize
  • InitPriority
  • Sentinel
  • AcquireCapability
  • RequiresCapability
  • LocksExcluded
  • AcquireHandle

NB: Some attributes could have been missed in my shallow search.

Fixes #129631

@github-actions
Copy link

github-actions bot commented Oct 21, 2025

✅ With the latest revision this PR passed the C/C++ code formatter.

@llvmbot llvmbot added clang Clang issues not falling into any other category clang:frontend Language frontend issues, e.g. anything involving "Sema" labels Oct 21, 2025
@llvmbot
Copy link
Member

llvmbot commented Oct 21, 2025

@llvm/pr-subscribers-clang

Author: Guillot Tony (to268)

Changes

Previously, the handling of the cleanup attribute had some checks based on the type, but we were deducing the type after handling the attribute.
This PR fixes the way the are dealing with type checks for the cleanup attribute by delaying these checks after we are deducing the type.

It is also fixed in a way that the solution can be adapted for other attributes that does some type based checks.
This is the list of C/C++ attributes that are doing type based checks and will need to be fixed in additional PRs:

  • CUDAShared
  • MutualExclusions
  • PassObjectSize
  • InitPriority
  • Sentinel
  • AcquireCapability
  • RequiresCapability
  • LocksExcluded
  • AcquireHandle

NB: Some attributes could have been missed in my shallow search.

Fixes #129631


Full diff: https://github.com/llvm/llvm-project/pull/164440.diff

5 Files Affected:

  • (modified) clang/docs/ReleaseNotes.rst (+1)
  • (modified) clang/include/clang/Sema/Sema.h (+7)
  • (modified) clang/lib/Sema/SemaDecl.cpp (+18)
  • (modified) clang/lib/Sema/SemaDeclAttr.cpp (+24-10)
  • (added) clang/test/Sema/type-dependent-attrs.c (+11)
diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index fe77f917bb801..491cfd3351861 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -447,6 +447,7 @@ Bug Fixes to Attribute Support
 - Using ``[[gnu::cleanup(some_func)]]`` where some_func is annotated with
   ``[[gnu::error("some error")]]`` now correctly triggers an error. (#GH146520)
 - Fix a crash when the function name is empty in the `swift_name` attribute. (#GH157075)
+- Fix ``cleanup`` attribute by delaying type checks after the type is deduced. (#GH129631)
 
 Bug Fixes to C++ Support
 ^^^^^^^^^^^^^^^^^^^^^^^^
diff --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index cb21335ede075..09fb20aa54a6f 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -4465,6 +4465,10 @@ class Sema final : public SemaBase {
       NamedDecl *New, Decl *Old,
       AvailabilityMergeKind AMK = AvailabilityMergeKind::Redeclaration);
 
+  /// CheckAttributesOnDeducedType - Calls Sema functions for attributes that
+  /// requires the type to be deduced.
+  void CheckAttributesOnDeducedType(Expr *E, Decl *D);
+
   /// MergeTypedefNameDecl - We just parsed a typedef 'New' which has the
   /// same name and scope as a previous declaration 'Old'.  Figure out
   /// how to resolve this situation, merging decls or emitting
@@ -15483,6 +15487,9 @@ class Sema final : public SemaBase {
   std::optional<FunctionEffectMode>
   ActOnEffectExpression(Expr *CondExpr, StringRef AttributeName);
 
+
+  void ActOnCleanupAttr(Expr *E, Decl *D, const Attr *A);
+
 private:
   /// The implementation of RequireCompleteType
   bool RequireCompleteTypeImpl(SourceLocation Loc, QualType T,
diff --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index fc3aabf5741ca..13600218b9d83 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -3354,6 +3354,21 @@ void Sema::mergeDeclAttributes(NamedDecl *New, Decl *Old,
   if (!foundAny) New->dropAttrs();
 }
 
+void Sema::CheckAttributesOnDeducedType(Expr *E, Decl *D) {
+  if (!D->hasAttrs())
+    return;
+
+  for (const Attr *A : D->getAttrs()) {
+    switch (A->getKind()) {
+    case attr::Cleanup:
+      ActOnCleanupAttr(E, D, A);
+      break;
+    default:
+      continue;
+    }
+  }
+}
+
 // Returns the number of added attributes.
 template <class T>
 static unsigned propagateAttribute(ParmVarDecl *To, const ParmVarDecl *From,
@@ -13797,6 +13812,8 @@ void Sema::AddInitializerToDecl(Decl *RealDecl, Expr *Init, bool DirectInit) {
       return;
   }
 
+  this->CheckAttributesOnDeducedType(Init, RealDecl);
+
   // dllimport cannot be used on variable definitions.
   if (VDecl->hasAttr<DLLImportAttr>() && !VDecl->isStaticDataMember()) {
     Diag(VDecl->getLocation(), diag::err_attribute_dllimport_data_definition);
@@ -14587,6 +14604,7 @@ void Sema::ActOnUninitializedDecl(Decl *RealDecl) {
         Var->setInit(RecoveryExpr.get());
     }
 
+    this->CheckAttributesOnDeducedType(Init.get(), RealDecl);
     CheckCompleteVariableDeclaration(Var);
   }
 }
diff --git a/clang/lib/Sema/SemaDeclAttr.cpp b/clang/lib/Sema/SemaDeclAttr.cpp
index 9475b8a684082..a60ad17ed1eb0 100644
--- a/clang/lib/Sema/SemaDeclAttr.cpp
+++ b/clang/lib/Sema/SemaDeclAttr.cpp
@@ -3511,16 +3511,6 @@ static void handleCleanupAttr(Sema &S, Decl *D, const ParsedAttr &AL) {
     return;
   }
 
-  // We're currently more strict than GCC about what function types we accept.
-  // If this ever proves to be a problem it should be easy to fix.
-  QualType Ty = S.Context.getPointerType(cast<VarDecl>(D)->getType());
-  QualType ParamTy = FD->getParamDecl(0)->getType();
-  if (!S.IsAssignConvertCompatible(S.CheckAssignmentConstraints(
-          FD->getParamDecl(0)->getLocation(), ParamTy, Ty))) {
-    S.Diag(Loc, diag::err_attribute_cleanup_func_arg_incompatible_type)
-      << NI.getName() << ParamTy << Ty;
-    return;
-  }
   VarDecl *VD = cast<VarDecl>(D);
   // Create a reference to the variable declaration. This is a fake/dummy
   // reference.
@@ -8291,3 +8281,27 @@ void Sema::redelayDiagnostics(DelayedDiagnosticPool &pool) {
   assert(curPool && "re-emitting in undelayed context not supported");
   curPool->steal(pool);
 }
+
+void Sema::ActOnCleanupAttr(Expr *E, Decl *D, const Attr *A) {
+  FunctionDecl *FD = nullptr;
+  DeclarationNameInfo NI;
+  CleanupAttr *Attr = D->getAttr<CleanupAttr>();
+
+  // Obtains the FunctionDecl that was found when handling the attribute
+  // earlier.
+  FD = Attr->getFunctionDecl();
+  NI = FD->getNameInfo();
+
+  // We're currently more strict than GCC about what function types we accept.
+  // If this ever proves to be a problem it should be easy to fix.
+  QualType Ty = this->Context.getPointerType(cast<VarDecl>(D)->getType());
+  QualType ParamTy = FD->getParamDecl(0)->getType();
+  if (!this->IsAssignConvertCompatible(this->CheckAssignmentConstraints(
+          FD->getParamDecl(0)->getLocation(), ParamTy, Ty))) {
+    this->Diag(Attr->getArgLoc(),
+               diag::err_attribute_cleanup_func_arg_incompatible_type)
+        << NI.getName() << ParamTy << Ty;
+    D->dropAttr<CleanupAttr>();
+    return;
+  }
+}
diff --git a/clang/test/Sema/type-dependent-attrs.c b/clang/test/Sema/type-dependent-attrs.c
new file mode 100644
index 0000000000000..f99293d1cd639
--- /dev/null
+++ b/clang/test/Sema/type-dependent-attrs.c
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -std=c23 -fsyntax-only -verify %s
+
+// #GH129631-CleanupAttr
+int open() { return 0; }
+void close(typeof(open()) *) {}
+
+void cleanup_attr() {
+  int fd_int [[gnu::cleanup(close)]] = open();
+  auto fd_auto [[gnu::cleanup(close)]] = open();
+  float fd_invalid [[gnu::cleanup(close)]] = open(); // expected-error {{'cleanup' function 'close' parameter has type 'typeof (open()) *' (aka 'int *') which is incompatible with type 'float *'}}
+}

Copy link
Collaborator

@erichkeane erichkeane left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1 suggestion on how to improve tablegen, else LGTM.

Copy link
Collaborator

@AaronBallman AaronBallman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM aside from a comment request, feel free to keep or ignore the suggestion.

@to268
Copy link
Contributor Author

to268 commented Oct 24, 2025

As found by Aaron, there is an additional bug with templated types that will need to be fixed before landing this PR.
See: https://godbolt.org/z/8E83bx7jK
I am currently getting the same diagnostic emitted in the test2() function.

@to268
Copy link
Contributor Author

to268 commented Oct 29, 2025

@erichkeane I am requesting guidance for fixing this template deduction issue as you are the template code owner and I don't know the template deduction area.

@erichkeane
Copy link
Collaborator

@erichkeane I am requesting guidance for fixing this template deduction issue as you are the template code owner and I don't know the template deduction area.

Thanks to the LLVM-Dev and ISO C++ meetings this week/next week, it'll be a while before I get a chance to take a look. I DO have this on my list of things to take a look at when I return however!

If you could, please summarize the problem you're needing solved (with terse examples if possible!) in a way that doesn't require extensive reading of the history of this PR so far. That would very much help me get started on this when I get back.

@to268
Copy link
Contributor Author

to268 commented Nov 4, 2025

Basically, it is about the way template type parameters are deduced.
The Ty template type parameter should be referring to the int type in the following example:

int open() { return 0; }
void close(decltype(open()) *) {}

template <typename Ty>
void test() {
  Ty fd [[gnu::cleanup(close)]] = open(); // error: 'cleanup' function 'close' parameter has type 'decltype(open()) *' (aka 'int *') which is incompatible with type 'Ty *'
}

int main() {
  test<int>();
}

The fix would be to trigger the deduction of the template parameter, which should transform the Ty * to a int * type, which would be a compatible type.
I have heard that the deducing logic is triggered based on a TableGen file, but I do not find where would it be.

@erichkeane
Copy link
Collaborator

Basically, it is about the way template type parameters are deduced. The Ty template type parameter should be referring to the int type in the following example:

int open() { return 0; }
void close(decltype(open()) *) {}

template <typename Ty>
void test() {
  Ty fd [[gnu::cleanup(close)]] = open(); // error: 'cleanup' function 'close' parameter has type 'decltype(open()) *' (aka 'int *') which is incompatible with type 'Ty *'
}

int main() {
  test<int>();
}

The fix would be to trigger the deduction of the template parameter, which should transform the Ty * to a int * type, which would be a compatible type. I have heard that the deducing logic is triggered based on a TableGen file, but I do not find where would it be.

Ah, hmm... This seems more to me that the VarDecl has yet to be instantiated at the point of checking (this isn't really deduction at that point?). So I suspect we're checking the 'type' for the purpose of the attribute too soon. I'll have to build locally, but I'll see if I can figure out where we decide on that. But basically, we need to make sure the type is completely instantiated before we check.

I would presume this is either a case of passing the wrong type to the attribute checking/wrong declaration, or doing the attribute checking too early.

@erichkeane
Copy link
Collaborator

erichkeane commented Nov 12, 2025

Basically, it is about the way template type parameters are deduced. The Ty template type parameter should be referring to the int type in the following example:

int open() { return 0; }
void close(decltype(open()) *) {}

template <typename Ty>
void test() {
  Ty fd [[gnu::cleanup(close)]] = open(); // error: 'cleanup' function 'close' parameter has type 'decltype(open()) *' (aka 'int *') which is incompatible with type 'Ty *'
}

int main() {
  test<int>();
}

The fix would be to trigger the deduction of the template parameter, which should transform the Ty * to a int * type, which would be a compatible type. I have heard that the deducing logic is triggered based on a TableGen file, but I do not find where would it be.

Ah, hmm... This seems more to me that the VarDecl has yet to be instantiated at the point of checking (this isn't really deduction at that point?). So I suspect we're checking the 'type' for the purpose of the attribute too soon. I'll have to build locally, but I'll see if I can figure out where we decide on that. But basically, we need to make sure the type is completely instantiated before we check.

I would presume this is either a case of passing the wrong type to the attribute checking/wrong declaration, or doing the attribute checking too early.

diff --git a/clang/lib/Sema/SemaDeclAttr.cpp b/clang/lib/Sema/SemaDeclAttr.cpp
index 2afe50614cd7..30b71e1fc2a5 100644
--- a/clang/lib/Sema/SemaDeclAttr.cpp
+++ b/clang/lib/Sema/SemaDeclAttr.cpp
@@ -8308,10 +8308,13 @@ void Sema::ActOnCleanupAttr(Decl *D, const Attr *A) {
   CleanupAttr *Attr = D->getAttr<CleanupAttr>();
   FunctionDecl *FD = Attr->getFunctionDecl();
   DeclarationNameInfo NI = FD->getNameInfo();
+  VarDecl *VD = cast<VarDecl>(D);
+  if (VD->getType()->isDependentType())
+    return;
 
   // We're currently more strict than GCC about what function types we accept.
   // If this ever proves to be a problem it should be easy to fix.
-  QualType Ty = this->Context.getPointerType(cast<VarDecl>(D)->getType());
+  QualType Ty = this->Context.getPointerType(VD->getType());
   QualType ParamTy = FD->getParamDecl(0)->getType();
   if (!this->IsAssignConvertCompatible(this->CheckAssignmentConstraints(
           FD->getParamDecl(0)->getLocation(), ParamTy, Ty))) {

^^ Something like that. Please make sure you have tests for the mismatch happening AFTER template instantiation however.

@to268
Copy link
Contributor Author

to268 commented Nov 13, 2025

Thank you Erich!
I was not expecting the fix would be that simple.
However, I did stumble on a new issue that took me a few hours to figure out.
In Sema::InstantiateAttrs() we forgot to move the argument SourceLocation of CleanupAttr, which was impacting the error diagnostic is case a mismatch happened after the template instantiation.

@to268 to268 force-pushed the issue-129631 branch 2 times, most recently from 37a184c to 88d25e8 Compare November 13, 2025 17:06
@erichkeane
Copy link
Collaborator

Thank you Erich! I was not expecting the fix would be that simple. However, I did stumble on a new issue that took me a few hours to figure out. In Sema::InstantiateAttrs() we forgot to move the argument SourceLocation of CleanupAttr, which was impacting the error diagnostic is case a mismatch happened after the template instantiation.

Ah right, since it is an 'additional members' you have to do stuff like that manually.

Few nits left, else th is is pretty close.

Copy link
Collaborator

@AaronBallman AaronBallman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aside from a few nits, I'm happy if @erichkeane is happy

@to268
Copy link
Contributor Author

to268 commented Nov 17, 2025

I have applied the small changes.
This PR is now ready to be merged on my behalf.

@erichkeane erichkeane enabled auto-merge (squash) November 17, 2025 19:55
@erichkeane erichkeane disabled auto-merge November 17, 2025 19:56
@erichkeane
Copy link
Collaborator

Aaron/I will merge in the morning to make sure we're around to deal with fallout.

@github-actions
Copy link

🐧 Linux x64 Test Results

  • 111273 tests passed
  • 4418 tests skipped


void Sema::ActOnCleanupAttr(Decl *D, const Attr *A) {
VarDecl *VD = cast<VarDecl>(D);
if (VD->getType()->isDependentType())
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on my reading of the documentation in Attr.td this seems like it should be an assert on !VD->getType()->isDependentType() right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well no, if isDependentType() is true we would delay (by exiting the function early) till the template has been instantiated before trying to do type checks. After template instantiation, this function is called again and would perform type checks as usual.

@AaronBallman AaronBallman merged commit 22a2cae into llvm:main Nov 18, 2025
11 checks passed
@llvm-ci
Copy link
Collaborator

llvm-ci commented Nov 18, 2025

LLVM Buildbot has detected a new failure on builder sanitizer-x86_64-linux running on sanitizer-buildbot2 while building clang,llvm at step 2 "annotate".

Full details are available at: https://lab.llvm.org/buildbot/#/builders/66/builds/22460

Here is the relevant piece of the build log for the reference
Step 2 (annotate) failure: 'python ../sanitizer_buildbot/sanitizers/zorg/buildbot/builders/sanitizers/buildbot_selector.py' (failure)
...
llvm-lit: /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/lit.common.cfg.py:246: warning: COMPILER_RT_TEST_STANDALONE_BUILD_LIBS=ON, but this test suite does not support testing the just-built runtime libraries when the test compiler is configured to use different runtime libraries. Either modify this test suite to support this test configuration, or set COMPILER_RT_TEST_STANDALONE_BUILD_LIBS=OFF to test the runtime libraries included in the compiler instead.
llvm-lit: /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/lit.common.cfg.py:257: note: Testing using libraries in "/home/b/sanitizer-x86_64-linux/build/build_default/./lib/../lib/clang/22/lib/i386-unknown-linux-gnu"
llvm-lit: /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/lit.common.cfg.py:235: warning: Compiler lib dir != compiler-rt lib dir
Compiler libdir:     "/home/b/sanitizer-x86_64-linux/build/build_default/lib/clang/22/lib/i386-unknown-linux-gnu"
compiler-rt libdir:  "/home/b/sanitizer-x86_64-linux/build/build_default/lib/clang/22/lib/x86_64-unknown-linux-gnu"
llvm-lit: /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/lit.common.cfg.py:246: warning: COMPILER_RT_TEST_STANDALONE_BUILD_LIBS=ON, but this test suite does not support testing the just-built runtime libraries when the test compiler is configured to use different runtime libraries. Either modify this test suite to support this test configuration, or set COMPILER_RT_TEST_STANDALONE_BUILD_LIBS=OFF to test the runtime libraries included in the compiler instead.
llvm-lit: /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/lit.common.cfg.py:257: note: Testing using libraries in "/home/b/sanitizer-x86_64-linux/build/build_default/./lib/../lib/clang/22/lib/x86_64-unknown-linux-gnu"
llvm-lit: /home/b/sanitizer-x86_64-linux/build/llvm-project/llvm/utils/lit/lit/main.py:74: note: The test suite configuration requested an individual test timeout of 0 seconds but a timeout of 900 seconds was requested on the command line. Forcing timeout to be 900 seconds.
-- Testing: 4666 of 10459 tests, 64 workers --
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 
FAIL: ThreadSanitizer-x86_64 :: bench_threads.cpp (4248 of 4666)
******************** TEST 'ThreadSanitizer-x86_64 :: bench_threads.cpp' FAILED ********************
Exit Code: 1

Command Output (stderr):
--
/home/b/sanitizer-x86_64-linux/build/build_default/./bin/clang  --driver-mode=g++ -fsanitize=thread -Wall  -m64  -msse4.2   -gline-tables-only -I/home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/tsan/../ -std=c++11 -I/home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/tsan/../ -nostdinc++ -I/home/b/sanitizer-x86_64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/lib/tsan/libcxx_tsan_x86_64/include/c++/v1 /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/tsan/bench_threads.cpp -o /home/b/sanitizer-x86_64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/tsan/X86_64Config/Output/bench_threads.cpp.tmp # RUN: at line 1
+ /home/b/sanitizer-x86_64-linux/build/build_default/./bin/clang --driver-mode=g++ -fsanitize=thread -Wall -m64 -msse4.2 -gline-tables-only -I/home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/tsan/../ -std=c++11 -I/home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/tsan/../ -nostdinc++ -I/home/b/sanitizer-x86_64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/lib/tsan/libcxx_tsan_x86_64/include/c++/v1 /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/tsan/bench_threads.cpp -o /home/b/sanitizer-x86_64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/tsan/X86_64Config/Output/bench_threads.cpp.tmp
/home/b/sanitizer-x86_64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/tsan/X86_64Config/Output/bench_threads.cpp.tmp 2>&1 | FileCheck /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/tsan/bench_threads.cpp # RUN: at line 2
+ FileCheck /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/tsan/bench_threads.cpp
+ /home/b/sanitizer-x86_64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/tsan/X86_64Config/Output/bench_threads.cpp.tmp
/home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/tsan/bench_threads.cpp:45:11: error: CHECK: expected string not found in input
// CHECK: DONE
          ^
<stdin>:1:1: note: scanning from here
ThreadSanitizer: CHECK failed: tsan_platform.h:992 "((IsAppMemImpl::Apply<Mapping>(x))) != (0)" (0x0, 0x0) (tid=3862854)
^
<stdin>:7:13: note: possible intended match here
 #5 __tsan::DontNeedShadowFor(unsigned long, unsigned long) /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/lib/tsan/rtl/tsan_rtl.cpp (bench_threads.cpp.tmp+0x1009ab)
            ^

Input file: <stdin>
Check file: /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/tsan/bench_threads.cpp

-dump-input=help explains the following input dump.

Input was:
<<<<<<
            1: ThreadSanitizer: CHECK failed: tsan_platform.h:992 "((IsAppMemImpl::Apply<Mapping>(x))) != (0)" (0x0, 0x0) (tid=3862854) 
check:45'0     X~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: no match found
            2:  #0 __tsan::CheckUnwind() /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/lib/tsan/rtl/tsan_rtl.cpp:696:21 (bench_threads.cpp.tmp+0x100f85) 
check:45'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            3:  #1 __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_termination.cpp:86:5 (bench_threads.cpp.tmp+0x8acd2) 
check:45'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            4:  #2 unsigned long __tsan::MemToShadowImpl::Apply<__tsan::Mapping48AddressSpace>(unsigned long) /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/lib/tsan/rtl/tsan_platform.h:992:5 (bench_threads.cpp.tmp+0x1009ab) 
check:45'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            5:  #3 auto __tsan::SelectMapping<__tsan::MemToShadowImpl, unsigned long>(unsigned long) /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/lib/tsan/rtl/tsan_platform.h:800:10 (bench_threads.cpp.tmp+0x1009ab) 
check:45'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            6:  #4 __tsan::MemToShadow(unsigned long) /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/lib/tsan/rtl/tsan_platform.h:1003:7 (bench_threads.cpp.tmp+0x1009ab) 
Step 11 (test compiler-rt debug) failure: test compiler-rt debug (failure)
...
llvm-lit: /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/lit.common.cfg.py:246: warning: COMPILER_RT_TEST_STANDALONE_BUILD_LIBS=ON, but this test suite does not support testing the just-built runtime libraries when the test compiler is configured to use different runtime libraries. Either modify this test suite to support this test configuration, or set COMPILER_RT_TEST_STANDALONE_BUILD_LIBS=OFF to test the runtime libraries included in the compiler instead.
llvm-lit: /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/lit.common.cfg.py:257: note: Testing using libraries in "/home/b/sanitizer-x86_64-linux/build/build_default/./lib/../lib/clang/22/lib/i386-unknown-linux-gnu"
llvm-lit: /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/lit.common.cfg.py:235: warning: Compiler lib dir != compiler-rt lib dir
Compiler libdir:     "/home/b/sanitizer-x86_64-linux/build/build_default/lib/clang/22/lib/i386-unknown-linux-gnu"
compiler-rt libdir:  "/home/b/sanitizer-x86_64-linux/build/build_default/lib/clang/22/lib/x86_64-unknown-linux-gnu"
llvm-lit: /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/lit.common.cfg.py:246: warning: COMPILER_RT_TEST_STANDALONE_BUILD_LIBS=ON, but this test suite does not support testing the just-built runtime libraries when the test compiler is configured to use different runtime libraries. Either modify this test suite to support this test configuration, or set COMPILER_RT_TEST_STANDALONE_BUILD_LIBS=OFF to test the runtime libraries included in the compiler instead.
llvm-lit: /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/lit.common.cfg.py:257: note: Testing using libraries in "/home/b/sanitizer-x86_64-linux/build/build_default/./lib/../lib/clang/22/lib/x86_64-unknown-linux-gnu"
llvm-lit: /home/b/sanitizer-x86_64-linux/build/llvm-project/llvm/utils/lit/lit/main.py:74: note: The test suite configuration requested an individual test timeout of 0 seconds but a timeout of 900 seconds was requested on the command line. Forcing timeout to be 900 seconds.
-- Testing: 4666 of 10459 tests, 64 workers --
Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 
FAIL: ThreadSanitizer-x86_64 :: bench_threads.cpp (4248 of 4666)
******************** TEST 'ThreadSanitizer-x86_64 :: bench_threads.cpp' FAILED ********************
Exit Code: 1

Command Output (stderr):
--
/home/b/sanitizer-x86_64-linux/build/build_default/./bin/clang  --driver-mode=g++ -fsanitize=thread -Wall  -m64  -msse4.2   -gline-tables-only -I/home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/tsan/../ -std=c++11 -I/home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/tsan/../ -nostdinc++ -I/home/b/sanitizer-x86_64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/lib/tsan/libcxx_tsan_x86_64/include/c++/v1 /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/tsan/bench_threads.cpp -o /home/b/sanitizer-x86_64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/tsan/X86_64Config/Output/bench_threads.cpp.tmp # RUN: at line 1
+ /home/b/sanitizer-x86_64-linux/build/build_default/./bin/clang --driver-mode=g++ -fsanitize=thread -Wall -m64 -msse4.2 -gline-tables-only -I/home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/tsan/../ -std=c++11 -I/home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/tsan/../ -nostdinc++ -I/home/b/sanitizer-x86_64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/lib/tsan/libcxx_tsan_x86_64/include/c++/v1 /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/tsan/bench_threads.cpp -o /home/b/sanitizer-x86_64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/tsan/X86_64Config/Output/bench_threads.cpp.tmp
/home/b/sanitizer-x86_64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/tsan/X86_64Config/Output/bench_threads.cpp.tmp 2>&1 | FileCheck /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/tsan/bench_threads.cpp # RUN: at line 2
+ FileCheck /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/tsan/bench_threads.cpp
+ /home/b/sanitizer-x86_64-linux/build/build_default/runtimes/runtimes-bins/compiler-rt/test/tsan/X86_64Config/Output/bench_threads.cpp.tmp
/home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/tsan/bench_threads.cpp:45:11: error: CHECK: expected string not found in input
// CHECK: DONE
          ^
<stdin>:1:1: note: scanning from here
ThreadSanitizer: CHECK failed: tsan_platform.h:992 "((IsAppMemImpl::Apply<Mapping>(x))) != (0)" (0x0, 0x0) (tid=3862854)
^
<stdin>:7:13: note: possible intended match here
 #5 __tsan::DontNeedShadowFor(unsigned long, unsigned long) /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/lib/tsan/rtl/tsan_rtl.cpp (bench_threads.cpp.tmp+0x1009ab)
            ^

Input file: <stdin>
Check file: /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/test/tsan/bench_threads.cpp

-dump-input=help explains the following input dump.

Input was:
<<<<<<
            1: ThreadSanitizer: CHECK failed: tsan_platform.h:992 "((IsAppMemImpl::Apply<Mapping>(x))) != (0)" (0x0, 0x0) (tid=3862854) 
check:45'0     X~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: no match found
            2:  #0 __tsan::CheckUnwind() /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/lib/tsan/rtl/tsan_rtl.cpp:696:21 (bench_threads.cpp.tmp+0x100f85) 
check:45'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            3:  #1 __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_termination.cpp:86:5 (bench_threads.cpp.tmp+0x8acd2) 
check:45'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            4:  #2 unsigned long __tsan::MemToShadowImpl::Apply<__tsan::Mapping48AddressSpace>(unsigned long) /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/lib/tsan/rtl/tsan_platform.h:992:5 (bench_threads.cpp.tmp+0x1009ab) 
check:45'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            5:  #3 auto __tsan::SelectMapping<__tsan::MemToShadowImpl, unsigned long>(unsigned long) /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/lib/tsan/rtl/tsan_platform.h:800:10 (bench_threads.cpp.tmp+0x1009ab) 
check:45'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
            6:  #4 __tsan::MemToShadow(unsigned long) /home/b/sanitizer-x86_64-linux/build/llvm-project/compiler-rt/lib/tsan/rtl/tsan_platform.h:1003:7 (bench_threads.cpp.tmp+0x1009ab) 

@to268 to268 deleted the issue-129631 branch November 18, 2025 14:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

clang:frontend Language frontend issues, e.g. anything involving "Sema" clang Clang issues not falling into any other category

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[clang] the "cleanup" attribute prevents type deduction

6 participants