[PATCH] D157485: [X86][RFC] Support new feature AVX10

2023-08-31 Thread Phoebe Wang via Phabricator via cfe-commits
pengfei planned changes to this revision.
pengfei added a comment.

In D157485#4597603 , @e-kud wrote:

> Just curious, in RFC we have `-mavx10.x-256/-mavx10.x-512` but here we refer 
> to `-mavx10.x/-mavx10.x,-mavx10-512bit`. Is it compliant with GCC, or the 
> revision is just for the illustrative purpose?

Sorry for the late reply. We have received a couple concerns about how to 
interpret these options, especially when used together with AVX512 options. We 
decided not to provide AVX10.1 options at the present, instead, we just provide 
`-m[no-]evex512` to disable ZMM and 64-bit mask instructions for AVX512 
features. For more details, lease take a look at D159250 
.




Comment at: clang/lib/Basic/Targets/X86.cpp:739
+  if (HasAVX10_512BIT)
+Builder.defineMacro("__AVX10_512BIT__");
+

MaskRay wrote:
> This is untested?
Done in an alternative reversion D159250.



Comment at: clang/lib/Driver/ToolChains/Arch/X86.cpp:261
+if (AVXVecSize == 256)
+  D.Diag(diag::warn_drv_overriding_flag_option) << "AVX10-256"
+<< "AVX10-512";

MaskRay wrote:
> `warn_drv_overriding_flag_option` is under the group `-Woverriding-t-option`, 
> which was intended for clang-cl `/T*` options (`D1290`).
> 
> I created D158137 to add `-Woverriding-option`.
Thanks! This is not needed in the new version.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157485

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


[PATCH] D158061: [clang] Construct ExprRequirement with SubstitutionDiagnostic on SubstFailure

2023-08-31 Thread Younan Zhang via Phabricator via cfe-commits
zyounan updated this revision to Diff 554914.
zyounan marked an inline comment as done.
zyounan added a comment.

Expand diagnostics in the test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158061

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/AST/ExprConcepts.h
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/test/SemaCXX/concept-crash-on-diagnostic.cpp
  clang/test/SemaCXX/concept-fatal-error.cpp

Index: clang/test/SemaCXX/concept-fatal-error.cpp
===
--- clang/test/SemaCXX/concept-fatal-error.cpp
+++ clang/test/SemaCXX/concept-fatal-error.cpp
@@ -1,4 +1,4 @@
-// RUN: not %clang_cc1 -fsyntax-only -std=c++20 -ferror-limit 1 -verify %s
+// RUN: %clang_cc1 -fsyntax-only -std=c++20 -ferror-limit 1 -verify %s
 
 template 
 concept f = requires { 42; };
@@ -6,5 +6,5 @@
   // The missing semicolon will trigger an error and -ferror-limit=1 will make it fatal
   // We test that we do not crash in such cases (#55401)
   int i = requires { { i } f } // expected-error {{expected ';' at end of declaration list}}
-   // expected-error@* {{too many errros emitted}}
+   // expected-error@* {{too many errors emitted}}
 };
Index: clang/test/SemaCXX/concept-crash-on-diagnostic.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/concept-crash-on-diagnostic.cpp
@@ -0,0 +1,41 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c++20 -verify %s
+
+template  class normal_iterator {};
+
+template  struct is_convertible {};
+
+template 
+inline constexpr bool is_convertible_v = is_convertible::value; // #1
+
+template 
+concept convertible_to = is_convertible_v; // #2
+
+template 
+  requires requires(IteratorL lhs, IteratorR rhs) { // #3
+{ lhs == rhs } -> convertible_to; // #4
+  }
+constexpr bool compare(normal_iterator lhs, normal_iterator rhs) { // #5
+  return false;
+}
+
+class Object;
+
+void function() {
+  normal_iterator begin, end;
+  compare(begin, end); // #6
+}
+
+// expected-error@#1 {{no member named 'value' in 'is_convertible'}}
+
+// expected-note@#2 {{in instantiation of variable template specialization 'is_convertible_v' requested here}}
+// expected-note@#2 {{substituting template arguments into constraint expression here}}
+// expected-note@#4 {{checking the satisfaction of concept 'convertible_to'}}
+// expected-note@#3 {{substituting template arguments into constraint expression here}}
+// expected-note@#6 {{checking constraint satisfaction for template 'compare'}}
+// expected-note@#6 {{in instantiation of function template specialization 'compare' requested here}}
+
+// expected-error@#6 {{no matching function for call to 'compare'}}
+
+// expected-note@#5 {{candidate template ignored: constraints not satisfied [with IteratorL = Object *, IteratorR = Object *]}}
+// We don't know exactly the substituted type for `lhs == rhs`, thus a placeholder 'expr-type' is emitted.
+// expected-note@#4 {{because 'convertible_to' would be invalid}}
Index: clang/lib/Sema/SemaTemplateInstantiate.cpp
===
--- clang/lib/Sema/SemaTemplateInstantiate.cpp
+++ clang/lib/Sema/SemaTemplateInstantiate.cpp
@@ -2271,9 +2271,9 @@
   getPackIndex(Pack), Arg, TL.getNameLoc());
 }
 
-template
 static concepts::Requirement::SubstitutionDiagnostic *
-createSubstDiag(Sema &S, TemplateDeductionInfo &Info, EntityPrinter Printer) {
+createSubstDiag(Sema &S, TemplateDeductionInfo &Info,
+concepts::EntityPrinter Printer) {
   SmallString<128> Message;
   SourceLocation ErrorLoc;
   if (Info.hasSFINAEDiagnostic()) {
@@ -2297,6 +2297,19 @@
   StringRef(MessageBuf, Message.size())};
 }
 
+concepts::Requirement::SubstitutionDiagnostic *
+concepts::createSubstDiagAt(Sema &S, SourceLocation Location,
+EntityPrinter Printer) {
+  SmallString<128> Entity;
+  llvm::raw_svector_ostream OS(Entity);
+  Printer(OS);
+  char *EntityBuf = new (S.Context) char[Entity.size()];
+  llvm::copy(Entity, EntityBuf);
+  return new (S.Context) concepts::Requirement::SubstitutionDiagnostic{
+  /*SubstitutedEntity=*/StringRef(EntityBuf, Entity.size()),
+  /*DiagLoc=*/Location, /*DiagMessage=*/StringRef()};
+}
+
 ExprResult TemplateInstantiator::TransformRequiresTypeParams(
 SourceLocation KWLoc, SourceLocation RBraceLoc, const RequiresExpr *RE,
 RequiresExprBodyDecl *Body, ArrayRef Params,
Index: clang/lib/Sema/SemaExprCXX.cpp
===
--- clang/lib/Sema/SemaExprCXX.cpp
+++ clang/lib/Sema/SemaExprCXX.cpp
@@ -19,6 +19,7 @@
 #include "clang/AST/CharUnits.h"
 #include "clang/AST/DeclObjC.h"
 #include "clang/AST/ExprCXX.h"
+#include "clang/AST/ExprConcepts.h"
 #include "clang/AST/Ex

[PATCH] D158061: [clang] Construct ExprRequirement with SubstitutionDiagnostic on SubstFailure

2023-08-31 Thread Younan Zhang via Phabricator via cfe-commits
zyounan added a comment.

Thanks for the review!




Comment at: clang/test/SemaCXX/concept-crash-on-diagnostic.cpp:26
+// Consume remaining notes/errors.
+// expected-note@* 0+{{}}
+// expected-error@* 0+{{}}

erichkeane wrote:
> Please don't do this, actually write out the remaining diagnostics.  Same 
> with the notes above.
> 
> Additionally, please use the 'bookmark' feature of verify-consumer to make 
> sure the diagnostics/notes are in proper order (which makes it easier to 
> figure out when reviewing).
Thanks for reminding me. Will do that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158061

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


[PATCH] D158061: [clang] Construct ExprRequirement with SubstitutionDiagnostic on SubstFailure

2023-08-31 Thread Younan Zhang via Phabricator via cfe-commits
zyounan updated this revision to Diff 554919.
zyounan added a comment.

Rebase to main


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158061

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/AST/ExprConcepts.h
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/test/SemaCXX/concept-crash-on-diagnostic.cpp
  clang/test/SemaCXX/concept-fatal-error.cpp

Index: clang/test/SemaCXX/concept-fatal-error.cpp
===
--- clang/test/SemaCXX/concept-fatal-error.cpp
+++ clang/test/SemaCXX/concept-fatal-error.cpp
@@ -1,4 +1,4 @@
-// RUN: not %clang_cc1 -fsyntax-only -std=c++20 -ferror-limit 1 -verify %s
+// RUN: %clang_cc1 -fsyntax-only -std=c++20 -ferror-limit 1 -verify %s
 
 template 
 concept f = requires { 42; };
@@ -6,5 +6,5 @@
   // The missing semicolon will trigger an error and -ferror-limit=1 will make it fatal
   // We test that we do not crash in such cases (#55401)
   int i = requires { { i } f } // expected-error {{expected ';' at end of declaration list}}
-   // expected-error@* {{too many errros emitted}}
+   // expected-error@* {{too many errors emitted}}
 };
Index: clang/test/SemaCXX/concept-crash-on-diagnostic.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/concept-crash-on-diagnostic.cpp
@@ -0,0 +1,41 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c++20 -verify %s
+
+template  class normal_iterator {};
+
+template  struct is_convertible {};
+
+template 
+inline constexpr bool is_convertible_v = is_convertible::value; // #1
+
+template 
+concept convertible_to = is_convertible_v; // #2
+
+template 
+  requires requires(IteratorL lhs, IteratorR rhs) { // #3
+{ lhs == rhs } -> convertible_to; // #4
+  }
+constexpr bool compare(normal_iterator lhs, normal_iterator rhs) { // #5
+  return false;
+}
+
+class Object;
+
+void function() {
+  normal_iterator begin, end;
+  compare(begin, end); // #6
+}
+
+// expected-error@#1 {{no member named 'value' in 'is_convertible'}}
+
+// expected-note@#2 {{in instantiation of variable template specialization 'is_convertible_v' requested here}}
+// expected-note@#2 {{substituting template arguments into constraint expression here}}
+// expected-note@#4 {{checking the satisfaction of concept 'convertible_to'}}
+// expected-note@#3 {{substituting template arguments into constraint expression here}}
+// expected-note@#6 {{checking constraint satisfaction for template 'compare'}}
+// expected-note@#6 {{in instantiation of function template specialization 'compare' requested here}}
+
+// expected-error@#6 {{no matching function for call to 'compare'}}
+
+// expected-note@#5 {{candidate template ignored: constraints not satisfied [with IteratorL = Object *, IteratorR = Object *]}}
+// We don't know exactly the substituted type for `lhs == rhs`, thus a placeholder 'expr-type' is emitted.
+// expected-note@#4 {{because 'convertible_to' would be invalid}}
Index: clang/lib/Sema/SemaTemplateInstantiate.cpp
===
--- clang/lib/Sema/SemaTemplateInstantiate.cpp
+++ clang/lib/Sema/SemaTemplateInstantiate.cpp
@@ -2271,9 +2271,9 @@
   getPackIndex(Pack), Arg, TL.getNameLoc());
 }
 
-template
 static concepts::Requirement::SubstitutionDiagnostic *
-createSubstDiag(Sema &S, TemplateDeductionInfo &Info, EntityPrinter Printer) {
+createSubstDiag(Sema &S, TemplateDeductionInfo &Info,
+concepts::EntityPrinter Printer) {
   SmallString<128> Message;
   SourceLocation ErrorLoc;
   if (Info.hasSFINAEDiagnostic()) {
@@ -2297,6 +2297,19 @@
   StringRef(MessageBuf, Message.size())};
 }
 
+concepts::Requirement::SubstitutionDiagnostic *
+concepts::createSubstDiagAt(Sema &S, SourceLocation Location,
+EntityPrinter Printer) {
+  SmallString<128> Entity;
+  llvm::raw_svector_ostream OS(Entity);
+  Printer(OS);
+  char *EntityBuf = new (S.Context) char[Entity.size()];
+  llvm::copy(Entity, EntityBuf);
+  return new (S.Context) concepts::Requirement::SubstitutionDiagnostic{
+  /*SubstitutedEntity=*/StringRef(EntityBuf, Entity.size()),
+  /*DiagLoc=*/Location, /*DiagMessage=*/StringRef()};
+}
+
 ExprResult TemplateInstantiator::TransformRequiresTypeParams(
 SourceLocation KWLoc, SourceLocation RBraceLoc, const RequiresExpr *RE,
 RequiresExprBodyDecl *Body, ArrayRef Params,
Index: clang/lib/Sema/SemaExprCXX.cpp
===
--- clang/lib/Sema/SemaExprCXX.cpp
+++ clang/lib/Sema/SemaExprCXX.cpp
@@ -19,6 +19,7 @@
 #include "clang/AST/CharUnits.h"
 #include "clang/AST/DeclObjC.h"
 #include "clang/AST/ExprCXX.h"
+#include "clang/AST/ExprConcepts.h"
 #include "clang/AST/ExprObjC.h"
 #include "clang/AST/RecursiveASTVisitor.h"
 #inc

[clang] 4b40ced - [RISCV] Add --print-supported-extensions support

2023-08-31 Thread via cfe-commits

Author: 4vtomat
Date: 2023-08-31T00:24:06-07:00
New Revision: 4b40ced4e5ba10b841516b3970e7699ba8ded572

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

LOG: [RISCV] Add --print-supported-extensions support

This revision supports --print-supported-extensions,
it prints out all of the extensions and corresponding version supported.

Reviewed By: craig.topper, kito-cheng

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

Added: 


Modified: 
clang/include/clang/Driver/Options.td
clang/include/clang/Frontend/FrontendOptions.h
clang/lib/Driver/Driver.cpp
clang/tools/driver/cc1_main.cpp
llvm/include/llvm/Support/RISCVISAInfo.h
llvm/lib/Support/RISCVISAInfo.cpp
llvm/unittests/Support/RISCVISAInfoTest.cpp

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index a2a6cf0dcad3c0..b8b02af9f35f0c 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -5251,6 +5251,10 @@ def print_supported_cpus : Flag<["-", "--"], 
"print-supported-cpus">,
   HelpText<"Print supported cpu models for the given target (if target is not 
specified,"
" it will print the supported cpus for the default target)">,
   MarshallingInfoFlag>;
+def print_supported_extensions : Flag<["-", "--"], 
"print-supported-extensions">,
+  Visibility<[ClangOption, CC1Option, CLOption]>,
+  HelpText<"Print supported extensions for RISC-V">,
+  MarshallingInfoFlag>;
 def : Flag<["-"], "mcpu=help">, Alias;
 def : Flag<["-"], "mtune=help">, Alias;
 def time : Flag<["-"], "time">,

diff  --git a/clang/include/clang/Frontend/FrontendOptions.h 
b/clang/include/clang/Frontend/FrontendOptions.h
index 3132c11705d3d8..117e35de6f76c4 100644
--- a/clang/include/clang/Frontend/FrontendOptions.h
+++ b/clang/include/clang/Frontend/FrontendOptions.h
@@ -283,6 +283,9 @@ class FrontendOptions {
   /// print the supported cpus for the current target
   unsigned PrintSupportedCPUs : 1;
 
+  /// Print the supported extensions for the current target.
+  unsigned PrintSupportedExtensions : 1;
+
   /// Show the -version text.
   unsigned ShowVersion : 1;
 

diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 8d5c0efeea0a90..6784b838257cd9 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -2103,7 +2103,8 @@ bool Driver::HandleImmediateArgs(const Compilation &C) {
 
   if (C.getArgs().hasArg(options::OPT_v) ||
   C.getArgs().hasArg(options::OPT__HASH_HASH_HASH) ||
-  C.getArgs().hasArg(options::OPT_print_supported_cpus)) {
+  C.getArgs().hasArg(options::OPT_print_supported_cpus) ||
+  C.getArgs().hasArg(options::OPT_print_supported_extensions)) {
 PrintVersion(C, llvm::errs());
 SuppressMissingInputWarning = true;
   }
@@ -4273,16 +4274,30 @@ void Driver::BuildActions(Compilation &C, 
DerivedArgList &Args,
   C.MakeAction(MergerInputs, types::TY_Image));
   }
 
-  // If --print-supported-cpus, -mcpu=? or -mtune=? is specified, build a 
custom
-  // Compile phase that prints out supported cpu models and quits.
-  if (Arg *A = Args.getLastArg(options::OPT_print_supported_cpus)) {
-// Use the -mcpu=? flag as the dummy input to cc1.
-Actions.clear();
-Action *InputAc = C.MakeAction(*A, types::TY_C);
-Actions.push_back(
-C.MakeAction(InputAc, types::TY_Nothing));
-for (auto &I : Inputs)
-  I.second->claim();
+  for (auto Opt : {options::OPT_print_supported_cpus,
+   options::OPT_print_supported_extensions}) {
+// If --print-supported-cpus, -mcpu=? or -mtune=? is specified, build a
+// custom Compile phase that prints out supported cpu models and quits.
+//
+// If --print-supported-extensions is specified, call the helper function
+// RISCVMarchHelp in RISCVISAInfo.cpp that prints out supported extensions
+// and quits.
+if (Arg *A = Args.getLastArg(Opt)) {
+  if (Opt == options::OPT_print_supported_extensions &&
+  !C.getDefaultToolChain().getTriple().isRISCV()) {
+C.getDriver().Diag(diag::err_opt_not_valid_on_target)
+<< "--print-supported-extensions";
+return;
+  }
+
+  // Use the -mcpu=? flag as the dummy input to cc1.
+  Actions.clear();
+  Action *InputAc = C.MakeAction(*A, types::TY_C);
+  Actions.push_back(
+  C.MakeAction(InputAc, types::TY_Nothing));
+  for (auto &I : Inputs)
+I.second->claim();
+}
   }
 
   // Call validator for dxil when -Vd not in Args.

diff  --git a/clang/tools/driver/cc1_main.cpp b/clang/tools/driver/cc1_main.cpp
index 9e7f8679b4cbdf..ab886d0adc7e5c 100644
--- a/clang/tools/driver/cc1_main.cpp
+++ b/clang/tools/driver/cc1_main.cpp
@@ -38,6 +38,7 

[PATCH] D146054: [RISCV] Add --print-supported-extensions support

2023-08-31 Thread Brandon Wu 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 rG4b40ced4e5ba: [RISCV] Add --print-supported-extensions 
support (authored by 4vtomat).

Changed prior to commit:
  https://reviews.llvm.org/D146054?vs=554609&id=554921#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146054

Files:
  clang/include/clang/Driver/Options.td
  clang/include/clang/Frontend/FrontendOptions.h
  clang/lib/Driver/Driver.cpp
  clang/tools/driver/cc1_main.cpp
  llvm/include/llvm/Support/RISCVISAInfo.h
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/unittests/Support/RISCVISAInfoTest.cpp

Index: llvm/unittests/Support/RISCVISAInfoTest.cpp
===
--- llvm/unittests/Support/RISCVISAInfoTest.cpp
+++ llvm/unittests/Support/RISCVISAInfoTest.cpp
@@ -626,3 +626,143 @@
   EXPECT_EQ(RISCVISAInfo::getTargetFeatureForExtension(""), "");
   EXPECT_EQ(RISCVISAInfo::getTargetFeatureForExtension("zbbzihintntl"), "");
 }
+
+TEST(RiscvExtensionsHelp, CheckExtensions) {
+  std::string ExpectedOutput =
+R"(All available -march extensions for RISC-V
+
+	NameVersion
+	i   2.1
+	e   2.0
+	m   2.0
+	a   2.1
+	f   2.2
+	d   2.2
+	c   2.0
+	v   1.0
+	h   1.0
+	zicbom  1.0
+	zicbop  1.0
+	zicboz  1.0
+	zicntr  1.0
+	zicsr   2.0
+	zifencei2.0
+	zihintntl   1.0
+	zihintpause 2.0
+	zihpm   1.0
+	zmmul   1.0
+	zawrs   1.0
+	zfh 1.0
+	zfhmin  1.0
+	zfinx   1.0
+	zdinx   1.0
+	zca 1.0
+	zcb 1.0
+	zcd 1.0
+	zce 1.0
+	zcf 1.0
+	zcmp1.0
+	zcmt1.0
+	zba 1.0
+	zbb 1.0
+	zbc 1.0
+	zbkb1.0
+	zbkc1.0
+	zbkx1.0
+	zbs 1.0
+	zk  1.0
+	zkn 1.0
+	zknd1.0
+	zkne1.0
+	zknh1.0
+	zkr 1.0
+	zks 1.0
+	zksed   1.0
+	zksh1.0
+	zkt 1.0
+	zve32f  1.0
+	zve32x  1.0
+	zve64d  1.0
+	zve64f  1.0
+	zve64x  1.0
+	zvfh1.0
+	zvfhmin 1.0
+	zvl1024b1.0
+	zvl128b 1.0
+	zvl16384b   1.0
+	zvl2048b1.0
+	zvl256b 1.0
+	zvl32768b   1.0
+	zvl32b  1.0
+	zvl4096b1.0
+	zvl512b 1.0
+	zvl64b  1.0
+	zvl65536b   1.0
+	zvl8192b1.0
+	zhinx   1.0
+	zhinxmin1.0
+	svinval 1.0
+	svnapot 1.0
+	svpbmt  1.0
+	xcvalu  1.0
+	xcvbi   1.0
+	xcvbitmanip 1.0
+	xcvmac  1.0
+	xcvsimd 1.0
+	xsfcie  1.0
+	xsfvcp  1.0
+	xtheadba1.0
+	xtheadbb1.0
+	xtheadbs1.0
+	xtheadcmo   1.0
+	xtheadcondmov   1.0
+	xtheadfmemidx   1.0
+	xtheadmac   1.0
+	xtheadmemidx1.0
+	xtheadmempair   1.0
+	xtheadsync  1.0
+	xtheadvdot  1.0
+	xventanacondops 1.0
+
+Experimental extensions
+	zicfilp 0.2
+	zicond  1.0
+	zacas   1.0
+	zfa 0.2
+	zfbfmin 0.8
+	ztso0.1
+	zvbb1.0
+	zvbc1.0
+	zvfbfmin0.8
+	zvfbfwma0.8
+	zvkb1.0
+	zvkg1.0
+	zvkn1.0
+	zvknc   1.0
+	zvkned  1.0
+	zvkng   1.0
+	zvknha  1.0
+	zvknhb  1.0
+	zvks1.0
+	zvksc   1.0
+	zvksed  1.0
+	zvksg   1.0
+	zvksh   1.0
+	zvkt1.0
+	smaia   1.0
+	ssaia   1.0
+
+Use -march to specify the target's extension.
+For example, clang -march=rv32i_v1p0)";
+
+  outs().flush();
+  testing::internal::CaptureStdout();
+
+  llvm::riscvExtensionsHelp();
+  outs().flush();
+
+  std::string CapturedOutput = testing::internal::GetCapturedStdout();
+  EXPECT_TRUE([](std::string &Captured, std::string &Expected) {
+return Captured.find(Expected) != std::string::npos;
+  }(CapturedOutput, ExpectedOutput));
+}
Index: llvm/lib/Support/RISCVISAInfo.cpp
===
--- llvm/lib/Support/RISCVISAInfo.cpp
+++ llvm/lib/Support/RISC

[PATCH] D158266: Patch for Support to loop bind clause : Checking Parent Region

2023-08-31 Thread Sunil K via Phabricator via cfe-commits
koops updated this revision to Diff 554920.
koops added a comment.

Using isOpenMPWorksharingDirective( ) for the "omp loop bind(parallel)" and 
"omp loop bind(teams)".
Added extra tests in loop_bind_messages.cpp.


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

https://reviews.llvm.org/D158266

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/loop_bind_messages.cpp
  clang/test/PCH/pragma-loop.cpp

Index: clang/test/PCH/pragma-loop.cpp
===
--- clang/test/PCH/pragma-loop.cpp
+++ clang/test/PCH/pragma-loop.cpp
@@ -116,9 +116,13 @@
 
   inline void run10(int *List, int Length) {
 int i = 0;
-#pragma omp loop bind(teams)
+int j = 0;
+#pragma omp teams
 for (int i = 0; i < Length; i++) {
-  List[i] = i;
+  #pragma omp loop bind(teams)
+  for (int j = 0; j < Length; j++) {
+List[i] = i+j;
+  }
 }
   }
 
Index: clang/test/OpenMP/loop_bind_messages.cpp
===
--- clang/test/OpenMP/loop_bind_messages.cpp
+++ clang/test/OpenMP/loop_bind_messages.cpp
@@ -4,6 +4,7 @@
 
 #define NNN 50
 int aaa[NNN];
+int aaa2[NNN][NNN];
 
 void parallel_loop() {
   #pragma omp parallel
@@ -15,6 +16,50 @@
}
 }
 
+void parallel_for_AND_loop_bind() {
+  #pragma omp parallel for
+  for (int i = 0 ; i < NNN ; i++) {
+#pragma omp loop bind(parallel) // expected-error{{region cannot be closely nested inside 'parallel for' region; perhaps you forget to enclose 'omp loop' directive into a parallel region?}}
+for (int j = 0 ; j < NNN ; j++) {
+  aaa2[i][j] = i+j;
+}
+  }
+}
+
+void parallel_for_with_nothing() {
+  #pragma omp parallel for
+  for (int i = 0 ; i < NNN ; i++) {
+#pragma omp nothing
+#pragma omp loop // expected-error{{region cannot be closely nested inside 'parallel for' region; perhaps you forget to enclose 'omp loop' directive into a parallel region?}}
+for (int j = 0 ; j < NNN ; j++) {
+  aaa2[i][j] = i+j;
+}
+  }
+}
+
+void parallel_targetfor_with_loop_bind() {
+  #pragma omp target teams distribute parallel for 
+  for (int i = 0 ; i < NNN ; i++) {
+#pragma omp loop bind(parallel) // expected-error{{region cannot be closely nested inside 'target teams distribute parallel for' region; perhaps you forget to enclose 'omp loop' directive into a parallel region?}}
+for (int j = 0 ; j < NNN ; j++) {
+  aaa2[i][j] = i+j;
+}
+  }
+}
+
+void loop_bind_AND_loop_bind() {
+  #pragma omp parallel for
+  for (int i = 0; i < 100; ++i) {
+#pragma omp loop bind(parallel) // expected-error{{region cannot be closely nested inside 'parallel for' region; perhaps you forget to enclose 'omp loop' directive into a parallel region?}} 
+for (int i = 0 ; i < NNN ; i++) {
+  #pragma omp loop bind(parallel) // expected-error{{region cannot be closely nested inside 'loop' region; perhaps you forget to enclose 'omp loop' directive into a parallel region?}} 
+  for (int j = 0 ; j < NNN ; j++) {
+aaa[j] = j*NNN;
+  }
+}
+  }
+}
+
 void teams_loop() {
   int var1, var2;
 
@@ -65,12 +110,65 @@
}
 }
 
+void orphan_loop_teams_bind(){
+  #pragma omp loop bind(teams)
+  for (int i = 0; i < NNN; i++) {
+aaa[i] = i+i*NNN;
+  }
+}
+
+void parallel_for_with_loop_teams_bind(){
+  #pragma omp parallel for
+  for (int i = 0; i < NNN; i++) {
+#pragma omp loop bind(teams) // expected-error{{region cannot be closely nested inside 'parallel for' region; perhaps you forget to enclose 'omp loop' directive into a teams region?}}
+for (int j = 0 ; j < NNN ; j++) {
+  aaa[i] = i+i*NNN;
+}
+  }
+}
+
+void parallel_with_sections_loop() {
+  #pragma omp parallel
+  {
+ #pragma omp sections
+ {
+for (int i = 0 ; i < NNN ; i++) {
+  #pragma omp loop bind(parallel) // expected-error{{region cannot be closely nested inside 'sections' region; perhaps you forget to enclose 'omp loop' directive into a parallel region?}}
+  for (int j = 0 ; j < NNN ; j++) {
+aaa2[i][j] = i+j;
+  }
+}
+
+#pragma omp section
+	{
+  aaa[NNN-1] = NNN;
+}
+ }
+  }
+}
+
+void teams_with_loop_thread_bind(){
+  #pragma omp teams
+  for (int i = 0; i < NNN; i++) {
+#pragma omp loop bind(thread)
+for (int j = 0 ; j < NNN ; j++) {
+  aaa[i] = i+i*NNN;
+}
+  }
+}
+
 int main(int argc, char *argv[]) {
   parallel_loop();
+  parallel_for_AND_loop_bind();
+  parallel_for_with_nothing();
+  parallel_targetfor_with_loop_bind();
   teams_loop();
   orphan_loop_with_bind();
   orphan_loop_no_bind();
   teams_loop_reduction();
+  orphan_loop_teams_bind();
+  parallel_for_with_loop_teams_bind();
+  parallel_with_sections_loop();
 }
 
 #endif
Index: clang/lib/Sema/SemaOpenMP.cpp
===
--- clang/lib/Sema/SemaOpenMP.cpp
+++ clan

[PATCH] D153114: [clangd] [C++20] [Modules] Support C++20 modules for clangd

2023-08-31 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu added a comment.

@sammccall @nridge while I am looking for the initial support for modules in 
clangd, I failed to find the mechanism to update files after I update a header 
file.

e.g., when I am opening the following file:

  // a.cc
  #include "a.h"
  ...

and there is a concurrent update to `a.h`. How can the ASTWorker of `a.cc` know 
such changes so that it can update the corresponding Preamble of `a.cc`?

In the comments of `ClangdServer::reparseOpenFilesIfNeeded()`, I see:

> /// Requests a reparse of currently opened files using their latest source.
> /// This will typically only rebuild if something other than the source has
> /// changed (e.g. the CDB yields different flags, or **files included in the
> /// preamble have been modified**).

So I thought this is what I want. However, I can't search the caller of 
`reparseOpenFilesIfNeeded` which semantics matches the behavior. The two 
callers of  `reparseOpenFilesIfNeeded` I found are 
`ClangdLSPServer::applyConfiguration()` and 
`ClangdLSPServer::onDocumentDidSave()` and neither of them matches description 
`files included in the  preamble have been modified`.

So I want to ask what's the behavior when I update a header and where is the 
corresponding code. Thanks.


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

https://reviews.llvm.org/D153114

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


[PATCH] D159247: [HLSL] Cleanup support for `this` as an l-value

2023-08-31 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin added a comment.

Thanks for working on this.
This is going to conflict with deducing this (https://reviews.llvm.org/D140828) 
in interesting (ie, horrible) ways, so i guess I'll have to deal with that.
For people following along we are trying to fix nasty lambda regression 
https://reviews.llvm.org/D159126, for which the present patch is needed so we 
probably needs to land the current patch before `deducing this`, which is less 
than ideal.

I do wonder if we do really need 3 functions though.

We ought to have `this` being either a pointer (C++), or a reference (HLSL), 
and the type of the object it points to.
It's unclear to me that we could not  just have 2 methods.

- getThisObjectType
- getThisType (as implemented in getThisArgType)

What would happen if we would:

- Make `getThisType` return a reference type (for HLSL)
- Explicitely remove the reference  where we need to

If that would be too verbose, maybe renaming would add some clarity
`getThisReferenceType` and `getThisType` - this would mirror what we do for 
deducing this (`getFunctionObjectParameterReferenceType` and 
`getFunctionObjectParameterType`)

Ultimately we can have:

- This being a pointer in C++
- This a reference in HLSL
- The object parameter being a reference or a pointer depending on whether it 
is explicit or not in C++23, or depending on whether we are using HLSL

Which is... not confusing at all !


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159247

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


[PATCH] D159106: [analyzer] ArrayBoundCheckerV2 should listen to check::Bind as well

2023-08-31 Thread Balázs Benics via Phabricator via cfe-commits
steakhal planned changes to this revision.
steakhal added a comment.

This patch would cause FPs on this code:

  struct S {};
  void zero_size_array() {
S arr[0];
(void)arr;
  }

Being short on time, I'll just drop this commit from the stack and come back in 
a late future.
This might be related to D131501 .


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159106

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


[PATCH] D153924: [OpenMP] Allow exceptions in target regions when offloading to GPUs

2023-08-31 Thread Hans Wennborg via Phabricator via cfe-commits
hans added inline comments.



Comment at: clang/test/OpenMP/amdgpu_exceptions.cpp:10
+
+// RUN: %clang_cc1 -fopenmp -triple amdgcn-amd-amdhsa 
-fopenmp-is-target-device -fcxx-exceptions -fexceptions %s -emit-llvm -S 
-verify=with -Wopenmp-target-exception -analyze
+// RUN: %clang_cc1 -fopenmp -triple amdgcn-amd-amdhsa 
-fopenmp-is-target-device -fcxx-exceptions -fexceptions %s -emit-llvm -S 
-verify=with -Wopenmp-target-exception -analyze

aeubanks wrote:
> I believe tests using `-analyze` need `REQUIRES: staticanalyzer`
Right, otherwise these fail in builds confiugured with 
-DCLANG_ENABLE_STATIC_ANALYZER=OFF.

Adding the requirement in 1968f0d7981df2d508c7c862d875b115837208b3.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D153924

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


[clang] 1968f0d - Add REQUIRES: staticanalyzer to some tests using clang -analyze

2023-08-31 Thread Hans Wennborg via cfe-commits

Author: Hans Wennborg
Date: 2023-08-31T09:37:04+02:00
New Revision: 1968f0d7981df2d508c7c862d875b115837208b3

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

LOG: Add REQUIRES: staticanalyzer to some tests using clang -analyze

Otherwise they fail in builds configured with
-DCLANG_ENABLE_STATIC_ANALYZER=OFF. Follow-up to
3c9988f85d2508bdbc64c81fed7c4b9b8db54262.

Added: 


Modified: 
clang/test/OpenMP/amdgpu_exceptions.cpp
clang/test/OpenMP/amdgpu_throw.cpp
clang/test/OpenMP/amdgpu_try_catch.cpp
clang/test/OpenMP/nvptx_exceptions.cpp
clang/test/OpenMP/nvptx_throw.cpp
clang/test/OpenMP/nvptx_try_catch.cpp
clang/test/OpenMP/x86_target_exceptions.cpp
clang/test/OpenMP/x86_target_throw.cpp
clang/test/OpenMP/x86_target_try_catch.cpp

Removed: 




diff  --git a/clang/test/OpenMP/amdgpu_exceptions.cpp 
b/clang/test/OpenMP/amdgpu_exceptions.cpp
index 0e62192c92e4cb..2bc1d4340f75c7 100644
--- a/clang/test/OpenMP/amdgpu_exceptions.cpp
+++ b/clang/test/OpenMP/amdgpu_exceptions.cpp
@@ -1,4 +1,4 @@
-// REQUIRES: amdgpu-registered-target
+// REQUIRES: amdgpu-registered-target, staticanalyzer
 
 /**
  * The first four lines test that a warning is produced when enabling 

diff  --git a/clang/test/OpenMP/amdgpu_throw.cpp 
b/clang/test/OpenMP/amdgpu_throw.cpp
index aa3d6b37a66982..c7248222d7efdb 100644
--- a/clang/test/OpenMP/amdgpu_throw.cpp
+++ b/clang/test/OpenMP/amdgpu_throw.cpp
@@ -1,4 +1,4 @@
-// REQUIRES: amdgpu-registered-target
+// REQUIRES: amdgpu-registered-target, staticanalyzer
 
 /**
  * The first four lines test that a warning is produced when enabling 

diff  --git a/clang/test/OpenMP/amdgpu_try_catch.cpp 
b/clang/test/OpenMP/amdgpu_try_catch.cpp
index 45552e0c2d5f46..76568f2cc69674 100644
--- a/clang/test/OpenMP/amdgpu_try_catch.cpp
+++ b/clang/test/OpenMP/amdgpu_try_catch.cpp
@@ -1,4 +1,4 @@
-// REQUIRES: amdgpu-registered-target
+// REQUIRES: amdgpu-registered-target, staticanalyzer
 
 /**
  * The first four lines test that a warning is produced when enabling 

diff  --git a/clang/test/OpenMP/nvptx_exceptions.cpp 
b/clang/test/OpenMP/nvptx_exceptions.cpp
index f30bd9da080cde..af283b0649d84d 100644
--- a/clang/test/OpenMP/nvptx_exceptions.cpp
+++ b/clang/test/OpenMP/nvptx_exceptions.cpp
@@ -1,4 +1,4 @@
-// REQUIRES: nvptx-registered-target
+// REQUIRES: nvptx-registered-target, staticanalyzer
 
 /**
  * The first four lines test that a warning is produced when enabling 

diff  --git a/clang/test/OpenMP/nvptx_throw.cpp 
b/clang/test/OpenMP/nvptx_throw.cpp
index f494fde8805bf6..8bc4366fcf7655 100644
--- a/clang/test/OpenMP/nvptx_throw.cpp
+++ b/clang/test/OpenMP/nvptx_throw.cpp
@@ -1,4 +1,4 @@
-// REQUIRES: nvptx-registered-target
+// REQUIRES: nvptx-registered-target, staticanalyzer
 
 /**
  * The first four lines test that a warning is produced when enabling 

diff  --git a/clang/test/OpenMP/nvptx_try_catch.cpp 
b/clang/test/OpenMP/nvptx_try_catch.cpp
index 417a6ec1db0b4d..0e9954c6e22322 100644
--- a/clang/test/OpenMP/nvptx_try_catch.cpp
+++ b/clang/test/OpenMP/nvptx_try_catch.cpp
@@ -1,4 +1,4 @@
-// REQUIRES: nvptx-registered-target
+// REQUIRES: nvptx-registered-target, staticanalyzer
 
 /**
  * The first four lines test that a warning is produced when enabling 

diff  --git a/clang/test/OpenMP/x86_target_exceptions.cpp 
b/clang/test/OpenMP/x86_target_exceptions.cpp
index effa76f0016dbe..5c02bcb92621bf 100644
--- a/clang/test/OpenMP/x86_target_exceptions.cpp
+++ b/clang/test/OpenMP/x86_target_exceptions.cpp
@@ -1,4 +1,4 @@
-// REQUIRES: x86-registered-target
+// REQUIRES: x86-registered-target, staticanalyzer
 
 // RUN: %clang_cc1 -fopenmp -triple x86_64-pc-linux-gnu 
-fopenmp-is-target-device -fcxx-exceptions -fexceptions %s -emit-llvm -S 
-verify -Wopenmp-target-exception -analyze
 #pragma omp declare target

diff  --git a/clang/test/OpenMP/x86_target_throw.cpp 
b/clang/test/OpenMP/x86_target_throw.cpp
index b55775287daa69..a9186bac43d63f 100644
--- a/clang/test/OpenMP/x86_target_throw.cpp
+++ b/clang/test/OpenMP/x86_target_throw.cpp
@@ -1,4 +1,4 @@
-// REQUIRES: x86-registered-target
+// REQUIRES: x86-registered-target, staticanalyzer
 
 // RUN: %clang_cc1 -fopenmp -triple x86_64-pc-linux-gnu 
-fopenmp-is-target-device -fcxx-exceptions -fexceptions %s -emit-llvm -S 
-verify -Wopenmp-target-exception -analyze
 #pragma omp declare target

diff  --git a/clang/test/OpenMP/x86_target_try_catch.cpp 
b/clang/test/OpenMP/x86_target_try_catch.cpp
index f18e6aaf99f90a..698af912c6ac15 100644
--- a/clang/test/OpenMP/x86_target_try_catch.cpp
+++ b/clang/test/OpenMP/x86_target_try_catch.cpp
@@ -1,4 +1,4 @@
-// REQUIRES: x86-registered-target
+// REQUIRES: x86-registered-target, staticanalyzer
 
 // RUN: %clang_cc1 -fopenmp -triple x86_64-pc-linux-gnu 
-

[PATCH] D159107: [analyzer] ArrayBoundCheckerV2 should disallow forming lvalues to out-of-bounds locations

2023-08-31 Thread Balázs Benics via Phabricator via cfe-commits
steakhal abandoned this revision.
steakhal added a comment.

In D159107#4627903 , @donat.nagy 
wrote:

> Good direction of development, this will be useful for providing better bug 
> reports (in addition to ensuring correct behavior some situations). 
> Note that it's also possible to dereference pointers with the operator `->`, 
> which is represented by `MemberExpr`s in the AST; we should probably handle 
> that as if it was a `UO_Deref`.

+1, +1

> There is also a small corner case that for an array `some_type arr[N]` it's 
> well-defined to form the past-the-end pointer as `&arr[N]` (instead of `arr + 
> N`) -- while any other use of `arr[N]` is undefined behavior. If this occurs 
> in practice, then we'll probably need some additional logic to handle it. 
> (Note that the `check::Location` implementation dodged this question, because 
> it didn't report anything when the program formed `&arr[N]`, but later 
> created a bug report when this pointer value was dereferenced.)

Ah, this disappoints me. You are right. This delayed mechanism definitely needs 
a more careful approach.

Given these concerns and the quality of the diagnostics, I don't think it's 
something easy to fix. I'll abandon this for now, to focus on the low-hanging 
patches to upstream.

Thanks for the thoughtful review! @donat.nagy




Comment at: clang/lib/StaticAnalyzer/Checkers/ArrayBoundCheckerV2.cpp:34
+class ArrayBoundCheckerV2
+: public Checker,
+ check::PostStmt> {

donat.nagy wrote:
> Which testcase would break without the `check::Bind` callback? (Not action 
> needed, I'm just curious.)
Good question. TO my surprise, no tests would be broken if we removed this 
callback.
Nice catch.
I thought it would break the new test added in D159106, but it would still pass.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159107

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


[PATCH] D159256: [NFC][Clang] Remove redundant function definitions

2023-08-31 Thread Juan Manuel Martinez Caamaño via Phabricator via cfe-commits
jmmartinez created this revision.
jmmartinez added a reviewer: jhuber6.
Herald added a project: All.
jmmartinez requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

There were 3 definitions of the mergeDefaultFunctionDefinitionAttributes
function: A private implementation, a version exposed in CodeGen, a
version exposed in CodeGenModule.

This patch removes the private and the CodeGenModule versions and keeps
a single definition in CodeGen.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D159256

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGCall.h
  clang/lib/CodeGen/CodeGenModule.h

Index: clang/lib/CodeGen/CodeGenModule.h
===
--- clang/lib/CodeGen/CodeGenModule.h
+++ clang/lib/CodeGen/CodeGenModule.h
@@ -1259,26 +1259,6 @@
   llvm::AttributeList &Attrs, unsigned &CallingConv,
   bool AttrOnCallSite, bool IsThunk);
 
-  /// Adds attributes to F according to our CodeGenOptions and LangOptions, as
-  /// though we had emitted it ourselves.  We remove any attributes on F that
-  /// conflict with the attributes we add here.
-  ///
-  /// This is useful for adding attrs to bitcode modules that you want to link
-  /// with but don't control, such as CUDA's libdevice.  When linking with such
-  /// a bitcode library, you might want to set e.g. its functions'
-  /// "unsafe-fp-math" attribute to match the attr of the functions you're
-  /// codegen'ing.  Otherwise, LLVM will interpret the bitcode module's lack of
-  /// unsafe-fp-math attrs as tantamount to unsafe-fp-math=false, and then LLVM
-  /// will propagate unsafe-fp-math=false up to every transitive caller of a
-  /// function in the bitcode library!
-  ///
-  /// With the exception of fast-math attrs, this will only make the attributes
-  /// on the function more conservative.  But it's unsafe to call this on a
-  /// function which relies on particular fast-math attributes for correctness.
-  /// It's up to you to ensure that this is safe.
-  void mergeDefaultFunctionDefinitionAttributes(llvm::Function &F,
-bool WillInternalize);
-
   /// Like the overload taking a `Function &`, but intended specifically
   /// for frontends that want to build on Clang's target-configuration logic.
   void addDefaultFunctionDefinitionAttributes(llvm::AttrBuilder &attrs);
Index: clang/lib/CodeGen/CGCall.h
===
--- clang/lib/CodeGen/CGCall.h
+++ clang/lib/CodeGen/CGCall.h
@@ -395,10 +395,25 @@
   bool isExternallyDestructed() const { return IsExternallyDestructed; }
 };
 
-/// Helper to add attributes to \p F according to the CodeGenOptions and
-/// LangOptions without requiring a CodeGenModule to be constructed.
+/// Adds attributes to \p F according to our \p CodeGenOpts and \p LangOpts, as
+/// though we had emitted it ourselves. We remove any attributes on F that
+/// conflict with the attributes we add here.
+///
+/// This is useful for adding attrs to bitcode modules that you want to link
+/// with but don't control, such as CUDA's libdevice.  When linking with such
+/// a bitcode library, you might want to set e.g. its functions'
+/// "unsafe-fp-math" attribute to match the attr of the functions you're
+/// codegen'ing.  Otherwise, LLVM will interpret the bitcode module's lack of
+/// unsafe-fp-math attrs as tantamount to unsafe-fp-math=false, and then LLVM
+/// will propagate unsafe-fp-math=false up to every transitive caller of a
+/// function in the bitcode library!
+///
+/// With the exception of fast-math attrs, this will only make the attributes
+/// on the function more conservative.  But it's unsafe to call this on a
+/// function which relies on particular fast-math attributes for correctness.
+/// It's up to you to ensure that this is safe.
 void mergeDefaultFunctionDefinitionAttributes(llvm::Function &F,
-  const CodeGenOptions CodeGenOpts,
+  const CodeGenOptions &CodeGenOpts,
   const LangOptions &LangOpts,
   const TargetOptions &TargetOpts,
   bool WillInternalize);
Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -2002,10 +2002,7 @@
   }
 }
 
-/// Adds attributes to \p F according to our \p CodeGenOpts and \p LangOpts, as
-/// though we had emitted it ourselves. We remove any attributes on F that
-/// conflict with the attributes we add here.
-static void mergeDefaultFunctionDefinitionAttributes(
+void CodeGen::mergeDefaultFunctionDefinitionAttributes(
 llvm::Function &F, const CodeGenOptions &C

[PATCH] D153114: [clangd] [C++20] [Modules] Support C++20 modules for clangd

2023-08-31 Thread Nathan Ridge via Phabricator via cfe-commits
nridge added a comment.

In D153114#4630318 , @ChuanqiXu wrote:

> However, I can't search the caller of `reparseOpenFilesIfNeeded` which 
> semantics matches the behavior. The two callers of  
> `reparseOpenFilesIfNeeded` I found are 
> `ClangdLSPServer::applyConfiguration()` and 
> `ClangdLSPServer::onDocumentDidSave()` and neither of them matches 
> description `files included in the  preamble have been modified`.
>
> So I want to ask what's the behavior when I update a header and where is the 
> corresponding code. Thanks.

I'm afraid `onDocumentDidSave()` is all we have for now. It detects changes to 
the header when editing the header in the client (when the header is saved). I 
don't believe we have a mechanism for detecting changes to the header made in 
other ways.

If/when we want to add such a mechanism, I think the way to do it is using 
didChangeWatchedFiles 

 (there is some discussion there about why LSP recommends servers delegate 
file-watching to the client rather than implementing file-watching in the 
server).


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

https://reviews.llvm.org/D153114

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


[PATCH] D159256: [NFC][Clang] Remove redundant function definitions

2023-08-31 Thread Juan Manuel Martinez Caamaño via Phabricator via cfe-commits
jmmartinez added a comment.

@jhuber6 I was wondering if there is a reason you kept 3 versions of 
`mergeDefaultFunctionDefinitionAttributes` in https://reviews.llvm.org/D152391 ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159256

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


[PATCH] D153114: [clangd] [C++20] [Modules] Support C++20 modules for clangd

2023-08-31 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu added a comment.

In D153114#4630408 , @nridge wrote:

> In D153114#4630318 , @ChuanqiXu 
> wrote:
>
>> However, I can't search the caller of `reparseOpenFilesIfNeeded` which 
>> semantics matches the behavior. The two callers of  
>> `reparseOpenFilesIfNeeded` I found are 
>> `ClangdLSPServer::applyConfiguration()` and 
>> `ClangdLSPServer::onDocumentDidSave()` and neither of them matches 
>> description `files included in the  preamble have been modified`.
>>
>> So I want to ask what's the behavior when I update a header and where is the 
>> corresponding code. Thanks.
>
> I'm afraid `onDocumentDidSave()` is all we have for now. It detects changes 
> to the header when editing the header in the client (when the header is 
> saved). I don't believe we have a mechanism for detecting changes to the 
> header made in other ways.

IIUC, when we open `a.cpp` and `b.h` (there is no relationship between them), 
and we edit and save `b.h`, then the AST Worker of `a.cpp` will receive a 
request to update `a.cpp`. Did I understand correct? I imaged there may be an 
early exit point in the path of `ASTWorker::update` or `PreambleThread::update` 
if we detects the preamble doesn't change actually. But I failed to find it.

> If/when we want to add such a mechanism, I think the way to do it is using 
> didChangeWatchedFiles (there is some discussion there about why LSP 
> recommends servers delegate file-watching to the client rather than 
> implementing file-watching in the server).

Got it. And I am wondering the reason we didn't implement it may be that it is 
not so bad actually. Since a user generally won't open too many tabs. Do I 
understand right? And if it is the case, maybe we need to look at it in the 
future since it may be a concern with modules.


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

https://reviews.llvm.org/D153114

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


[clang] c2bf9ba - Add a concept AST node.

2023-08-31 Thread Jens Massberg via cfe-commits

Author: Jens Massberg
Date: 2023-08-31T10:22:21+02:00
New Revision: c2bf9baf59870532d0c503066634bf438c35184f

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

LOG: Add a concept AST node.

This patch adds a concept AST node (`ConceptLoc`) and uses it at the 
corresponding places.

There are three objects that might have constraints via concepts:
`TypeConstraint`,  `ConceptSpecializationExpr` and `AutoTypeLoc`.
The first two inherit from `ConceptReference` while the latter has
the information about a possible constraint directly stored in 
`AutoTypeLocInfo`. It would be nice if the concept information would be stored 
the same way in all three cases.

Moreover the current structure makes it difficult to deal with these concepts. 
For example in Clangd accessing the locations of constraints of a `AutoTypeLoc` 
can only be done with quite ugly hacks.

So we think that it makes sense to create a new AST node for such concepts.

In details we propose the following:
- Rename `ConceptReference` to `ConceptLoc` (or something else what is 
approriate)
and make it the new AST node.
- `TypeConstraint` and `ConceptSpecializationExpr` do not longer inherit from 
`ConceptReference` but store a pointer to a `ConceptLoc`.
- `AutoTypeLoc` stores a pointer to `ConceptLoc` instead of storing the concept 
info in `AutoTypeLocInfo`.

This patch implements a first version of this idea which compiles and where the 
existing tests pass.
To make this patch as small as possible we keep the existing member functions 
to access concept data. Later these can be replaced by directly calling the 
corresponding functions of the `ConceptLoc`s.

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

Added: 


Modified: 
clang/include/clang/AST/ASTConcept.h
clang/include/clang/AST/DeclTemplate.h
clang/include/clang/AST/ExprConcepts.h
clang/include/clang/AST/RecursiveASTVisitor.h
clang/include/clang/AST/TypeLoc.h
clang/include/clang/Serialization/ASTRecordReader.h
clang/include/clang/Serialization/ASTRecordWriter.h
clang/lib/AST/ASTContext.cpp
clang/lib/AST/ASTImporter.cpp
clang/lib/AST/DeclTemplate.cpp
clang/lib/AST/ExprConcepts.cpp
clang/lib/AST/TypeLoc.cpp
clang/lib/Sema/SemaTemplate.cpp
clang/lib/Sema/SemaTemplateInstantiate.cpp
clang/lib/Sema/SemaType.cpp
clang/lib/Sema/TreeTransform.h
clang/lib/Serialization/ASTReader.cpp
clang/lib/Serialization/ASTReaderDecl.cpp
clang/lib/Serialization/ASTReaderStmt.cpp
clang/lib/Serialization/ASTWriter.cpp
clang/lib/Serialization/ASTWriterDecl.cpp
clang/lib/Serialization/ASTWriterStmt.cpp
clang/unittests/AST/SourceLocationTest.cpp
clang/unittests/Tooling/RecursiveASTVisitorTests/Concept.cpp

Removed: 




diff  --git a/clang/include/clang/AST/ASTConcept.h 
b/clang/include/clang/AST/ASTConcept.h
index e6e2d57597ea02..832918785434d4 100644
--- a/clang/include/clang/AST/ASTConcept.h
+++ b/clang/include/clang/AST/ASTConcept.h
@@ -14,7 +14,9 @@
 #ifndef LLVM_CLANG_AST_ASTCONCEPT_H
 #define LLVM_CLANG_AST_ASTCONCEPT_H
 
+#include "clang/AST/Decl.h"
 #include "clang/AST/Expr.h"
+#include "clang/AST/PrettyPrinter.h"
 #include "clang/Basic/SourceLocation.h"
 #include "llvm/ADT/PointerUnion.h"
 #include "llvm/ADT/SmallVector.h"
@@ -107,10 +109,18 @@ struct ASTConstraintSatisfaction final :
   Rebuild(const ASTContext &C, const ASTConstraintSatisfaction &Satisfaction);
 };
 
-/// \brief Common data class for constructs that reference concepts with
-/// template arguments.
+/// A reference to a concept and its template args, as it appears in the code.
+///
+/// Examples:
+///   template  requires is_even int half = X/2;
+/// ~~ (in ConceptSpecializationExpr)
+///
+///   std::input_iterator auto I = Container.begin();
+///   ~~~ (in AutoTypeLoc)
+///
+///   template  T> void dump();
+/// ~~~ (in TemplateTypeParmDecl)
 class ConceptReference {
-protected:
   // \brief The optional nested name specifier used when naming the concept.
   NestedNameSpecifierLoc NestedNameSpec;
 
@@ -134,7 +144,6 @@ class ConceptReference {
   /// concept.
   const ASTTemplateArgumentListInfo *ArgsAsWritten;
 
-public:
   ConceptReference(NestedNameSpecifierLoc NNS, SourceLocation TemplateKWLoc,
DeclarationNameInfo ConceptNameInfo, NamedDecl *FoundDecl,
ConceptDecl *NamedConcept,
@@ -143,8 +152,15 @@ class ConceptReference {
 ConceptName(ConceptNameInfo), FoundDecl(FoundDecl),
 NamedConcept(NamedConcept), ArgsAsWritten(ArgsAsWritten) {}
 
-  ConceptReference()
-  : FoundDecl(nullptr), NamedConcept(nullptr), ArgsAsWritten(nullptr) {}
+public:
+  static ConceptReference *
+  

[PATCH] D155858: Add a concept AST node.

2023-08-31 Thread Jens Massberg 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 rGc2bf9baf5987: Add a concept AST node. (authored by massberg).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D155858

Files:
  clang/include/clang/AST/ASTConcept.h
  clang/include/clang/AST/DeclTemplate.h
  clang/include/clang/AST/ExprConcepts.h
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/AST/TypeLoc.h
  clang/include/clang/Serialization/ASTRecordReader.h
  clang/include/clang/Serialization/ASTRecordWriter.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ASTImporter.cpp
  clang/lib/AST/DeclTemplate.cpp
  clang/lib/AST/ExprConcepts.cpp
  clang/lib/AST/TypeLoc.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/lib/Sema/SemaType.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTReaderDecl.cpp
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/lib/Serialization/ASTWriterDecl.cpp
  clang/lib/Serialization/ASTWriterStmt.cpp
  clang/unittests/AST/SourceLocationTest.cpp
  clang/unittests/Tooling/RecursiveASTVisitorTests/Concept.cpp

Index: clang/unittests/Tooling/RecursiveASTVisitorTests/Concept.cpp
===
--- clang/unittests/Tooling/RecursiveASTVisitorTests/Concept.cpp
+++ clang/unittests/Tooling/RecursiveASTVisitorTests/Concept.cpp
@@ -29,12 +29,22 @@
 ++ConceptRequirementsTraversed;
 return ExpectedLocationVisitor::TraverseConceptRequirement(R);
   }
+  bool TraverseConceptReference(ConceptReference *CR) {
+++ConceptReferencesTraversed;
+return ExpectedLocationVisitor::TraverseConceptReference(CR);
+  }
+  bool VisitConceptReference(ConceptReference *CR) {
+++ConceptReferencesVisited;
+return true;
+  }
 
   bool shouldVisitImplicitCode() { return ShouldVisitImplicitCode; }
 
   int ConceptSpecializationExprsVisited = 0;
   int TypeConstraintsTraversed = 0;
   int ConceptRequirementsTraversed = 0;
+  int ConceptReferencesTraversed = 0;
+  int ConceptReferencesVisited = 0;
   bool ShouldVisitImplicitCode = false;
 };
 
@@ -50,6 +60,8 @@
   EXPECT_EQ(1, Visitor.ConceptSpecializationExprsVisited);
   // Also check we traversed the TypeConstraint that produced the expr.
   EXPECT_EQ(1, Visitor.TypeConstraintsTraversed);
+  EXPECT_EQ(1, Visitor.ConceptReferencesTraversed);
+  EXPECT_EQ(1, Visitor.ConceptReferencesVisited);
 
   Visitor = {}; // Don't visit implicit code now.
   EXPECT_TRUE(Visitor.runOver("template  concept Fooable = true;\n"
@@ -59,6 +71,8 @@
   // generated immediately declared expression.
   EXPECT_EQ(0, Visitor.ConceptSpecializationExprsVisited);
   EXPECT_EQ(1, Visitor.TypeConstraintsTraversed);
+  EXPECT_EQ(1, Visitor.ConceptReferencesTraversed);
+  EXPECT_EQ(1, Visitor.ConceptReferencesVisited);
 
   Visitor = {};
   EXPECT_TRUE(Visitor.runOver("template  concept A = true;\n"
@@ -70,6 +84,8 @@
   "};",
   ConceptVisitor::Lang_CXX2a));
   EXPECT_EQ(3, Visitor.ConceptRequirementsTraversed);
+  EXPECT_EQ(1, Visitor.ConceptReferencesTraversed);
+  EXPECT_EQ(1, Visitor.ConceptReferencesVisited);
 }
 
 struct VisitDeclOnlyOnce : ExpectedLocationVisitor {
@@ -86,6 +102,10 @@
 ++AutoTypeLocVisited;
 return true;
   }
+  bool VisitConceptReference(ConceptReference *) {
+++ConceptReferencesVisited;
+return true;
+  }
 
   bool TraverseVarDecl(VarDecl *V) {
 // The base traversal visits only the `TypeLoc`.
@@ -99,6 +119,7 @@
   int ConceptDeclsVisited = 0;
   int AutoTypeVisited = 0;
   int AutoTypeLocVisited = 0;
+  int ConceptReferencesVisited = 0;
 };
 
 TEST(RecursiveASTVisitor, ConceptDeclInAutoType) {
@@ -111,6 +132,7 @@
   EXPECT_EQ(1, Visitor.AutoTypeVisited);
   EXPECT_EQ(1, Visitor.AutoTypeLocVisited);
   EXPECT_EQ(1, Visitor.ConceptDeclsVisited);
+  EXPECT_EQ(1, Visitor.ConceptReferencesVisited);
 }
 
 } // end anonymous namespace
Index: clang/unittests/AST/SourceLocationTest.cpp
===
--- clang/unittests/AST/SourceLocationTest.cpp
+++ clang/unittests/AST/SourceLocationTest.cpp
@@ -16,7 +16,11 @@
 //===--===//
 
 #include "MatchVerifier.h"
+#include "clang/AST/ASTConcept.h"
 #include "clang/AST/ASTContext.h"
+#include "clang/AST/ASTFwd.h"
+#include "clang/AST/DeclTemplate.h"
+#include "clang/AST/ExprConcepts.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/ASTMatchers/ASTMatchers.h"
 #include "clang/Tooling/Tooling.h"
@@ -370,10 +374,10 @@
 TEST(CompoundLiteralExpr, ParensCompoundVectorLiteralRange) {
   RangeVerifier Verifier;
   Verifier.expectRange(2, 20, 2, 31);
-  EXPECT_TRUE(Verifier.match(
-  

[PATCH] D158614: [UBSan] Disable the function sanitizer on an execute-only target.

2023-08-31 Thread Ying Yi via Phabricator via cfe-commits
MaggieYi added a comment.

Thanks @MaskRay.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158614

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


[PATCH] D153114: [clangd] [C++20] [Modules] Support C++20 modules for clangd

2023-08-31 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

In D153114#4630318 , @ChuanqiXu wrote:

> @sammccall @nridge while I am looking for the initial support for modules in 
> clangd, I failed to find the mechanism to update files after I update a 
> header file.
>
> e.g., when I am opening the following file:
>
>   // a.cc
>   #include "a.h"
>   ...
>
> and there is a concurrent update to `a.h`. How can the ASTWorker of `a.cc` 
> know such changes so that it can update the corresponding Preamble of `a.cc`?

The PrecompiledPreamble structure (defined in clang, not clangd) consists of a 
handle to the `*.pch` file, and also a list of filenames that it was built 
from. We can test whether it's out of date by `stat()`ing the input files 
(`PrecompiledPreamble::CanReuse`).

Once upon a time, clangd used this in a simple way: the ASTWorker always called 

 [`clangd::buildPreamble(inputs, old 
preamble)`](https://github.com/llvm/llvm-project/blob/release/10.x/clang-tools-extra/clangd/Preamble.cpp#L101-L107)
 which would just return the old one if it was still valid.

For a while now we've had async preambles which are more complicated but use 
the same underlying mechanism. Each file has an ASTWorker thread and a 
PreambleThread. When the ASTWorker thread wants to reuse preamble, it notifies 
the PreambleThread "hey, maybe rebuild the preamble?" but meanwhile it charges 
on using the old stale preamble. The preamble asynchronously performs the 
validity check 
,
 rebuilds the preamble if needed, and eventually informs the ASTWorker which 
ensures the up-to-date preamble is eventually used.

This is a "pull" system: we only check if the preamble is valid when we tried 
to use it, i.e. when the main-file changed. If you just touch a header on disk 
but do nothing else, we won't rebuild either the main file or the preamble.

> In the comments of `ClangdServer::reparseOpenFilesIfNeeded()`, I see:
>
>> /// Requests a reparse of currently opened files using their latest source.
>> /// This will typically only rebuild if something other than the source has
>> /// changed (e.g. the CDB yields different flags, or **files included in the
>> /// preamble have been modified**).

Because the above is a pull system, editing a header doesn't update e.g. 
diagnostics in files that include that header.
So this is a workaround: it requests all files to be rebuilt from current 
sources, so we pull on all preambles.
Then at every layer we try to ensure this does no work if nothing has changed 
:-)

In practice we call this in response to didSave (user edited+saved a header in 
their editor), we could potentially call it in response to changes on disk as 
Nathan suggested, and I think we have a custom integration somewhere that calls 
it when we know externally that compile flags have changed.


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

https://reviews.llvm.org/D153114

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


[PATCH] D159206: [Clang] Propagate target-features if compatible when using mlink-builtin-bitcode

2023-08-31 Thread Juan Manuel Martinez Caamaño via Phabricator via cfe-commits
jmmartinez updated this revision to Diff 554934.
jmmartinez added a comment.

- Rollback, drop incompatible functions in a separate commit


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159206

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGCall.h
  clang/test/CodeGen/link-builtin-bitcode.c
  clang/test/CodeGenCUDA/link-builtin-bitcode-gpu-attrs-preserved.cu

Index: clang/test/CodeGenCUDA/link-builtin-bitcode-gpu-attrs-preserved.cu
===
--- clang/test/CodeGenCUDA/link-builtin-bitcode-gpu-attrs-preserved.cu
+++ clang/test/CodeGenCUDA/link-builtin-bitcode-gpu-attrs-preserved.cu
@@ -31,7 +31,7 @@
 
 
 // CHECK: define {{.*}} i64 @do_intrin_stuff() #[[ATTR:[0-9]+]]
-// INTERNALIZE: attributes #[[ATTR]] = {{.*}} "target-cpu"="gfx{{.*}}" "target-features"="+gfx11-insts"
+// INTERNALIZE: attributes #[[ATTR]] = {{.*}} "target-cpu"="gfx{{.*}}" "target-features"="{{.*}}+gfx11-insts{{.*}}"
 // NOINTERNALIZE: attributes #[[ATTR]] = {{.*}} "target-features"="+gfx11-insts"
 
 #define __device__ __attribute__((device))
Index: clang/test/CodeGen/link-builtin-bitcode.c
===
--- clang/test/CodeGen/link-builtin-bitcode.c
+++ clang/test/CodeGen/link-builtin-bitcode.c
@@ -1,42 +1,50 @@
-// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --check-attributes --check-globals --include-generated-funcs --version 2
+// Build two version of the bitcode library, one with a target-cpu set and one without
 // RUN: %clang_cc1 -triple amdgcn-- -target-cpu gfx803 -DBITCODE -emit-llvm-bc -o %t-lib.bc %s
+// RUN: %clang_cc1 -triple amdgcn-- -DBITCODE -emit-llvm-bc -o %t-lib.no-cpu.bc %s
+
+// RUN: %clang_cc1 -triple amdgcn-- -target-cpu gfx90a -emit-llvm-bc -o %t.bc %s
+// RUN: %clang_cc1 -triple amdgcn-- -target-cpu gfx90a -emit-llvm \
+// RUN:   -mlink-builtin-bitcode %t-lib.bc -o - %t.bc | FileCheck %s --check-prefixes=CHECK,CPU
+
 // RUN: %clang_cc1 -triple amdgcn-- -target-cpu gfx90a -emit-llvm-bc -o %t.bc %s
 // RUN: %clang_cc1 -triple amdgcn-- -target-cpu gfx90a -emit-llvm \
-// RUN:   -mlink-builtin-bitcode %t-lib.bc -o - %t.bc | FileCheck %s
+// RUN:   -mlink-builtin-bitcode %t-lib.no-cpu.bc -o - %t.bc | FileCheck %s --check-prefixes=CHECK,NOCPU
 
 #ifdef BITCODE
-int foo(void) { return 42; }
+int no_attr(void) { return 42; }
+int __attribute__((target("gfx8-insts"))) attr_in_target(void) { return 42; }
+int __attribute__((target("extended-image-insts"))) attr_not_in_target(void) { return 42; }
+int __attribute__((target("no-gfx9-insts"))) attr_incompatible(void) { return 42; }
 int x = 12;
 #endif
 
-extern int foo(void);
+extern int no_attr(void);
+extern int attr_in_target(void);
+extern int attr_not_in_target(void);
+extern int attr_incompatible(void);
 extern int x;
 
-int bar() { return foo() + x; }
-//.
+int bar() { return no_attr() + attr_in_target() + attr_not_in_target() + attr_incompatible() + x; }
+
 // CHECK: @x = internal addrspace(1) global i32 12, align 4
-//.
-// CHECK: Function Attrs: noinline nounwind optnone
+
 // CHECK-LABEL: define dso_local i32 @bar
-// CHECK-SAME: () #[[ATTR0:[0-9]+]] {
-// CHECK-NEXT:  entry:
-// CHECK-NEXT:[[RETVAL:%.*]] = alloca i32, align 4, addrspace(5)
-// CHECK-NEXT:[[RETVAL_ASCAST:%.*]] = addrspacecast ptr addrspace(5) [[RETVAL]] to ptr
-// CHECK-NEXT:[[CALL:%.*]] = call i32 @foo()
-// CHECK-NEXT:[[TMP0:%.*]] = load i32, ptr addrspacecast (ptr addrspace(1) @x to ptr), align 4
-// CHECK-NEXT:[[ADD:%.*]] = add nsw i32 [[CALL]], [[TMP0]]
-// CHECK-NEXT:ret i32 [[ADD]]
+// CHECK-SAME: () #[[ATTR_BAR:[0-9]+]] {
 //
-//
-// CHECK: Function Attrs: convergent noinline nounwind optnone
-// CHECK-LABEL: define internal i32 @foo
-// CHECK-SAME: () #[[ATTR1:[0-9]+]] {
-// CHECK-NEXT:  entry:
-// CHECK-NEXT:[[RETVAL:%.*]] = alloca i32, align 4, addrspace(5)
-// CHECK-NEXT:[[RETVAL_ASCAST:%.*]] = addrspacecast ptr addrspace(5) [[RETVAL]] to ptr
-// CHECK-NEXT:ret i32 42
-//
-//.
-// CHECK: attributes #0 = { noinline nounwind optnone "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="gfx90a" "target-features"="+16-bit-insts,+atomic-buffer-global-pk-add-f16-insts,+atomic-fadd-rtn-insts,+ci-insts,+dl-insts,+dot1-insts,+dot10-insts,+dot2-insts,+dot3-insts,+dot4-insts,+dot5-insts,+dot6-insts,+dot7-insts,+dpp,+gfx8-insts,+gfx9-insts,+gfx90a-insts,+mai-insts,+s-memrealtime,+s-memtime-inst,+wavefrontsize64" }
-// CHECK: attributes #1 = { convergent noinline nounwind optnone "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="gfx90a" "target-features"="+16-bit-insts,+ci-insts,+dpp,+gfx8-insts,+s-memrealtime,+s-memtime-inst,+wavefrontsize64" }
-//.
+// CHECK-LABEL: define internal i32 @no_attr
+// CHECK-SAME: () #[[ATTR_COMPATIBLE:[0-9]+]] {
+
+// CHECK-LABEL: define inte

[PATCH] D159257: [Clang] Drop functions with incompatible target-features when using mlink-builtin-bitcode

2023-08-31 Thread Juan Manuel Martinez Caamaño via Phabricator via cfe-commits
jmmartinez created this revision.
jmmartinez added reviewers: arsenm, Pierre-vh, yaxunl, jhuber6.
Herald added a project: All.
jmmartinez requested review of this revision.
Herald added subscribers: cfe-commits, wdng.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D159257

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGCall.h
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/test/CodeGen/link-builtin-bitcode.c


Index: clang/test/CodeGen/link-builtin-bitcode.c
===
--- clang/test/CodeGen/link-builtin-bitcode.c
+++ clang/test/CodeGen/link-builtin-bitcode.c
@@ -4,11 +4,11 @@
 
 // RUN: %clang_cc1 -triple amdgcn-- -target-cpu gfx90a -emit-llvm-bc -o %t.bc 
%s
 // RUN: %clang_cc1 -triple amdgcn-- -target-cpu gfx90a -emit-llvm \
-// RUN:   -mlink-builtin-bitcode %t-lib.bc -o - %t.bc | FileCheck %s 
--check-prefixes=CHECK,CPU
+// RUN:   -mlink-builtin-bitcode %t-lib.bc -o - %t.bc | FileCheck %s
 
 // RUN: %clang_cc1 -triple amdgcn-- -target-cpu gfx90a -emit-llvm-bc -o %t.bc 
%s
 // RUN: %clang_cc1 -triple amdgcn-- -target-cpu gfx90a -emit-llvm \
-// RUN:   -mlink-builtin-bitcode %t-lib.no-cpu.bc -o - %t.bc | FileCheck %s 
--check-prefixes=CHECK,NOCPU
+// RUN:   -mlink-builtin-bitcode %t-lib.no-cpu.bc -o - %t.bc | FileCheck %s
 
 #ifdef BITCODE
 int no_attr(void) { return 42; }
@@ -40,11 +40,8 @@
 // CHECK-LABEL: define internal i32 @attr_not_in_target
 // CHECK-SAME: () #[[ATTR_EXTEND:[0-9]+]] {
 
-// CHECK-LABEL: @attr_incompatible
-// CHECK-SAME: () #[[ATTR_INCOMPATIBLE:[0-9]+]] {
+// CHECK-NOT: @attr_incompatible
 
 // CHECK: attributes #[[ATTR_BAR]] = { noinline nounwind optnone 
"no-trapping-math"="true" "stack-protector-buffer-size"="8" 
"target-cpu"="gfx90a" 
"target-features"="+16-bit-insts,+atomic-buffer-global-pk-add-f16-insts,+atomic-fadd-rtn-insts,+ci-insts,+dl-insts,+dot1-insts,+dot10-insts,+dot2-insts,+dot3-insts,+dot4-insts,+dot5-insts,+dot6-insts,+dot7-insts,+dpp,+gfx8-insts,+gfx9-insts,+gfx90a-insts,+mai-insts,+s-memrealtime,+s-memtime-inst,+wavefrontsize64"
 }
 // CHECK: attributes #[[ATTR_COMPATIBLE]] = { convergent noinline nounwind 
optnone "no-trapping-math"="true" "stack-protector-buffer-size"="8" 
"target-cpu"="gfx90a" 
"target-features"="+16-bit-insts,+atomic-buffer-global-pk-add-f16-insts,+atomic-fadd-rtn-insts,+ci-insts,+dl-insts,+dot1-insts,+dot10-insts,+dot2-insts,+dot3-insts,+dot4-insts,+dot5-insts,+dot6-insts,+dot7-insts,+dpp,+gfx8-insts,+gfx9-insts,+gfx90a-insts,+gws,+image-insts,+mai-insts,+s-memrealtime,+s-memtime-inst,+wavefrontsize64"
 }
 // CHECK: attributes #[[ATTR_EXTEND]] = { convergent noinline nounwind optnone 
"no-trapping-math"="true" "stack-protector-buffer-size"="8" 
"target-cpu"="gfx90a" 
"target-features"="+16-bit-insts,+atomic-buffer-global-pk-add-f16-insts,+atomic-fadd-rtn-insts,+ci-insts,+dl-insts,+dot1-insts,+dot10-insts,+dot2-insts,+dot3-insts,+dot4-insts,+dot5-insts,+dot6-insts,+dot7-insts,+dpp,+gfx8-insts,+gfx9-insts,+gfx90a-insts,+gws,+image-insts,+mai-insts,+s-memrealtime,+s-memtime-inst,+wavefrontsize64,+extended-image-insts"
 }
-// CPU: attributes #[[ATTR_INCOMPATIBLE]] = { convergent noinline nounwind 
optnone "no-trapping-math"="true" "stack-protector-buffer-size"="8" 
"target-cpu"="gfx90a" 
"target-features"="+16-bit-insts,+ci-insts,+dpp,+gfx8-insts,+s-memrealtime,+s-memtime-inst,+wavefrontsize64,-gfx9-insts"
 }
-// NOCPU: attributes #[[ATTR_INCOMPATIBLE]] = { convergent noinline nounwind 
optnone "no-trapping-math"="true" "stack-protector-buffer-size"="8" 
"target-cpu"="gfx90a" "target-features"="-gfx9-insts" }
Index: clang/lib/CodeGen/CodeGenAction.cpp
===
--- clang/lib/CodeGen/CodeGenAction.cpp
+++ clang/lib/CodeGen/CodeGenAction.cpp
@@ -267,11 +267,13 @@
   for (auto &LM : LinkModules) {
 assert(LM.Module && "LinkModule does not actually have a module");
 if (LM.PropagateAttrs)
-  for (Function &F : *LM.Module) {
+  for (Function &F : llvm::make_early_inc_range(*LM.Module)) {
 // Skip intrinsics. Keep consistent with how intrinsics are created
 // in LLVM IR.
 if (F.isIntrinsic())
   continue;
+if (CodeGen::dropFunctionWithIncompatibleAttributes(F, TargetOpts))
+  continue;
 CodeGen::mergeDefaultFunctionDefinitionAttributes(
 F, CodeGenOpts, LangOpts, TargetOpts, LM.Internalize);
   }
Index: clang/lib/CodeGen/CGCall.h
===
--- clang/lib/CodeGen/CGCall.h
+++ clang/lib/CodeGen/CGCall.h
@@ -395,6 +395,11 @@
   bool isExternallyDestructed() const { return IsExternallyDestructed; }
 };
 
+/// If \p F "target-features" are incompatible with the \p TargetOpts features,
+/// it is correct to drop the function. \return true if \p F is dropped
+bool dropFunctionWithIncompa

[PATCH] D153114: [clangd] [C++20] [Modules] Support C++20 modules for clangd

2023-08-31 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu added a comment.

Got it. Thanks for your explanation. I can continue my experiment : )


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

https://reviews.llvm.org/D153114

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


[PATCH] D159188: [AArch64][SME] Make the overloaded svreinterpret_* functions streaming-compatible.

2023-08-31 Thread David Sherwood via Phabricator via cfe-commits
david-arm added inline comments.



Comment at: clang/include/clang/Basic/Attr.td:418
 def TargetARM : TargetArch<["arm", "thumb", "armeb", "thumbeb"]>;
-def TargetAArch64 : TargetArch<["aarch64"]>;
+def TargetAArch64 : TargetArch<["aarch64", "aarch64_be"]>;
 def TargetAnyArm : TargetArch;

I'm not sure why this change is included in this patch?



Comment at: clang/test/CodeGen/attr-arm-sve-vector-bits-types.c:6
 // RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve 
-target-feature +bf16 -mvscale-min=16 -mvscale-max=16 -S -emit-llvm -o - %s | 
FileCheck %s --check-prefix=CHECK-2048
-// RUN: %clang_cc1 -triple aarch64_32-unknown-darwin -target-feature +sve 
-target-feature +bf16 -mvscale-min=4 -mvscale-max=4 -S -emit-llvm -o - %s | 
FileCheck %s --check-prefix=CHECK-ILP32
 

I can see this line looks redundant, but is it supposed to be related to the 
other changes?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159188

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


[PATCH] D159107: [analyzer] ArrayBoundCheckerV2 should disallow forming lvalues to out-of-bounds locations

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

I don't think that the `&arr[N]` issue is too serious: we can just increment 
the array extent when the parent expression of the array subscript operator is 
the unary operator `&`. If the past-the-end pointer ends up dereferenced later, 
the current code is sufficient to report it as a bug (as the checker monitors 
all dereferences).

I'd be happy to see (a slightly extended variant of) this commit merged, 
because I could provide much better warning messages if I can access the 
concrete subscript/dereference operations. Of course if you don't have time to 
work on this I can put this up for review myself (probably after your other 
commits are handled).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159107

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


[PATCH] D85309: [Driver] Support GNU ld on Solaris

2023-08-31 Thread Rainer Orth via Phabricator via cfe-commits
ro marked an inline comment as done.
ro added inline comments.



Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:305
 
+bool tools::isLinkerGnuLd(const ToolChain &TC, const ArgList &Args) {
+  // Only used if targetting Solaris.

MaskRay wrote:
> I suppose that this should be in a Solaris specific file to indicate that 
> it's not for other systems.
> 
> GNU ld is almost ubiquitous on Linux and is almost always available at 
> /usr/bin/ld (with very few distributions using others linkers by default or 
> providing an option).
> 
> Detecting linker to affect driver decisions is we Linux are very wary of. We 
> are nervous even trying to do some stuff only related to lld.
> 
> We likely don't want this function to be in CommonArgs to lure other 
> contributors to use.
> I suppose that this should be in a Solaris specific file to indicate that 
> it's not for other systems.

Indeed.  I've moved it to `Solaris.{h,cpp}` now.  In fact, initially i'd tried 
to assert a Solaris target in `isLinkerGnuLd`, but that cannot work because in 
some cases the function is called in common code, even though the result is 
only used on Solaris.

I briefly thought about generalizing both `IsLinkerGnuLd` and `IsLinkerLLD` 
into a common
```
enum LinkerFlavour getLinkerFlavor();
```
but doing this for all possible configs seemed like a can of worms I'd rather 
not open.

> GNU ld is almost ubiquitous on Linux and is almost always available at 
> /usr/bin/ld (with very few distributions using others linkers by default or 
> providing an option).
> 
> Detecting linker to affect driver decisions is we Linux are very wary of. We 
> are nervous even trying to do some stuff only related to lld.

I saw: that code is only used on Darwin, it seems, and I'd like to avoid 
touching that.

> We likely don't want this function to be in CommonArgs to lure other 
> contributors to use.

Apart from the move to `Solaris.h`, I've also moved it into the `solaris` 
namespace to make things completely obvious.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85309

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


[PATCH] D85309: [Driver] Support GNU ld on Solaris

2023-08-31 Thread Rainer Orth via Phabricator via cfe-commits
ro updated this revision to Diff 554946.
ro marked an inline comment as done.
ro added a comment.

Move `isLinkerGnuLd` to `Solaris.{h,cpp}` and into `solaris` namespace to make 
it unambigously clear where to use it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85309

Files:
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/Solaris.cpp
  clang/lib/Driver/ToolChains/Solaris.h
  clang/test/Driver/hip-link-bundle-archive.hip
  clang/test/Driver/solaris-ld-sanitizer.c
  clang/test/Driver/solaris-ld.c
  compiler-rt/cmake/config-ix.cmake
  compiler-rt/test/asan/TestCases/global-location-nodebug.cpp
  flang/test/Driver/linker-flags.f90
  llvm/cmake/modules/AddLLVM.cmake

Index: llvm/cmake/modules/AddLLVM.cmake
===
--- llvm/cmake/modules/AddLLVM.cmake
+++ llvm/cmake/modules/AddLLVM.cmake
@@ -282,9 +282,9 @@
 # ld64's implementation of -dead_strip breaks tools that use plugins.
 set_property(TARGET ${target_name} APPEND_STRING PROPERTY
  LINK_FLAGS " -Wl,-dead_strip")
-  elseif(${CMAKE_SYSTEM_NAME} MATCHES "SunOS")
+  elseif(${CMAKE_SYSTEM_NAME} MATCHES "SunOS" AND LLVM_LINKER_IS_SOLARISLD)
 # Support for ld -z discard-unused=sections was only added in
-# Solaris 11.4.
+# Solaris 11.4.  GNU ld ignores it, but warns every time.
 include(LLVMCheckLinkerFlag)
 llvm_check_linker_flag(CXX "-Wl,-z,discard-unused=sections" LINKER_SUPPORTS_Z_DISCARD_UNUSED)
 if (LINKER_SUPPORTS_Z_DISCARD_UNUSED)
@@ -1288,7 +1288,10 @@
 # the size of the exported symbol table, but on other platforms we can do
 # it without any trouble.
 set_target_properties(${target} PROPERTIES ENABLE_EXPORTS 1)
-if (APPLE)
+# CMake doesn't set CMAKE_EXE_EXPORTS_${lang}_FLAG on Solaris, so
+# ENABLE_EXPORTS has no effect.  While Solaris ld defaults to -rdynamic
+# behaviour, GNU ld needs it.
+if (APPLE OR ${CMAKE_SYSTEM_NAME} STREQUAL "SunOS")
   set_property(TARGET ${target} APPEND_STRING PROPERTY
 LINK_FLAGS " -rdynamic")
 endif()
Index: flang/test/Driver/linker-flags.f90
===
--- flang/test/Driver/linker-flags.f90
+++ flang/test/Driver/linker-flags.f90
@@ -10,7 +10,7 @@
 !   'oldnames' on Windows, but they are not needed when compiling
 !   Fortran code and they might bring in additional dependencies.
 !   Make sure they're not added.
-! RUN: %flang -### -target aarch64-windows-msvc %S/Inputs/hello.f90 2>&1 | FileCheck %s --check-prefixes=CHECK,MSVC --implicit-check-not libcmt --implicit-check-not oldnames
+! RUN: %flang -### -target aarch64-windows-msvc -fuse-ld= %S/Inputs/hello.f90 2>&1 | FileCheck %s --check-prefixes=CHECK,MSVC --implicit-check-not libcmt --implicit-check-not oldnames
 
 ! Compiler invocation to generate the object file
 ! CHECK-LABEL: {{.*}} "-emit-obj"
Index: compiler-rt/test/asan/TestCases/global-location-nodebug.cpp
===
--- compiler-rt/test/asan/TestCases/global-location-nodebug.cpp
+++ compiler-rt/test/asan/TestCases/global-location-nodebug.cpp
@@ -2,13 +2,14 @@
 /// allow this test to also run on Windows (which can't be done for the
 /// debuginfo variant).
 
-// RUN: %clangxx_asan -O2 %S/global-location.cpp -o %t %if target={{.*-windows-msvc.*}} %{ -Wl,/DEBUG:NONE %} %else %{ -Wl,-S %}
+// RUN: %clangxx_asan -O2 %S/global-location.cpp -o %t %if target={{.*-windows-msvc.*}} %{ -Wl,/DEBUG:NONE %} %else %{ -Wl,-S %} %if target={{.*-solaris.*}} %{ -fuse-ld= %}
 // RUN: not %run %t g 2>&1 | FileCheck %s --check-prefix=CHECK --check-prefix=GLOB-NO-G
 // RUN: not %run %t c 2>&1 | FileCheck %s --check-prefix=CHECK --check-prefix=CLASS_STATIC-NO-G
 // RUN: not %run %t f 2>&1 | FileCheck %s --check-prefix=CHECK --check-prefix=FUNC_STATIC-NO-G
 // RUN: not %run %t l 2>&1 | FileCheck %s --check-prefix=CHECK --check-prefix=LITERAL-NO-G
 
-/// Solaris ld -S has different semantics.
+/// Solaris ld -S has different semantics, so enforce -fuse-ld= for
+/// configurations that default to GNU ld.
 // XFAIL: target={{.*solaris.*}}
 
 // CHECK: AddressSanitizer: global-buffer-overflow
Index: compiler-rt/cmake/config-ix.cmake
===
--- compiler-rt/cmake/config-ix.cmake
+++ compiler-rt/cmake/config-ix.cmake
@@ -1,4 +1,5 @@
 include(CMakePushCheckState)
+include(AddLLVM)
 include(LLVMCheckCompilerLinkerFlag)
 include(CheckCCompilerFlag)
 include(CheckCXXCompilerFlag)
@@ -196,7 +197,7 @@
 llvm_check_compiler_linker_flag(C "-Wl,-z,text" COMPILER_RT_HAS_Z_TEXT)
 llvm_check_compiler_linker_flag(C "-fuse-ld=lld" COMPILER_RT_HAS_FUSE_LD_LLD_FLAG)
 
-if(${CMAKE_SYSTEM_NAME} MATCHES "SunOS")
+if(${CMAKE_SYSTEM_NAME} MATCHES "SunOS" AND LLVM_LINKER_

[PATCH] D159261: [clang][dataflow] Eliminate deprecated `DataflowAnalysis` constructor.

2023-08-31 Thread Martin Böhme via Phabricator via cfe-commits
mboehme created this revision.
Herald added subscribers: martong, xazax.hun.
Herald added a reviewer: NoQ.
Herald added a project: All.
mboehme requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D159261

Files:
  clang/include/clang/Analysis/FlowSensitive/DataflowAnalysis.h
  clang/include/clang/Analysis/FlowSensitive/NoopAnalysis.h
  clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp
  clang/unittests/Analysis/FlowSensitive/TestingSupportTest.cpp
  clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
  clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TypeErasedDataflowAnalysisTest.cpp
@@ -78,7 +78,9 @@
 TEST(DataflowAnalysisTest, NoopAnalysis) {
   auto BlockStates = llvm::cantFail(
   runAnalysis("void target() {}", [](ASTContext &C) {
-return NoopAnalysis(C, false);
+return NoopAnalysis(C,
+// Don't use builtin transfer function.
+DataflowAnalysisOptions{std::nullopt});
   }));
   EXPECT_EQ(BlockStates.size(), 2u);
   EXPECT_TRUE(BlockStates[0].has_value());
@@ -130,7 +132,8 @@
   explicit NonConvergingAnalysis(ASTContext &Context)
   : DataflowAnalysis(
 Context,
-/*ApplyBuiltinTransfer=*/false) {}
+// Don't apply builtin transfer function.
+DataflowAnalysisOptions{std::nullopt}) {}
 
   static NonConvergingLattice initialElement() { return {0}; }
 
@@ -811,7 +814,7 @@
 AnalysisInputs(
 Code, ast_matchers::hasName("target"),
 [](ASTContext &Context, Environment &Env) {
-  return NoopAnalysis(Context, true);
+  return NoopAnalysis(Context);
 })
 .withASTBuildArgs({"-fsyntax-only", "-std=c++17"}),
 /*VerifyResults=*/[&Match](const llvm::StringMap<
Index: clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -1418,9 +1418,7 @@
   checkDataflow(
   AnalysisInputs(
   Code, cxxConstructorDecl(ofClass(hasName("B"))),
-  [](ASTContext &C, Environment &) {
-return NoopAnalysis(C, /*ApplyBuiltinTransfer=*/true);
-  })
+  [](ASTContext &C, Environment &) { return NoopAnalysis(C); })
   .withASTBuildArgs(
   {"-fsyntax-only", "-fno-delayed-template-parsing",
"-std=" + std::string(LangStandard::getLangStandardForKind(
Index: clang/unittests/Analysis/FlowSensitive/TestingSupportTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TestingSupportTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TestingSupportTest.cpp
@@ -86,7 +86,9 @@
 Code, std::move(TargetFuncMatcher),
 [](ASTContext &Context, Environment &) {
   return NoopAnalysis(
-  Context, /*ApplyBuiltinTransfer=*/false);
+  Context,
+  // Don't apply builtin transfer function.
+  DataflowAnalysisOptions{std::nullopt});
 })
 .withASTBuildArgs({"-fsyntax-only", "-std=c++17"}),
 /*VerifyResults=*/std::move(Expectations)),
Index: clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/ChromiumCheckModelTest.cpp
@@ -113,8 +113,7 @@
 : public DataflowAnalysis, NoopLattice> {
 public:
   explicit ModelAdaptorAnalysis(ASTContext &Context)
-  : DataflowAnalysis(
-Context, /*ApplyBuiltinTransfer=*/true) {}
+  : DataflowAnalysis(Context) {}
 
   static NoopLattice initialElement() { return NoopLattice(); }
 
Index: clang/include/clang/Analysis/FlowSensitive/NoopAnalysis.h
===
--- clang/include/clang/Analysis/FlowSensitive/NoopAnalysis.h
+++ clang/include/clang/Analysis/FlowSensitive/NoopAnalysis.h
@@ -27,15 +27,6 @@
   NoopAnalysis(ASTContext &Context)
   : DataflowAnalysis(Context) {}
 
-  /// Deprecated. Use the `DataflowAnalysisOptions` constructor in

[PATCH] D159262: [clang][dataflow] Eliminate deprecated `ControlFlowContext::build()` overload.

2023-08-31 Thread Martin Böhme via Phabricator via cfe-commits
mboehme created this revision.
Herald added subscribers: martong, xazax.hun.
Herald added a reviewer: NoQ.
Herald added a project: All.
mboehme requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D159262

Files:
  clang/include/clang/Analysis/FlowSensitive/ControlFlowContext.h
  clang/lib/Analysis/FlowSensitive/ControlFlowContext.cpp


Index: clang/lib/Analysis/FlowSensitive/ControlFlowContext.cpp
===
--- clang/lib/Analysis/FlowSensitive/ControlFlowContext.cpp
+++ clang/lib/Analysis/FlowSensitive/ControlFlowContext.cpp
@@ -109,15 +109,5 @@
 std::move(BlockReachable));
 }
 
-llvm::Expected
-ControlFlowContext::build(const Decl *D, Stmt &S, ASTContext &C) {
-  if (D == nullptr)
-return llvm::createStringError(
-std::make_error_code(std::errc::invalid_argument),
-"Declaration must not be null");
-
-  return build(*D, S, C);
-}
-
 } // namespace dataflow
 } // namespace clang
Index: clang/include/clang/Analysis/FlowSensitive/ControlFlowContext.h
===
--- clang/include/clang/Analysis/FlowSensitive/ControlFlowContext.h
+++ clang/include/clang/Analysis/FlowSensitive/ControlFlowContext.h
@@ -40,12 +40,6 @@
   static llvm::Expected build(const Decl &D, Stmt &S,
   ASTContext &C);
 
-  /// Builds a ControlFlowContext from an AST node. `D` is the function in 
which
-  /// `S` resides. `D` must not be null and `D->isTemplated()` must be false.
-  LLVM_DEPRECATED("Use the version that takes a const Decl & instead", "")
-  static llvm::Expected build(const Decl *D, Stmt &S,
-  ASTContext &C);
-
   /// Returns the `Decl` containing the statement used to construct the CFG, if
   /// available.
   const Decl &getDecl() const { return ContainingDecl; }


Index: clang/lib/Analysis/FlowSensitive/ControlFlowContext.cpp
===
--- clang/lib/Analysis/FlowSensitive/ControlFlowContext.cpp
+++ clang/lib/Analysis/FlowSensitive/ControlFlowContext.cpp
@@ -109,15 +109,5 @@
 std::move(BlockReachable));
 }
 
-llvm::Expected
-ControlFlowContext::build(const Decl *D, Stmt &S, ASTContext &C) {
-  if (D == nullptr)
-return llvm::createStringError(
-std::make_error_code(std::errc::invalid_argument),
-"Declaration must not be null");
-
-  return build(*D, S, C);
-}
-
 } // namespace dataflow
 } // namespace clang
Index: clang/include/clang/Analysis/FlowSensitive/ControlFlowContext.h
===
--- clang/include/clang/Analysis/FlowSensitive/ControlFlowContext.h
+++ clang/include/clang/Analysis/FlowSensitive/ControlFlowContext.h
@@ -40,12 +40,6 @@
   static llvm::Expected build(const Decl &D, Stmt &S,
   ASTContext &C);
 
-  /// Builds a ControlFlowContext from an AST node. `D` is the function in which
-  /// `S` resides. `D` must not be null and `D->isTemplated()` must be false.
-  LLVM_DEPRECATED("Use the version that takes a const Decl & instead", "")
-  static llvm::Expected build(const Decl *D, Stmt &S,
-  ASTContext &C);
-
   /// Returns the `Decl` containing the statement used to construct the CFG, if
   /// available.
   const Decl &getDecl() const { return ContainingDecl; }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D154838: [analyzer] Add check for null pointer passed to the %p of printf family

2023-08-31 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.

I'd suggest renaming the checker to `alpha.unix.NullFormatSpecifier`.
Maybe add tests where multiple format specifiers are null, and also one test 
where no variadic args are present.

I also tried to simplify your solution a bit, so that we don't need to specify 
manually which arguments are for the "variadic" part.
Check it out here: F28923128: simplified.patch 


We should think about a shorter diagnostic message because it seems 
unnecessarily long to me.
The rest looks good to me.

I could do a measurement to see how this would behave in the wild.




Comment at: 
clang/lib/StaticAnalyzer/Checkers/UnixAPIPortabilityMinorChecker.cpp:70-71
+  new BugType(this,
+  "Passing a null pointer to the pointer conversion "
+  "specifier of ",
+  categories::UnixAPI));

Is this an unfinished sentence? I guess you could remove the ` of ` suffix.



Comment at: 
clang/lib/StaticAnalyzer/Checkers/UnixAPIPortabilityMinorChecker.cpp:86
+  ExplodedNode *N =
+  C.generateNonFatalErrorNode(nullState ? nullState : C.getState());
+  if (!N)

You always pass this state.



Comment at: clang/test/Analysis/unix-api-portability-minor.cpp:5-13
+struct FILE_t;
+typedef struct FILE_t FILE;
+
+typedef __typeof(sizeof(int)) size_t;
+
+int printf(const char *, ... );
+int fprintf(FILE *, const char *, ...);





Comment at: clang/test/Analysis/unix-api-portability-minor.cpp:30-35
+  printf(format, NULL); // expected-warning{{The result of passing a null 
pointer to the pointer conversion specifier of the printf family of functions 
is implementation defined}}
+  printf(format, 1, NULL); // expected-warning{{The result of passing a null 
pointer to the pointer conversion specifier of the printf family of functions 
is implementation defined}}
+  printf(format, 1, NULL, 2); // expected-warning{{The result of passing a 
null pointer to the pointer conversion specifier of the printf family of 
functions is implementation defined}}
+  printf(format, NULL, NULL); // expected-warning{{The result of passing a 
null pointer to the pointer conversion specifier of the printf family of 
functions is implementation defined}}
+  printf(format, NULL, 1, NULL); // expected-warning{{The result of passing a 
null pointer to the pointer conversion specifier of the printf family of 
functions is implementation defined}}
+  printf(format, 0); // no-warning

This format makes the pattern more apparent.



Comment at: clang/test/Analysis/unix-api-portability-minor.cpp:42-43
+  printf(format, pointer1); // no-warning
+  // Pointer argument should not get constrained after the check.
+  *pointer1 = 777; // no-warning
+

If `printf` had assumed that `pointer1` must be non-null to make the 
postcondition of the function pass, the dereference would succeed afterward 
anyway.

To test if `printf` didn't assume this, just have this afterward to make this 
observable:
```lang=C++
if (pointer1) {
  *pointer1 = 777;
} else {
  // We should have a warning here, as 'printf' didn't assume that the 
specifier is non-null.
  *pointer1 = 888; // expect-warning {{deref}}
}
```
If the pointer was constrained, then the `else` branch should be proven 
dead-code, and we should not have a warning


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D154838

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


[PATCH] D159263: [clang-tidy] misc-include-cleaner: remove duplicated includes & fixes

2023-08-31 Thread Ding Fei via Phabricator via cfe-commits
danix800 created this revision.
danix800 added reviewers: VitaNuo, kadircet, sammccall.
danix800 added a project: clang-tools-extra.
Herald added subscribers: PiotrZSL, carlosgalvezp, xazax.hun.
Herald added a reviewer: njames93.
Herald added a project: All.
danix800 requested review of this revision.
Herald added a subscriber: cfe-commits.

1. Duplicated includes could be removed:

  #include "bar.h"
  #include "bar.h" # could be eliminated



2. FixItHint should not be applied (multiple insertions) for different symbols 
from same header.

  // baz.h
  #pragma once
  #define BAZ 10
  int baz();
  
  // include-cleaner.cpp
  // only one '#include "baz.h"' should be inserted.
  int BazResult = baz();
  int BazResultAgain = BAZ;


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D159263

Files:
  clang-tools-extra/clang-tidy/misc/IncludeCleanerCheck.cpp
  clang-tools-extra/test/clang-tidy/checkers/misc/Inputs/baz.h
  clang-tools-extra/test/clang-tidy/checkers/misc/include-cleaner.cpp


Index: clang-tools-extra/test/clang-tidy/checkers/misc/include-cleaner.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/misc/include-cleaner.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/misc/include-cleaner.cpp
@@ -1,5 +1,8 @@
 // RUN: %check_clang_tidy %s misc-include-cleaner %t -- -- -I%S/Inputs 
-isystem%S/Inputs/system
 #include "bar.h"
+#include "bar.h"
+// CHECK-MESSAGES: :[[@LINE-1]]:1: warning: included header bar.h is not used 
directly [misc-include-cleaner]
+// CHECK-FIXES: {{^}}
 // CHECK-FIXES: {{^}}#include "baz.h"{{$}}
 #include "foo.h"
 // CHECK-MESSAGES: :[[@LINE-1]]:1: warning: included header foo.h is not used 
directly [misc-include-cleaner]
@@ -11,6 +14,8 @@
 int BarResult = bar();
 int BazResult = baz();
 // CHECK-MESSAGES: :[[@LINE-1]]:17: warning: no header providing "baz" is 
directly included [misc-include-cleaner]
+int BazResultAgain = BAZ; // Header should not be inserted more than once
+// CHECK-MESSAGES: :[[@LINE-1]]:22: warning: no header providing "BAZ" is 
directly included [misc-include-cleaner]
 std::string HelloString;
 // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: no header providing "std::string" 
is directly included [misc-include-cleaner]
 int FooBarResult = foobar();
Index: clang-tools-extra/test/clang-tidy/checkers/misc/Inputs/baz.h
===
--- clang-tools-extra/test/clang-tidy/checkers/misc/Inputs/baz.h
+++ clang-tools-extra/test/clang-tidy/checkers/misc/Inputs/baz.h
@@ -1,2 +1,3 @@
 #pragma once
+#define BAZ 10
 int baz();
Index: clang-tools-extra/clang-tidy/misc/IncludeCleanerCheck.cpp
===
--- clang-tools-extra/clang-tidy/misc/IncludeCleanerCheck.cpp
+++ clang-tools-extra/clang-tidy/misc/IncludeCleanerCheck.cpp
@@ -33,6 +33,7 @@
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/ADT/StringRef.h"
+#include "llvm/ADT/StringSet.h"
 #include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/Regex.h"
@@ -156,10 +157,18 @@
});
 
   std::vector Unused;
+  llvm::StringSet<> AlreadyIncludedHeaders;
   for (const include_cleaner::Include &I :
RecordedPreprocessor.Includes.all()) {
-if (Used.contains(&I) || !I.Resolved)
+if (!I.Resolved)
   continue;
+if (Used.contains(&I)) {
+  if (!AlreadyIncludedHeaders.contains(I.Spelled))
+AlreadyIncludedHeaders.insert(I.Spelled);
+  else
+Unused.push_back(&I);
+  continue;
+}
 if (RecordedPI.shouldKeep(*I.Resolved))
   continue;
 // Check if main file is the public interface for a private header. If so
@@ -199,6 +208,7 @@
 
   tooling::HeaderIncludes HeaderIncludes(getCurrentMainFile(), Code,
  FileStyle->IncludeStyle);
+  llvm::StringSet<> AlreadyInserted;
   for (const auto &Inc : Missing) {
 std::string Spelling = include_cleaner::spellHeader(
 {Inc.Missing, PP->getHeaderSearchInfo(), MainFile});
@@ -209,14 +219,18 @@
 // main file.
 if (auto Replacement =
 HeaderIncludes.insert(llvm::StringRef{Spelling}.trim("\"<>"),
-  Angled, tooling::IncludeDirective::Include))
-  diag(SM->getSpellingLoc(Inc.SymRef.RefLocation),
-   "no header providing \"%0\" is directly included")
-  << Inc.SymRef.Target.name()
-  << FixItHint::CreateInsertion(
- SM->getComposedLoc(SM->getMainFileID(),
-Replacement->getOffset()),
- Replacement->getReplacementText());
+  Angled, tooling::IncludeDirective::Include)) 
{
+  DiagnosticBuilder DB =
+  diag(SM->getSpellingLoc(Inc.SymRef.RefLocation),
+   "no header providing \"%0\" is directly included")
+  << Inc.SymRe

[PATCH] D159264: [clang][dataflow] Remove deprecated synonyms related to `RecordStorageLocation` and `RecordValue`

2023-08-31 Thread Martin Böhme via Phabricator via cfe-commits
mboehme created this revision.
Herald added subscribers: martong, xazax.hun.
Herald added a reviewer: NoQ.
Herald added a project: All.
mboehme requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D159264

Files:
  clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
  clang/include/clang/Analysis/FlowSensitive/StorageLocation.h
  clang/include/clang/Analysis/FlowSensitive/Value.h


Index: clang/include/clang/Analysis/FlowSensitive/Value.h
===
--- clang/include/clang/Analysis/FlowSensitive/Value.h
+++ clang/include/clang/Analysis/FlowSensitive/Value.h
@@ -36,8 +36,6 @@
 Integer,
 Pointer,
 Record,
-// Deprecated synonym for `Record`
-Struct = Record,
 
 // TODO: Top values should not be need to be type-specific.
 TopBool,
@@ -227,9 +225,6 @@
   /// Returns the storage location that this `RecordValue` is associated with.
   RecordStorageLocation &getLoc() const { return Loc; }
 
-  /// Deprecated synonym for `getLoc()`.
-  RecordStorageLocation &getAggregateLoc() const { return Loc; }
-
   /// Convenience function that returns the child storage location for `Field`.
   /// See also the documentation for `RecordStorageLocation::getChild()`.
   StorageLocation *getChild(const ValueDecl &Field) const {
@@ -240,9 +235,6 @@
   RecordStorageLocation &Loc;
 };
 
-/// Deprecated synonym for `RecordValue`.
-using StructValue = RecordValue;
-
 raw_ostream &operator<<(raw_ostream &OS, const Value &Val);
 
 } // namespace dataflow
Index: clang/include/clang/Analysis/FlowSensitive/StorageLocation.h
===
--- clang/include/clang/Analysis/FlowSensitive/StorageLocation.h
+++ clang/include/clang/Analysis/FlowSensitive/StorageLocation.h
@@ -34,8 +34,6 @@
   enum class Kind {
 Scalar,
 Record,
-// Deprecated synonym for `Record`
-Aggregate = Record,
   };
 
   StorageLocation(Kind LocKind, QualType Type) : LocKind(LocKind), Type(Type) {
@@ -155,9 +153,6 @@
   FieldToLoc Children;
 };
 
-/// Deprecated synonym for `RecordStorageLocation`.
-using AggregateStorageLocation = RecordStorageLocation;
-
 } // namespace dataflow
 } // namespace clang
 
Index: clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
===
--- clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
+++ clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
@@ -701,15 +701,6 @@
 /// See also documentation for the overload above.
 RecordValue &refreshRecordValue(const Expr &Expr, Environment &Env);
 
-/// Deprecated synonym for `refreshRecordValue()`.
-inline RecordValue &refreshStructValue(RecordStorageLocation &Loc,
-   Environment &Env) {
-  return refreshRecordValue(Loc, Env);
-}
-inline RecordValue &refreshStructValue(const Expr &Expr, Environment &Env) {
-  return refreshRecordValue(Expr, Env);
-}
-
 } // namespace dataflow
 } // namespace clang
 


Index: clang/include/clang/Analysis/FlowSensitive/Value.h
===
--- clang/include/clang/Analysis/FlowSensitive/Value.h
+++ clang/include/clang/Analysis/FlowSensitive/Value.h
@@ -36,8 +36,6 @@
 Integer,
 Pointer,
 Record,
-// Deprecated synonym for `Record`
-Struct = Record,
 
 // TODO: Top values should not be need to be type-specific.
 TopBool,
@@ -227,9 +225,6 @@
   /// Returns the storage location that this `RecordValue` is associated with.
   RecordStorageLocation &getLoc() const { return Loc; }
 
-  /// Deprecated synonym for `getLoc()`.
-  RecordStorageLocation &getAggregateLoc() const { return Loc; }
-
   /// Convenience function that returns the child storage location for `Field`.
   /// See also the documentation for `RecordStorageLocation::getChild()`.
   StorageLocation *getChild(const ValueDecl &Field) const {
@@ -240,9 +235,6 @@
   RecordStorageLocation &Loc;
 };
 
-/// Deprecated synonym for `RecordValue`.
-using StructValue = RecordValue;
-
 raw_ostream &operator<<(raw_ostream &OS, const Value &Val);
 
 } // namespace dataflow
Index: clang/include/clang/Analysis/FlowSensitive/StorageLocation.h
===
--- clang/include/clang/Analysis/FlowSensitive/StorageLocation.h
+++ clang/include/clang/Analysis/FlowSensitive/StorageLocation.h
@@ -34,8 +34,6 @@
   enum class Kind {
 Scalar,
 Record,
-// Deprecated synonym for `Record`
-Aggregate = Record,
   };
 
   StorageLocation(Kind LocKind, QualType Type) : LocKind(LocKind), Type(Type) {
@@ -155,9 +153,6 @@
   FieldToLoc Children;
 };
 
-/// Deprecated synonym for `RecordStorageLocation`.
-using AggregateStorageLocation = RecordStorageLocation;
-
 } // namespace dataflo

[PATCH] D158842: [include-cleaner] Handle decls/refs to concepts.

2023-08-31 Thread Utkarsh Saxena via Phabricator via cfe-commits
usaxena95 updated this revision to Diff 554955.
usaxena95 marked 2 inline comments as done.
usaxena95 added a comment.

Rebased over AST changes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158842

Files:
  clang-tools-extra/include-cleaner/lib/WalkAST.cpp
  clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp


Index: clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp
===
--- clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp
+++ clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp
@@ -198,6 +198,55 @@
   Pair(Code.point("4"), UnorderedElementsAre(MainFile;
 }
 
+TEST_F(WalkUsedTest, Concepts) {
+  llvm::Annotations ConceptHdr(guard(R"cpp(
+template
+concept Foo = true;
+  )cpp"));
+  llvm::Annotations Code(R"cpp(
+#include "concept.h"
+
+template
+concept $Bar1^Bar = $Foo1^Foo && true;
+
+template<$Bar2^Bar T> requires $Bar3^Bar && $Foo2^Foo
+void $1^func1() {}
+
+template<$Foo3^Foo T>
+void $2^func2() requires $Bar4^Bar {}
+
+void $3^func3($Bar5^Bar auto x) {
+  $Foo4^Foo auto $y^y = 1;
+}
+  )cpp");
+  Inputs.Code = Code.code();
+  Inputs.ExtraFiles["concept.h"] = ConceptHdr.code();
+  Inputs.ExtraArgs.push_back("--std=c++20");
+  TestAST AST(Inputs);
+  auto &SM = AST.sourceManager();
+  const auto *ConceptHdrFile = SM.getFileManager().getFile("concept.h").get();
+  auto MainFile = Header(SM.getFileEntryForID(SM.getMainFileID()));
+
+  EXPECT_THAT(
+  offsetToProviders(AST),
+  UnorderedElementsAre(
+  Pair(Code.point("Foo1"), UnorderedElementsAre(ConceptHdrFile)),
+  Pair(Code.point("Foo2"), UnorderedElementsAre(ConceptHdrFile)),
+  Pair(Code.point("Foo3"), UnorderedElementsAre(ConceptHdrFile)),
+  Pair(Code.point("Bar1"), UnorderedElementsAre(MainFile)),
+  Pair(Code.point("Bar2"), UnorderedElementsAre(MainFile)),
+  Pair(Code.point("Bar3"), UnorderedElementsAre(MainFile)),
+  Pair(Code.point("Bar4"), UnorderedElementsAre(MainFile)),
+  Pair(Code.point("Bar5"), UnorderedElementsAre(MainFile)),
+  // FIXME: Foo4 should be reported.
+  // Pair(Code.point("Foo4"), UnorderedElementsAre(ConceptHdrFile)),
+  Pair(Code.point("1"), UnorderedElementsAre(MainFile)),
+  Pair(Code.point("2"), UnorderedElementsAre(MainFile)),
+  Pair(Code.point("3"), UnorderedElementsAre(MainFile)),
+  Pair(Code.point("y"), UnorderedElementsAre(MainFile
+  << Code.code();
+}
+
 class AnalyzeTest : public testing::Test {
 protected:
   TestInputs Inputs;
@@ -299,7 +348,7 @@
   Results.Unused.push_back(Inc.atLine(4));
 
   EXPECT_EQ(fixIncludes(Results, "d.cc", Code, format::getLLVMStyle()),
-R"cpp(#include "d.h"
+R"cpp(#include "d.h"
 #include "a.h"
 #include "aa.h"
 #include "ab.h"
@@ -310,7 +359,7 @@
   Results.Missing.push_back("\"d.h\"");
   Code = R"cpp(#include "a.h")cpp";
   EXPECT_EQ(fixIncludes(Results, "d.cc", Code, format::getLLVMStyle()),
-R"cpp(#include "d.h"
+R"cpp(#include "d.h"
 #include "a.h")cpp");
 }
 
Index: clang-tools-extra/include-cleaner/lib/WalkAST.cpp
===
--- clang-tools-extra/include-cleaner/lib/WalkAST.cpp
+++ clang-tools-extra/include-cleaner/lib/WalkAST.cpp
@@ -241,6 +241,16 @@
 return true;
   }
 
+  bool VisitConceptDecl(ConceptDecl *CD) {
+report(CD->getLocation(), CD);
+return true;
+  }
+
+  bool VisitConceptReference(const ConceptReference *CR) {
+report(CR->getConceptNameLoc(), CR->getFoundDecl());
+return true;
+  }
+
   // Report a reference from explicit specializations to the specialized
   // template. Implicit ones are filtered out by RAV and explicit 
instantiations
   // are already traversed through typelocs.


Index: clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp
===
--- clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp
+++ clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp
@@ -198,6 +198,55 @@
   Pair(Code.point("4"), UnorderedElementsAre(MainFile;
 }
 
+TEST_F(WalkUsedTest, Concepts) {
+  llvm::Annotations ConceptHdr(guard(R"cpp(
+template
+concept Foo = true;
+  )cpp"));
+  llvm::Annotations Code(R"cpp(
+#include "concept.h"
+
+template
+concept $Bar1^Bar = $Foo1^Foo && true;
+
+template<$Bar2^Bar T> requires $Bar3^Bar && $Foo2^Foo
+void $1^func1() {}
+
+template<$Foo3^Foo T>
+void $2^func2() requires $Bar4^Bar {}
+
+void $3^func3($Bar5^Bar auto x) {
+  $Foo4^Foo auto $y^y = 1;
+}
+  )cpp");
+  Inputs.Code = Code.code();
+  Inputs.ExtraFiles["concept.h"] = ConceptHdr.code();
+  Inputs.ExtraArgs.push_back("--std=c++20");
+  TestAST AST(Inputs);
+  a

[PATCH] D158842: [include-cleaner] Handle decls/refs to concepts.

2023-08-31 Thread Utkarsh Saxena via Phabricator via cfe-commits
usaxena95 added inline comments.



Comment at: clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp:217
+void $2^func2() requires $Bar4^Bar {}
+  )cpp");
+  Inputs.Code = Code.code();

sammccall wrote:
> to complete the set I think you want
> 
> `void foo(Bar auto x)` (abbreviated template param) and `Bar auto x = 1` 
> (deduced type).
> 
> Though these may not pass yet
For some reason, `Bar auto x = 1` is still failing; investigating.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158842

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


[PATCH] D159263: [clang-tidy] misc-include-cleaner: remove duplicated includes & fixes

2023-08-31 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

Thanks! @kadircet should make the call on these features (they look good to 
me), I have some implementation notes.

This is making two independent changes, one is a policy change that should be 
applied to the include-cleaner library, and one is a bugfix to the clang-tidy 
check. I think they should be separate patches.




Comment at: clang-tools-extra/clang-tidy/misc/IncludeCleanerCheck.cpp:169
+  else
+Unused.push_back(&I);
+  continue;

If we want this policy, it should be provided at the include-cleaner library 
level so it applies to all clients, not just the clang-tidy check.

I think the clearest way is to encapsulate this in include_cleaner::Includes, 
so that match() never matches a Header requirement against a duplicative 
Include. This will naturally lead to the directives being marked as unused.

(In practice, the result will work in clangd, and will respect configuration of 
headers where analysis should be ignored, keep directives, etc)



Comment at: clang-tools-extra/clang-tidy/misc/IncludeCleanerCheck.cpp:227
+  << Inc.SymRef.Target.name();
+  if (!AlreadyInserted.contains(Inc.Missing.resolvedPath())) {
+DB << FixItHint::CreateInsertion(

This means that if you're looking at individual diagnostics rather than 
applying all fixes to a file, only the first diagnostic will have any fix 
available at all.

I believe the preferred solution is to do this conditionally based on 
areDiagsSelfContained(). `clang_tidy::utils::IncludeInserter` encapsulates 
this, but isn't used here.

I don't know whether we would want to use it here, or how carefully it's 
already been considered. (It definitely contains a lot of logic that is dubious 
to apply when the include to insert has already been precisely calculated, but 
also some things that would be helpful). Will defer to Kadir on that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159263

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


[PATCH] D158842: [include-cleaner] Handle decls/refs to concepts.

2023-08-31 Thread Sam McCall via Phabricator via cfe-commits
sammccall added inline comments.



Comment at: clang-tools-extra/include-cleaner/lib/WalkAST.cpp:244
 
+  bool VisitConceptDecl(ConceptDecl *CD) {
+report(CD->getLocation(), CD);

I don't know why we're doing this, decls in general are not considered 
references to themselves.

Function/Var/Enum are in some cases, because their definition should be 
typechecked against a forward-declaration in the header. But that doesn't apply 
here: you can't forward-declare a concept.



Comment at: clang-tools-extra/include-cleaner/unittests/AnalysisTest.cpp:201
 
+TEST_F(WalkUsedTest, Concepts) {
+  llvm::Annotations ConceptHdr(guard(R"cpp(

AFAICT these are just normal AST nodes, so should be tested in WalkASTTest 
which is narrower and lighter-weight.

The tests in this file run a bit more code, and none of it seems specifically 
relevant to concepts.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158842

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


[PATCH] D158842: [include-cleaner] Handle decls/refs to concepts.

2023-08-31 Thread Utkarsh Saxena via Phabricator via cfe-commits
usaxena95 updated this revision to Diff 554962.
usaxena95 marked 2 inline comments as done.
usaxena95 added a comment.

Addressed comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158842

Files:
  clang-tools-extra/include-cleaner/lib/WalkAST.cpp
  clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp


Index: clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
===
--- clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
+++ clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
@@ -528,5 +528,16 @@
const char* s = "";
auto sx = ^{s};)cpp");
 }
+
+TEST(WalkAST, Concepts) {
+  std::string Concept = "template concept $explicit^Foo = true;";
+  testWalk(Concept, "templateconcept Bar = ^Foo && true;");
+  testWalk(Concept, "template<^Foo T>void func() {}");
+  testWalk(Concept, "template requires ^Foo void func() {}");
+  testWalk(Concept, "template void func() requires ^Foo {}");
+  testWalk(Concept, "void func(^Foo auto x) {}");
+  // FIXME: Foo should be explicitly referenced.
+  testWalk("template concept Foo = true;", "void func() { ^Foo 
auto x = 1; }");
+}
 } // namespace
 } // namespace clang::include_cleaner
Index: clang-tools-extra/include-cleaner/lib/WalkAST.cpp
===
--- clang-tools-extra/include-cleaner/lib/WalkAST.cpp
+++ clang-tools-extra/include-cleaner/lib/WalkAST.cpp
@@ -241,6 +241,11 @@
 return true;
   }
 
+  bool VisitConceptReference(const ConceptReference *CR) {
+report(CR->getConceptNameLoc(), CR->getFoundDecl());
+return true;
+  }
+
   // Report a reference from explicit specializations to the specialized
   // template. Implicit ones are filtered out by RAV and explicit 
instantiations
   // are already traversed through typelocs.


Index: clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
===
--- clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
+++ clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
@@ -528,5 +528,16 @@
const char* s = "";
auto sx = ^{s};)cpp");
 }
+
+TEST(WalkAST, Concepts) {
+  std::string Concept = "template concept $explicit^Foo = true;";
+  testWalk(Concept, "templateconcept Bar = ^Foo && true;");
+  testWalk(Concept, "template<^Foo T>void func() {}");
+  testWalk(Concept, "template requires ^Foo void func() {}");
+  testWalk(Concept, "template void func() requires ^Foo {}");
+  testWalk(Concept, "void func(^Foo auto x) {}");
+  // FIXME: Foo should be explicitly referenced.
+  testWalk("template concept Foo = true;", "void func() { ^Foo auto x = 1; }");
+}
 } // namespace
 } // namespace clang::include_cleaner
Index: clang-tools-extra/include-cleaner/lib/WalkAST.cpp
===
--- clang-tools-extra/include-cleaner/lib/WalkAST.cpp
+++ clang-tools-extra/include-cleaner/lib/WalkAST.cpp
@@ -241,6 +241,11 @@
 return true;
   }
 
+  bool VisitConceptReference(const ConceptReference *CR) {
+report(CR->getConceptNameLoc(), CR->getFoundDecl());
+return true;
+  }
+
   // Report a reference from explicit specializations to the specialized
   // template. Implicit ones are filtered out by RAV and explicit instantiations
   // are already traversed through typelocs.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D159107: [analyzer] ArrayBoundCheckerV2 should disallow forming lvalues to out-of-bounds locations

2023-08-31 Thread Balázs Benics via Phabricator via cfe-commits
steakhal added a comment.

In D159107#4630573 , @donat.nagy 
wrote:

> I don't think that the `&arr[N]` issue is too serious: we can just increment 
> the array extent when the parent expression of the array subscript operator 
> is the unary operator `&`. If the past-the-end pointer ends up dereferenced 
> later, the current code is sufficient to report it as a bug (as the checker 
> monitors all dereferences).

My instinct suggests that there is more behind the curtain.
For example, on an expression `&arr[N]` (of type  `int arr[10]`), we would 
constrain `N`. We could say that we allow the one before and one after 
elements, thus introduce a constraint: `N: [-1, 11]`. This `-1` later could 
participate in casts, and end up interpreted as a really large unsigned number. 
I should also think about how would we detect off-by-one errors, which is a 
common category.

> I'd be happy to see (a slightly extended variant of) this commit merged, 
> because I could provide much better warning messages if I can access the 
> concrete subscript/dereference operations. Of course if you don't have time 
> to work on this I can put this up for review myself (probably after your 
> other commits are handled).

The thing is, that I only have this week, aka. 1.5 days before I leave for 
vacation. :D
In the future, (no ETA), we likely come back to the Juliet improvements.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159107

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


[PATCH] D159268: [c++20][clangd] Simplify code using the new `ConceptReference` nodes.

2023-08-31 Thread Jens Massberg via Phabricator via cfe-commits
massberg created this revision.
massberg added a reviewer: sammccall.
Herald added subscribers: kadircet, arphaman.
Herald added a project: All.
massberg requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang-tools-extra.

Directly traverse `ConceptReference`s in FindTarget.cpp.

There is no need for the extra logic for `AutoTypeLoc`s in 
SemanticHightlighting.cpp as the concept information is stored in a 
`ConceptReference` which is now traversed.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D159268

Files:
  clang-tools-extra/clangd/FindTarget.cpp
  clang-tools-extra/clangd/SemanticHighlighting.cpp


Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -736,14 +736,6 @@
 return true;
   }
 
-  bool VisitAutoTypeLoc(AutoTypeLoc L) {
-if (L.isConstrained()) {
-  H.addAngleBracketTokens(L.getLAngleLoc(), L.getRAngleLoc());
-  H.addToken(L.getConceptNameInfo().getLoc(), HighlightingKind::Concept);
-}
-return true;
-  }
-
   bool VisitFunctionDecl(FunctionDecl *D) {
 if (D->isOverloadedOperator()) {
   const auto AddOpDeclToken = [&](SourceLocation Loc) {
Index: clang-tools-extra/clangd/FindTarget.cpp
===
--- clang-tools-extra/clangd/FindTarget.cpp
+++ clang-tools-extra/clangd/FindTarget.cpp
@@ -742,13 +742,6 @@
 // FIXME: handle more complicated cases: more ObjC, designated 
initializers.
 llvm::SmallVector Refs;
 
-void VisitConceptSpecializationExpr(const ConceptSpecializationExpr *E) {
-  Refs.push_back(ReferenceLoc{E->getNestedNameSpecifierLoc(),
-  E->getConceptNameLoc(),
-  /*IsDecl=*/false,
-  {E->getNamedConcept()}});
-}
-
 void VisitDeclRefExpr(const DeclRefExpr *E) {
   Refs.push_back(ReferenceLoc{E->getQualifierLoc(),
   E->getNameInfo().getLoc(),
@@ -1063,15 +1056,12 @@
 return RecursiveASTVisitor::TraverseConstructorInitializer(Init);
   }
 
-  bool TraverseTypeConstraint(const TypeConstraint *TC) {
-// We want to handle all ConceptReferences but RAV is missing a
-// polymorphic Visit or Traverse method for it, so we handle
-// TypeConstraints specially here.
-Out(ReferenceLoc{TC->getNestedNameSpecifierLoc(),
- TC->getConceptNameLoc(),
+  bool TraverseConceptReference(ConceptReference *ConceptRef) {
+Out(ReferenceLoc{ConceptRef->getNestedNameSpecifierLoc(),
+ ConceptRef->getConceptNameLoc(),
  /*IsDecl=*/false,
- {TC->getNamedConcept()}});
-return RecursiveASTVisitor::TraverseTypeConstraint(TC);
+ {ConceptRef->getNamedConcept()}});
+return RecursiveASTVisitor::TraverseConceptReference(ConceptRef);
   }
 
 private:


Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -736,14 +736,6 @@
 return true;
   }
 
-  bool VisitAutoTypeLoc(AutoTypeLoc L) {
-if (L.isConstrained()) {
-  H.addAngleBracketTokens(L.getLAngleLoc(), L.getRAngleLoc());
-  H.addToken(L.getConceptNameInfo().getLoc(), HighlightingKind::Concept);
-}
-return true;
-  }
-
   bool VisitFunctionDecl(FunctionDecl *D) {
 if (D->isOverloadedOperator()) {
   const auto AddOpDeclToken = [&](SourceLocation Loc) {
Index: clang-tools-extra/clangd/FindTarget.cpp
===
--- clang-tools-extra/clangd/FindTarget.cpp
+++ clang-tools-extra/clangd/FindTarget.cpp
@@ -742,13 +742,6 @@
 // FIXME: handle more complicated cases: more ObjC, designated initializers.
 llvm::SmallVector Refs;
 
-void VisitConceptSpecializationExpr(const ConceptSpecializationExpr *E) {
-  Refs.push_back(ReferenceLoc{E->getNestedNameSpecifierLoc(),
-  E->getConceptNameLoc(),
-  /*IsDecl=*/false,
-  {E->getNamedConcept()}});
-}
-
 void VisitDeclRefExpr(const DeclRefExpr *E) {
   Refs.push_back(ReferenceLoc{E->getQualifierLoc(),
   E->getNameInfo().getLoc(),
@@ -1063,15 +1056,12 @@
 return RecursiveASTVisitor::TraverseConstructorInitializer(Init);
   }
 
-  bool TraverseTypeConstraint(const TypeConstraint *TC) {
-// We want to handle all ConceptReferences but RAV is missing a
-// polymorphic Visit or Traverse method for it, so we handle
-// TypeConstraints specially here.
-Out(ReferenceLoc{

[PATCH] D158842: [include-cleaner] Handle decls/refs to concepts.

2023-08-31 Thread Sam McCall via Phabricator via cfe-commits
sammccall accepted this revision.
sammccall added a comment.
This revision is now accepted and ready to land.

LGTM

Unclear to me whether the FIXME will be addressed by an AST bug or a local 
change, either way continuing to look into it SG but this is fine to land as-is.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158842

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


[PATCH] D159268: [c++20][clangd] Simplify code using the new `ConceptReference` nodes.

2023-08-31 Thread Sam McCall via Phabricator via cfe-commits
sammccall accepted this revision.
sammccall added inline comments.
This revision is now accepted and ready to land.



Comment at: clang-tools-extra/clangd/FindTarget.cpp:1059
 
-  bool TraverseTypeConstraint(const TypeConstraint *TC) {
-// We want to handle all ConceptReferences but RAV is missing a
-// polymorphic Visit or Traverse method for it, so we handle
-// TypeConstraints specially here.
-Out(ReferenceLoc{TC->getNestedNameSpecifierLoc(),
- TC->getConceptNameLoc(),
+  bool TraverseConceptReference(ConceptReference *ConceptRef) {
+Out(ReferenceLoc{ConceptRef->getNestedNameSpecifierLoc(),

I think this can just be VisitConceptReference, then no need to call into base


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159268

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


[PATCH] D159268: [c++20][clangd] Simplify code using the new `ConceptReference` nodes.

2023-08-31 Thread Jens Massberg via Phabricator via cfe-commits
massberg updated this revision to Diff 554985.
massberg marked an inline comment as done.
massberg added a comment.

Use VisitConceptReference instead of TraverseConceptReference


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159268

Files:
  clang-tools-extra/clangd/FindTarget.cpp
  clang-tools-extra/clangd/SemanticHighlighting.cpp


Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -736,14 +736,6 @@
 return true;
   }
 
-  bool VisitAutoTypeLoc(AutoTypeLoc L) {
-if (L.isConstrained()) {
-  H.addAngleBracketTokens(L.getLAngleLoc(), L.getRAngleLoc());
-  H.addToken(L.getConceptNameInfo().getLoc(), HighlightingKind::Concept);
-}
-return true;
-  }
-
   bool VisitFunctionDecl(FunctionDecl *D) {
 if (D->isOverloadedOperator()) {
   const auto AddOpDeclToken = [&](SourceLocation Loc) {
Index: clang-tools-extra/clangd/FindTarget.cpp
===
--- clang-tools-extra/clangd/FindTarget.cpp
+++ clang-tools-extra/clangd/FindTarget.cpp
@@ -742,13 +742,6 @@
 // FIXME: handle more complicated cases: more ObjC, designated 
initializers.
 llvm::SmallVector Refs;
 
-void VisitConceptSpecializationExpr(const ConceptSpecializationExpr *E) {
-  Refs.push_back(ReferenceLoc{E->getNestedNameSpecifierLoc(),
-  E->getConceptNameLoc(),
-  /*IsDecl=*/false,
-  {E->getNamedConcept()}});
-}
-
 void VisitDeclRefExpr(const DeclRefExpr *E) {
   Refs.push_back(ReferenceLoc{E->getQualifierLoc(),
   E->getNameInfo().getLoc(),
@@ -1063,15 +1056,12 @@
 return RecursiveASTVisitor::TraverseConstructorInitializer(Init);
   }
 
-  bool TraverseTypeConstraint(const TypeConstraint *TC) {
-// We want to handle all ConceptReferences but RAV is missing a
-// polymorphic Visit or Traverse method for it, so we handle
-// TypeConstraints specially here.
-Out(ReferenceLoc{TC->getNestedNameSpecifierLoc(),
- TC->getConceptNameLoc(),
+  bool VisitConceptReference(ConceptReference *ConceptRef) {
+Out(ReferenceLoc{ConceptRef->getNestedNameSpecifierLoc(),
+ ConceptRef->getConceptNameLoc(),
  /*IsDecl=*/false,
- {TC->getNamedConcept()}});
-return RecursiveASTVisitor::TraverseTypeConstraint(TC);
+ {ConceptRef->getNamedConcept()}});
+return true;
   }
 
 private:


Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -736,14 +736,6 @@
 return true;
   }
 
-  bool VisitAutoTypeLoc(AutoTypeLoc L) {
-if (L.isConstrained()) {
-  H.addAngleBracketTokens(L.getLAngleLoc(), L.getRAngleLoc());
-  H.addToken(L.getConceptNameInfo().getLoc(), HighlightingKind::Concept);
-}
-return true;
-  }
-
   bool VisitFunctionDecl(FunctionDecl *D) {
 if (D->isOverloadedOperator()) {
   const auto AddOpDeclToken = [&](SourceLocation Loc) {
Index: clang-tools-extra/clangd/FindTarget.cpp
===
--- clang-tools-extra/clangd/FindTarget.cpp
+++ clang-tools-extra/clangd/FindTarget.cpp
@@ -742,13 +742,6 @@
 // FIXME: handle more complicated cases: more ObjC, designated initializers.
 llvm::SmallVector Refs;
 
-void VisitConceptSpecializationExpr(const ConceptSpecializationExpr *E) {
-  Refs.push_back(ReferenceLoc{E->getNestedNameSpecifierLoc(),
-  E->getConceptNameLoc(),
-  /*IsDecl=*/false,
-  {E->getNamedConcept()}});
-}
-
 void VisitDeclRefExpr(const DeclRefExpr *E) {
   Refs.push_back(ReferenceLoc{E->getQualifierLoc(),
   E->getNameInfo().getLoc(),
@@ -1063,15 +1056,12 @@
 return RecursiveASTVisitor::TraverseConstructorInitializer(Init);
   }
 
-  bool TraverseTypeConstraint(const TypeConstraint *TC) {
-// We want to handle all ConceptReferences but RAV is missing a
-// polymorphic Visit or Traverse method for it, so we handle
-// TypeConstraints specially here.
-Out(ReferenceLoc{TC->getNestedNameSpecifierLoc(),
- TC->getConceptNameLoc(),
+  bool VisitConceptReference(ConceptReference *ConceptRef) {
+Out(ReferenceLoc{ConceptRef->getNestedNameSpecifierLoc(),
+ ConceptRef->getConceptNameLoc(),
  /*IsDecl=*/false,
- {TC->getNamedC

[clang-tools-extra] c39dcd2 - [c++20][clangd] Simplify code using the new `ConceptReference` nodes.

2023-08-31 Thread Jens Massberg via cfe-commits

Author: Jens Massberg
Date: 2023-08-31T13:53:56+02:00
New Revision: c39dcd2c2bc7fd142ac8305b3a41f24e1addbd8c

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

LOG: [c++20][clangd] Simplify code using the new `ConceptReference` nodes.

Directly traverse `ConceptReference`s in FindTarget.cpp.

There is no need for the extra logic for `AutoTypeLoc`s in 
SemanticHightlighting.cpp as the concept information is stored in a 
`ConceptReference` which is now traversed.

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

Added: 


Modified: 
clang-tools-extra/clangd/FindTarget.cpp
clang-tools-extra/clangd/SemanticHighlighting.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/FindTarget.cpp 
b/clang-tools-extra/clangd/FindTarget.cpp
index 630b75059b6baf..c1ec030275c4f6 100644
--- a/clang-tools-extra/clangd/FindTarget.cpp
+++ b/clang-tools-extra/clangd/FindTarget.cpp
@@ -742,13 +742,6 @@ llvm::SmallVector refInStmt(const Stmt *S,
 // FIXME: handle more complicated cases: more ObjC, designated 
initializers.
 llvm::SmallVector Refs;
 
-void VisitConceptSpecializationExpr(const ConceptSpecializationExpr *E) {
-  Refs.push_back(ReferenceLoc{E->getNestedNameSpecifierLoc(),
-  E->getConceptNameLoc(),
-  /*IsDecl=*/false,
-  {E->getNamedConcept()}});
-}
-
 void VisitDeclRefExpr(const DeclRefExpr *E) {
   Refs.push_back(ReferenceLoc{E->getQualifierLoc(),
   E->getNameInfo().getLoc(),
@@ -1063,15 +1056,12 @@ class ExplicitReferenceCollector
 return RecursiveASTVisitor::TraverseConstructorInitializer(Init);
   }
 
-  bool TraverseTypeConstraint(const TypeConstraint *TC) {
-// We want to handle all ConceptReferences but RAV is missing a
-// polymorphic Visit or Traverse method for it, so we handle
-// TypeConstraints specially here.
-Out(ReferenceLoc{TC->getNestedNameSpecifierLoc(),
- TC->getConceptNameLoc(),
+  bool VisitConceptReference(ConceptReference *ConceptRef) {
+Out(ReferenceLoc{ConceptRef->getNestedNameSpecifierLoc(),
+ ConceptRef->getConceptNameLoc(),
  /*IsDecl=*/false,
- {TC->getNamedConcept()}});
-return RecursiveASTVisitor::TraverseTypeConstraint(TC);
+ {ConceptRef->getNamedConcept()}});
+return true;
   }
 
 private:

diff  --git a/clang-tools-extra/clangd/SemanticHighlighting.cpp 
b/clang-tools-extra/clangd/SemanticHighlighting.cpp
index 8003a3c98f0ad8..45c01634e2e38d 100644
--- a/clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ b/clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -736,14 +736,6 @@ class CollectExtraHighlightings
 return true;
   }
 
-  bool VisitAutoTypeLoc(AutoTypeLoc L) {
-if (L.isConstrained()) {
-  H.addAngleBracketTokens(L.getLAngleLoc(), L.getRAngleLoc());
-  H.addToken(L.getConceptNameInfo().getLoc(), HighlightingKind::Concept);
-}
-return true;
-  }
-
   bool VisitFunctionDecl(FunctionDecl *D) {
 if (D->isOverloadedOperator()) {
   const auto AddOpDeclToken = [&](SourceLocation Loc) {



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


[PATCH] D159268: [c++20][clangd] Simplify code using the new `ConceptReference` nodes.

2023-08-31 Thread Jens Massberg 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 rGc39dcd2c2bc7: [c++20][clangd] Simplify code using the new 
`ConceptReference` nodes. (authored by massberg).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159268

Files:
  clang-tools-extra/clangd/FindTarget.cpp
  clang-tools-extra/clangd/SemanticHighlighting.cpp


Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -736,14 +736,6 @@
 return true;
   }
 
-  bool VisitAutoTypeLoc(AutoTypeLoc L) {
-if (L.isConstrained()) {
-  H.addAngleBracketTokens(L.getLAngleLoc(), L.getRAngleLoc());
-  H.addToken(L.getConceptNameInfo().getLoc(), HighlightingKind::Concept);
-}
-return true;
-  }
-
   bool VisitFunctionDecl(FunctionDecl *D) {
 if (D->isOverloadedOperator()) {
   const auto AddOpDeclToken = [&](SourceLocation Loc) {
Index: clang-tools-extra/clangd/FindTarget.cpp
===
--- clang-tools-extra/clangd/FindTarget.cpp
+++ clang-tools-extra/clangd/FindTarget.cpp
@@ -742,13 +742,6 @@
 // FIXME: handle more complicated cases: more ObjC, designated 
initializers.
 llvm::SmallVector Refs;
 
-void VisitConceptSpecializationExpr(const ConceptSpecializationExpr *E) {
-  Refs.push_back(ReferenceLoc{E->getNestedNameSpecifierLoc(),
-  E->getConceptNameLoc(),
-  /*IsDecl=*/false,
-  {E->getNamedConcept()}});
-}
-
 void VisitDeclRefExpr(const DeclRefExpr *E) {
   Refs.push_back(ReferenceLoc{E->getQualifierLoc(),
   E->getNameInfo().getLoc(),
@@ -1063,15 +1056,12 @@
 return RecursiveASTVisitor::TraverseConstructorInitializer(Init);
   }
 
-  bool TraverseTypeConstraint(const TypeConstraint *TC) {
-// We want to handle all ConceptReferences but RAV is missing a
-// polymorphic Visit or Traverse method for it, so we handle
-// TypeConstraints specially here.
-Out(ReferenceLoc{TC->getNestedNameSpecifierLoc(),
- TC->getConceptNameLoc(),
+  bool VisitConceptReference(ConceptReference *ConceptRef) {
+Out(ReferenceLoc{ConceptRef->getNestedNameSpecifierLoc(),
+ ConceptRef->getConceptNameLoc(),
  /*IsDecl=*/false,
- {TC->getNamedConcept()}});
-return RecursiveASTVisitor::TraverseTypeConstraint(TC);
+ {ConceptRef->getNamedConcept()}});
+return true;
   }
 
 private:


Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -736,14 +736,6 @@
 return true;
   }
 
-  bool VisitAutoTypeLoc(AutoTypeLoc L) {
-if (L.isConstrained()) {
-  H.addAngleBracketTokens(L.getLAngleLoc(), L.getRAngleLoc());
-  H.addToken(L.getConceptNameInfo().getLoc(), HighlightingKind::Concept);
-}
-return true;
-  }
-
   bool VisitFunctionDecl(FunctionDecl *D) {
 if (D->isOverloadedOperator()) {
   const auto AddOpDeclToken = [&](SourceLocation Loc) {
Index: clang-tools-extra/clangd/FindTarget.cpp
===
--- clang-tools-extra/clangd/FindTarget.cpp
+++ clang-tools-extra/clangd/FindTarget.cpp
@@ -742,13 +742,6 @@
 // FIXME: handle more complicated cases: more ObjC, designated initializers.
 llvm::SmallVector Refs;
 
-void VisitConceptSpecializationExpr(const ConceptSpecializationExpr *E) {
-  Refs.push_back(ReferenceLoc{E->getNestedNameSpecifierLoc(),
-  E->getConceptNameLoc(),
-  /*IsDecl=*/false,
-  {E->getNamedConcept()}});
-}
-
 void VisitDeclRefExpr(const DeclRefExpr *E) {
   Refs.push_back(ReferenceLoc{E->getQualifierLoc(),
   E->getNameInfo().getLoc(),
@@ -1063,15 +1056,12 @@
 return RecursiveASTVisitor::TraverseConstructorInitializer(Init);
   }
 
-  bool TraverseTypeConstraint(const TypeConstraint *TC) {
-// We want to handle all ConceptReferences but RAV is missing a
-// polymorphic Visit or Traverse method for it, so we handle
-// TypeConstraints specially here.
-Out(ReferenceLoc{TC->getNestedNameSpecifierLoc(),
- TC->getConceptNameLoc(),
+  bool VisitConceptReference(ConceptReference *ConceptRef) {
+Out(ReferenceLoc{ConceptRef->getNestedNameSpecifierLoc(),
+ ConceptRef->getConceptNameLoc()

[PATCH] D159256: [NFC][Clang] Remove redundant function definitions

2023-08-31 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 added a comment.

In D159256#4630410 , @jmmartinez 
wrote:

> @jhuber6 I was wondering if there is a reason you kept 3 versions of 
> `mergeDefaultFunctionDefinitionAttributes` in 
> https://reviews.llvm.org/D152391 ?

I believe it's because one was a freestanding function, the other was a member 
function, and the last was a common implementation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159256

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


[PATCH] D141757: [clangd] allow extracting to variable for lambda expressions

2023-08-31 Thread Julian Schmidt via Phabricator via cfe-commits
5chmidti marked an inline comment as done.
5chmidti added a comment.

Ping


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

https://reviews.llvm.org/D141757

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


[clang-tools-extra] ac2d265 - [include-cleaner] Handle decls/refs to concepts

2023-08-31 Thread Utkarsh Saxena via cfe-commits

Author: Utkarsh Saxena
Date: 2023-08-31T13:57:22+02:00
New Revision: ac2d2652db8de9ea2b750dd2bf1232941039dffe

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

LOG: [include-cleaner] Handle decls/refs to concepts

Added: 


Modified: 
clang-tools-extra/include-cleaner/lib/WalkAST.cpp
clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp

Removed: 




diff  --git a/clang-tools-extra/include-cleaner/lib/WalkAST.cpp 
b/clang-tools-extra/include-cleaner/lib/WalkAST.cpp
index e3ba2d3b604072..15a579afd456c3 100644
--- a/clang-tools-extra/include-cleaner/lib/WalkAST.cpp
+++ b/clang-tools-extra/include-cleaner/lib/WalkAST.cpp
@@ -241,6 +241,11 @@ class ASTWalker : public RecursiveASTVisitor {
 return true;
   }
 
+  bool VisitConceptReference(const ConceptReference *CR) {
+report(CR->getConceptNameLoc(), CR->getFoundDecl());
+return true;
+  }
+
   // Report a reference from explicit specializations to the specialized
   // template. Implicit ones are filtered out by RAV and explicit 
instantiations
   // are already traversed through typelocs.

diff  --git a/clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp 
b/clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
index 67248d4eedb915..f53959877dc513 100644
--- a/clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
+++ b/clang-tools-extra/include-cleaner/unittests/WalkASTTest.cpp
@@ -528,5 +528,16 @@ TEST(WalkAST, InitializerList) {
const char* s = "";
auto sx = ^{s};)cpp");
 }
+
+TEST(WalkAST, Concepts) {
+  std::string Concept = "template concept $explicit^Foo = true;";
+  testWalk(Concept, "templateconcept Bar = ^Foo && true;");
+  testWalk(Concept, "template<^Foo T>void func() {}");
+  testWalk(Concept, "template requires ^Foo void func() {}");
+  testWalk(Concept, "template void func() requires ^Foo {}");
+  testWalk(Concept, "void func(^Foo auto x) {}");
+  // FIXME: Foo should be explicitly referenced.
+  testWalk("template concept Foo = true;", "void func() { ^Foo 
auto x = 1; }");
+}
 } // namespace
 } // namespace clang::include_cleaner



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


[PATCH] D138499: [clangd] Extract Function: add hoisting support

2023-08-31 Thread Julian Schmidt via Phabricator via cfe-commits
5chmidti added a comment.

Ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D138499

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


[PATCH] D158842: [include-cleaner] Handle decls/refs to concepts.

2023-08-31 Thread Utkarsh Saxena via Phabricator via cfe-commits
usaxena95 closed this revision.
usaxena95 added a comment.

closed by ac2d2652db8de9ea2b750dd2bf1232941039dffe 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158842

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


[PATCH] D159256: [NFC][Clang] Remove redundant function definitions

2023-08-31 Thread Juan Manuel Martinez Caamaño via Phabricator via cfe-commits
jmmartinez added a comment.

In D159256#4630876 , @jhuber6 wrote:

> In D159256#4630410 , @jmmartinez 
> wrote:
>
>> @jhuber6 I was wondering if there is a reason you kept 3 versions of 
>> `mergeDefaultFunctionDefinitionAttributes` in 
>> https://reviews.llvm.org/D152391 ?
>
> I believe it's because one was a freestanding function, the other was a 
> member function, and the last was a common implementation.

Would it be ok if I keep only one? It seems that the member function is not 
used (I was not sure if there was some external code using it).

If not, I can also keep just 2 versions (the freestanding function and the 
member function), move the implementation to the freestanding one, and drop the 
static function since it is redundant.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159256

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


[PATCH] D159256: [NFC][Clang] Remove redundant function definitions

2023-08-31 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 accepted this revision.
jhuber6 added a comment.
This revision is now accepted and ready to land.

In D159256#4630915 , @jmmartinez 
wrote:

> In D159256#4630876 , @jhuber6 wrote:
>
>> In D159256#4630410 , @jmmartinez 
>> wrote:
>>
>>> @jhuber6 I was wondering if there is a reason you kept 3 versions of 
>>> `mergeDefaultFunctionDefinitionAttributes` in 
>>> https://reviews.llvm.org/D152391 ?
>>
>> I believe it's because one was a freestanding function, the other was a 
>> member function, and the last was a common implementation.
>
> Would it be ok if I keep only one? It seems that the member function is not 
> used (I was not sure if there was some external code using it).
>
> If not, I can also keep just 2 versions (the freestanding function and the 
> member function), move the implementation to the freestanding one, and drop 
> the static function since it is redundant.

Yeah I think I noticed that when I was doing the patch but I just left it 
because I figured it would be less disruptive. It should be fine since I'm not 
aware of any other users.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159256

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


[PATCH] D159105: [analyzer] ArrayBoundCheckerV2 should check the region for taint as well

2023-08-31 Thread Balázs Benics via Phabricator via cfe-commits
steakhal added a comment.

I'm thinking of a heuristic like this:

  bool IsAtOffsetZero = [ByteOffset] {
const auto *Int = ByteOffset.getAsInteger();
return Int && Int->isZero();
  }();
  // ...
  if (state_precedesLowerBound && state_withinLowerBound && !IsAtOffsetZero &&
  isTainted(state, location)) {
reportTaintOOB(checkerContext, state_precedesLowerBound, location);
return;
  }

It will definitely not work for all cases but should filter out the most 
annoying ones.

  int testTaintedPtr() {
// Read a pointer from a tainted source and dereference it.
char *app = getenv("APP_NAME");
if (!app)
  return -1;
if (app[0] == '\0') return 0; // no-warning: Allow manual checking for null 
terminator at offset zero.
if (app[1] == '\0') return 1; // expected-warning {{Out of bound memory 
access (index is tainted)}} Any other index than 0 is disallowed.
if (app[2] == '\0') return 2; // no-warning: The path already sunk.
return -1;
  }




Comment at: clang/test/Analysis/taint-generic.c:1133-1141
+void testTaintedLowerConstrainedIndex() {
+  int n;
+  scanf("%d", &n);
+  if (n >= 0) {
+// We only constained the lower end, and it's tainted => report.
+Buffer[n] = 1; // expected-warning {{Out of bound memory access (index is 
tainted)}}
+  }

donat.nagy wrote:
> Also add the "opposite" of this where you test `if (n < BUFSIZE)`.
Makes sense.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159105

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


[PATCH] D158869: [clang] Fix timing of propagation of MSInheritanceAttr for template instantiation declarations.

2023-08-31 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.

LGTM but please add a release note


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158869

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


[PATCH] D159274: [clang][dataflow] When dumping `ExprToVal`, dump the `Value`, not just its location.

2023-08-31 Thread Martin Böhme via Phabricator via cfe-commits
mboehme created this revision.
Herald added subscribers: martong, xazax.hun.
Herald added a reviewer: NoQ.
Herald added a project: All.
mboehme requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This makes `ExprToVal` dumping consistent with `LocToVal` dumping.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D159274

Files:
  clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp


Index: clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
===
--- clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
+++ clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
@@ -918,7 +918,7 @@
 
   OS << "ExprToVal:\n";
   for (auto [E, V] : ExprToVal)
-OS << "  [" << E << ", " << V << "]\n";
+OS << "  [" << E << ", " << V << ": " << *V << "]\n";
 
   OS << "LocToVal:\n";
   for (auto [L, V] : LocToVal) {


Index: clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
===
--- clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
+++ clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
@@ -918,7 +918,7 @@
 
   OS << "ExprToVal:\n";
   for (auto [E, V] : ExprToVal)
-OS << "  [" << E << ", " << V << "]\n";
+OS << "  [" << E << ", " << V << ": " << *V << "]\n";
 
   OS << "LocToVal:\n";
   for (auto [L, V] : LocToVal) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 19550e7 - [NFC][Clang] Remove redundant function definitions

2023-08-31 Thread Juan Manuel MARTINEZ CAAMAÑO via cfe-commits

Author: Juan Manuel MARTINEZ CAAMAÑO
Date: 2023-08-31T14:47:42+02:00
New Revision: 19550e79b50f0689404309a2c6091f0b53770e08

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

LOG: [NFC][Clang] Remove redundant function definitions

There were 3 definitions of the mergeDefaultFunctionDefinitionAttributes
function: A private implementation, a version exposed in CodeGen, a
version exposed in CodeGenModule.

This patch removes the private and the CodeGenModule versions and keeps
a single definition in CodeGen.

Reviewed By: jhuber6

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

Added: 


Modified: 
clang/lib/CodeGen/CGCall.cpp
clang/lib/CodeGen/CGCall.h
clang/lib/CodeGen/CodeGenModule.h

Removed: 




diff  --git a/clang/lib/CodeGen/CGCall.cpp b/clang/lib/CodeGen/CGCall.cpp
index 01bbbd7371aad4..af05eec0ce19fc 100644
--- a/clang/lib/CodeGen/CGCall.cpp
+++ b/clang/lib/CodeGen/CGCall.cpp
@@ -2002,10 +2002,7 @@ static void getTrivialDefaultFunctionAttributes(
   }
 }
 
-/// Adds attributes to \p F according to our \p CodeGenOpts and \p LangOpts, as
-/// though we had emitted it ourselves. We remove any attributes on F that
-/// conflict with the attributes we add here.
-static void mergeDefaultFunctionDefinitionAttributes(
+void CodeGen::mergeDefaultFunctionDefinitionAttributes(
 llvm::Function &F, const CodeGenOptions &CodeGenOpts,
 const LangOptions &LangOpts, const TargetOptions &TargetOpts,
 bool WillInternalize) {
@@ -2065,15 +2062,6 @@ static void mergeDefaultFunctionDefinitionAttributes(
   F.addFnAttrs(FuncAttrs);
 }
 
-void clang::CodeGen::mergeDefaultFunctionDefinitionAttributes(
-llvm::Function &F, const CodeGenOptions CodeGenOpts,
-const LangOptions &LangOpts, const TargetOptions &TargetOpts,
-bool WillInternalize) {
-
-  ::mergeDefaultFunctionDefinitionAttributes(F, CodeGenOpts, LangOpts,
- TargetOpts, WillInternalize);
-}
-
 void CodeGenModule::getTrivialDefaultFunctionAttributes(
 StringRef Name, bool HasOptnone, bool AttrOnCallSite,
 llvm::AttrBuilder &FuncAttrs) {
@@ -2094,15 +2082,6 @@ void 
CodeGenModule::getDefaultFunctionAttributes(StringRef Name,
 addMergableDefaultFunctionAttributes(CodeGenOpts, FuncAttrs);
 }
 
-/// Apply default attributes to \p F, accounting for merge semantics of
-/// attributes that should not overwrite existing attributes.
-void CodeGenModule::mergeDefaultFunctionDefinitionAttributes(
-llvm::Function &F, bool WillInternalize) {
-  ::mergeDefaultFunctionDefinitionAttributes(F, getCodeGenOpts(), 
getLangOpts(),
- getTarget().getTargetOpts(),
- WillInternalize);
-}
-
 void CodeGenModule::addDefaultFunctionDefinitionAttributes(
 llvm::AttrBuilder &attrs) {
   getDefaultFunctionAttributes(/*function name*/ "", /*optnone*/ false,

diff  --git a/clang/lib/CodeGen/CGCall.h b/clang/lib/CodeGen/CGCall.h
index 75c4dcc400caf0..cc0b1daf338e65 100644
--- a/clang/lib/CodeGen/CGCall.h
+++ b/clang/lib/CodeGen/CGCall.h
@@ -395,10 +395,25 @@ class ReturnValueSlot {
   bool isExternallyDestructed() const { return IsExternallyDestructed; }
 };
 
-/// Helper to add attributes to \p F according to the CodeGenOptions and
-/// LangOptions without requiring a CodeGenModule to be constructed.
+/// Adds attributes to \p F according to our \p CodeGenOpts and \p LangOpts, as
+/// though we had emitted it ourselves. We remove any attributes on F that
+/// conflict with the attributes we add here.
+///
+/// This is useful for adding attrs to bitcode modules that you want to link
+/// with but don't control, such as CUDA's libdevice.  When linking with such
+/// a bitcode library, you might want to set e.g. its functions'
+/// "unsafe-fp-math" attribute to match the attr of the functions you're
+/// codegen'ing.  Otherwise, LLVM will interpret the bitcode module's lack of
+/// unsafe-fp-math attrs as tantamount to unsafe-fp-math=false, and then LLVM
+/// will propagate unsafe-fp-math=false up to every transitive caller of a
+/// function in the bitcode library!
+///
+/// With the exception of fast-math attrs, this will only make the attributes
+/// on the function more conservative.  But it's unsafe to call this on a
+/// function which relies on particular fast-math attributes for correctness.
+/// It's up to you to ensure that this is safe.
 void mergeDefaultFunctionDefinitionAttributes(llvm::Function &F,
-  const CodeGenOptions CodeGenOpts,
+  const CodeGenOptions 
&CodeGenOpts,
   const LangOptions &LangOpts,
   

[PATCH] D159256: [NFC][Clang] Remove redundant function definitions

2023-08-31 Thread Juan Manuel Martinez Caamaño 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 rG19550e79b50f: [NFC][Clang] Remove redundant function 
definitions (authored by jmmartinez).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159256

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGCall.h
  clang/lib/CodeGen/CodeGenModule.h

Index: clang/lib/CodeGen/CodeGenModule.h
===
--- clang/lib/CodeGen/CodeGenModule.h
+++ clang/lib/CodeGen/CodeGenModule.h
@@ -1259,26 +1259,6 @@
   llvm::AttributeList &Attrs, unsigned &CallingConv,
   bool AttrOnCallSite, bool IsThunk);
 
-  /// Adds attributes to F according to our CodeGenOptions and LangOptions, as
-  /// though we had emitted it ourselves.  We remove any attributes on F that
-  /// conflict with the attributes we add here.
-  ///
-  /// This is useful for adding attrs to bitcode modules that you want to link
-  /// with but don't control, such as CUDA's libdevice.  When linking with such
-  /// a bitcode library, you might want to set e.g. its functions'
-  /// "unsafe-fp-math" attribute to match the attr of the functions you're
-  /// codegen'ing.  Otherwise, LLVM will interpret the bitcode module's lack of
-  /// unsafe-fp-math attrs as tantamount to unsafe-fp-math=false, and then LLVM
-  /// will propagate unsafe-fp-math=false up to every transitive caller of a
-  /// function in the bitcode library!
-  ///
-  /// With the exception of fast-math attrs, this will only make the attributes
-  /// on the function more conservative.  But it's unsafe to call this on a
-  /// function which relies on particular fast-math attributes for correctness.
-  /// It's up to you to ensure that this is safe.
-  void mergeDefaultFunctionDefinitionAttributes(llvm::Function &F,
-bool WillInternalize);
-
   /// Like the overload taking a `Function &`, but intended specifically
   /// for frontends that want to build on Clang's target-configuration logic.
   void addDefaultFunctionDefinitionAttributes(llvm::AttrBuilder &attrs);
Index: clang/lib/CodeGen/CGCall.h
===
--- clang/lib/CodeGen/CGCall.h
+++ clang/lib/CodeGen/CGCall.h
@@ -395,10 +395,25 @@
   bool isExternallyDestructed() const { return IsExternallyDestructed; }
 };
 
-/// Helper to add attributes to \p F according to the CodeGenOptions and
-/// LangOptions without requiring a CodeGenModule to be constructed.
+/// Adds attributes to \p F according to our \p CodeGenOpts and \p LangOpts, as
+/// though we had emitted it ourselves. We remove any attributes on F that
+/// conflict with the attributes we add here.
+///
+/// This is useful for adding attrs to bitcode modules that you want to link
+/// with but don't control, such as CUDA's libdevice.  When linking with such
+/// a bitcode library, you might want to set e.g. its functions'
+/// "unsafe-fp-math" attribute to match the attr of the functions you're
+/// codegen'ing.  Otherwise, LLVM will interpret the bitcode module's lack of
+/// unsafe-fp-math attrs as tantamount to unsafe-fp-math=false, and then LLVM
+/// will propagate unsafe-fp-math=false up to every transitive caller of a
+/// function in the bitcode library!
+///
+/// With the exception of fast-math attrs, this will only make the attributes
+/// on the function more conservative.  But it's unsafe to call this on a
+/// function which relies on particular fast-math attributes for correctness.
+/// It's up to you to ensure that this is safe.
 void mergeDefaultFunctionDefinitionAttributes(llvm::Function &F,
-  const CodeGenOptions CodeGenOpts,
+  const CodeGenOptions &CodeGenOpts,
   const LangOptions &LangOpts,
   const TargetOptions &TargetOpts,
   bool WillInternalize);
Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -2002,10 +2002,7 @@
   }
 }
 
-/// Adds attributes to \p F according to our \p CodeGenOpts and \p LangOpts, as
-/// though we had emitted it ourselves. We remove any attributes on F that
-/// conflict with the attributes we add here.
-static void mergeDefaultFunctionDefinitionAttributes(
+void CodeGen::mergeDefaultFunctionDefinitionAttributes(
 llvm::Function &F, const CodeGenOptions &CodeGenOpts,
 const LangOptions &LangOpts, const TargetOptions &TargetOpts,
 bool WillInternalize) {
@@ -2065,15 +2062,6 @@
   F.addFnAttrs(FuncAttrs);
 }
 
-void clang::CodeGen::mergeD

[PATCH] D159256: [NFC][Clang] Remove redundant function definitions

2023-08-31 Thread Juan Manuel Martinez Caamaño via Phabricator via cfe-commits
jmmartinez added a comment.

Thanks for the review!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159256

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


[PATCH] D158296: [clang] Diagnose overly complex Record in __builtin_dump_struct

2023-08-31 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/lib/Sema/SemaChecking.cpp:732-733
+int RDKind = RD->isClass() ? 0 : (RD->isStruct() ? 1 : 2);
+S.Diag(PtrArg->getBeginLoc(), diag::err_builtin_dump_struct_too_complex)
+<< RDKind << RD->getName();
+return ExprError();

rsmith wrote:
> aaron.ballman wrote:
> > This will correctly handle diagnosing a gigantic anonymous struct.
> Producing an error here seems likely to eventually cause problems in practice 
> for some users: people are using `__builtin_dump_struct` in generic code for 
> reflection purposes, not just for debugging, and this will cause us to start 
> rejecting complex generic code.
> 
> Instead of rejecting, can we produce a tree of `PseudoObjectExpr`s if we have 
> too many steps to store in a single expression?
> Producing an error here seems likely to eventually cause problems in practice 
> for some users: people are using __builtin_dump_struct in generic code for 
> reflection purposes, not just for debugging, and this will cause us to start 
> rejecting complex generic code.
>
> Instead of rejecting, can we produce a tree of PseudoObjectExprs if we have 
> too many steps to store in a single expression?

I think that requires wider discussion -- I don't think `__builtin_dump_struct` 
is a reasonable interface we want to support for reflection (in fact, I'd argue 
it's an explicit non-goal, the same as reflection via `-ast-dump`). 
Compile-time reflection is something we're likely to need to support more 
intentionally and I don't think we're going to want to use this as an interface 
for it or have to maintain it as a reflection tool long-term. As such, I think 
producing a tree of `PseudoObjectExpr`s is overkill; you can quote me on this a 
few years from now when we're laughing at its quaintness, but "16k fields of 
debug output is enough for anyone" for a debugging interface.

(That said, I think we should be considering what support we want to add to the 
compiler for reflection in service of the work being done in WG21 on the topic 
-- if `__builtin_dump_struct` is being used for reflection in practice, it 
would be nice to give people a supported, more ergonomic interface for it that 
we can use for a future version of C++.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158296

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


[PATCH] D159107: [analyzer] ArrayBoundCheckerV2 should disallow forming lvalues to out-of-bounds locations

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

In D159107#4630764 , @steakhal wrote:

> In D159107#4630573 , @donat.nagy 
> wrote:
>
>> I don't think that the `&arr[N]` issue is too serious: we can just increment 
>> the array extent when the parent expression of the array subscript operator 
>> is the unary operator `&`. If the past-the-end pointer ends up dereferenced 
>> later, the current code is sufficient to report it as a bug (as the checker 
>> monitors all dereferences).
>
> My instinct suggests that there is more behind the curtain.

As a rough solution we can simply say that this checker ignores `&arr[idx]` 
(because it's just a different way of writing `arr + idx`) and only checks 
expressions where "real" dereference happens. This way the checker would won't 
emit false positives on past-the-end pointers and still report every out of 
bound //memory access// (including off-by-one errors).

This can be refined by adding a check that which validates that in an 
expression like `&arr[idx]` the index satisfies `0 <= idx && idx <= 
array_size`. This is conceptually independent (but can use the same 
implementation as the real memory access check) and would add some useful 
reports and constraints without breaking anything.

In D159107#4630764 , @steakhal wrote:

> For example, on an expression `&arr[N]` (of type  `int arr[10]`), we would 
> constrain `N`. We could say that we allow the one before and one after 
> elements, thus introduce a constraint: `N: [-1, 11]`. This `-1` later could 
> participate in casts, and end up interpreted as a really large unsigned 
> number. I should also think about how would we detect off-by-one errors, 
> which is a common category.

Pointer arithmetic is very restricted in the standard, e.g. 
http://eel.is/c++draft/basic.compound says that

> Every value of pointer type is one of the following:
> (3.1) a pointer to an object or function (the pointer is said to point to the 
> object or function), or
> (3.2) a pointer past the end of an object ([expr.add]), or
> (3.3) the null pointer value for that type, or
> (3.4) an invalid pointer value.

As this explicitly rules out before-first-element pointers and they are not too 
common (I don't recall any code that used them), I don't think that they 
deserve a special case (just report them if we see them).

In D159107#4630764 , @steakhal wrote:

> The thing is, that I only have this week, aka. 1.5 days before I leave for 
> vacation. :D
> In the future, (no ETA), we likely come back to the Juliet improvements.

Of course, it's completely reasonable to focus on a limited set of changes 
before the vacation.

In the meantime, I'll probably work on one or more commits that would (1) 
switch to using the concrete `check::PostStmt` callbacks instead of 
`check::Location` (and `Bind`) like this commit (2) improve the diagnostics, 
add more details to the messages. When will you return from the vacation? 
Should I wait for you with the review of these changes (if I can write and test 
them before your return)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159107

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


[PATCH] D157747: Support Unicode Microsoft predefined macros

2023-08-31 Thread Richard Dzenis via Phabricator via cfe-commits
RIscRIpt abandoned this revision.
RIscRIpt added a comment.

I found a way to implement `__LPREFIX`-macros-family in Clang. I need some more 
time to finish and polish it. Going to post it a couple of weeks later.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157747

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


[PATCH] D159279: [clang] Emit `Wformat` for bool value and char specifier confusion in scanf

2023-08-31 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.

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


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D159279

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/AST/FormatString.cpp
  clang/test/SemaCXX/format-strings-scanf.cpp


Index: clang/test/SemaCXX/format-strings-scanf.cpp
===
--- clang/test/SemaCXX/format-strings-scanf.cpp
+++ clang/test/SemaCXX/format-strings-scanf.cpp
@@ -29,6 +29,8 @@
 
 void test(void) {
 bag b;
+// expected-warning@+2 {{format specifies type 'char *' but the argument 
has type 'bool *'}}
+// expected-warning@+1 {{format specifies type 'unsigned char *' but the 
argument has type 'bool *'}}
 scan("%hhi %hhu %hhi %hhu", &b.sc, &b.uc, &b.b, &b.b);
 scan("%hi %hu", &b.ss, &b.us);
 scan("%i %u", &b.si, &b.ui);
Index: clang/lib/AST/FormatString.cpp
===
--- clang/lib/AST/FormatString.cpp
+++ clang/lib/AST/FormatString.cpp
@@ -368,8 +368,11 @@
 case BuiltinType::SChar:
 case BuiltinType::UChar:
 case BuiltinType::Char_U:
+return Match;
 case BuiltinType::Bool:
-  return Match;
+  if (!Ptr)
+return Match;
+  break;
 }
 // "Partially matched" because of promotions?
 if (!Ptr) {
@@ -410,11 +413,14 @@
 switch (BT->getKind()) {
   default:
 break;
+  case BuiltinType::Bool:
+if (Ptr && (T == C.UnsignedCharTy || T == C.SignedCharTy))
+  return NoMatch;
+[[fallthrough]];
   case BuiltinType::Char_S:
   case BuiltinType::SChar:
   case BuiltinType::Char_U:
   case BuiltinType::UChar:
-  case BuiltinType::Bool:
 if (T == C.UnsignedShortTy || T == C.ShortTy)
   return NoMatchTypeConfusion;
 if (T == C.UnsignedCharTy || T == C.SignedCharTy)
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -208,6 +208,9 @@
 - For function multi-versioning using the ``target`` or ``target_clones``
   attributes, remove comdat for internal linkage functions.
   (`#65114 `_)
+- Clang now reports ``-Wformat`` for bool value and char specifier confusion
+  in scanf. Fixes
+  (`#64987 `_)
 
 Bug Fixes to Compiler Builtins
 ^^


Index: clang/test/SemaCXX/format-strings-scanf.cpp
===
--- clang/test/SemaCXX/format-strings-scanf.cpp
+++ clang/test/SemaCXX/format-strings-scanf.cpp
@@ -29,6 +29,8 @@
 
 void test(void) {
 bag b;
+// expected-warning@+2 {{format specifies type 'char *' but the argument has type 'bool *'}}
+// expected-warning@+1 {{format specifies type 'unsigned char *' but the argument has type 'bool *'}}
 scan("%hhi %hhu %hhi %hhu", &b.sc, &b.uc, &b.b, &b.b);
 scan("%hi %hu", &b.ss, &b.us);
 scan("%i %u", &b.si, &b.ui);
Index: clang/lib/AST/FormatString.cpp
===
--- clang/lib/AST/FormatString.cpp
+++ clang/lib/AST/FormatString.cpp
@@ -368,8 +368,11 @@
 case BuiltinType::SChar:
 case BuiltinType::UChar:
 case BuiltinType::Char_U:
+return Match;
 case BuiltinType::Bool:
-  return Match;
+  if (!Ptr)
+return Match;
+  break;
 }
 // "Partially matched" because of promotions?
 if (!Ptr) {
@@ -410,11 +413,14 @@
 switch (BT->getKind()) {
   default:
 break;
+  case BuiltinType::Bool:
+if (Ptr && (T == C.UnsignedCharTy || T == C.SignedCharTy))
+  return NoMatch;
+[[fallthrough]];
   case BuiltinType::Char_S:
   case BuiltinType::SChar:
   case BuiltinType::Char_U:
   case BuiltinType::UChar:
-  case BuiltinType::Bool:
 if (T == C.UnsignedShortTy || T == C.ShortTy)
   return NoMatchTypeConfusion;
 if (T == C.UnsignedCharTy || T == C.SignedCharTy)
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -208,6 +208,9 @@
 - For function multi-versioning using the ``target`` or ``target_clones``
   attributes, remove comdat for internal linkage functions.
   (`#65114 `_)
+- Clang now reports ``-Wformat`` for bool value and char

[PATCH] D159107: [analyzer] ArrayBoundCheckerV2 should disallow forming lvalues to out-of-bounds locations

2023-08-31 Thread Balázs Benics via Phabricator via cfe-commits
steakhal added a comment.

In D159107#4631069 , @donat.nagy 
wrote:

> In D159107#4630764 , @steakhal 
> wrote:
>
>> In D159107#4630573 , @donat.nagy 
>> wrote:
>>
>>> I don't think that the `&arr[N]` issue is too serious: we can just 
>>> increment the array extent when the parent expression of the array 
>>> subscript operator is the unary operator `&`. If the past-the-end pointer 
>>> ends up dereferenced later, the current code is sufficient to report it as 
>>> a bug (as the checker monitors all dereferences).
>>
>> My instinct suggests that there is more behind the curtain.
>
> As a rough solution we can simply say that this checker ignores `&arr[idx]` 
> (because it's just a different way of writing `arr + idx`) and only checks 
> expressions where "real" dereference happens. This way the checker would 
> won't emit false positives on past-the-end pointers and still report every 
> out of bound //memory access// (including off-by-one errors).
>
> This can be refined by adding a check that which validates that in an 
> expression like `&arr[idx]` the index satisfies `0 <= idx && idx <= 
> array_size`. This is conceptually independent (but can use the same 
> implementation as the real memory access check) and would add some useful 
> reports and constraints without breaking anything.

It makes sense, but it would need to special case on the parent or child AST 
node, which isn't really clean. But I think we think the same on this subject.
(Note that the `&` is a parent of the `arr[N]`, where the checker would 
trigger, thus we would need to check the parent node to ignore such cases; and 
that is not really supported in the AST, and using the ParentMap for it is 
expensive. Remember, that this would happen for any SubscriptExpr as many times 
they are visited.)

> In D159107#4630764 , @steakhal 
> wrote:
>
>> For example, on an expression `&arr[N]` (of type  `int arr[10]`), we would 
>> constrain `N`. We could say that we allow the one before and one after 
>> elements, thus introduce a constraint: `N: [-1, 11]`. This `-1` later could 
>> participate in casts, and end up interpreted as a really large unsigned 
>> number. I should also think about how would we detect off-by-one errors, 
>> which is a common category.
>
> Pointer arithmetic is very restricted in the standard, e.g. 
> http://eel.is/c++draft/basic.compound says that
>
>> Every value of pointer type is one of the following:
>> (3.1) a pointer to an object or function (the pointer is said to point to 
>> the object or function), or
>> (3.2) a pointer past the end of an object ([expr.add]), or
>> (3.3) the null pointer value for that type, or
>> (3.4) an invalid pointer value.
>
> As this explicitly rules out before-first-element pointers and they are not 
> too common (I don't recall any code that used them), I don't think that they 
> deserve a special case (just report them if we see them).

Yes. They are really restricted, and AFAIK only past-the-end pointers are 
allowed, unlike before-the-first element. Such code might be written for 
reverse iterations.
But we know that hardware would work like that, and people might rely on it.

> In D159107#4630764 , @steakhal 
> wrote:
>
>> The thing is, that I only have this week, aka. 1.5 days before I leave for 
>> vacation. :D
>> In the future, (no ETA), we likely come back to the Juliet improvements.
>
> Of course, it's completely reasonable to focus on a limited set of changes 
> before the vacation.
>
> In the meantime, I'll probably work on one or more commits that would (1) 
> switch to using the concrete `check::PostStmt` callbacks instead of 
> `check::Location` (and `Bind`) like this commit (2) improve the diagnostics, 
> add more details to the messages. When will you return from the vacation? 
> Should I wait for you with the review of these changes (if I can write and 
> test them before your return)?

I don't think you should wait for me. I'll be off for a week though, but I 
might not have the bandwidth to do reviews even after that.
Post it once you are fine with it. Prove it "behaves well", and just wait for 
someone to review it. It might be noq, xazax or me. We will see.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159107

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


[clang] 27313b6 - Revert "[CUDA][HIP] Fix overloading resolution in global variable initializer"

2023-08-31 Thread Yaxun Liu via cfe-commits

Author: Yaxun (Sam) Liu
Date: 2023-08-31T09:02:49-04:00
New Revision: 27313b68ef0ec9a94c4288eca9af6ca25cd17f8f

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

LOG: Revert "[CUDA][HIP] Fix overloading resolution in global variable 
initializer"

This reverts commit de0df639724b10001ea9a74539381ea494296be9.

It was reverted due to regression in HIP unit test on Windows:

 In file included from C:\hip-tests\catch\unit\graph\hipGraphClone.cc:37:

 In file included from C:\hip-tests\catch\.\include\hip_test_common.hh:24:

 In file included from C:\hip-tests\catch\.\include/hip_test_context.hh:24:

 In file included from 
C:/install/native/Release/x64/hip/include\hip/hip_runtime.h:54:

 C:/dk/win\vc\14.31.31107\include\thread:76:70: error: cannot initialize a 
parameter of type '_beginthreadex_proc_type' (aka 'unsigned int (*)(void *) 
__attribute__((stdcall))') with an lvalue of type 'const unsigned int (*)(void 
*) noexcept __attribute__((stdcall))': different exception specifications

76 | reinterpret_cast(_CSTD _beginthreadex(nullptr, 0, 
_Invoker_proc, _Decay_copied.get(), 0, &_Thr._Id));

   |  
^

 C:\hip-tests\catch\unit\graph\hipGraphClone.cc:290:21) &>' requested here

90 | _Start(_STD forward<_Fn>(_Fx), _STD forward<_Args>(_Ax)...);

   | ^

 C:\hip-tests\catch\unit\graph\hipGraphClone.cc:290:21) &, 0>' requested here

   311 | std::thread t(lambdaFunc);

   | ^

 C:/dk/win\ms_wdk\e22621\Include\10.0.22621.0\ucrt\process.h:99:40: note: 
passing argument to parameter '_StartAddress' here

99 | _In_  _beginthreadex_proc_type _StartAddress,

   |^

 1 error generated when compiling for gfx1030.

Added: 
clang/test/SemaCUDA/global-initializers-host.cu

Modified: 
clang/include/clang/Sema/Sema.h
clang/lib/Parse/ParseDecl.cpp
clang/lib/Sema/SemaCUDA.cpp
clang/lib/Sema/SemaDeclAttr.cpp
clang/lib/Sema/SemaOverload.cpp
clang/lib/Sema/SemaType.cpp
clang/test/SemaCUDA/amdgpu-windows-vectorcall.cu
clang/test/SemaCUDA/function-overload.cu

Removed: 
clang/test/CodeGenCUDA/global-initializers.cu
clang/test/SemaCUDA/global-initializers.cu



diff  --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 28e085ccebbb2f..1980571e6656f9 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -1012,14 +1012,6 @@ class Sema final {
 }
   } DelayedDiagnostics;
 
-  enum CUDAFunctionTarget {
-CFT_Device,
-CFT_Global,
-CFT_Host,
-CFT_HostDevice,
-CFT_InvalidTarget
-  };
-
   /// A RAII object to temporarily push a declaration context.
   class ContextRAII {
   private:
@@ -4765,13 +4757,8 @@ class Sema final {
   bool isValidPointerAttrType(QualType T, bool RefOkay = false);
 
   bool CheckRegparmAttr(const ParsedAttr &attr, unsigned &value);
-
-  /// Check validaty of calling convention attribute \p attr. If \p FD
-  /// is not null pointer, use \p FD to determine the CUDA/HIP host/device
-  /// target. Otherwise, it is specified by \p CFT.
   bool CheckCallingConvAttr(const ParsedAttr &attr, CallingConv &CC,
-const FunctionDecl *FD = nullptr,
-CUDAFunctionTarget CFT = CFT_InvalidTarget);
+const FunctionDecl *FD = nullptr);
   bool CheckAttrTarget(const ParsedAttr &CurrAttr);
   bool CheckAttrNoArgs(const ParsedAttr &CurrAttr);
   bool checkStringLiteralArgumentAttr(const AttributeCommonInfo &CI,
@@ -13278,6 +13265,14 @@ class Sema final {
   void checkTypeSupport(QualType Ty, SourceLocation Loc,
 ValueDecl *D = nullptr);
 
+  enum CUDAFunctionTarget {
+CFT_Device,
+CFT_Global,
+CFT_Host,
+CFT_HostDevice,
+CFT_InvalidTarget
+  };
+
   /// Determines whether the given function is a CUDA device/host/kernel/etc.
   /// function.
   ///
@@ -13296,29 +13291,6 @@ class Sema final {
   /// Determines whether the given variable is emitted on host or device side.
   CUDAVariableTarget IdentifyCUDATarget(const VarDecl *D);
 
-  /// Defines kinds of CUDA global host/device context where a function may be
-  /// called.
-  enum CUDATargetContextKind {
-CTCK_Unknown,   /// Unknown context
-CTCK_InitGlobalVar, /// Function called during global variable
-/// initialization
-  };
-
-  /// Define the current global CUDA host/device context where a function may 
be
-  /// called. Only used when a function is called outside of any functions.
-  struct CUDATargetContext {
-CUDAFunctionTarget Target = CFT_HostDevice;
-CUDATargetContextKi

[libclc] 37a3de1 - libclc: Fix signed integer underflow in abs_diff

2023-08-31 Thread Fraser Cormack via cfe-commits

Author: Fraser Cormack
Date: 2023-08-31T14:28:16+01:00
New Revision: 37a3de1e2eedf848b8442217ef3790436f69a7db

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

LOG: libclc: Fix signed integer underflow in abs_diff

We noticed this same issue in our own implementation of abs_diff, and
the same issue also came up in the abs_diff reference function in the
OpenCL CTS.

Reviewed By: rjodinchr

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

Added: 


Modified: 
libclc/generic/lib/integer/abs_diff.inc

Removed: 




diff  --git a/libclc/generic/lib/integer/abs_
diff .inc b/libclc/generic/lib/integer/abs_
diff .inc
index f39c3ff4d3e8ab..2d3c492cae0e68 100644
--- a/libclc/generic/lib/integer/abs_
diff .inc
+++ b/libclc/generic/lib/integer/abs_
diff .inc
@@ -1,3 +1,5 @@
 _CLC_OVERLOAD _CLC_DEF __CLC_U_GENTYPE abs_
diff (__CLC_GENTYPE x, __CLC_GENTYPE y) {
-  return __builtin_astype((__CLC_GENTYPE)(x > y ? x-y : y-x), __CLC_U_GENTYPE);
+  __CLC_U_GENTYPE ux = __builtin_astype(x, __CLC_U_GENTYPE);
+  __CLC_U_GENTYPE uy = __builtin_astype(y, __CLC_U_GENTYPE);
+  return x > y ? ux - uy : uy - ux;
 }



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


[PATCH] D159197: [clang][ci] Don't block all jobs on clang-format

2023-08-31 Thread Louis Dionne via Phabricator via cfe-commits
ldionne added a comment.

In D159197#4628232 , @aaron.ballman 
wrote:

> Thank you for this! I'm not qualified to say the changes are correct (they 
> look sensible to me though), but I am really appreciative of the change.

Yup this is mostly for awareness, the changes are simple enough and the CI run 
in this review shows that they worked (there's no wait step anymore after the 
clang-format).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159197

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


[clang] e34ddb1 - [clang][ci] Don't block all jobs on clang-format

2023-08-31 Thread Louis Dionne via cfe-commits

Author: Louis Dionne
Date: 2023-08-31T09:52:41-04:00
New Revision: e34ddb1b5da499d0e7c8e0d33ff1ec89d97cf5f1

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

LOG: [clang][ci] Don't block all jobs on clang-format

It was expressed in some reviews that Clang folks didn't want to hold
off other testing jobs in case clang-format failed. This patch makes
it so that the basic clang testing jobs will run even if clang-format
fails on the patch. The overall build will still be marked as failed,
but it will be possible to see the failures in clang tests so at least
there will be some feedback available.

The whole pipeline was originally blocked on clang-format because we
inherited that pipeline definition from libc++, where we want to block
on clang-format for capacity reasons.

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

Added: 


Modified: 
clang/utils/ci/buildkite-pipeline.yml

Removed: 




diff  --git a/clang/utils/ci/buildkite-pipeline.yml 
b/clang/utils/ci/buildkite-pipeline.yml
index 92793480217932..7a679176038c69 100644
--- a/clang/utils/ci/buildkite-pipeline.yml
+++ b/clang/utils/ci/buildkite-pipeline.yml
@@ -20,7 +20,6 @@ steps:
   - label: "Format"
 commands:
   - "clang/utils/ci/run-buildbot check-format"
-
 agents:
   queue: "linux"
 retry:
@@ -29,8 +28,6 @@ steps:
   limit: 2
 timeout_in_minutes: 120
 
-  - wait
-
   - label: "Building and testing clang (Linux)"
 commands:
   - "clang/utils/ci/run-buildbot build-clang"



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


[PATCH] D159197: [clang][ci] Don't block all jobs on clang-format

2023-08-31 Thread Louis Dionne via Phabricator via cfe-commits
This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rGe34ddb1b5da4: [clang][ci] Don't block all jobs on 
clang-format (authored by ldionne).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159197

Files:
  clang/utils/ci/buildkite-pipeline.yml


Index: clang/utils/ci/buildkite-pipeline.yml
===
--- clang/utils/ci/buildkite-pipeline.yml
+++ clang/utils/ci/buildkite-pipeline.yml
@@ -20,7 +20,6 @@
   - label: "Format"
 commands:
   - "clang/utils/ci/run-buildbot check-format"
-
 agents:
   queue: "linux"
 retry:
@@ -29,8 +28,6 @@
   limit: 2
 timeout_in_minutes: 120
 
-  - wait
-
   - label: "Building and testing clang (Linux)"
 commands:
   - "clang/utils/ci/run-buildbot build-clang"


Index: clang/utils/ci/buildkite-pipeline.yml
===
--- clang/utils/ci/buildkite-pipeline.yml
+++ clang/utils/ci/buildkite-pipeline.yml
@@ -20,7 +20,6 @@
   - label: "Format"
 commands:
   - "clang/utils/ci/run-buildbot check-format"
-
 agents:
   queue: "linux"
 retry:
@@ -29,8 +28,6 @@
   limit: 2
 timeout_in_minutes: 120
 
-  - wait
-
   - label: "Building and testing clang (Linux)"
 commands:
   - "clang/utils/ci/run-buildbot build-clang"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D159261: [clang][dataflow] Eliminate deprecated `DataflowAnalysis` constructor.

2023-08-31 Thread Yitzhak Mandelbaum via Phabricator via cfe-commits
ymandel accepted this revision.
ymandel added a comment.
This revision is now accepted and ready to land.

Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159261

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


[PATCH] D159212: [MLIR] Allow dialects to disable CSE for certain operations

2023-08-31 Thread Sergio Afonso via Phabricator via cfe-commits
skatrak added a comment.

Thank you for your comments @jsjodin and @kiranchandramohan , I created an RFC 
here 

 to try to get consensus on what the best solution should be.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159212

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


[PATCH] D159284: Fix Record initialization with InitListExpr and inheritances

2023-08-31 Thread Kinuko Yasuda via Phabricator via cfe-commits
kinu created this revision.
Herald added a reviewer: NoQ.
Herald added a project: All.
kinu requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Usually RecordValues for record objects (e.g. struct) are initialized with
`Environment::createValue()` which internally calls `getObjectFields()` to
collects all fields from the current and base classes, and then filter them
with `ModeledValues` via `DACtx::getModeledFields()` so that the fields that
are actually referenced are modeled.

The consistent set of fields should be initialized when a record is initialized
with an initializer list (InitListExpr), however the existing code's behavior
was different.

Before this patch:

- When a struct is initialized with InitListExpr, its fields are initialized 
based on what is returned by `getFieldsForInitListExpr()`, which only collects 
the direct fields in the current class, but not from the base classes. 
Moreover, if the base classes have their own InitListExpr, values that are 
initialized by their InitListExpr's weren't merged into the child objects.

After this patch:

- When a struct is initialized with InitListExpr, it collects and merges the 
fields in the base classes that were initialized by their InitListExpr's. The 
code also asserts that the consistent set of fields are initialized with the 
ModeledFields.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D159284

Files:
  clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
  clang/lib/Analysis/FlowSensitive/Transfer.cpp
  clang/unittests/Analysis/FlowSensitive/TransferTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
===
--- clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
+++ clang/unittests/Analysis/FlowSensitive/TransferTest.cpp
@@ -1438,6 +1438,150 @@
   llvm::Succeeded());
 }
 
+TEST(TransferTest, StructModeledFieldsWithComplicatedInheritance) {
+  std::string Code = R"(
+struct Base3 {
+  int x7;
+  int x8;
+};
+struct Base2 : Base3 {
+  int x5;
+  int x6;
+};
+struct Base {
+  int x3;
+  int x4;
+};
+struct Foo : public Base, Base2 {
+  int x1;
+  int x2;
+};
+
+void target() {
+  Foo F;
+  F.x4 = F.x2;
+  F.x6 = 1;
+  F.x8 = 1;
+  // [[p]]
+}
+  )";
+  runDataflow(
+  Code,
+  [](const llvm::StringMap> &Results,
+ ASTContext &ASTCtx) {
+const Environment &Env =
+  getEnvironmentAtAnnotation(Results, "p");
+
+const ValueDecl *FooDecl = findValueDecl(ASTCtx, "F");
+const ValueDecl *X1Decl = findValueDecl(ASTCtx, "x1");
+const ValueDecl *X2Decl = findValueDecl(ASTCtx, "x2");
+const ValueDecl *X3Decl = findValueDecl(ASTCtx, "x3");
+const ValueDecl *X4Decl = findValueDecl(ASTCtx, "x4");
+const ValueDecl *X5Decl = findValueDecl(ASTCtx, "x5");
+const ValueDecl *X6Decl = findValueDecl(ASTCtx, "x6");
+const ValueDecl *X7Decl = findValueDecl(ASTCtx, "x7");
+const ValueDecl *X8Decl = findValueDecl(ASTCtx, "x8");
+ASSERT_THAT(FooDecl, NotNull());
+
+// Only "x2", "x4", "x6", and "x8" are accessed and exist in the model.
+const auto *FooLoc =
+cast(Env.getStorageLocation(*FooDecl));
+llvm::DenseSet Fields;
+for (auto [Field, _] : FooLoc->children()) {
+  Fields.insert(Field);
+}
+ASSERT_EQ(Fields.size(), 4);
+ASSERT_TRUE(Fields.contains(X2Decl));
+ASSERT_TRUE(Fields.contains(X4Decl));
+ASSERT_TRUE(Fields.contains(X6Decl));
+ASSERT_TRUE(Fields.contains(X8Decl));
+
+// "x1", "x3", "x5", "x7" are not used therefore are filtered out.
+ASSERT_FALSE(Fields.contains(X1Decl));
+ASSERT_FALSE(Fields.contains(X3Decl));
+ASSERT_FALSE(Fields.contains(X5Decl));
+ASSERT_FALSE(Fields.contains(X7Decl));
+  });
+}
+
+TEST(TransferTest, StructInitializerListWithComplicatedInheritance) {
+  std::string Code = R"(
+struct Base3 {
+  int x7;
+  int x8;
+};
+struct Base2 : Base3 {
+  int x5;
+  int x6;
+};
+struct Base {
+  int x3;
+  int x4;
+};
+struct Foo : public Base, Base2 {
+  int x1;
+  int x2;
+};
+
+void target() {
+  Foo F = {};
+  F.x4 = F.x2;
+  F.x6 = 1;
+  F.x8 = 1;
+  // [[p]]
+}
+  )";
+  runDataflow(
+  Code,
+  [](const llvm::StringMap> &Results,
+ ASTContext &ASTCtx) {
+const Environment &Env =
+  getEnvironmentAtAnnotation(Results, "p");
+
+const ValueDecl *FooDecl = findValueDecl(ASTCtx, "F");
+const ValueDecl *X1Decl = findValueDecl(ASTCtx, "x1");
+const ValueDecl *X2Decl = findValueDecl(ASTCtx, "x2");
+const ValueDecl *X3Decl = findValueDecl(ASTCtx, "x3");
+const ValueDecl *X4

[PATCH] D159284: [clang][dataflow] Fix Record initialization with InitListExpr and inheritances

2023-08-31 Thread Kinuko Yasuda via Phabricator via cfe-commits
kinu added inline comments.



Comment at: clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp:131
+// initialized with InitListExpr.
 assert(&RecordVal1->getLoc() == &RecordVal2->getLoc());
 

Note, this hits regardless of my change, but not very often.  I haven't looked 
into details yet


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159284

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


[PATCH] D159138: [clang][Sema] Fix format size estimator's handling of %o, %x, %X with alternative form

2023-08-31 Thread Takuya Shimizu via Phabricator via cfe-commits
hazohelet updated this revision to Diff 555043.
hazohelet marked an inline comment as done.
hazohelet added a comment.

Added `%X` and `%o` tests, which are also affected


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

https://reviews.llvm.org/D159138

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Sema/SemaChecking.cpp
  clang/test/Sema/warn-fortify-source.c

Index: clang/test/Sema/warn-fortify-source.c
===
--- clang/test/Sema/warn-fortify-source.c
+++ clang/test/Sema/warn-fortify-source.c
@@ -85,7 +85,7 @@
   __builtin_memset(buf, 0xff, 11); // expected-warning {{'memset' will always overflow; destination buffer has size 10, but size argument is 11}}
 }
 
-void call_snprintf(double d) {
+void call_snprintf(double d, int n) {
   char buf[10];
   __builtin_snprintf(buf, 10, "merp");
   __builtin_snprintf(buf, 11, "merp"); // expected-warning {{'snprintf' size argument is too large; destination buffer has size 10, but size argument is 11}}
@@ -96,6 +96,13 @@
   __builtin_snprintf(buf, 1, "%.1000g", d); // expected-warning {{'snprintf' will always be truncated; specified size is 1, but format string expands to at least 2}}
   __builtin_snprintf(buf, 5, "%.1000g", d);
   __builtin_snprintf(buf, 5, "%.1000G", d);
+  __builtin_snprintf(buf, 10, " %#08x", n);
+  __builtin_snprintf(buf, 2, "%#x", n);
+  __builtin_snprintf(buf, 2, "%#X", n);
+  __builtin_snprintf(buf, 2, "%#o", n);
+  __builtin_snprintf(buf, 1, "%#x", n); // expected-warning {{'snprintf' will always be truncated; specified size is 1, but format string expands to at least 2}}
+  __builtin_snprintf(buf, 1, "%#X", n); // expected-warning {{'snprintf' will always be truncated; specified size is 1, but format string expands to at least 2}}
+  __builtin_snprintf(buf, 1, "%#o", n); // expected-warning {{'snprintf' will always be truncated; specified size is 1, but format string expands to at least 2}}
 }
 
 void call_vsnprintf(void) {
@@ -110,6 +117,13 @@
   __builtin_vsnprintf(buf, 1, "%.1000g", list); // expected-warning {{'vsnprintf' will always be truncated; specified size is 1, but format string expands to at least 2}}
   __builtin_vsnprintf(buf, 5, "%.1000g", list);
   __builtin_vsnprintf(buf, 5, "%.1000G", list);
+  __builtin_vsnprintf(buf, 10, " %#08x", list);
+  __builtin_vsnprintf(buf, 2, "%#x", list);
+  __builtin_vsnprintf(buf, 2, "%#X", list);
+  __builtin_vsnprintf(buf, 2, "%#o", list);
+  __builtin_vsnprintf(buf, 1, "%#x", list); // expected-warning {{'vsnprintf' will always be truncated; specified size is 1, but format string expands to at least 2}}
+  __builtin_vsnprintf(buf, 1, "%#X", list); // expected-warning {{'vsnprintf' will always be truncated; specified size is 1, but format string expands to at least 2}}
+  __builtin_vsnprintf(buf, 1, "%#o", list); // expected-warning {{'vsnprintf' will always be truncated; specified size is 1, but format string expands to at least 2}}
 }
 
 void call_sprintf_chk(char *buf) {
@@ -147,7 +161,7 @@
   __builtin___sprintf_chk(buf, 1, 2, "%%");
   __builtin___sprintf_chk(buf, 1, 1, "%%"); // expected-warning {{'sprintf' will always overflow; destination buffer has size 1, but format string expands to at least 2}}
   __builtin___sprintf_chk(buf, 1, 4, "%#x", 9);
-  __builtin___sprintf_chk(buf, 1, 3, "%#x", 9); // expected-warning {{'sprintf' will always overflow; destination buffer has size 3, but format string expands to at least 4}}
+  __builtin___sprintf_chk(buf, 1, 3, "%#x", 9);
   __builtin___sprintf_chk(buf, 1, 4, "%p", (void *)9);
   __builtin___sprintf_chk(buf, 1, 3, "%p", (void *)9); // expected-warning {{'sprintf' will always overflow; destination buffer has size 3, but format string expands to at least 4}}
   __builtin___sprintf_chk(buf, 1, 3, "%+d", 9);
@@ -184,7 +198,7 @@
   sprintf(buf, "1234%lld", 9ll);
   sprintf(buf, "12345%lld", 9ll); // expected-warning {{'sprintf' will always overflow; destination buffer has size 6, but format string expands to at least 7}}
   sprintf(buf, "12%#x", 9);
-  sprintf(buf, "123%#x", 9); // expected-warning {{'sprintf' will always overflow; destination buffer has size 6, but format string expands to at least 7}}
+  sprintf(buf, "123%#x", 9);
   sprintf(buf, "12%p", (void *)9);
   sprintf(buf, "123%p", (void *)9); // expected-warning {{'sprintf' will always overflow; destination buffer has size 6, but format string expands to at least 7}}
   sprintf(buf, "123%+d", 9);
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -890,6 +890,8 @@
 // %g style conversion switches between %f or %e style dynamically.
 // %g removes trailing zeros, and does not print decimal point if there are
 // no digits that follow it. Thus %g can print a single digit.
+// FIXME: If it is alternative form:
+// For g and G conversions, trailing zeros 

[PATCH] D159206: [Clang] Propagate target-features if compatible when using mlink-builtin-bitcode

2023-08-31 Thread Juan Manuel Martinez Caamaño via Phabricator via cfe-commits
jmmartinez updated this revision to Diff 555051.
jmmartinez added a comment.

- Rebased


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159206

Files:
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/link-builtin-bitcode.c
  clang/test/CodeGenCUDA/link-builtin-bitcode-gpu-attrs-preserved.cu

Index: clang/test/CodeGenCUDA/link-builtin-bitcode-gpu-attrs-preserved.cu
===
--- clang/test/CodeGenCUDA/link-builtin-bitcode-gpu-attrs-preserved.cu
+++ clang/test/CodeGenCUDA/link-builtin-bitcode-gpu-attrs-preserved.cu
@@ -31,7 +31,7 @@
 
 
 // CHECK: define {{.*}} i64 @do_intrin_stuff() #[[ATTR:[0-9]+]]
-// INTERNALIZE: attributes #[[ATTR]] = {{.*}} "target-cpu"="gfx{{.*}}" "target-features"="+gfx11-insts"
+// INTERNALIZE: attributes #[[ATTR]] = {{.*}} "target-cpu"="gfx{{.*}}" "target-features"="{{.*}}+gfx11-insts{{.*}}"
 // NOINTERNALIZE: attributes #[[ATTR]] = {{.*}} "target-features"="+gfx11-insts"
 
 #define __device__ __attribute__((device))
Index: clang/test/CodeGen/link-builtin-bitcode.c
===
--- clang/test/CodeGen/link-builtin-bitcode.c
+++ clang/test/CodeGen/link-builtin-bitcode.c
@@ -1,42 +1,50 @@
-// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --check-attributes --check-globals --include-generated-funcs --version 2
+// Build two version of the bitcode library, one with a target-cpu set and one without
 // RUN: %clang_cc1 -triple amdgcn-- -target-cpu gfx803 -DBITCODE -emit-llvm-bc -o %t-lib.bc %s
+// RUN: %clang_cc1 -triple amdgcn-- -DBITCODE -emit-llvm-bc -o %t-lib.no-cpu.bc %s
+
+// RUN: %clang_cc1 -triple amdgcn-- -target-cpu gfx90a -emit-llvm-bc -o %t.bc %s
+// RUN: %clang_cc1 -triple amdgcn-- -target-cpu gfx90a -emit-llvm \
+// RUN:   -mlink-builtin-bitcode %t-lib.bc -o - %t.bc | FileCheck %s --check-prefixes=CHECK,CPU
+
 // RUN: %clang_cc1 -triple amdgcn-- -target-cpu gfx90a -emit-llvm-bc -o %t.bc %s
 // RUN: %clang_cc1 -triple amdgcn-- -target-cpu gfx90a -emit-llvm \
-// RUN:   -mlink-builtin-bitcode %t-lib.bc -o - %t.bc | FileCheck %s
+// RUN:   -mlink-builtin-bitcode %t-lib.no-cpu.bc -o - %t.bc | FileCheck %s --check-prefixes=CHECK,NOCPU
 
 #ifdef BITCODE
-int foo(void) { return 42; }
+int no_attr(void) { return 42; }
+int __attribute__((target("gfx8-insts"))) attr_in_target(void) { return 42; }
+int __attribute__((target("extended-image-insts"))) attr_not_in_target(void) { return 42; }
+int __attribute__((target("no-gfx9-insts"))) attr_incompatible(void) { return 42; }
 int x = 12;
 #endif
 
-extern int foo(void);
+extern int no_attr(void);
+extern int attr_in_target(void);
+extern int attr_not_in_target(void);
+extern int attr_incompatible(void);
 extern int x;
 
-int bar() { return foo() + x; }
-//.
+int bar() { return no_attr() + attr_in_target() + attr_not_in_target() + attr_incompatible() + x; }
+
 // CHECK: @x = internal addrspace(1) global i32 12, align 4
-//.
-// CHECK: Function Attrs: noinline nounwind optnone
+
 // CHECK-LABEL: define dso_local i32 @bar
-// CHECK-SAME: () #[[ATTR0:[0-9]+]] {
-// CHECK-NEXT:  entry:
-// CHECK-NEXT:[[RETVAL:%.*]] = alloca i32, align 4, addrspace(5)
-// CHECK-NEXT:[[RETVAL_ASCAST:%.*]] = addrspacecast ptr addrspace(5) [[RETVAL]] to ptr
-// CHECK-NEXT:[[CALL:%.*]] = call i32 @foo()
-// CHECK-NEXT:[[TMP0:%.*]] = load i32, ptr addrspacecast (ptr addrspace(1) @x to ptr), align 4
-// CHECK-NEXT:[[ADD:%.*]] = add nsw i32 [[CALL]], [[TMP0]]
-// CHECK-NEXT:ret i32 [[ADD]]
+// CHECK-SAME: () #[[ATTR_BAR:[0-9]+]] {
 //
-//
-// CHECK: Function Attrs: convergent noinline nounwind optnone
-// CHECK-LABEL: define internal i32 @foo
-// CHECK-SAME: () #[[ATTR1:[0-9]+]] {
-// CHECK-NEXT:  entry:
-// CHECK-NEXT:[[RETVAL:%.*]] = alloca i32, align 4, addrspace(5)
-// CHECK-NEXT:[[RETVAL_ASCAST:%.*]] = addrspacecast ptr addrspace(5) [[RETVAL]] to ptr
-// CHECK-NEXT:ret i32 42
-//
-//.
-// CHECK: attributes #0 = { noinline nounwind optnone "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="gfx90a" "target-features"="+16-bit-insts,+atomic-buffer-global-pk-add-f16-insts,+atomic-fadd-rtn-insts,+ci-insts,+dl-insts,+dot1-insts,+dot10-insts,+dot2-insts,+dot3-insts,+dot4-insts,+dot5-insts,+dot6-insts,+dot7-insts,+dpp,+gfx8-insts,+gfx9-insts,+gfx90a-insts,+mai-insts,+s-memrealtime,+s-memtime-inst,+wavefrontsize64" }
-// CHECK: attributes #1 = { convergent noinline nounwind optnone "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="gfx90a" "target-features"="+16-bit-insts,+ci-insts,+dpp,+gfx8-insts,+s-memrealtime,+s-memtime-inst,+wavefrontsize64" }
-//.
+// CHECK-LABEL: define internal i32 @no_attr
+// CHECK-SAME: () #[[ATTR_COMPATIBLE:[0-9]+]] {
+
+// CHECK-LABEL: define internal i32 @attr_in_target
+// CHECK-SAME: () #[[ATTR_COMPATIBLE:[0-9]+]] {
+
+// 

[PATCH] D159105: [analyzer] ArrayBoundCheckerV2 should check the region for taint as well

2023-08-31 Thread Balázs Benics via Phabricator via cfe-commits
steakhal added a comment.

There are still a few FPs of the kind, where they iterate over the result of 
`getenv` in a loop, and continuously checks the character against the zero 
terminator.
I refined the suppression heuristic as follows:

- If the offset is zero, don't report taint issue. (as I suggested in the 
previous heuristic)
- If the offset is non-zero, calculate the offset for the previous element and 
check if the value there is proven to be non-zero. If it cannot be zero, don't 
report this taint issue.

I'll check the results tomorrow.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159105

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


[PATCH] D159263: [clang-tidy] misc-include-cleaner: remove duplicated includes & fixes

2023-08-31 Thread Ding Fei via Phabricator via cfe-commits
danix800 added inline comments.



Comment at: clang-tools-extra/clang-tidy/misc/IncludeCleanerCheck.cpp:227
+  << Inc.SymRef.Target.name();
+  if (!AlreadyInserted.contains(Inc.Missing.resolvedPath())) {
+DB << FixItHint::CreateInsertion(

sammccall wrote:
> This means that if you're looking at individual diagnostics rather than 
> applying all fixes to a file, only the first diagnostic will have any fix 
> available at all.
> 
> I believe the preferred solution is to do this conditionally based on 
> areDiagsSelfContained(). `clang_tidy::utils::IncludeInserter` encapsulates 
> this, but isn't used here.
> 
> I don't know whether we would want to use it here, or how carefully it's 
> already been considered. (It definitely contains a lot of logic that is 
> dubious to apply when the include to insert has already been precisely 
> calculated, but also some things that would be helpful). Will defer to Kadir 
> on that.
Thanks for mentioning the `clang_tidy::utils::IncludeInserter`. I took a 
further look and found that `IncludeInserter` is
more suitable for this checker.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159263

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


[PATCH] D159263: [clang-tidy] misc-include-cleaner: remove duplicated includes & fixes

2023-08-31 Thread Ding Fei via Phabricator via cfe-commits
danix800 added inline comments.



Comment at: clang-tools-extra/clang-tidy/misc/IncludeCleanerCheck.cpp:169
+  else
+Unused.push_back(&I);
+  continue;

sammccall wrote:
> If we want this policy, it should be provided at the include-cleaner library 
> level so it applies to all clients, not just the clang-tidy check.
> 
> I think the clearest way is to encapsulate this in include_cleaner::Includes, 
> so that match() never matches a Header requirement against a duplicative 
> Include. This will naturally lead to the directives being marked as unused.
> 
> (In practice, the result will work in clangd, and will respect configuration 
> of headers where analysis should be ignored, keep directives, etc)
I'll leave the policy part to another revision (maybe by others).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159263

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


[PATCH] D159138: [clang][Sema] Fix format size estimator's handling of %o, %x, %X with alternative form

2023-08-31 Thread Takuya Shimizu via Phabricator via cfe-commits
hazohelet added a comment.

In D159138#4628858 , @nickdesaulniers 
wrote:

> Mind adding tests for `%#X` and `%#o` as well, since you're changing the 
> behavior of those, too?
>
> I think it would also be good to have explicit tests for `%o` and `%b` where 
> the value being printed was and was not `0`.  IIUC, we cannot diagnose those 
> (unless a literal value is being printed)?
>
> (Thanks for finding that one of the kernel cases was a false positive!)

The current implementation only sees the format string and calculates the 
minimum possible length without taking into accout the actual value passed to 
it. So currently every case assumes that the value can be 0, even when a 
literal is passed.
Even if the printed expression is not literal, we can use something like 
`Expr::EvaluateAsRValue` to learn about the printed value.

As for the `%b`, it's C23 feature and `Wfortify-source` doesn't seem to support 
it yet (`%b` is considered a valid specifier, but does not increase `Size` 
here). I think `%b` tests should be added when we support it.


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

https://reviews.llvm.org/D159138

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


[PATCH] D159263: [clang-tidy] misc-include-cleaner: fix duplicated fixes

2023-08-31 Thread Ding Fei via Phabricator via cfe-commits
danix800 updated this revision to Diff 555059.
danix800 retitled this revision from "[clang-tidy] misc-include-cleaner: remove 
duplicated includes & fixes" to "[clang-tidy] misc-include-cleaner: fix 
duplicated fixes".
danix800 edited the summary of this revision.
danix800 added a comment.

1. Use `clang::tidy::utils::IncludeInserter` to avoid repeated insertion;
2. Leave out the deduplication policy part.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159263

Files:
  clang-tools-extra/clang-tidy/misc/IncludeCleanerCheck.cpp
  clang-tools-extra/clang-tidy/misc/IncludeCleanerCheck.h
  clang-tools-extra/test/clang-tidy/checkers/misc/Inputs/baz.h
  clang-tools-extra/test/clang-tidy/checkers/misc/include-cleaner.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/misc/include-cleaner.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/misc/include-cleaner.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/misc/include-cleaner.cpp
@@ -11,6 +11,8 @@
 int BarResult = bar();
 int BazResult = baz();
 // CHECK-MESSAGES: :[[@LINE-1]]:17: warning: no header providing "baz" is directly included [misc-include-cleaner]
+int BazResultAgain = BAZ; // Header should not be inserted more than once
+// CHECK-MESSAGES: :[[@LINE-1]]:22: warning: no header providing "BAZ" is directly included [misc-include-cleaner]
 std::string HelloString;
 // CHECK-MESSAGES: :[[@LINE-1]]:6: warning: no header providing "std::string" is directly included [misc-include-cleaner]
 int FooBarResult = foobar();
Index: clang-tools-extra/test/clang-tidy/checkers/misc/Inputs/baz.h
===
--- clang-tools-extra/test/clang-tidy/checkers/misc/Inputs/baz.h
+++ clang-tools-extra/test/clang-tidy/checkers/misc/Inputs/baz.h
@@ -1,2 +1,3 @@
 #pragma once
+#define BAZ 10
 int baz();
Index: clang-tools-extra/clang-tidy/misc/IncludeCleanerCheck.h
===
--- clang-tools-extra/clang-tidy/misc/IncludeCleanerCheck.h
+++ clang-tools-extra/clang-tidy/misc/IncludeCleanerCheck.h
@@ -12,13 +12,13 @@
 #include "../ClangTidyCheck.h"
 #include "../ClangTidyDiagnosticConsumer.h"
 #include "../ClangTidyOptions.h"
+#include "../utils/IncludeInserter.h"
 #include "clang-include-cleaner/Record.h"
 #include "clang-include-cleaner/Types.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/Basic/LLVM.h"
+#include "clang/Basic/LangOptions.h"
 #include "clang/Basic/SourceLocation.h"
-#include "clang/Lex/HeaderSearch.h"
-#include "clang/Lex/Preprocessor.h"
 #include "llvm/Support/Regex.h"
 #include 
 
@@ -47,6 +47,7 @@
   std::vector IgnoreHeaders;
   // Whether emit only one finding per usage of a symbol.
   const bool DeduplicateFindings;
+  utils::IncludeInserter IncludeInserter;
   llvm::SmallVector IgnoreHeadersRegex;
   bool shouldIgnore(const include_cleaner::Header &H);
 };
Index: clang-tools-extra/clang-tidy/misc/IncludeCleanerCheck.cpp
===
--- clang-tools-extra/clang-tidy/misc/IncludeCleanerCheck.cpp
+++ clang-tools-extra/clang-tidy/misc/IncludeCleanerCheck.cpp
@@ -10,6 +10,7 @@
 #include "../ClangTidyCheck.h"
 #include "../ClangTidyDiagnosticConsumer.h"
 #include "../ClangTidyOptions.h"
+#include "../utils/IncludeSorter.h"
 #include "../utils/OptionsUtils.h"
 #include "clang-include-cleaner/Analysis.h"
 #include "clang-include-cleaner/IncludeSpeller.h"
@@ -25,10 +26,8 @@
 #include "clang/Basic/LLVM.h"
 #include "clang/Basic/LangOptions.h"
 #include "clang/Basic/SourceLocation.h"
-#include "clang/Format/Format.h"
 #include "clang/Lex/Preprocessor.h"
 #include "clang/Tooling/Core/Replacement.h"
-#include "clang/Tooling/Inclusions/HeaderIncludes.h"
 #include "llvm/ADT/DenseSet.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SmallVector.h"
@@ -36,7 +35,6 @@
 #include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/Regex.h"
-#include 
 #include 
 #include 
 
@@ -57,7 +55,10 @@
   IgnoreHeaders(utils::options::parseStringList(
   Options.getLocalOrGlobal("IgnoreHeaders", ""))),
   DeduplicateFindings(
-  Options.getLocalOrGlobal("DeduplicateFindings", true)) {
+  Options.getLocalOrGlobal("DeduplicateFindings", true)),
+  IncludeInserter(Options.getLocalOrGlobal("IncludeStyle",
+   utils::IncludeSorter::IS_LLVM),
+  areDiagsSelfContained()) {
   for (const auto &Header : IgnoreHeaders) {
 if (!llvm::Regex{Header}.isValid())
   configurationDiag("Invalid ignore headers regex '%0'") << Header;
@@ -71,6 +72,7 @@
 void IncludeCleanerCheck::storeOptions(ClangTidyOptions::OptionMap &Opts) {
   Options.store(Opts, "IgnoreHeaders",
 utils::options::serializeStringList(Igno

[PATCH] D159138: [clang][Sema] Fix format size estimator's handling of %o, %x, %X with alternative form

2023-08-31 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers added inline comments.



Comment at: clang/test/Sema/warn-fortify-source.c:100-102
+  __builtin_snprintf(buf, 2, "%#x", n);
+  __builtin_snprintf(buf, 2, "%#X", n);
+  __builtin_snprintf(buf, 2, "%#o", n);

Note that GCC -Wformat-truncation can warn on some of these.

https://godbolt.org/z/jE3axWe1W

Looks like the diagnostic keeps an up and lower bounds on the estimated format 
string expansion.

Trunk for Clang also warns for these, so is this change a regression? Or are 
both GCC and Clang (trunk) incorrect?



Comment at: clang/test/Sema/warn-fortify-source.c:121-123
+  __builtin_vsnprintf(buf, 2, "%#x", list);
+  __builtin_vsnprintf(buf, 2, "%#X", list);
+  __builtin_vsnprintf(buf, 2, "%#o", list);

Clang @ trunk and GCC both warn for these 3. Regression?
https://godbolt.org/z/j551hTE5E


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

https://reviews.llvm.org/D159138

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


[PATCH] D158707: [analyzer] Fix a few size-type signedness inconsistency related to DynamicExtent

2023-08-31 Thread Ding Fei via Phabricator via cfe-commits
danix800 added a comment.

Thanks for clarifying!

If no further comments I'll commit this revison in a day or two!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158707

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


[clang] b6ce860 - [Driver][VE] Change to enable VPU flag by default

2023-08-31 Thread Kazushi Marukawa via cfe-commits

Author: Kazushi (Jam) Marukawa
Date: 2023-09-01T00:41:38+09:00
New Revision: b6ce860024013397982cdd26b762df8182b14df9

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

LOG: [Driver][VE] Change to enable VPU flag by default

Change to enable VPU flag for VE by default in order to support vector
intrinsics from clang.

Reviewed By: efocht, MaskRay

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

Added: 
clang/test/Driver/ve-features.c

Modified: 
clang/include/clang/Driver/Options.td
clang/lib/Driver/ToolChains/Arch/VE.cpp

Removed: 




diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index b8b02af9f35f0c..3d73e24a4dc5af 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -199,6 +199,8 @@ def m_x86_Features_Group : OptionGroup<"">,
DocName<"X86">;
 def m_riscv_Features_Group : OptionGroup<"">,
  Group, DocName<"RISC-V">;
+def m_ve_Features_Group : OptionGroup<"">,
+  Group, DocName<"VE">;
 
 def m_libc_Group : OptionGroup<"">, Group,
Flags<[HelpHidden]>;
@@ -5845,6 +5847,13 @@ def mno_scatter : Flag<["-"], "mno-scatter">, 
Group,
   HelpText<"Disable generation of scatter instructions in 
auto-vectorization(x86 only)">;
 } // let Flags = [TargetSpecific]
 
+// VE feature flags
+let Flags = [TargetSpecific] in {
+def mvevpu : Flag<["-"], "mvevpu">, Group,
+  HelpText<"Emit VPU instructions for VE">;
+def mno_vevpu : Flag<["-"], "mno-vevpu">, Group;
+} // let Flags = [TargetSpecific]
+
 // These are legacy user-facing driver-level option spellings. They are always
 // aliases for options that are spelled using the more common Unix / GNU flag
 // style of double-dash and equals-joined flags.

diff  --git a/clang/lib/Driver/ToolChains/Arch/VE.cpp 
b/clang/lib/Driver/ToolChains/Arch/VE.cpp
index 97d74eb4e5efd0..b19760898c6477 100644
--- a/clang/lib/Driver/ToolChains/Arch/VE.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/VE.cpp
@@ -18,4 +18,9 @@ using namespace clang;
 using namespace llvm::opt;
 
 void ve::getVETargetFeatures(const Driver &D, const ArgList &Args,
- std::vector &Features) {}
+ std::vector &Features) {
+  if (Args.hasFlag(options::OPT_mvevpu, options::OPT_mno_vevpu, true))
+Features.push_back("+vpu");
+  else
+Features.push_back("-vpu");
+}

diff  --git a/clang/test/Driver/ve-features.c b/clang/test/Driver/ve-features.c
new file mode 100644
index 00..5e233b0893a3cf
--- /dev/null
+++ b/clang/test/Driver/ve-features.c
@@ -0,0 +1,5 @@
+// RUN: %clang --target=ve-unknown-linux-gnu -### %s 2>&1 | FileCheck %s 
-check-prefix=DEFAULT
+// RUN: %clang --target=ve-unknown-linux-gnu -### %s -mvevpu -mno-vevpu 2>&1 | 
FileCheck %s -check-prefix=NO-VEVPU
+
+// DEFAULT: "-target-feature" "+vpu"
+// NO-VEVPU: "-target-feature" "-vpu"



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


[PATCH] D157813: [Driver][VE] Change to enable VPU flag by default

2023-08-31 Thread Kazushi Marukawa via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGb6ce86002401: [Driver][VE] Change to enable VPU flag by 
default (authored by kaz7).

Changed prior to commit:
  https://reviews.llvm.org/D157813?vs=554742&id=555063#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D157813

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Arch/VE.cpp
  clang/test/Driver/ve-features.c


Index: clang/test/Driver/ve-features.c
===
--- /dev/null
+++ clang/test/Driver/ve-features.c
@@ -0,0 +1,5 @@
+// RUN: %clang --target=ve-unknown-linux-gnu -### %s 2>&1 | FileCheck %s 
-check-prefix=DEFAULT
+// RUN: %clang --target=ve-unknown-linux-gnu -### %s -mvevpu -mno-vevpu 2>&1 | 
FileCheck %s -check-prefix=NO-VEVPU
+
+// DEFAULT: "-target-feature" "+vpu"
+// NO-VEVPU: "-target-feature" "-vpu"
Index: clang/lib/Driver/ToolChains/Arch/VE.cpp
===
--- clang/lib/Driver/ToolChains/Arch/VE.cpp
+++ clang/lib/Driver/ToolChains/Arch/VE.cpp
@@ -18,4 +18,9 @@
 using namespace llvm::opt;
 
 void ve::getVETargetFeatures(const Driver &D, const ArgList &Args,
- std::vector &Features) {}
+ std::vector &Features) {
+  if (Args.hasFlag(options::OPT_mvevpu, options::OPT_mno_vevpu, true))
+Features.push_back("+vpu");
+  else
+Features.push_back("-vpu");
+}
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -199,6 +199,8 @@
DocName<"X86">;
 def m_riscv_Features_Group : OptionGroup<"">,
  Group, DocName<"RISC-V">;
+def m_ve_Features_Group : OptionGroup<"">,
+  Group, DocName<"VE">;
 
 def m_libc_Group : OptionGroup<"">, Group,
Flags<[HelpHidden]>;
@@ -5845,6 +5847,13 @@
   HelpText<"Disable generation of scatter instructions in 
auto-vectorization(x86 only)">;
 } // let Flags = [TargetSpecific]
 
+// VE feature flags
+let Flags = [TargetSpecific] in {
+def mvevpu : Flag<["-"], "mvevpu">, Group,
+  HelpText<"Emit VPU instructions for VE">;
+def mno_vevpu : Flag<["-"], "mno-vevpu">, Group;
+} // let Flags = [TargetSpecific]
+
 // These are legacy user-facing driver-level option spellings. They are always
 // aliases for options that are spelled using the more common Unix / GNU flag
 // style of double-dash and equals-joined flags.


Index: clang/test/Driver/ve-features.c
===
--- /dev/null
+++ clang/test/Driver/ve-features.c
@@ -0,0 +1,5 @@
+// RUN: %clang --target=ve-unknown-linux-gnu -### %s 2>&1 | FileCheck %s -check-prefix=DEFAULT
+// RUN: %clang --target=ve-unknown-linux-gnu -### %s -mvevpu -mno-vevpu 2>&1 | FileCheck %s -check-prefix=NO-VEVPU
+
+// DEFAULT: "-target-feature" "+vpu"
+// NO-VEVPU: "-target-feature" "-vpu"
Index: clang/lib/Driver/ToolChains/Arch/VE.cpp
===
--- clang/lib/Driver/ToolChains/Arch/VE.cpp
+++ clang/lib/Driver/ToolChains/Arch/VE.cpp
@@ -18,4 +18,9 @@
 using namespace llvm::opt;
 
 void ve::getVETargetFeatures(const Driver &D, const ArgList &Args,
- std::vector &Features) {}
+ std::vector &Features) {
+  if (Args.hasFlag(options::OPT_mvevpu, options::OPT_mno_vevpu, true))
+Features.push_back("+vpu");
+  else
+Features.push_back("-vpu");
+}
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -199,6 +199,8 @@
DocName<"X86">;
 def m_riscv_Features_Group : OptionGroup<"">,
  Group, DocName<"RISC-V">;
+def m_ve_Features_Group : OptionGroup<"">,
+  Group, DocName<"VE">;
 
 def m_libc_Group : OptionGroup<"">, Group,
Flags<[HelpHidden]>;
@@ -5845,6 +5847,13 @@
   HelpText<"Disable generation of scatter instructions in auto-vectorization(x86 only)">;
 } // let Flags = [TargetSpecific]
 
+// VE feature flags
+let Flags = [TargetSpecific] in {
+def mvevpu : Flag<["-"], "mvevpu">, Group,
+  HelpText<"Emit VPU instructions for VE">;
+def mno_vevpu : Flag<["-"], "mno-vevpu">, Group;
+} // let Flags = [TargetSpecific]
+
 // These are legacy user-facing driver-level option spellings. They are always
 // aliases for options that are spelled using the more common Unix / GNU flag
 // style of double-dash and equals-joined flags.
___
cfe-commits mailing list
cf

[PATCH] D158739: AIX: Issue an error when specifying an alias for a common symbol

2023-08-31 Thread Stephen Peckham 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 rG282da837565f: [XCOFF][AIX] Issue an error when specifying an 
alias for a common symbol (authored by stephenpeckham).

Changed prior to commit:
  https://reviews.llvm.org/D158739?vs=554299&id=555064#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158739

Files:
  clang/include/clang/Basic/DiagnosticFrontendKinds.td
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/CodeGen/aix-common.c
  llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp
  llvm/test/CodeGen/PowerPC/aix-common.ll

Index: llvm/test/CodeGen/PowerPC/aix-common.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/aix-common.ll
@@ -0,0 +1,15 @@
+; RUN: not llc -filetype=obj -mtriple powerpc-ibm-aix-xcoff -o %t.o < %s 2>&1 | FileCheck %s
+; RUN: not llc -filetype=asm -mtriple powerpc-ibm-aix-xcoff -o %t.o < %s 2>&1 | FileCheck %s
+; RUN: not llc -filetype=obj -mtriple powerpc64-ibm-aix-xcoff -o %t.o < %s 2>&1 | FileCheck %s
+; RUN: not llc -filetype=asm -mtriple powerpc64-ibm-aix-xcoff -o %t.o < %s 2>&1 | FileCheck %s
+@x= common global i32 0, align 4
+
+@y= alias i32, ptr @x
+
+; Function Attrs: noinline nounwind optnone
+define ptr @g() #0 {
+entry:
+  ret ptr @y
+}
+; CHECK: LLVM ERROR: Aliases to common variables are not allowed on AIX:
+; CHECK-NEXT:Alias attribute for y is invalid because x is common.
Index: llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp
===
--- llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp
+++ llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp
@@ -2762,11 +2762,21 @@
 
   // Construct an aliasing list for each GlobalObject.
   for (const auto &Alias : M.aliases()) {
-const GlobalObject *Base = Alias.getAliaseeObject();
-if (!Base)
+const GlobalObject *Aliasee = Alias.getAliaseeObject();
+if (!Aliasee)
   report_fatal_error(
   "alias without a base object is not yet supported on AIX");
-GOAliasMap[Base].push_back(&Alias);
+
+if (Aliasee->hasCommonLinkage()) {
+  report_fatal_error("Aliases to common variables are not allowed on AIX:"
+ "\n\tAlias attribute for " +
+ Alias.getGlobalIdentifier() +
+ " is invalid because " + Aliasee->getName() +
+ " is common.",
+ false);
+}
+
+GOAliasMap[Aliasee].push_back(&Alias);
   }
 
   return Result;
Index: clang/test/CodeGen/aix-common.c
===
--- /dev/null
+++ clang/test/CodeGen/aix-common.c
@@ -0,0 +1,6 @@
+// RUN: %clang_cc1 -triple powerpc-ibm-aix   -S -fcommon %s -verify -o -
+// RUN: %clang_cc1 -triple powerpc64-ibm-aix -S -fcommon %s -verify -o -
+int xx;
+extern int yy __attribute__((__alias__("xx") )); //expected-error {{alias to a variable in a common section is not allowed}}
+
+void *gg() { return &yy; }
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -563,8 +563,8 @@
 }
 
 static bool checkAliasedGlobal(
-DiagnosticsEngine &Diags, SourceLocation Location, bool IsIFunc,
-const llvm::GlobalValue *Alias, const llvm::GlobalValue *&GV,
+const ASTContext &Context, DiagnosticsEngine &Diags, SourceLocation Location,
+bool IsIFunc, const llvm::GlobalValue *Alias, const llvm::GlobalValue *&GV,
 const llvm::MapVector &MangledDeclNames,
 SourceRange AliasRange) {
   GV = getAliasedGlobal(Alias);
@@ -573,6 +573,14 @@
 return false;
   }
 
+  if (GV->hasCommonLinkage()) {
+const llvm::Triple &Triple = Context.getTargetInfo().getTriple();
+if (Triple.getObjectFormat() == llvm::Triple::XCOFF) {
+  Diags.Report(Location, diag::err_alias_to_common);
+  return false;
+}
+  }
+
   if (GV->isDeclaration()) {
 Diags.Report(Location, diag::err_alias_to_undefined) << IsIFunc << IsIFunc;
 Diags.Report(Location, diag::note_alias_requires_mangled_name)
@@ -633,7 +641,7 @@
 StringRef MangledName = getMangledName(GD);
 llvm::GlobalValue *Alias = GetGlobalValue(MangledName);
 const llvm::GlobalValue *GV = nullptr;
-if (!checkAliasedGlobal(Diags, Location, IsIFunc, Alias, GV,
+if (!checkAliasedGlobal(getContext(), Diags, Location, IsIFunc, Alias, GV,
 MangledDeclNames, Range)) {
   Error = true;
   continue;
Index: clang/include/clang/Basic/DiagnosticFrontendKinds.td
===
--- clang/include/clang/Basic/DiagnosticFrontendKinds.td
+++ clang/include/clang/Basic/DiagnosticFrontendKinds.td
@@ -283,6

[clang] 282da83 - [XCOFF][AIX] Issue an error when specifying an alias for a common symbol

2023-08-31 Thread Stephen Peckham via cfe-commits

Author: Stephen Peckham
Date: 2023-08-31T11:43:47-04:00
New Revision: 282da837565fcf8598a81b5f3b34bc25705917d3

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

LOG: [XCOFF][AIX] Issue an error when specifying an alias for a common symbol

Summary:

There is no support in XCOFF for labels on common symbols. Therefore, an alias 
for a common symbol is not supported. Issue an error in the front end when an 
aliasee is a common symbol. Issue a similar error in the back end in case an IR 
specifies an alias for a common symbol.

Reviewed by: hubert.reinterpretcast, DiggerLin

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

Added: 
clang/test/CodeGen/aix-common.c
llvm/test/CodeGen/PowerPC/aix-common.ll

Modified: 
clang/include/clang/Basic/DiagnosticFrontendKinds.td
clang/lib/CodeGen/CodeGenModule.cpp
llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticFrontendKinds.td 
b/clang/include/clang/Basic/DiagnosticFrontendKinds.td
index 9ed9a88fa3d62d..c950a2d95f641d 100644
--- a/clang/include/clang/Basic/DiagnosticFrontendKinds.td
+++ b/clang/include/clang/Basic/DiagnosticFrontendKinds.td
@@ -283,6 +283,8 @@ def err_avx_calling_convention : 
Error;
 def err_alias_to_undefined : Error<
   "%select{alias|ifunc}0 must point to a defined "
   "%select{variable or |}1function">;
+def err_alias_to_common : Error<
+  "alias to a variable in a common section is not allowed">;
 def note_alias_requires_mangled_name : Note<
   "the %select{function or variable|function}0 specified in an 
%select{alias|ifunc}1 must refer to its mangled name">;
 def note_alias_mangled_name_alternative: Note<

diff  --git a/clang/lib/CodeGen/CodeGenModule.cpp 
b/clang/lib/CodeGen/CodeGenModule.cpp
index f27fc019ccc53e..07bce12d7e6689 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -563,8 +563,8 @@ static const llvm::GlobalValue *getAliasedGlobal(const 
llvm::GlobalValue *GV) {
 }
 
 static bool checkAliasedGlobal(
-DiagnosticsEngine &Diags, SourceLocation Location, bool IsIFunc,
-const llvm::GlobalValue *Alias, const llvm::GlobalValue *&GV,
+const ASTContext &Context, DiagnosticsEngine &Diags, SourceLocation 
Location,
+bool IsIFunc, const llvm::GlobalValue *Alias, const llvm::GlobalValue *&GV,
 const llvm::MapVector &MangledDeclNames,
 SourceRange AliasRange) {
   GV = getAliasedGlobal(Alias);
@@ -573,6 +573,14 @@ static bool checkAliasedGlobal(
 return false;
   }
 
+  if (GV->hasCommonLinkage()) {
+const llvm::Triple &Triple = Context.getTargetInfo().getTriple();
+if (Triple.getObjectFormat() == llvm::Triple::XCOFF) {
+  Diags.Report(Location, diag::err_alias_to_common);
+  return false;
+}
+  }
+
   if (GV->isDeclaration()) {
 Diags.Report(Location, diag::err_alias_to_undefined) << IsIFunc << IsIFunc;
 Diags.Report(Location, diag::note_alias_requires_mangled_name)
@@ -633,7 +641,7 @@ void CodeGenModule::checkAliases() {
 StringRef MangledName = getMangledName(GD);
 llvm::GlobalValue *Alias = GetGlobalValue(MangledName);
 const llvm::GlobalValue *GV = nullptr;
-if (!checkAliasedGlobal(Diags, Location, IsIFunc, Alias, GV,
+if (!checkAliasedGlobal(getContext(), Diags, Location, IsIFunc, Alias, GV,
 MangledDeclNames, Range)) {
   Error = true;
   continue;

diff  --git a/clang/test/CodeGen/aix-common.c b/clang/test/CodeGen/aix-common.c
new file mode 100644
index 00..c18eb8f30623f5
--- /dev/null
+++ b/clang/test/CodeGen/aix-common.c
@@ -0,0 +1,6 @@
+// RUN: %clang_cc1 -triple powerpc-ibm-aix   -S -fcommon %s -verify -o -
+// RUN: %clang_cc1 -triple powerpc64-ibm-aix -S -fcommon %s -verify -o -
+int xx;
+extern int yy __attribute__((__alias__("xx") )); //expected-error 
{{alias to a variable in a common section is not allowed}}
+
+void *gg() { return &yy; }

diff  --git a/llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp 
b/llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp
index 377bd7af9f191e..1ecccdebe036f0 100644
--- a/llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp
+++ b/llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp
@@ -2762,11 +2762,21 @@ bool PPCAIXAsmPrinter::doInitialization(Module &M) {
 
   // Construct an aliasing list for each GlobalObject.
   for (const auto &Alias : M.aliases()) {
-const GlobalObject *Base = Alias.getAliaseeObject();
-if (!Base)
+const GlobalObject *Aliasee = Alias.getAliaseeObject();
+if (!Aliasee)
   report_fatal_error(
   "alias without a base object is not yet supported on AIX");
-GOAliasMap[Base].push_back(&Alias);
+
+if (Aliasee->hasCommonLinkage()) {
+  report_fatal_error("Aliases to common variables are not

[PATCH] D106339: Add support to generate Sphinx DOCX documentation

2023-08-31 Thread Louis Dionne via Phabricator via cfe-commits
ldionne commandeered this revision.
ldionne added a reviewer: t-tye.
ldionne added a comment.
Herald added a subscriber: jplehr.
Herald added a project: All.

[GitHub PR transition cleanup]

This has been open for 2 years with multiple subscribers able to see this 
discussion, but there doesn't seem to be a lot of interest for moving forward 
with this. I will commandeer and abandon to clear the review queue in the 
context of moving to Github PRs. If you'd still like to push for this to 
happen, feel free to re-open this as a Github PR.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106339

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


[PATCH] D156320: [Flang][Driver] Add support for Rpass and related options

2023-08-31 Thread victorkingi via Phabricator via cfe-commits
victorkingi abandoned this revision.
victorkingi added a comment.

Replaced by a series of patches already merged on github, starting from 
https://reviews.llvm.org/D157410


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D156320

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


[libunwind] ba55034 - [libunwind][NFC] Fix whitespace in comments

2023-08-31 Thread Louis Dionne via cfe-commits

Author: Louis Dionne
Date: 2023-08-31T11:55:10-04:00
New Revision: ba55034a898baf728f4d78ec811664b2a154bbfe

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

LOG: [libunwind][NFC] Fix whitespace in comments

Added: 


Modified: 
libunwind/include/mach-o/compact_unwind_encoding.h

Removed: 




diff  --git a/libunwind/include/mach-o/compact_unwind_encoding.h 
b/libunwind/include/mach-o/compact_unwind_encoding.h
index 2dd857e45b496f..76a9478ac93d2b 100644
--- a/libunwind/include/mach-o/compact_unwind_encoding.h
+++ b/libunwind/include/mach-o/compact_unwind_encoding.h
@@ -108,7 +108,7 @@ enum {
 //are encoded in the UNWIND_X86_EBP_FRAME_REGISTERS bits as five 3-bit 
entries.
 //Each entry contains which register to restore.
 // UNWIND_X86_MODE_STACK_IMMD:
-//A "frameless" (EBP not used as frame pointer) function with a small 
+//A "frameless" (EBP not used as frame pointer) function with a small
 //constant stack size.  To return, a constant (encoded in the compact
 //unwind encoding) is added to the ESP. Then the return is done by
 //popping the stack into the pc.
@@ -119,16 +119,16 @@ enum {
 //UNWIND_X86_FRAMELESS_STACK_REG_PERMUTATION contains which registers were
 //saved and their order.
 // UNWIND_X86_MODE_STACK_IND:
-//A "frameless" (EBP not used as frame pointer) function large constant 
+//A "frameless" (EBP not used as frame pointer) function large constant
 //stack size.  This case is like the previous, except the stack size is too
-//large to encode in the compact unwind encoding.  Instead it requires 
that 
-//the function contains "subl $,ESP" in its prolog.  The compact 
+//large to encode in the compact unwind encoding.  Instead it requires that
+//the function contains "subl $,ESP" in its prolog.  The compact
 //encoding contains the offset to the  value in the function in
-//UNWIND_X86_FRAMELESS_STACK_SIZE.  
+//UNWIND_X86_FRAMELESS_STACK_SIZE.
 // UNWIND_X86_MODE_DWARF:
 //No compact unwind encoding is available.  Instead the low 24-bits of the
 //compact encoding is the offset of the DWARF FDE in the __eh_frame 
section.
-//This mode is never used in object files.  It is only generated by the 
+//This mode is never used in object files.  It is only generated by the
 //linker in final linked images which have only DWARF unwind info for a
 //function.
 //
@@ -233,36 +233,36 @@ enum {
 // For x86_64 there are four modes for the compact unwind encoding:
 // UNWIND_X86_64_MODE_RBP_FRAME:
 //RBP based frame where RBP is push on stack immediately after return 
address,
-//then RSP is moved to RBP. Thus, to unwind RSP is restored with the 
current 
-//EPB value, then RBP is restored by popping off the stack, and the return 
+//then RSP is moved to RBP. Thus, to unwind RSP is restored with the 
current
+//EPB value, then RBP is restored by popping off the stack, and the return
 //is done by popping the stack once more into the pc.
 //All non-volatile registers that need to be restored must have been saved
-//in a small range in the stack that starts RBP-8 to RBP-2040.  The 
offset/8 
+//in a small range in the stack that starts RBP-8 to RBP-2040.  The 
offset/8
 //is encoded in the UNWIND_X86_64_RBP_FRAME_OFFSET bits.  The registers 
saved
 //are encoded in the UNWIND_X86_64_RBP_FRAME_REGISTERS bits as five 3-bit 
entries.
-//Each entry contains which register to restore.  
+//Each entry contains which register to restore.
 // UNWIND_X86_64_MODE_STACK_IMMD:
-//A "frameless" (RBP not used as frame pointer) function with a small 
-//constant stack size.  To return, a constant (encoded in the compact 
-//unwind encoding) is added to the RSP. Then the return is done by 
+//A "frameless" (RBP not used as frame pointer) function with a small
+//constant stack size.  To return, a constant (encoded in the compact
+//unwind encoding) is added to the RSP. Then the return is done by
 //popping the stack into the pc.
 //All non-volatile registers that need to be restored must have been saved
 //on the stack immediately after the return address.  The stack_size/8 is
 //encoded in the UNWIND_X86_64_FRAMELESS_STACK_SIZE (max stack size is 
2048).
 //The number of registers saved is encoded in 
UNWIND_X86_64_FRAMELESS_STACK_REG_COUNT.
 //UNWIND_X86_64_FRAMELESS_STACK_REG_PERMUTATION contains which registers 
were
-//saved and their order.  
+//saved and their order.
 // UNWIND_X86_64_MODE_STACK_IND:
-//A "frameless" (RBP not used as frame pointer) function large constant 
+//A "frameless" (RBP not used as frame pointer) function large constant
 //  

[libunwind] b397921 - [runtimes] Fix some duplicate word typos

2023-08-31 Thread Louis Dionne via cfe-commits

Author: Louis Dionne
Date: 2023-08-31T11:55:10-04:00
New Revision: b397921fc7ef4e2882b3ae9c5f12fb40daca4078

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

LOG: [runtimes] Fix some duplicate word typos

Those fixes were taken from https://reviews.llvm.org/D137338.

Added: 


Modified: 
libcxx/include/__format/buffer.h
libcxx/test/std/time/time.syn/formatter.duration.pass.cpp
libcxxabi/src/private_typeinfo.cpp
libunwind/include/mach-o/compact_unwind_encoding.h
libunwind/src/FrameHeaderCache.hpp
libunwind/src/UnwindRegistersRestore.S

Removed: 




diff  --git a/libcxx/include/__format/buffer.h 
b/libcxx/include/__format/buffer.h
index 45f9da801722cca..c0502971ce127ad 100644
--- a/libcxx/include/__format/buffer.h
+++ b/libcxx/include/__format/buffer.h
@@ -95,7 +95,7 @@ class _LIBCPP_TEMPLATE_VIS __output_buffer {
   _LIBCPP_HIDE_FROM_ABI void __copy(basic_string_view<_InCharT> __str) {
 // When the underlying iterator is a simple iterator the __capacity_ is
 // infinite. For a string or container back_inserter it isn't. This means
-// adding a large string the the buffer can cause some overhead. In that
+// that adding a large string to the buffer can cause some overhead. In 
that
 // case a better approach could be:
 // - flush the buffer
 // - container.append(__str.begin(), __str.end());

diff  --git a/libcxx/test/std/time/time.syn/formatter.duration.pass.cpp 
b/libcxx/test/std/time/time.syn/formatter.duration.pass.cpp
index 9367055fb9694cb..dbf373a19ba806b 100644
--- a/libcxx/test/std/time/time.syn/formatter.duration.pass.cpp
+++ b/libcxx/test/std/time/time.syn/formatter.duration.pass.cpp
@@ -1176,7 +1176,7 @@ static void test() {
   check_exception("End of input while parsing the modifier E", SV("{:%E"), 
0ms);
   check_exception("End of input while parsing the modifier O", SV("{:%O"), 
0ms);
 
-  // Make sure the the required values work, based on their minimum number of 
required bits per [time.syn].
+  // Make sure the required values work, based on their minimum number of 
required bits per [time.syn].
   check(SV("23:47:16.854775807"),
 SV("{:%T}"),
 std::chrono::nanoseconds{0x7fff'''ll}); // 64 bit signed 
value max

diff  --git a/libcxxabi/src/private_typeinfo.cpp 
b/libcxxabi/src/private_typeinfo.cpp
index 83d1f9f130a3915..c737d96f418d8a8 100644
--- a/libcxxabi/src/private_typeinfo.cpp
+++ b/libcxxabi/src/private_typeinfo.cpp
@@ -1075,7 +1075,7 @@ 
__vmi_class_type_info::search_below_dst(__dynamic_cast_info* info,
 if (info->search_done)
 break;
 // If we just found a dst_type with a public path to 
(static_ptr, static_type),
-//then the only reason to continue the search is to 
make sure sure
+//then the only reason to continue the search is to 
make sure
 //no other dst_type points to (static_ptr, 
static_type).
 //If !diamond, then we don't need to search here.
 // if we just found a dst_type with a private path to 
(static_ptr, static_type),

diff  --git a/libunwind/include/mach-o/compact_unwind_encoding.h 
b/libunwind/include/mach-o/compact_unwind_encoding.h
index 76a9478ac93d2b0..4c48e33c3c177d9 100644
--- a/libunwind/include/mach-o/compact_unwind_encoding.h
+++ b/libunwind/include/mach-o/compact_unwind_encoding.h
@@ -372,7 +372,7 @@ enum {
 // .quadexcept_tab1
 //
 //
-// Notes: There is no need for any labels in the the __compact_unwind section.
+// Notes: There is no need for any labels in the __compact_unwind section.
 //The use of the .set directive is to force the evaluation of the
 //range-length at assembly time, instead of generating relocations.
 //

diff  --git a/libunwind/src/FrameHeaderCache.hpp 
b/libunwind/src/FrameHeaderCache.hpp
index 54d5d33c3cd7ede..e1754cb6e1e676a 100644
--- a/libunwind/src/FrameHeaderCache.hpp
+++ b/libunwind/src/FrameHeaderCache.hpp
@@ -41,7 +41,7 @@ class _LIBUNWIND_HIDDEN FrameHeaderCache {
 
   // Can't depend on the C++ standard library in libunwind, so use an array to
   // allocate the entries, and two linked lists for ordering unused and 
recently
-  // used entries.  FIXME: Would the the extra memory for a doubly-linked list
+  // used entries.  FIXME: Would the extra memory for a doubly-linked list
   // be better than the runtime cost of traversing a very short singly-linked
   // list on a cache miss? The entries themselves are all small and 
consecutive,
   // so unlikely to cause page faults when following the pointers. The memory

diff  --git a/libunwind/src/UnwindRegistersRestore.S 
b/libunwind/src/UnwindRegistersRestore.S
index c4

[PATCH] D137338: Fix dupe word typos

2023-08-31 Thread Louis Dionne via Phabricator via cfe-commits
ldionne added a comment.
Herald added subscribers: wangpc, gysit, Dinistro, hoy, bviyer, wlei, jplehr, 
PiotrZSL, luke, sunshaoce.
Herald added a reviewer: springerm.
Herald added a reviewer: kiranchandramohan.
Herald added a project: clang-format.
Herald added reviewers: rymiel, HazardyKnusperkeks, owenpan, MyDeveloperDay.

The libcxx, libcxxabi and libunwind parts were committed in 
b397921fc7ef4e2882b3ae9c5f12fb40daca4078 
. Is it 
possible to close this or rebase it so we can remove the libc++ subscription to 
clear the review queue? We're trying to clean things up as part of the Github 
PR transition.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D137338

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


[PATCH] D159045: [clang-tidy] Improved documentation for readability-function-size

2023-08-31 Thread Félix-Antoine Constantin via Phabricator via cfe-commits
felix642 added a comment.

We can already disable those options if we don't define them in the config. 
Adding the possibility to provide optional values seems redundant to me. Do you 
see any reason why we would absolutely need to add this option to the config if 
we want to disable it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159045

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


[PATCH] D158507: [Flang][Driver] Add support for fomit-frame-pointer 1/2

2023-08-31 Thread victorkingi via Phabricator via cfe-commits
victorkingi updated this revision to Diff 555074.
victorkingi added a comment.

Moved function implementations from llvm directory to clang


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158507

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/CommonArgs.h
  clang/lib/Driver/ToolChains/Flang.cpp
  flang/test/Driver/driver-help-hidden.f90
  flang/test/Driver/driver-help.f90
  flang/test/Driver/frontend-forwarding.f90

Index: flang/test/Driver/frontend-forwarding.f90
===
--- flang/test/Driver/frontend-forwarding.f90
+++ flang/test/Driver/frontend-forwarding.f90
@@ -14,6 +14,7 @@
 ! RUN: -fno-signed-zeros \
 ! RUN: -fassociative-math \
 ! RUN: -freciprocal-math \
+! RUN: -fomit-frame-pointer \
 ! RUN: -fpass-plugin=Bye%pluginext \
 ! RUN: -fversion-loops-for-stride \
 ! RUN: -flang-experimental-polymorphism \
@@ -58,5 +59,6 @@
 ! CHECK: "-Reverything"
 ! CHECK: "-Rno-everything"
 ! CHECK: "-Rpass=inline"
+! CHECK: "-mframe-pointer=none"
 ! CHECK: "-mllvm" "-print-before-all"
 ! CHECK: "-save-temps=obj"
Index: flang/test/Driver/driver-help.f90
===
--- flang/test/Driver/driver-help.f90
+++ flang/test/Driver/driver-help.f90
@@ -57,6 +57,7 @@
 ! HELP-NEXT: -fno-stack-arrays   Allocate array temporaries on the heap (default)
 ! HELP-NEXT: -fno-version-loops-for-stride
 ! HELP-NEXT: Do not create unit-strided loops (default)
+! HELP-NEXT: -fomit-frame-pointerOmit the frame pointer from functions that don't need it. Some stack unwinding cases, such as profilers and sanitizers, may prefer specifying -fno-omit-frame-pointer. On many targets, -O1 and higher omit the frame pointer by default. -m[no-]omit-leaf-frame-pointer takes precedence for leaf functions
 ! HELP-NEXT: -fopenacc   Enable OpenACC
 ! HELP-NEXT: -fopenmp-target-debug   Enable debugging in the OpenMP offloading device RTL
 ! HELP-NEXT: -fopenmp-targets=
@@ -219,6 +220,7 @@
 ! HELP-FC1-NEXT: -load  Load the named plugin (dynamic shared object)
 ! HELP-FC1-NEXT: -menable-no-infsAllow optimization to assume there are no infinities.
 ! HELP-FC1-NEXT: -menable-no-nansAllow optimization to assume there are no NaNs.
+! HELP-FC1-NEXT: -mframe-pointer= Specify which frame pointers to retain.
 ! HELP-FC1-NEXT: -mllvm   Additional arguments to forward to LLVM's option processing
 ! HELP-FC1-NEXT: -mmlir   Additional arguments to forward to MLIR's option processing
 ! HELP-FC1-NEXT: -module-dirPut MODULE files in 
Index: flang/test/Driver/driver-help-hidden.f90
===
--- flang/test/Driver/driver-help-hidden.f90
+++ flang/test/Driver/driver-help-hidden.f90
@@ -65,6 +65,7 @@
 ! CHECK-NEXT: -fno-stack-arrays   Allocate array temporaries on the heap (default)
 ! CHECK-NEXT: -fno-version-loops-for-stride
 ! CHECK-NEXT: Do not create unit-strided loops (default)
+! CHECK-NEXT: -fomit-frame-pointerOmit the frame pointer from functions that don't need it. Some stack unwinding cases, such as profilers and sanitizers, may prefer specifying -fno-omit-frame-pointer. On many targets, -O1 and higher omit the frame pointer by default. -m[no-]omit-leaf-frame-pointer takes precedence for leaf functions
 ! CHECK-NEXT: -fopenacc   Enable OpenACC
 ! CHECK-NEXT: -fopenmp-assume-no-nested-parallelism
 ! CHECK-NEXT: Assert no nested parallel regions in the GPU
Index: clang/lib/Driver/ToolChains/Flang.cpp
===
--- clang/lib/Driver/ToolChains/Flang.cpp
+++ clang/lib/Driver/ToolChains/Flang.cpp
@@ -10,6 +10,7 @@
 #include "Flang.h"
 #include "CommonArgs.h"
 
+#include "clang/Basic/CodeGenOptions.h"
 #include "clang/Driver/Options.h"
 #include "llvm/Frontend/Debug/Options.h"
 #include "llvm/Support/FileSystem.h"
@@ -534,6 +535,24 @@
   // Forward -Xflang arguments to -fc1
   Args.AddAllArgValues(CmdArgs, options::OPT_Xflang);
 
+  CodeGenOptions::FramePointerKind FPKeepKind =
+  getFramePointerKind(Args, Triple);
+
+  const char *FPKeepKindStr = nullptr;
+  switch (FPKeepKind) {
+  case CodeGenOptions::FramePointerKind::None:
+FPKeepKindStr = "-mframe-pointer=none";
+break;
+  case CodeGenOptions::FramePointerKind::NonLeaf:
+FPKeepKindStr = "-mframe-pointer=non-leaf";
+break;
+  case CodeGenOptions::FramePointerKind::All:
+FPKeepKindStr = "-mframe-pointer=all";
+break;
+  }
+  assert(FPKeepKindStr && "unknown FramePointerKind");
+  CmdArgs.push_back(FPKeepKindStr);
+
   // Forward -mllvm options to the LLVM option parser. In practice, t

[PATCH] D159045: [clang-tidy] Improved documentation for readability-function-size

2023-08-31 Thread Piotr Zegar via Phabricator via cfe-commits
PiotrZSL added a comment.

In D159045#4631650 , @felix642 wrote:

> We can already disable those options if we don't define them in the config. 
> Adding the possibility to provide optional values seems redundant to me. Do 
> you see any reason why we would absolutely need to add this option to the 
> config if we want to disable it?

a) If you use config file inheritance, when one config file define it, and 
other that inherit it (or command line) want to disable such option.
b) When we use --dump-config then it will be printed anyway.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D159045

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


[PATCH] D158707: [analyzer] Fix a few size-type signedness inconsistency related to DynamicExtent

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



Comment at: clang/test/Analysis/memory-model.cpp:167
+  clang_analyzer_dumpExtent(a);   // expected-warning {{0 S64b}}
+  clang_analyzer_dumpElementCount(a); // expected-warning {{5 S64b}}
+  clang_analyzer_dumpExtent(t);   // expected-warning {{0 S64b}}

If the array has zero extent, how can is have any elements?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158707

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


[PATCH] D158869: [clang] Fix timing of propagation of MSInheritanceAttr for template instantiation declarations.

2023-08-31 Thread Tom Honermann via Phabricator via cfe-commits
tahonermann updated this revision to Diff 555076.
tahonermann added a comment.

Added a release note.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158869

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/CodeGenCXX/microsoft-abi-member-pointers.cpp


Index: clang/test/CodeGenCXX/microsoft-abi-member-pointers.cpp
===
--- clang/test/CodeGenCXX/microsoft-abi-member-pointers.cpp
+++ clang/test/CodeGenCXX/microsoft-abi-member-pointers.cpp
@@ -1,5 +1,6 @@
 // RUN: %clang_cc1 -std=c++11 -Wno-uninitialized -fno-rtti -emit-llvm %s -o - 
-triple=i386-pc-win32 -fms-extensions | FileCheck -allow-deprecated-dag-overlap 
%s
 // RUN: %clang_cc1 -std=c++11 -Wno-uninitialized -fno-rtti -emit-llvm %s -o - 
-triple=x86_64-pc-win32 -fms-extensions | FileCheck %s -check-prefix=X64
+// RUN: %clang_cc1 -std=c++17 -Wno-uninitialized -fno-rtti -emit-llvm %s -o - 
-triple=x86_64-pc-win32 -fms-extensions | FileCheck %s -check-prefix=X64
 // RUN: %clang_cc1 -std=c++11 -Wno-uninitialized -fno-rtti -emit-llvm %s -o - 
-triple=i386-pc-win32 -DINCOMPLETE_VIRTUAL -fms-extensions -verify
 // RUN: %clang_cc1 -std=c++11 -Wno-uninitialized -fno-rtti -emit-llvm %s -o - 
-triple=i386-pc-win32 -DINCOMPLETE_VIRTUAL -DMEMFUN -fms-extensions -verify
 
@@ -934,3 +935,32 @@
 void A::printd() { JSMethod(); }
 // CHECK-LABEL: 
@"??$JSMethod@VA@PMFInTemplateArgument@@$1?printd@12@AAEHH@Z@PMFInTemplateArgument@@YAXXZ"(
 }
+
+namespace MissingMSInheritanceAttr {
+// This is a regression test for an assertion failure that occurred when
+// compiling for C++17. The issue concerned a failure to propagate a
+// MSInheritanceAttr attribute for the explicit template instantiation
+// definition prior to it being required to complete the specialization
+// definition in order to determine its alignment so as to resolve a
+// lookup for a deallocation function for the virtual destructor.
+template 
+class a;
+struct b {
+  typedef void (a::*f)();
+  f d;
+};
+template 
+class a {
+  virtual ~a();
+  b e;
+};
+extern template class a;
+template class a;
+#ifdef _WIN64
+static_assert(sizeof(b::d) == 24, "");
+static_assert(sizeof(void (a::*)()) == 24, "");
+#else
+static_assert(sizeof(b::d) == 16, "");
+static_assert(sizeof(void (a::*)()) == 16, "");
+#endif
+}
Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -10110,6 +10110,17 @@
 ClassTemplate, CanonicalConverted, PrevDecl);
 SetNestedNameSpecifier(*this, Specialization, SS);
 
+// A MSInheritanceAttr attached to the previous declaration must be
+// propagated to the new node prior to instantiation.
+if (PrevDecl) {
+  if (const auto *A = PrevDecl->getAttr()) {
+auto *Clone = A->clone(getASTContext());
+Clone->setInherited(true);
+Specialization->addAttr(Clone);
+Consumer.AssignInheritanceModel(Specialization);
+  }
+}
+
 if (!HasNoEffect && !PrevDecl) {
   // Insert the new specialization.
   ClassTemplate->AddSpecialization(Specialization, InsertPos);
@@ -10226,11 +10237,6 @@
   dllExportImportClassTemplateSpecialization(*this, Def);
 }
 
-if (Def->hasAttr()) {
-  Specialization->addAttr(Def->getAttr());
-  Consumer.AssignInheritanceModel(Specialization);
-}
-
 // Set the template specialization kind. Make sure it is set before
 // instantiating the members which will trigger ASTConsumer callbacks.
 Specialization->setTemplateSpecializationKind(TSK);
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -292,6 +292,9 @@
 
 Windows Support
 ^^^
+- Fixed an assertion failure that occurred due to a failure to propagate
+  ``MSInheritanceAttr`` attributes to class template instantiations created
+  for explicit template instantiation declarations.
 
 LoongArch Support
 ^


Index: clang/test/CodeGenCXX/microsoft-abi-member-pointers.cpp
===
--- clang/test/CodeGenCXX/microsoft-abi-member-pointers.cpp
+++ clang/test/CodeGenCXX/microsoft-abi-member-pointers.cpp
@@ -1,5 +1,6 @@
 // RUN: %clang_cc1 -std=c++11 -Wno-uninitialized -fno-rtti -emit-llvm %s -o - -triple=i386-pc-win32 -fms-extensions | FileCheck -allow-deprecated-dag-overlap %s
 // RUN: %clang_cc1 -std=c++11 -Wno-uninitialized -fno-rtti -emit-llvm %s -o - -triple=x86_64-pc-win32 -fms-extensions | FileCheck %s -check-prefix=X64
+// RUN: %clang_cc1 -std=c++17 -Wno-uninitialized -fno-rtti -emit-llvm %s -o - -triple=x86_64-pc-win32 -fms-extensions | FileCheck %s -check-prefix=X64
 // RUN: %clang_cc1 -std=c++11 -Wno-uninitialized -fno

[clang] 6658db5 - [clang] Fix timing of propagation of MSInheritanceAttr for template instantiation declarations.

2023-08-31 Thread Tom Honermann via cfe-commits

Author: Tom Honermann
Date: 2023-08-31T09:10:05-07:00
New Revision: 6658db5e501475bf288f6d9eb2a8ff21d5fee8b5

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

LOG: [clang] Fix timing of propagation of MSInheritanceAttr for template 
instantiation declarations.

This change addresses three issues:
1) A failure to propagate a MSInheritanceAttr prior to it being required by
   an explicit class template instantiation definition.
2) The same MSInheritanceAttr attribute being attached to the same
   ClassTemplateSpecializationDecl twice.
3) MSInheritanceAttr attributes were not being cloned nor marked as inherited
   when added to new template instantiation declarations.

Sema::ActOnExplicitInstantiation() is responsible for the construction of
ClassTemplateSpecializationDecl nodes for explicit template instantiation
declarations and definitions.  When invoked when a prior declaration node
corresponding to an implicit instantiation exists, the prior declaration
node is repurposed to represent the explicit instantiation declaration
or definition.  When no previous declaration node exists or when the previous
node corresponds to an explicit declaration, a new node is allocated.
Previously, in either case, the function attempted to propagate any existing
MSInheritanceAttr attribute from the previous node, but did so regardless
of whether the previous node was reused (in which case the repurposed previous
node would gain a second attachment of the attribute; the second issue listed
above) or a new node was created.  In the latter case, the attribute was not
propagated before it was required to be present when compiling for C++17 or
later (the first issue listed above).  The absent attribute resulted in an
assertion failure that occurred during instantiation of the specialization
definition when attempting to complete the definition in order to determine
its alignment so as to resolve a lookup for a deallocation function for a
virtual destructor.  This change addresses both issues by propagating the
attribute closer in time to when a new ClassTemplateSpecializationDecl node
is created and only when such a node is newly created.

Reviewed By: aaron.ballman, rnk

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

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/lib/Sema/SemaTemplate.cpp
clang/test/CodeGenCXX/microsoft-abi-member-pointers.cpp

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index ded58a369c7a03..138730336f7426 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -292,6 +292,9 @@ Arm and AArch64 Support
 
 Windows Support
 ^^^
+- Fixed an assertion failure that occurred due to a failure to propagate
+  ``MSInheritanceAttr`` attributes to class template instantiations created
+  for explicit template instantiation declarations.
 
 LoongArch Support
 ^

diff  --git a/clang/lib/Sema/SemaTemplate.cpp b/clang/lib/Sema/SemaTemplate.cpp
index f45c4c463fa95f..808a8b000aff72 100644
--- a/clang/lib/Sema/SemaTemplate.cpp
+++ b/clang/lib/Sema/SemaTemplate.cpp
@@ -10110,6 +10110,17 @@ DeclResult Sema::ActOnExplicitInstantiation(
 ClassTemplate, CanonicalConverted, PrevDecl);
 SetNestedNameSpecifier(*this, Specialization, SS);
 
+// A MSInheritanceAttr attached to the previous declaration must be
+// propagated to the new node prior to instantiation.
+if (PrevDecl) {
+  if (const auto *A = PrevDecl->getAttr()) {
+auto *Clone = A->clone(getASTContext());
+Clone->setInherited(true);
+Specialization->addAttr(Clone);
+Consumer.AssignInheritanceModel(Specialization);
+  }
+}
+
 if (!HasNoEffect && !PrevDecl) {
   // Insert the new specialization.
   ClassTemplate->AddSpecialization(Specialization, InsertPos);
@@ -10226,11 +10237,6 @@ DeclResult Sema::ActOnExplicitInstantiation(
   dllExportImportClassTemplateSpecialization(*this, Def);
 }
 
-if (Def->hasAttr()) {
-  Specialization->addAttr(Def->getAttr());
-  Consumer.AssignInheritanceModel(Specialization);
-}
-
 // Set the template specialization kind. Make sure it is set before
 // instantiating the members which will trigger ASTConsumer callbacks.
 Specialization->setTemplateSpecializationKind(TSK);

diff  --git a/clang/test/CodeGenCXX/microsoft-abi-member-pointers.cpp 
b/clang/test/CodeGenCXX/microsoft-abi-member-pointers.cpp
index 04ce29c64d6e36..2ac1961465d8a8 100644
--- a/clang/test/CodeGenCXX/microsoft-abi-member-pointers.cpp
+++ b/clang/test/CodeGenCXX/microsoft-abi-member-pointers.cpp
@@ -1,5 +1,6 @@
 // RUN: %clang_cc1 -std=c++11 -Wno-uninitialized -fno-rtti -emit-llvm %s -o - 
-triple=i386-pc-win32 -fms-exten

[PATCH] D158869: [clang] Fix timing of propagation of MSInheritanceAttr for template instantiation declarations.

2023-08-31 Thread Tom Honermann 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 rG6658db5e5014: [clang] Fix timing of propagation of 
MSInheritanceAttr for template… (authored by tahonermann).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158869

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Sema/SemaTemplate.cpp
  clang/test/CodeGenCXX/microsoft-abi-member-pointers.cpp


Index: clang/test/CodeGenCXX/microsoft-abi-member-pointers.cpp
===
--- clang/test/CodeGenCXX/microsoft-abi-member-pointers.cpp
+++ clang/test/CodeGenCXX/microsoft-abi-member-pointers.cpp
@@ -1,5 +1,6 @@
 // RUN: %clang_cc1 -std=c++11 -Wno-uninitialized -fno-rtti -emit-llvm %s -o - 
-triple=i386-pc-win32 -fms-extensions | FileCheck -allow-deprecated-dag-overlap 
%s
 // RUN: %clang_cc1 -std=c++11 -Wno-uninitialized -fno-rtti -emit-llvm %s -o - 
-triple=x86_64-pc-win32 -fms-extensions | FileCheck %s -check-prefix=X64
+// RUN: %clang_cc1 -std=c++17 -Wno-uninitialized -fno-rtti -emit-llvm %s -o - 
-triple=x86_64-pc-win32 -fms-extensions | FileCheck %s -check-prefix=X64
 // RUN: %clang_cc1 -std=c++11 -Wno-uninitialized -fno-rtti -emit-llvm %s -o - 
-triple=i386-pc-win32 -DINCOMPLETE_VIRTUAL -fms-extensions -verify
 // RUN: %clang_cc1 -std=c++11 -Wno-uninitialized -fno-rtti -emit-llvm %s -o - 
-triple=i386-pc-win32 -DINCOMPLETE_VIRTUAL -DMEMFUN -fms-extensions -verify
 
@@ -934,3 +935,32 @@
 void A::printd() { JSMethod(); }
 // CHECK-LABEL: 
@"??$JSMethod@VA@PMFInTemplateArgument@@$1?printd@12@AAEHH@Z@PMFInTemplateArgument@@YAXXZ"(
 }
+
+namespace MissingMSInheritanceAttr {
+// This is a regression test for an assertion failure that occurred when
+// compiling for C++17. The issue concerned a failure to propagate a
+// MSInheritanceAttr attribute for the explicit template instantiation
+// definition prior to it being required to complete the specialization
+// definition in order to determine its alignment so as to resolve a
+// lookup for a deallocation function for the virtual destructor.
+template 
+class a;
+struct b {
+  typedef void (a::*f)();
+  f d;
+};
+template 
+class a {
+  virtual ~a();
+  b e;
+};
+extern template class a;
+template class a;
+#ifdef _WIN64
+static_assert(sizeof(b::d) == 24, "");
+static_assert(sizeof(void (a::*)()) == 24, "");
+#else
+static_assert(sizeof(b::d) == 16, "");
+static_assert(sizeof(void (a::*)()) == 16, "");
+#endif
+}
Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -10110,6 +10110,17 @@
 ClassTemplate, CanonicalConverted, PrevDecl);
 SetNestedNameSpecifier(*this, Specialization, SS);
 
+// A MSInheritanceAttr attached to the previous declaration must be
+// propagated to the new node prior to instantiation.
+if (PrevDecl) {
+  if (const auto *A = PrevDecl->getAttr()) {
+auto *Clone = A->clone(getASTContext());
+Clone->setInherited(true);
+Specialization->addAttr(Clone);
+Consumer.AssignInheritanceModel(Specialization);
+  }
+}
+
 if (!HasNoEffect && !PrevDecl) {
   // Insert the new specialization.
   ClassTemplate->AddSpecialization(Specialization, InsertPos);
@@ -10226,11 +10237,6 @@
   dllExportImportClassTemplateSpecialization(*this, Def);
 }
 
-if (Def->hasAttr()) {
-  Specialization->addAttr(Def->getAttr());
-  Consumer.AssignInheritanceModel(Specialization);
-}
-
 // Set the template specialization kind. Make sure it is set before
 // instantiating the members which will trigger ASTConsumer callbacks.
 Specialization->setTemplateSpecializationKind(TSK);
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -292,6 +292,9 @@
 
 Windows Support
 ^^^
+- Fixed an assertion failure that occurred due to a failure to propagate
+  ``MSInheritanceAttr`` attributes to class template instantiations created
+  for explicit template instantiation declarations.
 
 LoongArch Support
 ^


Index: clang/test/CodeGenCXX/microsoft-abi-member-pointers.cpp
===
--- clang/test/CodeGenCXX/microsoft-abi-member-pointers.cpp
+++ clang/test/CodeGenCXX/microsoft-abi-member-pointers.cpp
@@ -1,5 +1,6 @@
 // RUN: %clang_cc1 -std=c++11 -Wno-uninitialized -fno-rtti -emit-llvm %s -o - -triple=i386-pc-win32 -fms-extensions | FileCheck -allow-deprecated-dag-overlap %s
 // RUN: %clang_cc1 -std=c++11 -Wno-uninitialized -fno-rtti -emit-llvm %s -o - -triple=x86_64-pc-win32 -fms-extensions | FileCheck %s -check-prefix=X64
+// RUN: %clang_cc1 -std=c++17 -Wno-uninitialized

[PATCH] D159292: [driver] Conditionally include installed libc++ headers for Android

2023-08-31 Thread Shoaib Meenai via Phabricator via cfe-commits
smeenai created this revision.
smeenai added reviewers: danalbert, srhines, pcc, phosek, thakis, MaskRay, 
glandium.
Herald added a subscriber: danielkiss.
Herald added a project: All.
smeenai requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

https://reviews.llvm.org/D71154 prevented Clang from search for libc++
headers installed alongside the driver when targeting Android. The
motivation was the NDK's use of a different libc++ inline namespace
(`__ndk1` instead of the standard `__1`), which made regular libc++
headers incompatible with the NDK's libc++ library.

Since then, libc++ has gained the ability to install its `__config_site`
header (which controls the inline namespace, among other things) to a
per-target include directory, which enables per-target customizations.
If this directory is present, the user has expressly built libc++ for
Android, and we should use those headers.

The motivation is that, with the current setup, if a user builds their
own libc++ for Android, they'll use the library they built themselves
but the NDK's headers instead of their own, which is surprising at best
and can cause all sorts of problems (e.g. if you built your own libc++
with a different ABI configuration). It's important to match the headers
and libraries in that scenario, and checking for an Android per-target
include directory lets us do so without regressing the original scenario
which https://reviews.llvm.org/D71154 was addressing.

While I'm here, switch to using sys::path::append instead of slashes
directly, to get system path separators on Windows, which is consistent
with how library paths are constructed (and that consistency will be
important in a follow-up, where we use a common search function for the
include and library path construction).

(As an aside, one of the motivations for https://reviews.llvm.org/D71154
was to support targeting both Android and Apple platforms, which
expected libc++ headers to be provided by the toolcain at the time.
Apple has since switched to including libc++ headers in the platform SDK
instead of in the toolchain, so that specific motivation no longer
applies either.)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D159292

Files:
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/test/Driver/android-installed-libcxx.cpp
  clang/test/Driver/android-ndk-standalone.cpp
  clang/test/Driver/android-no-installed-libcxx.cpp
  clang/test/Driver/linux-header-search.cpp
  clang/test/Driver/linux-musl-header-search.cpp
  clang/test/Driver/linux-per-target-runtime-dir.c

Index: clang/test/Driver/linux-per-target-runtime-dir.c
===
--- clang/test/Driver/linux-per-target-runtime-dir.c
+++ clang/test/Driver/linux-per-target-runtime-dir.c
@@ -9,7 +9,7 @@
 // CHECK-PER-TARGET-RUNTIME: "-cc1"
 // CHECK-PER-TARGET-RUNTIME: "-resource-dir" "[[RESDIR:[^"]*]]"
 // CHECK-PER-TARGET-RUNTIME: "-isysroot" "[[SYSROOT:[^"]+]]"
-// CHECK-PER-TARGET-RUNTIME: "-internal-isystem" "{{.*}}/../include/c++/v1"
+// CHECK-PER-TARGET-RUNTIME: "-internal-isystem" "{{.*}}{{/|}}..{{/|}}include{{/|}}c++{{/|}}v1"
 // CHECK-PER-TARGET-RUNTIME: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
 // CHECK-PER-TARGET-RUNTIME: "--sysroot=[[SYSROOT]]"
 // CHECK-PER-TARGET-RUNTIME: "-L{{.*}}{{/|}}..{{/|}}lib{{/|}}x86_64-unknown-linux-gnu"
Index: clang/test/Driver/linux-musl-header-search.cpp
===
--- clang/test/Driver/linux-musl-header-search.cpp
+++ clang/test/Driver/linux-musl-header-search.cpp
@@ -9,7 +9,7 @@
 // This is different from a glibc-based distribution.
 // CHECK-X86-64-LIBCXX: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
 // CHECK-X86-64-LIBCXX: "-isysroot" "[[SYSROOT:[^"]+]]"
-// CHECK-X86-64-LIBCXX: "-internal-isystem" "[[SYSROOT]]/usr/include/c++/v1"
+// CHECK-X86-64-LIBCXX: "-internal-isystem" "[[SYSROOT]]{{/|}}usr{{/|}}include{{/|}}c++{{/|}}v1"
 // CHECK-X86-64-LIBCXX: "-internal-isystem" "[[SYSROOT]]/usr/local/include"
 // CHECK-X86-64-LIBCXX: "-internal-externc-isystem" "[[SYSROOT]]/usr/include"
 // CHECK-X86-64-LIBCXX: "-internal-isystem" "[[RESOURCE_DIR]]{{/|}}include"
Index: clang/test/Driver/linux-header-search.cpp
===
--- clang/test/Driver/linux-header-search.cpp
+++ clang/test/Driver/linux-header-search.cpp
@@ -13,8 +13,8 @@
 // RUN:   | FileCheck --check-prefix=CHECK-BASIC-LIBCXX-SYSROOT %s
 // CHECK-BASIC-LIBCXX-SYSROOT: "-cc1"
 // CHECK-BASIC-LIBCXX-SYSROOT: "-isysroot" "[[SYSROOT:[^"]+]]"
-// CHECK-BASIC-LIBCXX-SYSROOT: "-internal-isystem" "[[SYSROOT]]/usr/include/x86_64-unknown-linux-gnu/c++/v1"
-// CHECK-BASIC-LIBCXX-SYSROOT: "-internal-isystem" "[[SYSROOT]]/usr/include/c++/v1"
+// CHECK-BASIC-LIBCXX-SYSROOT: "-internal-isystem" "[[SYSROOT]][[SEP:/|]]usr[[SEP]]include[[SEP]]x86_64-unkno

[PATCH] D159293: [driver] Perform fallback target searches for stdlib

2023-08-31 Thread Shoaib Meenai via Phabricator via cfe-commits
smeenai created this revision.
smeenai added reviewers: MaskRay, phosek, thakis, glandium.
Herald added a subscriber: abrachet.
Herald added a project: All.
smeenai requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Searching for target-specific standard library header and library paths
should perform fallback searches for targets, the same way searching for
the runtime libraries does. It's important for the header and library
searches to be consistent, otherwise we could end up using mismatched
headers and libraries. (See also https://reviews.llvm.org/D146664.)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D159293

Files:
  clang/include/clang/Driver/ToolChain.h
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/Fuchsia.cpp
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/lib/Driver/ToolChains/VEToolchain.cpp
  clang/test/Driver/Inputs/basic_android_libcxx_tree/usr/bin/.keep
  
clang/test/Driver/Inputs/basic_android_libcxx_tree/usr/lib/aarch64-unknown-linux-android/libc++.so
  
clang/test/Driver/Inputs/basic_android_libcxx_tree/usr/lib/aarch64-unknown-linux-android21/libc++.so
  clang/test/Driver/android-installed-libcxx.cpp
  clang/test/Driver/linux-per-target-runtime-dir.c

Index: clang/test/Driver/linux-per-target-runtime-dir.c
===
--- clang/test/Driver/linux-per-target-runtime-dir.c
+++ clang/test/Driver/linux-per-target-runtime-dir.c
@@ -14,6 +14,21 @@
 // CHECK-PER-TARGET-RUNTIME: "--sysroot=[[SYSROOT]]"
 // CHECK-PER-TARGET-RUNTIME: "-L{{.*}}{{/|}}..{{/|}}lib{{/|}}x86_64-unknown-linux-gnu"
 
+// RUN: %clang --target=aarch64-unknown-linux-android21 -print-file-name=libc++.so 2>&1 \
+// RUN: -ccc-install-dir %S/Inputs/basic_android_libcxx_tree/usr/bin \
+// RUN:   | FileCheck --check-prefix=CHECK-LIBCXX-ANDROID21 %s
+// CHECK-LIBCXX-ANDROID21: ..{{/|\\}}lib{{/|\\}}aarch64-unknown-linux-android21{{/|\\}}libc++.so
+
+// RUN: %clang --target=aarch64-unknown-linux-android23 -print-file-name=libc++.so 2>&1 \
+// RUN: -ccc-install-dir %S/Inputs/basic_android_libcxx_tree/usr/bin \
+// RUN:   | FileCheck --check-prefix=CHECK-LIBCXX-ANDROID23 %s
+// CHECK-LIBCXX-ANDROID23: ..{{/|\\}}lib{{/|\\}}aarch64-unknown-linux-android{{/|\\}}libc++.so
+
+// RUN: %clang --target=aarch64-unknown-linux-android -print-file-name=libc++.so 2>&1 \
+// RUN: -ccc-install-dir %S/Inputs/basic_android_libcxx_tree/usr/bin \
+// RUN:   | FileCheck --check-prefix=CHECK-LIBCXX-ANDROID %s
+// CHECK-LIBCXX-ANDROID: ..{{/|\\}}lib{{/|\\}}aarch64-unknown-linux-android{{/|\\}}libc++.so
+
 // RUN: %clang -rtlib=compiler-rt -print-libgcc-file-name 2>&1 \
 // RUN: --target=x86_64-unknown-linux-gnu \
 // RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
Index: clang/test/Driver/android-installed-libcxx.cpp
===
--- clang/test/Driver/android-installed-libcxx.cpp
+++ clang/test/Driver/android-installed-libcxx.cpp
@@ -18,5 +18,9 @@
 // RUN:   --sysroot=%t2/sysroot -stdlib=libc++ -fsyntax-only \
 // RUN:   %s -### 2>&1 | FileCheck --check-prefix=ANDROID-DIR -DDIR=%/t2/bin %s
 
+// RUN: %clang -target aarch64-none-linux-android21 -ccc-install-dir %/t2/bin \
+// RUN:   --sysroot=%t2/sysroot -stdlib=libc++ -fsyntax-only \
+// RUN:   %s -### 2>&1 | FileCheck --check-prefix=ANDROID-DIR -DDIR=%/t2/bin %s
+
 // ANDROID-DIR: "-internal-isystem" "[[DIR]][[SEP:/|]]..[[SEP]]include[[SEP]]aarch64-none-linux-android[[SEP]]c++[[SEP]]v1"
 // ANDROID-DIR-SAME: "-internal-isystem" "[[DIR]][[SEP]]..[[SEP]]include[[SEP]]c++[[SEP]]v1"
Index: clang/lib/Driver/ToolChains/VEToolchain.cpp
===
--- clang/lib/Driver/ToolChains/VEToolchain.cpp
+++ clang/lib/Driver/ToolChains/VEToolchain.cpp
@@ -45,11 +45,11 @@
   getFilePaths().clear();
 
   // Add library directories:
-  //   ${BINPATH}/../lib/ve-unknown-linux-gnu, (== getStdlibPaths)
+  //   ${BINPATH}/../lib/ve-unknown-linux-gnu, (== getStdlibPath)
   //   ${RESOURCEDIR}/lib/linux/ve, (== getArchSpecificLibPaths)
   //   ${SYSROOT}/opt/nec/ve/lib,
-  for (auto &Path : getStdlibPaths())
-getFilePaths().push_back(std::move(Path));
+  if (std::optional Path = getStdlibPath())
+getFilePaths().push_back(std::move(*Path));
   for (const auto &Path : getArchSpecificLibPaths())
 getFilePaths().push_back(Path);
   getFilePaths().push_back(computeSysRoot() + "/opt/nec/ve/lib");
Index: clang/lib/Driver/ToolChains/Gnu.cpp
===
--- clang/lib/Driver/ToolChains/Gnu.cpp
+++ clang/lib/Driver/ToolChains/Gnu.cpp
@@ -3096,7 +3096,6 @@
llvm::opt::ArgStringList &CC1Args) const {
   const Driver &D = getDriver();
   std::string SysRoot = computeSysRoot();
-  std::string Target = getTripleString();
 
   auto AddInclu

[PATCH] D158476: [driver] Search for compatible Android runtime directories

2023-08-31 Thread Shoaib Meenai via Phabricator via cfe-commits
smeenai updated this revision to Diff 555082.
smeenai added a comment.

Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158476

Files:
  clang/include/clang/Driver/ToolChain.h
  clang/lib/Driver/ToolChain.cpp
  
clang/test/Driver/Inputs/basic_android_libcxx_tree/usr/lib/aarch64-unknown-linux-android21/libc++.so
  
clang/test/Driver/Inputs/basic_android_libcxx_tree/usr/lib/aarch64-unknown-linux-android23/libc++.so
  
clang/test/Driver/Inputs/basic_android_libcxx_tree/usr/lib/aarch64-unknown-linux-android29/libc++.so
  
clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/lib/aarch64-unknown-linux-android21/libclang_rt.builtins.a
  
clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/lib/aarch64-unknown-linux-android23/libclang_rt.builtins.a
  
clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/lib/aarch64-unknown-linux-android29/libclang_rt.builtins.a
  clang/test/Driver/android-installed-libcxx.cpp
  clang/test/Driver/linux-per-target-runtime-dir.c

Index: clang/test/Driver/linux-per-target-runtime-dir.c
===
--- clang/test/Driver/linux-per-target-runtime-dir.c
+++ clang/test/Driver/linux-per-target-runtime-dir.c
@@ -17,12 +17,25 @@
 // RUN: %clang --target=aarch64-unknown-linux-android21 -print-file-name=libc++.so 2>&1 \
 // RUN: -ccc-install-dir %S/Inputs/basic_android_libcxx_tree/usr/bin \
 // RUN:   | FileCheck --check-prefix=CHECK-LIBCXX-ANDROID21 %s
-// CHECK-LIBCXX-ANDROID21: ..{{/|\\}}lib{{/|\\}}aarch64-unknown-linux-android21{{/|\\}}libc++.so
+// CHECK-LIBCXX-ANDROID21: ..{{/|\\}}lib{{/|\\}}aarch64-unknown-linux-android{{/|\\}}libc++.so
 
 // RUN: %clang --target=aarch64-unknown-linux-android23 -print-file-name=libc++.so 2>&1 \
 // RUN: -ccc-install-dir %S/Inputs/basic_android_libcxx_tree/usr/bin \
 // RUN:   | FileCheck --check-prefix=CHECK-LIBCXX-ANDROID23 %s
-// CHECK-LIBCXX-ANDROID23: ..{{/|\\}}lib{{/|\\}}aarch64-unknown-linux-android{{/|\\}}libc++.so
+// CHECK-LIBCXX-ANDROID23: ..{{/|\\}}lib{{/|\\}}aarch64-unknown-linux-android23{{/|\\}}libc++.so
+
+// RUN: %clang --target=aarch64-unknown-linux-android26 -print-file-name=libc++.so 2>&1 \
+// RUN: -ccc-install-dir %S/Inputs/basic_android_libcxx_tree/usr/bin \
+// RUN:   | FileCheck --check-prefix=CHECK-LIBCXX-ANDROID23 %s
+
+// RUN: %clang --target=aarch64-unknown-linux-android29 -print-file-name=libc++.so 2>&1 \
+// RUN: -ccc-install-dir %S/Inputs/basic_android_libcxx_tree/usr/bin \
+// RUN:   | FileCheck --check-prefix=CHECK-LIBCXX-ANDROID29 %s
+// CHECK-LIBCXX-ANDROID29: ..{{/|\\}}lib{{/|\\}}aarch64-unknown-linux-android29{{/|\\}}libc++.so
+
+// RUN: %clang --target=aarch64-unknown-linux-android31 -print-file-name=libc++.so 2>&1 \
+// RUN: -ccc-install-dir %S/Inputs/basic_android_libcxx_tree/usr/bin \
+// RUN:   | FileCheck --check-prefix=CHECK-LIBCXX-ANDROID29 %s
 
 // RUN: %clang --target=aarch64-unknown-linux-android -print-file-name=libc++.so 2>&1 \
 // RUN: -ccc-install-dir %S/Inputs/basic_android_libcxx_tree/usr/bin \
@@ -45,13 +58,29 @@
 // RUN: --target=aarch64-unknown-linux-android21 \
 // RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
 // RUN:   | FileCheck --check-prefix=CHECK-FILE-NAME-ANDROID21 %s
-// CHECK-FILE-NAME-ANDROID21: lib{{/|\\}}aarch64-unknown-linux-android21{{/|\\}}libclang_rt.builtins.a
+// CHECK-FILE-NAME-ANDROID21: lib{{/|\\}}aarch64-unknown-linux-android{{/|\\}}libclang_rt.builtins.a
 
 // RUN: %clang -rtlib=compiler-rt -print-file-name=libclang_rt.builtins.a 2>&1 \
 // RUN: --target=aarch64-unknown-linux-android23 \
 // RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
 // RUN:   | FileCheck --check-prefix=CHECK-FILE-NAME-ANDROID23 %s
-// CHECK-FILE-NAME-ANDROID23: lib{{/|\\}}aarch64-unknown-linux-android{{/|\\}}libclang_rt.builtins.a
+// CHECK-FILE-NAME-ANDROID23: lib{{/|\\}}aarch64-unknown-linux-android23{{/|\\}}libclang_rt.builtins.a
+
+// RUN: %clang -rtlib=compiler-rt -print-file-name=libclang_rt.builtins.a 2>&1 \
+// RUN: --target=aarch64-unknown-linux-android26 \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN:   | FileCheck --check-prefix=CHECK-FILE-NAME-ANDROID23 %s
+
+// RUN: %clang -rtlib=compiler-rt -print-file-name=libclang_rt.builtins.a 2>&1 \
+// RUN: --target=aarch64-unknown-linux-android29 \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN:   | FileCheck --check-prefix=CHECK-FILE-NAME-ANDROID29 %s
+// CHECK-FILE-NAME-ANDROID29: lib{{/|\\}}aarch64-unknown-linux-android29{{/|\\}}libclang_rt.builtins.a
+
+// RUN: %clang -rtlib=compiler-rt -print-file-name=libclang_rt.builtins.a 2>&1 \
+// RUN: --target=aarch64-unknown-linux-android31 \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN:   | FileCheck --check-prefix=CHECK-FILE-NAME-

  1   2   3   >