[PATCH] D148439: [clang-rename] Exit gracefully when no input provided

2023-04-19 Thread Shivam Gupta via Phabricator via cfe-commits
xgupta updated this revision to Diff 514842.
xgupta marked an inline comment as done.
xgupta added a comment.

address comments


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148439/new/

https://reviews.llvm.org/D148439

Files:
  clang/test/clang-rename/NonExistFile.cpp
  clang/tools/clang-rename/ClangRename.cpp


Index: clang/tools/clang-rename/ClangRename.cpp
===
--- clang/tools/clang-rename/ClangRename.cpp
+++ clang/tools/clang-rename/ClangRename.cpp
@@ -229,6 +229,10 @@
 Tool.applyAllReplacements(Rewrite);
 for (const auto &File : Files) {
   auto Entry = FileMgr.getFile(File);
+  if (!Entry) {
+errs() << "clang-rename: " << File << " does not exist.\n";
+return 1;
+  }
   const auto ID = Sources.getOrCreateFileID(*Entry, SrcMgr::C_User);
   Rewrite.getEditBuffer(ID).write(outs());
 }
Index: clang/test/clang-rename/NonExistFile.cpp
===
--- /dev/null
+++ clang/test/clang-rename/NonExistFile.cpp
@@ -0,0 +1,2 @@
+// RUN: not clang-rename -offset=0 -new-name=bar non-existing-file 2>&1 | 
FileCheck %s
+// CHECK: clang-rename: non-existing-file does not exist.


Index: clang/tools/clang-rename/ClangRename.cpp
===
--- clang/tools/clang-rename/ClangRename.cpp
+++ clang/tools/clang-rename/ClangRename.cpp
@@ -229,6 +229,10 @@
 Tool.applyAllReplacements(Rewrite);
 for (const auto &File : Files) {
   auto Entry = FileMgr.getFile(File);
+  if (!Entry) {
+errs() << "clang-rename: " << File << " does not exist.\n";
+return 1;
+  }
   const auto ID = Sources.getOrCreateFileID(*Entry, SrcMgr::C_User);
   Rewrite.getEditBuffer(ID).write(outs());
 }
Index: clang/test/clang-rename/NonExistFile.cpp
===
--- /dev/null
+++ clang/test/clang-rename/NonExistFile.cpp
@@ -0,0 +1,2 @@
+// RUN: not clang-rename -offset=0 -new-name=bar non-existing-file 2>&1 | FileCheck %s
+// CHECK: clang-rename: non-existing-file does not exist.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148223: [SiFive] Support C intrinsics for xsfvcp extension.

2023-04-19 Thread Craig Topper via Phabricator via cfe-commits
craig.topper accepted this revision.
craig.topper added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148223/new/

https://reviews.llvm.org/D148223

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148315: [RISCV] Modify arch string parsing order according to latest riscv spec

2023-04-19 Thread Jun Sha via Phabricator via cfe-commits
joshua-arch1 added a comment.

In D148315#4279486 , @asb wrote:

> I'm starting to think we should just remove the ordering rules for z/s/x 
> altogether when parsing arch strings I see that gcc 12.2.0 actually requires 
> s and then z:
>
>   [asb@purge ~]$ riscv64-linux-gnu-gcc -march=rv64imafdc_svinval_zicbom t.c -c
>   [asb@purge ~]$ riscv64-linux-gnu-gcc -march=rv64imafdc_zicbom_svinval t.c -c
>   riscv64-linux-gnu-gcc: error: '-march=rv64imafdc_zicbom_svinval': 
> unexpected ISA string at end: 'svinval'
>
> So ISA naming strings aren't easily portable between clang and GCC right now, 
> even if the same extension names are recognised.

One of my colleagues working on GCC posted a patch to modify this order in GCC 
yesterday. Also, Binutils requires z and then s, which is inconsistent with GCC 
now.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148315/new/

https://reviews.llvm.org/D148315

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148690: [clang][Interp] Handle __extension__ unary operators

2023-04-19 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder created this revision.
tbaeder added reviewers: aaron.ballman, tahonermann, shafik, erichkeane.
Herald added a project: All.
tbaeder requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

AFAIK this is just used to suppress warnings, so ignore it altogether.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D148690

Files:
  clang/lib/AST/Interp/ByteCodeExprGen.cpp
  clang/test/AST/Interp/literals.cpp


Index: clang/test/AST/Interp/literals.cpp
===
--- clang/test/AST/Interp/literals.cpp
+++ clang/test/AST/Interp/literals.cpp
@@ -782,6 +782,12 @@
 
 namespace PredefinedExprs {
   constexpr char heh(unsigned index) {
+#if __cplusplus >= 201402L
+__FUNCTION__;   // ref-warning {{result unused}} \
+// expected-warning {{result unused}}
+__extension__ __FUNCTION__; // ref-warning {{result unused}} \
+// expected-warning {{result unused}}
+#endif
 return __FUNCTION__[index];
   }
   static_assert(heh(0) == 'h', "");
Index: clang/lib/AST/Interp/ByteCodeExprGen.cpp
===
--- clang/lib/AST/Interp/ByteCodeExprGen.cpp
+++ clang/lib/AST/Interp/ByteCodeExprGen.cpp
@@ -1856,6 +1856,9 @@
   case UO_Real:   // __real x
   case UO_Imag:   // __imag x
   case UO_Extension:
+if (DiscardResult)
+  return this->discard(SubExpr);
+return this->visit(SubExpr);
   case UO_Coawait:
 assert(false && "Unhandled opcode");
   }


Index: clang/test/AST/Interp/literals.cpp
===
--- clang/test/AST/Interp/literals.cpp
+++ clang/test/AST/Interp/literals.cpp
@@ -782,6 +782,12 @@
 
 namespace PredefinedExprs {
   constexpr char heh(unsigned index) {
+#if __cplusplus >= 201402L
+__FUNCTION__;   // ref-warning {{result unused}} \
+// expected-warning {{result unused}}
+__extension__ __FUNCTION__; // ref-warning {{result unused}} \
+// expected-warning {{result unused}}
+#endif
 return __FUNCTION__[index];
   }
   static_assert(heh(0) == 'h', "");
Index: clang/lib/AST/Interp/ByteCodeExprGen.cpp
===
--- clang/lib/AST/Interp/ByteCodeExprGen.cpp
+++ clang/lib/AST/Interp/ByteCodeExprGen.cpp
@@ -1856,6 +1856,9 @@
   case UO_Real:   // __real x
   case UO_Imag:   // __imag x
   case UO_Extension:
+if (DiscardResult)
+  return this->discard(SubExpr);
+return this->visit(SubExpr);
   case UO_Coawait:
 assert(false && "Unhandled opcode");
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148690: [clang][Interp] Handle __extension__ unary operators

2023-04-19 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder added inline comments.



Comment at: clang/test/AST/Interp/literals.cpp:791
+#endif
 return __FUNCTION__[index];
   }

It's weird that the above two statements warn about using `__FUNCTION__` and 
the return statement doesn't.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148690/new/

https://reviews.llvm.org/D148690

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148223: [SiFive] Support C intrinsics for xsfvcp extension.

2023-04-19 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added inline comments.



Comment at: clang/include/clang/Basic/riscv_sifive_vector.td:46
+
+multiclass RVVVCIXBuiltinSet range, string prototype,
+ list intrinsic_types, bit EncodeVtype,

We might consider breaking this class into 2 different classes. One for 
EncodeVtype=1 and EncodeVtype=0. The simplification might be worth the little 
bit of duplication.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148223/new/

https://reviews.llvm.org/D148223

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148439: [clang-rename] Exit gracefully when no input provided

2023-04-19 Thread Shivam Gupta via Phabricator via cfe-commits
xgupta added inline comments.



Comment at: clang/tools/clang-rename/ClangRename.cpp:233
+  if (!Entry) {
+errs() << "clang-rename: input file does not exist.\n";
+return 1;

kbobyrev wrote:
> It is worth including the filename in the error message, otherwise it won't 
> be possible to understand which one is missing (there can be multiple IIRC, 
> right?).
> 
> Also, it's better to put this check to the top of main, where the `OP` if 
> first declared, since this is a sanity check and we want to fail if the 
> inputs are corrupted.
Thanks for the suggestion, I agree, I updated the error message regarding the 
filename. 

But I am not sure running a similar `for` loop again should be the correct way.
So just sharing the diff before committing, WDYT -

```
diff --git a/clang/tools/clang-rename/ClangRename.cpp 
b/clang/tools/clang-rename/ClangRename.cpp
index 24c9d8521..bc777cc01 100644
--- a/clang/tools/clang-rename/ClangRename.cpp
+++ b/clang/tools/clang-rename/ClangRename.cpp
@@ -106,6 +106,17 @@ int main(int argc, const char **argv) {
   }
   tooling::CommonOptionsParser &OP = ExpectedParser.get();
 
+  auto Files = OP.getSourcePathList();
+  tooling::RefactoringTool Tool(OP.getCompilations(), Files);
+auto &FileMgr = Tool.getFiles();
+  for (const auto &File : Files) {
+  auto Entry = FileMgr.getFile(File);
+  if (!Entry) {
+errs() << "clang-rename: " << File << " does not exist.\n";
+return 1;
+  }
+}
+
   if (!Input.empty()) {
 // Populate QualifiedNames and NewNames from a YAML file.
 ErrorOr> Buffer =
@@ -162,8 +173,6 @@ int main(int argc, const char **argv) {
 return 1;
   }
 
-  auto Files = OP.getSourcePathList();
-  tooling::RefactoringTool Tool(OP.getCompilations(), Files);
   tooling::USRFindingAction FindingAction(SymbolOffsets, QualifiedNames, 
Force);
   Tool.run(tooling::newFrontendActionFactory(&FindingAction).get());
   const std::vector> &USRList =
@@ -222,7 +231,6 @@ int main(int argc, const char **argv) {
 DiagnosticsEngine Diagnostics(
 IntrusiveRefCntPtr(new DiagnosticIDs()), &*DiagOpts,
 &DiagnosticPrinter, false);
-auto &FileMgr = Tool.getFiles();
 SourceManager Sources(Diagnostics, FileMgr);
 Rewriter Rewrite(Sources, DefaultLangOptions);
 
```


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148439/new/

https://reviews.llvm.org/D148439

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D147928: [clang] Keep multiple-include optimization for null directives

2023-04-19 Thread Elliot Goodrich via Phabricator via cfe-commits
IncludeGuardian updated this revision to Diff 514849.
IncludeGuardian added a comment.

Replace `ResetReadToken` with `SetReadToken` to avoid a conditional


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147928/new/

https://reviews.llvm.org/D147928

Files:
  clang/include/clang/Lex/MultipleIncludeOpt.h
  clang/lib/Lex/PPDirectives.cpp
  clang/test/Preprocessor/multiple-inclusion-opt.cpp
  clang/test/Preprocessor/multiple-inclusion-opt.h


Index: clang/test/Preprocessor/multiple-inclusion-opt.h
===
--- /dev/null
+++ clang/test/Preprocessor/multiple-inclusion-opt.h
@@ -0,0 +1,18 @@
+# // null directive and comments before include guard
+
+#ifndef MULTIPLE_INCLUSION_OPT
+
+int foo();
+
+// The position of the define should not matter
+#define MULTIPLE_INCLUSION_OPT
+
+int bar();
+
+#endif
+
+#
+#
+/* Two null directives
+   and a multiline comment
+   after the #endif */
Index: clang/test/Preprocessor/multiple-inclusion-opt.cpp
===
--- /dev/null
+++ clang/test/Preprocessor/multiple-inclusion-opt.cpp
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -E -P -H %s 2>&1 | grep "multiple-inclusion-opt.h" | count 1
+
+#include "multiple-inclusion-opt.h"
+#include "multiple-inclusion-opt.h"
+#include "multiple-inclusion-opt.h"
+#include "multiple-inclusion-opt.h"
+#include "multiple-inclusion-opt.h"
Index: clang/lib/Lex/PPDirectives.cpp
===
--- clang/lib/Lex/PPDirectives.cpp
+++ clang/lib/Lex/PPDirectives.cpp
@@ -1177,6 +1177,10 @@
 
   switch (Result.getKind()) {
   case tok::eod:
+// Ignore the null directive with regards to the multiple-include
+// optimization, i.e. allow the null directive to appear outside of the
+// include guard and still enable the multiple-include optimization.
+CurPPLexer->MIOpt.SetReadToken(ReadAnyTokensBeforeDirective);
 return;   // null directive.
   case tok::code_completion:
 setCodeCompletionReached();
Index: clang/include/clang/Lex/MultipleIncludeOpt.h
===
--- clang/include/clang/Lex/MultipleIncludeOpt.h
+++ clang/include/clang/Lex/MultipleIncludeOpt.h
@@ -108,6 +108,12 @@
 ImmediatelyAfterTopLevelIfndef = false;
   }
 
+  /// SetReadToken - Set whether the value of 'ReadAnyTokens'.  Called to
+  /// override when encountering tokens outside of the include guard that have
+  /// no effect if the file in question is is included multiple times (e.g. the
+  /// null directive).
+  void SetReadToken(bool Value) { ReadAnyTokens = Value; }
+
   /// ExpandedMacro - When a macro is expanded with this lexer as the current
   /// buffer, this method is called to disable the MIOpt if needed.
   void ExpandedMacro() { DidMacroExpansion = true; }


Index: clang/test/Preprocessor/multiple-inclusion-opt.h
===
--- /dev/null
+++ clang/test/Preprocessor/multiple-inclusion-opt.h
@@ -0,0 +1,18 @@
+# // null directive and comments before include guard
+
+#ifndef MULTIPLE_INCLUSION_OPT
+
+int foo();
+
+// The position of the define should not matter
+#define MULTIPLE_INCLUSION_OPT
+
+int bar();
+
+#endif
+
+#
+#
+/* Two null directives
+   and a multiline comment
+   after the #endif */
Index: clang/test/Preprocessor/multiple-inclusion-opt.cpp
===
--- /dev/null
+++ clang/test/Preprocessor/multiple-inclusion-opt.cpp
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -E -P -H %s 2>&1 | grep "multiple-inclusion-opt.h" | count 1
+
+#include "multiple-inclusion-opt.h"
+#include "multiple-inclusion-opt.h"
+#include "multiple-inclusion-opt.h"
+#include "multiple-inclusion-opt.h"
+#include "multiple-inclusion-opt.h"
Index: clang/lib/Lex/PPDirectives.cpp
===
--- clang/lib/Lex/PPDirectives.cpp
+++ clang/lib/Lex/PPDirectives.cpp
@@ -1177,6 +1177,10 @@
 
   switch (Result.getKind()) {
   case tok::eod:
+// Ignore the null directive with regards to the multiple-include
+// optimization, i.e. allow the null directive to appear outside of the
+// include guard and still enable the multiple-include optimization.
+CurPPLexer->MIOpt.SetReadToken(ReadAnyTokensBeforeDirective);
 return;   // null directive.
   case tok::code_completion:
 setCodeCompletionReached();
Index: clang/include/clang/Lex/MultipleIncludeOpt.h
===
--- clang/include/clang/Lex/MultipleIncludeOpt.h
+++ clang/include/clang/Lex/MultipleIncludeOpt.h
@@ -108,6 +108,12 @@
 ImmediatelyAfterTopLevelIfndef = false;
   }
 
+  /// SetReadToken - Set whether the value of 'ReadAnyTokens'.  Called to
+  /// override when encountering tokens outside of the include guard that have
+  /// no effect if the file in question is is inc

[PATCH] D148601: [Clang] Handle Error message to output proper Prefix

2023-04-19 Thread Usman Akinyemi via Phabricator via cfe-commits
Unique_Usman added a comment.

In D148601#4279334 , @tbaeder wrote:

> I am not 100% sure about the semantics of passing multiple prefixes, i.e. if 
> the error is emitted for all prefixes individually or if it's only emitted if 
> no `expected` line for any of the prefixes is found. In the latter case we 
> should probably add all the prefixes to the error message.

I tested different scenerios e.g added more than one RUN lines with different 
value of -verify, what I concluded on is that if we have multiple  RUN lines 
with each of them having no directive, the prefixes generated is always of the 
first occurence  with no  expected directive so, the error is always generated 
for the first occurence with no expected directive.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148601/new/

https://reviews.llvm.org/D148601

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D147875: [clang][Diagnostics] WIP: Show line numbers when printing code snippets

2023-04-19 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder added a comment.

Ping


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147875/new/

https://reviews.llvm.org/D147875

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 107b307 - Reapply D146987 "[Assignment Tracking] Enable by default"

2023-04-19 Thread via cfe-commits

Author: OCHyams
Date: 2023-04-19T09:32:09+01:00
New Revision: 107b307bd61e51aa66ea41f1a2c92c1459b39c7e

URL: 
https://github.com/llvm/llvm-project/commit/107b307bd61e51aa66ea41f1a2c92c1459b39c7e
DIFF: 
https://github.com/llvm/llvm-project/commit/107b307bd61e51aa66ea41f1a2c92c1459b39c7e.diff

LOG: Reapply D146987 "[Assignment Tracking] Enable by default"

This reverts commit efc8b52cbd942f4bd5ffe8f64da5fb8a3b7adc32
which reverts D146987.

See https://reviews.llvm.org/D146987 for issues.

Added: 


Modified: 
clang/include/clang/Driver/Options.td
clang/test/CodeGen/assignment-tracking/flag.cpp

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index eed0d517a1ad7..604b4a45fffc1 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -5817,7 +5817,7 @@ def fexperimental_assignment_tracking_EQ : Joined<["-"], 
"fexperimental-assignme
   Group, CodeGenOpts<"EnableAssignmentTracking">,
   NormalizedValuesScope<"CodeGenOptions::AssignmentTrackingOpts">,
   Values<"disabled,enabled,forced">, 
NormalizedValues<["Disabled","Enabled","Forced"]>,
-  MarshallingInfoEnum, "Disabled">;
+  MarshallingInfoEnum, "Enabled">;
 
 } // let Flags = [CC1Option, NoDriverOption]
 

diff  --git a/clang/test/CodeGen/assignment-tracking/flag.cpp 
b/clang/test/CodeGen/assignment-tracking/flag.cpp
index aa1f054dae4d7..3bd974fe07c6c 100644
--- a/clang/test/CodeGen/assignment-tracking/flag.cpp
+++ b/clang/test/CodeGen/assignment-tracking/flag.cpp
@@ -8,10 +8,10 @@
 // RUN: -emit-llvm  %s -o - -fexperimental-assignment-tracking=disabled 
-O1\
 // RUN: | FileCheck %s --check-prefixes=DISABLE
 
- Disabled by default:
+ Enabled by default:
 // RUN: %clang_cc1 -triple x86_64-none-linux-gnu -debug-info-kind=standalone   
\
 // RUN: -emit-llvm  %s -o - -O1
\
-// RUN: | FileCheck %s --check-prefixes=DISABLE
+// RUN: | FileCheck %s --check-prefixes=ENABLE
 
  Disabled at O0 unless forced.
 // RUN: %clang_cc1 -triple x86_64-none-linux-gnu -debug-info-kind=standalone   
\



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D146987: [Assignment Tracking] Enable by default

2023-04-19 Thread Orlando Cazalet-Hyams via Phabricator via cfe-commits
Orlando added a comment.

Thanks everyone for begin patient with this one. I've just pushed again after 
landing D148536 . I am hoping that's the last 
issue... I am watching the buildbots and chromium build page.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D146987/new/

https://reviews.llvm.org/D146987

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 7674ae7 - Revert D146987 "[Assignment Tracking] Enable by default"

2023-04-19 Thread via cfe-commits

Author: OCHyams
Date: 2023-04-19T10:03:32+01:00
New Revision: 7674ae7231c4e286b93eb399e475765630666f8b

URL: 
https://github.com/llvm/llvm-project/commit/7674ae7231c4e286b93eb399e475765630666f8b
DIFF: 
https://github.com/llvm/llvm-project/commit/7674ae7231c4e286b93eb399e475765630666f8b.diff

LOG: Revert D146987 "[Assignment Tracking] Enable by default"

This reverts commit 107b307bd61e51aa66ea41f1a2c92c1459b39c7e due
to build errors in a parent commit fca3e8e024f0015604d21e6f76f3e199345679c5

Added: 


Modified: 
clang/include/clang/Driver/Options.td
clang/test/CodeGen/assignment-tracking/flag.cpp

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 604b4a45fffc1..eed0d517a1ad7 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -5817,7 +5817,7 @@ def fexperimental_assignment_tracking_EQ : Joined<["-"], 
"fexperimental-assignme
   Group, CodeGenOpts<"EnableAssignmentTracking">,
   NormalizedValuesScope<"CodeGenOptions::AssignmentTrackingOpts">,
   Values<"disabled,enabled,forced">, 
NormalizedValues<["Disabled","Enabled","Forced"]>,
-  MarshallingInfoEnum, "Enabled">;
+  MarshallingInfoEnum, "Disabled">;
 
 } // let Flags = [CC1Option, NoDriverOption]
 

diff  --git a/clang/test/CodeGen/assignment-tracking/flag.cpp 
b/clang/test/CodeGen/assignment-tracking/flag.cpp
index 3bd974fe07c6c..aa1f054dae4d7 100644
--- a/clang/test/CodeGen/assignment-tracking/flag.cpp
+++ b/clang/test/CodeGen/assignment-tracking/flag.cpp
@@ -8,10 +8,10 @@
 // RUN: -emit-llvm  %s -o - -fexperimental-assignment-tracking=disabled 
-O1\
 // RUN: | FileCheck %s --check-prefixes=DISABLE
 
- Enabled by default:
+ Disabled by default:
 // RUN: %clang_cc1 -triple x86_64-none-linux-gnu -debug-info-kind=standalone   
\
 // RUN: -emit-llvm  %s -o - -O1
\
-// RUN: | FileCheck %s --check-prefixes=ENABLE
+// RUN: | FileCheck %s --check-prefixes=DISABLE
 
  Disabled at O0 unless forced.
 // RUN: %clang_cc1 -triple x86_64-none-linux-gnu -debug-info-kind=standalone   
\



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148694: [SanitizerBinaryMetadata] Respect no_sanitize("thread") function attribute

2023-04-19 Thread Marco Elver via Phabricator via cfe-commits
melver created this revision.
melver added a reviewer: dvyukov.
Herald added subscribers: Enna1, hiraditya.
Herald added a project: All.
melver requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

To avoid false positives, respect no_sanitize("thread") when atomics
metadata is enabled.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D148694

Files:
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/test/CodeGen/sanitize-metadata-nosanitize.c
  llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp

Index: llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp
===
--- llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp
+++ llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp
@@ -90,6 +90,11 @@
 "sanitizer-metadata-weak-callbacks",
 cl::desc("Declare callbacks extern weak, and only call if non-null."),
 cl::Hidden, cl::init(true));
+cl::opt
+ClNoSanitize("sanitizer-metadata-nosanitize-attr",
+ cl::desc("Mark some metadata features uncovered in functions "
+  "with associated no_sanitize attributes."),
+ cl::Hidden, cl::init(true));
 
 cl::opt ClEmitCovered("sanitizer-metadata-covered",
 cl::desc("Emit PCs for covered functions."),
@@ -268,6 +273,8 @@
 RequiresCovered |= runOn(I, MIS, MDB, FeatureMask);
   }
 
+  if (ClNoSanitize && F.hasFnAttribute("no_sanitize_thread"))
+FeatureMask &= ~kSanitizerBinaryMetadataAtomics;
   if (F.isVarArg())
 FeatureMask &= ~kSanitizerBinaryMetadataUAR;
   if (FeatureMask & kSanitizerBinaryMetadataUAR) {
Index: clang/test/CodeGen/sanitize-metadata-nosanitize.c
===
--- /dev/null
+++ clang/test/CodeGen/sanitize-metadata-nosanitize.c
@@ -0,0 +1,113 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --check-attributes --check-globals --version 2
+// RUN: %clang_cc1 -O -fexperimental-sanitize-metadata=covered -fexperimental-sanitize-metadata=atomics -fexperimental-sanitize-metadata=uar -triple x86_64-gnu-linux -x c -S -emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK
+
+//.
+// CHECK: @__start_sanmd_covered = extern_weak hidden global ptr
+// CHECK: @__stop_sanmd_covered = extern_weak hidden global ptr
+// CHECK: @__start_sanmd_atomics = extern_weak hidden global ptr
+// CHECK: @__stop_sanmd_atomics = extern_weak hidden global ptr
+// CHECK: @llvm.used = appending global [4 x ptr] [ptr @__sanitizer_metadata_covered.module_ctor, ptr @__sanitizer_metadata_covered.module_dtor, ptr @__sanitizer_metadata_atomics.module_ctor, ptr @__sanitizer_metadata_atomics.module_dtor], section "llvm.metadata"
+// CHECK: @llvm.global_ctors = appending global [2 x { i32, ptr, ptr }] [{ i32, ptr, ptr } { i32 2, ptr @__sanitizer_metadata_covered.module_ctor, ptr @__sanitizer_metadata_covered.module_ctor }, { i32, ptr, ptr } { i32 2, ptr @__sanitizer_metadata_atomics.module_ctor, ptr @__sanitizer_metadata_atomics.module_ctor }]
+// CHECK: @llvm.global_dtors = appending global [2 x { i32, ptr, ptr }] [{ i32, ptr, ptr } { i32 2, ptr @__sanitizer_metadata_covered.module_dtor, ptr @__sanitizer_metadata_covered.module_dtor }, { i32, ptr, ptr } { i32 2, ptr @__sanitizer_metadata_atomics.module_dtor, ptr @__sanitizer_metadata_atomics.module_dtor }]
+//.
+// CHECK: Function Attrs: mustprogress nofree noinline norecurse nosync nounwind willreturn memory(write, argmem: none, inaccessiblemem: none)
+// CHECK-LABEL: define dso_local void @escape
+// CHECK-SAME: (ptr noundef [[P:%.*]]) local_unnamed_addr #[[ATTR0:[0-9]+]] !pcsections !2 {
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:ret void
+//
+__attribute__((noinline, not_tail_called)) void escape(const volatile void *p) {
+  static const volatile void *sink;
+  sink = p;
+}
+
+// CHECK: Function Attrs: mustprogress nofree norecurse nounwind willreturn memory(write, argmem: readwrite, inaccessiblemem: none)
+// CHECK-LABEL: define dso_local i32 @normal_function
+// CHECK-SAME: (ptr noundef [[X:%.*]], ptr nocapture noundef readonly [[Y:%.*]]) local_unnamed_addr #[[ATTR1:[0-9]+]] !pcsections !4 {
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[X_ADDR:%.*]] = alloca ptr, align 8
+// CHECK-NEXT:store ptr [[X]], ptr [[X_ADDR]], align 8, !tbaa [[TBAA6:![0-9]+]]
+// CHECK-NEXT:store atomic i32 1, ptr [[X]] monotonic, align 4, !pcsections !10
+// CHECK-NEXT:notail call void @escape(ptr noundef nonnull [[X_ADDR]])
+// CHECK-NEXT:[[TMP0:%.*]] = load i32, ptr [[Y]], align 4, !tbaa [[TBAA11:![0-9]+]]
+// CHECK-NEXT:ret i32 [[TMP0]]
+//
+int normal_function(int *x, int *y) {
+  __atomic_store_n(x, 1, __ATOMIC_RELAXED);
+  escape(&x);
+  return *y;
+}
+
+// CHECK: Function Attrs: disable_sanitizer_instrumentation mustprogress nofree norecurse nounwind

[PATCH] D148694: [SanitizerBinaryMetadata] Respect no_sanitize("thread") function attribute

2023-04-19 Thread Marco Elver via Phabricator via cfe-commits
melver updated this revision to Diff 514871.
melver added a comment.

Fix test


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148694/new/

https://reviews.llvm.org/D148694

Files:
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/test/CodeGen/sanitize-metadata-nosanitize.c
  llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp

Index: llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp
===
--- llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp
+++ llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp
@@ -90,6 +90,11 @@
 "sanitizer-metadata-weak-callbacks",
 cl::desc("Declare callbacks extern weak, and only call if non-null."),
 cl::Hidden, cl::init(true));
+cl::opt
+ClNoSanitize("sanitizer-metadata-nosanitize-attr",
+ cl::desc("Mark some metadata features uncovered in functions "
+  "with associated no_sanitize attributes."),
+ cl::Hidden, cl::init(true));
 
 cl::opt ClEmitCovered("sanitizer-metadata-covered",
 cl::desc("Emit PCs for covered functions."),
@@ -268,6 +273,8 @@
 RequiresCovered |= runOn(I, MIS, MDB, FeatureMask);
   }
 
+  if (ClNoSanitize && F.hasFnAttribute("no_sanitize_thread"))
+FeatureMask &= ~kSanitizerBinaryMetadataAtomics;
   if (F.isVarArg())
 FeatureMask &= ~kSanitizerBinaryMetadataUAR;
   if (FeatureMask & kSanitizerBinaryMetadataUAR) {
Index: clang/test/CodeGen/sanitize-metadata-nosanitize.c
===
--- /dev/null
+++ clang/test/CodeGen/sanitize-metadata-nosanitize.c
@@ -0,0 +1,111 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --check-attributes --check-globals --version 2
+// RUN: %clang_cc1 -O -fexperimental-sanitize-metadata=covered -fexperimental-sanitize-metadata=atomics -fexperimental-sanitize-metadata=uar -triple x86_64-gnu-linux -x c -S -emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK
+
+//.
+// CHECK: @__start_sanmd_covered = extern_weak hidden global ptr
+// CHECK: @__stop_sanmd_covered = extern_weak hidden global ptr
+// CHECK: @__start_sanmd_atomics = extern_weak hidden global ptr
+// CHECK: @__stop_sanmd_atomics = extern_weak hidden global ptr
+// CHECK: @llvm.used = appending global [4 x ptr] [ptr @__sanitizer_metadata_covered.module_ctor, ptr @__sanitizer_metadata_covered.module_dtor, ptr @__sanitizer_metadata_atomics.module_ctor, ptr @__sanitizer_metadata_atomics.module_dtor], section "llvm.metadata"
+// CHECK: @llvm.global_ctors = appending global [2 x { i32, ptr, ptr }] [{ i32, ptr, ptr } { i32 2, ptr @__sanitizer_metadata_covered.module_ctor, ptr @__sanitizer_metadata_covered.module_ctor }, { i32, ptr, ptr } { i32 2, ptr @__sanitizer_metadata_atomics.module_ctor, ptr @__sanitizer_metadata_atomics.module_ctor }]
+// CHECK: @llvm.global_dtors = appending global [2 x { i32, ptr, ptr }] [{ i32, ptr, ptr } { i32 2, ptr @__sanitizer_metadata_covered.module_dtor, ptr @__sanitizer_metadata_covered.module_dtor }, { i32, ptr, ptr } { i32 2, ptr @__sanitizer_metadata_atomics.module_dtor, ptr @__sanitizer_metadata_atomics.module_dtor }]
+//.
+// CHECK: Function Attrs: mustprogress nofree noinline norecurse nosync nounwind willreturn memory(write, argmem: none, inaccessiblemem: none)
+// CHECK-LABEL: define dso_local void @escape
+// CHECK-SAME: (ptr noundef [[P:%.*]]) local_unnamed_addr #[[ATTR0:[0-9]+]] !pcsections !2 {
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:ret void
+//
+__attribute__((noinline, not_tail_called)) void escape(const volatile void *p) {
+  static const volatile void *sink;
+  sink = p;
+}
+
+// CHECK: Function Attrs: mustprogress nofree norecurse nounwind willreturn memory(write, argmem: readwrite, inaccessiblemem: none)
+// CHECK-LABEL: define dso_local i32 @normal_function
+// CHECK-SAME: (ptr noundef [[X:%.*]], ptr nocapture noundef readonly [[Y:%.*]]) local_unnamed_addr #[[ATTR1:[0-9]+]] !pcsections !4 {
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[X_ADDR:%.*]] = alloca ptr, align 8
+// CHECK-NEXT:store ptr [[X]], ptr [[X_ADDR]], align 8, !tbaa [[TBAA6:![0-9]+]]
+// CHECK-NEXT:store atomic i32 1, ptr [[X]] monotonic, align 4, !pcsections !10
+// CHECK-NEXT:notail call void @escape(ptr noundef nonnull [[X_ADDR]])
+// CHECK-NEXT:[[TMP0:%.*]] = load i32, ptr [[Y]], align 4, !tbaa [[TBAA11:![0-9]+]]
+// CHECK-NEXT:ret i32 [[TMP0]]
+//
+int normal_function(int *x, int *y) {
+  __atomic_store_n(x, 1, __ATOMIC_RELAXED);
+  escape(&x);
+  return *y;
+}
+
+// CHECK: Function Attrs: disable_sanitizer_instrumentation mustprogress nofree norecurse nounwind willreturn memory(write, argmem: readwrite, inaccessiblemem: none)
+// CHECK-LABEL: define dso_local i32 @test_disable_sanitize_instrumentation
+// CHECK-SAME: (ptr noundef [[X:%.*]], ptr nocapture noundef readon

[PATCH] D144269: [Analyzer] Show "taint originated here" note of alpha.security.taint.TaintPropagation checker at the correct place

2023-04-19 Thread Balázs Benics via Phabricator via cfe-commits
steakhal requested changes to this revision.
steakhal added a comment.
This revision now requires changes to proceed.

Nice improvement!
I only have minor nitpicks and some recommendations for the taint API.




Comment at: clang/lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp:205
+BR.markInteresting(CallLocation);
+if (TaintedArgs.at(Idx) != ReturnValueIndex) {
+  LLVM_DEBUG(llvm::dbgs() << "Taint Propagated to argument "

We usually use the `operator[]` on vector instead of the `at()`. When in doubt, 
we assert that the index is in `idx < size()`.
Apply this for all `.at()` uses.



Comment at: clang/lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp:209-214
+  if (nofTaintedArgs == 0)
+Out << "Taint propagated to argument "
+<< TaintedArgs.at(Sym.index()) + 1;
+  else
+Out << ", " << TaintedArgs.at(Sym.index()) + 1;
+  nofTaintedArgs++;

dkrupp wrote:
> steakhal wrote:
> > I'd recommend using `llvm::interleaveComma()` in such cases.
> > You can probably get rid of `nofTaintedArgs` as well - by using this 
> > function.
> I chose another solution. I hope that is ok too.
Looks good. I'm not expecting many cases propagating to multiple arguments 
anyway.



Comment at: clang/lib/StaticAnalyzer/Checkers/Taint.cpp:147-150
 bool taint::isTainted(ProgramStateRef State, const Stmt *S,
   const LocationContext *LCtx, TaintTagType Kind) {
-  SVal val = State->getSVal(S, LCtx);
-  return isTainted(State, val, Kind);
+  return !getTaintedSymbols(State, S, LCtx, Kind).empty();
 }

TBH I'm not sure if I like that now we allocate unbounded amount of times 
(because of `getTaintedSymbols()` is recursive and returns by value), where we 
previously did not.

What we could possibly do is to compute the elements of this sequence lazily.
I'm thinking of the `llvm::mapped_iterator`, but I'm not sure if it's possible 
to have something like that as a return type as it might encode the map 
function in the type or something like that.
Anyway, I'm just saying that it would be nice to not do more than it's 
necessary, and especially not allocate a lot of short-lived objects there.

Do you think there is a way to have the cake and eat it too?

---

I did some investigation, and one could get pretty far in the implementation, 
and maybe even complete it but it would be really complicated as of now. Maybe 
we could revisit this subject when we have coroutines.

So, I would suggest to have two sets of APIs:
 - the usual `isTainted(.) -> bool`
 - and a `getTaintedSymbols(.) -> vector`
The important point would be that the `isTainted()` version would not eagerly 
collect all tainted sub-syms but return on finding the first one.
While, the `getTaintedSymbols()` would collect eagerly all of them, as its name 
suggests.

Imagine if `getTaintedSymbolsImpl()` had an extra flag like `bool 
returnAfterFirstMatch`. This way `isTainted()` can call it like that. While in 
the other case, the parameter would be `false`, and eagerly collect all symbols.

This is probably the best of both worlds, as it prevents `isTainted` from doing 
extra work and if we need to iterate over the tainted symbols, we always 
iterate over all of them, so doing it lazily wouldn't gain us much in that case 
anyway.
As a bonus, the user-facing API would be self-descriptive.

WDYT?



Comment at: clang/lib/StaticAnalyzer/Checkers/Taint.cpp:265-268
+  std::vector TaintedRegions =
+  getTaintedSymbols(State, SRV->getRegion(), Kind);
+  TaintedSymbols.insert(TaintedSymbols.begin(), TaintedRegions.begin(),
+TaintedRegions.end());

For such constructs, I would prefer this.



Comment at: clang/test/Analysis/taint-diagnostic-visitor.c:12-13
+char* getenv( const char* env_var );
+size_t strlen( const char* str );
+void *malloc(size_t size );
+void free( void *ptr );

The [[ 
https://buildkite.com/llvm-project/premerge-checks/builds/146760#01877fd9-2f3a-4f8d-9ffa-6e017eb883c5
 | premerge bots ]] are complaining about these two lines on Windows:
```
error: 'warning' diagnostics seen but not expected: 
  File 
C:\ws\w8\llvm-project\premerge-checks\clang\test\Analysis\taint-diagnostic-visitor.c
 Line 12: incompatible redeclaration of library function 'strlen'
  File 
C:\ws\w8\llvm-project\premerge-checks\clang\test\Analysis\taint-diagnostic-visitor.c
 Line 13: incompatible redeclaration of library function 'malloc'
error: 'note' diagnostics seen but not expected: 
  File 
C:\ws\w8\llvm-project\premerge-checks\clang\test\Analysis\taint-diagnostic-visitor.c
 Line 12: 'strlen' is a builtin with type 'unsigned long long (const char *)'
  File 
C:\ws\w8\llvm-project\premerge-checks\clang\test\Analysis\taint-diagnostic-visitor.c
 Line 13: 'malloc' is a builtin with type 'void

[PATCH] D148696: [clang][Sema][NFC] Sprinkle some const around in Sema

2023-04-19 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder created this revision.
tbaeder added reviewers: aaron.ballman, shafik.
Herald added a project: All.
tbaeder requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

NFC but uploading for review for the pre-commit CI and maybe some actual review.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D148696

Files:
  clang/include/clang/AST/DeclarationName.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/DeclarationName.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaLookup.cpp

Index: clang/lib/Sema/SemaLookup.cpp
===
--- clang/lib/Sema/SemaLookup.cpp
+++ clang/lib/Sema/SemaLookup.cpp
@@ -199,7 +199,7 @@
 const_iterator end() const { return list.end(); }
 
 llvm::iterator_range
-getNamespacesFor(DeclContext *DC) const {
+getNamespacesFor(const DeclContext *DC) const {
   return llvm::make_range(std::equal_range(begin(), end(),
DC->getPrimaryContext(),
UnqualUsingEntry::Comparator()));
@@ -351,12 +351,12 @@
 
 /// Get a representative context for a declaration such that two declarations
 /// will have the same context if they were found within the same scope.
-static DeclContext *getContextForScopeMatching(Decl *D) {
+static const DeclContext *getContextForScopeMatching(const Decl *D) {
   // For function-local declarations, use that function as the context. This
   // doesn't account for scopes within the function; the caller must deal with
   // those.
-  DeclContext *DC = D->getLexicalDeclContext();
-  if (DC->isFunctionOrMethod())
+  if (const DeclContext *DC = D->getLexicalDeclContext();
+  DC->isFunctionOrMethod())
 return DC;
 
   // Otherwise, look at the semantic context of the declaration. The
@@ -367,15 +367,16 @@
 /// Determine whether \p D is a better lookup result than \p Existing,
 /// given that they declare the same entity.
 static bool isPreferredLookupResult(Sema &S, Sema::LookupNameKind Kind,
-NamedDecl *D, NamedDecl *Existing) {
+const NamedDecl *D,
+const NamedDecl *Existing) {
   // When looking up redeclarations of a using declaration, prefer a using
   // shadow declaration over any other declaration of the same entity.
   if (Kind == Sema::LookupUsingDeclName && isa(D) &&
   !isa(Existing))
 return true;
 
-  auto *DUnderlying = D->getUnderlyingDecl();
-  auto *EUnderlying = Existing->getUnderlyingDecl();
+  const auto *DUnderlying = D->getUnderlyingDecl();
+  const auto *EUnderlying = Existing->getUnderlyingDecl();
 
   // If they have different underlying declarations, prefer a typedef over the
   // original type (this happens when two type declarations denote the same
@@ -397,8 +398,8 @@
   // FIXME: In the presence of ambiguous default arguments, we should keep both,
   //so we can diagnose the ambiguity if the default argument is needed.
   //See C++ [over.match.best]p3.
-  if (auto *DFD = dyn_cast(DUnderlying)) {
-auto *EFD = cast(EUnderlying);
+  if (const auto *DFD = dyn_cast(DUnderlying)) {
+const auto *EFD = cast(EUnderlying);
 unsigned DMin = DFD->getMinRequiredArguments();
 unsigned EMin = EFD->getMinRequiredArguments();
 // If D has more default arguments, it is preferred.
@@ -409,8 +410,8 @@
   }
 
   // Pick the template with more default template arguments.
-  if (auto *DTD = dyn_cast(DUnderlying)) {
-auto *ETD = cast(EUnderlying);
+  if (const auto *DTD = dyn_cast(DUnderlying)) {
+const auto *ETD = cast(EUnderlying);
 unsigned DMin = DTD->getTemplateParameters()->getMinRequiredArguments();
 unsigned EMin = ETD->getTemplateParameters()->getMinRequiredArguments();
 // If D has more default arguments, it is preferred. Note that default
@@ -433,8 +434,8 @@
 
   // VarDecl can have incomplete array types, prefer the one with more complete
   // array type.
-  if (VarDecl *DVD = dyn_cast(DUnderlying)) {
-VarDecl *EVD = cast(EUnderlying);
+  if (const auto *DVD = dyn_cast(DUnderlying)) {
+const auto *EVD = cast(EUnderlying);
 if (EVD->getType()->isIncompleteType() &&
 !DVD->getType()->isIncompleteType()) {
   // Prefer the decl with a more complete type if visible.
@@ -451,7 +452,7 @@
   }
 
   // Pick the newer declaration; it might have a more precise type.
-  for (Decl *Prev = DUnderlying->getPreviousDecl(); Prev;
+  for (const Decl *Prev = DUnderlying->getPreviousDecl(); Prev;
Prev = Prev->getPreviousDecl())
 if (Prev == EUnderlying)
   return true;
@@ -459,7 +460,7 @@
 }
 
 /// Determine whether \p D can hide a tag declaration.
-static bool canHideTag(NamedDecl *D) {
+static bool canHideTag(const NamedDecl *D) {
   // C++ [basic.scope.declarative]p4:
   //   Given a set

[PATCH] D148697: [clang-tidy] Handle more cases of functions which should always be noexcept

2023-04-19 Thread André Schackier via Phabricator via cfe-commits
AMS21 created this revision.
AMS21 added reviewers: PiotrZSL, njames93.
Herald added subscribers: carlosgalvezp, kbarton, xazax.hun, nemanjai.
Herald added a project: All.
AMS21 requested review of this revision.
Herald added a project: clang-tools-extra.
Herald added a subscriber: cfe-commits.

Renamed `performance-noexcept-move-constructor` -> 
`performance-noexcept-special-functions`
to reflect that it now also handles default constructors, destructors and swap 
functions.
Add check alias `cppcoreguidelines-noexcept-special-functions`.

This fixes llvm#62154


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D148697

Files:
  clang-tools-extra/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
  clang-tools-extra/clang-tidy/hicpp/HICPPTidyModule.cpp
  clang-tools-extra/clang-tidy/performance/CMakeLists.txt
  clang-tools-extra/clang-tidy/performance/NoexceptMoveConstructorCheck.cpp
  clang-tools-extra/clang-tidy/performance/NoexceptMoveConstructorCheck.h
  clang-tools-extra/clang-tidy/performance/NoexceptSpecialFunctionsCheck.cpp
  clang-tools-extra/clang-tidy/performance/NoexceptSpecialFunctionsCheck.h
  clang-tools-extra/clang-tidy/performance/PerformanceTidyModule.cpp
  clang-tools-extra/clang-tidy/utils/ExceptionSpecAnalyzer.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines/noexcept-special-functions.rst
  clang-tools-extra/docs/clang-tidy/checks/hicpp/noexcept-move.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/docs/clang-tidy/checks/performance/noexcept-move-constructor.rst
  
clang-tools-extra/docs/clang-tidy/checks/performance/noexcept-special-functions.rst
  
clang-tools-extra/test/clang-tidy/checkers/performance/noexcept-move-constructor-fix.cpp
  
clang-tools-extra/test/clang-tidy/checkers/performance/noexcept-move-constructor.cpp
  
clang-tools-extra/test/clang-tidy/checkers/performance/noexcept-special-functions-fix.cpp
  
clang-tools-extra/test/clang-tidy/checkers/performance/noexcept-special-functions.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/performance/noexcept-special-functions.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/performance/noexcept-special-functions.cpp
@@ -0,0 +1,601 @@
+// RUN: %check_clang_tidy %s performance-noexcept-special-functions %t -- -- -fexceptions
+
+struct Empty
+{};
+
+struct IntWrapper {
+  int value;
+};
+
+template 
+struct FalseT {
+  static constexpr bool value = false;
+};
+
+template 
+struct TrueT {
+  static constexpr bool value = true;
+};
+
+struct ThrowOnAnything {
+  ThrowOnAnything() noexcept(false);
+  ThrowOnAnything(ThrowOnAnything&&) noexcept(false);
+  ThrowOnAnything& operator=(ThrowOnAnything &&) noexcept(false);
+  ~ThrowOnAnything() noexcept(false);
+};
+
+class A {
+  A();
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: default constructor should be marked noexcept [performance-noexcept-special-functions]
+  // CHECK-FIXES: A() noexcept ;
+  A(A &&);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: move constructor should be marked noexcept [performance-noexcept-special-functions]
+  // CHECK-FIXES: A(A &&) noexcept ;
+  A &operator=(A &&);
+  // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: move assignment operator should be marked noexcept [performance-noexcept-special-functions]
+  // CHECK-FIXES: A &operator=(A &&) noexcept ;
+  void swap(A &);
+  // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: swap function should be marked noexcept [performance-noexcept-special-functions]
+  // CHECK-FIXES: void swap(A &) noexcept ;
+};
+
+void swap(A &, A &);
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: swap function should be marked noexcept [performance-noexcept-special-functions]
+// CHECK-FIXES: void swap(A &, A &) noexcept ;
+
+struct B {
+  static constexpr bool kFalse = false;
+  B() noexcept(kFalse);
+  // CHECK-MESSAGES: :[[@LINE-1]]:16: warning: noexcept specifier on the default constructor evaluates to 'false' [performance-noexcept-special-functions]
+  B(B &&) noexcept(kFalse);
+  // CHECK-MESSAGES: :[[@LINE-1]]:20: warning: noexcept specifier on the move constructor evaluates to 'false' [performance-noexcept-special-functions]
+  B &operator=(B &&) noexcept(kFalse);
+  // CHECK-MESSAGES: :[[@LINE-1]]:31: warning: noexcept specifier on the move assignment operator evaluates to 'false' [performance-noexcept-special-functions]
+  ~B() noexcept(kFalse);
+  // CHECK-MESSAGES: :[[@LINE-1]]:17: warning: noexcept specifier on the destructor evaluates to 'false' [performance-noexcept-special-functions]
+  void swap(B &) noexcept(kFalse);
+  // CHECK-MESSAGES: :[[@LINE-1]]:27: warning: noexcept specifier on the swap function evaluates to 'false' [performance-noexcept-special-functions]
+};
+
+void swap(B &, B &);
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: swap function should be marked noexcept [performance-noexcept-special-functions]
+// CHECK

[PATCH] D148696: [clang][Sema][NFC] Sprinkle some const around in Sema

2023-04-19 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder updated this revision to Diff 514878.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148696/new/

https://reviews.llvm.org/D148696

Files:
  clang/include/clang/AST/DeclarationName.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/DeclarationName.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaLookup.cpp

Index: clang/lib/Sema/SemaLookup.cpp
===
--- clang/lib/Sema/SemaLookup.cpp
+++ clang/lib/Sema/SemaLookup.cpp
@@ -199,7 +199,7 @@
 const_iterator end() const { return list.end(); }
 
 llvm::iterator_range
-getNamespacesFor(DeclContext *DC) const {
+getNamespacesFor(const DeclContext *DC) const {
   return llvm::make_range(std::equal_range(begin(), end(),
DC->getPrimaryContext(),
UnqualUsingEntry::Comparator()));
@@ -351,12 +351,12 @@
 
 /// Get a representative context for a declaration such that two declarations
 /// will have the same context if they were found within the same scope.
-static DeclContext *getContextForScopeMatching(Decl *D) {
+static const DeclContext *getContextForScopeMatching(const Decl *D) {
   // For function-local declarations, use that function as the context. This
   // doesn't account for scopes within the function; the caller must deal with
   // those.
-  DeclContext *DC = D->getLexicalDeclContext();
-  if (DC->isFunctionOrMethod())
+  if (const DeclContext *DC = D->getLexicalDeclContext();
+  DC->isFunctionOrMethod())
 return DC;
 
   // Otherwise, look at the semantic context of the declaration. The
@@ -367,15 +367,16 @@
 /// Determine whether \p D is a better lookup result than \p Existing,
 /// given that they declare the same entity.
 static bool isPreferredLookupResult(Sema &S, Sema::LookupNameKind Kind,
-NamedDecl *D, NamedDecl *Existing) {
+const NamedDecl *D,
+const NamedDecl *Existing) {
   // When looking up redeclarations of a using declaration, prefer a using
   // shadow declaration over any other declaration of the same entity.
   if (Kind == Sema::LookupUsingDeclName && isa(D) &&
   !isa(Existing))
 return true;
 
-  auto *DUnderlying = D->getUnderlyingDecl();
-  auto *EUnderlying = Existing->getUnderlyingDecl();
+  const auto *DUnderlying = D->getUnderlyingDecl();
+  const auto *EUnderlying = Existing->getUnderlyingDecl();
 
   // If they have different underlying declarations, prefer a typedef over the
   // original type (this happens when two type declarations denote the same
@@ -397,8 +398,8 @@
   // FIXME: In the presence of ambiguous default arguments, we should keep both,
   //so we can diagnose the ambiguity if the default argument is needed.
   //See C++ [over.match.best]p3.
-  if (auto *DFD = dyn_cast(DUnderlying)) {
-auto *EFD = cast(EUnderlying);
+  if (const auto *DFD = dyn_cast(DUnderlying)) {
+const auto *EFD = cast(EUnderlying);
 unsigned DMin = DFD->getMinRequiredArguments();
 unsigned EMin = EFD->getMinRequiredArguments();
 // If D has more default arguments, it is preferred.
@@ -409,8 +410,8 @@
   }
 
   // Pick the template with more default template arguments.
-  if (auto *DTD = dyn_cast(DUnderlying)) {
-auto *ETD = cast(EUnderlying);
+  if (const auto *DTD = dyn_cast(DUnderlying)) {
+const auto *ETD = cast(EUnderlying);
 unsigned DMin = DTD->getTemplateParameters()->getMinRequiredArguments();
 unsigned EMin = ETD->getTemplateParameters()->getMinRequiredArguments();
 // If D has more default arguments, it is preferred. Note that default
@@ -433,8 +434,8 @@
 
   // VarDecl can have incomplete array types, prefer the one with more complete
   // array type.
-  if (VarDecl *DVD = dyn_cast(DUnderlying)) {
-VarDecl *EVD = cast(EUnderlying);
+  if (const auto *DVD = dyn_cast(DUnderlying)) {
+const auto *EVD = cast(EUnderlying);
 if (EVD->getType()->isIncompleteType() &&
 !DVD->getType()->isIncompleteType()) {
   // Prefer the decl with a more complete type if visible.
@@ -451,7 +452,7 @@
   }
 
   // Pick the newer declaration; it might have a more precise type.
-  for (Decl *Prev = DUnderlying->getPreviousDecl(); Prev;
+  for (const Decl *Prev = DUnderlying->getPreviousDecl(); Prev;
Prev = Prev->getPreviousDecl())
 if (Prev == EUnderlying)
   return true;
@@ -459,7 +460,7 @@
 }
 
 /// Determine whether \p D can hide a tag declaration.
-static bool canHideTag(NamedDecl *D) {
+static bool canHideTag(const NamedDecl *D) {
   // C++ [basic.scope.declarative]p4:
   //   Given a set of declarations in a single declarative region [...]
   //   exactly one declaration shall declare a class name or enumeration name
@@ -492,7 +493,7 @@
   // If there's a single decl, we need to examine it to decide what
   // kin

[PATCH] D148355: [analyzer] Fix comparison logic in ArrayBoundCheckerV2

2023-04-19 Thread Donát Nagy via Phabricator via cfe-commits
donat.nagy added a comment.

@steakhal Thanks for the background information!

I didn't know about D86874  so I indeed ended 
up with something very similar to it. I reviewed D88359 
 and I knew that it's a completely general 
solution of this issue, but I felt that it's too complicated and wanted to 
create a patch with shorter code than that.

I really like the "use zero instead of negative numbers" trick in the 
SonarSource patch; if you would upload that for a review, I'd strongly support 
merging it.

Another alternative is that I'm working on a new version of my patch, which 
would eliminate the code duplication between the underflow and overflow checks 
(by introducing a single function compareValueToThreshold that performs offset 
simplification when needed, handles the unsigned-vs-negative case, calls 
evalBinOpNN and invokes state->assume). This would be equivalent to the 
SonarSource patch (it handles unsigned-vs-negative comparison on "both sides") 
with the added independent benefit of simplifying the codebase. However, I can 
also do this code simplification as a separate patch after merging the 
SonarSource solution for the bug.

Which solution would you prefer (upstream the solution used by SonarSource + 
separate code quality improvement or the combined 
refactor-and-check-before-evalBinOpNN variant that I could implement)?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148355/new/

https://reviews.llvm.org/D148355

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148699: [clang] Mark keywords that have their own parsing rules

2023-04-19 Thread Richard Sandiford via Phabricator via cfe-commits
rsandifo-arm created this revision.
rsandifo-arm added reviewers: erichkeane, aaron.ballman.
Herald added a project: All.
rsandifo-arm requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This patch retroactively classified all existing keyword attributes
as “custom” keyword attributes, in the sense that the keywords have
their own custom parsing rules.  A follow-on patch will add an
alternative type of keyword.

No functional change intended.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D148699

Files:
  clang/include/clang/Basic/Attr.td

Index: clang/include/clang/Basic/Attr.td
===
--- clang/include/clang/Basic/Attr.td
+++ clang/include/clang/Basic/Attr.td
@@ -311,7 +311,13 @@
   string Namespace = namespace;
 }
 
-class Keyword : Spelling;
+class Keyword
+: Spelling {
+  bit HasOwnParseRules = hasOwnParseRules;
+}
+// A keyword that has its own individual parsing rules.
+class CustomKeyword : Keyword {}
+
 class Pragma : Spelling {
   string Namespace = namespace;
 }
@@ -709,13 +715,13 @@
 }
 
 def Aligned : InheritableAttr {
-  let Spellings = [GCC<"aligned">, Declspec<"align">, Keyword<"alignas">,
-   Keyword<"_Alignas">];
+  let Spellings = [GCC<"aligned">, Declspec<"align">, CustomKeyword<"alignas">,
+   CustomKeyword<"_Alignas">];
   let Args = [AlignedArgument<"Alignment", 1>];
   let Accessors = [Accessor<"isGNU", [GCC<"aligned">]>,
-   Accessor<"isC11", [Keyword<"_Alignas">]>,
-   Accessor<"isAlignas", [Keyword<"alignas">,
-  Keyword<"_Alignas">]>,
+   Accessor<"isC11", [CustomKeyword<"_Alignas">]>,
+   Accessor<"isAlignas", [CustomKeyword<"alignas">,
+  CustomKeyword<"_Alignas">]>,
Accessor<"isDeclspec",[Declspec<"align">]>];
   let Documentation = [Undocumented];
 }
@@ -756,7 +762,7 @@
 
 def AlwaysInline : DeclOrStmtAttr {
   let Spellings = [GCC<"always_inline">, CXX11<"clang", "always_inline">,
-   C2x<"clang", "always_inline">, Keyword<"__forceinline">];
+   C2x<"clang", "always_inline">, CustomKeyword<"__forceinline">];
   let Accessors = [Accessor<"isClangAlwaysInline", [CXX11<"clang", "always_inline">,
 C2x<"clang", "always_inline">]>];
   let Subjects = SubjectList<[Function, Stmt], WarnDiag,
@@ -879,7 +885,7 @@
 }
 
 def AsmLabel : InheritableAttr {
-  let Spellings = [Keyword<"asm">, Keyword<"__asm__">];
+  let Spellings = [CustomKeyword<"asm">, CustomKeyword<"__asm__">];
   let Args = [
 // Label specifies the mangled name for the decl.
 StringArgument<"Label">,
@@ -997,7 +1003,7 @@
 }
 
 def CDecl : DeclOrTypeAttr {
-  let Spellings = [GCC<"cdecl">, Keyword<"__cdecl">, Keyword<"_cdecl">];
+  let Spellings = [GCC<"cdecl">, CustomKeyword<"__cdecl">, CustomKeyword<"_cdecl">];
 //  let Subjects = [Function, ObjCMethod];
   let Documentation = [Undocumented];
 }
@@ -1122,10 +1128,10 @@
 def ConstInit : InheritableAttr {
   // This attribute does not have a C [[]] spelling because it requires the
   // CPlusPlus language option.
-  let Spellings = [Keyword<"constinit">,
+  let Spellings = [CustomKeyword<"constinit">,
Clang<"require_constant_initialization", 0>];
   let Subjects = SubjectList<[GlobalVar], ErrorDiag>;
-  let Accessors = [Accessor<"isConstinit", [Keyword<"constinit">]>];
+  let Accessors = [Accessor<"isConstinit", [CustomKeyword<"constinit">]>];
   let Documentation = [ConstInitDocs];
   let LangOpts = [CPlusPlus];
   let SimpleHandler = 1;
@@ -1276,7 +1282,7 @@
 }
 
 def C11NoReturn : InheritableAttr {
-  let Spellings = [Keyword<"_Noreturn">];
+  let Spellings = [CustomKeyword<"_Noreturn">];
   let Subjects = SubjectList<[Function], ErrorDiag>;
   let SemaHandler = 0;
   let Documentation = [C11NoReturnDocs];
@@ -1292,7 +1298,7 @@
 // Similar to CUDA, OpenCL attributes do not receive a [[]] spelling because
 // the specification does not expose them with one currently.
 def OpenCLKernel : InheritableAttr {
-  let Spellings = [Keyword<"__kernel">, Keyword<"kernel">];
+  let Spellings = [CustomKeyword<"__kernel">, CustomKeyword<"kernel">];
   let Subjects = SubjectList<[Function], ErrorDiag>;
   let Documentation = [Undocumented];
   let SimpleHandler = 1;
@@ -1316,26 +1322,28 @@
 // This attribute is both a type attribute, and a declaration attribute (for
 // parameter variables).
 def OpenCLAccess : Attr {
-  let Spellings = [Keyword<"__read_only">, Keyword<"read_only">,
-   Keyword<"__write_only">, Keyword<"write_only">,
-   Keyword<"__read_write">, Keyword<"read_write">];
+  let Spellings = [CustomKeyword<"__read_only">, CustomKeyword<"read_only">,
+   CustomKeyword<"__write_only"

[PATCH] D148700: [clang] Add support for “regular” keyword attributes

2023-04-19 Thread Richard Sandiford via Phabricator via cfe-commits
rsandifo-arm created this revision.
rsandifo-arm added reviewers: erichkeane, aaron.ballman.
Herald added subscribers: kristof.beyls, dschuff.
Herald added a project: All.
rsandifo-arm requested review of this revision.
Herald added subscribers: cfe-commits, aheejin.
Herald added projects: clang, clang-tools-extra.

Platform-specific language extensions often want to provide a way of
indicating that certain functions should be called in a different way,
compiled in a different way, or otherwise treated differently from a
“normal” function.  Honoring these indications is often required for
correctness, rather being than an optimization/QoI thing.

If a function declaration has a property P that matters for correctness,
it will be ODR-incompatible with a function that does not have property P.
If a function type has a property P that affects the calling convention,
it will not be two-way compatible with a function type that does not
have property P.  These properties therefore affect language semantics.
That in turn means that they cannot be treated as standard [[]]
attributes.

Until now, many of these properties have been specified using GNU-style
attributes instead.  GNU attributes have traditionally been more lax
than standard attributes, with many of them having semantic meaning.
Examples include calling conventions and the vector_size attribute.

However, there is a big drawback to using GNU attributes for semantic
information: compilers that don't understand the attributes will
(by default) emit a warning rather than an error.  They will go on to
compile the code as though the attributes weren't present, which will
inevitably lead to wrong code in most cases.  For users who live
dangerously and disable the warning, this wrong code could even be
generated silently.

A more robust approach would be to specify the properties using
keywords, which older compilers would then reject.  Some vendor-specific
extensions have already taken this approach.  But traditionally, each
such keyword has been treated as a language extension in its own right.
This has three major drawbacks:

(1) The parsing rules need to be kept up-to-date as the language evolves.

(2) There are often corner cases that similar extensions handle differently.

(3) Each extension requires more custom code than a standard attribute.

The underlying problem for all three is that, unlike for true attributes,
there is no established template that extensions can reuse.  The purpose
of this patch series is to try to provide such a template.

One option would have been to pick an existing keyword and do whatever
that keyword does.  The problem with that is that most keywords only
apply to specific kinds of types, kinds of decls, etc., and so the
parsing rules are (for good reason) not generally applicable to all
types and decls.

Really, the “only” thing wrong with using standard attributes is that
standard attributes cannot affect semantics.  In all other respects
they provide exactly what we need: a well-defined grammar that evolves
with the language, clear rules about what an attribute appertains to,
and so on.

This series therefore adds keyword “attributes” that can appear
exactly where a standard attribute can appear and that appertain
to exactly what a standard attribute would appertain to.  The link is
mechanical and no opt-outs or variations are allowed.  This should
make the keywords predictable for programmers who are already
familiar with standard attributes.

This does mean that these keywords will be accepted for parsing purposes
in many more places than necessary.  Inappropriate uses will then be
diagnosed during semantic analysis.  However, the compiler would need
to reject the keywords in those positions whatever happens, and treating
them as ostensible attributes shouldn't be any worse than the alternative.
In some cases it might even be better.  For example, SME's
__arm_streaming attribute would make conceptual sense as a statement
attribute, so someone who takes a “try-it-and-see” approach might write:

  __arm_streaming { …block-of-code…; }

In fact, we did consider supporting this originally.  The reason for
rejecting it was that it was too difficult to implement, rather than
because it didn't make conceptual sense.

One slight disadvantage of the keyword-based approach is that it isn't
possible to use #pragma clang attribute with the keywords.  Perhaps we
could add support for that in future, if it turns out to be useful.

For want of a better term, I've called the new attributes "regular"
keyword attributes (in the sense that their parsing is regular wrt
standard attributes), as opposed to "custom" keyword attributes that
have their own parsing rules.

This patch adds the Attr.td support for regular keyword attributes.
Adding an attribute with a RegularKeyword spelling causes tablegen
to define the associated tokens and to record that attributes created
with that syntax are regular keyword attributes rather than custom
keywo

[PATCH] D148702: [clang] Add Parse and Sema support for RegularKeyword attributes

2023-04-19 Thread Richard Sandiford via Phabricator via cfe-commits
rsandifo-arm created this revision.
rsandifo-arm added reviewers: erichkeane, aaron.ballman.
Herald added subscribers: jdoerfert, kristof.beyls, dschuff.
Herald added a project: All.
rsandifo-arm requested review of this revision.
Herald added subscribers: cfe-commits, aheejin.
Herald added a project: clang.

This patch adds the Parse and Sema support for RegularKeyword attributes,
following on from a previous patch that added Attr.td support.

The patch is quite large.  However, nothing outside the tests is
specific to the first RegularKeyword attribute (__arm_streaming).
The patch should therefore be a one-off, up-front cost.  Other
attributes just need an entry in Attr.td and the usual Sema support.

The approach taken in the patch is that the keywords can be used with
any language version.  If standard attributes were added in language
version Y, the keyword rules for version Xhttps://reviews.llvm.org/D148702

Files:
  clang/examples/Attribute/Attribute.cpp
  clang/examples/CallSuperAttribute/CallSuperAttrInfo.cpp
  clang/include/clang/Basic/DiagnosticCommonKinds.td
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Parse/Parser.h
  clang/include/clang/Sema/DeclSpec.h
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Parse/ParseExprCXX.cpp
  clang/lib/Parse/ParsePragma.cpp
  clang/lib/Parse/ParseStmt.cpp
  clang/lib/Parse/ParseTentative.cpp
  clang/lib/Parse/Parser.cpp
  clang/lib/Sema/ParsedAttr.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaStmtAttr.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/Parser/c2x-attribute-keywords.c
  clang/test/Parser/c2x-attribute-keywords.m
  clang/test/Parser/cxx0x-keyword-attributes.cpp
  clang/utils/TableGen/ClangAttrEmitter.cpp

Index: clang/utils/TableGen/ClangAttrEmitter.cpp
===
--- clang/utils/TableGen/ClangAttrEmitter.cpp
+++ clang/utils/TableGen/ClangAttrEmitter.cpp
@@ -3878,7 +3878,8 @@
   OS << "bool diagAppertainsToDecl(Sema &S, const ParsedAttr &AL, ";
   OS << "const Decl *D) const override {\n";
   OS << "  S.Diag(AL.getLoc(), diag::err_attribute_invalid_on_decl)\n";
-  OS << "<< AL << D->getLocation();\n";
+  OS << "<< AL << AL.isRegularKeywordAttribute() << "
+"D->getLocation();\n";
   OS << "  return false;\n";
   OS << "}\n\n";
 }
@@ -3907,7 +3908,7 @@
 OS << (Warn ? "warn_attribute_wrong_decl_type_str"
 : "err_attribute_wrong_decl_type_str");
 OS << ")\n";
-OS << "  << Attr << ";
+OS << "  << Attr << Attr.isRegularKeywordAttribute() << ";
 OS << CalculateDiagnostic(*SubjectObj) << ";\n";
 OS << "return false;\n";
 OS << "  }\n";
@@ -3922,7 +3923,8 @@
   OS << "bool diagAppertainsToStmt(Sema &S, const ParsedAttr &AL, ";
   OS << "const Stmt *St) const override {\n";
   OS << "  S.Diag(AL.getLoc(), diag::err_decl_attribute_invalid_on_stmt)\n";
-  OS << "<< AL << St->getBeginLoc();\n";
+  OS << "<< AL << AL.isRegularKeywordAttribute() << "
+"St->getBeginLoc();\n";
   OS << "  return false;\n";
   OS << "}\n\n";
 }
@@ -3941,7 +3943,7 @@
 OS << (Warn ? "warn_attribute_wrong_decl_type_str"
 : "err_attribute_wrong_decl_type_str");
 OS << ")\n";
-OS << "  << Attr << ";
+OS << "  << Attr << Attr.isRegularKeywordAttribute() << ";
 OS << CalculateDiagnostic(*SubjectObj) << ";\n";
 OS << "return false;\n";
 OS << "  }\n";
@@ -4012,7 +4014,8 @@
 for (const std::string &A : DeclAttrs) {
   OS << "if (const auto *A = D->getAttr<" << A << ">()) {\n";
   OS << "  S.Diag(AL.getLoc(), diag::err_attributes_are_not_compatible)"
- << " << AL << A;\n";
+ << " << AL << A << (AL.isRegularKeywordAttribute() ||"
+ << " A->isRegularKeywordAttribute());\n";
   OS << "  S.Diag(A->getLocation(), diag::note_conflicting_attribute);";
   OS << "  \nreturn false;\n";
   OS << "}\n";
@@ -4033,7 +4036,8 @@
 << ">()) {\n";
 MergeDeclOS << "  S.Diag(First->getLocation(), "
 << "diag::err_attributes_are_not_compatible) << First << "
-<< "Second;\n";
+<< "Second << (First->isRegularKeywordAttribute() || "
+<< "Second->isRegularKeywordAttribute());\n";
 MergeDeclOS << "  S.Diag(Second->getLocation(), "
 << "diag::note_conflicting_attribute);\n";
 MergeDeclOS << "  return false;\n";
@@ -4073,7 +4077,8 @@
 MergeStmtOS << "  if (Iter != C.end()) {\n";
 MergeStmtOS << "S.Diag((*Iter)->getLocation(), "
 << "diag::err_attributes_are_not_compatible) << *Iter << "
-

[PATCH] D148697: [clang-tidy] Handle more cases of functions which should always be noexcept

2023-04-19 Thread Piotr Zegar via Phabricator via cfe-commits
PiotrZSL added a comment.

Few issues, first we should have single check for a single cppcoreguidelines 
rule.
And due to that I'm not fan of merging these things, because for example If I 
would enable this check in my project I woudn't like to enforce noexcept 
default constructor or destructor. Simply there are other checks for 
destructors .

This is why better would be to rename this check into 
performance-noexcept-move-special-functions, and add other checks for swap, 
hash, default constructor.
Where one for default constructor could be cpp-core-guidelines only check, and 
swap, hash could have some performance code.
For example in libcxx if hash function is noexcept, then hash value is not 
cached in container, but when is not noexcept then it's cached. But thats only 
libcxx.
Also things like compare operators for me should be noexcept...

If you want to keep single check, I'm fine with it, but consider adding option 
to disable some parts of it (mainly default constructors), and consider 
including (not necessary in this patch, all compare operators).

Give it a thing...




Comment at: clang-tools-extra/docs/ReleaseNotes.rst:347
 
+- Improved :doc:`performance-noexcept-special-functions
+  ` to also handle

Add release notes info about check rename, best as separate entry.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines/noexcept-special-functions.rst:10
+`performance-noexcept-special-functions 
<../performance/noexcept-special-functions.html>`_
+for more information.

Add link to implemented cpp core guidelines rules.
Add reference 
C.66: Make move operations noexcept
C.83: For value-like types, consider providing a noexcept swap function.
Same goes to operator == (C.86 rule)
And hash C.89 rule




Comment at: clang-tools-extra/docs/clang-tidy/checks/list.rst:195
`cppcoreguidelines-no-malloc `_,
+   `cppcoreguidelines-noexcept-special-functions 
`_, "Yes"
`cppcoreguidelines-owning-memory `_,

This list os for checks, 
Add alias under .. csv-table:: Aliases..



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/performance/noexcept-special-functions.rst:7
 
-The check flags user-defined move constructors and assignment operators not
+The check flags user-defined default constructors, move constructors,
+assignment operators, destructors and swap functions not

user defined default constructor does not need to be noexcept.
There is rule `C.44: Prefer default constructors to be simple and non-throwing` 
but that.s just a guideline.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/performance/noexcept-special-functions.rst:8
+The check flags user-defined default constructors, move constructors,
+assignment operators, destructors and swap functions not
 marked with ``noexcept`` or marked with ``noexcept(expr)`` where ``expr``

add entry here why destructors and swap functions should be also noexcept.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148697/new/

https://reviews.llvm.org/D148697

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148699: [clang] Mark keywords that have their own parsing rules

2023-04-19 Thread Richard Sandiford via Phabricator via cfe-commits
rsandifo-arm added a comment.

See https://reviews.llvm.org/D139028 for previous discussion on this topic.  
https://reviews.llvm.org/D148700 contains the Attr.td support (and the main 
rationale) while https://reviews.llvm.org/D148702 contains the main Parse & 
Sema support.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148699/new/

https://reviews.llvm.org/D148699

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D147920: [clang] Add test for CWG399

2023-04-19 Thread Vlad Serebrennikov via Phabricator via cfe-commits
Endill added a comment.

@aaron.ballman ping


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147920/new/

https://reviews.llvm.org/D147920

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148467: [clang-format] Add a new AfterCSharpProperty to BraceWrapping

2023-04-19 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added a comment.

There is more to this than meets the eye.. what we have so far, from existing 
`AfterFunction` use and the propsed here `AfterCSharpProperty` is...

  public Foo
  {<--- controlled by **AfterFunction **(rightly or 
wrongly)
   get {   <--- proposing to controlled by 
**AfterCSharpProperty**
  return;
   }
   set {
  val= value;
   }
  }

But for trivial Properties, these are automatically assumed to be wanted on the 
same line.

  public Foo { set; get}

Trivial Properties are defined as:

   all ordering variants  (public/internal/private)
  set;get;
  public set;get
  public init;get
  get;set

My problem is AfterFunction ONLY kicks in if this isn't a TrivialProperty.. We 
can't currently force TrivialProperties to be handled differently.

AfterFunction = true we get

  public Foo { set; get}  
  
  // we can't get to
  public Foo { 
set; get
  }

Handling of Trivial Properties I feel there should be an 
"**AllowCSharpPropertiesOnASingleLine**" to match other options, otherwise it 
should follow AfterFunction  (**AllowCSharpPropertiesOnASingleLine **default 
would need to be **true **to match current behaviour)

**AllowCSharpPropertiesOnASingleLine **=true, **AfterFunction **= true/false

  public Foo {  set; get }

**AllowCSharpPropertiesOnASingleLine **= false, **AfterFunction **= true

  public Foo { 
   set; get
  }

So then how do we handle

  set;get

vs

  set;
  get;

Should **AfterCSharpProperty **be use in this case? or do we introduce  
"**BreakBetweenCSharpProperties  **"  (default false)

I know it seems strange to add 3 options to handle this, but I think it would 
give people the best of both worlds

you can have the following in the same file (which is actually quite common)

**BreakBetweenCSharpProperties   **= false
**AllowCSharpPropertiesOnASingleLine  **= true
**AfterFunction  **= true
**AfterCSharpProperty **= true

  public Foo
  {
   get 
   {   
return value;
   }
   set {
value = 123;
   }
  }
  
  public Bar
  {
   get; set;
  }

If we use**AfterCSharpProperty  ** to control **BreakBetweenCSharpProperties  
**then I think we have to have the following and we can't control Bar how we 
might want

  public Foo
  {
   get 
   {   
return value;
   }
   set {
value = 123;
   }
  }
  
  public Bar
  {
   get; 
   set;
  }

From what I can tell...Microsoft .NET Framework seems to be

**BreakBetweenCSharpProperties   **= true
**AllowCSharpPropertiesOnASingleLine  **= false
**AfterFunction  **= true
**AfterCSharpProperty **= true

https://github.com/microsoft/referencesource/blob/5697c29004a34d80acdaf5742d7e699022c64ecd/mscorlib/system/iappdomainsetup.cs

https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/using-properties

It would seem they don't seem to put Trivial Properties/AutoProperties on the 
same line


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148467/new/

https://reviews.llvm.org/D148467

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D147044: [clangd] Implement cross reference request for #include lines.

2023-04-19 Thread Viktoriia Bakalova via Phabricator via cfe-commits
VitaNuo updated this revision to Diff 514901.
VitaNuo added a comment.

Extract a test for th firstMatchedProvider method.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147044/new/

https://reviews.llvm.org/D147044

Files:
  clang-tools-extra/clangd/Hover.cpp
  clang-tools-extra/clangd/IncludeCleaner.cpp
  clang-tools-extra/clangd/IncludeCleaner.h
  clang-tools-extra/clangd/XRefs.cpp
  clang-tools-extra/clangd/unittests/HoverTests.cpp
  clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
  clang-tools-extra/clangd/unittests/XRefsTests.cpp

Index: clang-tools-extra/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -43,6 +43,10 @@
 using ::testing::UnorderedElementsAreArray;
 using ::testing::UnorderedPointwise;
 
+std::string guard(llvm::StringRef Code) {
+  return "#pragma once\n" + Code.str();
+}
+
 MATCHER_P2(FileRange, File, Range, "") {
   return Location{URIForFile::canonicalize(File, testRoot()), Range} == arg;
 }
@@ -2293,6 +2297,50 @@
 checkFindRefs(Test);
 }
 
+TEST(FindReferences, UsedSymbolsFromInclude) {
+  const char *Tests[] = {
+  R"cpp([[#include ^"bar.h"]]
+#include 
+int fstBar = [[bar1]]();
+int sndBar = [[bar2]]();
+[[Bar]] bar;
+int macroBar = [[BAR]];
+std::vector vec;
+  )cpp",
+
+  R"cpp([[#in^clude ]]
+std::[[vector]] vec;
+  )cpp"};
+  for (const char *Test : Tests) {
+Annotations T(Test);
+auto TU = TestTU::withCode(T.code());
+TU.ExtraArgs.push_back("-std=c++20");
+TU.AdditionalFiles["bar.h"] = guard(R"cpp(
+  #define BAR 5
+  int bar1();
+  int bar2();
+  class Bar {};
+)cpp");
+TU.AdditionalFiles["system/vector"] = guard(R"cpp(
+  namespace std {
+template
+class vector{};
+  }
+)cpp");
+TU.ExtraArgs.push_back("-isystem" + testPath("system"));
+
+auto AST = TU.build();
+std::vector> ExpectedLocations;
+for (const auto &R : T.ranges())
+  ExpectedLocations.push_back(AllOf(rangeIs(R), attrsAre(0u)));
+for (const auto &P : T.points()) 
+  EXPECT_THAT(findReferences(AST, P, 0).References,
+  UnorderedElementsAreArray(ExpectedLocations))
+  << "Failed for Refs at " << P << "\n"
+  << Test;
+  }
+}
+
 TEST(FindReferences, NeedsIndexForSymbols) {
   const char *Header = "int foo();";
   Annotations Main("int main() { [[f^oo]](); }");
Index: clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
===
--- clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
+++ clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp
@@ -29,6 +29,7 @@
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -384,6 +385,43 @@
   EXPECT_THAT(Findings.UnusedIncludes, IsEmpty());
 }
 
+TEST(IncludeCleaner, FirstMatchedProvider) {
+  struct {
+const char *Code;
+const std::vector Providers;
+const std::optional ExpectedProvider;
+  } Cases[] = {
+  {R"cpp(
+#include "bar.h"
+#include "foo.h"
+  )cpp",
+   {include_cleaner::Header{"bar.h"}, include_cleaner::Header{"foo.h"}},
+   include_cleaner::Header{"bar.h"}},
+  {"#include \"bar.h\"",
+   {include_cleaner::Header{"bar.h"}},
+   include_cleaner::Header{"bar.h"}},
+  {"#include \"bar.h\"", {include_cleaner::Header{"foo.h"}}, std::nullopt},
+  {"#include \"bar.h\"", {}, std::nullopt}};
+  for (const auto &Case : Cases) {
+Annotations Code{Case.Code};
+SCOPED_TRACE(Code.code());
+
+TestTU TU;
+TU.Filename = "foo.cpp";
+TU.Code = Code.code();
+TU.AdditionalFiles["bar.h"] = "";
+TU.AdditionalFiles["foo.h"] = "";
+
+auto AST = TU.build();
+std::optional MatchedProvider =
+firstMatchedProvider(
+convertIncludes(AST.getSourceManager(),
+AST.getIncludeStructure().MainFileIncludes),
+Case.Providers);
+EXPECT_EQ(MatchedProvider, Case.ExpectedProvider);
+  }
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/unittests/HoverTests.cpp
===
--- clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -2999,36 +2999,7 @@
   #in^clude 
   std::vector vec;
 )cpp",
-[](HoverInfo &HI) { HI.UsedSymbolNames = {"vector"}; }},
-   {R"cpp(
-  #in^clude "public.h"
-  #include "private.h"
-  int fooVar = foo();
-)cpp",
-[](HoverInfo &HI) { HI.UsedSymbolNames = 

[PATCH] D147044: [clangd] Implement cross reference request for #include lines.

2023-04-19 Thread Viktoriia Bakalova via Phabricator via cfe-commits
VitaNuo marked an inline comment as done.
VitaNuo added inline comments.



Comment at: clang-tools-extra/clangd/IncludeCleaner.h:87
+std::optional
+firstMatchedProvider(const include_cleaner::Includes &Includes,
+ llvm::ArrayRef Providers);

kadircet wrote:
> VitaNuo wrote:
> > kadircet wrote:
> > > can you also move tests related to this functionality from HoverTests 
> > > into IncludeCleanerTests ?
> > Not really, not sure what you mean.
> > 
> > This function receives a ranked list of providers that should be a result 
> > of include_cleaner analysis.
> > 
> > If I just test the function based on a fake list of providers, the test 
> > will be trivial. The current hover test seems to provide more value than 
> > that.
> > If I just test the function based on a fake list of providers, the test 
> > will be trivial.
> 
> but that's the "unit" of logic we're trying to test, no?
Ok, I've extracted a test. Hopefully that's what you've meant.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147044/new/

https://reviews.llvm.org/D147044

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148318: [clang-tidy] Add `performance-avoid-endl` check

2023-04-19 Thread André Schackier via Phabricator via cfe-commits
AMS21 updated this revision to Diff 514908.
AMS21 added a comment.

Minor code cleanup


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148318/new/

https://reviews.llvm.org/D148318

Files:
  clang-tools-extra/clang-tidy/performance/AvoidEndlCheck.cpp
  clang-tools-extra/clang-tidy/performance/AvoidEndlCheck.h
  clang-tools-extra/clang-tidy/performance/CMakeLists.txt
  clang-tools-extra/clang-tidy/performance/PerformanceTidyModule.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/docs/clang-tidy/checks/performance/avoid-endl.rst
  clang-tools-extra/test/clang-tidy/checkers/performance/avoid-endl.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/performance/avoid-endl.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/performance/avoid-endl.cpp
@@ -0,0 +1,227 @@
+// RUN: %check_clang_tidy %s performance-avoid-endl %t
+
+namespace std {
+  template 
+  class basic_ostream {
+public:
+template 
+basic_ostream& operator<<(T);
+basic_ostream& operator<<(basic_ostream& (*)(basic_ostream&));
+  };
+
+  template 
+  class basic_iostream : public basic_ostream {};
+
+  using ostream = basic_ostream;
+  using wostream = basic_ostream;
+
+  using iostream = basic_iostream;
+  using wiostream = basic_iostream;
+
+  ostream cout;
+  wostream wcout;
+
+  ostream cerr;
+  wostream wcerr;
+
+  ostream clog;
+  wostream wclog;
+
+  template
+  basic_ostream& endl(basic_ostream&);
+} // namespace std
+
+void good() {
+  std::cout << "Hello" << '\n';
+  std::cout << "World\n";
+
+  std::wcout << "Hello" << '\n';
+  std::wcout << "World\n";
+
+  std::cerr << "Hello" << '\n';
+  std::cerr << "World\n";
+
+  std::wcerr << "Hello" << '\n';
+  std::wcerr << "World\n";
+
+  std::clog << "Hello" << '\n';
+  std::clog << "World\n";
+
+  std::wclog << "Hello" << '\n';
+  std::wclog << "World\n";
+}
+
+void bad() {
+  std::cout << "World" << std::endl;
+  // CHECK-MESSAGES: :[[@LINE-1]]:27: warning: do not use 'std::endl' with streams; use '\n' instead [performance-avoid-endl]
+  // CHECK-FIXES: std::cout << "World" << '\n';
+  std::wcout << "World" << std::endl;
+  // CHECK-MESSAGES: :[[@LINE-1]]:28: warning: do not use 'std::endl' with streams; use '\n' instead [performance-avoid-endl]
+  // CHECK-FIXES: std::wcout << "World" << '\n';
+  std::cerr << "World" << std::endl;
+  // CHECK-MESSAGES: :[[@LINE-1]]:27: warning: do not use 'std::endl' with streams; use '\n' instead [performance-avoid-endl]
+  // CHECK-FIXES: std::cerr << "World" << '\n';
+  std::wcerr << "World" << std::endl;
+  // CHECK-MESSAGES: :[[@LINE-1]]:28: warning: do not use 'std::endl' with streams; use '\n' instead [performance-avoid-endl]
+  // CHECK-FIXES: std::wcerr << "World" << '\n';
+  std::clog << "World" << std::endl;
+  // CHECK-MESSAGES: :[[@LINE-1]]:27: warning: do not use 'std::endl' with streams; use '\n' instead [performance-avoid-endl]
+  // CHECK-FIXES: std::clog << "World" << '\n';
+  std::wclog << "World" << std::endl;
+  // CHECK-MESSAGES: :[[@LINE-1]]:28: warning: do not use 'std::endl' with streams; use '\n' instead [performance-avoid-endl]
+  // CHECK-FIXES: std::wclog << "World" << '\n';
+}
+
+void bad_single_argument() {
+  std::cout << std::endl;
+  // CHECK-MESSAGES: :[[@LINE-1]]:16: warning: do not use 'std::endl' with streams; use '\n' instead [performance-avoid-endl]
+  // CHECK-FIXES: std::cout << '\n';
+  std::wcout << std::endl;
+  // CHECK-MESSAGES: :[[@LINE-1]]:17: warning: do not use 'std::endl' with streams; use '\n' instead [performance-avoid-endl]
+  // CHECK-FIXES: std::wcout << '\n';
+  std::cerr << std::endl;
+  // CHECK-MESSAGES: :[[@LINE-1]]:16: warning: do not use 'std::endl' with streams; use '\n' instead [performance-avoid-endl]
+  // CHECK-FIXES: std::cerr << '\n';
+  std::wcerr << std::endl;
+  // CHECK-MESSAGES: :[[@LINE-1]]:17: warning: do not use 'std::endl' with streams; use '\n' instead [performance-avoid-endl]
+  // CHECK-FIXES: std::wcerr << '\n';
+  std::clog << std::endl;
+  // CHECK-MESSAGES: :[[@LINE-1]]:16: warning: do not use 'std::endl' with streams; use '\n' instead [performance-avoid-endl]
+  // CHECK-FIXES: std::clog << '\n';
+  std::wclog << std::endl;
+  // CHECK-MESSAGES: :[[@LINE-1]]:17: warning: do not use 'std::endl' with streams; use '\n' instead [performance-avoid-endl]
+  // CHECK-FIXES: std::wclog << '\n';
+}
+
+void bad_multiple() {
+  std::cout << "Hello" << std::endl << "World" << std::endl;
+  // CHECK-MESSAGES: :[[@LINE-1]]:27: warning: do not use 'std::endl' with streams; use '\n' instead [performance-avoid-endl]
+  // CHECK-MESSAGES: :[[@LINE-2]]:51: warning: do not use 'std::endl' with streams; use '\n' instead [performance-avoid-endl]
+  // CHECK-FIXES: std::cout << "Hello" << '\n' << "World" << '\n';
+  std::wcout << "Hello" << std::endl << "World" << std::endl;
+  // 

[PATCH] D142688: [Clang][Driver] Handle LoongArch multiarch tuples

2023-04-19 Thread Lu Weining via Phabricator via cfe-commits
SixWeining added inline comments.



Comment at: clang/test/Driver/linux-header-search.cpp:247
 //
+// Check header search on Debian loong64
+// RUN: %clang -### %s -fsyntax-only 2>&1 \

Better to use “loongarch64” when talking about debian? Refer 
https://wiki.debian.org/Multiarch/Tuples



Comment at: clang/test/Driver/linux-header-search.cpp:252
+// RUN: --gcc-toolchain="" \
+// RUN:   | FileCheck --check-prefix=CHECK-LOONG64-GNU %s
+//

Use LA64 instead of LOONG64?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D142688/new/

https://reviews.llvm.org/D142688

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D147989: [clang] Fix Attribute Placement

2023-04-19 Thread Priyanshi Agarwal via Phabricator via cfe-commits
ipriyanshi1708 updated this revision to Diff 514909.
ipriyanshi1708 added a comment.

Updated the test file


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147989/new/

https://reviews.llvm.org/D147989

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaDecl.cpp
  clang/test/Sema/attr-declspec-ignored.c
  clang/test/SemaCXX/attr-declspec-ignored.cpp

Index: clang/test/SemaCXX/attr-declspec-ignored.cpp
===
--- clang/test/SemaCXX/attr-declspec-ignored.cpp
+++ clang/test/SemaCXX/attr-declspec-ignored.cpp
@@ -9,6 +9,8 @@
   // expected-warning{{attribute 'aligned' is ignored, place it after "union" to apply attribute to type declaration}}
   __attribute__((visibility("hidden")))  __attribute__((aligned)) enum D {D}; // expected-warning{{attribute 'visibility' is ignored, place it after "enum" to apply attribute to type declaration}} \
   // expected-warning{{attribute 'aligned' is ignored, place it after "enum" to apply attribute to type declaration}}
+  __attribute__((visibility("hidden")))  __attribute__((aligned)) enum class EC {}; // expected-warning{{attribute 'visibility' is ignored, place it after "enum class" to apply attribute to type declaration}} \
+  // expected-warning{{attribute 'aligned' is ignored, place it after "enum class" to apply attribute to type declaration}}
 
   // Test that we get the same warnings for type declarations nested in a record.
   struct X {
@@ -20,7 +22,9 @@
 // expected-warning{{attribute 'aligned' is ignored, place it after "union" to apply attribute to type declaration}}
 __attribute__((visibility("hidden")))  __attribute__((aligned)) enum D {D}; // expected-warning{{attribute 'visibility' is ignored, place it after "enum" to apply attribute to type declaration}} \
 // expected-warning{{attribute 'aligned' is ignored, place it after "enum" to apply attribute to type declaration}}
-
+__attribute__((visibility("hidden")))  __attribute__((aligned)) enum class EC {}; // expected-warning{{attribute 'visibility' is ignored, place it after "enum class" to apply attribute to type declaration}} \
+// expected-warning{{attribute 'aligned' is ignored, place it after "enum class" to apply attribute to type declaration}}
+  
 // Also test [[]] attribute syntax. (On a non-nested declaration, these
 // generate a hard "misplaced attributes" error, which we test for
 // elsewhere.)
@@ -32,6 +36,8 @@
 // expected-warning{{attribute 'aligned' is ignored, place it after "union" to apply attribute to type declaration}}
 [[gnu::visibility("hidden")]]  [[gnu::aligned]] enum H {H}; // expected-warning{{attribute 'visibility' is ignored, place it after "enum" to apply attribute to type declaration}} \
 // expected-warning{{attribute 'aligned' is ignored, place it after "enum" to apply attribute to type declaration}}
+[[gnu::visibility("hidden")]]  [[gnu::aligned]] enum class I {}; // expected-warning{{attribute 'visibility' is ignored, place it after "enum class" to apply attribute to type declaration}} \
+// expected-warning{{attribute 'aligned' is ignored, place it after "enum class" to apply attribute to type declaration}}
   };
 }
 
@@ -40,16 +46,19 @@
   __attribute__((visibility("hidden")))  __attribute__((aligned)) struct B {} b;
   __attribute__((visibility("hidden")))  __attribute__((aligned)) union C {} c;
   __attribute__((visibility("hidden")))  __attribute__((aligned)) enum D {D} d;
+  __attribute__((visibility("hidden")))  __attribute__((aligned)) enum class EC {} ec;
 
   struct X {
 __attribute__((visibility("hidden")))  __attribute__((aligned)) class A {} a;
 __attribute__((visibility("hidden")))  __attribute__((aligned)) struct B {} b;
 __attribute__((visibility("hidden")))  __attribute__((aligned)) union C {} c;
 __attribute__((visibility("hidden")))  __attribute__((aligned)) enum D {D} d;
+__attribute__((visibility("hidden")))  __attribute__((aligned)) enum class EC {} ec;
 
 [[gnu::visibility("hidden")]]  [[gnu::aligned]] class E {} e;
 [[gnu::visibility("hidden")]]  [[gnu::aligned]] struct F {} f;
 [[gnu::visibility("hidden")]]  [[gnu::aligned]] union G {} g;
 [[gnu::visibility("hidden")]]  [[gnu::aligned]] enum H {H} h;
+[[gnu::visibility("hidden")]]  [[gnu::aligned]] enum class I {} i;
   };
 }
Index: clang/test/Sema/attr-declspec-ignored.c
===
--- clang/test/Sema/attr-declspec-ignored.c
+++ clang/test/Sema/attr-declspec-ignored.c
@@ -19,4 +19,4 @@
 
 __attribute__((visibility("hidden")))  __attribute__((aligned)) struct D {} d;
 __attribute__((visibility("hidden")))  __attribute__((aligned)) union E {} e;
-__attribute__((visibility("hidden")))  __attribute__((aligned)) enum F {F} f;
+__attribute__((visibility("hidden")))  __attribute__((aligned)) en

[PATCH] D147044: [clangd] Implement cross reference request for #include lines.

2023-04-19 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet accepted this revision.
kadircet added a comment.
This revision is now accepted and ready to land.

thanks!




Comment at: clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp:398
+  )cpp",
+   {include_cleaner::Header{"bar.h"}, include_cleaner::Header{"foo.h"}},
+   include_cleaner::Header{"bar.h"}},

can you add a similar test case in which `foo.h` comes before `bar.h` ?



Comment at: clang-tools-extra/clangd/unittests/IncludeCleanerTests.cpp:410
+TestTU TU;
+TU.Filename = "foo.cpp";
+TU.Code = Code.code();

nit: no need for the filename


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147044/new/

https://reviews.llvm.org/D147044

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D147989: [clang] Fix Attribute Placement

2023-04-19 Thread Priyanshi Agarwal via Phabricator via cfe-commits
ipriyanshi1708 updated this revision to Diff 514911.
ipriyanshi1708 added a comment.

Removed spurious whitespace changes


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147989/new/

https://reviews.llvm.org/D147989

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaDecl.cpp
  clang/test/Sema/attr-declspec-ignored.c
  clang/test/SemaCXX/attr-declspec-ignored.cpp

Index: clang/test/SemaCXX/attr-declspec-ignored.cpp
===
--- clang/test/SemaCXX/attr-declspec-ignored.cpp
+++ clang/test/SemaCXX/attr-declspec-ignored.cpp
@@ -9,6 +9,8 @@
   // expected-warning{{attribute 'aligned' is ignored, place it after "union" to apply attribute to type declaration}}
   __attribute__((visibility("hidden")))  __attribute__((aligned)) enum D {D}; // expected-warning{{attribute 'visibility' is ignored, place it after "enum" to apply attribute to type declaration}} \
   // expected-warning{{attribute 'aligned' is ignored, place it after "enum" to apply attribute to type declaration}}
+  __attribute__((visibility("hidden")))  __attribute__((aligned)) enum class EC {}; // expected-warning{{attribute 'visibility' is ignored, place it after "enum class" to apply attribute to type declaration}} \
+  // expected-warning{{attribute 'aligned' is ignored, place it after "enum class" to apply attribute to type declaration}}
 
   // Test that we get the same warnings for type declarations nested in a record.
   struct X {
@@ -20,7 +22,9 @@
 // expected-warning{{attribute 'aligned' is ignored, place it after "union" to apply attribute to type declaration}}
 __attribute__((visibility("hidden")))  __attribute__((aligned)) enum D {D}; // expected-warning{{attribute 'visibility' is ignored, place it after "enum" to apply attribute to type declaration}} \
 // expected-warning{{attribute 'aligned' is ignored, place it after "enum" to apply attribute to type declaration}}
-
+__attribute__((visibility("hidden")))  __attribute__((aligned)) enum class EC {}; // expected-warning{{attribute 'visibility' is ignored, place it after "enum class" to apply attribute to type declaration}} \
+// expected-warning{{attribute 'aligned' is ignored, place it after "enum class" to apply attribute to type declaration}}
+  
 // Also test [[]] attribute syntax. (On a non-nested declaration, these
 // generate a hard "misplaced attributes" error, which we test for
 // elsewhere.)
@@ -32,6 +36,8 @@
 // expected-warning{{attribute 'aligned' is ignored, place it after "union" to apply attribute to type declaration}}
 [[gnu::visibility("hidden")]]  [[gnu::aligned]] enum H {H}; // expected-warning{{attribute 'visibility' is ignored, place it after "enum" to apply attribute to type declaration}} \
 // expected-warning{{attribute 'aligned' is ignored, place it after "enum" to apply attribute to type declaration}}
+[[gnu::visibility("hidden")]]  [[gnu::aligned]] enum class I {}; // expected-warning{{attribute 'visibility' is ignored, place it after "enum class" to apply attribute to type declaration}} \
+// expected-warning{{attribute 'aligned' is ignored, place it after "enum class" to apply attribute to type declaration}}
   };
 }
 
@@ -40,16 +46,19 @@
   __attribute__((visibility("hidden")))  __attribute__((aligned)) struct B {} b;
   __attribute__((visibility("hidden")))  __attribute__((aligned)) union C {} c;
   __attribute__((visibility("hidden")))  __attribute__((aligned)) enum D {D} d;
+  __attribute__((visibility("hidden")))  __attribute__((aligned)) enum class EC {} ec;
 
   struct X {
 __attribute__((visibility("hidden")))  __attribute__((aligned)) class A {} a;
 __attribute__((visibility("hidden")))  __attribute__((aligned)) struct B {} b;
 __attribute__((visibility("hidden")))  __attribute__((aligned)) union C {} c;
 __attribute__((visibility("hidden")))  __attribute__((aligned)) enum D {D} d;
+__attribute__((visibility("hidden")))  __attribute__((aligned)) enum class EC {} ec;
 
 [[gnu::visibility("hidden")]]  [[gnu::aligned]] class E {} e;
 [[gnu::visibility("hidden")]]  [[gnu::aligned]] struct F {} f;
 [[gnu::visibility("hidden")]]  [[gnu::aligned]] union G {} g;
 [[gnu::visibility("hidden")]]  [[gnu::aligned]] enum H {H} h;
+[[gnu::visibility("hidden")]]  [[gnu::aligned]] enum class I {} i;
   };
 }
Index: clang/test/Sema/attr-declspec-ignored.c
===
--- clang/test/Sema/attr-declspec-ignored.c
+++ clang/test/Sema/attr-declspec-ignored.c
@@ -19,4 +19,4 @@
 
 __attribute__((visibility("hidden")))  __attribute__((aligned)) struct D {} d;
 __attribute__((visibility("hidden")))  __attribute__((aligned)) union E {} e;
-__attribute__((visibility("hidden")))  __attribute__((aligned)) enum F {F} f;
+__attribute__((visibility("hidden")))  __attribute__

[PATCH] D142688: [Clang][Driver] Handle LoongArch multiarch tuples

2023-04-19 Thread WÁNG Xuěruì via Phabricator via cfe-commits
xen0n added inline comments.



Comment at: clang/test/Driver/linux-header-search.cpp:247
 //
+// Check header search on Debian loong64
+// RUN: %clang -### %s -fsyntax-only 2>&1 \

SixWeining wrote:
> Better to use “loongarch64” when talking about debian? Refer 
> https://wiki.debian.org/Multiarch/Tuples
It's the dpkg arch identifier and actually [[ 
https://wiki.debian.org/Ports/loong64 | the port's official name ]]. I chose it 
because it's shorter. Do we still want to emphasize the target tuple instead of 
the distro identity in this case?



Comment at: clang/test/Driver/linux-header-search.cpp:252
+// RUN: --gcc-toolchain="" \
+// RUN:   | FileCheck --check-prefix=CHECK-LOONG64-GNU %s
+//

SixWeining wrote:
> Use LA64 instead of LOONG64?
Similarly I meant to refer to the Debian port name here.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D142688/new/

https://reviews.llvm.org/D142688

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148355: [analyzer] Fix comparison logic in ArrayBoundCheckerV2

2023-04-19 Thread Balázs Benics via Phabricator via cfe-commits
steakhal added a subscriber: tomasz-kaminski-sonarsource.
steakhal added a comment.

In D148355#4279866 , @donat.nagy 
wrote:

> @steakhal Thanks for the background information!
>
> I didn't know about D86874  so I indeed 
> ended up with something very similar to it. I reviewed D88359 
>  and I knew that it's a completely general 
> solution of this issue, but I felt that it's too complicated and wanted to 
> create a patch with shorter code than that.
>
> I really like the "use zero instead of negative numbers" trick in the 
> SonarSource patch; if you would upload that for a review, I'd strongly 
> support merging it.
>
> Another alternative is that I'm working on a new version of my patch, which 
> would eliminate the code duplication between the underflow and overflow 
> checks (by introducing a single function compareValueToThreshold that 
> performs offset simplification when needed, handles the unsigned-vs-negative 
> case, calls evalBinOpNN and invokes state->assume). This would be equivalent 
> to the SonarSource patch (it handles unsigned-vs-negative comparison on "both 
> sides") with the added independent benefit of simplifying the codebase. 
> However, I can also do this code simplification as a separate patch after 
> merging the SonarSource solution for the bug.
>
> Which solution would you prefer (upstream the solution used by SonarSource + 
> separate code quality improvement or the combined 
> refactor-and-check-before-evalBinOpNN variant that I could implement)?

Right now I don't have the bandwidth for upstreaming our version, and it seems 
like you already picked up the subject, so it's probably less intrusive for 
you. But I should speak for my self I know.
So, you can update this revision to our version, or modify or inspire by our 
version. Anything you want.
The only thing is, if the patch, in the end, is sufficiently similar to ours, I 
think we should add credit to the original author, who is I think 
@tomasz-kaminski-sonarsource (`Tomasz Kamiński 
`).

I can help to review and do measurements at scale but I don't think I can 
contribute in other ways.

And on the note of doing refinement followup patches. If those are NFC 
(non-function changes), then those should be separated from semantic changes 
for sure.
Pure NFC changes make validation much easier, equally so the review process. If 
not, then it's up to you how you think it's the easiest to review the patch set.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148355/new/

https://reviews.llvm.org/D148355

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D142688: [Clang][Driver] Handle LoongArch multiarch tuples

2023-04-19 Thread Lu Weining via Phabricator via cfe-commits
SixWeining accepted this revision.
SixWeining added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/test/Driver/linux-header-search.cpp:247
 //
+// Check header search on Debian loong64
+// RUN: %clang -### %s -fsyntax-only 2>&1 \

xen0n wrote:
> SixWeining wrote:
> > Better to use “loongarch64” when talking about debian? Refer 
> > https://wiki.debian.org/Multiarch/Tuples
> It's the dpkg arch identifier and actually [[ 
> https://wiki.debian.org/Ports/loong64 | the port's official name ]]. I chose 
> it because it's shorter. Do we still want to emphasize the target tuple 
> instead of the distro identity in this case?
Sorry I didn’t noticed this before. Now it LGTM. Thanks.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D142688/new/

https://reviews.llvm.org/D142688

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] bf47c1e - [dataflow] Extract arena for Value/StorageLocation out of DataflowAnalysisContext

2023-04-19 Thread Sam McCall via cfe-commits

Author: Sam McCall
Date: 2023-04-19T14:32:13+02:00
New Revision: bf47c1ed855605324efcca4af92517026c7e53e5

URL: 
https://github.com/llvm/llvm-project/commit/bf47c1ed855605324efcca4af92517026c7e53e5
DIFF: 
https://github.com/llvm/llvm-project/commit/bf47c1ed855605324efcca4af92517026c7e53e5.diff

LOG: [dataflow] Extract arena for Value/StorageLocation out of 
DataflowAnalysisContext

DataflowAnalysisContext has a few too many responsibilities, this narrows them.

It also allows the Arena to be shared with analysis steps, which need to create
Values, without exposing the whole DACtx API (flow conditions etc).
This means Environment no longer needs to proxy all these methods.
(For now it still does, because there are many callsites to update, and maybe
if we separate bool formulas from values we can avoid churning them twice)

In future, if we untangle the concepts of Values from boolean formulas/atoms,
Arena would also be responsible for creating formulas and managing atom IDs.

Differential Revision: https://reviews.llvm.org/D148554

Added: 
clang/include/clang/Analysis/FlowSensitive/Arena.h
clang/lib/Analysis/FlowSensitive/Arena.cpp
clang/unittests/Analysis/FlowSensitive/ArenaTest.cpp

Modified: 
clang/include/clang/Analysis/FlowSensitive/DataflowAnalysisContext.h
clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
clang/lib/Analysis/FlowSensitive/CMakeLists.txt
clang/lib/Analysis/FlowSensitive/DataflowAnalysisContext.cpp
clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
clang/unittests/Analysis/FlowSensitive/CMakeLists.txt
clang/unittests/Analysis/FlowSensitive/DataflowAnalysisContextTest.cpp

Removed: 




diff  --git a/clang/include/clang/Analysis/FlowSensitive/Arena.h 
b/clang/include/clang/Analysis/FlowSensitive/Arena.h
new file mode 100644
index 0..8dc51e044b14f
--- /dev/null
+++ b/clang/include/clang/Analysis/FlowSensitive/Arena.h
@@ -0,0 +1,120 @@
+//===-- Arena.h ---*- C++ 
---*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang/Analysis/FlowSensitive/StorageLocation.h"
+#include "clang/Analysis/FlowSensitive/Value.h"
+#include 
+
+namespace clang::dataflow {
+
+/// The Arena owns the objects that model data within an analysis.
+/// For example, `Value` and `StorageLocation`.
+class Arena {
+public:
+  Arena()
+  : TrueVal(create()),
+FalseVal(create()) {}
+  Arena(const Arena &) = delete;
+  Arena &operator=(const Arena &) = delete;
+
+  /// Creates a `T` (some subclass of `StorageLocation`), forwarding `args` to
+  /// the constructor, and returns a reference to it.
+  ///
+  /// The `DataflowAnalysisContext` takes ownership of the created object. The
+  /// object will be destroyed when the `DataflowAnalysisContext` is destroyed.
+  template 
+  std::enable_if_t::value, T &>
+  create(Args &&...args) {
+// Note: If allocation of individual `StorageLocation`s turns out to be
+// costly, consider creating specializations of `create` for commonly
+// used `StorageLocation` subclasses and make them use a 
`BumpPtrAllocator`.
+return *cast(
+Locs.emplace_back(std::make_unique(std::forward(args)...))
+.get());
+  }
+
+  /// Creates a `T` (some subclass of `Value`), forwarding `args` to the
+  /// constructor, and returns a reference to it.
+  ///
+  /// The `DataflowAnalysisContext` takes ownership of the created object. The
+  /// object will be destroyed when the `DataflowAnalysisContext` is destroyed.
+  template 
+  std::enable_if_t::value, T &>
+  create(Args &&...args) {
+// Note: If allocation of individual `Value`s turns out to be costly,
+// consider creating specializations of `create` for commonly used
+// `Value` subclasses and make them use a `BumpPtrAllocator`.
+return *cast(
+Vals.emplace_back(std::make_unique(std::forward(args)...))
+.get());
+  }
+
+  /// Returns a boolean value that represents the conjunction of `LHS` and
+  /// `RHS`. Subsequent calls with the same arguments, regardless of their
+  /// order, will return the same result. If the given boolean values represent
+  /// the same value, the result will be the value itself.
+  BoolValue &makeAnd(BoolValue &LHS, BoolValue &RHS);
+
+  /// Returns a boolean value that represents the disjunction of `LHS` and
+  /// `RHS`. Subsequent calls with the same arguments, regardless of their
+  /// order, will return the same result. If the given boolean values represent
+  /// the same value, the result will be the value itself.
+  BoolValue &makeOr(BoolValue &LHS, BoolValue &RHS);
+
+  /// 

[PATCH] D148554: [dataflow] Extract arena for Value/StorageLocation out of DataflowAnalysisContext

2023-04-19 Thread Sam McCall via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
sammccall marked 2 inline comments as done.
Closed by commit rGbf47c1ed8556: [dataflow] Extract arena for 
Value/StorageLocation out of… (authored by sammccall).

Changed prior to commit:
  https://reviews.llvm.org/D148554?vs=514602&id=514918#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148554/new/

https://reviews.llvm.org/D148554

Files:
  clang/include/clang/Analysis/FlowSensitive/Arena.h
  clang/include/clang/Analysis/FlowSensitive/DataflowAnalysisContext.h
  clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
  clang/lib/Analysis/FlowSensitive/Arena.cpp
  clang/lib/Analysis/FlowSensitive/CMakeLists.txt
  clang/lib/Analysis/FlowSensitive/DataflowAnalysisContext.cpp
  clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
  clang/unittests/Analysis/FlowSensitive/ArenaTest.cpp
  clang/unittests/Analysis/FlowSensitive/CMakeLists.txt
  clang/unittests/Analysis/FlowSensitive/DataflowAnalysisContextTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/DataflowAnalysisContextTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/DataflowAnalysisContextTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/DataflowAnalysisContextTest.cpp
@@ -20,150 +20,35 @@
 class DataflowAnalysisContextTest : public ::testing::Test {
 protected:
   DataflowAnalysisContextTest()
-  : Context(std::make_unique()) {}
+  : Context(std::make_unique()), A(Context.arena()) {
+  }
 
   DataflowAnalysisContext Context;
+  Arena &A;
 };
 
-TEST_F(DataflowAnalysisContextTest,
-   CreateAtomicBoolValueReturnsDistinctValues) {
-  auto &X = Context.create();
-  auto &Y = Context.create();
-  EXPECT_NE(&X, &Y);
-}
-
-TEST_F(DataflowAnalysisContextTest,
-   CreateTopBoolValueReturnsDistinctValues) {
-  auto &X = Context.create();
-  auto &Y = Context.create();
-  EXPECT_NE(&X, &Y);
-}
-
 TEST_F(DataflowAnalysisContextTest, DistinctTopsNotEquivalent) {
-  auto &X = Context.create();
-  auto &Y = Context.create();
+  auto &X = A.create();
+  auto &Y = A.create();
   EXPECT_FALSE(Context.equivalentBoolValues(X, Y));
 }
 
-TEST_F(DataflowAnalysisContextTest,
-   GetOrCreateConjunctionReturnsSameExprGivenSameArgs) {
-  auto &X = Context.create();
-  auto &XAndX = Context.getOrCreateConjunction(X, X);
-  EXPECT_EQ(&XAndX, &X);
-}
-
-TEST_F(DataflowAnalysisContextTest,
-   GetOrCreateConjunctionReturnsSameExprOnSubsequentCalls) {
-  auto &X = Context.create();
-  auto &Y = Context.create();
-  auto &XAndY1 = Context.getOrCreateConjunction(X, Y);
-  auto &XAndY2 = Context.getOrCreateConjunction(X, Y);
-  EXPECT_EQ(&XAndY1, &XAndY2);
-
-  auto &YAndX = Context.getOrCreateConjunction(Y, X);
-  EXPECT_EQ(&XAndY1, &YAndX);
-
-  auto &Z = Context.create();
-  auto &XAndZ = Context.getOrCreateConjunction(X, Z);
-  EXPECT_NE(&XAndY1, &XAndZ);
-}
-
-TEST_F(DataflowAnalysisContextTest,
-   GetOrCreateDisjunctionReturnsSameExprGivenSameArgs) {
-  auto &X = Context.create();
-  auto &XOrX = Context.getOrCreateDisjunction(X, X);
-  EXPECT_EQ(&XOrX, &X);
-}
-
-TEST_F(DataflowAnalysisContextTest,
-   GetOrCreateDisjunctionReturnsSameExprOnSubsequentCalls) {
-  auto &X = Context.create();
-  auto &Y = Context.create();
-  auto &XOrY1 = Context.getOrCreateDisjunction(X, Y);
-  auto &XOrY2 = Context.getOrCreateDisjunction(X, Y);
-  EXPECT_EQ(&XOrY1, &XOrY2);
-
-  auto &YOrX = Context.getOrCreateDisjunction(Y, X);
-  EXPECT_EQ(&XOrY1, &YOrX);
-
-  auto &Z = Context.create();
-  auto &XOrZ = Context.getOrCreateDisjunction(X, Z);
-  EXPECT_NE(&XOrY1, &XOrZ);
-}
-
-TEST_F(DataflowAnalysisContextTest,
-   GetOrCreateNegationReturnsSameExprOnSubsequentCalls) {
-  auto &X = Context.create();
-  auto &NotX1 = Context.getOrCreateNegation(X);
-  auto &NotX2 = Context.getOrCreateNegation(X);
-  EXPECT_EQ(&NotX1, &NotX2);
-
-  auto &Y = Context.create();
-  auto &NotY = Context.getOrCreateNegation(Y);
-  EXPECT_NE(&NotX1, &NotY);
-}
-
-TEST_F(DataflowAnalysisContextTest,
-   GetOrCreateImplicationReturnsTrueGivenSameArgs) {
-  auto &X = Context.create();
-  auto &XImpliesX = Context.getOrCreateImplication(X, X);
-  EXPECT_EQ(&XImpliesX, &Context.getBoolLiteralValue(true));
-}
-
-TEST_F(DataflowAnalysisContextTest,
-   GetOrCreateImplicationReturnsSameExprOnSubsequentCalls) {
-  auto &X = Context.create();
-  auto &Y = Context.create();
-  auto &XImpliesY1 = Context.getOrCreateImplication(X, Y);
-  auto &XImpliesY2 = Context.getOrCreateImplication(X, Y);
-  EXPECT_EQ(&XImpliesY1, &XImpliesY2);
-
-  auto &YImpliesX = Context.getOrCreateImplication(Y, X);
-  EXPECT_NE(&XImpliesY1, &YImpliesX);
-
-  auto &Z = Context.create();
-  auto &XImpliesZ = Context.getOrCreateImplication(X, Z);
-  EXPECT_NE(&XImpliesY1, &XImpliesZ);
-}
-
-TEST_F(DataflowAnalysisContextTest, GetOrCreateIffRet

[PATCH] D148639: [NFC][clang] Fix static analyzer concerns about AUTO_CAUSES_COPY

2023-04-19 Thread Balázs Benics via Phabricator via cfe-commits
steakhal added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/ExprEngine.cpp:1053
 
-  for (auto I : CleanedState->get()) {
+  for (const auto &I : CleanedState->get()) {
 if (SymbolRef Sym = I.second.getAsSymbol())

I think this is supposed to be just some lightweight handle: some discriminator 
and pointer under the hood. `sizeof(I)`
 is just 40 bytes. Another point is that the copy construction is not 
customized, so the `sizeof` for such objects should be a good proxy for 
estimating how costly the copy is.

For me personally, if it fits into a cacheline (on `x86_64` I think its 64 
bytes) (and ~trivially-copyable) then it should've probably taken by value.
I haven't measured this theory, so take it with a pinch of salt.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148639/new/

https://reviews.llvm.org/D148639

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D147989: [clang] Fix Attribute Placement

2023-04-19 Thread Sam Tebbs via Phabricator via cfe-commits
samtebbs added inline comments.



Comment at: clang/lib/Sema/SemaDecl.cpp:5051
+return 5;
+  else
+return 4;

Instead of returning 4 here, I think it's best to just delegate to the other 
`GetDiagnosticTypeSpecifierID` function. That way, if the IDs change for 
whatever reason they only have to updated in one place. This could be done 
cleanly by just making the call below be at the top level of the function (i.e. 
not inside an `else` block).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147989/new/

https://reviews.llvm.org/D147989

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 5f605e2 - [SanitizerBinaryMetadata] Respect no_sanitize("thread") function attribute

2023-04-19 Thread Marco Elver via cfe-commits

Author: Marco Elver
Date: 2023-04-19T14:49:56+02:00
New Revision: 5f605e254a0f81a41fd69025c572d597f3059ebc

URL: 
https://github.com/llvm/llvm-project/commit/5f605e254a0f81a41fd69025c572d597f3059ebc
DIFF: 
https://github.com/llvm/llvm-project/commit/5f605e254a0f81a41fd69025c572d597f3059ebc.diff

LOG: [SanitizerBinaryMetadata] Respect no_sanitize("thread") function attribute

To avoid false positives, respect no_sanitize("thread") when atomics
metadata is enabled.

Reviewed By: dvyukov

Differential Revision: https://reviews.llvm.org/D148694

Added: 
clang/test/CodeGen/sanitize-metadata-nosanitize.c

Modified: 
clang/lib/CodeGen/CodeGenFunction.cpp
llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CodeGenFunction.cpp 
b/clang/lib/CodeGen/CodeGenFunction.cpp
index a5cbf7223ad65..f6f92ebd85cf2 100644
--- a/clang/lib/CodeGen/CodeGenFunction.cpp
+++ b/clang/lib/CodeGen/CodeGenFunction.cpp
@@ -730,31 +730,38 @@ void CodeGenFunction::StartFunction(GlobalDecl GD, 
QualType RetTy,
 
   if (D) {
 const bool SanitizeBounds = SanOpts.hasOneOf(SanitizerKind::Bounds);
+SanitizerMask no_sanitize_mask;
 bool NoSanitizeCoverage = false;
 
 for (auto *Attr : D->specific_attrs()) {
-  // Apply the no_sanitize* attributes to SanOpts.
-  SanitizerMask mask = Attr->getMask();
-  SanOpts.Mask &= ~mask;
-  if (mask & SanitizerKind::Address)
-SanOpts.set(SanitizerKind::KernelAddress, false);
-  if (mask & SanitizerKind::KernelAddress)
-SanOpts.set(SanitizerKind::Address, false);
-  if (mask & SanitizerKind::HWAddress)
-SanOpts.set(SanitizerKind::KernelHWAddress, false);
-  if (mask & SanitizerKind::KernelHWAddress)
-SanOpts.set(SanitizerKind::HWAddress, false);
-
+  no_sanitize_mask |= Attr->getMask();
   // SanitizeCoverage is not handled by SanOpts.
   if (Attr->hasCoverage())
 NoSanitizeCoverage = true;
 }
 
+// Apply the no_sanitize* attributes to SanOpts.
+SanOpts.Mask &= ~no_sanitize_mask;
+if (no_sanitize_mask & SanitizerKind::Address)
+  SanOpts.set(SanitizerKind::KernelAddress, false);
+if (no_sanitize_mask & SanitizerKind::KernelAddress)
+  SanOpts.set(SanitizerKind::Address, false);
+if (no_sanitize_mask & SanitizerKind::HWAddress)
+  SanOpts.set(SanitizerKind::KernelHWAddress, false);
+if (no_sanitize_mask & SanitizerKind::KernelHWAddress)
+  SanOpts.set(SanitizerKind::HWAddress, false);
+
 if (SanitizeBounds && !SanOpts.hasOneOf(SanitizerKind::Bounds))
   Fn->addFnAttr(llvm::Attribute::NoSanitizeBounds);
 
 if (NoSanitizeCoverage && CGM.getCodeGenOpts().hasSanitizeCoverage())
   Fn->addFnAttr(llvm::Attribute::NoSanitizeCoverage);
+
+// Some passes need the non-negated no_sanitize attribute. Pass them on.
+if (CGM.getCodeGenOpts().hasSanitizeBinaryMetadata()) {
+  if (no_sanitize_mask & SanitizerKind::Thread)
+Fn->addFnAttr("no_sanitize_thread");
+}
   }
 
   if (ShouldSkipSanitizerInstrumentation()) {

diff  --git a/clang/test/CodeGen/sanitize-metadata-nosanitize.c 
b/clang/test/CodeGen/sanitize-metadata-nosanitize.c
new file mode 100644
index 0..488714fe6078e
--- /dev/null
+++ b/clang/test/CodeGen/sanitize-metadata-nosanitize.c
@@ -0,0 +1,111 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py 
UTC_ARGS: --check-attributes --check-globals --version 2
+// RUN: %clang_cc1 -O -fexperimental-sanitize-metadata=covered 
-fexperimental-sanitize-metadata=atomics -fexperimental-sanitize-metadata=uar 
-triple x86_64-gnu-linux -x c -S -emit-llvm %s -o - | FileCheck %s 
--check-prefixes=CHECK
+
+//.
+// CHECK: @__start_sanmd_covered = extern_weak hidden global ptr
+// CHECK: @__stop_sanmd_covered = extern_weak hidden global ptr
+// CHECK: @__start_sanmd_atomics = extern_weak hidden global ptr
+// CHECK: @__stop_sanmd_atomics = extern_weak hidden global ptr
+// CHECK: @llvm.used = appending global [4 x ptr] [ptr 
@__sanitizer_metadata_covered.module_ctor, ptr 
@__sanitizer_metadata_covered.module_dtor, ptr 
@__sanitizer_metadata_atomics.module_ctor, ptr 
@__sanitizer_metadata_atomics.module_dtor], section "llvm.metadata"
+// CHECK: @llvm.global_ctors = appending global [2 x { i32, ptr, ptr }] [{ 
i32, ptr, ptr } { i32 2, ptr @__sanitizer_metadata_covered.module_ctor, ptr 
@__sanitizer_metadata_covered.module_ctor }, { i32, ptr, ptr } { i32 2, ptr 
@__sanitizer_metadata_atomics.module_ctor, ptr 
@__sanitizer_metadata_atomics.module_ctor }]
+// CHECK: @llvm.global_dtors = appending global [2 x { i32, ptr, ptr }] [{ 
i32, ptr, ptr } { i32 2, ptr @__sanitizer_metadata_covered.module_dtor, ptr 
@__sanitizer_metadata_covered.module_dtor }, { i32, ptr, ptr } { i32 2, ptr 
@__sanitizer_metadata_atomics.module_dtor, ptr 
@__sanitizer_metadata_atomics.module_dtor }]

[PATCH] D148694: [SanitizerBinaryMetadata] Respect no_sanitize("thread") function attribute

2023-04-19 Thread Marco Elver via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG5f605e254a0f: [SanitizerBinaryMetadata] Respect 
no_sanitize("thread") function attribute (authored by melver).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148694/new/

https://reviews.llvm.org/D148694

Files:
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/test/CodeGen/sanitize-metadata-nosanitize.c
  llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp

Index: llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp
===
--- llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp
+++ llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp
@@ -90,6 +90,11 @@
 "sanitizer-metadata-weak-callbacks",
 cl::desc("Declare callbacks extern weak, and only call if non-null."),
 cl::Hidden, cl::init(true));
+cl::opt
+ClNoSanitize("sanitizer-metadata-nosanitize-attr",
+ cl::desc("Mark some metadata features uncovered in functions "
+  "with associated no_sanitize attributes."),
+ cl::Hidden, cl::init(true));
 
 cl::opt ClEmitCovered("sanitizer-metadata-covered",
 cl::desc("Emit PCs for covered functions."),
@@ -268,6 +273,8 @@
 RequiresCovered |= runOn(I, MIS, MDB, FeatureMask);
   }
 
+  if (ClNoSanitize && F.hasFnAttribute("no_sanitize_thread"))
+FeatureMask &= ~kSanitizerBinaryMetadataAtomics;
   if (F.isVarArg())
 FeatureMask &= ~kSanitizerBinaryMetadataUAR;
   if (FeatureMask & kSanitizerBinaryMetadataUAR) {
Index: clang/test/CodeGen/sanitize-metadata-nosanitize.c
===
--- /dev/null
+++ clang/test/CodeGen/sanitize-metadata-nosanitize.c
@@ -0,0 +1,111 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --check-attributes --check-globals --version 2
+// RUN: %clang_cc1 -O -fexperimental-sanitize-metadata=covered -fexperimental-sanitize-metadata=atomics -fexperimental-sanitize-metadata=uar -triple x86_64-gnu-linux -x c -S -emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK
+
+//.
+// CHECK: @__start_sanmd_covered = extern_weak hidden global ptr
+// CHECK: @__stop_sanmd_covered = extern_weak hidden global ptr
+// CHECK: @__start_sanmd_atomics = extern_weak hidden global ptr
+// CHECK: @__stop_sanmd_atomics = extern_weak hidden global ptr
+// CHECK: @llvm.used = appending global [4 x ptr] [ptr @__sanitizer_metadata_covered.module_ctor, ptr @__sanitizer_metadata_covered.module_dtor, ptr @__sanitizer_metadata_atomics.module_ctor, ptr @__sanitizer_metadata_atomics.module_dtor], section "llvm.metadata"
+// CHECK: @llvm.global_ctors = appending global [2 x { i32, ptr, ptr }] [{ i32, ptr, ptr } { i32 2, ptr @__sanitizer_metadata_covered.module_ctor, ptr @__sanitizer_metadata_covered.module_ctor }, { i32, ptr, ptr } { i32 2, ptr @__sanitizer_metadata_atomics.module_ctor, ptr @__sanitizer_metadata_atomics.module_ctor }]
+// CHECK: @llvm.global_dtors = appending global [2 x { i32, ptr, ptr }] [{ i32, ptr, ptr } { i32 2, ptr @__sanitizer_metadata_covered.module_dtor, ptr @__sanitizer_metadata_covered.module_dtor }, { i32, ptr, ptr } { i32 2, ptr @__sanitizer_metadata_atomics.module_dtor, ptr @__sanitizer_metadata_atomics.module_dtor }]
+//.
+// CHECK: Function Attrs: mustprogress nofree noinline norecurse nosync nounwind willreturn memory(write, argmem: none, inaccessiblemem: none)
+// CHECK-LABEL: define dso_local void @escape
+// CHECK-SAME: (ptr noundef [[P:%.*]]) local_unnamed_addr #[[ATTR0:[0-9]+]] !pcsections !2 {
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:ret void
+//
+__attribute__((noinline, not_tail_called)) void escape(const volatile void *p) {
+  static const volatile void *sink;
+  sink = p;
+}
+
+// CHECK: Function Attrs: mustprogress nofree norecurse nounwind willreturn memory(write, argmem: readwrite, inaccessiblemem: none)
+// CHECK-LABEL: define dso_local i32 @normal_function
+// CHECK-SAME: (ptr noundef [[X:%.*]], ptr nocapture noundef readonly [[Y:%.*]]) local_unnamed_addr #[[ATTR1:[0-9]+]] !pcsections !4 {
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[X_ADDR:%.*]] = alloca ptr, align 8
+// CHECK-NEXT:store ptr [[X]], ptr [[X_ADDR]], align 8, !tbaa [[TBAA6:![0-9]+]]
+// CHECK-NEXT:store atomic i32 1, ptr [[X]] monotonic, align 4, !pcsections !10
+// CHECK-NEXT:notail call void @escape(ptr noundef nonnull [[X_ADDR]])
+// CHECK-NEXT:[[TMP0:%.*]] = load i32, ptr [[Y]], align 4, !tbaa [[TBAA11:![0-9]+]]
+// CHECK-NEXT:ret i32 [[TMP0]]
+//
+int normal_function(int *x, int *y) {
+  __atomic_store_n(x, 1, __ATOMIC_RELAXED);
+  escape(&x);
+  return *y;
+}
+
+// CHECK: Function Attrs: disable_sanitizer_instrumentation mustprogress nofree norecurse nounwind willreturn memory(write, argmem

[PATCH] D147989: [clang] Fix Attribute Placement

2023-04-19 Thread Sam Tebbs via Phabricator via cfe-commits
samtebbs added inline comments.



Comment at: clang/lib/Sema/SemaDecl.cpp:5041
   case DeclSpec::TST_enum:
 return 4;
   default:

ipriyanshi1708 wrote:
> jrtc27 wrote:
> > Why not just always pass the full DeclSpec and handle the class case here, 
> > maybe with a bool to allow other users to not need to treat enum class as 
> > different?
> Ya, we can do that too. But like GetDiagnosticTypeSpecifierID() is also 
> called in many other places in the file so if I pass the full DeclSpec in 
> this function will not disturb those calls?
It's probably worth doing as the other callsites just pass the `DeclSpec`'s 
type specifier.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147989/new/

https://reviews.llvm.org/D147989

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D147989: [clang] Fix Attribute Placement

2023-04-19 Thread Priyanshi Agarwal via Phabricator via cfe-commits
ipriyanshi1708 updated this revision to Diff 514931.
ipriyanshi1708 marked an inline comment as done.
ipriyanshi1708 added a comment.

Updated the logic


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147989/new/

https://reviews.llvm.org/D147989

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaDecl.cpp
  clang/test/Sema/attr-declspec-ignored.c
  clang/test/SemaCXX/attr-declspec-ignored.cpp

Index: clang/test/SemaCXX/attr-declspec-ignored.cpp
===
--- clang/test/SemaCXX/attr-declspec-ignored.cpp
+++ clang/test/SemaCXX/attr-declspec-ignored.cpp
@@ -9,6 +9,8 @@
   // expected-warning{{attribute 'aligned' is ignored, place it after "union" to apply attribute to type declaration}}
   __attribute__((visibility("hidden")))  __attribute__((aligned)) enum D {D}; // expected-warning{{attribute 'visibility' is ignored, place it after "enum" to apply attribute to type declaration}} \
   // expected-warning{{attribute 'aligned' is ignored, place it after "enum" to apply attribute to type declaration}}
+  __attribute__((visibility("hidden")))  __attribute__((aligned)) enum class EC {}; // expected-warning{{attribute 'visibility' is ignored, place it after "enum class" to apply attribute to type declaration}} \
+  // expected-warning{{attribute 'aligned' is ignored, place it after "enum class" to apply attribute to type declaration}}
 
   // Test that we get the same warnings for type declarations nested in a record.
   struct X {
@@ -20,7 +22,9 @@
 // expected-warning{{attribute 'aligned' is ignored, place it after "union" to apply attribute to type declaration}}
 __attribute__((visibility("hidden")))  __attribute__((aligned)) enum D {D}; // expected-warning{{attribute 'visibility' is ignored, place it after "enum" to apply attribute to type declaration}} \
 // expected-warning{{attribute 'aligned' is ignored, place it after "enum" to apply attribute to type declaration}}
-
+__attribute__((visibility("hidden")))  __attribute__((aligned)) enum class EC {}; // expected-warning{{attribute 'visibility' is ignored, place it after "enum class" to apply attribute to type declaration}} \
+// expected-warning{{attribute 'aligned' is ignored, place it after "enum class" to apply attribute to type declaration}}
+  
 // Also test [[]] attribute syntax. (On a non-nested declaration, these
 // generate a hard "misplaced attributes" error, which we test for
 // elsewhere.)
@@ -32,6 +36,8 @@
 // expected-warning{{attribute 'aligned' is ignored, place it after "union" to apply attribute to type declaration}}
 [[gnu::visibility("hidden")]]  [[gnu::aligned]] enum H {H}; // expected-warning{{attribute 'visibility' is ignored, place it after "enum" to apply attribute to type declaration}} \
 // expected-warning{{attribute 'aligned' is ignored, place it after "enum" to apply attribute to type declaration}}
+[[gnu::visibility("hidden")]]  [[gnu::aligned]] enum class I {}; // expected-warning{{attribute 'visibility' is ignored, place it after "enum class" to apply attribute to type declaration}} \
+// expected-warning{{attribute 'aligned' is ignored, place it after "enum class" to apply attribute to type declaration}}
   };
 }
 
@@ -40,16 +46,19 @@
   __attribute__((visibility("hidden")))  __attribute__((aligned)) struct B {} b;
   __attribute__((visibility("hidden")))  __attribute__((aligned)) union C {} c;
   __attribute__((visibility("hidden")))  __attribute__((aligned)) enum D {D} d;
+  __attribute__((visibility("hidden")))  __attribute__((aligned)) enum class EC {} ec;
 
   struct X {
 __attribute__((visibility("hidden")))  __attribute__((aligned)) class A {} a;
 __attribute__((visibility("hidden")))  __attribute__((aligned)) struct B {} b;
 __attribute__((visibility("hidden")))  __attribute__((aligned)) union C {} c;
 __attribute__((visibility("hidden")))  __attribute__((aligned)) enum D {D} d;
+__attribute__((visibility("hidden")))  __attribute__((aligned)) enum class EC {} ec;
 
 [[gnu::visibility("hidden")]]  [[gnu::aligned]] class E {} e;
 [[gnu::visibility("hidden")]]  [[gnu::aligned]] struct F {} f;
 [[gnu::visibility("hidden")]]  [[gnu::aligned]] union G {} g;
 [[gnu::visibility("hidden")]]  [[gnu::aligned]] enum H {H} h;
+[[gnu::visibility("hidden")]]  [[gnu::aligned]] enum class I {} i;
   };
 }
Index: clang/test/Sema/attr-declspec-ignored.c
===
--- clang/test/Sema/attr-declspec-ignored.c
+++ clang/test/Sema/attr-declspec-ignored.c
@@ -19,4 +19,4 @@
 
 __attribute__((visibility("hidden")))  __attribute__((aligned)) struct D {} d;
 __attribute__((visibility("hidden")))  __attribute__((aligned)) union E {} e;
-__attribute__((visibility("hidden")))  __attribute__((aligned)) enum F {F} f;
+__attribute__((visibi

[PATCH] D143870: [clang-format] Remove all include duplicates not only those in the same block

2023-04-19 Thread Fabian Keßler via Phabricator via cfe-commits
Febbe added a comment.

Actually, I already wanted to add an enum, controlling this behavior. 
But even with an enum, this check should only remove includes in consecutive 
blocks, which could be relocated (are not split by `#defines` or a comment)
Or I should add the options to `DeduplicateIncludeDirectives`: 
`{DID_InSameBlock (default), DID_Never, DID_Allways, DID_OnlyConsecutiveBlocks}`

Note, that I use DID_InSameBlock as default, because that's the current 
behavior, even many people would like to have it off by default.

Regarding the breaking of current features: What would you do, if a break is 
necessary, to implement a way more useful feature or to fix a huge issue/bug? 
Would you just infer a new version number? (I personally don't like the idea of 
having version numbers for specific tests, but that would be the easiest way to 
keep compatibility with old configurations and codebases).
Of course, the assumptions must be proven, as you said.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143870/new/

https://reviews.llvm.org/D143870

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D146178: [Clang][Sema] Fix comparison of constraint expressions

2023-04-19 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

Sorry I haven't been able to help yet, I'm STILL dealing with IT issues with 
the server I work on.  I appreciate your patience!

I have no comments, this all looks fine to me. Does this fix 62110 as well?  Is 
there anythign to hold this up from landing?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D146178/new/

https://reviews.llvm.org/D146178

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 89d2785 - Reapply D146987 "[Assignment Tracking] Enable by default"

2023-04-19 Thread via cfe-commits

Author: OCHyams
Date: 2023-04-19T14:15:58+01:00
New Revision: 89d27854ec7f5e8bd83e72fa574740bf3d06355b

URL: 
https://github.com/llvm/llvm-project/commit/89d27854ec7f5e8bd83e72fa574740bf3d06355b
DIFF: 
https://github.com/llvm/llvm-project/commit/89d27854ec7f5e8bd83e72fa574740bf3d06355b.diff

LOG: Reapply D146987 "[Assignment Tracking] Enable by default"

This reverts commit 7674ae7231c4e286b93eb399e475765630666f8b which
reverts D146987.

See https://reviews.llvm.org/D146987 for issues.

Added: 


Modified: 
clang/include/clang/Driver/Options.td
clang/test/CodeGen/assignment-tracking/flag.cpp

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index eed0d517a1ad7..604b4a45fffc1 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -5817,7 +5817,7 @@ def fexperimental_assignment_tracking_EQ : Joined<["-"], 
"fexperimental-assignme
   Group, CodeGenOpts<"EnableAssignmentTracking">,
   NormalizedValuesScope<"CodeGenOptions::AssignmentTrackingOpts">,
   Values<"disabled,enabled,forced">, 
NormalizedValues<["Disabled","Enabled","Forced"]>,
-  MarshallingInfoEnum, "Disabled">;
+  MarshallingInfoEnum, "Enabled">;
 
 } // let Flags = [CC1Option, NoDriverOption]
 

diff  --git a/clang/test/CodeGen/assignment-tracking/flag.cpp 
b/clang/test/CodeGen/assignment-tracking/flag.cpp
index aa1f054dae4d7..3bd974fe07c6c 100644
--- a/clang/test/CodeGen/assignment-tracking/flag.cpp
+++ b/clang/test/CodeGen/assignment-tracking/flag.cpp
@@ -8,10 +8,10 @@
 // RUN: -emit-llvm  %s -o - -fexperimental-assignment-tracking=disabled 
-O1\
 // RUN: | FileCheck %s --check-prefixes=DISABLE
 
- Disabled by default:
+ Enabled by default:
 // RUN: %clang_cc1 -triple x86_64-none-linux-gnu -debug-info-kind=standalone   
\
 // RUN: -emit-llvm  %s -o - -O1
\
-// RUN: | FileCheck %s --check-prefixes=DISABLE
+// RUN: | FileCheck %s --check-prefixes=ENABLE
 
  Disabled at O0 unless forced.
 // RUN: %clang_cc1 -triple x86_64-none-linux-gnu -debug-info-kind=standalone   
\



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148696: [clang][Sema][NFC] Sprinkle some const around in Sema

2023-04-19 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder updated this revision to Diff 514933.
Herald added a reviewer: jdoerfert.
Herald added subscribers: jplehr, sstefan1.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148696/new/

https://reviews.llvm.org/D148696

Files:
  clang/include/clang/AST/DeclarationName.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/DeclarationName.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaLookup.cpp
  clang/lib/Sema/SemaOpenMP.cpp

Index: clang/lib/Sema/SemaOpenMP.cpp
===
--- clang/lib/Sema/SemaOpenMP.cpp
+++ clang/lib/Sema/SemaOpenMP.cpp
@@ -2025,9 +2025,9 @@
 };
 } // anonymous namespace
 
-Sema::SemaDiagnosticBuilder Sema::diagIfOpenMPDeviceCode(SourceLocation Loc,
- unsigned DiagID,
- FunctionDecl *FD) {
+Sema::SemaDiagnosticBuilder
+Sema::diagIfOpenMPDeviceCode(SourceLocation Loc, unsigned DiagID,
+ const FunctionDecl *FD) {
   assert(LangOpts.OpenMP && LangOpts.OpenMPIsDevice &&
  "Expected OpenMP device compilation.");
 
@@ -2065,7 +2065,7 @@
 
 Sema::SemaDiagnosticBuilder Sema::diagIfOpenMPHostCode(SourceLocation Loc,
unsigned DiagID,
-   FunctionDecl *FD) {
+   const FunctionDecl *FD) {
   assert(LangOpts.OpenMP && !LangOpts.OpenMPIsDevice &&
  "Expected OpenMP host compilation.");
 
Index: clang/lib/Sema/SemaLookup.cpp
===
--- clang/lib/Sema/SemaLookup.cpp
+++ clang/lib/Sema/SemaLookup.cpp
@@ -199,7 +199,7 @@
 const_iterator end() const { return list.end(); }
 
 llvm::iterator_range
-getNamespacesFor(DeclContext *DC) const {
+getNamespacesFor(const DeclContext *DC) const {
   return llvm::make_range(std::equal_range(begin(), end(),
DC->getPrimaryContext(),
UnqualUsingEntry::Comparator()));
@@ -351,12 +351,12 @@
 
 /// Get a representative context for a declaration such that two declarations
 /// will have the same context if they were found within the same scope.
-static DeclContext *getContextForScopeMatching(Decl *D) {
+static const DeclContext *getContextForScopeMatching(const Decl *D) {
   // For function-local declarations, use that function as the context. This
   // doesn't account for scopes within the function; the caller must deal with
   // those.
-  DeclContext *DC = D->getLexicalDeclContext();
-  if (DC->isFunctionOrMethod())
+  if (const DeclContext *DC = D->getLexicalDeclContext();
+  DC->isFunctionOrMethod())
 return DC;
 
   // Otherwise, look at the semantic context of the declaration. The
@@ -367,15 +367,16 @@
 /// Determine whether \p D is a better lookup result than \p Existing,
 /// given that they declare the same entity.
 static bool isPreferredLookupResult(Sema &S, Sema::LookupNameKind Kind,
-NamedDecl *D, NamedDecl *Existing) {
+const NamedDecl *D,
+const NamedDecl *Existing) {
   // When looking up redeclarations of a using declaration, prefer a using
   // shadow declaration over any other declaration of the same entity.
   if (Kind == Sema::LookupUsingDeclName && isa(D) &&
   !isa(Existing))
 return true;
 
-  auto *DUnderlying = D->getUnderlyingDecl();
-  auto *EUnderlying = Existing->getUnderlyingDecl();
+  const auto *DUnderlying = D->getUnderlyingDecl();
+  const auto *EUnderlying = Existing->getUnderlyingDecl();
 
   // If they have different underlying declarations, prefer a typedef over the
   // original type (this happens when two type declarations denote the same
@@ -397,8 +398,8 @@
   // FIXME: In the presence of ambiguous default arguments, we should keep both,
   //so we can diagnose the ambiguity if the default argument is needed.
   //See C++ [over.match.best]p3.
-  if (auto *DFD = dyn_cast(DUnderlying)) {
-auto *EFD = cast(EUnderlying);
+  if (const auto *DFD = dyn_cast(DUnderlying)) {
+const auto *EFD = cast(EUnderlying);
 unsigned DMin = DFD->getMinRequiredArguments();
 unsigned EMin = EFD->getMinRequiredArguments();
 // If D has more default arguments, it is preferred.
@@ -409,8 +410,8 @@
   }
 
   // Pick the template with more default template arguments.
-  if (auto *DTD = dyn_cast(DUnderlying)) {
-auto *ETD = cast(EUnderlying);
+  if (const auto *DTD = dyn_cast(DUnderlying)) {
+const auto *ETD = cast(EUnderlying);
 unsigned DMin = DTD->getTemplateParameters()->getMinRequiredArguments();
 unsigned EMin = ETD->getTemplateParameters()->getMinRequiredArguments();
  

[PATCH] D148690: [clang][Interp] Handle __extension__ unary operators

2023-04-19 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added inline comments.



Comment at: clang/test/AST/Interp/literals.cpp:791
+#endif
 return __FUNCTION__[index];
   }

tbaeder wrote:
> It's weird that the above two statements warn about using `__FUNCTION__` and 
> the return statement doesn't.
Aren't they warning about it being 'unused'?  If so, the 'return' uses them...


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148690/new/

https://reviews.llvm.org/D148690

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148690: [clang][Interp] Handle __extension__ unary operators

2023-04-19 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder added inline comments.



Comment at: clang/test/AST/Interp/literals.cpp:791
+#endif
 return __FUNCTION__[index];
   }

erichkeane wrote:
> tbaeder wrote:
> > It's weird that the above two statements warn about using `__FUNCTION__` 
> > and the return statement doesn't.
> Aren't they warning about it being 'unused'?  If so, the 'return' uses them...
Right, my message wasn't clear but I meant the c++14 extension diagnostic: 
https://godbolt.org/z/Kso8qv7jh


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148690/new/

https://reviews.llvm.org/D148690

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148712: [clang] Diagnose shadowing of lambda's template parameter by a capture

2023-04-19 Thread Mariya Podchishchaeva via Phabricator via cfe-commits
Fznamznon created this revision.
Herald added a project: All.
Fznamznon requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

expr.prim.lambda.capture p5 says:
If an identifier in a capture appears as the declarator-id of a parameter of
the lambda-declarator's parameter-declaration-clause or as the name of a
template parameter of the lambda-expression's template-parameter-list,
the program is ill-formed.
and also has the following example:

  auto h = [y = 0](y) { return 0; };

which now results in

  error: declaration of 'y' shadows template parameter
auto l1 = [y = 0](y) { return 0; };
   ^
  note: template parameter is declared here
auto l1 = [y = 0](y) { return 0; };
   ^

Fixes https://github.com/llvm/llvm-project/issues/61105


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D148712

Files:
  clang/lib/Sema/SemaLambda.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.lambda/expr.prim.lambda.capture/p5.cpp
  clang/test/SemaCXX/warn-shadow-in-lambdas.cpp


Index: clang/test/SemaCXX/warn-shadow-in-lambdas.cpp
===
--- clang/test/SemaCXX/warn-shadow-in-lambdas.cpp
+++ clang/test/SemaCXX/warn-shadow-in-lambdas.cpp
@@ -2,6 +2,7 @@
 // RUN: %clang_cc1 -std=c++14 -verify -fsyntax-only -Wshadow 
-Wshadow-uncaptured-local %s
 // RUN: %clang_cc1 -std=c++14 -verify -fsyntax-only -Wshadow-all %s
 // RUN: %clang_cc1 -std=c++17 -verify -fsyntax-only -Wshadow-all %s
+// RUN: %clang_cc1 -std=c++20 -verify -fsyntax-only -Wshadow-all %s
 
 void foo(int param) { // expected-note 1+ {{previous declaration is here}}
   int var = 0; // expected-note 1+ {{previous declaration is here}}
@@ -146,3 +147,21 @@
 int b = 0; // expected-error {{redefinition of 'b'}}
   };
 }
+
+namespace GH61105 {
+void f() {
+  int y = 0;
+  int x = 0;
+#if __cplusplus >= 202002L
+  auto l1 = [y](y) { return 0; }; // expected-error {{declaration 
of 'y' shadows template parameter}} \
+  // expected-note {{template 
parameter is declared here}}
+  auto l2 = [=]() { int a = y; return 0; }; // expected-error 
{{'y' does not refer to a value}} \
+// expected-note 
{{declared here}}
+  auto l3 = [&, y](y) { int a = x; return 0; }; // 
expected-error {{declaration of 'y' shadows template parameter}} \
+  // 
expected-note {{template parameter is declared here}}
+  auto l4 = [x, y]() { return 0; }; // expected-error 
{{declaration of 'y' shadows template parameter}} \
+   // expected-error 
{{declaration of 'x' shadows template parameter}} \
+   // expected-note 
2{{template parameter is declared here}}
+#endif
+}
+}
Index: 
clang/test/CXX/expr/expr.prim/expr.prim.lambda/expr.prim.lambda.capture/p5.cpp
===
--- /dev/null
+++ 
clang/test/CXX/expr/expr.prim/expr.prim.lambda/expr.prim.lambda.capture/p5.cpp
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -std=c++20 -verify %s
+
+void f() {
+  int x = 0;
+  auto g = [x](int x) { return 0; }; // expected-error {{a lambda parameter 
cannot shadow an explicitly captured entity}} \
+ // expected-note {{variable 'x' is 
explicitly captured here}}
+  auto h = [y = 0](y) { return 0; };  // expected-error 
{{declaration of 'y' shadows template parameter}} \
+  // expected-note {{template 
parameter is declared here}}
+
+}
Index: clang/lib/Sema/SemaLambda.cpp
===
--- clang/lib/Sema/SemaLambda.cpp
+++ clang/lib/Sema/SemaLambda.cpp
@@ -1365,6 +1365,26 @@
 PushOnScopeChains(P, CurScope);
   }
 
+  // C++: expr.prim.lambda.capture p5:
+  // If an identifier in a capture appears as the declarator-id of a parameter
+  // of the lambda-declarator's parameter-declaration-clause or as the name of 
a
+  // template parameter of the lambda-expression's template-parameter-list, the
+  // program is ill-formed.
+  TemplateParameterList *TemplateParams =
+  getGenericLambdaTemplateParameterList(LSI, *this);
+  if (TemplateParams) {
+for (const auto *TP : TemplateParams->asArray()) {
+  if (!TP->getIdentifier())
+continue;
+  for (const auto &Capture : Intro.Captures) {
+if (Capture.Id == TP->getIdentifier()) {
+  Diag(Capture.Loc, diag::err_template_param_shadow) << Capture.Id;
+  Diag(TP->getLocation(), diag::note_template_param_here);
+}
+  }
+}
+  }
+
   // C++20: dcl.decl.general p4:
   // The optional requires-clause ([temp.pre]) in an init-declarator or
   // member-declarator shall be present only if the declarator d

[PATCH] D148573: Port -fsanitize=function to AArch64

2023-04-19 Thread Peter Smith via Phabricator via cfe-commits
peter.smith accepted this revision.
peter.smith added a comment.
This revision is now accepted and ready to land.

With moving the signature before the function entry this looks good to me. I'm 
not so familiar with the code in https://reviews.llvm.org/D148665 would ideally 
find someone a bit more experienced to take a look at that part. If I'm the 
only one available I can take a look but may take a bit more time.

We're looking to clarify when a BTI is required in the ABI 
https://github.com/ARM-software/abi-aa/issues/196 starting with some design 
options.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148573/new/

https://reviews.llvm.org/D148573

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D146591: [dataflow] add HTML logger: browse code/cfg/analysis timeline/state

2023-04-19 Thread Sam McCall via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGa443b3d18ef4: [dataflow] add HTML logger: browse 
code/cfg/analysis timeline/state (authored by sammccall).

Changed prior to commit:
  https://reviews.llvm.org/D146591?vs=513544&id=514941#toc

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D146591/new/

https://reviews.llvm.org/D146591

Files:
  clang/include/clang/Analysis/FlowSensitive/Logger.h
  clang/lib/Analysis/FlowSensitive/CMakeLists.txt
  clang/lib/Analysis/FlowSensitive/DataflowAnalysisContext.cpp
  clang/lib/Analysis/FlowSensitive/HTMLLogger.cpp
  clang/lib/Analysis/FlowSensitive/HTMLLogger.css
  clang/lib/Analysis/FlowSensitive/HTMLLogger.html
  clang/lib/Analysis/FlowSensitive/HTMLLogger.js
  clang/unittests/Analysis/FlowSensitive/LoggerTest.cpp
  clang/utils/bundle_resources.py

Index: clang/utils/bundle_resources.py
===
--- /dev/null
+++ clang/utils/bundle_resources.py
@@ -0,0 +1,29 @@
+#!/usr/bin/env python3
+
+#===- bundle_resources.py - Generate string constants with file contents. ===
+#
+# Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+# See https://llvm.org/LICENSE.txt for license information.
+# SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+#
+#===--===
+
+# Usage: bundle-resources.py foo.inc a.js path/b.css ...
+# Produces foo.inc containing:
+#   const char a_js[] = "...";
+#   const char b_css[] = "...";
+import os
+import sys
+
+outfile = sys.argv[1]
+infiles = sys.argv[2:]
+
+with open(outfile, 'w') as out:
+  for filename in infiles:
+varname = os.path.basename(filename).replace('.', '_')
+out.write("const char " + varname + "[] = \n");
+# MSVC limits each chunk of string to 2k, so split by lines.
+# The overall limit is 64k, which ought to be enough for anyone.
+for line in open(filename).read().split('\n'):
+  out.write('  R"x(' + line + ')x" "\\n"\n' )
+out.write('  ;\n');
Index: clang/unittests/Analysis/FlowSensitive/LoggerTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/LoggerTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/LoggerTest.cpp
@@ -9,6 +9,7 @@
 
 namespace clang::dataflow::test {
 namespace {
+using testing::HasSubstr;
 
 struct TestLattice {
   int Elements = 0;
@@ -83,19 +84,24 @@
   void logText(llvm::StringRef Text) override { OS << Text << "\n"; }
 };
 
-TEST(LoggerTest, Sequence) {
+AnalysisInputs makeInputs() {
   const char *Code = R"cpp(
 int target(bool b, int p, int q) {
   return b ? p : q;
 }
 )cpp";
+  static const std::vector Args = {
+  "-fsyntax-only", "-fno-delayed-template-parsing", "-std=c++17"};
 
   auto Inputs = AnalysisInputs(
   Code, ast_matchers::hasName("target"),
   [](ASTContext &C, Environment &) { return TestAnalysis(C); });
-  std::vector Args = {
-  "-fsyntax-only", "-fno-delayed-template-parsing", "-std=c++17"};
   Inputs.ASTBuildArgs = Args;
+  return Inputs;
+}
+
+TEST(LoggerTest, Sequence) {
+  auto Inputs = makeInputs();
   std::string Log;
   TestLogger Logger(Log);
   Inputs.BuiltinOptions.Log = &Logger;
@@ -148,5 +154,29 @@
 )");
 }
 
+TEST(LoggerTest, HTML) {
+  auto Inputs = makeInputs();
+  std::vector Logs;
+  auto Logger = Logger::html([&]() {
+Logs.emplace_back();
+return std::make_unique(Logs.back());
+  });
+  Inputs.BuiltinOptions.Log = Logger.get();
+
+  ASSERT_THAT_ERROR(checkDataflow(std::move(Inputs),
+[](const AnalysisOutputs &) {}),
+llvm::Succeeded());
+
+  // Simple smoke tests: we can't meaningfully test the behavior.
+  ASSERT_THAT(Logs, testing::SizeIs(1));
+  EXPECT_THAT(Logs[0], HasSubstr("function updateSelection")) << "embeds JS";
+  EXPECT_THAT(Logs[0], HasSubstr("html {")) << "embeds CSS";
+  EXPECT_THAT(Logs[0], HasSubstr("b (ImplicitCastExpr")) << "has CFG elements";
+  EXPECT_THAT(Logs[0], HasSubstr("\"B3:1_B3.1\":"))
+  << "has analysis point state";
+  EXPECT_THAT(Logs[0], HasSubstr("transferBranch(0)")) << "has analysis logs";
+  EXPECT_THAT(Logs[0], HasSubstr("LocToVal")) << "has built-in lattice dump";
+}
+
 } // namespace
 } // namespace clang::dataflow::test
Index: clang/lib/Analysis/FlowSensitive/HTMLLogger.js
===
--- /dev/null
+++ clang/lib/Analysis/FlowSensitive/HTMLLogger.js
@@ -0,0 +1,216 @@
+//===-- HTMLLogger.js -===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--

[clang] a443b3d - [dataflow] add HTML logger: browse code/cfg/analysis timeline/state

2023-04-19 Thread Sam McCall via cfe-commits

Author: Sam McCall
Date: 2023-04-19T15:37:06+02:00
New Revision: a443b3d18ef4d01e767994845b3f2819480a7b48

URL: 
https://github.com/llvm/llvm-project/commit/a443b3d18ef4d01e767994845b3f2819480a7b48
DIFF: 
https://github.com/llvm/llvm-project/commit/a443b3d18ef4d01e767994845b3f2819480a7b48.diff

LOG: [dataflow] add HTML logger: browse code/cfg/analysis timeline/state

With -dataflow-log=/dir we will write /dir/0.html etc for each
function analyzed.

These files show the function's code and CFG, and the path through
the CFG taken by the analysis. At each analysis point we can see the
lattice state.

Currently the lattice state dump is not terribly useful but we can
improve this: showing values associated with the current Expr,
simplifying flow condition, highlighting changes etc.

(Trying not to let this patch scope-creep too much, so I ripped out the
half-finished features)

Demo: 
https://htmlpreview.github.io/?https://gist.githubusercontent.com/sam-mccall/1746985bf13406bd19181af281aea9ff/raw/9718fdd48406dabccb3092acd983b4bd55da9dfa/analysis.html

Differential Revision: https://reviews.llvm.org/D146591

Added: 
clang/lib/Analysis/FlowSensitive/HTMLLogger.cpp
clang/lib/Analysis/FlowSensitive/HTMLLogger.css
clang/lib/Analysis/FlowSensitive/HTMLLogger.html
clang/lib/Analysis/FlowSensitive/HTMLLogger.js
clang/utils/bundle_resources.py

Modified: 
clang/include/clang/Analysis/FlowSensitive/Logger.h
clang/lib/Analysis/FlowSensitive/CMakeLists.txt
clang/lib/Analysis/FlowSensitive/DataflowAnalysisContext.cpp
clang/unittests/Analysis/FlowSensitive/LoggerTest.cpp

Removed: 




diff  --git a/clang/include/clang/Analysis/FlowSensitive/Logger.h 
b/clang/include/clang/Analysis/FlowSensitive/Logger.h
index 903dfbc30d40d..6836488003a97 100644
--- a/clang/include/clang/Analysis/FlowSensitive/Logger.h
+++ b/clang/include/clang/Analysis/FlowSensitive/Logger.h
@@ -31,6 +31,10 @@ class Logger {
   /// A logger that simply writes messages to the specified ostream in real
   /// time.
   static std::unique_ptr textual(llvm::raw_ostream &);
+  /// A logger that builds an HTML UI to inspect the analysis results.
+  /// Each function's analysis is written to a stream obtained from the 
factory.
+  static std::unique_ptr
+  html(std::function()>);
 
   virtual ~Logger() = default;
 

diff  --git a/clang/lib/Analysis/FlowSensitive/CMakeLists.txt 
b/clang/lib/Analysis/FlowSensitive/CMakeLists.txt
index 86646662c4da9..aafbdfb2f6bdf 100644
--- a/clang/lib/Analysis/FlowSensitive/CMakeLists.txt
+++ b/clang/lib/Analysis/FlowSensitive/CMakeLists.txt
@@ -3,6 +3,7 @@ add_clang_library(clangAnalysisFlowSensitive
   ControlFlowContext.cpp
   DataflowAnalysisContext.cpp
   DataflowEnvironment.cpp
+  HTMLLogger.cpp
   Logger.cpp
   Transfer.cpp
   TypeErasedDataflowAnalysis.cpp
@@ -17,3 +18,14 @@ add_clang_library(clangAnalysisFlowSensitive
   )
 
 add_subdirectory(Models)
+
+add_custom_command(OUTPUT HTMLLogger.inc
+  COMMAND "${Python3_EXECUTABLE}" 
${CLANG_SOURCE_DIR}/utils/bundle_resources.py 
+  ${CMAKE_CURRENT_BINARY_DIR}/HTMLLogger.inc
+  HTMLLogger.html HTMLLogger.css HTMLLogger.js
+  WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR}
+  COMMENT "Bundling HTMLLogger resources"
+  DEPENDS ${CLANG_SOURCE_DIR}/utils/bundle_resources.py HTMLLogger.html 
HTMLLogger.css HTMLLogger.js
+  VERBATIM)
+add_custom_target(clangAnalysisFlowSensitiveResources DEPENDS HTMLLogger.inc)
+add_dependencies(clangAnalysisFlowSensitive 
clangAnalysisFlowSensitiveResources)

diff  --git a/clang/lib/Analysis/FlowSensitive/DataflowAnalysisContext.cpp 
b/clang/lib/Analysis/FlowSensitive/DataflowAnalysisContext.cpp
index ad57fd156f443..5dd390e962d82 100644
--- a/clang/lib/Analysis/FlowSensitive/DataflowAnalysisContext.cpp
+++ b/clang/lib/Analysis/FlowSensitive/DataflowAnalysisContext.cpp
@@ -20,14 +20,17 @@
 #include "llvm/ADT/SetOperations.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/Debug.h"
+#include "llvm/Support/FileSystem.h"
+#include "llvm/Support/Path.h"
 #include 
 #include 
 #include 
 
-static llvm::cl::opt
-DataflowLog("dataflow-log", llvm::cl::Hidden, llvm::cl::ValueOptional,
-llvm::cl::desc("Emit log of dataflow analysis. With no arg, "
-   "writes textual log to stderr."));
+static llvm::cl::opt DataflowLog(
+"dataflow-log", llvm::cl::Hidden, llvm::cl::ValueOptional,
+llvm::cl::desc("Emit log of dataflow analysis. With no arg, writes textual 
"
+   "log to stderr. With an arg, writes HTML logs under the "
+   "specified directory (one per analyzed function)."));
 
 namespace clang {
 namespace dataflow {
@@ -218,6 +221,34 @@ DataflowAnalysisContext::getControlFlowContext(const 
FunctionDecl *F) {
   return nullptr;
 }
 
+static std::unique_ptr makeLoggerFromCommandLine() {
+  if (DataflowLog.empty())
+return Logger::textua

[PATCH] D148700: [clang] Add support for “regular” keyword attributes

2023-04-19 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added inline comments.



Comment at: clang/include/clang/Basic/TokenKinds.h:106
+#include "clang/Basic/AttrTokenKinds.inc"
+#undef KEYWORD
+  );

Does AttrTokenKinds.inc not do this undef for you?  Most of our tablegen'ed/.td 
files tend to...

Edit now that I've gone through the whole patch:

I see the inclusion into TokenKinds.def makes adding one a pain, but I suggest 
instead making these be KEYWORD_ATTRIBUTE(...), with all the 'fixings' that 
comes in TokenKinds.def (see the defines at the top), and then including 
TokenKinds.def here instead.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148700/new/

https://reviews.llvm.org/D148700

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D145264: [OpenMP][MLIR][Flang][Driver][bbc] Lower and apply Module FlagsAttr

2023-04-19 Thread Andrew Gozillon via Phabricator via cfe-commits
agozillon abandoned this revision.
agozillon added a comment.
Herald added a subscriber: bviyer.

Closing this patch now that each individual component is upstreamed via 
seperate phabricator patches! Thank you to all the reviewers for your time and 
help.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D145264/new/

https://reviews.llvm.org/D145264

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148699: [clang] Mark keywords that have their own parsing rules

2023-04-19 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

I see a lot of other attributes are being marked with this CustomKeyword 
syntax, I find myself thinking tests should be written in terms of them, rather 
than a 'new'/'incomplete' attribute


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148699/new/

https://reviews.llvm.org/D148699

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148702: [clang] Add Parse and Sema support for RegularKeyword attributes

2023-04-19 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

So I don't mind the changes in this stack, though this doing a little bit of a 
'backdoor' way of getting the arm-streaming attribute in rubs me the wrong way. 
 I'm not a huge fan that the solution we've got here only solves THIS problem, 
and doesn't extend to improving the situation with older attributes as well.

I would like someone more knowledgeable in parsing to take a look as well.




Comment at: clang/lib/Sema/SemaDecl.cpp:5308
   for (const ParsedAttr &AL : DS.getAttributes())
-Diag(AL.getLoc(), diag::warn_declspec_attribute_ignored)
+Diag(AL.getLoc(), AL.isRegularKeywordAttribute()
+  ? diag::err_declspec_keyword_has_no_effect

Is this function (isRegularKeywordAttribute) checking spellings?  If not, it 
needs to.  


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148702/new/

https://reviews.llvm.org/D148702

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D146591: [dataflow] add HTML logger: browse code/cfg/analysis timeline/state

2023-04-19 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

In D146591#4278074 , @xazax.hun wrote:

> I am a bit overloaded at the moment, feel free to commit. I can still add 
> comments later that could be addressed in a follow up.

Thanks! Happy to address as they come up.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D146591/new/

https://reviews.llvm.org/D146591

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] bbffa8b - [dataflow] add missing clangLex dep after a443b3d18ef4d01e7

2023-04-19 Thread Sam McCall via cfe-commits

Author: Sam McCall
Date: 2023-04-19T16:12:42+02:00
New Revision: bbffa8bd75fdaca8029e9719fa96923a3b15e2fd

URL: 
https://github.com/llvm/llvm-project/commit/bbffa8bd75fdaca8029e9719fa96923a3b15e2fd
DIFF: 
https://github.com/llvm/llvm-project/commit/bbffa8bd75fdaca8029e9719fa96923a3b15e2fd.diff

LOG: [dataflow] add missing clangLex dep after a443b3d18ef4d01e7

Added: 


Modified: 
clang/lib/Analysis/FlowSensitive/CMakeLists.txt

Removed: 




diff  --git a/clang/lib/Analysis/FlowSensitive/CMakeLists.txt 
b/clang/lib/Analysis/FlowSensitive/CMakeLists.txt
index aafbdfb2f6bd..b356116bcb54 100644
--- a/clang/lib/Analysis/FlowSensitive/CMakeLists.txt
+++ b/clang/lib/Analysis/FlowSensitive/CMakeLists.txt
@@ -15,6 +15,7 @@ add_clang_library(clangAnalysisFlowSensitive
   clangAnalysis
   clangAST
   clangBasic
+  clangLex
   )
 
 add_subdirectory(Models)



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148702: [clang] Add Parse and Sema support for RegularKeyword attributes

2023-04-19 Thread Richard Sandiford via Phabricator via cfe-commits
rsandifo-arm marked an inline comment as done.
rsandifo-arm added a comment.

Thanks for the reviews!

In D148702#4280392 , @erichkeane 
wrote:

> So I don't mind the changes in this stack, though this doing a little bit of 
> a 'backdoor' way of getting the arm-streaming attribute in rubs me the wrong 
> way.  I'm not a huge fan that the solution we've got here only solves THIS 
> problem, and doesn't extend to improving the situation with older attributes 
> as well.

Yeah, it looks a bit over-the-top/special-purpose when `__arm_streaming` is the 
only thing using it.  But we (Arm) have other “semantic attributes” in the 
pipeline, and this would be useful for them too.  Hopefully other targets will 
find the same.

We could even go back and retroactively support keywords for some existing Arm 
semantic attributes.  E.g. maybe we could allow `__aarch64_vector_pcs` 
alongside `__attribute__((aarch64_vector_pcs))`.  I'd have to see what others 
think.

But as far as I could tell, there are no existing keyword attributes whose 
grammar is close enough to standard attributes for the keywords to use the new 
infrastructure.  E.g. many existing keywords are allowed between qualifiers, 
whereas standard attributes aren't:

  int (__stdcall a1)(); // OK, but standard attributes aren't allowed in this 
position
  extern int (*const __stdcall volatile a2) (); // OK, but standard attributes 
wouldn't be allowed here

I don't think we can retroactively forbid these.  But I don't think it makes 
sense to allow new attributes like `__arm_streaming` in these positions either.




Comment at: clang/lib/Sema/SemaDecl.cpp:5308
   for (const ParsedAttr &AL : DS.getAttributes())
-Diag(AL.getLoc(), diag::warn_declspec_attribute_ignored)
+Diag(AL.getLoc(), AL.isRegularKeywordAttribute()
+  ? diag::err_declspec_keyword_has_no_effect

erichkeane wrote:
> Is this function (isRegularKeywordAttribute) checking spellings?  If not, it 
> needs to.  
Yeah, this is checking the spelling.  In principle, the series supports 
attributes that have a RegularKeyword spelling and some other spelling, and in 
that case, this check would only include attributes that were written using the 
RegularKeyword spelling.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148702/new/

https://reviews.llvm.org/D148702

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D147875: [clang][Diagnostics] WIP: Show line numbers when printing code snippets

2023-04-19 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder updated this revision to Diff 514954.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147875/new/

https://reviews.llvm.org/D147875

Files:
  clang/include/clang/Basic/DiagnosticOptions.def
  clang/include/clang/Basic/DiagnosticOptions.h
  clang/include/clang/Driver/Options.td
  clang/include/clang/Frontend/TextDiagnostic.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/TextDiagnostic.cpp
  clang/test/Analysis/Checkers/WebKit/uncounted-lambda-captures.cpp
  clang/test/FixIt/fixit-function-call.cpp
  clang/test/FixIt/fixit-newline-style.c
  clang/test/FixIt/fixit-unicode-with-utf8-output.c
  clang/test/FixIt/fixit-unicode.c
  clang/test/Frontend/source-col-map.c
  clang/test/Lexer/header.cpp
  clang/test/Lexer/string-literal-errors.cpp
  clang/test/Misc/caret-diags-macros.c
  clang/test/Misc/caret-diags-multiline.cpp
  clang/test/Misc/diag-macro-backtrace.c
  clang/test/Misc/message-length.c
  clang/test/Misc/tabstop.c
  clang/test/Misc/unnecessary-elipses.cpp
  clang/test/Misc/unprintable.c
  clang/test/Misc/wrong-encoding.c
  clang/test/Parser/brackets.c
  clang/test/Parser/brackets.cpp
  clang/test/Preprocessor/ucn-pp-identifier.c
  clang/test/Sema/caret-diags-complex-init.cpp
  clang/test/SemaCXX/struct-class-redecl.cpp

Index: clang/test/SemaCXX/struct-class-redecl.cpp
===
--- clang/test/SemaCXX/struct-class-redecl.cpp
+++ clang/test/SemaCXX/struct-class-redecl.cpp
@@ -1,5 +1,5 @@
-// RUN: %clang_cc1 -fsyntax-only -Wmismatched-tags -verify %s
-// RUN: not %clang_cc1 -fsyntax-only -Wmismatched-tags %s 2>&1 | FileCheck %s
+// RUN: %clang_cc1 -fsyntax-only -Wmismatched-tags -fno-diagnostics-show-line-numbers -verify %s
+// RUN: not %clang_cc1 -fsyntax-only -Wmismatched-tags -fno-diagnostics-show-line-numbers %s 2>&1 | FileCheck %s
 class X; // expected-note 2{{here}}
 typedef struct X * X_t; // expected-warning{{previously declared}}
 union X { int x; float y; }; // expected-error{{use of 'X' with tag type that does not match previous declaration}}
Index: clang/test/Sema/caret-diags-complex-init.cpp
===
--- clang/test/Sema/caret-diags-complex-init.cpp
+++ clang/test/Sema/caret-diags-complex-init.cpp
@@ -1,4 +1,4 @@
-// RUN: not %clang_cc1 -std=c++11 -fsyntax-only -fcaret-diagnostics-max-lines 5 %s 2>&1 | FileCheck %s -strict-whitespace
+// RUN: not %clang_cc1 -std=c++11 -fsyntax-only -fno-diagnostics-show-line-numbers -fcaret-diagnostics-max-lines 5 %s 2>&1 | FileCheck %s -strict-whitespace
 
 
 //CHECK: {{.*}}: error: excess elements in scalar initializer
Index: clang/test/Preprocessor/ucn-pp-identifier.c
===
--- clang/test/Preprocessor/ucn-pp-identifier.c
+++ clang/test/Preprocessor/ucn-pp-identifier.c
@@ -112,9 +112,9 @@
 #define capital_u_\U00FC
 // expected-warning@-1 {{incomplete universal character name}} expected-note@-1 {{did you mean to use '\u'?}} expected-warning@-1 {{whitespace}}
 // CHECK: note: did you mean to use '\u'?
-// CHECK-NEXT:   #define capital_u_\U00FC
-// CHECK-NEXT: {{^   \^}}
-// CHECK-NEXT: {{^   u}}
+// CHECK-NEXT: {{^  112 | #define capital_u_\U00FC}}
+// CHECK-NEXT: {{^  |\^}}
+// CHECK-NEXT: {{^  |u}}
 
 #define \u{}   // expected-warning {{empty delimited universal character name; treating as '\' 'u' '{' '}'}} expected-error {{macro name must be an identifier}}
 #define \u1{123}   // expected-warning {{incomplete universal character name; treating as '\' followed by identifier}} expected-error {{macro name must be an identifier}}
Index: clang/test/Parser/brackets.cpp
===
--- clang/test/Parser/brackets.cpp
+++ clang/test/Parser/brackets.cpp
@@ -2,7 +2,7 @@
 // RUN: cp %s %t
 // RUN: not %clang_cc1 -fixit %t -x c++ -DFIXIT
 // RUN: %clang_cc1 -fsyntax-only %t -x c++ -DFIXIT
-// RUN: not %clang_cc1 -fsyntax-only -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s -strict-whitespace
+// RUN: not %clang_cc1 -fsyntax-only -fdiagnostics-parseable-fixits -fno-diagnostics-show-line-numbers %s 2>&1 | FileCheck %s -strict-whitespace
 
 void test1() {
   int a[] = {0,1,1,2,3};
Index: clang/test/Parser/brackets.c
===
--- clang/test/Parser/brackets.c
+++ clang/test/Parser/brackets.c
@@ -2,7 +2,7 @@
 // RUN: cp %s %t
 // RUN: not %clang_cc1 -fixit %t -x c -DFIXIT
 // RUN: %clang_cc1 -fsyntax-only %t -x c -DFIXIT
-// RUN: not %clang_cc1 -fsyntax-only -fdiagnostics-parseable-fixits %s 2>&1 | FileCheck %s -strict-whitespace
+// RUN: not %clang_cc1 -fsyntax-only -fdiagnostics-parseable-fixits -fno-diagnostics-show-line-numbers %s 2>&1 | FileCheck %s -strict-whitespace
 
 void test1(void) {
   int a[] = {0,1,1,2,3};
Index: clang/test/Misc/wrong-encoding.c
=

[PATCH] D147307: [clang] Do not require GNUInlineAttr for inline builtins

2023-04-19 Thread serge via Phabricator via cfe-commits
serge-sans-paille added a comment.

In D147307#4279337 , @jyu2 wrote:

> This change seems cause assert:
>
> https://godbolt.org/z/z9G87Wr37

I can reproduce, investigating...


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D147307/new/

https://reviews.llvm.org/D147307

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148697: [clang-tidy] Handle more cases of functions which should always be noexcept

2023-04-19 Thread Carlos Galvez via Phabricator via cfe-commits
carlosgalvezp added a comment.

First of all thank you for the contribution! I had just a quick look so here's 
some very preliminary comments, will have more time to deeply review during the 
weekend:

- Unfortunately we cannot simply rename a check like this, since it breaks 
backwards compatibility. We need a period of 2 major releases where both the 
new check and the old check (marked as deprecated) co-exist, so people have 
enough time to port over. Only after those 2 releases can the old check be 
fully removed.
- Contrary to my comment on Github, I no longer think this should be a 
cppcoreguideline check, as it does **not** implement rule F.6. The enforcement 
required is to flag **all** functions (not just the special ones) that cannot 
throw and mark them as noexcept. That's a huge difference with a larger scope 
and impact in a codebase. I personally think that last bit is impractical in a 
real-world project, it would add too much noise.
- This check is also used as an alias to another guideline - HiCPP Rule 12.5.4, 
which strictly only covers move operators. Guideline checks  (HiCPP, 
CppCoreGuidelines) are stricter than the regular checks, and should only cover 
what they intend to cover - no more, no less.
- Special member functions are also copy constructors & assignments, yet those 
don't seem to be part of the rule?




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148697/new/

https://reviews.llvm.org/D148697

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D144269: [Analyzer] Show "taint originated here" note of alpha.security.taint.TaintPropagation checker at the correct place

2023-04-19 Thread Daniel Krupp via Phabricator via cfe-commits
dkrupp updated this revision to Diff 514973.
dkrupp marked an inline comment as done.
dkrupp added a comment.

- Implemented early return in getTaintedSymbols() when it is called by 
isTainted() for efficiency
- Fixed test incompatibility on Windows


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D144269/new/

https://reviews.llvm.org/D144269

Files:
  clang/include/clang/StaticAnalyzer/Checkers/Taint.h
  clang/include/clang/StaticAnalyzer/Core/BugReporter/CommonBugCategories.h
  clang/lib/StaticAnalyzer/Checkers/ArrayBoundCheckerV2.cpp
  clang/lib/StaticAnalyzer/Checkers/DivZeroChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/Taint.cpp
  clang/lib/StaticAnalyzer/Checkers/VLASizeChecker.cpp
  clang/lib/StaticAnalyzer/Core/CommonBugCategories.cpp
  clang/test/Analysis/taint-diagnostic-visitor.c
  clang/test/Analysis/taint-tester.c

Index: clang/test/Analysis/taint-tester.c
===
--- clang/test/Analysis/taint-tester.c
+++ clang/test/Analysis/taint-tester.c
@@ -122,7 +122,7 @@
   fscanf(pp, "%d", &ii);
   int jj = ii;// expected-warning + {{tainted}}
 
-  fscanf(p, "%d", &ii);
+  fscanf(p, "%d", &ii);// expected-warning + {{tainted}}
   int jj2 = ii;// expected-warning + {{tainted}}
 
   ii = 3;
Index: clang/test/Analysis/taint-diagnostic-visitor.c
===
--- clang/test/Analysis/taint-diagnostic-visitor.c
+++ clang/test/Analysis/taint-diagnostic-visitor.c
@@ -2,13 +2,24 @@
 
 // This file is for testing enhanced diagnostics produced by the GenericTaintChecker
 
+typedef __typeof(sizeof(int)) size_t;
+struct _IO_FILE;
+typedef struct _IO_FILE FILE;
+
 int scanf(const char *restrict format, ...);
 int system(const char *command);
+char* getenv( const char* env_var );
+size_t strlen( const char* str );
+void *malloc(size_t size );
+void free( void *ptr );
+char *fgets(char *str, int n, FILE *stream);
+FILE *stdin;
 
 void taintDiagnostic(void)
 {
   char buf[128];
   scanf("%s", buf); // expected-note {{Taint originated here}}
+// expected-note@-1 {{Taint propagated to the 2nd argument}}
   system(buf); // expected-warning {{Untrusted data is passed to a system call}} // expected-note {{Untrusted data is passed to a system call (CERT/STR02-C. Sanitize data passed to complex subsystems)}}
 }
 
@@ -16,6 +27,7 @@
   int index;
   int Array[] = {1, 2, 3, 4, 5};
   scanf("%d", &index); // expected-note {{Taint originated here}}
+   // expected-note@-1 {{Taint propagated to the 2nd argument}}
   return Array[index]; // expected-warning {{Out of bound memory access (index is tainted)}}
// expected-note@-1 {{Out of bound memory access (index is tainted)}}
 }
@@ -23,6 +35,7 @@
 int taintDiagnosticDivZero(int operand) {
   scanf("%d", &operand); // expected-note {{Value assigned to 'operand'}}
  // expected-note@-1 {{Taint originated here}}
+ // expected-note@-2 {{Taint propagated to the 2nd argument}}
   return 10 / operand; // expected-warning {{Division by a tainted value, possibly zero}}
// expected-note@-1 {{Division by a tainted value, possibly zero}}
 }
@@ -31,6 +44,71 @@
   int x;
   scanf("%d", &x); // expected-note {{Value assigned to 'x'}}
// expected-note@-1 {{Taint originated here}}
+   // expected-note@-2 {{Taint propagated to the 2nd argument}}
   int vla[x]; // expected-warning {{Declared variable-length array (VLA) has tainted size}}
   // expected-note@-1 {{Declared variable-length array (VLA) has tainted size}}
 }
+
+
+//Tests if the originated note is correctly placed even if the path is
+//propagating through variables and expressions
+char* taintDiagnosticPropagation(){
+  char *pathbuf;
+  char *pathlist=getenv("PATH"); // expected-note {{Taint originated here}}
+ // expected-note@-1 {{Taint propagated to the return value}}
+  if (pathlist){ // expected-note {{Assuming 'pathlist' is non-null}}
+	   // expected-note@-1 {{Taking true branch}}
+pathbuf=(char*) malloc(strlen(pathlist)+1); // expected-warning{{Untrusted data is used to specify the buffer size}}
+// expected-note@-1{{Untrusted data is used to specify the buffer size}}
+// expected-note@-2 {{Taint propagated to the return value}}
+return pathbuf;
+  }
+  return 0;
+}
+
+//Taint origin should be marked correctly even if there are multiple taint
+//sources in the function
+char* taintDiagnosticPropagation2(){
+  char *pathbuf;
+  char *user_env2=getenv("USER_ENV_VAR2");//unrelated taint source
+  char *pathlist=getenv("PATH"); // expected-note {{Taint originated here}}
+ // expected-note@-1 {{Taint 

[PATCH] D144269: [Analyzer] Show "taint originated here" note of alpha.security.taint.TaintPropagation checker at the correct place

2023-04-19 Thread Daniel Krupp via Phabricator via cfe-commits
dkrupp marked an inline comment as done.
dkrupp added a comment.

@steakhal  thanks for your review. All your remarks have been fixed.




Comment at: clang/lib/StaticAnalyzer/Checkers/Taint.cpp:147-150
 bool taint::isTainted(ProgramStateRef State, const Stmt *S,
   const LocationContext *LCtx, TaintTagType Kind) {
-  SVal val = State->getSVal(S, LCtx);
-  return isTainted(State, val, Kind);
+  return !getTaintedSymbols(State, S, LCtx, Kind).empty();
 }

steakhal wrote:
> TBH I'm not sure if I like that now we allocate unbounded amount of times 
> (because of `getTaintedSymbols()` is recursive and returns by value), where 
> we previously did not.
> 
> What we could possibly do is to compute the elements of this sequence lazily.
> I'm thinking of the `llvm::mapped_iterator`, but I'm not sure if it's 
> possible to have something like that as a return type as it might encode the 
> map function in the type or something like that.
> Anyway, I'm just saying that it would be nice to not do more than it's 
> necessary, and especially not allocate a lot of short-lived objects there.
> 
> Do you think there is a way to have the cake and eat it too?
> 
> ---
> 
> I did some investigation, and one could get pretty far in the implementation, 
> and maybe even complete it but it would be really complicated as of now. 
> Maybe we could revisit this subject when we have coroutines.
> 
> So, I would suggest to have two sets of APIs:
>  - the usual `isTainted(.) -> bool`
>  - and a `getTaintedSymbols(.) -> vector`
> The important point would be that the `isTainted()` version would not eagerly 
> collect all tainted sub-syms but return on finding the first one.
> While, the `getTaintedSymbols()` would collect eagerly all of them, as its 
> name suggests.
> 
> Imagine if `getTaintedSymbolsImpl()` had an extra flag like `bool 
> returnAfterFirstMatch`. This way `isTainted()` can call it like that. While 
> in the other case, the parameter would be `false`, and eagerly collect all 
> symbols.
> 
> This is probably the best of both worlds, as it prevents `isTainted` from 
> doing extra work and if we need to iterate over the tainted symbols, we 
> always iterate over all of them, so doing it lazily wouldn't gain us much in 
> that case anyway.
> As a bonus, the user-facing API would be self-descriptive.
> 
> WDYT?
Good idea. I implemented the early return option in getTaintedSymbols(). This 
is used now by the isTainted() function.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D144269/new/

https://reviews.llvm.org/D144269

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148658: [clang] Make access to submodules via `iterator_range`

2023-04-19 Thread Sviatoslav Osipov via Phabricator via cfe-commits
Stoorx updated this revision to Diff 514976.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148658/new/

https://reviews.llvm.org/D148658

Files:
  clang/include/clang/Basic/Module.h
  clang/lib/Basic/Module.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/Frontend/CompilerInstance.cpp
  clang/lib/Frontend/FrontendAction.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaCodeComplete.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp

Index: clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
===
--- clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
+++ clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
@@ -500,8 +500,7 @@
   // Submodule order depends on order of header includes for inferred submodules
   // we don't care about the exact order, so sort so that it's consistent across
   // TUs to improve sharing.
-  SmallVector Submodules(M->submodule_begin(),
- M->submodule_end());
+  SmallVector Submodules(M->submodules());
   llvm::stable_sort(Submodules, [](const Module *A, const Module *B) {
 return A->Name < B->Name;
   });
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -1903,18 +1903,16 @@
 SavedStrings.push_back(FilenameDup.data());
 
 HeaderFileInfoTrait::key_type Key = {
-  FilenameDup, *U.Size, IncludeTimestamps ? *U.ModTime : 0
-};
+FilenameDup, *U.Size, IncludeTimestamps ? *U.ModTime : 0};
 HeaderFileInfoTrait::data_type Data = {
-  Empty, {}, {M, ModuleMap::headerKindToRole(U.Kind)}
-};
+Empty, {}, {M, ModuleMap::headerKindToRole(U.Kind)}};
 // FIXME: Deal with cases where there are multiple unresolved header
 // directives in different submodules for the same header.
 Generator.insert(Key, Data, GeneratorTrait);
 ++NumHeaderSearchEntries;
   }
-
-  Worklist.append(M->submodule_begin(), M->submodule_end());
+  auto SubmodulesRange = M->submodules();
+  Worklist.append(SubmodulesRange.begin(), SubmodulesRange.end());
 }
   }
 
@@ -2701,9 +2699,8 @@
 /// given module).
 static unsigned getNumberOfModules(Module *Mod) {
   unsigned ChildModules = 0;
-  for (auto Sub = Mod->submodule_begin(), SubEnd = Mod->submodule_end();
-   Sub != SubEnd; ++Sub)
-ChildModules += getNumberOfModules(*Sub);
+  for (auto *Submodule : Mod->submodules())
+ChildModules += getNumberOfModules(Submodule);
 
   return ChildModules + 1;
 }
Index: clang/lib/Sema/SemaCodeComplete.cpp
===
--- clang/lib/Sema/SemaCodeComplete.cpp
+++ clang/lib/Sema/SemaCodeComplete.cpp
@@ -4309,15 +4309,12 @@
 /*IsInclusionDirective=*/false);
 // Enumerate submodules.
 if (Mod) {
-  for (Module::submodule_iterator Sub = Mod->submodule_begin(),
-  SubEnd = Mod->submodule_end();
-   Sub != SubEnd; ++Sub) {
-
+  for (auto *Submodule : Mod->submodules()) {
 Builder.AddTypedTextChunk(
-Builder.getAllocator().CopyString((*Sub)->Name));
+Builder.getAllocator().CopyString(Submodule->Name));
 Results.AddResult(Result(
 Builder.TakeString(), CCP_Declaration, CXCursor_ModuleImportDecl,
-(*Sub)->isAvailable() ? CXAvailability_Available
+Submodule->isAvailable() ? CXAvailability_Available
   : CXAvailability_NotAvailable));
   }
 }
Index: clang/lib/Sema/Sema.cpp
===
--- clang/lib/Sema/Sema.cpp
+++ clang/lib/Sema/Sema.cpp
@@ -1240,7 +1240,8 @@
 ModMap.resolveConflicts(Mod, /*Complain=*/false);
 
 // Queue the submodules, so their exports will also be resolved.
-Stack.append(Mod->submodule_begin(), Mod->submodule_end());
+auto SubmodulesRange = Mod->submodules();
+Stack.append(SubmodulesRange.begin(), SubmodulesRange.end());
   }
 }
 
Index: clang/lib/Frontend/FrontendAction.cpp
===
--- clang/lib/Frontend/FrontendAction.cpp
+++ clang/lib/Frontend/FrontendAction.cpp
@@ -429,11 +429,9 @@
   }
 
   // Recurse into submodules.
-  for (clang::Module::submodule_iterator Sub = Module->submodule_begin(),
-  SubEnd = Module->submodule_end();
-   Sub != SubEnd; ++Sub)
+  for (auto *Submodule : Module->submodules())
 if (std::error_code Err = collectModuleHeaderIncludes(
-LangOpts, FileMgr, Diag, ModMap, *Sub, Includes))
+LangOpts, FileMgr, Diag, ModMap, Submodule,

[PATCH] D148697: [clang-tidy] Handle more cases of functions which should always be noexcept

2023-04-19 Thread Carlos Galvez via Phabricator via cfe-commits
carlosgalvezp added inline comments.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines/noexcept-special-functions.rst:10
+`performance-noexcept-special-functions 
<../performance/noexcept-special-functions.html>`_
+for more information.

PiotrZSL wrote:
> Add link to implemented cpp core guidelines rules.
> Add reference 
> C.66: Make move operations noexcept
> C.83: For value-like types, consider providing a noexcept swap function.
> Same goes to operator == (C.86 rule)
> And hash C.89 rule
> 
Since there are different rules for different functions it's probably easier to 
maintain if we have 1 check per rule. Having a large check doing multiple 
things and multiple reasons for change can lead to more bugs, churn, renames, 
etc. What do you think?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148697/new/

https://reviews.llvm.org/D148697

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148723: [clang] Enforce internal linkage for inline builtin

2023-04-19 Thread serge via Phabricator via cfe-commits
serge-sans-paille created this revision.
serge-sans-paille added reviewers: jyu2, efriedma.
Herald added a project: All.
serge-sans-paille requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Otherwise we end up with link once odr because of the inline keyword, which 
translates to comdat in windows world. But we prune the body and that's 
inconsistent...
See https://godbolt.org/z/z9G87Wr37 for the original failing test case


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D148723

Files:
  clang/lib/AST/ASTContext.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/CodeGen/inline-builtin-comdat.c


Index: clang/test/CodeGen/inline-builtin-comdat.c
===
--- /dev/null
+++ clang/test/CodeGen/inline-builtin-comdat.c
@@ -0,0 +1,20 @@
+// RUN: %clang_cc1 -triple x86_64-windows -S -emit-llvm %s -o - | FileCheck %s
+// Make sure we don't generate definition for Inline Builtins on windows
+
+double __cdecl frexp( double _X, int* _Y);
+inline __attribute__((always_inline))  long double __cdecl frexpl( long double 
__x, int *__exp ) {
+  return (long double) frexp((double)__x, __exp );
+}
+
+long double pain(void)
+{
+long double f = 123.45;
+int i;
+long double f2 = frexpl(f, &i);
+return f2;
+}
+
+// CHECK-NOT: define{{.*}}@frexpl(
+// CHECK: define dso_local double @pain
+// CHECK:[[CALL_I:%.*]] = call double @frexp(double noundef [[TMP2]], ptr 
noundef [[TMP1]]) #[[ATTR3:[0-9]+]]
+// CHECK: declare dso_local double @frexp(double noundef, ptr noundef)
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -5189,9 +5189,10 @@
   if (D->hasAttr())
 return llvm::GlobalVariable::WeakAnyLinkage;
 
-  if (const auto *FD = D->getAsFunction())
+  if (const auto *FD = D->getAsFunction()) {
 if (FD->isMultiVersion() && Linkage == GVA_AvailableExternally)
   return llvm::GlobalVariable::LinkOnceAnyLinkage;
+  }
 
   // We are guaranteed to have a strong definition somewhere else,
   // so we can use available_externally linkage.
Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -11535,7 +11535,7 @@
 
 static GVALinkage basicGVALinkageForFunction(const ASTContext &Context,
  const FunctionDecl *FD) {
-  if (!FD->isExternallyVisible())
+  if (!FD->isExternallyVisible() || FD->isInlineBuiltinDeclaration())
 return GVA_Internal;
 
   // Non-user-provided functions get emitted as weak definitions with every


Index: clang/test/CodeGen/inline-builtin-comdat.c
===
--- /dev/null
+++ clang/test/CodeGen/inline-builtin-comdat.c
@@ -0,0 +1,20 @@
+// RUN: %clang_cc1 -triple x86_64-windows -S -emit-llvm %s -o - | FileCheck %s
+// Make sure we don't generate definition for Inline Builtins on windows
+
+double __cdecl frexp( double _X, int* _Y);
+inline __attribute__((always_inline))  long double __cdecl frexpl( long double __x, int *__exp ) {
+  return (long double) frexp((double)__x, __exp );
+}
+
+long double pain(void)
+{
+long double f = 123.45;
+int i;
+long double f2 = frexpl(f, &i);
+return f2;
+}
+
+// CHECK-NOT: define{{.*}}@frexpl(
+// CHECK: define dso_local double @pain
+// CHECK:[[CALL_I:%.*]] = call double @frexp(double noundef [[TMP2]], ptr noundef [[TMP1]]) #[[ATTR3:[0-9]+]]
+// CHECK: declare dso_local double @frexp(double noundef, ptr noundef)
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -5189,9 +5189,10 @@
   if (D->hasAttr())
 return llvm::GlobalVariable::WeakAnyLinkage;
 
-  if (const auto *FD = D->getAsFunction())
+  if (const auto *FD = D->getAsFunction()) {
 if (FD->isMultiVersion() && Linkage == GVA_AvailableExternally)
   return llvm::GlobalVariable::LinkOnceAnyLinkage;
+  }
 
   // We are guaranteed to have a strong definition somewhere else,
   // so we can use available_externally linkage.
Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -11535,7 +11535,7 @@
 
 static GVALinkage basicGVALinkageForFunction(const ASTContext &Context,
  const FunctionDecl *FD) {
-  if (!FD->isExternallyVisible())
+  if (!FD->isExternallyVisible() || FD->isInlineBuiltinDeclaration())
 return GVA_Internal;
 
   // Non-user-provided functions get emitted as weak definitions with every
___
cfe-commits mailing li

[PATCH] D148700: [clang] Add support for “regular” keyword attributes

2023-04-19 Thread Richard Sandiford via Phabricator via cfe-commits
rsandifo-arm updated this revision to Diff 514993.
rsandifo-arm added a comment.

Make AttrTokenKinds.inc use a new KEYWORD_ATTRIBUTE macro, rather than
using KEYWORD directly.  Move the #undef to the .inc file.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148700/new/

https://reviews.llvm.org/D148700

Files:
  clang-tools-extra/pseudo/lib/grammar/CMakeLists.txt
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttributeCommonInfo.h
  clang/include/clang/Basic/CMakeLists.txt
  clang/include/clang/Basic/TokenKinds.def
  clang/include/clang/Basic/TokenKinds.h
  clang/include/clang/Lex/Token.h
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaType.cpp
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/unittests/AST/AttrTest.cpp
  clang/utils/TableGen/ClangAttrEmitter.cpp
  clang/utils/TableGen/TableGen.cpp
  clang/utils/TableGen/TableGenBackends.h

Index: clang/utils/TableGen/TableGenBackends.h
===
--- clang/utils/TableGen/TableGenBackends.h
+++ clang/utils/TableGen/TableGenBackends.h
@@ -43,6 +43,8 @@
llvm::raw_ostream &OS);
 void EmitClangAttrPCHRead(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
 void EmitClangAttrPCHWrite(llvm::RecordKeeper &Records, llvm::raw_ostream &OS);
+void EmitClangAttrTokenKinds(llvm::RecordKeeper &Records,
+ llvm::raw_ostream &OS);
 void EmitClangAttrHasAttrImpl(llvm::RecordKeeper &Records,
   llvm::raw_ostream &OS);
 void EmitClangAttrSpellingListIndex(llvm::RecordKeeper &Records,
Index: clang/utils/TableGen/TableGen.cpp
===
--- clang/utils/TableGen/TableGen.cpp
+++ clang/utils/TableGen/TableGen.cpp
@@ -35,6 +35,7 @@
   GenClangAttrSubjectMatchRuleList,
   GenClangAttrPCHRead,
   GenClangAttrPCHWrite,
+  GenClangAttrTokenKinds,
   GenClangAttrHasAttributeImpl,
   GenClangAttrSpellingListIndex,
   GenClangAttrASTVisitor,
@@ -128,6 +129,8 @@
"Generate clang PCH attribute reader"),
 clEnumValN(GenClangAttrPCHWrite, "gen-clang-attr-pch-write",
"Generate clang PCH attribute writer"),
+clEnumValN(GenClangAttrTokenKinds, "gen-clang-attr-token-kinds",
+   "Generate a list of attribute-related clang tokens"),
 clEnumValN(GenClangAttrHasAttributeImpl,
"gen-clang-attr-has-attribute-impl",
"Generate a clang attribute spelling list"),
@@ -303,6 +306,9 @@
   case GenClangAttrPCHWrite:
 EmitClangAttrPCHWrite(Records, OS);
 break;
+  case GenClangAttrTokenKinds:
+EmitClangAttrTokenKinds(Records, OS);
+break;
   case GenClangAttrHasAttributeImpl:
 EmitClangAttrHasAttrImpl(Records, OS);
 break;
Index: clang/utils/TableGen/ClangAttrEmitter.cpp
===
--- clang/utils/TableGen/ClangAttrEmitter.cpp
+++ clang/utils/TableGen/ClangAttrEmitter.cpp
@@ -2378,6 +2378,11 @@
   OS << "#endif // CLANG_ATTR_ACCEPTS_EXPR_PACK\n\n";
 }
 
+static bool isRegularKeywordAttribute(const FlattenedSpelling &S) {
+  return (S.variety() == "Keyword" &&
+  !S.getSpellingRecord().getValueAsBit("HasOwnParseRules"));
+}
+
 static void emitFormInitializer(raw_ostream &OS,
 const FlattenedSpelling &Spelling,
 StringRef SpellingIndex) {
@@ -2385,7 +2390,9 @@
   (Spelling.variety() == "Keyword" && Spelling.name() == "alignas");
   OS << "{AttributeCommonInfo::AS_" << Spelling.variety() << ", "
  << SpellingIndex << ", " << (IsAlignas ? "true" : "false")
- << " /*IsAlignas*/}";
+ << " /*IsAlignas*/, "
+ << (isRegularKeywordAttribute(Spelling) ? "true" : "false")
+ << " /*IsRegularKeywordAttribute*/}";
 }
 
 static void emitAttributes(RecordKeeper &Records, raw_ostream &OS,
@@ -3404,6 +3411,26 @@
   OS << ".Default(0);\n";
 }
 
+// Emits the list of tokens for regular keyword attributes.
+void EmitClangAttrTokenKinds(RecordKeeper &Records, raw_ostream &OS) {
+  emitSourceFileHeader("A list of tokens generated from the attribute"
+   " definitions",
+   OS);
+  // Assume for now that the same token is not used in multiple regular
+  // keyword attributes.
+  for (auto *R : Records.getAllDerivedDefinitions("Attr"))
+for (const auto &S : GetFlattenedSpellings(*R))
+  if (isRegularKeywordAttribute(S)) {
+if (!R->getValueAsListOfDefs("Args").empty())
+  PrintError(R->getLoc(),
+ "RegularKeyword attributes with arguments are not "
+ "yet supported");
+OS << "KEYWORD_ATTRIBUTE("
+   << S.getSpellingRecord().getValueAsString("Name") << ")\n";
+  }
+  OS 

[PATCH] D140722: [OpenMP] Prefix outlined and reduction func names with original func's name

2023-04-19 Thread Itay Bookstein via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG029bfc311d4d: [OpenMP] Prefix outlined and reduction func 
names with original func's name (authored by nextsilicon-itay-bookstein).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D140722/new/

https://reviews.llvm.org/D140722

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/CodeGen/CGOpenMPRuntime.h
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.h
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/test/CodeGen/PowerPC/ppc64le-varargs-f128.c
  clang/test/CoverageMapping/openmp.c
  clang/test/OpenMP/amdgpu_target_with_aligned_attribute.c
  clang/test/OpenMP/bug54082.c
  clang/test/OpenMP/bug60602.cpp
  clang/test/OpenMP/cancel_codegen.cpp
  clang/test/OpenMP/cancellation_point_codegen.cpp
  clang/test/OpenMP/debug-info-complex-byval.cpp
  clang/test/OpenMP/debug-info-openmp-array.cpp
  clang/test/OpenMP/debug_threadprivate_copyin.c
  clang/test/OpenMP/declare_target_codegen_globalization.cpp
  clang/test/OpenMP/distribute_codegen.cpp
  clang/test/OpenMP/distribute_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_if_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_num_threads_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_private_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_proc_bind_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_reduction_task_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_if_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_num_threads_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_private_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_proc_bind_codegen.cpp
  clang/test/OpenMP/distribute_private_codegen.cpp
  clang/test/OpenMP/distribute_simd_codegen.cpp
  clang/test/OpenMP/distribute_simd_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_simd_private_codegen.cpp
  clang/test/OpenMP/distribute_simd_reduction_codegen.cpp
  clang/test/OpenMP/for_firstprivate_codegen.cpp
  clang/test/OpenMP/for_lastprivate_codegen.cpp
  clang/test/OpenMP/for_linear_codegen.cpp
  clang/test/OpenMP/for_private_codegen.cpp
  clang/test/OpenMP/for_reduction_codegen.cpp
  clang/test/OpenMP/for_reduction_codegen_UDR.cpp
  clang/test/OpenMP/for_reduction_task_codegen.cpp
  clang/test/OpenMP/function-attr.cpp
  clang/test/OpenMP/master_taskloop_in_reduction_codegen.cpp
  clang/test/OpenMP/master_taskloop_simd_in_reduction_codegen.cpp
  clang/test/OpenMP/metadirective_device_arch_codegen.cpp
  clang/test/OpenMP/metadirective_device_isa_codegen.cpp
  clang/test/OpenMP/metadirective_implementation_codegen.c
  clang/test/OpenMP/nested_loop_codegen.cpp
  clang/test/OpenMP/nvptx_SPMD_codegen.cpp
  clang/test/OpenMP/nvptx_allocate_codegen.cpp
  clang/test/OpenMP/nvptx_data_sharing.cpp
  clang/test/OpenMP/nvptx_distribute_parallel_generic_mode_codegen.cpp
  clang/test/OpenMP/nvptx_lambda_capturing.cpp
  clang/test/OpenMP/nvptx_multi_target_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_nested_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_parallel_for_codegen.cpp
  clang/test/OpenMP/nvptx_target_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_num_threads_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_proc_bind_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_reduction_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_reduction_codegen_tbaa_PR46146.cpp
  clang/test/OpenMP/nvptx_target_teams_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_codegen.cpp
  
clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_generic_mode_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_simd_codegen.cpp
  clang/test/OpenMP/nvptx_teams_codegen.cpp
  clang/test/OpenMP/nvptx_teams_reduction_codegen.cpp
  clang/test/OpenMP/omp_with_loop_pragma_instr_profile.c
  clang/test/OpenMP/openmp_win_codegen.cpp
  clang/test/OpenMP/outlined_artificial.c
  clang/test/OpenMP/parallel_codegen.cpp
  clang/test/OpenMP/parallel_copyin_codegen.cpp
  clang/test/OpenMP/parallel_copyin_combined_codegen.c
  clang/test/OpenMP/parallel_firstprivate_codegen.cpp
  clang/test/

[PATCH] D148700: [clang] Add support for “regular” keyword attributes

2023-04-19 Thread Richard Sandiford via Phabricator via cfe-commits
rsandifo-arm marked an inline comment as done.
rsandifo-arm added inline comments.



Comment at: clang/include/clang/Basic/TokenKinds.h:106
+#include "clang/Basic/AttrTokenKinds.inc"
+#undef KEYWORD
+  );

erichkeane wrote:
> Does AttrTokenKinds.inc not do this undef for you?  Most of our 
> tablegen'ed/.td files tend to...
> 
> Edit now that I've gone through the whole patch:
> 
> I see the inclusion into TokenKinds.def makes adding one a pain, but I 
> suggest instead making these be KEYWORD_ATTRIBUTE(...), with all the 
> 'fixings' that comes in TokenKinds.def (see the defines at the top), and then 
> including TokenKinds.def here instead.
Ah, yeah, that's neater, thanks.  It also means that the KEYALL can be moved to 
TokenKinds.def until such time (hopefully never) as it becomes necessary to 
vary it based on attribute.

Done in the updated version.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148700/new/

https://reviews.llvm.org/D148700

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148700: [clang] Add support for “regular” keyword attributes

2023-04-19 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

Generally ok with all of this, but want some time to think about it/give 
aaron/etc time to see it.




Comment at: clang/include/clang/Basic/TokenKinds.def:751
+// Keywords defined by Attr.td.
+#define KEYWORD_ATTRIBUTE(X) KEYWORD(X, KEYALL)
+#include "clang/Basic/AttrTokenKinds.inc"

Probably should be: `#ifndef KEYWORD_ATTRIBUTE` here.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148700/new/

https://reviews.llvm.org/D148700

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148658: [clang] Make access to submodules via `iterator_range`

2023-04-19 Thread Sviatoslav Osipov via Phabricator via cfe-commits
Stoorx updated this revision to Diff 515001.
Herald added a project: clang-tools-extra.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148658/new/

https://reviews.llvm.org/D148658

Files:
  clang-tools-extra/modularize/CoverageChecker.cpp
  clang-tools-extra/modularize/ModularizeUtilities.cpp
  clang/include/clang/Basic/Module.h
  clang/lib/Basic/Module.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/Frontend/CompilerInstance.cpp
  clang/lib/Frontend/FrontendAction.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaCodeComplete.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp

Index: clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
===
--- clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
+++ clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
@@ -500,8 +500,7 @@
   // Submodule order depends on order of header includes for inferred submodules
   // we don't care about the exact order, so sort so that it's consistent across
   // TUs to improve sharing.
-  SmallVector Submodules(M->submodule_begin(),
- M->submodule_end());
+  SmallVector Submodules(M->submodules());
   llvm::stable_sort(Submodules, [](const Module *A, const Module *B) {
 return A->Name < B->Name;
   });
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -1903,18 +1903,16 @@
 SavedStrings.push_back(FilenameDup.data());
 
 HeaderFileInfoTrait::key_type Key = {
-  FilenameDup, *U.Size, IncludeTimestamps ? *U.ModTime : 0
-};
+FilenameDup, *U.Size, IncludeTimestamps ? *U.ModTime : 0};
 HeaderFileInfoTrait::data_type Data = {
-  Empty, {}, {M, ModuleMap::headerKindToRole(U.Kind)}
-};
+Empty, {}, {M, ModuleMap::headerKindToRole(U.Kind)}};
 // FIXME: Deal with cases where there are multiple unresolved header
 // directives in different submodules for the same header.
 Generator.insert(Key, Data, GeneratorTrait);
 ++NumHeaderSearchEntries;
   }
-
-  Worklist.append(M->submodule_begin(), M->submodule_end());
+  auto SubmodulesRange = M->submodules();
+  Worklist.append(SubmodulesRange.begin(), SubmodulesRange.end());
 }
   }
 
@@ -2701,9 +2699,8 @@
 /// given module).
 static unsigned getNumberOfModules(Module *Mod) {
   unsigned ChildModules = 0;
-  for (auto Sub = Mod->submodule_begin(), SubEnd = Mod->submodule_end();
-   Sub != SubEnd; ++Sub)
-ChildModules += getNumberOfModules(*Sub);
+  for (auto *Submodule : Mod->submodules())
+ChildModules += getNumberOfModules(Submodule);
 
   return ChildModules + 1;
 }
Index: clang/lib/Sema/SemaCodeComplete.cpp
===
--- clang/lib/Sema/SemaCodeComplete.cpp
+++ clang/lib/Sema/SemaCodeComplete.cpp
@@ -4309,15 +4309,12 @@
 /*IsInclusionDirective=*/false);
 // Enumerate submodules.
 if (Mod) {
-  for (Module::submodule_iterator Sub = Mod->submodule_begin(),
-  SubEnd = Mod->submodule_end();
-   Sub != SubEnd; ++Sub) {
-
+  for (auto *Submodule : Mod->submodules()) {
 Builder.AddTypedTextChunk(
-Builder.getAllocator().CopyString((*Sub)->Name));
+Builder.getAllocator().CopyString(Submodule->Name));
 Results.AddResult(Result(
 Builder.TakeString(), CCP_Declaration, CXCursor_ModuleImportDecl,
-(*Sub)->isAvailable() ? CXAvailability_Available
+Submodule->isAvailable() ? CXAvailability_Available
   : CXAvailability_NotAvailable));
   }
 }
Index: clang/lib/Sema/Sema.cpp
===
--- clang/lib/Sema/Sema.cpp
+++ clang/lib/Sema/Sema.cpp
@@ -1240,7 +1240,8 @@
 ModMap.resolveConflicts(Mod, /*Complain=*/false);
 
 // Queue the submodules, so their exports will also be resolved.
-Stack.append(Mod->submodule_begin(), Mod->submodule_end());
+auto SubmodulesRange = Mod->submodules();
+Stack.append(SubmodulesRange.begin(), SubmodulesRange.end());
   }
 }
 
Index: clang/lib/Frontend/FrontendAction.cpp
===
--- clang/lib/Frontend/FrontendAction.cpp
+++ clang/lib/Frontend/FrontendAction.cpp
@@ -429,11 +429,9 @@
   }
 
   // Recurse into submodules.
-  for (clang::Module::submodule_iterator Sub = Module->submodule_begin(),
-  SubEnd = Module->submodule_end();
-   Sub != SubEnd; ++Sub)
+  for (auto *Submodule : Module->submodules())
 if (std::error_code Err =

[clang] 5ddcef2 - [Headers][doc] Add/revise MONITOR/MWAIT descriptions

2023-04-19 Thread Paul Robinson via cfe-commits

Author: Paul Robinson
Date: 2023-04-19T09:50:15-07:00
New Revision: 5ddcef2ad3db5aa6e20a2e50e7799816c736e785

URL: 
https://github.com/llvm/llvm-project/commit/5ddcef2ad3db5aa6e20a2e50e7799816c736e785
DIFF: 
https://github.com/llvm/llvm-project/commit/5ddcef2ad3db5aa6e20a2e50e7799816c736e785.diff

LOG: [Headers][doc] Add/revise MONITOR/MWAIT descriptions

Differential Revision: https://reviews.llvm.org/D148653

Added: 


Modified: 
clang/lib/Headers/mwaitxintrin.h
clang/lib/Headers/pmmintrin.h

Removed: 




diff  --git a/clang/lib/Headers/mwaitxintrin.h 
b/clang/lib/Headers/mwaitxintrin.h
index ed485380af795..4d51892ec234a 100644
--- a/clang/lib/Headers/mwaitxintrin.h
+++ b/clang/lib/Headers/mwaitxintrin.h
@@ -16,12 +16,41 @@
 
 /* Define the default attributes for the functions in this file. */
 #define __DEFAULT_FN_ATTRS __attribute__((__always_inline__, __nodebug__,  
__target__("mwaitx")))
+
+/// Establishes a linear address memory range to be monitored and puts
+///the processor in the monitor event pending state. Data stored in the
+///monitored address range causes the processor to exit the pending state.
+///
+/// \headerfile 
+///
+/// This intrinsic corresponds to the \c MONITORX instruction.
+///
+/// \param __p
+///The memory range to be monitored. The size of the range is determined by
+///CPUID function _0005h.
+/// \param __extensions
+///Optional extensions for the monitoring state.
+/// \param __hints
+///Optional hints for the monitoring state.
 static __inline__ void __DEFAULT_FN_ATTRS
 _mm_monitorx(void * __p, unsigned __extensions, unsigned __hints)
 {
   __builtin_ia32_monitorx(__p, __extensions, __hints);
 }
 
+/// Used with the \c MONITORX instruction to wait while the processor is in
+///the monitor event pending state. Data stored in the monitored address
+///range causes the processor to exit the pending state.
+///
+/// \headerfile 
+///
+/// This intrinsic corresponds to the \c MWAITX instruction.
+///
+/// \param __extensions
+///Optional extensions for the monitoring state, which can vary by
+///processor.
+/// \param __hints
+///Optional hints for the monitoring state, which can vary by processor.
 static __inline__ void __DEFAULT_FN_ATTRS
 _mm_mwaitx(unsigned __extensions, unsigned __hints, unsigned __clock)
 {

diff  --git a/clang/lib/Headers/pmmintrin.h b/clang/lib/Headers/pmmintrin.h
index ee660e95d2744..ce06695558e61 100644
--- a/clang/lib/Headers/pmmintrin.h
+++ b/clang/lib/Headers/pmmintrin.h
@@ -253,9 +253,12 @@ _mm_movedup_pd(__m128d __a)
 ///the processor in the monitor event pending state. Data stored in the
 ///monitored address range causes the processor to exit the pending state.
 ///
+/// The \c MONITOR instruction can be used in kernel mode, and in other modes
+/// if MSR  C001_0015h[MonMwaitUserEn]  is set.
+///
 /// \headerfile 
 ///
-/// This intrinsic corresponds to the  MONITOR  instruction.
+/// This intrinsic corresponds to the \c MONITOR instruction.
 ///
 /// \param __p
 ///The memory range to be monitored. The size of the range is determined by
@@ -270,19 +273,22 @@ _mm_monitor(void const *__p, unsigned __extensions, 
unsigned __hints)
   __builtin_ia32_monitor(__p, __extensions, __hints);
 }
 
-/// Used with the MONITOR instruction to wait while the processor is in
+/// Used with the \c MONITOR instruction to wait while the processor is in
 ///the monitor event pending state. Data stored in the monitored address
 ///range causes the processor to exit the pending state.
 ///
+/// The \c MWAIT instruction can be used in kernel mode, and in other modes if
+/// MSR  C001_0015h[MonMwaitUserEn]  is set.
+///
 /// \headerfile 
 ///
-/// This intrinsic corresponds to the  MWAIT  instruction.
+/// This intrinsic corresponds to the \c MWAIT instruction.
 ///
 /// \param __extensions
-///Optional extensions for the monitoring state, which may vary by
+///Optional extensions for the monitoring state, which can vary by
 ///processor.
 /// \param __hints
-///Optional hints for the monitoring state, which may vary by processor.
+///Optional hints for the monitoring state, which can vary by processor.
 static __inline__ void __DEFAULT_FN_ATTRS
 _mm_mwait(unsigned __extensions, unsigned __hints)
 {



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148653: [Header][doc] Add/revise MONITOR/MWAIT[X] descriptions

2023-04-19 Thread Paul Robinson via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG5ddcef2ad3db: [Headers][doc] Add/revise MONITOR/MWAIT 
descriptions (authored by probinson).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148653/new/

https://reviews.llvm.org/D148653

Files:
  clang/lib/Headers/mwaitxintrin.h
  clang/lib/Headers/pmmintrin.h


Index: clang/lib/Headers/pmmintrin.h
===
--- clang/lib/Headers/pmmintrin.h
+++ clang/lib/Headers/pmmintrin.h
@@ -253,9 +253,12 @@
 ///the processor in the monitor event pending state. Data stored in the
 ///monitored address range causes the processor to exit the pending state.
 ///
+/// The \c MONITOR instruction can be used in kernel mode, and in other modes
+/// if MSR  C001_0015h[MonMwaitUserEn]  is set.
+///
 /// \headerfile 
 ///
-/// This intrinsic corresponds to the  MONITOR  instruction.
+/// This intrinsic corresponds to the \c MONITOR instruction.
 ///
 /// \param __p
 ///The memory range to be monitored. The size of the range is determined by
@@ -270,19 +273,22 @@
   __builtin_ia32_monitor(__p, __extensions, __hints);
 }
 
-/// Used with the MONITOR instruction to wait while the processor is in
+/// Used with the \c MONITOR instruction to wait while the processor is in
 ///the monitor event pending state. Data stored in the monitored address
 ///range causes the processor to exit the pending state.
 ///
+/// The \c MWAIT instruction can be used in kernel mode, and in other modes if
+/// MSR  C001_0015h[MonMwaitUserEn]  is set.
+///
 /// \headerfile 
 ///
-/// This intrinsic corresponds to the  MWAIT  instruction.
+/// This intrinsic corresponds to the \c MWAIT instruction.
 ///
 /// \param __extensions
-///Optional extensions for the monitoring state, which may vary by
+///Optional extensions for the monitoring state, which can vary by
 ///processor.
 /// \param __hints
-///Optional hints for the monitoring state, which may vary by processor.
+///Optional hints for the monitoring state, which can vary by processor.
 static __inline__ void __DEFAULT_FN_ATTRS
 _mm_mwait(unsigned __extensions, unsigned __hints)
 {
Index: clang/lib/Headers/mwaitxintrin.h
===
--- clang/lib/Headers/mwaitxintrin.h
+++ clang/lib/Headers/mwaitxintrin.h
@@ -16,12 +16,41 @@
 
 /* Define the default attributes for the functions in this file. */
 #define __DEFAULT_FN_ATTRS __attribute__((__always_inline__, __nodebug__,  
__target__("mwaitx")))
+
+/// Establishes a linear address memory range to be monitored and puts
+///the processor in the monitor event pending state. Data stored in the
+///monitored address range causes the processor to exit the pending state.
+///
+/// \headerfile 
+///
+/// This intrinsic corresponds to the \c MONITORX instruction.
+///
+/// \param __p
+///The memory range to be monitored. The size of the range is determined by
+///CPUID function _0005h.
+/// \param __extensions
+///Optional extensions for the monitoring state.
+/// \param __hints
+///Optional hints for the monitoring state.
 static __inline__ void __DEFAULT_FN_ATTRS
 _mm_monitorx(void * __p, unsigned __extensions, unsigned __hints)
 {
   __builtin_ia32_monitorx(__p, __extensions, __hints);
 }
 
+/// Used with the \c MONITORX instruction to wait while the processor is in
+///the monitor event pending state. Data stored in the monitored address
+///range causes the processor to exit the pending state.
+///
+/// \headerfile 
+///
+/// This intrinsic corresponds to the \c MWAITX instruction.
+///
+/// \param __extensions
+///Optional extensions for the monitoring state, which can vary by
+///processor.
+/// \param __hints
+///Optional hints for the monitoring state, which can vary by processor.
 static __inline__ void __DEFAULT_FN_ATTRS
 _mm_mwaitx(unsigned __extensions, unsigned __hints, unsigned __clock)
 {


Index: clang/lib/Headers/pmmintrin.h
===
--- clang/lib/Headers/pmmintrin.h
+++ clang/lib/Headers/pmmintrin.h
@@ -253,9 +253,12 @@
 ///the processor in the monitor event pending state. Data stored in the
 ///monitored address range causes the processor to exit the pending state.
 ///
+/// The \c MONITOR instruction can be used in kernel mode, and in other modes
+/// if MSR  C001_0015h[MonMwaitUserEn]  is set.
+///
 /// \headerfile 
 ///
-/// This intrinsic corresponds to the  MONITOR  instruction.
+/// This intrinsic corresponds to the \c MONITOR instruction.
 ///
 /// \param __p
 ///The memory range to be monitored. The size of the range is determined by
@@ -270,19 +273,22 @@
   __builtin_ia32_monitor(__p, __extensions, __hints);
 }
 
-/// Used with the MONITOR inst

[PATCH] D146764: [clang] Make predefined expressions string literals under -fms-extensions

2023-04-19 Thread Arthur Eubanks via Phabricator via cfe-commits
aeubanks added a comment.

ping


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D146764/new/

https://reviews.llvm.org/D146764

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 1242644 - [Header][doc] Tweak wording for MWAIT[X] intrinsics

2023-04-19 Thread Paul Robinson via cfe-commits

Author: Paul Robinson
Date: 2023-04-19T09:57:33-07:00
New Revision: 12426441ea2a9fdfcf6121a0061fa91d6112781d

URL: 
https://github.com/llvm/llvm-project/commit/12426441ea2a9fdfcf6121a0061fa91d6112781d
DIFF: 
https://github.com/llvm/llvm-project/commit/12426441ea2a9fdfcf6121a0061fa91d6112781d.diff

LOG: [Header][doc] Tweak wording for MWAIT[X] intrinsics

Added: 


Modified: 
clang/lib/Headers/mwaitxintrin.h
clang/lib/Headers/pmmintrin.h

Removed: 




diff  --git a/clang/lib/Headers/mwaitxintrin.h 
b/clang/lib/Headers/mwaitxintrin.h
index 4d51892ec234a..65f427105b41b 100644
--- a/clang/lib/Headers/mwaitxintrin.h
+++ b/clang/lib/Headers/mwaitxintrin.h
@@ -40,7 +40,7 @@ _mm_monitorx(void * __p, unsigned __extensions, unsigned 
__hints)
 
 /// Used with the \c MONITORX instruction to wait while the processor is in
 ///the monitor event pending state. Data stored in the monitored address
-///range causes the processor to exit the pending state.
+///range, or an interrupt, causes the processor to exit the pending state.
 ///
 /// \headerfile 
 ///

diff  --git a/clang/lib/Headers/pmmintrin.h b/clang/lib/Headers/pmmintrin.h
index ce06695558e61..203c0aa0f8c67 100644
--- a/clang/lib/Headers/pmmintrin.h
+++ b/clang/lib/Headers/pmmintrin.h
@@ -275,7 +275,7 @@ _mm_monitor(void const *__p, unsigned __extensions, 
unsigned __hints)
 
 /// Used with the \c MONITOR instruction to wait while the processor is in
 ///the monitor event pending state. Data stored in the monitored address
-///range causes the processor to exit the pending state.
+///range, or an interrupt, causes the processor to exit the pending state.
 ///
 /// The \c MWAIT instruction can be used in kernel mode, and in other modes if
 /// MSR  C001_0015h[MonMwaitUserEn]  is set.



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148723: [clang] Enforce internal linkage for inline builtin

2023-04-19 Thread Jennifer Yu via Phabricator via cfe-commits
jyu2 added a comment.

Hi @serge-sans-paille, thanks for the fix.  Could you please also try some test 
with dllimport/dllexport with inline function?  Jennifer




Comment at: clang/lib/AST/ASTContext.cpp:11538
  const FunctionDecl *FD) {
-  if (!FD->isExternallyVisible())
+  if (!FD->isExternallyVisible() || FD->isInlineBuiltinDeclaration())
 return GVA_Internal;

How about __declspec(dllimpor/dllexprort) __forceinline fexprl?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148723/new/

https://reviews.llvm.org/D148723

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148653: [Header][doc] Add/revise MONITOR/MWAIT[X] descriptions

2023-04-19 Thread Paul Robinson via Phabricator via cfe-commits
probinson added inline comments.



Comment at: clang/lib/Headers/pmmintrin.h:278
 ///the monitor event pending state. Data stored in the monitored address
 ///range causes the processor to exit the pending state.
 ///

goldstein.w.n wrote:
> interrupts too. Might as well add that if updating the comments.
Ah, sorry missed this comment before I pushed. Updated in rG12426441




Comment at: clang/lib/Headers/pmmintrin.h:291
 /// \param __hints
-///Optional hints for the monitoring state, which may vary by processor.
+///Optional hints for the monitoring state, which can vary by processor.
 static __inline__ void __DEFAULT_FN_ATTRS

goldstein.w.n wrote:
> out of curiosity, why "may" -> "can"?
That was on the advice of my tech writer.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148653/new/

https://reviews.llvm.org/D148653

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148723: [clang] Enforce internal linkage for inline builtin

2023-04-19 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added inline comments.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:5192
 
-  if (const auto *FD = D->getAsFunction())
+  if (const auto *FD = D->getAsFunction()) {
 if (FD->isMultiVersion() && Linkage == GVA_AvailableExternally)

Is this an unrelated change?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148723/new/

https://reviews.llvm.org/D148723

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 33e2161 - [clang] makes `__is_trivially_equality_comparable` available as a struct

2023-04-19 Thread Christopher Di Bella via cfe-commits

Author: Christopher Di Bella
Date: 2023-04-19T17:16:40Z
New Revision: 33e21610f9cd40e991b7cac107ba190678970f81

URL: 
https://github.com/llvm/llvm-project/commit/33e21610f9cd40e991b7cac107ba190678970f81
DIFF: 
https://github.com/llvm/llvm-project/commit/33e21610f9cd40e991b7cac107ba190678970f81.diff

LOG: [clang] makes `__is_trivially_equality_comparable` available as a struct

Since this was originally a name in library, it needs an escape hatch
for versions of Clang that are slightly out-of-sync with libc++.

Differential Revision: https://reviews.llvm.org/D148677

Added: 
clang/test/SemaCXX/libcxx_is_trivially_equality_comparable_hack.cpp

Modified: 
clang/lib/Parse/ParseDeclCXX.cpp

Removed: 




diff  --git a/clang/lib/Parse/ParseDeclCXX.cpp 
b/clang/lib/Parse/ParseDeclCXX.cpp
index 638cc7604066a..45b0a1a5f8669 100644
--- a/clang/lib/Parse/ParseDeclCXX.cpp
+++ b/clang/lib/Parse/ParseDeclCXX.cpp
@@ -1622,6 +1622,7 @@ void Parser::ParseClassSpecifier(tok::TokenKind 
TagTokKind,
   tok::kw___is_signed,
   tok::kw___is_standard_layout,
   tok::kw___is_trivial,
+  tok::kw___is_trivially_equality_comparable,
   tok::kw___is_trivially_assignable,
   tok::kw___is_trivially_constructible,
   tok::kw___is_trivially_copyable,

diff  --git 
a/clang/test/SemaCXX/libcxx_is_trivially_equality_comparable_hack.cpp 
b/clang/test/SemaCXX/libcxx_is_trivially_equality_comparable_hack.cpp
new file mode 100644
index 0..b236ce09b2970
--- /dev/null
+++ b/clang/test/SemaCXX/libcxx_is_trivially_equality_comparable_hack.cpp
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify 
-std=gnu++20 -fms-extensions -Wno-microsoft %s
+// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify 
-std=gnu++2b -fms-extensions -Wno-microsoft %s
+
+template 
+struct Same {
+  static constexpr auto value = __is_same(T, U);
+};
+
+template 
+struct __is_trivially_equality_comparable { // expected-warning{{keyword 
'__is_trivially_equality_comparable' will be made available as an identifier 
for the remainder of the translation unit}}
+  using type = T;
+};
+
+using A = Same<__is_trivially_equality_comparable::type, 
__is_trivially_equality_comparable::type>;



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148677: [clang] makes `__is_trivially_equality_comparable` available as a struct

2023-04-19 Thread Christopher Di Bella via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG33e21610f9cd: [clang] makes 
`__is_trivially_equality_comparable` available as a struct (authored by cjdb).

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148677/new/

https://reviews.llvm.org/D148677

Files:
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/test/SemaCXX/libcxx_is_trivially_equality_comparable_hack.cpp


Index: clang/test/SemaCXX/libcxx_is_trivially_equality_comparable_hack.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/libcxx_is_trivially_equality_comparable_hack.cpp
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify 
-std=gnu++20 -fms-extensions -Wno-microsoft %s
+// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify 
-std=gnu++2b -fms-extensions -Wno-microsoft %s
+
+template 
+struct Same {
+  static constexpr auto value = __is_same(T, U);
+};
+
+template 
+struct __is_trivially_equality_comparable { // expected-warning{{keyword 
'__is_trivially_equality_comparable' will be made available as an identifier 
for the remainder of the translation unit}}
+  using type = T;
+};
+
+using A = Same<__is_trivially_equality_comparable::type, 
__is_trivially_equality_comparable::type>;
Index: clang/lib/Parse/ParseDeclCXX.cpp
===
--- clang/lib/Parse/ParseDeclCXX.cpp
+++ clang/lib/Parse/ParseDeclCXX.cpp
@@ -1622,6 +1622,7 @@
   tok::kw___is_signed,
   tok::kw___is_standard_layout,
   tok::kw___is_trivial,
+  tok::kw___is_trivially_equality_comparable,
   tok::kw___is_trivially_assignable,
   tok::kw___is_trivially_constructible,
   tok::kw___is_trivially_copyable,


Index: clang/test/SemaCXX/libcxx_is_trivially_equality_comparable_hack.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/libcxx_is_trivially_equality_comparable_hack.cpp
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++20 -fms-extensions -Wno-microsoft %s
+// RUN: %clang_cc1 -triple x86_64-apple-darwin10 -fsyntax-only -verify -std=gnu++2b -fms-extensions -Wno-microsoft %s
+
+template 
+struct Same {
+  static constexpr auto value = __is_same(T, U);
+};
+
+template 
+struct __is_trivially_equality_comparable { // expected-warning{{keyword '__is_trivially_equality_comparable' will be made available as an identifier for the remainder of the translation unit}}
+  using type = T;
+};
+
+using A = Same<__is_trivially_equality_comparable::type, __is_trivially_equality_comparable::type>;
Index: clang/lib/Parse/ParseDeclCXX.cpp
===
--- clang/lib/Parse/ParseDeclCXX.cpp
+++ clang/lib/Parse/ParseDeclCXX.cpp
@@ -1622,6 +1622,7 @@
   tok::kw___is_signed,
   tok::kw___is_standard_layout,
   tok::kw___is_trivial,
+  tok::kw___is_trivially_equality_comparable,
   tok::kw___is_trivially_assignable,
   tok::kw___is_trivially_constructible,
   tok::kw___is_trivially_copyable,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148723: [clang] Enforce internal linkage for inline builtin

2023-04-19 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added a comment.

This seems like a weird way to fix this.  The point of an "inline builtin" is 
that the inline function is actually the original function; it's just the 
inline implementation is only used in limited circumstances (in particular, it 
can't be used recursively).  Changing the linkage could have unexpected 
side-effects.

Maybe it makes sense to restore some form of the "GNUInlineAttr" check in 
isInlineBuiltinDeclaration.  But instead of actually checking for the 
attribute, check that the function would be emitted with available_externally 
linkage.  So "inline builtins" don't exist on Windows because inline functions 
are linkonce_odr.  But we still detect builtins that are declared `inline` 
instead of `extern inline __attribute((gnu_inline))`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148723/new/

https://reviews.llvm.org/D148723

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148658: [clang] Make access to submodules via `iterator_range`

2023-04-19 Thread Sviatoslav Osipov via Phabricator via cfe-commits
Stoorx updated this revision to Diff 515016.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148658/new/

https://reviews.llvm.org/D148658

Files:
  clang-tools-extra/modularize/CoverageChecker.cpp
  clang-tools-extra/modularize/ModularizeUtilities.cpp
  clang/include/clang/Basic/Module.h
  clang/lib/Basic/Module.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/Frontend/CompilerInstance.cpp
  clang/lib/Frontend/FrontendAction.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaCodeComplete.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp

Index: clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
===
--- clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
+++ clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
@@ -500,8 +500,7 @@
   // Submodule order depends on order of header includes for inferred submodules
   // we don't care about the exact order, so sort so that it's consistent across
   // TUs to improve sharing.
-  SmallVector Submodules(M->submodule_begin(),
- M->submodule_end());
+  SmallVector Submodules(M->submodules());
   llvm::stable_sort(Submodules, [](const Module *A, const Module *B) {
 return A->Name < B->Name;
   });
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -1903,18 +1903,16 @@
 SavedStrings.push_back(FilenameDup.data());
 
 HeaderFileInfoTrait::key_type Key = {
-  FilenameDup, *U.Size, IncludeTimestamps ? *U.ModTime : 0
-};
+FilenameDup, *U.Size, IncludeTimestamps ? *U.ModTime : 0};
 HeaderFileInfoTrait::data_type Data = {
-  Empty, {}, {M, ModuleMap::headerKindToRole(U.Kind)}
-};
+Empty, {}, {M, ModuleMap::headerKindToRole(U.Kind)}};
 // FIXME: Deal with cases where there are multiple unresolved header
 // directives in different submodules for the same header.
 Generator.insert(Key, Data, GeneratorTrait);
 ++NumHeaderSearchEntries;
   }
-
-  Worklist.append(M->submodule_begin(), M->submodule_end());
+  auto SubmodulesRange = M->submodules();
+  Worklist.append(SubmodulesRange.begin(), SubmodulesRange.end());
 }
   }
 
@@ -2701,9 +2699,8 @@
 /// given module).
 static unsigned getNumberOfModules(Module *Mod) {
   unsigned ChildModules = 0;
-  for (auto Sub = Mod->submodule_begin(), SubEnd = Mod->submodule_end();
-   Sub != SubEnd; ++Sub)
-ChildModules += getNumberOfModules(*Sub);
+  for (auto *Submodule : Mod->submodules())
+ChildModules += getNumberOfModules(Submodule);
 
   return ChildModules + 1;
 }
Index: clang/lib/Sema/SemaCodeComplete.cpp
===
--- clang/lib/Sema/SemaCodeComplete.cpp
+++ clang/lib/Sema/SemaCodeComplete.cpp
@@ -4309,16 +4309,13 @@
 /*IsInclusionDirective=*/false);
 // Enumerate submodules.
 if (Mod) {
-  for (Module::submodule_iterator Sub = Mod->submodule_begin(),
-  SubEnd = Mod->submodule_end();
-   Sub != SubEnd; ++Sub) {
-
+  for (auto *Submodule : Mod->submodules()) {
 Builder.AddTypedTextChunk(
-Builder.getAllocator().CopyString((*Sub)->Name));
+Builder.getAllocator().CopyString(Submodule->Name));
 Results.AddResult(Result(
 Builder.TakeString(), CCP_Declaration, CXCursor_ModuleImportDecl,
-(*Sub)->isAvailable() ? CXAvailability_Available
-  : CXAvailability_NotAvailable));
+Submodule->isAvailable() ? CXAvailability_Available
+ : CXAvailability_NotAvailable));
   }
 }
   }
Index: clang/lib/Sema/Sema.cpp
===
--- clang/lib/Sema/Sema.cpp
+++ clang/lib/Sema/Sema.cpp
@@ -1240,7 +1240,8 @@
 ModMap.resolveConflicts(Mod, /*Complain=*/false);
 
 // Queue the submodules, so their exports will also be resolved.
-Stack.append(Mod->submodule_begin(), Mod->submodule_end());
+auto SubmodulesRange = Mod->submodules();
+Stack.append(SubmodulesRange.begin(), SubmodulesRange.end());
   }
 }
 
Index: clang/lib/Frontend/FrontendAction.cpp
===
--- clang/lib/Frontend/FrontendAction.cpp
+++ clang/lib/Frontend/FrontendAction.cpp
@@ -429,11 +429,9 @@
   }
 
   // Recurse into submodules.
-  for (clang::Module::submodule_iterator Sub = Module->submodule_begin(),
-  SubEnd = Module->submodule_end();
-   Sub != SubEnd; ++Sub)
+  for (auto *Submodule : Module->submodules(

[PATCH] D146987: [Assignment Tracking] Enable by default

2023-04-19 Thread Paul Kirth via Phabricator via cfe-commits
paulkirth added a comment.

I think we may have an issue due to this. I'm basing that on the blamelist, but 
I'm still bisecting our build, which may take some time to confirm. Can you 
take a look, and revert if it's not a quick fix?

  FAILED: obj/third_party/mesa/src/compiler/nir/nir.nir_opt_uniform_atomics.c.o
  ../../../recipe_cleanup/clanghgeznbv_/bin/clang -MD -MF 
obj/third_party/mesa/src/compiler/nir/nir.nir_opt_uniform_atomics.c.o.d 
-D_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS -D_LIBCPP_REMOVE_TRANSITIVE_INCLUDES 
-DNDEBUG=1 -D_LIBCPP_ENABLE_THREAD_SAFETY_ANNOTATIONS=1 -DSTDC_HEADERS=1 
-DHAVE_ENDIAN_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAV...
  clang: llvm/lib/IR/IntrinsicInst.cpp:140: void 
llvm::DbgVariableIntrinsic::replaceVariableLocationOp(Value *, Value *): 
Assertion `DbgAssignAddrReplaced && "OldValue must be dbg.assign addr if unused 
in DIArgList"' failed.
  PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ 
and include the crash backtrace, preprocessed source, and associated run script.
  Stack dump:
  0.Program arguments: ../../../recipe_cleanup/clanghgeznbv_/bin/clang -MD 
-MF obj/third_party/mesa/src/compiler/nir/nir.nir_opt_uniform_atomics.c.o.d 
-D_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS -D_LIBCPP_REMOVE_TRANSITIVE_INCLUDES 
-DNDEBUG=1 -D_LIBCPP_ENABLE_THREAD_SAFETY_ANNOTATIONS=1 -DSTDC_HEADERS=1 
-DHAVE_ENDIAN_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 
-DHAVE_STRING_H=1 -...
  1. parser at end of file
  2.Optimizer
  #0 0x5588b5bbe168 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) 
(../../../recipe_cleanup/clanghgeznbv_/bin/clang+0x7fc2168)
  clang: error: clang frontend command failed with exit code 134 (use -v to see 
invocation)
  Fuchsia clang version 17.0.0 (https://llvm.googlesource.com/llvm-project 
4bb64daf34aa3463786f531b5b42d13ab5f47869)
  Target: x86_64-unknown-fuchsia
  Thread model: posix
  InstalledDir: ../../../recipe_cleanup/clanghgeznbv_/bin
  clang: note: diagnostic msg:
  
  
  PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
  Preprocessed source(s) and associated run script(s) are located at:
  clang: note: diagnostic msg: 
clang-crashreports/nir_opt_uniform_atomics-73fdef.c
  clang: note: diagnostic msg: 
clang-crashreports/nir_opt_uniform_atomics-73fdef.sh
  clang: note: diagnostic msg:
  
  

Bot: 
https://ci.chromium.org/ui/p/fuchsia/builders/ci/clang_toolchain.ci.core.x64-release/b8783373381569070049/overview


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D146987/new/

https://reviews.llvm.org/D146987

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D143967: [DebugInfo][BPF] Add 'btf:type_tag' annotation in DWARF

2023-04-19 Thread David Faust via Phabricator via cfe-commits
dfaust added a comment.

In D143967#4233742 , @eddyz87 wrote:

> Moving type tags past typedefs would also make C code reconstruction from BTF 
> incomplete. Such reconstruction is used now by e.g. bpftool to create a 
> vmlinux.h header with all kernel type definitions. So, I think type tags 
> should not be moved past typedefs.

Yes I agree. Tags should not be moved past typedefs.
In the GCC implementation we are not moving tags past typedefs.

> It uses `btf_type_is_modifier()` utility function, which treats typedef as a 
> modifier.
>
> So, in theory the transformation moving tags past typedef is necessary. On 
> the other hand, such transformation is not applied now, and this does not 
> cause issues. Which suggests that there are no cases in practice where type 
> tag follows typedef (and thus, this is not required for backwards 
> compatibility).

It seems to me then that the appropriate fix is to remove the expectation of 
this transformation from the verifier (for the reasons above).

If it is not important for backwards compatibility, then I guess it should not 
be problematic to change in the kernel? (I say, as not a kernel hacker...)

I find it odd that `BTF_KIND_TYPEDEF` is included in `btf_type_is_modifier()`, 
seems like the expectation of this transformation is almost an unintended side 
effect of that.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143967/new/

https://reviews.llvm.org/D143967

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148730: [C11] Allow initialization of an atomic-qualified pointer from a null pointer constant

2023-04-19 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman created this revision.
aaron.ballman added reviewers: rsmith, clang-language-wg.
Herald added a project: All.
aaron.ballman requested review of this revision.
Herald added a project: clang.

The relevant language rule from C11 is 6.5.16.1p1: "the left operand is an 
atomic, qualified, or unqualified pointer, and the right is a null pointer 
constant; or". We correctly handled qualified or unqualified pointer types, but 
failed to handle atomic-qualified pointer types. Now we look through the atomic 
qualification before testing the constraint requirements.

Fixes https://github.com/llvm/llvm-project/issues/49563


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D148730

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/AST/Expr.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/Sema/atomic-expr.c

Index: clang/test/Sema/atomic-expr.c
===
--- clang/test/Sema/atomic-expr.c
+++ clang/test/Sema/atomic-expr.c
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 %s -verify -fsyntax-only
-// RUN: %clang_cc1 %s -verify=off -fsyntax-only -Wno-atomic-access
-// off-no-diagnostics
+// RUN: %clang_cc1 %s -verify=expected,access -fsyntax-only
+// RUN: %clang_cc1 %s -std=c2x -verify=expected,access -fsyntax-only
+// RUN: %clang_cc1 %s -verify -fsyntax-only -Wno-atomic-access
 
 _Atomic(unsigned int) data1;
 int _Atomic data2;
@@ -82,26 +82,26 @@
 void func_16(void) {
   // LHS member access.
   _Atomic struct { int val; } x, *xp;
-  x.val = 12;   // expected-error {{accessing a member of an atomic structure or union is undefined behavior}}
-  xp->val = 12; // expected-error {{accessing a member of an atomic structure or union is undefined behavior}}
+  x.val = 12;   // access-error {{accessing a member of an atomic structure or union is undefined behavior}}
+  xp->val = 12; // access-error {{accessing a member of an atomic structure or union is undefined behavior}}
 
   _Atomic union {
 int ival;
 float fval;
   } y, *yp;
-  y.ival = 12; // expected-error {{accessing a member of an atomic structure or union is undefined behavior}}
-  yp->fval = 1.2f; // expected-error {{accessing a member of an atomic structure or union is undefined behavior}}
+  y.ival = 12; // access-error {{accessing a member of an atomic structure or union is undefined behavior}}
+  yp->fval = 1.2f; // access-error {{accessing a member of an atomic structure or union is undefined behavior}}
 
   // RHS member access.
-  int xval = x.val; // expected-error {{accessing a member of an atomic structure or union is undefined behavior}}
-  xval = xp->val;   // expected-error {{accessing a member of an atomic structure or union is undefined behavior}}
-  int yval = y.ival; // expected-error {{accessing a member of an atomic structure or union is undefined behavior}}
-  yval = yp->ival;   // expected-error {{accessing a member of an atomic structure or union is undefined behavior}}
+  int xval = x.val; // access-error {{accessing a member of an atomic structure or union is undefined behavior}}
+  xval = xp->val;   // access-error {{accessing a member of an atomic structure or union is undefined behavior}}
+  int yval = y.ival; // access-error {{accessing a member of an atomic structure or union is undefined behavior}}
+  yval = yp->ival;   // access-error {{accessing a member of an atomic structure or union is undefined behavior}}
 
   // Using the type specifier instead of the type qualifier.
   _Atomic(struct { int val; }) z;
-  z.val = 12;   // expected-error {{accessing a member of an atomic structure or union is undefined behavior}}
-  int zval = z.val; // expected-error {{accessing a member of an atomic structure or union is undefined behavior}}
+  z.val = 12;   // access-error {{accessing a member of an atomic structure or union is undefined behavior}}
+  int zval = z.val; // access-error {{accessing a member of an atomic structure or union is undefined behavior}}
 
   // Don't diagnose in an unevaluated context, however.
   (void)sizeof(x.val);
@@ -109,3 +109,93 @@
   (void)sizeof(y.ival);
   (void)sizeof(yp->ival);
 }
+
+// Ensure that we correctly implement assignment constraints from C2x 6.5.16.1.
+void func_17(void) {
+  // The left operand has atomic ... arithmetic type, and the right operand has
+  // arithmetic type;
+  _Atomic int i = 0;
+  _Atomic float f = 0.0f;
+
+  // the left operand has an atomic ... version of a structure or union type
+  // compatible with the type of the right operand;
+  struct S { int i; } non_atomic_s;
+  _Atomic struct S s = non_atomic_s;
+
+  union U { int i; float f; } non_atomic_u;
+  _Atomic union U u = non_atomic_u;
+
+  // the left operand has atomic ... pointer type, and (considering the type
+  // the left operand would have after lvalue conversion) both operands are
+  // pointers to qualified or unqualified versions of compatible types, and the
+  // type pointed to by the left operand has all the qualifiers

[PATCH] D146987: [Assignment Tracking] Enable by default

2023-04-19 Thread Paul Kirth via Phabricator via cfe-commits
paulkirth added a comment.

Here are the reproducers, though I haven't reduced them yet.

F27193433: clang-crashreports.zip 


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D146987/new/

https://reviews.llvm.org/D146987

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148730: [C11] Allow initialization of an atomic-qualified pointer from a null pointer constant

2023-04-19 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman updated this revision to Diff 515021.
aaron.ballman added a comment.

Added an additional test case (assignment of a null pointer constant to an 
atomic function pointer) that was mentioned in a comment on the original bug 
report.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148730/new/

https://reviews.llvm.org/D148730

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/AST/Expr.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/Sema/atomic-expr.c

Index: clang/test/Sema/atomic-expr.c
===
--- clang/test/Sema/atomic-expr.c
+++ clang/test/Sema/atomic-expr.c
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 %s -verify -fsyntax-only
-// RUN: %clang_cc1 %s -verify=off -fsyntax-only -Wno-atomic-access
-// off-no-diagnostics
+// RUN: %clang_cc1 %s -verify=expected,access -fsyntax-only
+// RUN: %clang_cc1 %s -std=c2x -verify=expected,access -fsyntax-only
+// RUN: %clang_cc1 %s -verify -fsyntax-only -Wno-atomic-access
 
 _Atomic(unsigned int) data1;
 int _Atomic data2;
@@ -82,26 +82,26 @@
 void func_16(void) {
   // LHS member access.
   _Atomic struct { int val; } x, *xp;
-  x.val = 12;   // expected-error {{accessing a member of an atomic structure or union is undefined behavior}}
-  xp->val = 12; // expected-error {{accessing a member of an atomic structure or union is undefined behavior}}
+  x.val = 12;   // access-error {{accessing a member of an atomic structure or union is undefined behavior}}
+  xp->val = 12; // access-error {{accessing a member of an atomic structure or union is undefined behavior}}
 
   _Atomic union {
 int ival;
 float fval;
   } y, *yp;
-  y.ival = 12; // expected-error {{accessing a member of an atomic structure or union is undefined behavior}}
-  yp->fval = 1.2f; // expected-error {{accessing a member of an atomic structure or union is undefined behavior}}
+  y.ival = 12; // access-error {{accessing a member of an atomic structure or union is undefined behavior}}
+  yp->fval = 1.2f; // access-error {{accessing a member of an atomic structure or union is undefined behavior}}
 
   // RHS member access.
-  int xval = x.val; // expected-error {{accessing a member of an atomic structure or union is undefined behavior}}
-  xval = xp->val;   // expected-error {{accessing a member of an atomic structure or union is undefined behavior}}
-  int yval = y.ival; // expected-error {{accessing a member of an atomic structure or union is undefined behavior}}
-  yval = yp->ival;   // expected-error {{accessing a member of an atomic structure or union is undefined behavior}}
+  int xval = x.val; // access-error {{accessing a member of an atomic structure or union is undefined behavior}}
+  xval = xp->val;   // access-error {{accessing a member of an atomic structure or union is undefined behavior}}
+  int yval = y.ival; // access-error {{accessing a member of an atomic structure or union is undefined behavior}}
+  yval = yp->ival;   // access-error {{accessing a member of an atomic structure or union is undefined behavior}}
 
   // Using the type specifier instead of the type qualifier.
   _Atomic(struct { int val; }) z;
-  z.val = 12;   // expected-error {{accessing a member of an atomic structure or union is undefined behavior}}
-  int zval = z.val; // expected-error {{accessing a member of an atomic structure or union is undefined behavior}}
+  z.val = 12;   // access-error {{accessing a member of an atomic structure or union is undefined behavior}}
+  int zval = z.val; // access-error {{accessing a member of an atomic structure or union is undefined behavior}}
 
   // Don't diagnose in an unevaluated context, however.
   (void)sizeof(x.val);
@@ -109,3 +109,97 @@
   (void)sizeof(y.ival);
   (void)sizeof(yp->ival);
 }
+
+// Ensure that we correctly implement assignment constraints from C2x 6.5.16.1.
+void func_17(void) {
+  // The left operand has atomic ... arithmetic type, and the right operand has
+  // arithmetic type;
+  _Atomic int i = 0;
+  _Atomic float f = 0.0f;
+
+  // the left operand has an atomic ... version of a structure or union type
+  // compatible with the type of the right operand;
+  struct S { int i; } non_atomic_s;
+  _Atomic struct S s = non_atomic_s;
+
+  union U { int i; float f; } non_atomic_u;
+  _Atomic union U u = non_atomic_u;
+
+  // the left operand has atomic ... pointer type, and (considering the type
+  // the left operand would have after lvalue conversion) both operands are
+  // pointers to qualified or unqualified versions of compatible types, and the
+  // type pointed to by the left operand has all the qualifiers of the type
+  // pointed to by the right operand;
+  const int *cip = 0;
+  volatile const int *vcip = 0;
+  const int * const cicp = 0;
+  _Atomic(const int *) acip = cip;
+  _Atomic(const int *) bad_acip = vcip; // expected-warning {{initializing '_Atomic(const int *)' with an expression of type 'const volatile int *' discards qualifiers}}
+  _Atomic(con

[PATCH] D140722: [OpenMP] Prefix outlined and reduction func names with original func's name

2023-04-19 Thread Paul Kirth via Phabricator via cfe-commits
paulkirth added a comment.

I'm seeing some test failures in our CI:

Clang :: OpenMP/parallel_masked.cpp
Clang :: OpenMP/parallel_masked_target.cpp

Bot: 
https://ci.chromium.org/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64-rbe/b8783369579855138017/overview

If this will be hard to fix, can you revert until a fix is ready?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D140722/new/

https://reviews.llvm.org/D140722

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148730: [C11] Allow initialization of an atomic-qualified pointer from a null pointer constant

2023-04-19 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman updated this revision to Diff 515022.
aaron.ballman added a comment.

Added a `-pedantic` run line and used `(void *)0` as a null pointer constant 
for the last test.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148730/new/

https://reviews.llvm.org/D148730

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/AST/Expr.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/Sema/atomic-expr.c

Index: clang/test/Sema/atomic-expr.c
===
--- clang/test/Sema/atomic-expr.c
+++ clang/test/Sema/atomic-expr.c
@@ -1,6 +1,7 @@
-// RUN: %clang_cc1 %s -verify -fsyntax-only
-// RUN: %clang_cc1 %s -verify=off -fsyntax-only -Wno-atomic-access
-// off-no-diagnostics
+// RUN: %clang_cc1 %s -verify=expected,access -fsyntax-only
+// RUN: %clang_cc1 %s -std=c2x -verify=expected,access -fsyntax-only
+// RUN: %clang_cc1 %s -std=c2x -pedantic -verify=expected,access -fsyntax-only
+// RUN: %clang_cc1 %s -verify -fsyntax-only -Wno-atomic-access
 
 _Atomic(unsigned int) data1;
 int _Atomic data2;
@@ -82,26 +83,26 @@
 void func_16(void) {
   // LHS member access.
   _Atomic struct { int val; } x, *xp;
-  x.val = 12;   // expected-error {{accessing a member of an atomic structure or union is undefined behavior}}
-  xp->val = 12; // expected-error {{accessing a member of an atomic structure or union is undefined behavior}}
+  x.val = 12;   // access-error {{accessing a member of an atomic structure or union is undefined behavior}}
+  xp->val = 12; // access-error {{accessing a member of an atomic structure or union is undefined behavior}}
 
   _Atomic union {
 int ival;
 float fval;
   } y, *yp;
-  y.ival = 12; // expected-error {{accessing a member of an atomic structure or union is undefined behavior}}
-  yp->fval = 1.2f; // expected-error {{accessing a member of an atomic structure or union is undefined behavior}}
+  y.ival = 12; // access-error {{accessing a member of an atomic structure or union is undefined behavior}}
+  yp->fval = 1.2f; // access-error {{accessing a member of an atomic structure or union is undefined behavior}}
 
   // RHS member access.
-  int xval = x.val; // expected-error {{accessing a member of an atomic structure or union is undefined behavior}}
-  xval = xp->val;   // expected-error {{accessing a member of an atomic structure or union is undefined behavior}}
-  int yval = y.ival; // expected-error {{accessing a member of an atomic structure or union is undefined behavior}}
-  yval = yp->ival;   // expected-error {{accessing a member of an atomic structure or union is undefined behavior}}
+  int xval = x.val; // access-error {{accessing a member of an atomic structure or union is undefined behavior}}
+  xval = xp->val;   // access-error {{accessing a member of an atomic structure or union is undefined behavior}}
+  int yval = y.ival; // access-error {{accessing a member of an atomic structure or union is undefined behavior}}
+  yval = yp->ival;   // access-error {{accessing a member of an atomic structure or union is undefined behavior}}
 
   // Using the type specifier instead of the type qualifier.
   _Atomic(struct { int val; }) z;
-  z.val = 12;   // expected-error {{accessing a member of an atomic structure or union is undefined behavior}}
-  int zval = z.val; // expected-error {{accessing a member of an atomic structure or union is undefined behavior}}
+  z.val = 12;   // access-error {{accessing a member of an atomic structure or union is undefined behavior}}
+  int zval = z.val; // access-error {{accessing a member of an atomic structure or union is undefined behavior}}
 
   // Don't diagnose in an unevaluated context, however.
   (void)sizeof(x.val);
@@ -109,3 +110,98 @@
   (void)sizeof(y.ival);
   (void)sizeof(yp->ival);
 }
+
+// Ensure that we correctly implement assignment constraints from C2x 6.5.16.1.
+void func_17(void) {
+  // The left operand has atomic ... arithmetic type, and the right operand has
+  // arithmetic type;
+  _Atomic int i = 0;
+  _Atomic float f = 0.0f;
+
+  // the left operand has an atomic ... version of a structure or union type
+  // compatible with the type of the right operand;
+  struct S { int i; } non_atomic_s;
+  _Atomic struct S s = non_atomic_s;
+
+  union U { int i; float f; } non_atomic_u;
+  _Atomic union U u = non_atomic_u;
+
+  // the left operand has atomic ... pointer type, and (considering the type
+  // the left operand would have after lvalue conversion) both operands are
+  // pointers to qualified or unqualified versions of compatible types, and the
+  // type pointed to by the left operand has all the qualifiers of the type
+  // pointed to by the right operand;
+  const int *cip = 0;
+  volatile const int *vcip = 0;
+  const int * const cicp = 0;
+  _Atomic(const int *) acip = cip;
+  _Atomic(const int *) bad_acip = vcip; // expected-warning {{initializing '_Atomic(const int *)' with an expression of type 'const volatile int *' discards qualifiers}}

[PATCH] D140722: [OpenMP] Prefix outlined and reduction func names with original func's name

2023-04-19 Thread Paul Kirth via Phabricator via cfe-commits
paulkirth added a comment.

Sorry, I missed that this was already reverted.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D140722/new/

https://reviews.llvm.org/D140722

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D146591: [dataflow] add HTML logger: browse code/cfg/analysis timeline/state

2023-04-19 Thread Nico Weber via Phabricator via cfe-commits
thakis added inline comments.



Comment at: clang/utils/bundle_resources.py:6
+# Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+# See https://llvm.org/LICENSE.txt for license information.
+# SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception

This file looks very similar to 
clang-tools-extra/pseudo/tool/bundle_resources.py. Could we remove 
clang-tools-extra/pseudo/tool/bundle_resources.py and make 
c-t-e/pseudo/tools/CMakeLists.txt call this script instead?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D146591/new/

https://reviews.llvm.org/D146591

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D148730: [C11] Allow initialization of an atomic-qualified pointer from a null pointer constant

2023-04-19 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added inline comments.



Comment at: clang/lib/Sema/SemaExpr.cpp:10307
   CXXCastPath Path;
   CheckPointerConversion(RHS.get(), LHSType, Kind, Path,
  /*IgnoreBaseAccess=*/false, Diagnose);

Does the LHSType here need switching too?  Or are we just going to use the 
'normal' pointer conversion rules here?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D148730/new/

https://reviews.llvm.org/D148730

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D140722: [OpenMP] Prefix outlined and reduction func names with original func's name

2023-04-19 Thread Itay Bookstein via Phabricator via cfe-commits
nextsilicon-itay-bookstein reopened this revision.
nextsilicon-itay-bookstein marked 2 inline comments as done.
nextsilicon-itay-bookstein added a comment.
This revision is now accepted and ready to land.

Reopening due to revert, will update with a fixed patch


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D140722/new/

https://reviews.llvm.org/D140722

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D140722: [OpenMP] Prefix outlined and reduction func names with original func's name

2023-04-19 Thread Itay Bookstein via Phabricator via cfe-commits
nextsilicon-itay-bookstein updated this revision to Diff 515025.
nextsilicon-itay-bookstein edited the summary of this revision.
nextsilicon-itay-bookstein added a comment.

Updated a couple of tests that were introduced in the interim


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D140722/new/

https://reviews.llvm.org/D140722

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/CodeGen/CGOpenMPRuntime.h
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.h
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/test/CodeGen/PowerPC/ppc64le-varargs-f128.c
  clang/test/CoverageMapping/openmp.c
  clang/test/OpenMP/amdgpu_target_with_aligned_attribute.c
  clang/test/OpenMP/bug54082.c
  clang/test/OpenMP/bug60602.cpp
  clang/test/OpenMP/cancel_codegen.cpp
  clang/test/OpenMP/cancellation_point_codegen.cpp
  clang/test/OpenMP/debug-info-complex-byval.cpp
  clang/test/OpenMP/debug-info-openmp-array.cpp
  clang/test/OpenMP/debug_threadprivate_copyin.c
  clang/test/OpenMP/declare_target_codegen_globalization.cpp
  clang/test/OpenMP/distribute_codegen.cpp
  clang/test/OpenMP/distribute_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_if_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_num_threads_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_private_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_proc_bind_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_reduction_task_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_if_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_num_threads_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_private_codegen.cpp
  clang/test/OpenMP/distribute_parallel_for_simd_proc_bind_codegen.cpp
  clang/test/OpenMP/distribute_private_codegen.cpp
  clang/test/OpenMP/distribute_simd_codegen.cpp
  clang/test/OpenMP/distribute_simd_firstprivate_codegen.cpp
  clang/test/OpenMP/distribute_simd_lastprivate_codegen.cpp
  clang/test/OpenMP/distribute_simd_private_codegen.cpp
  clang/test/OpenMP/distribute_simd_reduction_codegen.cpp
  clang/test/OpenMP/for_firstprivate_codegen.cpp
  clang/test/OpenMP/for_lastprivate_codegen.cpp
  clang/test/OpenMP/for_linear_codegen.cpp
  clang/test/OpenMP/for_private_codegen.cpp
  clang/test/OpenMP/for_reduction_codegen.cpp
  clang/test/OpenMP/for_reduction_codegen_UDR.cpp
  clang/test/OpenMP/for_reduction_task_codegen.cpp
  clang/test/OpenMP/function-attr.cpp
  clang/test/OpenMP/master_taskloop_in_reduction_codegen.cpp
  clang/test/OpenMP/master_taskloop_simd_in_reduction_codegen.cpp
  clang/test/OpenMP/metadirective_device_arch_codegen.cpp
  clang/test/OpenMP/metadirective_device_isa_codegen.cpp
  clang/test/OpenMP/metadirective_implementation_codegen.c
  clang/test/OpenMP/nested_loop_codegen.cpp
  clang/test/OpenMP/nvptx_SPMD_codegen.cpp
  clang/test/OpenMP/nvptx_allocate_codegen.cpp
  clang/test/OpenMP/nvptx_data_sharing.cpp
  clang/test/OpenMP/nvptx_distribute_parallel_generic_mode_codegen.cpp
  clang/test/OpenMP/nvptx_lambda_capturing.cpp
  clang/test/OpenMP/nvptx_multi_target_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_nested_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_parallel_for_codegen.cpp
  clang/test/OpenMP/nvptx_target_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_num_threads_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_proc_bind_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_reduction_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_reduction_codegen_tbaa_PR46146.cpp
  clang/test/OpenMP/nvptx_target_teams_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_codegen.cpp
  
clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_generic_mode_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_simd_codegen.cpp
  clang/test/OpenMP/nvptx_teams_codegen.cpp
  clang/test/OpenMP/nvptx_teams_reduction_codegen.cpp
  clang/test/OpenMP/omp_with_loop_pragma_instr_profile.c
  clang/test/OpenMP/openmp_win_codegen.cpp
  clang/test/OpenMP/outlined_artificial.c
  clang/test/OpenMP/parallel_codegen.cpp
  clang/test/OpenMP/parallel_copyin_codegen.cpp
  clang/test/OpenMP/parallel_copyin_combined_codegen.c
  clang/test/OpenMP/parallel_firstprivate_codegen.cpp
  

[clang] a65ca45 - Revert D146987 "[Assignment Tracking] Enable by default"

2023-04-19 Thread via cfe-commits

Author: OCHyams
Date: 2023-04-19T19:16:40+01:00
New Revision: a65ca4546b9ee042d6c40149d3f820893edbd766

URL: 
https://github.com/llvm/llvm-project/commit/a65ca4546b9ee042d6c40149d3f820893edbd766
DIFF: 
https://github.com/llvm/llvm-project/commit/a65ca4546b9ee042d6c40149d3f820893edbd766.diff

LOG: Revert D146987 "[Assignment Tracking] Enable by default"

This reverts commit 89d27854ec7f5e8bd83e72fa574740bf3d06355b.

See https://reviews.llvm.org/D146987 for issues.

Added: 


Modified: 
clang/include/clang/Driver/Options.td
clang/test/CodeGen/assignment-tracking/flag.cpp

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 604b4a45fffc1..eed0d517a1ad7 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -5817,7 +5817,7 @@ def fexperimental_assignment_tracking_EQ : Joined<["-"], 
"fexperimental-assignme
   Group, CodeGenOpts<"EnableAssignmentTracking">,
   NormalizedValuesScope<"CodeGenOptions::AssignmentTrackingOpts">,
   Values<"disabled,enabled,forced">, 
NormalizedValues<["Disabled","Enabled","Forced"]>,
-  MarshallingInfoEnum, "Enabled">;
+  MarshallingInfoEnum, "Disabled">;
 
 } // let Flags = [CC1Option, NoDriverOption]
 

diff  --git a/clang/test/CodeGen/assignment-tracking/flag.cpp 
b/clang/test/CodeGen/assignment-tracking/flag.cpp
index 3bd974fe07c6c..aa1f054dae4d7 100644
--- a/clang/test/CodeGen/assignment-tracking/flag.cpp
+++ b/clang/test/CodeGen/assignment-tracking/flag.cpp
@@ -8,10 +8,10 @@
 // RUN: -emit-llvm  %s -o - -fexperimental-assignment-tracking=disabled 
-O1\
 // RUN: | FileCheck %s --check-prefixes=DISABLE
 
- Enabled by default:
+ Disabled by default:
 // RUN: %clang_cc1 -triple x86_64-none-linux-gnu -debug-info-kind=standalone   
\
 // RUN: -emit-llvm  %s -o - -O1
\
-// RUN: | FileCheck %s --check-prefixes=ENABLE
+// RUN: | FileCheck %s --check-prefixes=DISABLE
 
  Disabled at O0 unless forced.
 // RUN: %clang_cc1 -triple x86_64-none-linux-gnu -debug-info-kind=standalone   
\



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D146987: [Assignment Tracking] Enable by default

2023-04-19 Thread Orlando Cazalet-Hyams via Phabricator via cfe-commits
Orlando added a comment.

> I think we may have an issue due to this. I'm basing that on the blamelist, 
> but I'm still bisecting our build, which may take some time to confirm. Can 
> you take a look, and revert if it's not a quick fix?

That looks related to assignment tracking to me. I'm unlikely to get the chance 
to look into it until tomorrow morning (UK / BST), so I've reverted it for now. 
Thanks for the info.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D146987/new/

https://reviews.llvm.org/D146987

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


  1   2   >