[clang-tools-extra] 5331e12 - [clang][transformer] Fix crash on replacement-less ASTEdit.

2022-08-10 Thread Clement Courbet via cfe-commits

Author: Clement Courbet
Date: 2022-08-10T09:08:05+02:00
New Revision: 5331e1229aa6d0d33b5ec9fab7c05310187746d9

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

LOG: [clang][transformer] Fix crash on replacement-less ASTEdit.

Given that we provide an EditGenerator edit(ASTEdit), we can't ever be
sure that the user won't give us an empty replacement.

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

Added: 


Modified: 
clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
clang/lib/Tooling/Transformer/RewriteRule.cpp

Removed: 




diff  --git 
a/clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp 
b/clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
index a3600ab58ff3f..9106d5a77dd7d 100644
--- a/clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
+++ b/clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
@@ -90,6 +90,32 @@ TEST(TransformerClangTidyCheckTest, 
DiagnosticsCorrectlyGenerated) {
   EXPECT_EQ(Errors[0].Message.FileOffset, 10U);
 }
 
+transformer::ASTEdit noReplacementEdit(transformer::RangeSelector Target) {
+  transformer::ASTEdit E;
+  E.TargetRange = std::move(Target);
+  return E;
+}
+
+TEST(TransformerClangTidyCheckTest, EmptyReplacement) {
+  class DiagOnlyCheck : public TransformerClangTidyCheck {
+  public:
+DiagOnlyCheck(StringRef Name, ClangTidyContext *Context)
+: TransformerClangTidyCheck(
+  makeRule(returnStmt(), edit(noReplacementEdit(node(RootID))),
+   cat("message")),
+  Name, Context) {}
+  };
+  std::string Input = "int h() { return 5; }";
+  std::vector Errors;
+  EXPECT_EQ("int h() { }", test::runCheckOnCode(Input, 
&Errors));
+  EXPECT_EQ(Errors.size(), 1U);
+  EXPECT_EQ(Errors[0].Message.Message, "message");
+  EXPECT_THAT(Errors[0].Message.Ranges, testing::IsEmpty());
+
+  // The diagnostic is anchored to the match, "return 5".
+  EXPECT_EQ(Errors[0].Message.FileOffset, 10U);
+}
+
 TEST(TransformerClangTidyCheckTest, DiagnosticMessageEscaped) {
   class GiveDiagWithPercentSymbol : public TransformerClangTidyCheck {
   public:

diff  --git a/clang/lib/Tooling/Transformer/RewriteRule.cpp 
b/clang/lib/Tooling/Transformer/RewriteRule.cpp
index 3e76489782f34..822d00d33d164 100644
--- a/clang/lib/Tooling/Transformer/RewriteRule.cpp
+++ b/clang/lib/Tooling/Transformer/RewriteRule.cpp
@@ -50,17 +50,21 @@ translateEdits(const MatchResult &Result, ArrayRef 
ASTEdits) {
 // produces a bad range, whereas the latter will simply ignore A.
 if (!EditRange)
   return SmallVector();
-auto Replacement = E.Replacement->eval(Result);
-if (!Replacement)
-  return Replacement.takeError();
-auto Metadata = E.Metadata(Result);
-if (!Metadata)
-  return Metadata.takeError();
 transformer::Edit T;
 T.Kind = E.Kind;
 T.Range = *EditRange;
-T.Replacement = std::move(*Replacement);
-T.Metadata = std::move(*Metadata);
+if (E.Replacement) {
+  auto Replacement = E.Replacement->eval(Result);
+  if (!Replacement)
+return Replacement.takeError();
+  T.Replacement = std::move(*Replacement);
+}
+if (E.Metadata) {
+  auto Metadata = E.Metadata(Result);
+  if (!Metadata)
+return Metadata.takeError();
+  T.Metadata = std::move(*Metadata);
+}
 Edits.push_back(std::move(T));
   }
   return Edits;



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


[PATCH] D128887: [clang][transformer] Fix crash on replacement-less ASTEdit.

2022-08-10 Thread Clement Courbet 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 rG5331e1229aa6: [clang][transformer] Fix crash on 
replacement-less ASTEdit. (authored by courbet).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128887

Files:
  clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
  clang/lib/Tooling/Transformer/RewriteRule.cpp


Index: clang/lib/Tooling/Transformer/RewriteRule.cpp
===
--- clang/lib/Tooling/Transformer/RewriteRule.cpp
+++ clang/lib/Tooling/Transformer/RewriteRule.cpp
@@ -50,17 +50,21 @@
 // produces a bad range, whereas the latter will simply ignore A.
 if (!EditRange)
   return SmallVector();
-auto Replacement = E.Replacement->eval(Result);
-if (!Replacement)
-  return Replacement.takeError();
-auto Metadata = E.Metadata(Result);
-if (!Metadata)
-  return Metadata.takeError();
 transformer::Edit T;
 T.Kind = E.Kind;
 T.Range = *EditRange;
-T.Replacement = std::move(*Replacement);
-T.Metadata = std::move(*Metadata);
+if (E.Replacement) {
+  auto Replacement = E.Replacement->eval(Result);
+  if (!Replacement)
+return Replacement.takeError();
+  T.Replacement = std::move(*Replacement);
+}
+if (E.Metadata) {
+  auto Metadata = E.Metadata(Result);
+  if (!Metadata)
+return Metadata.takeError();
+  T.Metadata = std::move(*Metadata);
+}
 Edits.push_back(std::move(T));
   }
   return Edits;
Index: clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
===
--- clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
+++ clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
@@ -90,6 +90,32 @@
   EXPECT_EQ(Errors[0].Message.FileOffset, 10U);
 }
 
+transformer::ASTEdit noReplacementEdit(transformer::RangeSelector Target) {
+  transformer::ASTEdit E;
+  E.TargetRange = std::move(Target);
+  return E;
+}
+
+TEST(TransformerClangTidyCheckTest, EmptyReplacement) {
+  class DiagOnlyCheck : public TransformerClangTidyCheck {
+  public:
+DiagOnlyCheck(StringRef Name, ClangTidyContext *Context)
+: TransformerClangTidyCheck(
+  makeRule(returnStmt(), edit(noReplacementEdit(node(RootID))),
+   cat("message")),
+  Name, Context) {}
+  };
+  std::string Input = "int h() { return 5; }";
+  std::vector Errors;
+  EXPECT_EQ("int h() { }", test::runCheckOnCode(Input, 
&Errors));
+  EXPECT_EQ(Errors.size(), 1U);
+  EXPECT_EQ(Errors[0].Message.Message, "message");
+  EXPECT_THAT(Errors[0].Message.Ranges, testing::IsEmpty());
+
+  // The diagnostic is anchored to the match, "return 5".
+  EXPECT_EQ(Errors[0].Message.FileOffset, 10U);
+}
+
 TEST(TransformerClangTidyCheckTest, DiagnosticMessageEscaped) {
   class GiveDiagWithPercentSymbol : public TransformerClangTidyCheck {
   public:


Index: clang/lib/Tooling/Transformer/RewriteRule.cpp
===
--- clang/lib/Tooling/Transformer/RewriteRule.cpp
+++ clang/lib/Tooling/Transformer/RewriteRule.cpp
@@ -50,17 +50,21 @@
 // produces a bad range, whereas the latter will simply ignore A.
 if (!EditRange)
   return SmallVector();
-auto Replacement = E.Replacement->eval(Result);
-if (!Replacement)
-  return Replacement.takeError();
-auto Metadata = E.Metadata(Result);
-if (!Metadata)
-  return Metadata.takeError();
 transformer::Edit T;
 T.Kind = E.Kind;
 T.Range = *EditRange;
-T.Replacement = std::move(*Replacement);
-T.Metadata = std::move(*Metadata);
+if (E.Replacement) {
+  auto Replacement = E.Replacement->eval(Result);
+  if (!Replacement)
+return Replacement.takeError();
+  T.Replacement = std::move(*Replacement);
+}
+if (E.Metadata) {
+  auto Metadata = E.Metadata(Result);
+  if (!Metadata)
+return Metadata.takeError();
+  T.Metadata = std::move(*Metadata);
+}
 Edits.push_back(std::move(T));
   }
   return Edits;
Index: clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
===
--- clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
+++ clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
@@ -90,6 +90,32 @@
   EXPECT_EQ(Errors[0].Message.FileOffset, 10U);
 }
 
+transformer::ASTEdit noReplacementEdit(transformer::RangeSelector Target) {
+  transformer::ASTEdit E;
+  E.TargetRange = std::move(Target);
+  return E;
+}
+
+TEST(TransformerClangTidyCheckTest, EmptyReplacement) {
+  class DiagOnlyCheck : public TransformerClangTidyCheck {
+  public:
+

[PATCH] D131464: [test] Make tests pass regardless of gnu++14/gnu++17 default

2022-08-10 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added inline comments.



Comment at: clang/test/AST/ast-dump-openmp-begin-declare-variant_11.c:2
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown -fopenmp -verify=c_mode   
-ast-dump %s   | FileCheck %s --check-prefix=C
-// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fopenmp -verify=cxx_mode 
-ast-dump %s -x c++| FileCheck %s --check-prefix=CXX
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fopenmp -verify=cxx_mode 
-ast-dump %s -x c++ -std=c++14 | FileCheck %s --check-prefix=CXX
 

junaire wrote:
> aaron.ballman wrote:
> > MaskRay wrote:
> > > aaron.ballman wrote:
> > > > I'm not really keen on this sort of change because it loses test 
> > > > coverage for other language standard versions. We usually try to write 
> > > > our tests to be standard version agnostic and only specify a specific 
> > > > language mode only when absolutely necessary, which doesn't seem to be 
> > > > the case for a lot of the tests in this patch (like this one).
> > > I think we can identify such issues (tests which want to test the latest 
> > > mature standard) and fix them post-transition. This way the transition 
> > > patch feels more isolated and can more easily be reverted.
> > > 
> > > Not sure whether @junaire wants to work on this...
> > > I think we can identify such issues (tests which want to test the latest 
> > > mature standard) and fix them post-transition. This way the transition 
> > > patch feels more isolated and can more easily be reverted.
> > 
> > That feels backwards to me, but maybe I'm misunderstanding. If there are 
> > tests that are specifically testing C++14 behavior (that did not carry 
> > forward into C++17 or later) but don't have a language standard specified 
> > on the RUN line, I think we should fix those *before* transitioning the 
> > default language standard version because those are NFC fixes that improve 
> > the test clarity even if we never make the transition. The transition patch 
> > should remain isolated and easily revertible with that approach, but 
> > there's less risk that nobody goes back and fixes the tests post-transition.
> > Not sure whether @junaire wants to work on this...
> I don't think I have enough knowledge and experience to do this work, So I 
> would like to abandon my previous patch to hope you can pick it up!
I'll fix some tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131464

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


[PATCH] D131541: [Sema] Fix friend destructor declarations after D130936

2022-08-10 Thread Roy Jacobson via Phabricator via cfe-commits
royjacobson updated this revision to Diff 451376.
royjacobson added a comment.

Don't regress on invalid (non-dependent) friend destructor declarations.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131541

Files:
  clang/lib/Sema/SemaDecl.cpp
  clang/test/SemaCXX/member-class-11.cpp


Index: clang/test/SemaCXX/member-class-11.cpp
===
--- clang/test/SemaCXX/member-class-11.cpp
+++ clang/test/SemaCXX/member-class-11.cpp
@@ -26,4 +26,35 @@
   ~B(); // expected-error {{expected the class name after '~' to name the 
enclosing class}}
 };
 
+template 
+struct D {
+  friend T::S::~S();
+private:
+  static constexpr int secret = 42;
+};
+
+// FIXME: We should diagnose here.
+template 
+struct E {
+  friend T::S::~V();
+};
+
+struct Q {
+  struct S { ~S(); };
+};
+
+Q::S::~S() {
+  void foo(int);
+  foo(D::secret);
+}
+
+struct X {
+  ~X();
+};
+struct Y;
+
+struct Z {
+  friend X::~Y(); // expected-error {{expected the class name after '~' to 
name the enclosing class}}
+};
+
 }
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -11514,16 +11514,21 @@
 if (CXXConstructorDecl *Constructor = dyn_cast(NewFD)) 
{
   CheckConstructor(Constructor);
 } else if (CXXDestructorDecl *Destructor =
-dyn_cast(NewFD)) {
-  CXXRecordDecl *Record = Destructor->getParent();
-  QualType ClassType = Context.getTypeDeclType(Record);
-
-  DeclarationName Name = Context.DeclarationNames.getCXXDestructorName(
-  Context.getCanonicalType(ClassType));
-  if (NewFD->getDeclName() != Name) {
-Diag(NewFD->getLocation(), diag::err_destructor_name);
-NewFD->setInvalidDecl();
-return Redeclaration;
+   dyn_cast(NewFD)) {
+  // FIXME: We still don't diagnose on this case
+  // template 
+  // struct A { friend T::S::~V(); };
+  if (NewFD->getFriendObjectKind() == Decl::FriendObjectKind::FOK_None ||
+  !NewFD->isDependentContext()) {
+QualType ClassType = Destructor->getThisObjectType();
+
+DeclarationName Name = Context.DeclarationNames.getCXXDestructorName(
+Context.getCanonicalType(ClassType));
+if (NewFD->getDeclName() != Name) {
+  Diag(NewFD->getLocation(), diag::err_destructor_name);
+  NewFD->setInvalidDecl();
+  return Redeclaration;
+}
   }
 } else if (auto *Guide = dyn_cast(NewFD)) {
   if (auto *TD = Guide->getDescribedFunctionTemplate())


Index: clang/test/SemaCXX/member-class-11.cpp
===
--- clang/test/SemaCXX/member-class-11.cpp
+++ clang/test/SemaCXX/member-class-11.cpp
@@ -26,4 +26,35 @@
   ~B(); // expected-error {{expected the class name after '~' to name the enclosing class}}
 };
 
+template 
+struct D {
+  friend T::S::~S();
+private:
+  static constexpr int secret = 42;
+};
+
+// FIXME: We should diagnose here.
+template 
+struct E {
+  friend T::S::~V();
+};
+
+struct Q {
+  struct S { ~S(); };
+};
+
+Q::S::~S() {
+  void foo(int);
+  foo(D::secret);
+}
+
+struct X {
+  ~X();
+};
+struct Y;
+
+struct Z {
+  friend X::~Y(); // expected-error {{expected the class name after '~' to name the enclosing class}}
+};
+
 }
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -11514,16 +11514,21 @@
 if (CXXConstructorDecl *Constructor = dyn_cast(NewFD)) {
   CheckConstructor(Constructor);
 } else if (CXXDestructorDecl *Destructor =
-dyn_cast(NewFD)) {
-  CXXRecordDecl *Record = Destructor->getParent();
-  QualType ClassType = Context.getTypeDeclType(Record);
-
-  DeclarationName Name = Context.DeclarationNames.getCXXDestructorName(
-  Context.getCanonicalType(ClassType));
-  if (NewFD->getDeclName() != Name) {
-Diag(NewFD->getLocation(), diag::err_destructor_name);
-NewFD->setInvalidDecl();
-return Redeclaration;
+   dyn_cast(NewFD)) {
+  // FIXME: We still don't diagnose on this case
+  // template 
+  // struct A { friend T::S::~V(); };
+  if (NewFD->getFriendObjectKind() == Decl::FriendObjectKind::FOK_None ||
+  !NewFD->isDependentContext()) {
+QualType ClassType = Destructor->getThisObjectType();
+
+DeclarationName Name = Context.DeclarationNames.getCXXDestructorName(
+Context.getCanonicalType(ClassType));
+if (NewFD->getDeclName() != Name) {
+  Diag(NewFD->getLocation(), diag::err_destructor_name);
+  NewFD->setInvalidDecl();
+  return Redeclaration;
+}
   }
 } else if (auto *Guide = dyn_cast(NewFD)) {
  

[PATCH] D131541: [Sema] Fix friend destructor declarations after D130936

2022-08-10 Thread Roy Jacobson via Phabricator via cfe-commits
royjacobson added a subscriber: hubert.reinterpretcast.
royjacobson added a comment.

Hi @hubert.reinterpretcast, thanks for the quick catch!

I have posted this initial patch, but it still misses the case

  template 
  struct E {
friend T::S::~V();
  };

Something goes wrong there that I haven't figured out yet. Do you think I 
should land this as-is to fix the master?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131541

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


[PATCH] D131533: [Flang][Driver] Enable PIC in the frontend

2022-08-10 Thread Andrzej Warzynski via Phabricator via cfe-commits
awarzynski added a comment.

Many thanks for implementing this! I've only skimmed through so far, but mostly 
makes sense. Will take a closer look later.

Could you update the summary by adding more detail? What options are enabled 
and whether the semantics from Clang are preserved or not (they should unless 
there is a good reason not to)? It would help if you could list all of them. 
More comments inline.




Comment at: clang/include/clang/Driver/Options.td:5954-5959
+def mrelocation_model : Separate<["-"], "mrelocation-model">,
+  HelpText<"The relocation model to use">, 
Values<"static,pic,ropi,rwpi,ropi-rwpi,dynamic-no-pic">,
+  Flags<[CC1Option, CC1AsOption, FC1Option, NoDriverOption]>,
+  NormalizedValuesScope<"llvm::Reloc">,
+  NormalizedValues<["Static", "PIC_", "ROPI", "RWPI", "ROPI_RWPI", 
"DynamicNoPIC"]>,
+  MarshallingInfoEnum, "PIC_">;

As per comments in Options.td, this is a "Code-gen Option" rather than a 
"Language Option". Could you move it back somewhere near the original [[ 
https://github.com/llvm/llvm-project/blob/e5e93b6130bde96d7e14851e218c5bf055f8a834/clang/include/clang/Driver/Options.td#L5231-L5233
 | comment ]]?

I would also suggest using `let` (there's going to be more options like this):
```
let Flags = [CC1Option, CC1AsOption, FC1Option, NoDriverOption] {

def mrelocation_model : Separate<["-"], "mrelocation-model">,
  HelpText<"The relocation model to use">, 
Values<"static,pic,ropi,rwpi,ropi-rwpi,dynamic-no-pic">,
  NormalizedValuesScope<"llvm::Reloc">,
  NormalizedValues<["Static", "PIC_", "ROPI", "RWPI", "ROPI_RWPI", 
"DynamicNoPIC"]>,
  MarshallingInfoEnum, "PIC_">;

} // let Flags = [CC1Option, CC1AsOption, FC1Option, NoDriverOption]
```



Comment at: clang/include/clang/Driver/Options.td:6320-6325
+def pic_level : Separate<["-"], "pic-level">,
+  HelpText<"Value for __PIC__">,
+  MarshallingInfoInt>;
+def pic_is_pie : Flag<["-"], "pic-is-pie">,
+  HelpText<"File is for a position independent executable">,
+  MarshallingInfoFlag>;

These are code-gen options to me. While originally located under "Language 
Options", I think that it would make more sense to move them near "CodeGen 
Options" instead (e.g. near `mrelocation_model`). @MaskRay any thoughts?



Comment at: clang/lib/Driver/ToolChains/Flang.cpp:120
 
+  // -fPIC/-fPIE and their variants. Similar to clang.
+  llvm::Reloc::Model RelocationModel;

I would skip "Similar to clang" - this applies most of things here.



Comment at: flang/test/Driver/pic-flags.f90:1
 ! Verify that in contrast to Clang, Flang does not default to generating 
position independent executables/code
 

This comment is no longer valid



Comment at: flang/test/Driver/pic-flags.f90:3
 
-! RUN: %flang -### %s --target=aarch64-linux-gnu 2>&1 | FileCheck %s 
--check-prefix=CHECK-NOPIE
-! RUN: %flang -### %s --target=aarch64-linux-gnu -fno-pie 2>&1 | FileCheck %s 
--check-prefix=CHECK-NOPIE
-
-! RUN: %flang -### %s --target=aarch64-linux-gnu -fpie 2>&1 | FileCheck %s 
--check-prefix=CHECK-PIE
-
-! CHECK-NOPIE: "-fc1"
-! CHECk-NOPIE-NOT: "-fpic"
-! CHECK-NOPIE: "{{.*}}ld"
-! CHECK-NOPIE-NOT: "-pie"
-
-! CHECK-PIE: "-fc1"
-!! TODO Once Flang supports `-fpie`, it //should// use -fpic when invoking 
`flang -fc1`. Update the following line once `-fpie` is
-! available.
-! CHECk-PIE-NOT: "-fpic"
-! CHECK-PIE: "{{.*}}ld"
-! CHECK-PIE-NOT: "-pie"
+! RUN: %flang -v -S -emit-llvm -o - %s --target=aarch64-linux-gnu -fno-pie 
2>&1 | FileCheck %s --check-prefix=CHECK-NOPIE
+

Why would you replace `-###` with `-v`? Same for other RUN lines. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131533

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


[PATCH] D131464: [test] Make tests pass regardless of gnu++14/gnu++17 default

2022-08-10 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay updated this revision to Diff 451377.
MaskRay added a comment.

fix some tests in a better way


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131464

Files:
  clang/lib/Basic/LangStandards.cpp
  clang/test/AST/ast-dump-openmp-begin-declare-variant_11.c
  clang/test/AST/ast-dump-openmp-begin-declare-variant_template_3.cpp
  clang/test/AST/ast-dump-undeduced-expr.cpp
  clang/test/AST/sourceranges.cpp
  clang/test/Analysis/blocks.m
  clang/test/Analysis/exploded-graph-rewriter/objects_under_construction.cpp
  clang/test/CXX/basic/basic.stc/basic.stc.dynamic/p2.cpp
  clang/test/CXX/class.access/class.friend/p1.cpp
  clang/test/CXX/dcl.dcl/dcl.spec/dcl.stc/p2.cpp
  clang/test/CXX/except/except.spec/p2-dynamic-types.cpp
  clang/test/CXX/except/except.spec/p9-dynamic.cpp
  clang/test/CXX/stmt.stmt/stmt.select/p3.cpp
  clang/test/CXX/temp/temp.arg/temp.arg.nontype/p1.cpp
  clang/test/CXX/temp/temp.res/temp.local/p3.cpp
  clang/test/CodeGen/typedef_alignment_mismatch_warning.cpp
  clang/test/CodeGenCXX/align-avx-complete-objects.cpp
  clang/test/CodeGenCXX/copy-constructor-elim-2.cpp
  clang/test/CodeGenCXX/debug-info-template-parameter.cpp
  clang/test/CodeGenCXX/debug-info-template-partial-specialization.cpp
  clang/test/CodeGenCXX/exception-spec-decay.cpp
  clang/test/CodeGenCXX/exceptions-cxx-ehsc.cpp
  clang/test/CodeGenCXX/exceptions-no-rtti.cpp
  clang/test/CodeGenCXX/global-init.cpp
  clang/test/CodeGenCXX/no-exceptions.cpp
  clang/test/CodeGenCXX/override-bit-field-layout.cpp
  clang/test/CodeGenCXX/override-layout.cpp
  clang/test/CodeGenCXX/reference-temporary-ms.cpp
  clang/test/CodeGenCXX/rtti-linkage.cpp
  clang/test/Layout/ms-x86-vtordisp.cpp
  clang/test/Modules/update-exception-spec.cpp
  clang/test/OpenMP/declare_mapper_messages.cpp
  clang/test/PCH/cxx-functions.cpp
  clang/test/Parser/cxx-casting.cpp
  clang/test/Parser/cxx-class.cpp
  clang/test/Parser/cxx-template-argument.cpp
  clang/test/Parser/cxx-template-decl.cpp
  clang/test/Parser/cxx1z-nested-namespace-definition.cpp
  clang/test/Sema/ms_class_layout.cpp
  clang/test/SemaCXX/MicrosoftExtensions.cpp
  clang/test/SemaCXX/PR12778.cpp
  clang/test/SemaCXX/altivec.cpp
  clang/test/SemaCXX/bool.cpp
  clang/test/SemaCXX/default2.cpp
  clang/test/SemaCXX/exception-spec-no-exceptions.cpp
  clang/test/SemaCXX/exceptions.cpp
  clang/test/SemaCXX/expressions.cpp
  clang/test/SemaCXX/inline.cpp
  clang/test/SemaCXX/libstdcxx_is_pod_hack.cpp
  clang/test/SemaCXX/linkage2.cpp
  clang/test/SemaCXX/member-pointer.cpp
  clang/test/SemaCXX/missing-namespace-qualifier-typo-corrections.cpp
  clang/test/SemaCXX/static-data-member.cpp
  clang/test/SemaCXX/type-definition-in-specifier.cpp
  clang/test/SemaCXX/user-defined-conversions.cpp
  clang/test/SemaCXX/warn-new-overaligned-3.cpp
  clang/test/SemaCXX/warn-new-overaligned.cpp
  clang/test/SemaCXX/writable-strings-deprecated.cpp
  clang/test/SemaSYCL/zero-length-arrays.cpp
  clang/test/SemaTemplate/class-template-id.cpp
  clang/test/SemaTemplate/constructor-template.cpp
  clang/test/SemaTemplate/explicit-instantiation.cpp
  clang/test/SemaTemplate/instantiate-exception-spec.cpp
  clang/test/SemaTemplate/instantiate-non-dependent-types.cpp
  clang/test/SemaTemplate/instantiation-default-2.cpp
  clang/test/SemaTemplate/temp_arg.cpp
  clang/test/SemaTemplate/temp_arg_template.cpp
  clang/test/SemaTemplate/typename-specifier-3.cpp
  clang/unittests/AST/ASTTraverserTest.cpp

Index: clang/unittests/AST/ASTTraverserTest.cpp
===
--- clang/unittests/AST/ASTTraverserTest.cpp
+++ clang/unittests/AST/ASTTraverserTest.cpp
@@ -280,7 +280,7 @@
 
 TEST(Traverse, IgnoreUnlessSpelledInSourceVars) {
 
-  auto AST = buildASTFromCode(R"cpp(
+  auto AST = buildASTFromCodeWithArgs(R"cpp(
 
 struct String
 {
@@ -346,7 +346,7 @@
   }
 }
 
-)cpp");
+)cpp", {"-std=c++14"});
 
   {
 auto FN =
@@ -715,7 +715,7 @@
 
 TEST(Traverse, IgnoreUnlessSpelledInSourceReturns) {
 
-  auto AST = buildASTFromCode(R"cpp(
+  auto AST = buildASTFromCodeWithArgs(R"cpp(
 
 struct A
 {
@@ -784,7 +784,7 @@
   return c;
 }
 
-)cpp");
+)cpp", {"-std=c++14"});
 
   auto getFunctionNode = [&AST](const std::string &name) {
 auto BN = ast_matchers::match(functionDecl(hasName(name)).bind("fn"),
Index: clang/test/SemaTemplate/typename-specifier-3.cpp
===
--- clang/test/SemaTemplate/typename-specifier-3.cpp
+++ clang/test/SemaTemplate/typename-specifier-3.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++14 %s
 
 // PR4364
 template struct a { // expected-note {{here}}
Index: clang/test/SemaTemplate/temp_arg_template.cpp
===
--- clang/test/SemaTemplate/temp_arg_template.cpp
+++ clang/test/SemaTemplate/temp_arg

[PATCH] D131547: [Clang][AArch64] Use generic extract/insert vector for svget/svset/svcreate tuples

2022-08-10 Thread Simon Pilgrim via Phabricator via cfe-commits
RKSimon added a comment.

Are you intending to AutoUpgrade the existing intrinsics in IR?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131547

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


[PATCH] D131526: [OMPIRBuilder] Add support for safelen clause

2022-08-10 Thread Dominik Adamski via Phabricator via cfe-commits
domada added inline comments.



Comment at: clang/lib/CodeGen/CGStmtOpenMP.cpp:2598
   for (OMPClause *C : S.clauses()) {
 // Currently only simdlen clause is supported
+if (!(isa(C) || isa(C)))

Could you update this comment?



Comment at: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:3045
+  if (!(Simdlen == nullptr && Safelen == nullptr)) {
+ConstantInt *VectorizeWidth = Simdlen == nullptr ? Safelen : Simdlen;
 addLoopMetadata(

Could you add comment which describes how simdlen and safelen clauses work?

BTW. Have you checked invalid test case where safelen < simdlen? 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131526

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


[PATCH] D131438: [clang][dataflow] Analyze constructor bodies

2022-08-10 Thread Stanislav Gatev via Phabricator via cfe-commits
sgatev accepted this revision.
sgatev added inline comments.



Comment at: clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h:379
+  /// Shared implementation of `pushCall` overloads.
+  void pushCallInternal(const FunctionDecl *FuncDecl,
+ArrayRef Args);

Let's add a note that unlike `pushCall`, this member is invoked on the 
environment of the callee.



Comment at: clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h:380
+  void pushCallInternal(const FunctionDecl *FuncDecl,
+ArrayRef Args);
+

`#include "llvm/ADT/ArrayRef.h"`



Comment at: clang/lib/Analysis/FlowSensitive/Transfer.cpp:667-670
+const ControlFlowContext *CFCtx = Env.getControlFlowContext(F);
+
+if (!CFCtx)
+  return;




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131438

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


[PATCH] D131547: [Clang][AArch64] Use generic extract/insert vector for svget/svset/svcreate tuples

2022-08-10 Thread Nuno Lopes via Phabricator via cfe-commits
nlopes added inline comments.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:9114
+  unsigned int MinElts = SrcTy->getElementCount().getKnownMinValue();
+  Value *Call = llvm::UndefValue::get(VTy);
+  for (unsigned int I = 0; I < Ops.size(); I++) {

Please use PoisonValue here


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131547

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


[PATCH] D131225: Driver: Refactor and support per target dirs in baremetal

2022-08-10 Thread Sergei Barannikov via Phabricator via cfe-commits
barannikov88 added a comment.

Still LGTM




Comment at: clang/lib/Driver/ToolChains/BareMetal.h:2
+//===--- BareMetal.h - Bare Metal Tool and ToolChain -*- C++
+//-*-===//
 //

Line overflowed


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131225

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


[PATCH] D131448: Introduce iterator sentinel to make graph traversal implementation more efficient and cleaner

2022-08-10 Thread Yury Gribov via Phabricator via cfe-commits
ygribov added a comment.

LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131448

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


[PATCH] D126907: Deferred Concept Instantiation Implementation Take 2

2022-08-10 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu added a comment.

In D126907#3710656 , @erichkeane 
wrote:

> Ok, fixed the test failure in clang, AND it managed to fix 
> all the failures in libcxx!
>
> HOWEVER, it appears that libcxx/test/libcxx/modules_include.sh.cpp
> is now hanging?
>
> I don't know much about the modules implementation (perhaps someone
> like @ChuanqiXu  can help out?), so I'm at least somewhat stuck until
> I can figure out how to get it to give me more info.

I may not be able to look into the details recently. What's the error message 
from the modules?


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

https://reviews.llvm.org/D126907

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


[PATCH] D131553: [analyzer] exploded-graph-rewriter: Fix python3 string encoding issues

2022-08-10 Thread Balázs Benics via Phabricator via cfe-commits
steakhal created this revision.
steakhal added reviewers: NoQ, martong, ASDenysPetrov.
Herald added subscribers: manas, dkrupp, donat.nagy, Szelethus, 
mikhail.ramalho, a.sidorin, rnkovacs, szepet, baloghadamsoftware, xazax.hun.
Herald added a project: All.
steakhal requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This encapsulates 3 changes:

- `DotDumpVisitor` now aggregates strings instead of *bytes* for both

`python2` and `python3`. This difference caused crashes when it tried
to write out the content as *strings*, similarly described at D71746 
.

- `graphviz.pipe()` expects the input in *bytes* instead of unicode

strings. And it results in *bytes*. Due to string concatenations and
similar operations, I'm using unicode string as the default, and
converting to *bytes* on demand.

- `write_temp_file()` now appends the `egraph-` prefix and more

importantly, it will create the temp file in the **current working
directory** instead of in the *temp*. This change makes `Firefox` be
able to open the file even if the `security.sandbox.content.level` is
set to the (default) most restricting `4`.
See https://support.mozilla.org/si/questions/1259285

An artifact of the bad byte handling was previously in the `HTML`
produced by the script that it displayed the `b'` string at the top left
corner. Now it won't anymore :)

I've tested that the following command works on `Ubuntu 22.04`:

  exploded-graph-rewriter my-egraph.dot

Both `python2` and `python3` works as expected.

PS: I'm not adding tests, as the current test infra does not support
testing HTML outputs for this script.
Check the `clang/test/Analysis/exploded-graph-rewriter/lit.local.cfg`.
We always pass the `--dump-dot-only` flag to the script.
Along with that, the default invocation will not only create this HTML
report but also try to open it. In addition to this, I'm not sure if the
buildbots have `graphviz` installed and also if this package is installed
on `pip`.
Unless we change some of these, we cannot test this change.
Given that D71746  had no tests, I'm not too 
worried about this either.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D131553

Files:
  clang/utils/analyzer/exploded-graph-rewriter.py


Index: clang/utils/analyzer/exploded-graph-rewriter.py
===
--- clang/utils/analyzer/exploded-graph-rewriter.py
+++ clang/utils/analyzer/exploded-graph-rewriter.py
@@ -18,7 +18,6 @@
 import logging
 import os
 import re
-import sys
 
 
 #===---===#
@@ -423,10 +422,7 @@
 
 def output(self):
 assert not self._dump_dot_only
-if sys.version_info[0] > 2 and sys.version_info[1] >= 5:
-return ''.join(self._output).encode()
-else:
-return ''.join(self._output)
+return ''.join(self._output)
 
 def _dump(self, s):
 s = s.replace('&', '&') \
@@ -854,12 +850,12 @@
 import sys
 import tempfile
 
-def write_temp_file(suffix, data):
-fd, filename = tempfile.mkstemp(suffix=suffix)
+def write_temp_file(suffix, prefix, data):
+fd, filename = tempfile.mkstemp(suffix, prefix, '.', True)
 print('Writing "%s"...' % filename)
 with os.fdopen(fd, 'w') as fp:
 fp.write(data)
-print('Done! Please remember to remove the file.')
+print('Done!')
 return filename
 
 try:
@@ -873,13 +869,13 @@
 print('You may also convert DOT to SVG manually via')
 print('  $ dot -Tsvg input.dot -o output.svg')
 print()
-write_temp_file('.dot', self.output())
+write_temp_file('.dot', 'egraph-', self.output())
 return
 
-svg = graphviz.pipe('dot', 'svg', self.output())
+svg = graphviz.pipe('dot', 'svg', self.output().encode()).decode()
 
 filename = write_temp_file(
-'.html', '%s' % (
+'.html', 'egraph-', '%s' % (
  '#1a1a1a' if self._dark_mode else 'white', svg))
 if sys.platform == 'win32':
 os.startfile(filename)


Index: clang/utils/analyzer/exploded-graph-rewriter.py
===
--- clang/utils/analyzer/exploded-graph-rewriter.py
+++ clang/utils/analyzer/exploded-graph-rewriter.py
@@ -18,7 +18,6 @@
 import logging
 import os
 import re
-import sys
 
 
 #===---===#
@@ -423,10 +422,7 @@
 
 def output(self):
 assert not self._dump_dot_only
-if sys.version_info[0] > 2 and sys.version_info[1] >= 5:
-  

[PATCH] D118996: [clang-tidy] Support C++14 in bugprone-signal-handler.

2022-08-10 Thread Balázs Kéri via Phabricator via cfe-commits
This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGa772f775a2ba: [clang-tidy] Support C++14 in 
bugprone-signal-handler. (authored by balazske).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118996

Files:
  clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.h
  clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/bugprone/signal-handler.rst
  clang-tools-extra/docs/clang-tidy/checks/cert/msc54-cpp.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/checkers/Inputs/Headers/signal.h
  
clang-tools-extra/test/clang-tidy/checkers/bugprone/Inputs/signal-handler/stdcpp.h
  clang-tools-extra/test/clang-tidy/checkers/bugprone/signal-handler.c
  clang-tools-extra/test/clang-tidy/checkers/bugprone/signal-handler.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone/signal-handler.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone/signal-handler.cpp
@@ -0,0 +1,228 @@
+// RUN: %check_clang_tidy -std=c++14 %s bugprone-signal-handler %t -- -- -isystem %clang_tidy_headers -isystem %S/Inputs/signal-handler
+
+#include "stdcpp.h"
+#include "stdio.h"
+
+// Functions called "signal" that are different from the system version.
+typedef void (*callback_t)(int);
+void signal(int, callback_t, int);
+namespace ns {
+void signal(int, callback_t);
+}
+
+extern "C" void handler_unsafe(int) {
+  printf("xxx");
+}
+
+extern "C" void handler_unsafe_1(int) {
+  printf("xxx");
+}
+
+namespace test_invalid_handler {
+
+void handler_non_extern_c(int) {
+  printf("xxx");
+}
+
+struct A {
+  static void handler_member(int) {
+printf("xxx");
+  }
+};
+
+void test() {
+  std::signal(SIGINT, handler_unsafe_1);
+  // CHECK-MESSAGES: :[[@LINE-17]]:3: warning: standard function 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+  // CHECK-MESSAGES: :[[@LINE-2]]:23: note: function 'handler_unsafe_1' registered here as signal handler
+
+  std::signal(SIGINT, handler_non_extern_c);
+  // CHECK-MESSAGES: :[[@LINE-1]]:23: warning: functions without C linkage are not allowed as signal handler (until C++17) [bugprone-signal-handler]
+  std::signal(SIGINT, A::handler_member);
+  // CHECK-MESSAGES: :[[@LINE-1]]:23: warning: functions without C linkage are not allowed as signal handler (until C++17) [bugprone-signal-handler]
+  std::signal(SIGINT, [](int) { printf("xxx"); });
+  // CHECK-MESSAGES: :[[@LINE-1]]:23: warning: lambda function is not allowed as signal handler (until C++17) [bugprone-signal-handler]
+
+  // This case is (deliberately) not found by the checker.
+  std::signal(SIGINT, [](int) -> callback_t { return &handler_unsafe; }(1));
+}
+
+} // namespace test_invalid_handler
+
+namespace test_non_standard_signal_call {
+
+struct Signal {
+  static void signal(int, callback_t);
+};
+
+void test() {
+  // No diagnostics here. All these signal calls differ from the standard system one.
+  signal(SIGINT, handler_unsafe, 1);
+  ns::signal(SIGINT, handler_unsafe);
+  Signal::signal(SIGINT, handler_unsafe);
+  system_other::signal(SIGINT, handler_unsafe);
+}
+
+} // namespace test_non_standard_signal_call
+
+namespace test_cpp_construct_in_handler {
+
+struct Struct {
+  virtual ~Struct() {}
+  void f1();
+  int *begin();
+  int *end();
+  static void f2();
+};
+struct Derived : public Struct {
+};
+
+struct X {
+  X(int, float);
+};
+
+Struct *S_Global;
+const Struct *S_GlobalConst;
+
+void f_non_extern_c() {
+}
+
+void f_default_arg(int P1 = 0) {
+}
+
+extern "C" void handler_cpp(int) {
+  using namespace ::test_cpp_construct_in_handler;
+
+  // These calls are not found as problems.
+  // (Called functions are not analyzed if the current function has already
+  // other problems.)
+  f_non_extern_c();
+  Struct::f2();
+  // 'auto' is not disallowed
+  auto Auto = 28u;
+
+  Struct S;
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: C++-only construct is not allowed in signal handler (until C++17) [bugprone-signal-handler]
+  // CHECK-MESSAGES: :[[@LINE-2]]:10: remark: internally, the statement is parsed as a 'CXXConstructExpr'
+  // CHECK-MESSAGES: :198:23: note: function 'handler_cpp' registered here as signal handler
+  S_Global->f1();
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: C++-only construct is not allowed in signal handler (until C++17) [bugprone-signal-handler]
+  // CHECK-MESSAGES: :[[@LINE-2]]:3: remark: internally, the statement is parsed as a 'CXXMemberCallExpr'
+  // CHECK-MESSAGES: :198:23: note: function 'han

[clang-tools-extra] a772f77 - [clang-tidy] Support C++14 in bugprone-signal-handler.

2022-08-10 Thread Balázs Kéri via cfe-commits

Author: Balázs Kéri
Date: 2022-08-10T12:00:16+02:00
New Revision: a772f775a2ba401e95a0bbe73deb6300f1dc12c0

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

LOG: [clang-tidy] Support C++14 in bugprone-signal-handler.

Check `bugprone-signal-handler` is improved to check for
C++-specific constructs in signal handlers. This check is
valid until C++17.

Reviewed By: whisperity

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

Added: 
clang-tools-extra/docs/clang-tidy/checks/cert/msc54-cpp.rst

clang-tools-extra/test/clang-tidy/checkers/bugprone/Inputs/signal-handler/stdcpp.h
clang-tools-extra/test/clang-tidy/checkers/bugprone/signal-handler.cpp

Modified: 
clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.h
clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp
clang-tools-extra/docs/ReleaseNotes.rst
clang-tools-extra/docs/clang-tidy/checks/bugprone/signal-handler.rst
clang-tools-extra/docs/clang-tidy/checks/list.rst
clang-tools-extra/test/clang-tidy/checkers/Inputs/Headers/signal.h
clang-tools-extra/test/clang-tidy/checkers/bugprone/signal-handler.c

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp 
b/clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
index 132fbf85c1fe6..fc91d79f26a65 100644
--- a/clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
+++ b/clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
@@ -22,6 +22,7 @@ constexpr llvm::StringLiteral MinimalConformingFunctions[] = {
 // mentioned POSIX specification was not updated after 'quick_exit' appeared
 // in the C11 standard.
 // Also, we want to keep the "minimal set" a subset of the "POSIX set".
+// The list is repeated in bugprone-signal-handler.rst and should be kept up 
to date.
 constexpr llvm::StringLiteral POSIXConformingFunctions[] = {
 "_Exit",
 "_exit",
@@ -277,6 +278,25 @@ bool isStandardFunction(const FunctionDecl *FD) {
   FD->getCanonicalDecl()->getLocation());
 }
 
+/// Check if a statement is "C++-only".
+/// This includes all statements that have a class name with "CXX" prefix
+/// and every other statement that is declared in file ExprCXX.h.
+bool isCXXOnlyStmt(const Stmt *S) {
+  StringRef Name = S->getStmtClassName();
+  if (Name.startswith("CXX"))
+return true;
+  // Check for all other class names in ExprCXX.h that have no 'CXX' prefix.
+  return isa(S);
+}
+
 /// Given a call graph node of a \p Caller function and a \p Callee that is
 /// called from \p Caller, get a \c CallExpr of the corresponding function 
call.
 /// It is unspecified which call is found if multiple calls exist, but the 
order
@@ -291,6 +311,18 @@ Expr *findCallExpr(const CallGraphNode *Caller, const 
CallGraphNode *Callee) {
   return FoundCallee->CallExpr;
 }
 
+SourceRange getSourceRangeOfStmt(const Stmt *S, ASTContext &Ctx) {
+  ParentMapContext &PM = Ctx.getParentMapContext();
+  DynTypedNode P = DynTypedNode::create(*S);
+  while (P.getSourceRange().isInvalid()) {
+DynTypedNodeList PL = PM.getParents(P);
+if (PL.size() != 1)
+  return {};
+P = PL[0];
+  }
+  return P.getSourceRange();
+}
+
 } // namespace
 
 AST_MATCHER(FunctionDecl, isStandardFunction) {
@@ -317,11 +349,7 @@ void 
SignalHandlerCheck::storeOptions(ClangTidyOptions::OptionMap &Opts) {
 
 bool SignalHandlerCheck::isLanguageVersionSupported(
 const LangOptions &LangOpts) const {
-  // FIXME: Make the checker useful on C++ code.
-  if (LangOpts.CPlusPlus)
-return false;
-
-  return true;
+  return !LangOpts.CPlusPlus17;
 }
 
 void SignalHandlerCheck::registerMatchers(MatchFinder *Finder) {
@@ -332,13 +360,23 @@ void SignalHandlerCheck::registerMatchers(MatchFinder 
*Finder) {
   unless(isExpandedFromMacro("SIG_IGN")),
   unless(isExpandedFromMacro("SIG_DFL")))
   .bind("handler_expr");
-  Finder->addMatcher(
-  callExpr(callee(SignalFunction), hasArgument(1, HandlerExpr))
-  .bind("register_call"),
-  this);
+  auto HandlerLambda = cxxMemberCallExpr(
+  on(expr(ignoringParenImpCasts(lambdaExpr().bind("handler_lambda");
+  Finder->addMatcher(callExpr(callee(SignalFunction),
+  hasArgument(1, anyOf(HandlerExpr, 
HandlerLambda)))
+ .bind("register_call"),
+ this);
 }
 
 void SignalHandlerCheck::check(const MatchFinder::MatchResult &Result) {
+  if (const auto *HandlerLambda =
+  Result.Nodes.getNodeAs("handler_lambda")) {
+diag(HandlerLambda->getBeginLoc(),
+ "lambda function is not allowed as signal handler (until C++17)")
+<< HandlerLambda->getSourceRange();
+return;
+  }
+
   co

[PATCH] D131555: [Clang] Propagate const context info when emitting compound literal

2022-08-10 Thread Ties Stuij via Phabricator via cfe-commits
stuij created this revision.
Herald added a project: All.
stuij requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This patch fixes a crash when trying to emit a constant compound literal.

For C++ Clang evaluates either casts or binary operations at translation time,
but doesn't pass on the InConstantContext information that was inferred when
parsing the statement.  Because of this, strict FP evaluation (-ftrapping-math)
which should be in effect yet, then causes checkFloatingpointResult to return
false, which in tryEmitGlobalCompoundLiteral will trigger an assert that the
compound literal wasn't constant.

The discussion here around 'manifestly constant evaluated contexts' was very
helpful to me when trying to understand what LLVM's position is on what
evaluation context should be in effect, together with the explanatory text in
that patch itself:
https://reviews.llvm.org/D87528


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D131555

Files:
  clang/lib/CodeGen/CGExprConstant.cpp
  clang/lib/CodeGen/ConstantEmitter.h
  clang/test/CodeGen/const-init.c


Index: clang/test/CodeGen/const-init.c
===
--- clang/test/CodeGen/const-init.c
+++ clang/test/CodeGen/const-init.c
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -no-opaque-pointers -triple i386-pc-linux-gnu 
-ffreestanding -Wno-pointer-to-int-cast -Wno-int-conversion -emit-llvm -o - %s 
| FileCheck %s
+// RUN: %clang_cc1 -no-opaque-pointers -triple i386-pc-linux-gnu 
-ffreestanding -Wno-pointer-to-int-cast -Wno-int-conversion 
-ffp-exception-behavior=strict -emit-llvm -o - %s | FileCheck %s
 
 #include 
 
@@ -181,3 +181,7 @@
 #pragma pack()
   // CHECK: @g31.a = internal global %struct.anon.2 { i16 23122, i32 
-12312731, i16 -312 }, align 4
 }
+
+struct { const float *floats; } compoundliteral = {
+  (float[1]) { 0.1, },
+};
Index: clang/lib/CodeGen/ConstantEmitter.h
===
--- clang/lib/CodeGen/ConstantEmitter.h
+++ clang/lib/CodeGen/ConstantEmitter.h
@@ -67,6 +67,9 @@
 return Abstract;
   }
 
+  bool isInConstantContext() const { return InConstantContext; }
+  void setInConstantContext(bool var) { InConstantContext = var; }
+
   /// Try to emit the initiaizer of the given declaration as an abstract
   /// constant.  If this succeeds, the emission must be finalized.
   llvm::Constant *tryEmitForInitializer(const VarDecl &D);
Index: clang/lib/CodeGen/CGExprConstant.cpp
===
--- clang/lib/CodeGen/CGExprConstant.cpp
+++ clang/lib/CodeGen/CGExprConstant.cpp
@@ -913,17 +913,15 @@
 // ConstExprEmitter
 
//===--===//
 
-static ConstantAddress tryEmitGlobalCompoundLiteral(CodeGenModule &CGM,
-CodeGenFunction *CGF,
+static ConstantAddress tryEmitGlobalCompoundLiteral(ConstantEmitter &emitter,
   const CompoundLiteralExpr *E) {
+  CodeGenModule &CGM = emitter.CGM;
   CharUnits Align = CGM.getContext().getTypeAlignInChars(E->getType());
   if (llvm::GlobalVariable *Addr =
   CGM.getAddrOfConstantCompoundLiteralIfEmitted(E))
 return ConstantAddress(Addr, Addr->getValueType(), Align);
 
   LangAS addressSpace = E->getType().getAddressSpace();
-
-  ConstantEmitter emitter(CGM, CGF);
   llvm::Constant *C = emitter.tryEmitForInitializer(E->getInitializer(),
 addressSpace, 
E->getType());
   if (!C) {
@@ -1970,7 +1968,9 @@
 
 ConstantLValue
 ConstantLValueEmitter::VisitCompoundLiteralExpr(const CompoundLiteralExpr *E) {
-  return tryEmitGlobalCompoundLiteral(CGM, Emitter.CGF, E);
+  ConstantEmitter CompoundLiteralEmitter(CGM, Emitter.CGF);
+  CompoundLiteralEmitter.setInConstantContext(Emitter.isInConstantContext());
+  return tryEmitGlobalCompoundLiteral(CompoundLiteralEmitter, E);
 }
 
 ConstantLValue
@@ -2214,7 +2214,8 @@
 ConstantAddress
 CodeGenModule::GetAddrOfConstantCompoundLiteral(const CompoundLiteralExpr *E) {
   assert(E->isFileScope() && "not a file-scope compound literal expr");
-  return tryEmitGlobalCompoundLiteral(*this, nullptr, E);
+  ConstantEmitter emitter(*this, nullptr);
+  return tryEmitGlobalCompoundLiteral(emitter, E);
 }
 
 llvm::Constant *


Index: clang/test/CodeGen/const-init.c
===
--- clang/test/CodeGen/const-init.c
+++ clang/test/CodeGen/const-init.c
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -no-opaque-pointers -triple i386-pc-linux-gnu -ffreestanding -Wno-pointer-to-int-cast -Wno-int-conversion -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -no-opaque-pointers -triple i386-pc-linux-gnu -ffreestanding -Wno-pointer-to-int-cast -Wno-int-conversion -ffp-exception-behavior=stric

[PATCH] D128861: [clang-tidy] add cppcoreguidelines-symmetric-binary-operator

2022-08-10 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/D128861/new/

https://reviews.llvm.org/D128861

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


[PATCH] D131479: Handle explicitly defaulted consteval special members.

2022-08-10 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov added a comment.

Should we follow suggestion from CWG Issue 2602 
 to fix this 
instead?
I think the trick is to keep the constructor consteval, but complain when 
processing its call, e.g. somewhere around `HandleConstructorCall` in 
`ExprConstant.cpp`?




Comment at: clang/lib/Sema/SemaDeclCXX.cpp:7207
+Sema::InheritedConstructorInfo *Inherited = nullptr,
+CXXMethodDecl *SpecialMemberDecl = nullptr) {
   if (!S.getLangOpts().CPlusPlus11)

The function attempts to check whether the `implicitly` defined member would be 
`constexpr`, which should not depend on what is written in the expliclitly 
defaulted declaration.

So the check should definitely be performed somewhere outside this function.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131479

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


[PATCH] D131555: [Clang] Propagate const context info when emitting compound literal

2022-08-10 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

The clang code change looks reasonable to me, but I'm not the most expert in 
that area.

The intended result certainly seems sensible, because the C90-compatible 
version of that code //without// a constant literal is happy to do double→float 
conversion at compile time without complaining about side effects:

  static const float separate_array[1] = { 0.1, };
  struct { const float *floats; } without_compound_literal = { separate_array };

and so it makes sense that the version with a compound literal should be 
treated no differently.

Nit in the commit message:

> which should be in effect yet

Surely "which //shouldn't// be in effect yet"?




Comment at: clang/test/CodeGen/const-init.c:1
-// RUN: %clang_cc1 -no-opaque-pointers -triple i386-pc-linux-gnu 
-ffreestanding -Wno-pointer-to-int-cast -Wno-int-conversion -emit-llvm -o - %s 
| FileCheck %s
+// RUN: %clang_cc1 -no-opaque-pointers -triple i386-pc-linux-gnu 
-ffreestanding -Wno-pointer-to-int-cast -Wno-int-conversion 
-ffp-exception-behavior=strict -emit-llvm -o - %s | FileCheck %s
 

I think some kind of a comment would be useful saying what this option is doing 
there -- at least, which one of the tests further down the file it's supposed 
to apply to. Otherwise I could easily imagine someone throwing it out again, 
and since the test would pass anyway, not noticing that it's no longer testing 
what it's meant to test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131555

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


[PATCH] D131423: [clang] fix frontend crash when evaluating type trait

2022-08-10 Thread YingChi Long via Phabricator via cfe-commits
inclyc added a comment.

@aaron.ballman @shafik  (Help wanted). These type traits will not cause clang 
to crash if current patch applied, but the `bool x` in that test case will 
evaluate to `false`.  I think the problem behind the github issue is that we 
don't check the number of arguments for builtin type trait like 
`__is_constructible`

I wanted to ask what is our expected behavior for this, give an error like 
using `std::is_constructible` or just consider `__is_constructible` should 
always have a bool value? Should we report a warning but compile translation 
unit, or report an error and terminate?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131423

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


[clang] 286d59e - [clang][AArch64][SVE] Add unary +/- operators for SVE types

2022-08-10 Thread David Truby via cfe-commits

Author: David Truby
Date: 2022-08-10T10:32:43Z
New Revision: 286d59ef6f7118c8a0600f3d281593700528a5d3

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

LOG: [clang][AArch64][SVE] Add unary +/- operators for SVE types

This patch enables the unary promotion and negation operators on
SVE types.

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

Added: 


Modified: 
clang/lib/Sema/SemaExpr.cpp
clang/test/CodeGen/aarch64-sve-vector-arith-ops.c
clang/test/Sema/sizeless-1.c
clang/test/SemaCXX/sizeless-1.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaExpr.cpp b/clang/lib/Sema/SemaExpr.cpp
index 9b686b8ff2a30..03f5ec9848e1f 100644
--- a/clang/lib/Sema/SemaExpr.cpp
+++ b/clang/lib/Sema/SemaExpr.cpp
@@ -15596,6 +15596,8 @@ ExprResult Sema::CreateBuiltinUnaryOp(SourceLocation 
OpLoc,
   resultType->castAs()->getVectorKind() !=
   VectorType::AltiVecBool))
   break;
+else if (resultType->isVLSTBuiltinType()) // SVE vectors allow + and -
+  break;
 else if (getLangOpts().CPlusPlus && // C++ [expr.unary.op]p6
  Opc == UO_Plus &&
  resultType->isPointerType())

diff  --git a/clang/test/CodeGen/aarch64-sve-vector-arith-ops.c 
b/clang/test/CodeGen/aarch64-sve-vector-arith-ops.c
index c57c476032025..d7c79d7a44220 100644
--- a/clang/test/CodeGen/aarch64-sve-vector-arith-ops.c
+++ b/clang/test/CodeGen/aarch64-sve-vector-arith-ops.c
@@ -1650,3 +1650,143 @@ svuint32_t rem_scalar_u32(svuint32_t a, uint32_t b) {
 svuint64_t rem_scalar_u64(svuint64_t a, uint64_t b) {
   return a % b;
 }
+
+// UNARY PROMOTION
+
+// CHECK-LABEL: @prom_i8(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:ret  [[A:%.*]]
+//
+svint8_t prom_i8(svint8_t a) {
+  return +a;
+}
+
+// CHECK-LABEL: @prom_i16(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:ret  [[A:%.*]]
+//
+svint16_t prom_i16(svint16_t a) {
+  return +a;
+}
+
+// CHECK-LABEL: @prom_i32(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:ret  [[A:%.*]]
+//
+svint32_t prom_i32(svint32_t a) {
+  return +a;
+}
+
+// CHECK-LABEL: @prom_i64(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:ret  [[A:%.*]]
+//
+svint64_t prom_i64(svint64_t a) {
+  return +a;
+}
+
+// CHECK-LABEL: @prom_u8(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:ret  [[A:%.*]]
+//
+svuint8_t prom_u8(svuint8_t a) {
+  return +a;
+}
+
+// CHECK-LABEL: @prom_u16(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:ret  [[A:%.*]]
+//
+svuint16_t prom_u16(svuint16_t a) {
+  return +a;
+}
+
+// CHECK-LABEL: @prom_u32(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:ret  [[A:%.*]]
+//
+svuint32_t prom_u32(svuint32_t a) {
+  return +a;
+}
+
+// CHECK-LABEL: @prom_u64(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:ret  [[A:%.*]]
+//
+svuint64_t prom_u64(svuint64_t a) {
+  return +a;
+}
+
+// UNARY NEGATION
+
+// CHECK-LABEL: @neg_i8(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[SUB:%.*]] = sub  zeroinitializer, 
[[A:%.*]]
+// CHECK-NEXT:ret  [[SUB]]
+//
+svint8_t neg_i8(svint8_t a) {
+  return -a;
+}
+
+// CHECK-LABEL: @neg_i16(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[SUB:%.*]] = sub  zeroinitializer, 
[[A:%.*]]
+// CHECK-NEXT:ret  [[SUB]]
+//
+svint16_t neg_i16(svint16_t a) {
+  return -a;
+}
+
+// CHECK-LABEL: @neg_i32(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[SUB:%.*]] = sub  zeroinitializer, 
[[A:%.*]]
+// CHECK-NEXT:ret  [[SUB]]
+//
+svint32_t neg_i32(svint32_t a) {
+  return -a;
+}
+
+// CHECK-LABEL: @neg_i64(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[SUB:%.*]] = sub  zeroinitializer, 
[[A:%.*]]
+// CHECK-NEXT:ret  [[SUB]]
+//
+svint64_t neg_i64(svint64_t a) {
+  return -a;
+}
+
+// CHECK-LABEL: @neg_u8(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[SUB:%.*]] = sub  zeroinitializer, 
[[A:%.*]]
+// CHECK-NEXT:ret  [[SUB]]
+//
+svuint8_t neg_u8(svuint8_t a) {
+  return -a;
+}
+
+// CHECK-LABEL: @neg_u16(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[SUB:%.*]] = sub  zeroinitializer, 
[[A:%.*]]
+// CHECK-NEXT:ret  [[SUB]]
+//
+svuint16_t neg_u16(svuint16_t a) {
+  return -a;
+}
+
+// CHECK-LABEL: @neg_u32(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[SUB:%.*]] = sub  zeroinitializer, 
[[A:%.*]]
+// CHECK-NEXT:ret  [[SUB]]
+//
+svuint32_t neg_u32(svuint32_t a) {
+  return -a;
+}
+
+// CHECK-LABEL: @neg_u64(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[SUB:%.*]] = sub  zeroinitializer, 
[[A:%.*]]
+// CHECK-NEXT:ret  [[SUB]]
+//
+svuint64_t neg_u64(svuint64_t a) {
+  return -a;
+}

diff  --git a/clang/test/Sema/sizeless-1.c b/clang/test/Sema/sizeless-1.c
index 5e7e3be772e8c..64af214d206b9 100644
--- a/clang/test/Sema/sizeless-1.c
+++ b/clang/test/Sema/sizeless-1.c
@@ -187,10 +187,8 @@ void func(int sel) {
   global_int8_ptr -= 1;  // expected-error {{arithmetic on a 
pointer to sizeless type}}
   global_int8_pt

[PATCH] D130984: [clang][AArch64][SVE] Add unary +/- operators for SVE types

2022-08-10 Thread David Truby 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 rG286d59ef6f71: [clang][AArch64][SVE] Add unary +/- operators 
for SVE types (authored by DavidTruby).

Changed prior to commit:
  https://reviews.llvm.org/D130984?vs=449264&id=451409#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130984

Files:
  clang/lib/Sema/SemaExpr.cpp
  clang/test/CodeGen/aarch64-sve-vector-arith-ops.c
  clang/test/Sema/sizeless-1.c
  clang/test/SemaCXX/sizeless-1.cpp

Index: clang/test/SemaCXX/sizeless-1.cpp
===
--- clang/test/SemaCXX/sizeless-1.cpp
+++ clang/test/SemaCXX/sizeless-1.cpp
@@ -199,10 +199,8 @@
   global_int8_ptr -= 1;  // expected-error {{arithmetic on a pointer to sizeless type}}
   global_int8_ptr - global_int8_ptr; // expected-error {{arithmetic on a pointer to sizeless type}}
 
-  +init_int8;   // expected-error {{invalid argument type 'svint8_t'}}
   ++init_int8;  // expected-error {{cannot increment value of type 'svint8_t'}}
   init_int8++;  // expected-error {{cannot increment value of type 'svint8_t'}}
-  -init_int8;   // expected-error {{invalid argument type 'svint8_t'}}
   --init_int8;  // expected-error {{cannot decrement value of type 'svint8_t'}}
   init_int8--;  // expected-error {{cannot decrement value of type 'svint8_t'}}
   !init_int8;   // expected-error {{invalid argument type 'svint8_t'}}
Index: clang/test/Sema/sizeless-1.c
===
--- clang/test/Sema/sizeless-1.c
+++ clang/test/Sema/sizeless-1.c
@@ -187,10 +187,8 @@
   global_int8_ptr -= 1;  // expected-error {{arithmetic on a pointer to sizeless type}}
   global_int8_ptr - global_int8_ptr; // expected-error {{arithmetic on a pointer to sizeless type}}
 
-  +init_int8;   // expected-error {{invalid argument type 'svint8_t'}}
   ++init_int8;  // expected-error {{cannot increment value of type 'svint8_t'}}
   init_int8++;  // expected-error {{cannot increment value of type 'svint8_t'}}
-  -init_int8;   // expected-error {{invalid argument type 'svint8_t'}}
   --init_int8;  // expected-error {{cannot decrement value of type 'svint8_t'}}
   init_int8--;  // expected-error {{cannot decrement value of type 'svint8_t'}}
   !init_int8;   // expected-error {{invalid argument type 'svint8_t'}}
Index: clang/test/CodeGen/aarch64-sve-vector-arith-ops.c
===
--- clang/test/CodeGen/aarch64-sve-vector-arith-ops.c
+++ clang/test/CodeGen/aarch64-sve-vector-arith-ops.c
@@ -1650,3 +1650,143 @@
 svuint64_t rem_scalar_u64(svuint64_t a, uint64_t b) {
   return a % b;
 }
+
+// UNARY PROMOTION
+
+// CHECK-LABEL: @prom_i8(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:ret  [[A:%.*]]
+//
+svint8_t prom_i8(svint8_t a) {
+  return +a;
+}
+
+// CHECK-LABEL: @prom_i16(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:ret  [[A:%.*]]
+//
+svint16_t prom_i16(svint16_t a) {
+  return +a;
+}
+
+// CHECK-LABEL: @prom_i32(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:ret  [[A:%.*]]
+//
+svint32_t prom_i32(svint32_t a) {
+  return +a;
+}
+
+// CHECK-LABEL: @prom_i64(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:ret  [[A:%.*]]
+//
+svint64_t prom_i64(svint64_t a) {
+  return +a;
+}
+
+// CHECK-LABEL: @prom_u8(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:ret  [[A:%.*]]
+//
+svuint8_t prom_u8(svuint8_t a) {
+  return +a;
+}
+
+// CHECK-LABEL: @prom_u16(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:ret  [[A:%.*]]
+//
+svuint16_t prom_u16(svuint16_t a) {
+  return +a;
+}
+
+// CHECK-LABEL: @prom_u32(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:ret  [[A:%.*]]
+//
+svuint32_t prom_u32(svuint32_t a) {
+  return +a;
+}
+
+// CHECK-LABEL: @prom_u64(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:ret  [[A:%.*]]
+//
+svuint64_t prom_u64(svuint64_t a) {
+  return +a;
+}
+
+// UNARY NEGATION
+
+// CHECK-LABEL: @neg_i8(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[SUB:%.*]] = sub  zeroinitializer, [[A:%.*]]
+// CHECK-NEXT:ret  [[SUB]]
+//
+svint8_t neg_i8(svint8_t a) {
+  return -a;
+}
+
+// CHECK-LABEL: @neg_i16(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[SUB:%.*]] = sub  zeroinitializer, [[A:%.*]]
+// CHECK-NEXT:ret  [[SUB]]
+//
+svint16_t neg_i16(svint16_t a) {
+  return -a;
+}
+
+// CHECK-LABEL: @neg_i32(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[SUB:%.*]] = sub  zeroinitializer, [[A:%.*]]
+// CHECK-NEXT:ret  [[SUB]]
+//
+svint32_t neg_i32(svint32_t a) {
+  return -a;
+}
+
+// CHECK-LABEL: @neg_i64(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[SUB:%.*]] = sub  zeroinitializer, [[A:%.*]]
+// CHECK-NEXT:ret  [[SUB]]
+//
+svint64_t neg_i64(svint64_t a) {
+  return -a;
+}
+
+// CHECK-LABEL: @neg_u8(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:[[SUB:%.*]]

[PATCH] D130015: [clangd] Add "usedAsMutablePointer" highlighting modifier

2022-08-10 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added a comment.

I agree with Nathan to some extent that this doesn't carry as much weight, but 
if we can get it without introducing much complexity to the user (i.e. a new 
modifier they need to remember), it's worth having since we don't need too much 
effort to support it.




Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:578
 // e.g. std::vector& is dependent but we would want to highlight it
-if (!T->isLValueReferenceType() ||
-T.getNonReferenceType().isConstQualified() || T->isDependentType()) {
+const bool IsRef = T->isLValueReferenceType();
+const bool IsPtr = T->isPointerType();

nit: we don't do `const`s for locals (not saying this is a bad practice, it's 
just not inline with the convention in the rest of the codebase).



Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:603
   H.addExtraModifier(*Location,
- HighlightingModifier::UsedAsMutableReference);
+ IsRef ? HighlightingModifier::UsedAsMutableReference
+   : HighlightingModifier::UsedAsMutablePointer);

why do you think we should have different modifiers for these? they both 
indicate the same thing, the parameter might get mutated by the call, and it 
being a pointer or reference doesn't seem to matter.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130015

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


[PATCH] D130974: [analyzer] Fix for the crash in #56873

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

In D130974#3709502 , @isuckatcs wrote:

>> Some checker should have caught the uninitialized value earlier than the 
>> defaultEvalCall().
>> I guess, the MallocCkecher could have checked for it in PreStmt.
>> Or alternatively, the CallAndMessageChecker::preCall() already does 
>> something like this in the PreVisitProcessArg(). I know that CXXNewExpr is 
>> not a call, but you get the idea.
>> WDYT, worth catching it?
>
> I definitely think it's worth catching it. I'm working on a checker which 
> addresses this in D131299 . It was 
> originally intended to be a part of MallocChecker but has been moved to a 
> separate one.

If so, shouldn't be some dependencies across these revisions? You could also 
specify an additional RUN line to demonstrate that this can be caught by an 
experimental configuration.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130974

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


[PATCH] D131065: [clang][dataflow] Store DeclContext of block being analysed in Environment if available.

2022-08-10 Thread weiyi via Phabricator via cfe-commits
wyt updated this revision to Diff 451411.
wyt added a comment.

Relocate function and fix comment for consistency.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131065

Files:
  clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
  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
@@ -154,7 +154,7 @@
 : DACtx(&DACtx), FlowConditionToken(&DACtx.makeFlowConditionToken()) {}
 
 Environment::Environment(const Environment &Other)
-: DACtx(Other.DACtx), ReturnLoc(Other.ReturnLoc),
+: DACtx(Other.DACtx), DeclCtx(Other.DeclCtx), ReturnLoc(Other.ReturnLoc),
   ThisPointeeLoc(Other.ThisPointeeLoc), DeclToLoc(Other.DeclToLoc),
   ExprToLoc(Other.ExprToLoc), LocToVal(Other.LocToVal),
   MemberLocToStruct(Other.MemberLocToStruct),
@@ -168,9 +168,11 @@
 }
 
 Environment::Environment(DataflowAnalysisContext &DACtx,
- const DeclContext &DeclCtx)
+ const DeclContext &DeclCtxArg)
 : Environment(DACtx) {
-  if (const auto *FuncDecl = dyn_cast(&DeclCtx)) {
+  setDeclCtx(&DeclCtxArg);
+
+  if (const auto *FuncDecl = dyn_cast(DeclCtx)) {
 assert(FuncDecl->getBody() != nullptr);
 initGlobalVars(*FuncDecl->getBody(), *this);
 for (const auto *ParamDecl : FuncDecl->parameters()) {
@@ -185,7 +187,7 @@
 ReturnLoc = &createStorageLocation(ReturnType);
   }
 
-  if (const auto *MethodDecl = dyn_cast(&DeclCtx)) {
+  if (const auto *MethodDecl = dyn_cast(DeclCtx)) {
 auto *Parent = MethodDecl->getParent();
 assert(Parent != nullptr);
 if (Parent->isLambda())
@@ -210,6 +212,9 @@
 
   const auto *FuncDecl = Call->getDirectCallee();
   assert(FuncDecl != nullptr);
+
+  Env.setDeclCtx(FuncDecl);
+
   // FIXME: In order to allow the callee to reference globals, we probably need
   // to call `initGlobalVars` here in some way.
 
@@ -252,12 +257,12 @@
 
 void Environment::popCall(const Environment &CalleeEnv) {
   // We ignore `DACtx` because it's already the same in both. We don't want the
-  // callee's `ReturnLoc` or `ThisPointeeLoc`. We don't bring back `DeclToLoc`
-  // and `ExprToLoc` because we want to be able to later analyze the same callee
-  // in a different context, and `setStorageLocation` requires there to not
-  // already be a storage location assigned. Conceptually, these maps capture
-  // information from the local scope, so when popping that scope, we do not
-  // propagate the maps.
+  // callee's `DeclCtx`, `ReturnLoc` or `ThisPointeeLoc`. We don't bring back
+  // `DeclToLoc` and `ExprToLoc` because we want to be able to later analyze the
+  // same callee in a different context, and `setStorageLocation` requires there
+  // to not already be a storage location assigned. Conceptually, these maps
+  // capture information from the local scope, so when popping that scope, we do
+  // not propagate the maps.
   this->LocToVal = std::move(CalleeEnv.LocToVal);
   this->MemberLocToStruct = std::move(CalleeEnv.MemberLocToStruct);
   this->FlowConditionToken = std::move(CalleeEnv.FlowConditionToken);
@@ -304,11 +309,13 @@
   assert(DACtx == Other.DACtx);
   assert(ReturnLoc == Other.ReturnLoc);
   assert(ThisPointeeLoc == Other.ThisPointeeLoc);
+  assert(DeclCtx == Other.DeclCtx);
 
   auto Effect = LatticeJoinEffect::Unchanged;
 
   Environment JoinedEnv(*DACtx);
 
+  JoinedEnv.setDeclCtx(DeclCtx);
   JoinedEnv.ReturnLoc = ReturnLoc;
   JoinedEnv.ThisPointeeLoc = ThisPointeeLoc;
 
Index: clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
===
--- clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
+++ clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
@@ -347,6 +347,13 @@
   /// imply that `Val` is true.
   bool flowConditionImplies(BoolValue &Val) const;
 
+  /// Returns the `DeclContext` of the block being analysed, if any. Otherwise,
+  /// returns null.
+  const DeclContext *getDeclCtx() { return DeclCtx; }
+
+  /// Sets the `DeclContext` of the block being analysed.
+  void setDeclCtx(const DeclContext *Ctx) { DeclCtx = Ctx; }
+
   /// Returns the `ControlFlowContext` registered for `F`, if any. Otherwise,
   /// returns null.
   const ControlFlowContext *getControlFlowContext(const FunctionDecl *F) {
@@ -377,6 +384,9 @@
   // `DACtx` is not null and not owned by this object.
   DataflowAnalysisContext *DACtx;
 
+  // `DeclContext` of the block being analysed if provided.
+  const DeclContext *DeclCtx;
+
   // In a properly initialized `Environment`, `ReturnLoc` should only be null if
   // its `DeclContext` could not be cast to a `FunctionDecl`.
   StorageLocat

[clang] 8a4c40b - [clang][dataflow] Store DeclContext of block being analysed in Environment if available.

2022-08-10 Thread Wei Yi Tee via cfe-commits

Author: Wei Yi Tee
Date: 2022-08-10T11:27:03Z
New Revision: 8a4c40bfe8e6605ffc9d866f8620618dfdde2875

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

LOG: [clang][dataflow] Store DeclContext of block being analysed in Environment 
if available.

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

Added: 


Modified: 
clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp

Removed: 




diff  --git a/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h 
b/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
index fc43b6b43575f..1b154010bf365 100644
--- a/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
+++ b/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
@@ -347,6 +347,13 @@ class Environment {
   /// imply that `Val` is true.
   bool flowConditionImplies(BoolValue &Val) const;
 
+  /// Returns the `DeclContext` of the block being analysed, if any. Otherwise,
+  /// returns null.
+  const DeclContext *getDeclCtx() { return DeclCtx; }
+
+  /// Sets the `DeclContext` of the block being analysed.
+  void setDeclCtx(const DeclContext *Ctx) { DeclCtx = Ctx; }
+
   /// Returns the `ControlFlowContext` registered for `F`, if any. Otherwise,
   /// returns null.
   const ControlFlowContext *getControlFlowContext(const FunctionDecl *F) {
@@ -377,6 +384,9 @@ class Environment {
   // `DACtx` is not null and not owned by this object.
   DataflowAnalysisContext *DACtx;
 
+  // `DeclContext` of the block being analysed if provided.
+  const DeclContext *DeclCtx;
+
   // In a properly initialized `Environment`, `ReturnLoc` should only be null 
if
   // its `DeclContext` could not be cast to a `FunctionDecl`.
   StorageLocation *ReturnLoc = nullptr;

diff  --git a/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp 
b/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
index ff27a2a45179b..16c83cad9d9e3 100644
--- a/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
+++ b/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
@@ -154,7 +154,7 @@ Environment::Environment(DataflowAnalysisContext &DACtx)
 : DACtx(&DACtx), FlowConditionToken(&DACtx.makeFlowConditionToken()) {}
 
 Environment::Environment(const Environment &Other)
-: DACtx(Other.DACtx), ReturnLoc(Other.ReturnLoc),
+: DACtx(Other.DACtx), DeclCtx(Other.DeclCtx), ReturnLoc(Other.ReturnLoc),
   ThisPointeeLoc(Other.ThisPointeeLoc), DeclToLoc(Other.DeclToLoc),
   ExprToLoc(Other.ExprToLoc), LocToVal(Other.LocToVal),
   MemberLocToStruct(Other.MemberLocToStruct),
@@ -168,9 +168,11 @@ Environment &Environment::operator=(const Environment 
&Other) {
 }
 
 Environment::Environment(DataflowAnalysisContext &DACtx,
- const DeclContext &DeclCtx)
+ const DeclContext &DeclCtxArg)
 : Environment(DACtx) {
-  if (const auto *FuncDecl = dyn_cast(&DeclCtx)) {
+  setDeclCtx(&DeclCtxArg);
+
+  if (const auto *FuncDecl = dyn_cast(DeclCtx)) {
 assert(FuncDecl->getBody() != nullptr);
 initGlobalVars(*FuncDecl->getBody(), *this);
 for (const auto *ParamDecl : FuncDecl->parameters()) {
@@ -185,7 +187,7 @@ Environment::Environment(DataflowAnalysisContext &DACtx,
 ReturnLoc = &createStorageLocation(ReturnType);
   }
 
-  if (const auto *MethodDecl = dyn_cast(&DeclCtx)) {
+  if (const auto *MethodDecl = dyn_cast(DeclCtx)) {
 auto *Parent = MethodDecl->getParent();
 assert(Parent != nullptr);
 if (Parent->isLambda())
@@ -210,6 +212,9 @@ Environment Environment::pushCall(const CallExpr *Call) 
const {
 
   const auto *FuncDecl = Call->getDirectCallee();
   assert(FuncDecl != nullptr);
+
+  Env.setDeclCtx(FuncDecl);
+
   // FIXME: In order to allow the callee to reference globals, we probably need
   // to call `initGlobalVars` here in some way.
 
@@ -252,12 +257,12 @@ Environment Environment::pushCall(const CallExpr *Call) 
const {
 
 void Environment::popCall(const Environment &CalleeEnv) {
   // We ignore `DACtx` because it's already the same in both. We don't want the
-  // callee's `ReturnLoc` or `ThisPointeeLoc`. We don't bring back `DeclToLoc`
-  // and `ExprToLoc` because we want to be able to later analyze the same 
callee
-  // in a 
diff erent context, and `setStorageLocation` requires there to not
-  // already be a storage location assigned. Conceptually, these maps capture
-  // information from the local scope, so when popping that scope, we do not
-  // propagate the maps.
+  // callee's `DeclCtx`, `ReturnLoc` or `ThisPointeeLoc`. We don't bring back
+  // `DeclToLoc` and `ExprToLoc` because we want to be able to later analyze 
the
+  // same callee in a 
diff erent context, and `setStorageLocati

[PATCH] D131065: [clang][dataflow] Store DeclContext of block being analysed in Environment if available.

2022-08-10 Thread weiyi 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 rG8a4c40bfe8e6: [clang][dataflow] Store DeclContext of block 
being analysed in Environment if… (authored by wyt).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131065

Files:
  clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
  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
@@ -154,7 +154,7 @@
 : DACtx(&DACtx), FlowConditionToken(&DACtx.makeFlowConditionToken()) {}
 
 Environment::Environment(const Environment &Other)
-: DACtx(Other.DACtx), ReturnLoc(Other.ReturnLoc),
+: DACtx(Other.DACtx), DeclCtx(Other.DeclCtx), ReturnLoc(Other.ReturnLoc),
   ThisPointeeLoc(Other.ThisPointeeLoc), DeclToLoc(Other.DeclToLoc),
   ExprToLoc(Other.ExprToLoc), LocToVal(Other.LocToVal),
   MemberLocToStruct(Other.MemberLocToStruct),
@@ -168,9 +168,11 @@
 }
 
 Environment::Environment(DataflowAnalysisContext &DACtx,
- const DeclContext &DeclCtx)
+ const DeclContext &DeclCtxArg)
 : Environment(DACtx) {
-  if (const auto *FuncDecl = dyn_cast(&DeclCtx)) {
+  setDeclCtx(&DeclCtxArg);
+
+  if (const auto *FuncDecl = dyn_cast(DeclCtx)) {
 assert(FuncDecl->getBody() != nullptr);
 initGlobalVars(*FuncDecl->getBody(), *this);
 for (const auto *ParamDecl : FuncDecl->parameters()) {
@@ -185,7 +187,7 @@
 ReturnLoc = &createStorageLocation(ReturnType);
   }
 
-  if (const auto *MethodDecl = dyn_cast(&DeclCtx)) {
+  if (const auto *MethodDecl = dyn_cast(DeclCtx)) {
 auto *Parent = MethodDecl->getParent();
 assert(Parent != nullptr);
 if (Parent->isLambda())
@@ -210,6 +212,9 @@
 
   const auto *FuncDecl = Call->getDirectCallee();
   assert(FuncDecl != nullptr);
+
+  Env.setDeclCtx(FuncDecl);
+
   // FIXME: In order to allow the callee to reference globals, we probably need
   // to call `initGlobalVars` here in some way.
 
@@ -252,12 +257,12 @@
 
 void Environment::popCall(const Environment &CalleeEnv) {
   // We ignore `DACtx` because it's already the same in both. We don't want the
-  // callee's `ReturnLoc` or `ThisPointeeLoc`. We don't bring back `DeclToLoc`
-  // and `ExprToLoc` because we want to be able to later analyze the same callee
-  // in a different context, and `setStorageLocation` requires there to not
-  // already be a storage location assigned. Conceptually, these maps capture
-  // information from the local scope, so when popping that scope, we do not
-  // propagate the maps.
+  // callee's `DeclCtx`, `ReturnLoc` or `ThisPointeeLoc`. We don't bring back
+  // `DeclToLoc` and `ExprToLoc` because we want to be able to later analyze the
+  // same callee in a different context, and `setStorageLocation` requires there
+  // to not already be a storage location assigned. Conceptually, these maps
+  // capture information from the local scope, so when popping that scope, we do
+  // not propagate the maps.
   this->LocToVal = std::move(CalleeEnv.LocToVal);
   this->MemberLocToStruct = std::move(CalleeEnv.MemberLocToStruct);
   this->FlowConditionToken = std::move(CalleeEnv.FlowConditionToken);
@@ -304,11 +309,13 @@
   assert(DACtx == Other.DACtx);
   assert(ReturnLoc == Other.ReturnLoc);
   assert(ThisPointeeLoc == Other.ThisPointeeLoc);
+  assert(DeclCtx == Other.DeclCtx);
 
   auto Effect = LatticeJoinEffect::Unchanged;
 
   Environment JoinedEnv(*DACtx);
 
+  JoinedEnv.setDeclCtx(DeclCtx);
   JoinedEnv.ReturnLoc = ReturnLoc;
   JoinedEnv.ThisPointeeLoc = ThisPointeeLoc;
 
Index: clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
===
--- clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
+++ clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
@@ -347,6 +347,13 @@
   /// imply that `Val` is true.
   bool flowConditionImplies(BoolValue &Val) const;
 
+  /// Returns the `DeclContext` of the block being analysed, if any. Otherwise,
+  /// returns null.
+  const DeclContext *getDeclCtx() { return DeclCtx; }
+
+  /// Sets the `DeclContext` of the block being analysed.
+  void setDeclCtx(const DeclContext *Ctx) { DeclCtx = Ctx; }
+
   /// Returns the `ControlFlowContext` registered for `F`, if any. Otherwise,
   /// returns null.
   const ControlFlowContext *getControlFlowContext(const FunctionDecl *F) {
@@ -377,6 +384,9 @@
   // `DACtx` is not null and not owned by this object.
   DataflowAnalysisContext *DACtx;
 
+  // `DeclContext` of the block being analysed if provided.
+  const DeclContext *DeclCtx;
+
   // In a pro

[PATCH] D130015: [clangd] Add "usedAsMutablePointer" highlighting modifier

2022-08-10 Thread Christian Kandeler via Phabricator via cfe-commits
ckandeler updated this revision to Diff 451420.
ckandeler marked an inline comment as done.
ckandeler added a comment.

Fixed style issues.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130015

Files:
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/SemanticHighlighting.h
  clang-tools-extra/clangd/test/initialize-params.test
  clang-tools-extra/clangd/test/semantic-tokens.test
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp

Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -373,7 +373,7 @@
   void $Function_decl[[foo]]() {
 $Class[[F]] $LocalVariable_decl[[FF]];
 $Class[[G]]<$Class[[F]], &$Class[[F]]::$Method[[f]]> $LocalVariable_decl[[GG]];
-$LocalVariable[[GG]].$Method[[foo]](&$LocalVariable[[FF]]);
+$LocalVariable[[GG]].$Method[[foo]](&$LocalVariable_usedAsMutablePointer[[FF]]);
 $Class[[A]]<$Function[[foo]]> $LocalVariable_decl[[AA]];
   }
 )cpp",
@@ -772,14 +772,14 @@
   const int* $LocalVariable_decl_readonly[[constPtr]];
   int** $LocalVariable_decl[[array]];
   $Function[[fun]]($LocalVariable[[val]], $LocalVariable[[val]], 
-   $LocalVariable[[ptr]], $LocalVariable_readonly[[constPtr]], 
+   $LocalVariable_usedAsMutablePointer[[ptr]], $LocalVariable_readonly[[constPtr]],
$LocalVariable_usedAsMutableReference[[val]], $LocalVariable[[val]], 
 
$LocalVariable_usedAsMutableReference[[ptr]],
$LocalVariable_readonly_usedAsMutableReference[[constPtr]],
$LocalVariable_readonly[[constPtr]],
 
-   $LocalVariable[[array]], $LocalVariable_usedAsMutableReference[[array]], 
+   $LocalVariable_usedAsMutablePointer[[array]], $LocalVariable_usedAsMutableReference[[array]],
$LocalVariable[[array]]
);
   [](int){}($LocalVariable[[val]]);
Index: clang-tools-extra/clangd/test/semantic-tokens.test
===
--- clang-tools-extra/clangd/test/semantic-tokens.test
+++ clang-tools-extra/clangd/test/semantic-tokens.test
@@ -23,7 +23,7 @@
 # CHECK-NEXT:  4,
 # CHECK-NEXT:  1,
 # CHECK-NEXT:  0,
-# CHECK-NEXT:  8193
+# CHECK-NEXT:  16385
 # CHECK-NEXT:],
 # CHECK-NEXT:"resultId": "1"
 # CHECK-NEXT:  }
@@ -49,7 +49,7 @@
 # CHECK-NEXT:  4,
 # CHECK-NEXT:  1,
 # CHECK-NEXT:  0,
-# CHECK-NEXT:  8193
+# CHECK-NEXT:  16385
 # CHECK-NEXT:],
 #Inserted at position 1
 # CHECK-NEXT:"deleteCount": 0,
@@ -72,12 +72,12 @@
 # CHECK-NEXT:  4,
 # CHECK-NEXT:  1,
 # CHECK-NEXT:  0,
-# CHECK-NEXT:  8193,
+# CHECK-NEXT:  16385,
 # CHECK-NEXT:  1,
 # CHECK-NEXT:  4,
 # CHECK-NEXT:  1,
 # CHECK-NEXT:  0,
-# CHECK-NEXT:  8193
+# CHECK-NEXT:  16385
 # CHECK-NEXT:],
 # CHECK-NEXT:"resultId": "3"
 # CHECK-NEXT:  }
Index: clang-tools-extra/clangd/test/initialize-params.test
===
--- clang-tools-extra/clangd/test/initialize-params.test
+++ clang-tools-extra/clangd/test/initialize-params.test
@@ -66,6 +66,7 @@
 # CHECK-NEXT:"dependentName",
 # CHECK-NEXT:"defaultLibrary",
 # CHECK-NEXT:"usedAsMutableReference",
+# CHECK-NEXT:"usedAsMutablePointer",
 # CHECK-NEXT:"functionScope",
 # CHECK-NEXT:"classScope",
 # CHECK-NEXT:"fileScope",
Index: clang-tools-extra/clangd/SemanticHighlighting.h
===
--- clang-tools-extra/clangd/SemanticHighlighting.h
+++ clang-tools-extra/clangd/SemanticHighlighting.h
@@ -71,6 +71,7 @@
   DependentName,
   DefaultLibrary,
   UsedAsMutableReference,
+  UsedAsMutablePointer,
 
   FunctionScope,
   ClassScope,
Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -572,11 +572,13 @@
 if (!Arg)
   return;
 
-// Is this parameter passed by non-const reference?
+// Is this parameter passed by non-const pointer or reference?
 // FIXME The condition T->idDependentType() could be relaxed a bit,
 // e.g. std::vector& is dependent but we would want to highlight it
-if (!T->isLValueReferenceType() ||
-T.getN

[PATCH] D130015: [clangd] Add "usedAsMutablePointer" highlighting modifier

2022-08-10 Thread Christian Kandeler via Phabricator via cfe-commits
ckandeler added inline comments.



Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:603
   H.addExtraModifier(*Location,
- HighlightingModifier::UsedAsMutableReference);
+ IsRef ? HighlightingModifier::UsedAsMutableReference
+   : HighlightingModifier::UsedAsMutablePointer);

kadircet wrote:
> why do you think we should have different modifiers for these? they both 
> indicate the same thing, the parameter might get mutated by the call, and it 
> being a pointer or reference doesn't seem to matter.
Because I'm aware that there are people (like Nathan) who don't find it useful 
for pointers, and having just one modifier would force it on everybody. With 
two distinct modifiers, clients can decide for themselves, possibly even 
exposing the choice to users.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130015

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


[PATCH] D131547: [Clang][AArch64] Use generic extract/insert vector for svget/svset/svcreate tuples

2022-08-10 Thread Sander de Smalen via Phabricator via cfe-commits
sdesmalen added inline comments.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:9077
 
+Value *CodeGenFunction::EmmitSVESetTuples(const SVETypeFlags &TypeFlags,
+  llvm::Type *Ty,

nit: s/Emmit/Emit/

How about naming these:
* EmitSVETupleGet
* EmitSVETupleSet
* EmitSVETupleCreate



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:9084
+  auto *SrcTy = dyn_cast(Ops[2]->getType());
+  unsigned int I = cast(Ops[1])->getSExtValue() *
+   SrcTy->getElementCount().getKnownMinValue();

nit: s/unsigned int/unsigned/



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:9091
+
+Value *CodeGenFunction::EmmitSVEGetTuples(const SVETypeFlags &TypeFlags,
+  llvm::Type *Ty,

nit: Can this function be merged with the function above, you could pass `bool 
IsInsert`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131547

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


[PATCH] D118996: [clang-tidy] Support C++14 in bugprone-signal-handler.

2022-08-10 Thread Simon Pilgrim via Phabricator via cfe-commits
RKSimon added a comment.

@balazske This is failing on 
https://lab.llvm.org/buildbot/#/builders/139/builds/26335 - do you have a fix 
in progress or should I revert?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118996

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


[PATCH] D128807: [clang][transformer] Finish plumbing `Note` all the way to the output.

2022-08-10 Thread Clement Courbet via Phabricator via cfe-commits
courbet updated this revision to Diff 451425.
courbet added a comment.

Replace both versions of `withNote()` with a single `ASTEdit note()` generator.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128807

Files:
  clang-tools-extra/clang-tidy/utils/TransformerClangTidyCheck.cpp
  clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
  clang/include/clang/Tooling/Transformer/RewriteRule.h
  clang/lib/Tooling/Transformer/RewriteRule.cpp

Index: clang/lib/Tooling/Transformer/RewriteRule.cpp
===
--- clang/lib/Tooling/Transformer/RewriteRule.cpp
+++ clang/lib/Tooling/Transformer/RewriteRule.cpp
@@ -59,6 +59,12 @@
 return Replacement.takeError();
   T.Replacement = std::move(*Replacement);
 }
+if (E.Note) {
+  auto Note = E.Note->eval(Result);
+  if (!Note)
+return Note.takeError();
+  T.Note = std::move(*Note);
+}
 if (E.Metadata) {
   auto Metadata = E.Metadata(Result);
   if (!Metadata)
@@ -125,6 +131,13 @@
   return E;
 }
 
+ASTEdit transformer::note(RangeSelector Anchor, TextGenerator Note) {
+  ASTEdit E;
+  E.TargetRange = transformer::before(Anchor);
+  E.Note = std::move(Note);
+  return E;
+}
+
 namespace {
 /// A \c TextGenerator that always returns a fixed string.
 class SimpleTextGenerator : public MatchComputation {
Index: clang/include/clang/Tooling/Transformer/RewriteRule.h
===
--- clang/include/clang/Tooling/Transformer/RewriteRule.h
+++ clang/include/clang/Tooling/Transformer/RewriteRule.h
@@ -46,6 +46,7 @@
   EditKind Kind = EditKind::Range;
   CharSourceRange Range;
   std::string Replacement;
+  std::string Note;
   llvm::Any Metadata;
 };
 
@@ -138,6 +139,10 @@
 /// diagnostic `Explanation` with the rule.
 EditGenerator noopEdit(RangeSelector Anchor);
 
+/// Generates a single, no-op edit with the associated note anchored at the
+/// start location of the specified range.
+ASTEdit note(RangeSelector Anchor, TextGenerator Note);
+
 /// Version of `ifBound` specialized to `ASTEdit`.
 inline EditGenerator ifBound(std::string ID, ASTEdit TrueEdit,
  ASTEdit FalseEdit) {
Index: clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
===
--- clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
+++ clang-tools-extra/unittests/clang-tidy/TransformerClangTidyCheckTest.cpp
@@ -28,6 +28,7 @@
 using transformer::makeRule;
 using transformer::node;
 using transformer::noopEdit;
+using transformer::note;
 using transformer::RewriteRuleWith;
 using transformer::RootID;
 using transformer::statement;
@@ -85,6 +86,7 @@
   EXPECT_EQ(Errors.size(), 1U);
   EXPECT_EQ(Errors[0].Message.Message, "message");
   EXPECT_THAT(Errors[0].Message.Ranges, testing::IsEmpty());
+  EXPECT_THAT(Errors[0].Notes, testing::IsEmpty());
 
   // The diagnostic is anchored to the match, "return 5".
   EXPECT_EQ(Errors[0].Message.FileOffset, 10U);
@@ -116,6 +118,27 @@
   EXPECT_EQ(Errors[0].Message.FileOffset, 10U);
 }
 
+TEST(TransformerClangTidyCheckTest, NotesCorrectlyGenerated) {
+  class DiagAndNoteCheck : public TransformerClangTidyCheck {
+  public:
+DiagAndNoteCheck(StringRef Name, ClangTidyContext *Context)
+: TransformerClangTidyCheck(
+  makeRule(returnStmt(),
+   note(node(RootID), cat("some note")),
+   cat("message")),
+  Name, Context) {}
+  };
+  std::string Input = "int h() { return 5; }";
+  std::vector Errors;
+  EXPECT_EQ(Input, test::runCheckOnCode(Input, &Errors));
+  EXPECT_EQ(Errors.size(), 1U);
+  EXPECT_EQ(Errors[0].Notes.size(), 1U);
+  EXPECT_EQ(Errors[0].Notes[0].Message, "some note");
+
+  // The note is anchored to the match, "return 5".
+  EXPECT_EQ(Errors[0].Notes[0].FileOffset, 10U);
+}
+
 TEST(TransformerClangTidyCheckTest, DiagnosticMessageEscaped) {
   class GiveDiagWithPercentSymbol : public TransformerClangTidyCheck {
   public:
Index: clang-tools-extra/clang-tidy/utils/TransformerClangTidyCheck.cpp
===
--- clang-tools-extra/clang-tidy/utils/TransformerClangTidyCheck.cpp
+++ clang-tools-extra/clang-tidy/utils/TransformerClangTidyCheck.cpp
@@ -7,6 +7,7 @@
 //===--===//
 
 #include "TransformerClangTidyCheck.h"
+#include "clang/Basic/DiagnosticIDs.h"
 #include "clang/Lex/Preprocessor.h"
 #include "llvm/ADT/STLExtras.h"
 
@@ -126,18 +127,28 @@
   }
 
   // Associate the diagnostic with the location of the first change.
-  DiagnosticBuilder Diag =
-  diag((*Edits)[0].Range.getBegin(), escapeForDiagnostic(*Explanation));
-  for (const auto &T : *Edits)
-switch (T.Kind) {
- 

[PATCH] D128807: [clang][transformer] Finish plumbing `Note` all the way to the output.

2022-08-10 Thread Clement Courbet via Phabricator via cfe-commits
courbet added a comment.

Thanks for the comments.




Comment at: clang/include/clang/Tooling/Transformer/RewriteRule.h:250-251
 
+// Adds a note to the given edit or edits. If there are several edits, the note
+// is added to each one of them.
+// \code

ymandel wrote:
> li.zhe.hua wrote:
> > Are we sure that this is what someone would want? Perhaps I am not creative 
> > enough, but this seems like it could explode a large number of notes that 
> > coincide to edits, which seems like an odd thing to want.
> Agreed. I'm more inclined to only include the ASTEdit version.  I see the 
> value of the other one, but seems easy to get wrong. Alternatively, implement 
> it to either only add to the first edit or append/prepend a separate edit 
> with the note.
> 
> Either way, I think the primary use should be with a standalone note 
> generator like `ASTEdit note(TextGenerator Note)`. The idea is that the new 
> combinator allows adding notes to a rule and we happen to store notes in 
> ASTEdits.  Then, `withNote` is really the uncommon case where you want to 
> supplement an existing edit or set of edits with a note. WDYT?

>  I'm more inclined to only include the ASTEdit version. I see the value of 
> the other one, but seems easy to get wrong. Alternatively, implement it to 
> either only add to the first edit or append/prepend a separate edit with the 
> note.

The `EditGenerator` version was so that we can always add a note. Some 
generators return an `EditGenerator` instead of an `ASTEdit`. For example, 
`noopEdit` needs access to the match result to generate an empty range . The 
second version is required to work with these:

```
withNote(changeTo(anchor1, ...));   // OK, changeTo returns an `ASTEdit`.
withNote(noopEdit(...));   // not OK, noopEdit returns an `EditGenerator`, we 
need the second version.
```

> Either way, I think the primary use should be with a standalone note 
> generator like ASTEdit note(TextGenerator Note). The idea is that the new 
> combinator allows adding notes to a rule and we happen to store notes in 
> ASTEdits. Then, withNote is really the uncommon case where you want to 
> supplement an existing edit or set of edits with a note. WDYT?

I think you're right, we don't need the notes to be attached to a particular 
edit. I expect most notes to be standalone: that's actually what I need in my 
case, and it's also actually what the `diag` API presents to the user.

```
diag(loc1, "some warning") << FixItHint::CreateReplacement(...);
diag(loc2, "some note", clang::DiagnosticIDs::Note)
```

becomes, in transformerland:

```
makeRule(matcher, flatten(changeTo(...), note(anchor2, cat("some note"))), 
cat("some warning"))
```

So I think we only really need an ` ASTEdit note()` generator. I went with that 
solution.






Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128807

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


[PATCH] D131563: [clang] Fix clang multiarch isssue with musl

2022-08-10 Thread Brahmajit via Phabricator via cfe-commits
listout created this revision.
listout added reviewers: dlj, atanasyan, MaskRay, Bdragon28.
Herald added subscribers: StephenFan, pengfei, fedor.sergeev, kristof.beyls.
Herald added a project: All.
listout requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

>From clang 13.0.0 has a new option -print-multiarch, matching gcc. On
linux-musl systems this outputs x86_64-linux-gnu (or aarch64-linux-gnu, etc)
instead of x86_64-linux-musl (or aarch64-linux-musl, etc).

Amongst other things, this bug breaks compiling python with clang on musl
hosts, as the python configure script does a sanity check and notices the
output of -print-multiarch is inconsistent with the linux-musl platform triplet
it (correctly) deduces for the host by other means. (The configure script
errors out with "internal configure error for the platform triplet, please file
a bug report" FWIW. This worked okay in clang 12.0.1 because python only checks
the multiarch target for consistency if $CC -print-multiarch isn't an error.)

The implementation in Linux::getMultiarchTriple() of
clang/lib/Driver/ToolChains/Linux.cpp special-cases -linux-android targets, and
assumes -linux-gnu for anything else.

Credit for this patch goes to arachsys 
Please also reffer:
https://bugs.llvm.org/show_bug.cgi?id=52127 and
llvm/llvm-project#51469


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D131563

Files:
  clang/lib/Driver/ToolChains/Linux.cpp

Index: clang/lib/Driver/ToolChains/Linux.cpp
===
--- clang/lib/Driver/ToolChains/Linux.cpp
+++ clang/lib/Driver/ToolChains/Linux.cpp
@@ -42,7 +42,9 @@
   StringRef SysRoot) const {
   llvm::Triple::EnvironmentType TargetEnvironment =
   TargetTriple.getEnvironment();
-  bool IsAndroid = TargetTriple.isAndroid();
+  std::string EnvName = TargetTriple.isAndroid() ? "android"
+: TargetTriple.isMusl()  ? "musl"
+ : "gnu";
   bool IsMipsR6 = TargetTriple.getSubArch() == llvm::Triple::MipsSubArch_r6;
   bool IsMipsN32Abi = TargetTriple.getEnvironment() == llvm::Triple::GNUABIN32;
 
@@ -58,78 +60,66 @@
   // regardless of what the actual target triple is.
   case llvm::Triple::arm:
   case llvm::Triple::thumb:
-if (IsAndroid)
-  return "arm-linux-androideabi";
 if (TargetEnvironment == llvm::Triple::GNUEABIHF)
-  return "arm-linux-gnueabihf";
-return "arm-linux-gnueabi";
+  return "arm-linux-" + EnvName + "eabihf";
+return "arm-linux-" + EnvName + "eabi";
   case llvm::Triple::armeb:
   case llvm::Triple::thumbeb:
 if (TargetEnvironment == llvm::Triple::GNUEABIHF)
-  return "armeb-linux-gnueabihf";
-return "armeb-linux-gnueabi";
+  return "armeb-linux-" + EnvName + "eabihf";
+return "armeb-linux-" + EnvName + "eabi";
   case llvm::Triple::x86:
-if (IsAndroid)
-  return "i686-linux-android";
-return "i386-linux-gnu";
+return "i386-linux-" + EnvName;
   case llvm::Triple::x86_64:
-if (IsAndroid)
-  return "x86_64-linux-android";
 if (TargetEnvironment == llvm::Triple::GNUX32)
-  return "x86_64-linux-gnux32";
-return "x86_64-linux-gnu";
+  return "x86_64-linux-" + EnvName + "x32";
+return "x86_64-linux-" + EnvName;
   case llvm::Triple::aarch64:
-if (IsAndroid)
-  return "aarch64-linux-android";
-return "aarch64-linux-gnu";
+return "aarch64-linux-" + EnvName;
   case llvm::Triple::aarch64_be:
-return "aarch64_be-linux-gnu";
+return "aarch64_be-linux-" + EnvName;
 
   case llvm::Triple::m68k:
-return "m68k-linux-gnu";
+return "m68k-linux-" + EnvName;
 
   case llvm::Triple::mips:
-return IsMipsR6 ? "mipsisa32r6-linux-gnu" : "mips-linux-gnu";
+return (IsMipsR6 ? "mipsisa32r6-linux-" : "mips-linux-") + EnvName;
   case llvm::Triple::mipsel:
-if (IsAndroid)
-  return "mipsel-linux-android";
-return IsMipsR6 ? "mipsisa32r6el-linux-gnu" : "mipsel-linux-gnu";
+return (IsMipsR6 ? "mipsisa32r6el-linux-" : "mipsel-linux-") + EnvName;
   case llvm::Triple::mips64: {
 std::string MT = std::string(IsMipsR6 ? "mipsisa64r6" : "mips64") +
- "-linux-" + (IsMipsN32Abi ? "gnuabin32" : "gnuabi64");
+ "-linux-" + EnvName + (IsMipsN32Abi ? "abin32" : "abi64");
 if (D.getVFS().exists(SysRoot + "/lib/" + MT))
   return MT;
-if (D.getVFS().exists(SysRoot + "/lib/mips64-linux-gnu"))
-  return "mips64-linux-gnu";
+if (D.getVFS().exists(SysRoot + "/lib/mips64-linux-" + EnvName))
+  return "mips64-linux-" + EnvName;
 break;
   }
   case llvm::Triple::mips64el: {
-if (IsAndroid)
-  return "mips64el-linux-android";
 std::string MT = std::string(IsMipsR6 ? "mipsisa64r6el" : "mips64el") +
- "-linux-" + (IsMipsN32Abi ? "gnuabin32" : "gnuabi64");
+ "-

[PATCH] D131563: [clang] Fix clang multiarch isssue with musl

2022-08-10 Thread Brahmajit via Phabricator via cfe-commits
listout added a comment.

The patch needs some rework for 15.x and above version. If people think it's 
appropriate then I'll be glad to make the changes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131563

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


[PATCH] D131464: [test] Make tests pass regardless of gnu++14/gnu++17 default

2022-08-10 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

I didn't do a full review because I spotted enough concerns that we might want 
to talk about the approach more first. I think the goal should be to avoid 
adding a `-std=` to any RUN line unless the test really requires it. I spotted 
a lot of instances where we went from testing the current language standard 
mode to losing testing for all language modes later than 14 or 17, which will 
give us problems when we go to update to C++20 or beyond. I think we want to 
use more `#if __cplusplus` or disable diagnostics when possible.

I made another lamentation about the lack of lit facilities that I think would 
solve these problems for us, but that's a big ask and is not something I insist 
upon for this. But if you felt like it was a good approach and wanted to work 
on it, I certainly wouldn't be sad about it. :-D




Comment at: clang/lib/Basic/LangStandards.cpp:81
 else
-  return LangStandard::lang_gnucxx14;
+  return LangStandard::lang_gnucxx17;
   case Language::RenderScript:

Unintended change used to find the tests that needed updating?



Comment at: clang/test/AST/ast-dump-undeduced-expr.cpp:1
-// RUN: not %clang_cc1 -triple x86_64-unknown-unknown -ast-dump %s | FileCheck 
%s
+// RUN: not %clang_cc1 -std=c++14 -triple x86_64-unknown-unknown -ast-dump %s 
| FileCheck %s
 

What from this test requires C++14?



Comment at: clang/test/AST/sourceranges.cpp:1-2
-// RUN: %clang_cc1 -triple i686-mingw32 -ast-dump %s | FileCheck %s
+// RUN: %clang_cc1 -std=c++14 -triple i686-mingw32 -ast-dump %s | FileCheck %s
 // RUN: %clang_cc1 -triple i686-mingw32 -std=c++1z -ast-dump %s | FileCheck %s 
-check-prefix=CHECK-1Z
 

I assume this change is because we're testing c++17 on the next RUN line and 
you want to be sure we still get the old test coverage?

The trouble is, when we bump from C++17 to C++20, we'll lose the test coverage 
for the latest standard.

(Not your problem per se, but I continue to think we have a lit deficiency 
where we need some facilities to say "run this test in C++N and later", "run 
this test in C89 through CN", or "run this test in all C++ language modes", 
etc.)



Comment at: clang/test/Analysis/blocks.m:2
 // RUN: %clang_analyze_cc1 -triple x86_64-apple-darwin10 
-analyzer-checker=core -fblocks -verify -Wno-strict-prototypes %s
-// RUN: %clang_analyze_cc1 -triple x86_64-apple-darwin10 
-analyzer-checker=core -fblocks -verify -x objective-c++ %s
+// RUN: %clang_analyze_cc1 -triple x86_64-apple-darwin10 
-analyzer-checker=core -fblocks -verify -x objective-c++ -std=c++14 %s
 

What from this test is invalid in C++17?



Comment at: clang/test/CXX/except/except.spec/p2-dynamic-types.cpp:1
-// RUN: %clang_cc1 -fexceptions -fcxx-exceptions -fsyntax-only -verify %s
+// RUN: %clang_cc1 -fexceptions -fcxx-exceptions -fsyntax-only -verify 
-std=c++14 %s
 

Why not pass `-Wno-dynamic-exception-spec` instead of limiting the test (we 
support dynamic exception specifications in newer language modes and it would 
be good to not lose that test coverage there).



Comment at: clang/test/CXX/except/except.spec/p9-dynamic.cpp:1
-// RUN: %clang_cc1 -no-opaque-pointers %s -triple=x86_64-apple-darwin10 
-emit-llvm -o - -fcxx-exceptions -fexceptions | FileCheck %s 
--check-prefixes=CHECK,CHECK-PRE17
+// RUN: %clang_cc1 -std=c++14 -no-opaque-pointers %s 
-triple=x86_64-apple-darwin10 -emit-llvm -o - -fcxx-exceptions -fexceptions | 
FileCheck %s --check-prefixes=CHECK,CHECK-PRE17
 // RUN: %clang_cc1 -no-opaque-pointers %s -triple=x86_64-apple-darwin10 
-std=c++17 -Wno-dynamic-exception-spec -emit-llvm -o - -fcxx-exceptions 
-fexceptions | FileCheck %s --check-prefixes=CHECK,CHECK-17

Same question here as above


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131464

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


[PATCH] D131528: [Clang] Restrict non fixed enum to a value outside the range of the enumeration values warning to context requiring a constant expression

2022-08-10 Thread Erich Keane via Phabricator via cfe-commits
erichkeane accepted this revision.
erichkeane added a comment.

Yep, looks fine to me.  We might consider adding an additional 
warning-as-warning for the alternative case (could you put a comment on this 
'if' statement to that effect?).


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

https://reviews.llvm.org/D131528

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


[PATCH] D131479: Handle explicitly defaulted consteval special members.

2022-08-10 Thread Utkarsh Saxena via Phabricator via cfe-commits
usaxena95 updated this revision to Diff 451432.
usaxena95 marked an inline comment as done.
usaxena95 added a comment.

Addressed comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131479

Files:
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/test/SemaCXX/cxx0x-defaulted-functions.cpp
  clang/test/SemaCXX/cxx2a-consteval.cpp

Index: clang/test/SemaCXX/cxx2a-consteval.cpp
===
--- clang/test/SemaCXX/cxx2a-consteval.cpp
+++ clang/test/SemaCXX/cxx2a-consteval.cpp
@@ -766,3 +766,102 @@
   static_assert(c == 8);
 }
 }
+
+namespace defaulted_special_member_template {
+template 
+struct default_ctor {
+  T data;
+  consteval default_ctor() = default; // expected-note {{non-constexpr constructor 'foo' cannot be used in a constant expression}}
+};
+
+template 
+struct copy {
+  T data;
+
+  consteval copy(const copy &) = default;// expected-note {{non-constexpr constructor 'foo' cannot be used in a constant expression}}
+  consteval copy &operator=(const copy &) = default; // expected-note {{non-constexpr function 'operator=' cannot be used in a constant expression}}
+  copy() = default;
+};
+
+template 
+struct move {
+  T data;
+
+  consteval move(move &&) = default;// expected-note {{non-constexpr constructor 'foo' cannot be used in a constant expression}}
+  consteval move &operator=(move &&) = default; // expected-note {{non-constexpr function 'operator=' cannot be used in a constant expression}}
+  move() = default;
+};
+
+struct foo {
+  foo() {}// expected-note {{declared here}}
+  foo(const foo &) {} // expected-note {{declared here}}
+  foo(foo &&) {}  // expected-note {{declared here}}
+
+  foo& operator=(const foo &) { return *this; } // expected-note {{declared here}}
+  foo& operator=(foo &&) { return *this; }  // expected-note {{declared here}}
+};
+
+void func() {
+  default_ctor fail0; // expected-error-re {{call to consteval function '{{.*::default_ctor<.*::foo>}}::default_ctor' is not a constant expression}} \
+  expected-note {{in call to 'default_ctor()'}}
+
+  copy good0;
+  copy fail1{good0}; // expected-error-re {{call to consteval function '{{.*::copy<.*::foo>}}::copy' is not a constant expression}} \
+ expected-note {{in call to 'copy(good0)'}}
+  fail1 = good0;  // expected-error-re {{call to consteval function '{{.*::copy<.*::foo>}}::operator=' is not a constant expression}} \
+ expected-note {{in call to '&fail1->operator=(good0)'}}
+
+  move good1;
+  move fail2{static_cast&&>(good1)}; // expected-error-re {{call to consteval function '{{.*::move<.*::foo>}}::move' is not a constant expression}} \
+   expected-note {{in call to 'move(good1)'}}
+  fail2 = static_cast&&>(good1);  // expected-error-re {{call to consteval function '{{.*::move<.*::foo>}}::operator=' is not a constant expression}} \
+   expected-note {{in call to '&fail2->operator=(good1)'}}
+}
+} // namespace defaulted_special_member_template
+
+namespace multiple_default_constructors {
+struct Foo {
+  Foo() {} // expected-note {{declared here}}
+};
+struct Bar {
+  Bar() = default;
+};
+struct Baz {
+  consteval Baz() {}
+};
+
+template 
+struct S {
+  T data;
+  S() requires (N==1) = default;
+  // This cannot be used in constexpr context.
+  S() requires (N==2) {}  // expected-note {{declared here}}
+  consteval S() requires (N==3) = default;  // expected-note {{non-constexpr constructor 'Foo' cannot be used in a constant expression}}
+};
+
+void func() {
+  // Explictly defaulted constructor.
+  S s1;
+  S s2;
+  // User provided constructor.
+  S s3;
+  S s4;
+  // Consteval explictly defaulted constructor.
+  S s5; // expected-error-re {{call to consteval function '{{.*}}::S<{{.*}}::Foo, 3>::S' is not a constant expression}} \
+   expected-note {{in call to 'S()'}}
+  S s6;
+  S s7;
+}
+
+consteval int aConstevalFunction() { // expected-error {{consteval function never produces a constant expression}}
+  // Defaulted default constructors are consteval.
+  S s1;
+
+  S s4; // expected-note {{non-constexpr constructor 'S' cannot be used in a constant expression}}
+
+  S s2;
+  S s3;
+  return 0;
+}
+
+} // namespace multiple_default_constructors
Index: clang/test/SemaCXX/cxx0x-defaulted-functions.cpp
===
--- clang/test/SemaCXX/cxx0x-defaulted-functions.cpp
+++ clang/test/SemaCXX/cxx0x-defaulted-functions.cpp
@@ -44,18 +44,20 @@
 }
 
 template struct S : T {
-  constexpr S() = default;
-  constexpr S(const S&) = default;
-  constexpr S(S&&) = default;
+  constexpr S() = default; // expected-note {{previous declaration is here}}
+  constexpr S(co

[PATCH] D131479: Handle explicitly defaulted consteval special members.

2022-08-10 Thread Utkarsh Saxena via Phabricator via cfe-commits
usaxena95 added a comment.

As discussed offline, we are already following the discussion 2602 
.
We are keeping the constructor `consteval` to allow complaining when we are 
actually processing the call to data member constructors (instead of the 
`consteval` constructor itself.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131479

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


[PATCH] D126907: Deferred Concept Instantiation Implementation Take 2

2022-08-10 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

In D126907#3711956 , @ChuanqiXu wrote:

> In D126907#3710656 , @erichkeane 
> wrote:
>
>> Ok, fixed the test failure in clang, AND it managed to fix 
>> all the failures in libcxx!
>>
>> HOWEVER, it appears that libcxx/test/libcxx/modules_include.sh.cpp
>> is now hanging?
>>
>> I don't know much about the modules implementation (perhaps someone
>> like @ChuanqiXu  can help out?), so I'm at least somewhat stuck until
>> I can figure out how to get it to give me more info.
>
> I may not be able to look into the details recently. What's the error message 
> from the modules?

At the moment, there IS no error message!  Just that the modules_include.sh.cpp 
test now takes a REALLY long time (I thought it was a 'hang', but it finished 
overnight).  So it is more like an extreme compile-time regression.  I can't 
make heads or tails of what the test is SUPPOSED to be doing, so I don't have a 
good idea what the issue is, nor what is happening...


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

https://reviews.llvm.org/D126907

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


[PATCH] D130933: Add docs for function attributes hot/cold

2022-08-10 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

I'm not a git expert by any means, but you might be able to address the patch 
issues with `git diff -U999 main > foo.patch` from the root llvm-project 
directory so that you're getting a diff with 999 lines of context and the 
differences are against the `main` branch.


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

https://reviews.llvm.org/D130933

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


[PATCH] D128095: clang: fix checking parameter packs for expansion

2022-08-10 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

Can you make a better commit message?  I don't have a good idea of the 
intent/description of what you're trying to do here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128095

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


[PATCH] D126676: [clang] Disallow differences in defines used for creating and using PCH

2022-08-10 Thread Martin Storsjö via Phabricator via cfe-commits
mstorsjo added a comment.

In D126676#3703024 , @jansvoboda11 
wrote:

> Also, I'd like to test this patch internally to see if it affects anything on 
> our end. I should be able to do so next week.

Ping @jansvoboda11 - any update on testing this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126676

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


[PATCH] D130847: [clang] SourceManager: fix at SourceManager::getFileIDLoaded for the case of invalid SLockEntry

2022-08-10 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM, thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130847

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


[PATCH] D111283: [clang] template / auto deduction deduces common sugar

2022-08-10 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

This is a sizable patch, and it isn't really clear from context what I'm 
looking at.  Can you please improve the description/commit message to better 
clarify what you are trying to do, what you did, and how you are trying to 
accomplish it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111283

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


[PATCH] D126676: [clang] Disallow differences in defines used for creating and using PCH

2022-08-10 Thread Martin Storsjö via Phabricator via cfe-commits
mstorsjo updated this revision to Diff 451434.
mstorsjo added a comment.

Rebased, to fix (trivial) conflicts in the release notes file.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126676

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Serialization/ASTReader.h
  clang/lib/Frontend/FrontendAction.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/test/PCH/pch-dir.c

Index: clang/test/PCH/pch-dir.c
===
--- clang/test/PCH/pch-dir.c
+++ clang/test/PCH/pch-dir.c
@@ -6,7 +6,7 @@
 // RUN: %clang -x c++-header -std=c++98 %S/pch-dir.h -o %t.h.gch/cpp.gch 
 // RUN: %clang -include %t.h -DFOO=foo -fsyntax-only %s -Xclang -print-stats 2> %t.clog
 // RUN: FileCheck -check-prefix=CHECK-C %s < %t.clog
-// RUN: %clang -include %t.h -DFOO=bar -DBAR=bar -fsyntax-only %s -Xclang -ast-print > %t.cbarlog
+// RUN: %clang -include %t.h -DFOO=bar -fsyntax-only %s -Xclang -ast-print > %t.cbarlog
 // RUN: FileCheck -check-prefix=CHECK-CBAR %s < %t.cbarlog
 // RUN: %clang -x c++ -include %t.h -std=c++98 -fsyntax-only %s -Xclang -print-stats 2> %t.cpplog
 // RUN: FileCheck -check-prefix=CHECK-CPP %s < %t.cpplog
@@ -14,6 +14,11 @@
 // RUN: not %clang -x c++ -std=c++11 -include %t.h -fsyntax-only %s 2> %t.cpp11log
 // RUN: FileCheck -check-prefix=CHECK-NO-SUITABLE %s < %t.cpp11log
 
+// RUN: not %clang -include %t.h -fsyntax-only %s 2> %t.missinglog2
+// RUN: FileCheck -check-prefix=CHECK-NO-SUITABLE %s < %t.missinglog2
+// RUN: not %clang -include %t.h -DFOO=foo -DBAR=bar -fsyntax-only %s 2> %t.missinglog2
+// RUN: FileCheck -check-prefix=CHECK-NO-SUITABLE %s < %t.missinglog2
+
 // Don't crash if the precompiled header file is missing.
 // RUN: not %clang_cc1 -include-pch %t.h.gch -DFOO=baz -fsyntax-only %s -print-stats 2> %t.missinglog
 // RUN: FileCheck -check-prefix=CHECK-NO-SUITABLE %s < %t.missinglog
Index: clang/lib/Serialization/ASTReader.cpp
===
--- clang/lib/Serialization/ASTReader.cpp
+++ clang/lib/Serialization/ASTReader.cpp
@@ -624,20 +624,28 @@
   }
 }
 
+enum OptionValidation {
+  OptionValidateNone,
+  OptionValidateContradictions,
+  OptionValidateStrictMatches,
+};
+
 /// Check the preprocessor options deserialized from the control block
 /// against the preprocessor options in an existing preprocessor.
 ///
 /// \param Diags If non-null, produce diagnostics for any mismatches incurred.
-/// \param Validate If true, validate preprocessor options. If false, allow
-///macros defined by \p ExistingPPOpts to override those defined by
-///\p PPOpts in SuggestedPredefines.
-static bool checkPreprocessorOptions(const PreprocessorOptions &PPOpts,
- const PreprocessorOptions &ExistingPPOpts,
- DiagnosticsEngine *Diags,
- FileManager &FileMgr,
- std::string &SuggestedPredefines,
- const LangOptions &LangOpts,
- bool Validate = true) {
+/// \param Validation If set to OptionValidateNone, ignore differences in
+///preprocessor options. If set to OptionValidateContradictions,
+///require that options passed both in the AST file and on the command
+///line (-D or -U) match, but tolerate options missing in one or the
+///other. If set to OptionValidateContradictions, require that there
+///are no differences in the options between the two.
+static bool checkPreprocessorOptions(
+const PreprocessorOptions &PPOpts,
+const PreprocessorOptions &ExistingPPOpts, DiagnosticsEngine *Diags,
+FileManager &FileMgr, std::string &SuggestedPredefines,
+const LangOptions &LangOpts,
+OptionValidation Validation = OptionValidateContradictions) {
   // Check macro definitions.
   MacroDefinitionsMap ASTFileMacros;
   collectMacroDefinitions(PPOpts, ASTFileMacros);
@@ -653,7 +661,15 @@
 // Check whether we know anything about this macro name or not.
 llvm::StringMap>::iterator Known =
 ASTFileMacros.find(MacroName);
-if (!Validate || Known == ASTFileMacros.end()) {
+if (Validation == OptionValidateNone || Known == ASTFileMacros.end()) {
+  if (Validation == OptionValidateStrictMatches) {
+// If strict matches are requested, don't tolerate any extra defines on
+// the command line that are missing in the AST file.
+if (Diags) {
+  Diags->Report(diag::err_pch_macro_def_undef) << MacroName << true;
+}
+return true;
+  }
   // FIXME: Check whether this identifier was referenced anywhere in the
   // AST file. If so, we should reject the AST file. Unfortunately, this
   // information isn't in the control block. What shall we do about it?
@@ -684,8 +70

[PATCH] D131526: [OMPIRBuilder] Add support for safelen clause

2022-08-10 Thread Prabhdeep Soni via Phabricator via cfe-commits
psoni2628 added inline comments.



Comment at: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:3045
+  if (!(Simdlen == nullptr && Safelen == nullptr)) {
+ConstantInt *VectorizeWidth = Simdlen == nullptr ? Safelen : Simdlen;
 addLoopMetadata(

domada wrote:
> Could you add comment which describes how simdlen and safelen clauses work?
> 
> BTW. Have you checked invalid test case where safelen < simdlen? 
Yes, I have checked this case, the case doesn't make it to OMPIRBuilder, 
because the frontend errors.


```
./ex2.c:9:38: error: the value of 'simdlen' parameter must be less than or 
equal to the value of the 'safelen' parameter
#pragma omp simd safelen(2) simdlen(3)
 ~  ^
1 error generated.

```

I was thinking about adding an assertion to assert that `simdlen < safelen` , 
but I wasn't sure that it made sense to do so when Clang is checking this 
anyways, and the existing codegen for simdlen/safelen also doesn't check this.


```
+  // If both simdlen and safelen clauses are specified, the value of the 
simdlen parameter must be less than or equal to the value of the safelen 
parameter.
+  if (Simdlen != nullptr && Safelen != nullptr &&  
(Simdlen->getValue().ugt(Safelen->getValue( {
+llvm_unreachable("Simdlen must be less than or to Safelen when both 
present");
+  }

```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131526

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


[PATCH] D127695: WIP: clang: Implement Template Specialization Resugaring

2022-08-10 Thread David Rector via Phabricator via cfe-commits
davrec added inline comments.



Comment at: clang/test/Sema/Resugar/resugar-expr.cpp:244
+// N-error@-2 {{with an rvalue of type 'int'}}
+} // namespace t21

Compositions of MemberExprs/CXXMemberCallExprs have an issue:
```
template  struct A {
  struct Inner {
A1 m;
A1 f();
  } inner;
  Inner g();
};
Z x1 = A().inner.m; //No resugar
Z x2 = A().inner.f(); //No resugar
Z x3 = A().g().m; //No resugar
Z x4 = A().g().f(); //No resugar
Z x5 = A::Inner().m; //ok
```

Composed `CallExprs` seem to work but probably warrant a test, e.g.
```
template  B1 h(B1);
Z x6 = h(Int());
Z x7 = h(h(Int()));
```

https://godbolt.org/z/cszrsvh8d



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127695

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


[PATCH] D131526: [OMPIRBuilder] Add support for safelen clause

2022-08-10 Thread Arnamoy B via Phabricator via cfe-commits
arnamoy10 added inline comments.



Comment at: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:3045
+  if (!(Simdlen == nullptr && Safelen == nullptr)) {
+ConstantInt *VectorizeWidth = Simdlen == nullptr ? Safelen : Simdlen;
 addLoopMetadata(

psoni2628 wrote:
> domada wrote:
> > Could you add comment which describes how simdlen and safelen clauses work?
> > 
> > BTW. Have you checked invalid test case where safelen < simdlen? 
> Yes, I have checked this case, the case doesn't make it to OMPIRBuilder, 
> because the frontend errors.
> 
> 
> ```
> ./ex2.c:9:38: error: the value of 'simdlen' parameter must be less than or 
> equal to the value of the 'safelen' parameter
> #pragma omp simd safelen(2) simdlen(3)
>  ~  ^
> 1 error generated.
> 
> ```
> 
> I was thinking about adding an assertion to assert that `simdlen < safelen` , 
> but I wasn't sure that it made sense to do so when Clang is checking this 
> anyways, and the existing codegen for simdlen/safelen also doesn't check this.
> 
> 
> ```
> +  // If both simdlen and safelen clauses are specified, the value of the 
> simdlen parameter must be less than or equal to the value of the safelen 
> parameter.
> +  if (Simdlen != nullptr && Safelen != nullptr &&  
> (Simdlen->getValue().ugt(Safelen->getValue( {
> +llvm_unreachable("Simdlen must be less than or to Safelen when both 
> present");
> +  }
> 
> ```
An `assert` is probably not necessary, as this is part of semantic check (as 
you identified to be done by the frontend).  The check is not part of codegen.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131526

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


[PATCH] D126907: Deferred Concept Instantiation Implementation Take 2

2022-08-10 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

In D126907#3711956 , @ChuanqiXu wrote:

> In D126907#3710656 , @erichkeane 
> wrote:
>
>> Ok, fixed the test failure in clang, AND it managed to fix 
>> all the failures in libcxx!
>>
>> HOWEVER, it appears that libcxx/test/libcxx/modules_include.sh.cpp
>> is now hanging?
>>
>> I don't know much about the modules implementation (perhaps someone
>> like @ChuanqiXu  can help out?), so I'm at least somewhat stuck until
>> I can figure out how to get it to give me more info.
>
> I may not be able to look into the details recently. What's the error message 
> from the modules?

Looking deeper... this test is a monstrosity 
(https://github.com/llvm/llvm-project/blob/main/libcxx/test/libcxx/modules_include.sh.cpp),
 and I'm not necessarily sure it is necessarily modules-related, other than 
enabling it on every header.  So it just seems like one of the STL headers is 
taking significantly longer to compile?  I have no idea how to move forward 
with this... it AT LEAST "finishes", but it takes a very long time to get 
through now.


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

https://reviews.llvm.org/D126907

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


[PATCH] D131438: [clang][dataflow] Analyze constructor bodies

2022-08-10 Thread Sam Estep via Phabricator via cfe-commits
samestep added inline comments.



Comment at: clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h:379
+  /// Shared implementation of `pushCall` overloads.
+  void pushCallInternal(const FunctionDecl *FuncDecl,
+ArrayRef Args);

sgatev wrote:
> Let's add a note that unlike `pushCall`, this member is invoked on the 
> environment of the callee.
Will do, thanks!



Comment at: clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h:380
+  void pushCallInternal(const FunctionDecl *FuncDecl,
+ArrayRef Args);
+

sgatev wrote:
> `#include "llvm/ADT/ArrayRef.h"`
When I add this, I get a warning: "Included header `ArrayRef.h` is not used 
directly"



Comment at: clang/lib/Analysis/FlowSensitive/Transfer.cpp:667-670
+const ControlFlowContext *CFCtx = Env.getControlFlowContext(F);
+
+if (!CFCtx)
+  return;

sgatev wrote:
> 
👍


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131438

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


[PATCH] D131438: [clang][dataflow] Analyze constructor bodies

2022-08-10 Thread Sam Estep via Phabricator via cfe-commits
samestep updated this revision to Diff 451445.
samestep added a comment.

Address Stanislav's comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131438

Files:
  clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
  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
@@ -4368,4 +4368,106 @@
/*.BuiltinTransferOptions=*/{/*.ContextSensitive=*/true}});
 }
 
+TEST(TransferTest, ContextSensitiveConstructorBody) {
+  std::string Code = R"(
+class MyClass {
+public:
+  MyClass() { MyField = true; }
+
+  bool MyField;
+};
+
+void target() {
+  MyClass MyObj;
+  bool Foo = MyObj.MyField;
+  // [[p]]
+}
+  )";
+  runDataflow(Code,
+  [](llvm::ArrayRef<
+ std::pair>>
+ Results,
+ ASTContext &ASTCtx) {
+ASSERT_THAT(Results, ElementsAre(Pair("p", _)));
+const Environment &Env = Results[0].second.Env;
+
+const ValueDecl *FooDecl = findValueDecl(ASTCtx, "Foo");
+ASSERT_THAT(FooDecl, NotNull());
+
+auto &FooVal =
+*cast(Env.getValue(*FooDecl, SkipPast::None));
+EXPECT_TRUE(Env.flowConditionImplies(FooVal));
+  },
+  {/*.ApplyBuiltinTransfer=*/true,
+   /*.BuiltinTransferOptions=*/{/*.ContextSensitive=*/true}});
+}
+
+TEST(TransferTest, ContextSensitiveConstructorInitializer) {
+  std::string Code = R"(
+class MyClass {
+public:
+  MyClass() : MyField(true) {}
+
+  bool MyField;
+};
+
+void target() {
+  MyClass MyObj;
+  bool Foo = MyObj.MyField;
+  // [[p]]
+}
+  )";
+  runDataflow(Code,
+  [](llvm::ArrayRef<
+ std::pair>>
+ Results,
+ ASTContext &ASTCtx) {
+ASSERT_THAT(Results, ElementsAre(Pair("p", _)));
+const Environment &Env = Results[0].second.Env;
+
+const ValueDecl *FooDecl = findValueDecl(ASTCtx, "Foo");
+ASSERT_THAT(FooDecl, NotNull());
+
+auto &FooVal =
+*cast(Env.getValue(*FooDecl, SkipPast::None));
+EXPECT_TRUE(Env.flowConditionImplies(FooVal));
+  },
+  {/*.ApplyBuiltinTransfer=*/true,
+   /*.BuiltinTransferOptions=*/{/*.ContextSensitive=*/true}});
+}
+
+TEST(TransferTest, ContextSensitiveConstructorDefault) {
+  std::string Code = R"(
+class MyClass {
+public:
+  MyClass() = default;
+
+  bool MyField = true;
+};
+
+void target() {
+  MyClass MyObj;
+  bool Foo = MyObj.MyField;
+  // [[p]]
+}
+  )";
+  runDataflow(Code,
+  [](llvm::ArrayRef<
+ std::pair>>
+ Results,
+ ASTContext &ASTCtx) {
+ASSERT_THAT(Results, ElementsAre(Pair("p", _)));
+const Environment &Env = Results[0].second.Env;
+
+const ValueDecl *FooDecl = findValueDecl(ASTCtx, "Foo");
+ASSERT_THAT(FooDecl, NotNull());
+
+auto &FooVal =
+*cast(Env.getValue(*FooDecl, SkipPast::None));
+EXPECT_TRUE(Env.flowConditionImplies(FooVal));
+  },
+  {/*.ApplyBuiltinTransfer=*/true,
+   /*.BuiltinTransferOptions=*/{/*.ContextSensitive=*/true}});
+}
+
 } // namespace
Index: clang/lib/Analysis/FlowSensitive/Transfer.cpp
===
--- clang/lib/Analysis/FlowSensitive/Transfer.cpp
+++ clang/lib/Analysis/FlowSensitive/Transfer.cpp
@@ -444,6 +444,8 @@
 Env.setStorageLocation(*S, Loc);
 if (Value *Val = Env.createValue(S->getType()))
   Env.setValue(Loc, *Val);
+
+transferInlineCall(S, ConstructorDecl);
   }
 
   void VisitCXXOperatorCallExpr(const CXXOperatorCallExpr *S) {
@@ -526,45 +528,7 @@
 return;
   Env.setStorageLocation(*S, *ArgLoc);
 } else if (const FunctionDecl *F = S->getDirectCallee()) {
-  // This case is for context-sensitive analysis.
-  if (!Options.ContextSensitive)
-return;
-
-  const ControlFlowContext *CFCtx = Env.getControlFlowContext(F);
-  if (!CFCtx)
-return;
-
-  // FIXME: We don't support context-sensitive analysis of recursion, so
-  // we should return early here if `F` is the same as the `FunctionDecl`
-  // holding `S` itself.
-
-  auto ExitBlock = CFCtx->ge

[clang] 000c8fe - [clang][dataflow] Analyze constructor bodies

2022-08-10 Thread Sam Estep via cfe-commits

Author: Sam Estep
Date: 2022-08-10T14:01:45Z
New Revision: 000c8fef86abb7f056cbea2de99f21dca4b81bf8

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

LOG: [clang][dataflow] Analyze constructor bodies

This patch adds the ability to context-sensitively analyze constructor bodies, 
by changing `pushCall` to allow both `CallExpr` and `CXXConstructExpr`, and 
extracting the main context-sensitive logic out of `VisitCallExpr` into a new 
`transferInlineCall` method which is now also called at the end of 
`VisitCXXConstructExpr`.

Reviewed By: ymandel, sgatev, xazax.hun

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

Added: 


Modified: 
clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
clang/lib/Analysis/FlowSensitive/Transfer.cpp
clang/unittests/Analysis/FlowSensitive/TransferTest.cpp

Removed: 




diff  --git a/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h 
b/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
index 1b154010bf365..8c169005846ef 100644
--- a/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
+++ b/clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
@@ -135,7 +135,7 @@ class Environment {
   ///
   /// Requirements:
   ///
-  ///  The callee of `Call` must be a `FunctionDecl` with a body.
+  ///  The callee of `Call` must be a `FunctionDecl`.
   ///
   ///  The body of the callee must not reference globals.
   ///
@@ -143,6 +143,7 @@ class Environment {
   ///
   ///  Each argument of `Call` must already have a `StorageLocation`.
   Environment pushCall(const CallExpr *Call) const;
+  Environment pushCall(const CXXConstructExpr *Call) const;
 
   /// Moves gathered information back into `this` from a `CalleeEnv` created 
via
   /// `pushCall`.
@@ -381,6 +382,12 @@ class Environment {
   StorageLocation &skip(StorageLocation &Loc, SkipPast SP) const;
   const StorageLocation &skip(const StorageLocation &Loc, SkipPast SP) const;
 
+  /// Shared implementation of `pushCall` overloads. Note that unlike
+  /// `pushCall`, this member is invoked on the environment of the callee, not
+  /// of the caller.
+  void pushCallInternal(const FunctionDecl *FuncDecl,
+ArrayRef Args);
+
   // `DACtx` is not null and not owned by this object.
   DataflowAnalysisContext *DACtx;
 

diff  --git a/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp 
b/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
index 16c83cad9d9e3..e4af68e53e14e 100644
--- a/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
+++ b/clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp
@@ -207,52 +207,68 @@ Environment::Environment(DataflowAnalysisContext &DACtx,
 
 Environment Environment::pushCall(const CallExpr *Call) const {
   Environment Env(*this);
-  // FIXME: Support references here.
-  Env.ReturnLoc = Env.getStorageLocation(*Call, SkipPast::Reference);
-
-  const auto *FuncDecl = Call->getDirectCallee();
-  assert(FuncDecl != nullptr);
 
-  Env.setDeclCtx(FuncDecl);
-
-  // FIXME: In order to allow the callee to reference globals, we probably need
-  // to call `initGlobalVars` here in some way.
+  // FIXME: Support references here.
+  Env.ReturnLoc = getStorageLocation(*Call, SkipPast::Reference);
 
   if (const auto *MethodCall = dyn_cast(Call)) {
 if (const Expr *Arg = MethodCall->getImplicitObjectArgument()) {
-  Env.ThisPointeeLoc = Env.getStorageLocation(*Arg, SkipPast::Reference);
+  Env.ThisPointeeLoc = getStorageLocation(*Arg, SkipPast::Reference);
 }
   }
 
+  Env.pushCallInternal(Call->getDirectCallee(),
+   llvm::makeArrayRef(Call->getArgs(), 
Call->getNumArgs()));
+
+  return Env;
+}
+
+Environment Environment::pushCall(const CXXConstructExpr *Call) const {
+  Environment Env(*this);
+
+  // FIXME: Support references here.
+  Env.ReturnLoc = getStorageLocation(*Call, SkipPast::Reference);
+
+  Env.ThisPointeeLoc = Env.ReturnLoc;
+
+  Env.pushCallInternal(Call->getConstructor(),
+   llvm::makeArrayRef(Call->getArgs(), 
Call->getNumArgs()));
+
+  return Env;
+}
+
+void Environment::pushCallInternal(const FunctionDecl *FuncDecl,
+   ArrayRef Args) {
+  setDeclCtx(FuncDecl);
+
+  // FIXME: In order to allow the callee to reference globals, we probably need
+  // to call `initGlobalVars` here in some way.
+
   auto ParamIt = FuncDecl->param_begin();
-  auto ArgIt = Call->arg_begin();
-  auto ArgEnd = Call->arg_end();
 
   // FIXME: Parameters don't always map to arguments 1:1; examples include
   // overloaded operators implemented as member functions, and parameter packs.
-  for (; ArgIt != ArgEnd; ++ParamIt, ++ArgI

[PATCH] D131438: [clang][dataflow] Analyze constructor bodies

2022-08-10 Thread Sam Estep 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 rG000c8fef86ab: [clang][dataflow] Analyze constructor bodies 
(authored by samestep).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131438

Files:
  clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h
  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
@@ -4368,4 +4368,106 @@
/*.BuiltinTransferOptions=*/{/*.ContextSensitive=*/true}});
 }
 
+TEST(TransferTest, ContextSensitiveConstructorBody) {
+  std::string Code = R"(
+class MyClass {
+public:
+  MyClass() { MyField = true; }
+
+  bool MyField;
+};
+
+void target() {
+  MyClass MyObj;
+  bool Foo = MyObj.MyField;
+  // [[p]]
+}
+  )";
+  runDataflow(Code,
+  [](llvm::ArrayRef<
+ std::pair>>
+ Results,
+ ASTContext &ASTCtx) {
+ASSERT_THAT(Results, ElementsAre(Pair("p", _)));
+const Environment &Env = Results[0].second.Env;
+
+const ValueDecl *FooDecl = findValueDecl(ASTCtx, "Foo");
+ASSERT_THAT(FooDecl, NotNull());
+
+auto &FooVal =
+*cast(Env.getValue(*FooDecl, SkipPast::None));
+EXPECT_TRUE(Env.flowConditionImplies(FooVal));
+  },
+  {/*.ApplyBuiltinTransfer=*/true,
+   /*.BuiltinTransferOptions=*/{/*.ContextSensitive=*/true}});
+}
+
+TEST(TransferTest, ContextSensitiveConstructorInitializer) {
+  std::string Code = R"(
+class MyClass {
+public:
+  MyClass() : MyField(true) {}
+
+  bool MyField;
+};
+
+void target() {
+  MyClass MyObj;
+  bool Foo = MyObj.MyField;
+  // [[p]]
+}
+  )";
+  runDataflow(Code,
+  [](llvm::ArrayRef<
+ std::pair>>
+ Results,
+ ASTContext &ASTCtx) {
+ASSERT_THAT(Results, ElementsAre(Pair("p", _)));
+const Environment &Env = Results[0].second.Env;
+
+const ValueDecl *FooDecl = findValueDecl(ASTCtx, "Foo");
+ASSERT_THAT(FooDecl, NotNull());
+
+auto &FooVal =
+*cast(Env.getValue(*FooDecl, SkipPast::None));
+EXPECT_TRUE(Env.flowConditionImplies(FooVal));
+  },
+  {/*.ApplyBuiltinTransfer=*/true,
+   /*.BuiltinTransferOptions=*/{/*.ContextSensitive=*/true}});
+}
+
+TEST(TransferTest, ContextSensitiveConstructorDefault) {
+  std::string Code = R"(
+class MyClass {
+public:
+  MyClass() = default;
+
+  bool MyField = true;
+};
+
+void target() {
+  MyClass MyObj;
+  bool Foo = MyObj.MyField;
+  // [[p]]
+}
+  )";
+  runDataflow(Code,
+  [](llvm::ArrayRef<
+ std::pair>>
+ Results,
+ ASTContext &ASTCtx) {
+ASSERT_THAT(Results, ElementsAre(Pair("p", _)));
+const Environment &Env = Results[0].second.Env;
+
+const ValueDecl *FooDecl = findValueDecl(ASTCtx, "Foo");
+ASSERT_THAT(FooDecl, NotNull());
+
+auto &FooVal =
+*cast(Env.getValue(*FooDecl, SkipPast::None));
+EXPECT_TRUE(Env.flowConditionImplies(FooVal));
+  },
+  {/*.ApplyBuiltinTransfer=*/true,
+   /*.BuiltinTransferOptions=*/{/*.ContextSensitive=*/true}});
+}
+
 } // namespace
Index: clang/lib/Analysis/FlowSensitive/Transfer.cpp
===
--- clang/lib/Analysis/FlowSensitive/Transfer.cpp
+++ clang/lib/Analysis/FlowSensitive/Transfer.cpp
@@ -444,6 +444,8 @@
 Env.setStorageLocation(*S, Loc);
 if (Value *Val = Env.createValue(S->getType()))
   Env.setValue(Loc, *Val);
+
+transferInlineCall(S, ConstructorDecl);
   }
 
   void VisitCXXOperatorCallExpr(const CXXOperatorCallExpr *S) {
@@ -526,45 +528,7 @@
 return;
   Env.setStorageLocation(*S, *ArgLoc);
 } else if (const FunctionDecl *F = S->getDirectCallee()) {
-  // This case is for context-sensitive analysis.
-  if (!Options.ContextSensitive)
-return;
-
-  const ControlFlowContext *CFCtx = Env.getControlFlowContext(F);
-  if (!CFCtx)
-return;
-
-  // FIXME: We don't support context-sensitive analysis of recursion, so
-  // we sh

[PATCH] D130033: [HLSL] Add resource binding attribute for HLSL.

2022-08-10 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/Attr.td:150
+[{isa(S)}],
+"global functions">;
 

This string literal looks suspiciously wrong to me. This is the text that shows 
up in a diagnostic message, so it's important to get it correct; so it seems 
like there's missing test coverage for the attribute.



Comment at: clang/include/clang/Basic/Attr.td:4022
+  let LangOpts = [HLSL];
+  let Args = [StringArgument<"Slot", 1>, StringArgument<"Space", 1>];
+  let Documentation = [HLSLResourceBindingDocs];

Do you really intend `Slot` to be optional?



Comment at: clang/include/clang/Basic/AttrDocs.td:6545
+The resource binding attribute sets the virtual register and logical register 
space for a resource.
+Attribute spelling in HLSL is: ``register(slot [, space])``.
+``slot`` takes the format ``[type][number]``,

This documentation says `slot` is mandatory, hence the question above about the 
argument.



Comment at: clang/include/clang/Basic/AttrDocs.td:6556
+Register space is specified in the format ``space[number]`` and defaults to 
``space0`` if omitted.
+
+The full documentation is available here: 
https://docs.microsoft.com/en-us/windows/win32/direct3d12/resource-binding-in-hlsl

I think it would help to have a working example here that shows both slot 
without space and slot with space.



Comment at: clang/include/clang/Basic/DiagnosticParseKinds.td:1609
 def err_unknown_hlsl_semantic : Error<"unknown HLSL semantic %0">;
+
 def ext_hlsl_access_specifiers : ExtWarn<

Unintended whitespace change.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:11650
 def err_hlsl_attribute_param_mismatch : Error<"%0 attribute parameters do not 
match the previous declaration">;
+def err_hlsl_empty_register_attr : Error<"register attribute cannot be empty">;
+def err_hlsl_unsupported_register_type : Error<"register type is unrecognized; 
expected resource class specifier 'b', 's', 't', 'u'">;

This diagnostic is not necessary; the common attribute handler already covers 
this. You're missing test coverage to verify that though.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:11651
+def err_hlsl_empty_register_attr : Error<"register attribute cannot be empty">;
+def err_hlsl_unsupported_register_type : Error<"register type is unrecognized; 
expected resource class specifier 'b', 's', 't', 'u'">;
+def err_hlsl_unsupported_register_number : Error<"register number should be an 
integer">;

Will a user be able to determine how to fix the issue from this? Mostly, will 
it be clear what the "resource class specifier" is that they have incorrect? 
Perhaps it would help to say `invalid resource class specifier '%0' used; 
expected 'b', 's', 't', or 'u'`?



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:11653-11654
+def err_hlsl_unsupported_register_number : Error<"register number should be an 
integer">;
+def err_hlsl_expected_space : Error<"expected space argument specified as 
'spaceX', where X is an integer">;
+def err_hlsl_unsupported_space_number : Error<"space number should be an 
integer">;
 

I don't know what the difference is between these two diagnostics; they seem to 
be the same situation. Also 'spaceX' looks like syntax the user wrote, but it's 
hardcoded in the diagnostic. Can these be replaced with `invalid space 
specifier '%0' used; expected 'space' followed by an integer` or something 
along those lines?

(Do we want to be kind and give users a fix-it for something like `space 10` 
that removes the whitespace and recovers by pretending the user wrote `space10` 
instead? Similar question about whitespace for register type.)



Comment at: clang/include/clang/Parse/Parser.h:2821
   SourceLocation *EndLoc = nullptr);
+
   Decl *ParseHLSLBuffer(SourceLocation &DeclEnd,

Spurious whitespace change that can be backed out.



Comment at: clang/lib/Parse/ParseHLSL.cpp:121-122
+  } break;
+  default:
+break;
+  }

This seems like a situation we should be asserting, right?



Comment at: clang/lib/Sema/SemaDeclAttr.cpp:6939-6942
+  if (AL.getNumArgs() == 0) {
+S.Diag(AL.getLoc(), diag::err_hlsl_empty_register_attr);
+return;
+  }

This code should not be necessary as the common handler should take care of it 
for you.



Comment at: clang/lib/Sema/SemaDeclAttr.cpp:6949
+  if (!AL.isArgIdent(0)) {
+S.Diag(ArgLoc, diag::err_hlsl_unsupported_register_type);
+return;

This diagnostic is wrong, it should be firing:   `S.Diag(AL.getLoc(), 
diag::err_attribute_argument_type) << AL << AAN

[PATCH] D118996: [clang-tidy] Support C++14 in bugprone-signal-handler.

2022-08-10 Thread Balázs Kéri via Phabricator via cfe-commits
balazske added a comment.

In D118996#3712218 , @RKSimon wrote:

> @balazske This is failing on 
> https://lab.llvm.org/buildbot/#/builders/139/builds/26335 - do you have a fix 
> in progress or should I revert?

Fix is not in progress, it may take some days.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118996

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


[PATCH] D131526: [OMPIRBuilder] Add support for safelen clause

2022-08-10 Thread Prabhdeep Soni via Phabricator via cfe-commits
psoni2628 updated this revision to Diff 451449.
psoni2628 added a comment.

- Add comments based on reviewer's feedback
- Rebase


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

https://reviews.llvm.org/D131526

Files:
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/test/OpenMP/irbuilder_safelen.cpp
  clang/test/OpenMP/irbuilder_simdlen_safelen.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
  llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
  llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
  mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp

Index: mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
===
--- mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
+++ mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
@@ -973,7 +973,7 @@
   ompBuilder->applySimd(
   loopInfo,
   loop.if_expr() ? moduleTranslation.lookupValue(loop.if_expr()) : nullptr,
-  simdlen);
+  simdlen, nullptr);
 
   builder.restoreIP(afterIP);
   return success();
Index: llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
===
--- llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
+++ llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
@@ -1771,7 +1771,8 @@
   CanonicalLoopInfo *CLI = buildSingleLoopFunction(DL, OMPBuilder, 32);
 
   // Simd-ize the loop.
-  OMPBuilder.applySimd(CLI, /* IfCond */ nullptr, /* Simdlen */ nullptr);
+  OMPBuilder.applySimd(CLI, /* IfCond */ nullptr, /* Simdlen */ nullptr,
+   /* Safelen */ nullptr);
 
   OMPBuilder.finalize();
   EXPECT_FALSE(verifyModule(*M, &errs()));
@@ -1802,8 +1803,9 @@
   CanonicalLoopInfo *CLI = buildSingleLoopFunction(DL, OMPBuilder, 32);
 
   // Simd-ize the loop.
-  OMPBuilder.applySimd(CLI, /*IfCond */ nullptr,
-   ConstantInt::get(Type::getInt32Ty(Ctx), 3));
+  OMPBuilder.applySimd(CLI, /* IfCond */ nullptr,
+   ConstantInt::get(Type::getInt32Ty(Ctx), 3),
+   /* Safelen */ nullptr);
 
   OMPBuilder.finalize();
   EXPECT_FALSE(verifyModule(*M, &errs()));
@@ -1829,6 +1831,74 @@
   }));
 }
 
+TEST_F(OpenMPIRBuilderTest, ApplySafelen) {
+  OpenMPIRBuilder OMPBuilder(*M);
+
+  CanonicalLoopInfo *CLI = buildSingleLoopFunction(DL, OMPBuilder, 32);
+
+  // Simd-ize the loop.
+  OMPBuilder.applySimd(CLI, /* IfCond */ nullptr,
+   /* Simdlen */ nullptr,
+   ConstantInt::get(Type::getInt32Ty(Ctx), 3));
+
+  OMPBuilder.finalize();
+  EXPECT_FALSE(verifyModule(*M, &errs()));
+
+  PassBuilder PB;
+  FunctionAnalysisManager FAM;
+  PB.registerFunctionAnalyses(FAM);
+  LoopInfo &LI = FAM.getResult(*F);
+
+  const std::vector &TopLvl = LI.getTopLevelLoops();
+  EXPECT_EQ(TopLvl.size(), 1u);
+
+  Loop *L = TopLvl.front();
+  EXPECT_FALSE(findStringMetadataForLoop(L, "llvm.loop.parallel_accesses"));
+  EXPECT_TRUE(getBooleanLoopAttribute(L, "llvm.loop.vectorize.enable"));
+  EXPECT_EQ(getIntLoopAttribute(L, "llvm.loop.vectorize.width"), 3);
+
+  // Check for llvm.access.group metadata attached to the printf
+  // function in the loop body.
+  BasicBlock *LoopBody = CLI->getBody();
+  EXPECT_FALSE(any_of(*LoopBody, [](Instruction &I) {
+return I.getMetadata("llvm.access.group") != nullptr;
+  }));
+}
+
+TEST_F(OpenMPIRBuilderTest, ApplySimdlenSafelen) {
+  OpenMPIRBuilder OMPBuilder(*M);
+
+  CanonicalLoopInfo *CLI = buildSingleLoopFunction(DL, OMPBuilder, 32);
+
+  // Simd-ize the loop.
+  OMPBuilder.applySimd(CLI, /* IfCond */ nullptr,
+   ConstantInt::get(Type::getInt32Ty(Ctx), 2),
+   ConstantInt::get(Type::getInt32Ty(Ctx), 3));
+
+  OMPBuilder.finalize();
+  EXPECT_FALSE(verifyModule(*M, &errs()));
+
+  PassBuilder PB;
+  FunctionAnalysisManager FAM;
+  PB.registerFunctionAnalyses(FAM);
+  LoopInfo &LI = FAM.getResult(*F);
+
+  const std::vector &TopLvl = LI.getTopLevelLoops();
+  EXPECT_EQ(TopLvl.size(), 1u);
+
+  Loop *L = TopLvl.front();
+  EXPECT_FALSE(findStringMetadataForLoop(L, "llvm.loop.parallel_accesses"));
+  EXPECT_TRUE(getBooleanLoopAttribute(L, "llvm.loop.vectorize.enable"));
+  EXPECT_EQ(getIntLoopAttribute(L, "llvm.loop.vectorize.width"), 2);
+
+  // Check for llvm.access.group metadata attached to the printf
+  // function in the loop body.
+  BasicBlock *LoopBody = CLI->getBody();
+  EXPECT_FALSE(any_of(*LoopBody, [](Instruction &I) {
+return I.getMetadata("llvm.access.group") != nullptr;
+  }));
+}
+
 TEST_F(OpenMPIRBuilderTest, ApplySimdLoopIf) {
   OpenMPIRBuilder OMPBuilder(*M);
   IRBuilder<> Builder(BB);
@@ -1846,7 +1916,8 @@
   CanonicalLoopInfo *CLI = buildSingleLoopFunction(DL, OMPBuilder, 32);
 
   // Simd-ize the loop with if condition
-  OMPBuilder.applySimd(CLI, IfCmp, ConstantInt::get(Type::getInt32Ty(Ctx), 3));
+  OMPBuilder.applySimd(CLI, IfCmp, ConstantInt::get(Type::getInt32Ty(Ctx)

[clang] e4642d7 - [clang] Correct documentation for NEON and SVE operator support

2022-08-10 Thread David Truby via cfe-commits

Author: David Truby
Date: 2022-08-10T15:16:38+01:00
New Revision: e4642d78a89930720bc84a4775614c45327bc0dc

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

LOG: [clang] Correct documentation for NEON and SVE operator support

Previously the language extension documentation didn't mention SVE and
was incomplete in listing the C/C++ operators supported on NEON. This
corrects the documentation to be in line with the implementation.

Added: 


Modified: 
clang/docs/LanguageExtensions.rst

Removed: 




diff  --git a/clang/docs/LanguageExtensions.rst 
b/clang/docs/LanguageExtensions.rst
index a6d02b2e02c15..3b80289fd5fe9 100644
--- a/clang/docs/LanguageExtensions.rst
+++ b/clang/docs/LanguageExtensions.rst
@@ -400,7 +400,7 @@ Builtin Macros
 Vectors and Extended Vectors
 
 
-Supports the GCC, OpenCL, AltiVec and NEON vector extensions.
+Supports the GCC, OpenCL, AltiVec, NEON and SVE vector extensions.
 
 OpenCL vector types are created using the ``ext_vector_type`` attribute.  It
 supports the ``V.xyzw`` syntax and other tidbits as seen in OpenCL.  An example
@@ -539,32 +539,33 @@ The table below shows the support for each operation by 
vector extension.  A
 dash indicates that an operation is not accepted according to a corresponding
 specification.
 
-== === === = ===
- Operator  OpenCL  AltiVec GCCNEON
-== === === = ===
-[]   yes yes   yes --
-unary operators +, --yes yes   yes --
-++, -- --yes yes   yes --
-+,--,*,/,%   yes yes   yes --
-bitwise operators &,|,^,~yes yes   yes --
->>,<, <, >=, <= yes yes   yes --
-=yes yes   yes yes
-?: [#]_  yes --yes --
-sizeof   yes yes   yes yes
-C-style cast yes yes   yes no
-reinterpret_cast yes noyes no
-static_cast  yes noyes no
-const_cast   no  nono  no
-address &v[i]no  nono [#]_ no
-== === === = ===
+== === === = === =
+ Operator  OpenCL  AltiVec GCCNEONSVE
+== === === = === =
+[]   yes yes   yes yesyes
+unary operators +, --yes yes   yes yesyes
+++, -- --yes yes   yes no no
++,--,*,/,%   yes yes   yes yesyes
+bitwise operators &,|,^,~yes yes   yes yesyes
+>>,<, <, >=, <= yes yes   yes yesyes
+=yes yes   yes yesyes
+?: [#]_  yes --yes yesyes
+sizeof   yes yes   yes yesyes
+C-style cast yes yes   yes no no
+reinterpret_cast yes noyes no no
+static_cast  yes noyes no no
+const_cast   no  nono  no no
+address &v[i]no  nono [#]_ no no
+== === === = === =
 
 See also :ref:`langext-__builtin_shufflevector`, 
:ref:`langext-__builtin_convertvector`.
 
 .. [#] ternary operator(?:) has 
diff erent behaviors depending on condition
   operand's vector type. If the condition is a GNU vector (i.e. 
__vector_size__),
-  it's only available in C++ and uses normal bool conversions (that is, != 0).
+  a NEON vector or an SVE vector, it's only available in C++ and uses normal 
bool
+  conversions (that is, != 0).
   If it's an extension (OpenCL) vector, it's only available in C and OpenCL C.
   And it selects base on signedness of the condition operands (OpenCL v1.1 
s6.3.9).

[PATCH] D131479: Handle explicitly defaulted consteval special members.

2022-08-10 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov accepted this revision.
ilya-biryukov added a comment.
This revision is now accepted and ready to land.

LGTM from my side. Thanks for explaining, I was confused because I looked at 
the code right after defaulted check and thought we were working around that 
particular error.
Turns out this is not the case and the change was actually marking the function 
as consteval, just as was expected.

@aaron.ballman, could you also take a quick look here?




Comment at: clang/test/SemaCXX/cxx2a-consteval.cpp:857
+consteval int aConstevalFunction() { // expected-error {{consteval function 
never produces a constant expression}}
+  // Defaulted default constructors are consteval.
+  S s1;

NIT


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131479

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


[PATCH] D131547: [Clang][AArch64] Use generic extract/insert vector for svget/svset/svcreate tuples

2022-08-10 Thread Caroline via Phabricator via cfe-commits
CarolineConcatto added a comment.

> Are you intending to AutoUpgrade the existing intrinsics in IR?

@RKSimon  
AFAIK we want to remove them altogether. 
It is not expected that external projects depend on these intrinsics.
It is a legacy intrinsic that was introduced before we had vector.extract and 
vector.insert




Comment at: clang/lib/CodeGen/CGBuiltin.cpp:9091
+
+Value *CodeGenFunction::EmmitSVEGetTuples(const SVETypeFlags &TypeFlags,
+  llvm::Type *Ty,

sdesmalen wrote:
> nit: Can this function be merged with the function above, you could pass 
> `bool IsInsert`?
I did what you suggested. Don't know if it is much better.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131547

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


[clang-tools-extra] 2534041 - Revert rGa772f775a2ba401e95a0bbe73deb6300f1dc12c0 "[clang-tidy] Support C++14 in bugprone-signal-handler."

2022-08-10 Thread Simon Pilgrim via cfe-commits

Author: Simon Pilgrim
Date: 2022-08-10T15:25:04+01:00
New Revision: 25340410c9a574d438b8868630fc8a9297d03dd7

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

LOG: Revert rGa772f775a2ba401e95a0bbe73deb6300f1dc12c0 "[clang-tidy] Support 
C++14 in bugprone-signal-handler."

This was breaking a number of buildbots: 
https://lab.llvm.org/buildbot/#/builders/139/builds/26335

Added: 


Modified: 
clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.h
clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp
clang-tools-extra/docs/ReleaseNotes.rst
clang-tools-extra/docs/clang-tidy/checks/bugprone/signal-handler.rst
clang-tools-extra/docs/clang-tidy/checks/list.rst
clang-tools-extra/test/clang-tidy/checkers/Inputs/Headers/signal.h
clang-tools-extra/test/clang-tidy/checkers/bugprone/signal-handler.c

Removed: 
clang-tools-extra/docs/clang-tidy/checks/cert/msc54-cpp.rst

clang-tools-extra/test/clang-tidy/checkers/bugprone/Inputs/signal-handler/stdcpp.h
clang-tools-extra/test/clang-tidy/checkers/bugprone/signal-handler.cpp



diff  --git a/clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp 
b/clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
index fc91d79f26a65..132fbf85c1fe6 100644
--- a/clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
+++ b/clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
@@ -22,7 +22,6 @@ constexpr llvm::StringLiteral MinimalConformingFunctions[] = {
 // mentioned POSIX specification was not updated after 'quick_exit' appeared
 // in the C11 standard.
 // Also, we want to keep the "minimal set" a subset of the "POSIX set".
-// The list is repeated in bugprone-signal-handler.rst and should be kept up 
to date.
 constexpr llvm::StringLiteral POSIXConformingFunctions[] = {
 "_Exit",
 "_exit",
@@ -278,25 +277,6 @@ bool isStandardFunction(const FunctionDecl *FD) {
   FD->getCanonicalDecl()->getLocation());
 }
 
-/// Check if a statement is "C++-only".
-/// This includes all statements that have a class name with "CXX" prefix
-/// and every other statement that is declared in file ExprCXX.h.
-bool isCXXOnlyStmt(const Stmt *S) {
-  StringRef Name = S->getStmtClassName();
-  if (Name.startswith("CXX"))
-return true;
-  // Check for all other class names in ExprCXX.h that have no 'CXX' prefix.
-  return isa(S);
-}
-
 /// Given a call graph node of a \p Caller function and a \p Callee that is
 /// called from \p Caller, get a \c CallExpr of the corresponding function 
call.
 /// It is unspecified which call is found if multiple calls exist, but the 
order
@@ -311,18 +291,6 @@ Expr *findCallExpr(const CallGraphNode *Caller, const 
CallGraphNode *Callee) {
   return FoundCallee->CallExpr;
 }
 
-SourceRange getSourceRangeOfStmt(const Stmt *S, ASTContext &Ctx) {
-  ParentMapContext &PM = Ctx.getParentMapContext();
-  DynTypedNode P = DynTypedNode::create(*S);
-  while (P.getSourceRange().isInvalid()) {
-DynTypedNodeList PL = PM.getParents(P);
-if (PL.size() != 1)
-  return {};
-P = PL[0];
-  }
-  return P.getSourceRange();
-}
-
 } // namespace
 
 AST_MATCHER(FunctionDecl, isStandardFunction) {
@@ -349,7 +317,11 @@ void 
SignalHandlerCheck::storeOptions(ClangTidyOptions::OptionMap &Opts) {
 
 bool SignalHandlerCheck::isLanguageVersionSupported(
 const LangOptions &LangOpts) const {
-  return !LangOpts.CPlusPlus17;
+  // FIXME: Make the checker useful on C++ code.
+  if (LangOpts.CPlusPlus)
+return false;
+
+  return true;
 }
 
 void SignalHandlerCheck::registerMatchers(MatchFinder *Finder) {
@@ -360,23 +332,13 @@ void SignalHandlerCheck::registerMatchers(MatchFinder 
*Finder) {
   unless(isExpandedFromMacro("SIG_IGN")),
   unless(isExpandedFromMacro("SIG_DFL")))
   .bind("handler_expr");
-  auto HandlerLambda = cxxMemberCallExpr(
-  on(expr(ignoringParenImpCasts(lambdaExpr().bind("handler_lambda");
-  Finder->addMatcher(callExpr(callee(SignalFunction),
-  hasArgument(1, anyOf(HandlerExpr, 
HandlerLambda)))
- .bind("register_call"),
- this);
+  Finder->addMatcher(
+  callExpr(callee(SignalFunction), hasArgument(1, HandlerExpr))
+  .bind("register_call"),
+  this);
 }
 
 void SignalHandlerCheck::check(const MatchFinder::MatchResult &Result) {
-  if (const auto *HandlerLambda =
-  Result.Nodes.getNodeAs("handler_lambda")) {
-diag(HandlerLambda->getBeginLoc(),
- "lambda function is not allowed as signal handler (until C++17)")
-<< HandlerLambda->getSourceRange();
-return;
-  }
-
   const auto *HandlerDecl =
   Result.Nodes.getNodeAs("handle

[PATCH] D131528: [Clang] Restrict non fixed enum to a value outside the range of the enumeration values warning to context requiring a constant expression

2022-08-10 Thread Adhemerval Zanella via Phabricator via cfe-commits
zatrazz added a comment.

It does help on test-suite, thanks.


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

https://reviews.llvm.org/D131528

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


[PATCH] D131563: [WIP] [clang] Fix clang multiarch isssue with musl

2022-08-10 Thread Brahmajit via Phabricator via cfe-commits
listout updated this revision to Diff 451452.
listout added a comment.
Herald added subscribers: pcwang-thead, luke957, s.egerton, simoncook.

Less drastic changes and rebased with main


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

https://reviews.llvm.org/D131563

Files:
  clang/lib/Driver/ToolChains/Linux.cpp


Index: clang/lib/Driver/ToolChains/Linux.cpp
===
--- clang/lib/Driver/ToolChains/Linux.cpp
+++ clang/lib/Driver/ToolChains/Linux.cpp
@@ -46,6 +46,8 @@
   bool IsMipsR6 = TargetTriple.getSubArch() == llvm::Triple::MipsSubArch_r6;
   bool IsMipsN32Abi = TargetTriple.getEnvironment() == llvm::Triple::GNUABIN32;
 
+  std::string EnvName = TargetTriple.isMusl() ? "musl" : "gnu";
+
   // For most architectures, just use whatever we have rather than trying to be
   // clever.
   switch (TargetTriple.getArch()) {
@@ -61,35 +63,35 @@
 if (IsAndroid)
   return "arm-linux-androideabi";
 if (TargetEnvironment == llvm::Triple::GNUEABIHF)
-  return "arm-linux-gnueabihf";
-return "arm-linux-gnueabi";
+  return "arm-linux-" + EnvName;
+return "arm-linux-" + EnvName;
   case llvm::Triple::armeb:
   case llvm::Triple::thumbeb:
 if (TargetEnvironment == llvm::Triple::GNUEABIHF)
-  return "armeb-linux-gnueabihf";
-return "armeb-linux-gnueabi";
+  return "armeb-linux-" + EnvName;
+return "armeb-linux-" + EnvName;
   case llvm::Triple::x86:
 if (IsAndroid)
   return "i686-linux-android";
-return "i386-linux-gnu";
+return "i386-linux" + EnvName;
   case llvm::Triple::x86_64:
 if (IsAndroid)
   return "x86_64-linux-android";
 if (TargetEnvironment == llvm::Triple::GNUX32)
   return "x86_64-linux-gnux32";
-return "x86_64-linux-gnu";
+return "x86_64-linux-" + EnvName;
   case llvm::Triple::aarch64:
 if (IsAndroid)
   return "aarch64-linux-android";
-return "aarch64-linux-gnu";
+return "aarch64-linux-" + EnvName;
   case llvm::Triple::aarch64_be:
-return "aarch64_be-linux-gnu";
+return "aarch64_be-linux-" + EnvName;
 
   case llvm::Triple::m68k:
 return "m68k-linux-gnu";
 
   case llvm::Triple::mips:
-return IsMipsR6 ? "mipsisa32r6-linux-gnu" : "mips-linux-gnu";
+return IsMipsR6 ? "mipsisa32r6-linux-gnu" : "mips-linux-" + EnvName;
   case llvm::Triple::mipsel:
 if (IsAndroid)
   return "mipsel-linux-android";
@@ -119,13 +121,13 @@
   return "powerpc-linux-gnuspe";
 return "powerpc-linux-gnu";
   case llvm::Triple::ppcle:
-return "powerpcle-linux-gnu";
+return "powerpcle-linux-" EnvName;
   case llvm::Triple::ppc64:
-return "powerpc64-linux-gnu";
+return "powerpc64-linux-" + EnvName;
   case llvm::Triple::ppc64le:
-return "powerpc64le-linux-gnu";
+return "powerpc64le-linux-" + EnvName;
   case llvm::Triple::riscv64:
-return "riscv64-linux-gnu";
+return "riscv64-linux-" + EnvName;
   case llvm::Triple::sparc:
 return "sparc-linux-gnu";
   case llvm::Triple::sparcv9:


Index: clang/lib/Driver/ToolChains/Linux.cpp
===
--- clang/lib/Driver/ToolChains/Linux.cpp
+++ clang/lib/Driver/ToolChains/Linux.cpp
@@ -46,6 +46,8 @@
   bool IsMipsR6 = TargetTriple.getSubArch() == llvm::Triple::MipsSubArch_r6;
   bool IsMipsN32Abi = TargetTriple.getEnvironment() == llvm::Triple::GNUABIN32;
 
+  std::string EnvName = TargetTriple.isMusl() ? "musl" : "gnu";
+
   // For most architectures, just use whatever we have rather than trying to be
   // clever.
   switch (TargetTriple.getArch()) {
@@ -61,35 +63,35 @@
 if (IsAndroid)
   return "arm-linux-androideabi";
 if (TargetEnvironment == llvm::Triple::GNUEABIHF)
-  return "arm-linux-gnueabihf";
-return "arm-linux-gnueabi";
+  return "arm-linux-" + EnvName;
+return "arm-linux-" + EnvName;
   case llvm::Triple::armeb:
   case llvm::Triple::thumbeb:
 if (TargetEnvironment == llvm::Triple::GNUEABIHF)
-  return "armeb-linux-gnueabihf";
-return "armeb-linux-gnueabi";
+  return "armeb-linux-" + EnvName;
+return "armeb-linux-" + EnvName;
   case llvm::Triple::x86:
 if (IsAndroid)
   return "i686-linux-android";
-return "i386-linux-gnu";
+return "i386-linux" + EnvName;
   case llvm::Triple::x86_64:
 if (IsAndroid)
   return "x86_64-linux-android";
 if (TargetEnvironment == llvm::Triple::GNUX32)
   return "x86_64-linux-gnux32";
-return "x86_64-linux-gnu";
+return "x86_64-linux-" + EnvName;
   case llvm::Triple::aarch64:
 if (IsAndroid)
   return "aarch64-linux-android";
-return "aarch64-linux-gnu";
+return "aarch64-linux-" + EnvName;
   case llvm::Triple::aarch64_be:
-return "aarch64_be-linux-gnu";
+return "aarch64_be-linux-" + EnvName;
 
   case llvm::Triple::m68k:
 return "m68k-linux-gnu";
 
   case llvm::Triple::mips:
-return IsMipsR6 ? "mipsisa32r6-linux-gnu" : "mips

[PATCH] D131569: [clangd] Allow updates to be canceled after compile flags retrieval

2022-08-10 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet created this revision.
kadircet added a reviewer: ilya-biryukov.
Herald added subscribers: usaxena95, arphaman, javed.absar.
Herald added a project: All.
kadircet requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.
Herald added a project: clang-tools-extra.

Retrieving compile flags might invalidate the environment of an update
request (e.g. generating build artifacts that wasn't captured at the time of
AddDocument notification). This enables clients with such behavior to optimize
away these intermediate AST builds.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D131569

Files:
  clang-tools-extra/clangd/TUScheduler.cpp


Index: clang-tools-extra/clangd/TUScheduler.cpp
===
--- clang-tools-extra/clangd/TUScheduler.cpp
+++ clang-tools-extra/clangd/TUScheduler.cpp
@@ -894,6 +894,14 @@
   FileInputs = Inputs;
 }
 
+if (isCancelled()) {
+  log("ASTWorker skipping update {0} for file {1}", Inputs.Version,
+  FileName);
+  // Don't even emplace a preamble, as we still want the first valid update
+  // to block any further reads.
+  return;
+}
+
 log("ASTWorker building file {0} version {1} with command {2}\n[{3}]\n{4}",
 FileName, Inputs.Version, Inputs.CompileCommand.Heuristic,
 Inputs.CompileCommand.Directory,


Index: clang-tools-extra/clangd/TUScheduler.cpp
===
--- clang-tools-extra/clangd/TUScheduler.cpp
+++ clang-tools-extra/clangd/TUScheduler.cpp
@@ -894,6 +894,14 @@
   FileInputs = Inputs;
 }
 
+if (isCancelled()) {
+  log("ASTWorker skipping update {0} for file {1}", Inputs.Version,
+  FileName);
+  // Don't even emplace a preamble, as we still want the first valid update
+  // to block any further reads.
+  return;
+}
+
 log("ASTWorker building file {0} version {1} with command {2}\n[{3}]\n{4}",
 FileName, Inputs.Version, Inputs.CompileCommand.Heuristic,
 Inputs.CompileCommand.Directory,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D130689: [LLVM] Update C++ standard to 17

2022-08-10 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

Re rollout: I suggested further up to put this behind an opt-in variable. That 
would've allowed people to test this on their setups. I still think that's a 
good suggestion, and it would've identified the MSVC issue at least.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130689

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


[PATCH] D118996: [clang-tidy] Support C++14 in bugprone-signal-handler.

2022-08-10 Thread Andrew Ng via Phabricator via cfe-commits
andrewng added a comment.

In D118996#3712493 , @balazske wrote:

> In D118996#3712218 , @RKSimon wrote:
>
>> @balazske This is failing on 
>> https://lab.llvm.org/buildbot/#/builders/139/builds/26335 - do you have a 
>> fix in progress or should I revert?
>
> Fix is not in progress, it may take some days.

I believe the problem is due to target specific default settings. Therefore, 
adding an explicit target, e.g. `-target x86_64-unknown-unknown`, to the 
`%check_clang_tidy` call should fix the problem.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118996

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


[PATCH] D131563: [WIP] [clang] Fix clang multiarch isssue with musl

2022-08-10 Thread Brahmajit via Phabricator via cfe-commits
listout updated this revision to Diff 451459.
listout added a comment.

Fix missing '+'


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

https://reviews.llvm.org/D131563

Files:
  clang/lib/Driver/ToolChains/Linux.cpp


Index: clang/lib/Driver/ToolChains/Linux.cpp
===
--- clang/lib/Driver/ToolChains/Linux.cpp
+++ clang/lib/Driver/ToolChains/Linux.cpp
@@ -46,6 +46,8 @@
   bool IsMipsR6 = TargetTriple.getSubArch() == llvm::Triple::MipsSubArch_r6;
   bool IsMipsN32Abi = TargetTriple.getEnvironment() == llvm::Triple::GNUABIN32;
 
+  std::string EnvName = TargetTriple.isMusl() ? "musl" : "gnu";
+
   // For most architectures, just use whatever we have rather than trying to be
   // clever.
   switch (TargetTriple.getArch()) {
@@ -61,35 +63,35 @@
 if (IsAndroid)
   return "arm-linux-androideabi";
 if (TargetEnvironment == llvm::Triple::GNUEABIHF)
-  return "arm-linux-gnueabihf";
-return "arm-linux-gnueabi";
+  return "arm-linux-" + EnvName;
+return "arm-linux-" + EnvName;
   case llvm::Triple::armeb:
   case llvm::Triple::thumbeb:
 if (TargetEnvironment == llvm::Triple::GNUEABIHF)
-  return "armeb-linux-gnueabihf";
-return "armeb-linux-gnueabi";
+  return "armeb-linux-" + EnvName;
+return "armeb-linux-" + EnvName;
   case llvm::Triple::x86:
 if (IsAndroid)
   return "i686-linux-android";
-return "i386-linux-gnu";
+return "i386-linux" + EnvName;
   case llvm::Triple::x86_64:
 if (IsAndroid)
   return "x86_64-linux-android";
 if (TargetEnvironment == llvm::Triple::GNUX32)
   return "x86_64-linux-gnux32";
-return "x86_64-linux-gnu";
+return "x86_64-linux-" + EnvName;
   case llvm::Triple::aarch64:
 if (IsAndroid)
   return "aarch64-linux-android";
-return "aarch64-linux-gnu";
+return "aarch64-linux-" + EnvName;
   case llvm::Triple::aarch64_be:
-return "aarch64_be-linux-gnu";
+return "aarch64_be-linux-" + EnvName;
 
   case llvm::Triple::m68k:
 return "m68k-linux-gnu";
 
   case llvm::Triple::mips:
-return IsMipsR6 ? "mipsisa32r6-linux-gnu" : "mips-linux-gnu";
+return IsMipsR6 ? "mipsisa32r6-linux-gnu" : "mips-linux-" + EnvName;
   case llvm::Triple::mipsel:
 if (IsAndroid)
   return "mipsel-linux-android";
@@ -119,13 +121,13 @@
   return "powerpc-linux-gnuspe";
 return "powerpc-linux-gnu";
   case llvm::Triple::ppcle:
-return "powerpcle-linux-gnu";
+return "powerpcle-linux-" + EnvName;
   case llvm::Triple::ppc64:
-return "powerpc64-linux-gnu";
+return "powerpc64-linux-" + EnvName;
   case llvm::Triple::ppc64le:
-return "powerpc64le-linux-gnu";
+return "powerpc64le-linux-" + EnvName;
   case llvm::Triple::riscv64:
-return "riscv64-linux-gnu";
+return "riscv64-linux-" + EnvName;
   case llvm::Triple::sparc:
 return "sparc-linux-gnu";
   case llvm::Triple::sparcv9:


Index: clang/lib/Driver/ToolChains/Linux.cpp
===
--- clang/lib/Driver/ToolChains/Linux.cpp
+++ clang/lib/Driver/ToolChains/Linux.cpp
@@ -46,6 +46,8 @@
   bool IsMipsR6 = TargetTriple.getSubArch() == llvm::Triple::MipsSubArch_r6;
   bool IsMipsN32Abi = TargetTriple.getEnvironment() == llvm::Triple::GNUABIN32;
 
+  std::string EnvName = TargetTriple.isMusl() ? "musl" : "gnu";
+
   // For most architectures, just use whatever we have rather than trying to be
   // clever.
   switch (TargetTriple.getArch()) {
@@ -61,35 +63,35 @@
 if (IsAndroid)
   return "arm-linux-androideabi";
 if (TargetEnvironment == llvm::Triple::GNUEABIHF)
-  return "arm-linux-gnueabihf";
-return "arm-linux-gnueabi";
+  return "arm-linux-" + EnvName;
+return "arm-linux-" + EnvName;
   case llvm::Triple::armeb:
   case llvm::Triple::thumbeb:
 if (TargetEnvironment == llvm::Triple::GNUEABIHF)
-  return "armeb-linux-gnueabihf";
-return "armeb-linux-gnueabi";
+  return "armeb-linux-" + EnvName;
+return "armeb-linux-" + EnvName;
   case llvm::Triple::x86:
 if (IsAndroid)
   return "i686-linux-android";
-return "i386-linux-gnu";
+return "i386-linux" + EnvName;
   case llvm::Triple::x86_64:
 if (IsAndroid)
   return "x86_64-linux-android";
 if (TargetEnvironment == llvm::Triple::GNUX32)
   return "x86_64-linux-gnux32";
-return "x86_64-linux-gnu";
+return "x86_64-linux-" + EnvName;
   case llvm::Triple::aarch64:
 if (IsAndroid)
   return "aarch64-linux-android";
-return "aarch64-linux-gnu";
+return "aarch64-linux-" + EnvName;
   case llvm::Triple::aarch64_be:
-return "aarch64_be-linux-gnu";
+return "aarch64_be-linux-" + EnvName;
 
   case llvm::Triple::m68k:
 return "m68k-linux-gnu";
 
   case llvm::Triple::mips:
-return IsMipsR6 ? "mipsisa32r6-linux-gnu" : "mips-linux-gnu";
+return IsMipsR6 ? "mipsisa32r6-linux-gnu" : "mips-linux-" + EnvName;
   case l

[PATCH] D131526: [OMPIRBuilder] Add support for safelen clause

2022-08-10 Thread Michael Kruse via Phabricator via cfe-commits
Meinersbur added inline comments.



Comment at: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:3029-3032
+addLoopMetadata(
+CanonicalLoop,
+MDNode::get(Ctx, {MDString::get(Ctx, "llvm.loop.parallel_accesses"),
+  AccessGroup}));

Instead of calling `addLoopMetadata` repeatedly, consider collecting metadata 
in a `SmallVector` and call `addLoopMetadata` only once at the end.
```
SmallVector MDList;
if (Safelen == nullptr) {
  ... 
  MDList.push_back(MDNode::get(...));
}
...
addLoopMetadata(CanonicalLoop, MDList);
```



Comment at: llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:3048
+// parameter. Therefore, use safelen only in the absence of simdlen.
+ConstantInt *VectorizeWidth = Simdlen == nullptr ? Safelen : Simdlen;
 addLoopMetadata(

`safelen` should not mean the same as `llvm.loop.vectorize.width`. `safelen` 
could be unreasonably large to use as SIMD width or a non-power-of-2.

That being said, it's what `CGStmtOpenMP.cpp` does as well and I don't know any 
better way.


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

https://reviews.llvm.org/D131526

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


[PATCH] D130847: [clang] SourceManager: fix at SourceManager::getFileIDLoaded for the case of invalid SLockEntry

2022-08-10 Thread Ivan Murashko via Phabricator via cfe-commits
ivanmurashko updated this revision to Diff 451464.
ivanmurashko added a comment.

Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130847

Files:
  clang/lib/Basic/SourceManager.cpp


Index: clang/lib/Basic/SourceManager.cpp
===
--- clang/lib/Basic/SourceManager.cpp
+++ clang/lib/Basic/SourceManager.cpp
@@ -877,9 +877,12 @@
 I = (-LastID - 2) + 1;
 
   unsigned NumProbes;
+  bool Invalid = false;
   for (NumProbes = 0; NumProbes < 8; ++NumProbes, ++I) {
 // Make sure the entry is loaded!
-const SrcMgr::SLocEntry &E = getLoadedSLocEntry(I);
+const SrcMgr::SLocEntry &E = getLoadedSLocEntry(I, &Invalid);
+if (Invalid)
+  return FileID(); // invalid entry.
 if (E.getOffset() <= SLocOffset) {
   FileID Res = FileID::get(-int(I) - 2);
   LastFileIDLookup = Res;
@@ -897,8 +900,8 @@
   while (true) {
 ++NumProbes;
 unsigned MiddleIndex = (LessIndex - GreaterIndex) / 2 + GreaterIndex;
-const SrcMgr::SLocEntry &E = getLoadedSLocEntry(MiddleIndex);
-if (E.getOffset() == 0)
+const SrcMgr::SLocEntry &E = getLoadedSLocEntry(MiddleIndex, &Invalid);
+if (Invalid)
   return FileID(); // invalid entry.
 
 ++NumProbes;


Index: clang/lib/Basic/SourceManager.cpp
===
--- clang/lib/Basic/SourceManager.cpp
+++ clang/lib/Basic/SourceManager.cpp
@@ -877,9 +877,12 @@
 I = (-LastID - 2) + 1;
 
   unsigned NumProbes;
+  bool Invalid = false;
   for (NumProbes = 0; NumProbes < 8; ++NumProbes, ++I) {
 // Make sure the entry is loaded!
-const SrcMgr::SLocEntry &E = getLoadedSLocEntry(I);
+const SrcMgr::SLocEntry &E = getLoadedSLocEntry(I, &Invalid);
+if (Invalid)
+  return FileID(); // invalid entry.
 if (E.getOffset() <= SLocOffset) {
   FileID Res = FileID::get(-int(I) - 2);
   LastFileIDLookup = Res;
@@ -897,8 +900,8 @@
   while (true) {
 ++NumProbes;
 unsigned MiddleIndex = (LessIndex - GreaterIndex) / 2 + GreaterIndex;
-const SrcMgr::SLocEntry &E = getLoadedSLocEntry(MiddleIndex);
-if (E.getOffset() == 0)
+const SrcMgr::SLocEntry &E = getLoadedSLocEntry(MiddleIndex, &Invalid);
+if (Invalid)
   return FileID(); // invalid entry.
 
 ++NumProbes;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D131573: [clang][AArch64][SVE] Change SVE_VECTOR_OPERATORS macro for VLA vectors

2022-08-10 Thread David Truby via Phabricator via cfe-commits
DavidTruby created this revision.
Herald added subscribers: ctetreau, psnobl, kristof.beyls, tschuett.
Herald added a reviewer: efriedma.
Herald added a project: All.
DavidTruby requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

The __ARM_FEATURE_SVE_VECTOR_OPERATORS macro should be changed to
indicate that this feature is now supported on VLA vectors as well as
VLS vectors. There is a complementary PR to the ACLE spec here
https://github.com/ARM-software/acle/pull/213


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D131573

Files:
  clang/lib/Basic/Targets/AArch64.cpp
  clang/test/Preprocessor/aarch64-target-features.c


Index: clang/test/Preprocessor/aarch64-target-features.c
===
--- clang/test/Preprocessor/aarch64-target-features.c
+++ clang/test/Preprocessor/aarch64-target-features.c
@@ -150,6 +150,7 @@
 
 // RUN: %clang -target aarch64-none-linux-gnu -march=armv8-a+sve -x c -E -dM 
%s -o - | FileCheck --check-prefix=CHECK-SVE %s
 // CHECK-SVE: __ARM_FEATURE_SVE 1
+// CHECK-SVE: __ARM_FEATURE_SVE_VECTOR_OPERATORS 2
 
 // RUN: %clang -target aarch64-none-linux-gnu -march=armv8-a+sve+bf16 -x c -E 
-dM %s -o - | FileCheck --check-prefix=CHECK-SVE-BF16 %s
 // CHECK-SVE-BF16: __ARM_FEATURE_BF16_SCALAR_ARITHMETIC 1
@@ -512,9 +513,7 @@
 // RUN: %clang -target aarch64-arm-none-eabi -march=armv8-a+sve 
-msve-vector-bits=2048 -x c -E -dM %s -o - 2>&1 | FileCheck 
-check-prefix=CHECK-SVE-VECTOR-BITS -D#VBITS=2048 %s
 // RUN: %clang -target aarch64-arm-none-eabi -march=armv8-a+sve 
-msve-vector-bits=512+ -x c -E -dM %s -o - 2>&1 | FileCheck 
-check-prefix=CHECK-NO-SVE-VECTOR-BITS %s
 // CHECK-SVE-VECTOR-BITS: __ARM_FEATURE_SVE_BITS [[#VBITS:]]
-// CHECK-SVE-VECTOR-BITS: __ARM_FEATURE_SVE_VECTOR_OPERATORS 1
 // CHECK-NO-SVE-VECTOR-BITS-NOT: __ARM_FEATURE_SVE_BITS
-// CHECK-NO-SVE-VECTOR-BITS-NOT: __ARM_FEATURE_SVE_VECTOR_OPERATORS
 
 // == Check Large System Extensions (LSE)
 // RUN: %clang -target aarch64-none-linux-gnu -march=armv8-a+lse -x c -E -dM 
%s -o - | FileCheck --check-prefix=CHECK-LSE %s
Index: clang/lib/Basic/Targets/AArch64.cpp
===
--- clang/lib/Basic/Targets/AArch64.cpp
+++ clang/lib/Basic/Targets/AArch64.cpp
@@ -489,9 +489,12 @@
   Builder.defineMacro("__FP_FAST_FMA", "1");
   Builder.defineMacro("__FP_FAST_FMAF", "1");
 
+  // C/C++ operators work on both VLS and VLA SVE types
+  if (FPU & SveMode)
+Builder.defineMacro("__ARM_FEATURE_SVE_VECTOR_OPERATORS", "2");
+
   if (Opts.VScaleMin && Opts.VScaleMin == Opts.VScaleMax) {
 Builder.defineMacro("__ARM_FEATURE_SVE_BITS", Twine(Opts.VScaleMin * 128));
-Builder.defineMacro("__ARM_FEATURE_SVE_VECTOR_OPERATORS");
   }
 }
 


Index: clang/test/Preprocessor/aarch64-target-features.c
===
--- clang/test/Preprocessor/aarch64-target-features.c
+++ clang/test/Preprocessor/aarch64-target-features.c
@@ -150,6 +150,7 @@
 
 // RUN: %clang -target aarch64-none-linux-gnu -march=armv8-a+sve -x c -E -dM %s -o - | FileCheck --check-prefix=CHECK-SVE %s
 // CHECK-SVE: __ARM_FEATURE_SVE 1
+// CHECK-SVE: __ARM_FEATURE_SVE_VECTOR_OPERATORS 2
 
 // RUN: %clang -target aarch64-none-linux-gnu -march=armv8-a+sve+bf16 -x c -E -dM %s -o - | FileCheck --check-prefix=CHECK-SVE-BF16 %s
 // CHECK-SVE-BF16: __ARM_FEATURE_BF16_SCALAR_ARITHMETIC 1
@@ -512,9 +513,7 @@
 // RUN: %clang -target aarch64-arm-none-eabi -march=armv8-a+sve -msve-vector-bits=2048 -x c -E -dM %s -o - 2>&1 | FileCheck -check-prefix=CHECK-SVE-VECTOR-BITS -D#VBITS=2048 %s
 // RUN: %clang -target aarch64-arm-none-eabi -march=armv8-a+sve -msve-vector-bits=512+ -x c -E -dM %s -o - 2>&1 | FileCheck -check-prefix=CHECK-NO-SVE-VECTOR-BITS %s
 // CHECK-SVE-VECTOR-BITS: __ARM_FEATURE_SVE_BITS [[#VBITS:]]
-// CHECK-SVE-VECTOR-BITS: __ARM_FEATURE_SVE_VECTOR_OPERATORS 1
 // CHECK-NO-SVE-VECTOR-BITS-NOT: __ARM_FEATURE_SVE_BITS
-// CHECK-NO-SVE-VECTOR-BITS-NOT: __ARM_FEATURE_SVE_VECTOR_OPERATORS
 
 // == Check Large System Extensions (LSE)
 // RUN: %clang -target aarch64-none-linux-gnu -march=armv8-a+lse -x c -E -dM %s -o - | FileCheck --check-prefix=CHECK-LSE %s
Index: clang/lib/Basic/Targets/AArch64.cpp
===
--- clang/lib/Basic/Targets/AArch64.cpp
+++ clang/lib/Basic/Targets/AArch64.cpp
@@ -489,9 +489,12 @@
   Builder.defineMacro("__FP_FAST_FMA", "1");
   Builder.defineMacro("__FP_FAST_FMAF", "1");
 
+  // C/C++ operators work on both VLS and VLA SVE types
+  if (FPU & SveMode)
+Builder.defineMacro("__ARM_FEATURE_SVE_VECTOR_OPERATORS", "2");
+
   if (Opts.VScaleMin && Opts.VScaleMin == Opts.VScaleMax) {
 Builder.defineMacro("__ARM_FEATURE_SVE_BITS", Twine(Opts.VScaleMin * 128));
-Builder.defineMacro("__ARM_FEATURE_SVE_VECTOR_OPERATORS");
   }
 }
 
__

[PATCH] D131547: [Clang][AArch64] Use generic extract/insert vector for svget/svset/svcreate tuples

2022-08-10 Thread Simon Pilgrim via Phabricator via cfe-commits
RKSimon added a comment.

In D131547#3712509 , 
@CarolineConcatto wrote:

>> Are you intending to AutoUpgrade the existing intrinsics in IR?
>
> @RKSimon  
> AFAIK we want to remove them altogether. 
> It is not expected that external projects depend on these intrinsics.
> It is a legacy intrinsic that was introduced before we had vector.extract and 
> vector.insert

OK - not sure what aarch64 policy is, but x86 we tend to continue support for 
old intrinsics that could still be in IR through AutoUpgrade.cpp which mostly 
converts them to generics (very similar to CGBuiltin) - technically we plan to 
remove the oldest at some point but we've been very loathe to actually do it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131547

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


[PATCH] D131573: [clang][AArch64][SVE] Change SVE_VECTOR_OPERATORS macro for VLA vectors

2022-08-10 Thread Peter Waller via Phabricator via cfe-commits
peterwaller-arm requested changes to this revision.
peterwaller-arm added inline comments.
This revision now requires changes to proceed.



Comment at: clang/lib/Basic/Targets/AArch64.cpp:493
+  // C/C++ operators work on both VLS and VLA SVE types
+  if (FPU & SveMode)
+Builder.defineMacro("__ARM_FEATURE_SVE_VECTOR_OPERATORS", "2");

Wrong operator?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131573

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


[PATCH] D131573: [clang][AArch64][SVE] Change SVE_VECTOR_OPERATORS macro for VLA vectors

2022-08-10 Thread Peter Waller via Phabricator via cfe-commits
peterwaller-arm accepted this revision.
peterwaller-arm added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/lib/Basic/Targets/AArch64.cpp:493
+  // C/C++ operators work on both VLS and VLA SVE types
+  if (FPU & SveMode)
+Builder.defineMacro("__ARM_FEATURE_SVE_VECTOR_OPERATORS", "2");

peterwaller-arm wrote:
> Wrong operator?
Sorry, I see I misinterpreted this, it's a bitmask check.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131573

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


[PATCH] D127695: WIP: clang: Implement Template Specialization Resugaring

2022-08-10 Thread Matheus Izvekov via Phabricator via cfe-commits
mizvekov added inline comments.



Comment at: clang/test/Sema/Resugar/resugar-expr.cpp:244
+// N-error@-2 {{with an rvalue of type 'int'}}
+} // namespace t21

davrec wrote:
> Compositions of MemberExprs/CXXMemberCallExprs have an issue:
> ```
> template  struct A {
>   struct Inner {
> A1 m;
> A1 f();
>   } inner;
>   Inner g();
> };
> Z x1 = A().inner.m; //No resugar
> Z x2 = A().inner.f(); //No resugar
> Z x3 = A().g().m; //No resugar
> Z x4 = A().g().f(); //No resugar
> Z x5 = A::Inner().m; //ok
> ```
> 
> Composed `CallExprs` seem to work but probably warrant a test, e.g.
> ```
> template  B1 h(B1);
> Z x6 = h(Int());
> Z x7 = h(h(Int()));
> ```
> 
> https://godbolt.org/z/cszrsvh8d
> 
Thanks for the feedback!

The problem here I think is that for a MemberExpr, we have to look at not only 
the BaseType of it for a resugaring context, but instead look at its BaseExpr 
to see if it or any bases of it, and so on recursively, can provide a 
resugaring context as well, effectively building one naming context from the 
whole composition.

I will try to address that later, I probably should work on facilitating the 
reviews of the other patches in this stack, and then splitting this one big 
patch up more :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127695

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


[PATCH] D131345: [RISC-V][HWASAN] Enable HWASAN for RISC-V architecture

2022-08-10 Thread Kito Cheng via Phabricator via cfe-commits
kito-cheng added a comment.

I guess we should checking `J` extension is enabled somewhere when user trying 
to enable HWASAN? or checking that at HWASAN library at run-time? otherwise my 
understanding is user will get crash when enabling HWASAN if linux and/or HW 
don't support that?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131345

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


[PATCH] D130689: [LLVM] Update C++ standard to 17

2022-08-10 Thread Tobias Hieta via Phabricator via cfe-commits
thieta added a comment.

Hi - I tried to incorporate all the feedback here and added a post to discourse 
suggesting tweaks to the developer policy - please have a look and review it: 
https://discourse.llvm.org/t/rfc-updates-to-developer-policy-around-c-standards-bump/64383


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130689

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


[clang] e78c80e - [clang] SourceManager: fix at SourceManager::getFileIDLoaded for the case of invalid SLockEntry

2022-08-10 Thread Ivan Murashko via cfe-commits

Author: Ivan Murashko
Date: 2022-08-10T16:37:42+01:00
New Revision: e78c80e3d622d455934102dabd765a60ac917739

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

LOG: [clang] SourceManager: fix at SourceManager::getFileIDLoaded for the case 
of invalid SLockEntry

There is a fix for the search procedure at `SourceManager::getFileIDLoaded`. It 
might return an invalid (not loaded) entry. That might cause clang/clangd 
crashes. At my case the scenario was the following:
- `SourceManager::getFileIDLoaded` returned an invalid file id for a non loaded 
entry and incorrectly set `SourceManager::LastFileIDLookup` to the value
- `getSLocEntry` returned `SourceManager::FakeSLocEntryForRecovery` introduced 
at [D89748](https://reviews.llvm.org/D89748).
- The result entry is not tested at `SourceManager::isOffsetInFileID`and as 
result the call `return SLocOffset < getSLocEntryByID(FID.ID+1).getOffset();` 
returned `true` value because `FID.ID+1` pointed to a non-fake entry
- The tested offset was marked as one that belonged to the fake `SLockEntry`

Such behaviour might cause a weird clangd crash when preamble contains some 
header files that were removed just after the preamble created. Unfortunately 
it's not so easy to reproduce the crash in the form of a LIT test thus I 
provided the fix only.

Test Plan:
```
ninja check-clang
```

Reviewed By: aaron.ballman

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

Added: 


Modified: 
clang/lib/Basic/SourceManager.cpp

Removed: 




diff  --git a/clang/lib/Basic/SourceManager.cpp 
b/clang/lib/Basic/SourceManager.cpp
index 98e731eb12e62..38545d1be918f 100644
--- a/clang/lib/Basic/SourceManager.cpp
+++ b/clang/lib/Basic/SourceManager.cpp
@@ -877,9 +877,12 @@ FileID 
SourceManager::getFileIDLoaded(SourceLocation::UIntTy SLocOffset) const {
 I = (-LastID - 2) + 1;
 
   unsigned NumProbes;
+  bool Invalid = false;
   for (NumProbes = 0; NumProbes < 8; ++NumProbes, ++I) {
 // Make sure the entry is loaded!
-const SrcMgr::SLocEntry &E = getLoadedSLocEntry(I);
+const SrcMgr::SLocEntry &E = getLoadedSLocEntry(I, &Invalid);
+if (Invalid)
+  return FileID(); // invalid entry.
 if (E.getOffset() <= SLocOffset) {
   FileID Res = FileID::get(-int(I) - 2);
   LastFileIDLookup = Res;
@@ -897,8 +900,8 @@ FileID 
SourceManager::getFileIDLoaded(SourceLocation::UIntTy SLocOffset) const {
   while (true) {
 ++NumProbes;
 unsigned MiddleIndex = (LessIndex - GreaterIndex) / 2 + GreaterIndex;
-const SrcMgr::SLocEntry &E = getLoadedSLocEntry(MiddleIndex);
-if (E.getOffset() == 0)
+const SrcMgr::SLocEntry &E = getLoadedSLocEntry(MiddleIndex, &Invalid);
+if (Invalid)
   return FileID(); // invalid entry.
 
 ++NumProbes;



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


[PATCH] D130847: [clang] SourceManager: fix at SourceManager::getFileIDLoaded for the case of invalid SLockEntry

2022-08-10 Thread Ivan Murashko via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGe78c80e3d622: [clang] SourceManager: fix at 
SourceManager::getFileIDLoaded for the case of… (authored by ivanmurashko).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130847

Files:
  clang/lib/Basic/SourceManager.cpp


Index: clang/lib/Basic/SourceManager.cpp
===
--- clang/lib/Basic/SourceManager.cpp
+++ clang/lib/Basic/SourceManager.cpp
@@ -877,9 +877,12 @@
 I = (-LastID - 2) + 1;
 
   unsigned NumProbes;
+  bool Invalid = false;
   for (NumProbes = 0; NumProbes < 8; ++NumProbes, ++I) {
 // Make sure the entry is loaded!
-const SrcMgr::SLocEntry &E = getLoadedSLocEntry(I);
+const SrcMgr::SLocEntry &E = getLoadedSLocEntry(I, &Invalid);
+if (Invalid)
+  return FileID(); // invalid entry.
 if (E.getOffset() <= SLocOffset) {
   FileID Res = FileID::get(-int(I) - 2);
   LastFileIDLookup = Res;
@@ -897,8 +900,8 @@
   while (true) {
 ++NumProbes;
 unsigned MiddleIndex = (LessIndex - GreaterIndex) / 2 + GreaterIndex;
-const SrcMgr::SLocEntry &E = getLoadedSLocEntry(MiddleIndex);
-if (E.getOffset() == 0)
+const SrcMgr::SLocEntry &E = getLoadedSLocEntry(MiddleIndex, &Invalid);
+if (Invalid)
   return FileID(); // invalid entry.
 
 ++NumProbes;


Index: clang/lib/Basic/SourceManager.cpp
===
--- clang/lib/Basic/SourceManager.cpp
+++ clang/lib/Basic/SourceManager.cpp
@@ -877,9 +877,12 @@
 I = (-LastID - 2) + 1;
 
   unsigned NumProbes;
+  bool Invalid = false;
   for (NumProbes = 0; NumProbes < 8; ++NumProbes, ++I) {
 // Make sure the entry is loaded!
-const SrcMgr::SLocEntry &E = getLoadedSLocEntry(I);
+const SrcMgr::SLocEntry &E = getLoadedSLocEntry(I, &Invalid);
+if (Invalid)
+  return FileID(); // invalid entry.
 if (E.getOffset() <= SLocOffset) {
   FileID Res = FileID::get(-int(I) - 2);
   LastFileIDLookup = Res;
@@ -897,8 +900,8 @@
   while (true) {
 ++NumProbes;
 unsigned MiddleIndex = (LessIndex - GreaterIndex) / 2 + GreaterIndex;
-const SrcMgr::SLocEntry &E = getLoadedSLocEntry(MiddleIndex);
-if (E.getOffset() == 0)
+const SrcMgr::SLocEntry &E = getLoadedSLocEntry(MiddleIndex, &Invalid);
+if (Invalid)
   return FileID(); // invalid entry.
 
 ++NumProbes;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D90275: [clang][IR] Add support for leaf attribute

2022-08-10 Thread Nuno Lopes via Phabricator via cfe-commits
nlopes added a comment.

In D90275#3707793 , @nlopes wrote:

> In D90275#3671983 , @gulfem wrote:
>
>> In D90275#3671019 , @nlopes wrote:
>>
>>> Could you please add a description of this attribute to LangRef?
>>> We need the semantics of this.
>>>
>>> Thank you!
>>
>> Sure, I'll do that!
>
> ping?

Since the patch author has been ignoring my ask (and is active), and since 
documenting IR features is of paramount importance, I suggest we revert this 
patch. I think 3 weeks to document something is sufficient, and the author 
didn't provide an ETA.
I would like to ask everyone to reject all future patches that change the IR 
and don't include documentation, as experience says that we'll get 
miscompilations due to different people having different ideas of the semantics.

TL;DR: I'll revert this patch on Friday if no one chimes in. Thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90275

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


[PATCH] D131580: [clang][SVE] Undefine preprocessor macro defined in

2022-08-10 Thread mgabka via Phabricator via cfe-commits
mgabka created this revision.
mgabka added a reviewer: paulwalker-arm.
Herald added subscribers: ctetreau, psnobl, kristof.beyls, tschuett.
Herald added a reviewer: efriedma.
Herald added a project: All.
mgabka requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

arm_sve.h defines and uses __ai macro which needs to be undefined (as it is
already in arm_neon.h).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D131580

Files:
  clang/utils/TableGen/SveEmitter.cpp


Index: clang/utils/TableGen/SveEmitter.cpp
===
--- clang/utils/TableGen/SveEmitter.cpp
+++ clang/utils/TableGen/SveEmitter.cpp
@@ -1282,6 +1282,7 @@
   OS << "#ifdef __cplusplus\n";
   OS << "} // extern \"C\"\n";
   OS << "#endif\n\n";
+  OS << "#undef __ai\n\n";
   OS << "#endif /*__ARM_FEATURE_SVE */\n\n";
   OS << "#endif /* __ARM_SVE_H */\n";
 }


Index: clang/utils/TableGen/SveEmitter.cpp
===
--- clang/utils/TableGen/SveEmitter.cpp
+++ clang/utils/TableGen/SveEmitter.cpp
@@ -1282,6 +1282,7 @@
   OS << "#ifdef __cplusplus\n";
   OS << "} // extern \"C\"\n";
   OS << "#endif\n\n";
+  OS << "#undef __ai\n\n";
   OS << "#endif /*__ARM_FEATURE_SVE */\n\n";
   OS << "#endif /* __ARM_SVE_H */\n";
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D131526: [OMPIRBuilder] Add support for safelen clause

2022-08-10 Thread Prabhdeep Soni via Phabricator via cfe-commits
psoni2628 updated this revision to Diff 451500.
psoni2628 added a comment.

- Add LoopMDList


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

https://reviews.llvm.org/D131526

Files:
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/test/OpenMP/irbuilder_safelen.cpp
  clang/test/OpenMP/irbuilder_simdlen_safelen.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
  llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
  llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
  mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp

Index: mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
===
--- mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
+++ mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
@@ -973,7 +973,7 @@
   ompBuilder->applySimd(
   loopInfo,
   loop.if_expr() ? moduleTranslation.lookupValue(loop.if_expr()) : nullptr,
-  simdlen);
+  simdlen, nullptr);
 
   builder.restoreIP(afterIP);
   return success();
Index: llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
===
--- llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
+++ llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
@@ -1771,7 +1771,8 @@
   CanonicalLoopInfo *CLI = buildSingleLoopFunction(DL, OMPBuilder, 32);
 
   // Simd-ize the loop.
-  OMPBuilder.applySimd(CLI, /* IfCond */ nullptr, /* Simdlen */ nullptr);
+  OMPBuilder.applySimd(CLI, /* IfCond */ nullptr, /* Simdlen */ nullptr,
+   /* Safelen */ nullptr);
 
   OMPBuilder.finalize();
   EXPECT_FALSE(verifyModule(*M, &errs()));
@@ -1802,8 +1803,9 @@
   CanonicalLoopInfo *CLI = buildSingleLoopFunction(DL, OMPBuilder, 32);
 
   // Simd-ize the loop.
-  OMPBuilder.applySimd(CLI, /*IfCond */ nullptr,
-   ConstantInt::get(Type::getInt32Ty(Ctx), 3));
+  OMPBuilder.applySimd(CLI, /* IfCond */ nullptr,
+   ConstantInt::get(Type::getInt32Ty(Ctx), 3),
+   /* Safelen */ nullptr);
 
   OMPBuilder.finalize();
   EXPECT_FALSE(verifyModule(*M, &errs()));
@@ -1829,6 +1831,74 @@
   }));
 }
 
+TEST_F(OpenMPIRBuilderTest, ApplySafelen) {
+  OpenMPIRBuilder OMPBuilder(*M);
+
+  CanonicalLoopInfo *CLI = buildSingleLoopFunction(DL, OMPBuilder, 32);
+
+  // Simd-ize the loop.
+  OMPBuilder.applySimd(CLI, /* IfCond */ nullptr,
+   /* Simdlen */ nullptr,
+   ConstantInt::get(Type::getInt32Ty(Ctx), 3));
+
+  OMPBuilder.finalize();
+  EXPECT_FALSE(verifyModule(*M, &errs()));
+
+  PassBuilder PB;
+  FunctionAnalysisManager FAM;
+  PB.registerFunctionAnalyses(FAM);
+  LoopInfo &LI = FAM.getResult(*F);
+
+  const std::vector &TopLvl = LI.getTopLevelLoops();
+  EXPECT_EQ(TopLvl.size(), 1u);
+
+  Loop *L = TopLvl.front();
+  EXPECT_FALSE(findStringMetadataForLoop(L, "llvm.loop.parallel_accesses"));
+  EXPECT_TRUE(getBooleanLoopAttribute(L, "llvm.loop.vectorize.enable"));
+  EXPECT_EQ(getIntLoopAttribute(L, "llvm.loop.vectorize.width"), 3);
+
+  // Check for llvm.access.group metadata attached to the printf
+  // function in the loop body.
+  BasicBlock *LoopBody = CLI->getBody();
+  EXPECT_FALSE(any_of(*LoopBody, [](Instruction &I) {
+return I.getMetadata("llvm.access.group") != nullptr;
+  }));
+}
+
+TEST_F(OpenMPIRBuilderTest, ApplySimdlenSafelen) {
+  OpenMPIRBuilder OMPBuilder(*M);
+
+  CanonicalLoopInfo *CLI = buildSingleLoopFunction(DL, OMPBuilder, 32);
+
+  // Simd-ize the loop.
+  OMPBuilder.applySimd(CLI, /* IfCond */ nullptr,
+   ConstantInt::get(Type::getInt32Ty(Ctx), 2),
+   ConstantInt::get(Type::getInt32Ty(Ctx), 3));
+
+  OMPBuilder.finalize();
+  EXPECT_FALSE(verifyModule(*M, &errs()));
+
+  PassBuilder PB;
+  FunctionAnalysisManager FAM;
+  PB.registerFunctionAnalyses(FAM);
+  LoopInfo &LI = FAM.getResult(*F);
+
+  const std::vector &TopLvl = LI.getTopLevelLoops();
+  EXPECT_EQ(TopLvl.size(), 1u);
+
+  Loop *L = TopLvl.front();
+  EXPECT_FALSE(findStringMetadataForLoop(L, "llvm.loop.parallel_accesses"));
+  EXPECT_TRUE(getBooleanLoopAttribute(L, "llvm.loop.vectorize.enable"));
+  EXPECT_EQ(getIntLoopAttribute(L, "llvm.loop.vectorize.width"), 2);
+
+  // Check for llvm.access.group metadata attached to the printf
+  // function in the loop body.
+  BasicBlock *LoopBody = CLI->getBody();
+  EXPECT_FALSE(any_of(*LoopBody, [](Instruction &I) {
+return I.getMetadata("llvm.access.group") != nullptr;
+  }));
+}
+
 TEST_F(OpenMPIRBuilderTest, ApplySimdLoopIf) {
   OpenMPIRBuilder OMPBuilder(*M);
   IRBuilder<> Builder(BB);
@@ -1846,7 +1916,8 @@
   CanonicalLoopInfo *CLI = buildSingleLoopFunction(DL, OMPBuilder, 32);
 
   // Simd-ize the loop with if condition
-  OMPBuilder.applySimd(CLI, IfCmp, ConstantInt::get(Type::getInt32Ty(Ctx), 3));
+  OMPBuilder.applySimd(CLI, IfCmp, ConstantInt::get(Type::getInt32Ty(Ctx), 3),
+   /* Saf

[PATCH] D90275: [clang][IR] Add support for leaf attribute

2022-08-10 Thread Gulfem Savrun Yeniceri via Phabricator via cfe-commits
gulfem added a comment.

In D90275#3712880 , @nlopes wrote:

> In D90275#3707793 , @nlopes wrote:
>
>> In D90275#3671983 , @gulfem wrote:
>>
>>> In D90275#3671019 , @nlopes wrote:
>>>
 Could you please add a description of this attribute to LangRef?
 We need the semantics of this.

 Thank you!
>>>
>>> Sure, I'll do that!
>>
>> ping?
>
> Since the patch author has been ignoring my ask (and is active), and since 
> documenting IR features is of paramount importance, I suggest we revert this 
> patch. I think 3 weeks to document something is sufficient, and the author 
> didn't provide an ETA.
> I would like to ask everyone to reject all future patches that change the IR 
> and don't include documentation, as experience says that we'll get 
> miscompilations due to different people having different ideas of the 
> semantics.
>
> TL;DR: I'll revert this patch on Friday if no one chimes in. Thank you!

I'm very sorry and I was not ignoring your ask. I'll do it now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90275

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


[PATCH] D131345: [RISC-V][HWASAN] Enable HWASAN for RISC-V architecture

2022-08-10 Thread Alexey Baturo via Phabricator via cfe-commits
smd added a comment.

In D131345#3712814 , @kito-cheng 
wrote:

> I guess we should checking `J` extension is enabled somewhere when user 
> trying to enable HWASAN? or checking that at HWASAN library at run-time? 
> otherwise my understanding is user will get crash when enabling HWASAN if 
> linux and/or HW don't support that?

It relies on a runtime check: during init runtime makes 
PR_{SET,GET}_TAGGED_ADDR_CTRL calls and if they're not supported, it fails with 
an error.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131345

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


[PATCH] D90275: [clang][IR] Add support for leaf attribute

2022-08-10 Thread Nuno Lopes via Phabricator via cfe-commits
nlopes added a comment.

In D90275#3712969 , @gulfem wrote:

> In D90275#3712880 , @nlopes wrote:
>
>> In D90275#3707793 , @nlopes wrote:
>>
>>> In D90275#3671983 , @gulfem wrote:
>>>
 In D90275#3671019 , @nlopes wrote:

> Could you please add a description of this attribute to LangRef?
> We need the semantics of this.
>
> Thank you!

 Sure, I'll do that!
>>>
>>> ping?
>>
>> Since the patch author has been ignoring my ask (and is active), and since 
>> documenting IR features is of paramount importance, I suggest we revert this 
>> patch. I think 3 weeks to document something is sufficient, and the author 
>> didn't provide an ETA.
>> I would like to ask everyone to reject all future patches that change the IR 
>> and don't include documentation, as experience says that we'll get 
>> miscompilations due to different people having different ideas of the 
>> semantics.
>>
>> TL;DR: I'll revert this patch on Friday if no one chimes in. Thank you!
>
> I'm very sorry and I was not ignoring your ask. I'll do it now.

Thanks!
I'm fine with a reasonable ETA, but we really need all IR features documented 
to avoid bugs.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90275

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


[PATCH] D131307: [Clang] Allow downgrading to a warning the diagnostic for setting a non fixed enum to a value outside the range of the enumeration values

2022-08-10 Thread Stephan Bergmann via Phabricator via cfe-commits
sberg added a comment.

With this commit,

  $ cat test.cc
  #include "boost/numeric/conversion/cast.hpp"
  int main() { return boost::numeric_cast(0L); }
  
  $ clang++ test.cc

succeeds without any diagnostic, while with its parent commit 
https://github.com/llvm/llvm-project/commit/b3645353041818f61e2580635409ddb81ff5a272
 " [Clang] Diagnose ill-formed constant expression when setting a non fixed 
enum to a value outside the range of the enumeration values" it had started to 
fail with

  In file included from test.cc:1:
  In file included from /usr/include/boost/numeric/conversion/cast.hpp:33:
  In file included from /usr/include/boost/numeric/conversion/converter.hpp:13:
  In file included from 
/usr/include/boost/numeric/conversion/conversion_traits.hpp:13:
  In file included from 
/usr/include/boost/numeric/conversion/detail/conversion_traits.hpp:18:
  In file included from 
/usr/include/boost/numeric/conversion/detail/int_float_mixture.hpp:19:
  In file included from /usr/include/boost/mpl/integral_c.hpp:32:
  /usr/include/boost/mpl/aux_/integral_wrapper.hpp:73:31: error: non-type 
template argument is not a constant expression
  typedef AUX_WRAPPER_INST( 
BOOST_MPL_AUX_STATIC_CAST(AUX_WRAPPER_VALUE_TYPE, (value - 1)) ) prior;
  
~~^~~~
  /usr/include/boost/mpl/aux_/static_cast.hpp:24:47: note: expanded from macro 
'BOOST_MPL_AUX_STATIC_CAST'
  #   define BOOST_MPL_AUX_STATIC_CAST(T, expr) static_cast(expr)
^
  /usr/include/boost/mpl/integral_c.hpp:31:54: note: expanded from macro 
'AUX_WRAPPER_INST'
  #define AUX_WRAPPER_INST(value) AUX_WRAPPER_NAME< T, value >
   ^
  /usr/include/boost/numeric/conversion/detail/meta.hpp:30:46: note: in 
instantiation of template class 
'mpl_::integral_c' requested here
 enum { x = ( BOOST_MPL_AUX_VALUE_WKND(T1)::value == 
BOOST_MPL_AUX_VALUE_WKND(T2)::value ) };
   ^
  /usr/include/boost/mpl/if.hpp:63:68: note: in instantiation of template class 
'boost::numeric::convdetail::equal_to, 
mpl_::integral_c>' requested here
BOOST_MPL_AUX_STATIC_CAST(bool, BOOST_MPL_AUX_VALUE_WKND(T1)::value)
 ^
  /usr/include/boost/mpl/eval_if.hpp:37:22: note: in instantiation of template 
class 
'boost::mpl::if_, 
mpl_::integral_c>, 
boost::mpl::identity>, 
boost::mpl::eval_if, 
mpl_::integral_c>, 
boost::mpl::identity>>, 
boost::mpl::if_, 
mpl_::integral_c>, 
boost::mpl::identity>, boost::mpl::identity' requested here
  typedef typename if_::type f_;
   ^
  /usr/include/boost/numeric/conversion/detail/meta.hpp:81:12: note: in 
instantiation of template class 
'boost::mpl::eval_if, 
mpl_::integral_c>, 
boost::mpl::identity>, 
boost::mpl::eval_if, 
mpl_::integral_c>, 
boost::mpl::identity>>, 
boost::mpl::if_, 
mpl_::integral_c>, 
boost::mpl::identity>, boost::mpl::identity' requested here
mpl::eval_if::type
 ^
  /usr/include/boost/numeric/conversion/detail/udt_builtin_mixture.hpp:41:7: 
note: in instantiation of template class 
'boost::numeric::convdetail::ct_switch4, 
mpl_::integral_c, 
mpl_::integral_c, 
mpl_::integral_c, 
boost::numeric::convdetail::get_subranged_BuiltIn2BuiltIn, 
boost::mpl::identity>, 
boost::mpl::identity>, boost::mpl::identity>>' requested here
ct_switch4::type
  ^
  /usr/include/boost/numeric/conversion/conversion_traits.hpp:22:7: note: in 
instantiation of template class 
'boost::numeric::convdetail::non_trivial_traits_impl' requested here
  : convdetail::get_conversion_traits::type
^
  /usr/include/boost/numeric/conversion/detail/converter.hpp:584:22: note: in 
instantiation of template class 'boost::numeric::conversion_traits' 
requested here
  typedef typename Traits::trivial trivial ;
   ^
  /usr/include/boost/numeric/conversion/converter.hpp:29:32: note: in 
instantiation of template class 
'boost::numeric::convdetail::get_converter_impl, boost::numeric::def_overflow_handler, boost::numeric::Trunc, 
boost::numeric::raw_converter>, 
boost::numeric::UseInternalRangeChecker>' requested here
  struct converter : convdetail::get_converter_impl, 
boost::numeric::def_overflow_handler, boost::numeric::Trunc>' requested 
here
  return converter::convert(arg);
 ^
  test.cc:2:28: note: in instantiation of function template specialization 
'boost::numeric_cast' requested here
  int main() { return boost::numeric_cast(0L); }
 ^
  /usr/include/boost/mpl/aux_/integral_wrapper.hpp:73:31: note: integer value 
-1 is outside the valid range of values [0, 3] for this enumeration type
  typedef AUX_WRAPPER_INST( 
BOOST_MPL_AUX_STATIC_CAST(AUX_WRAPPER_VALUE_TYPE, (value - 1)) ) prior;

[PATCH] D90275: [clang][IR] Add support for leaf attribute

2022-08-10 Thread Gulfem Savrun Yeniceri via Phabricator via cfe-commits
gulfem added a comment.

In D90275#3712991 , @nlopes wrote:

> In D90275#3712969 , @gulfem wrote:
>
>> In D90275#3712880 , @nlopes wrote:
>>
>>> In D90275#3707793 , @nlopes wrote:
>>>
 In D90275#3671983 , @gulfem wrote:

> In D90275#3671019 , @nlopes 
> wrote:
>
>> Could you please add a description of this attribute to LangRef?
>> We need the semantics of this.
>>
>> Thank you!
>
> Sure, I'll do that!

 ping?
>>>
>>> Since the patch author has been ignoring my ask (and is active), and since 
>>> documenting IR features is of paramount importance, I suggest we revert 
>>> this patch. I think 3 weeks to document something is sufficient, and the 
>>> author didn't provide an ETA.
>>> I would like to ask everyone to reject all future patches that change the 
>>> IR and don't include documentation, as experience says that we'll get 
>>> miscompilations due to different people having different ideas of the 
>>> semantics.
>>>
>>> TL;DR: I'll revert this patch on Friday if no one chimes in. Thank you!
>>
>> I'm very sorry and I was not ignoring your ask. I'll do it now.
>
> Thanks!
> I'm fine with a reasonable ETA, but we really need all IR features documented 
> to avoid bugs.

The urgency was not clear to me at the beginning, and I already added this to 
my list. 
I did not have a chance to respond to your comment this week because of 
traveling.
But again, I did not mean to ignore this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90275

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


[PATCH] D130974: [analyzer] Fix for the crash in #56873

2022-08-10 Thread Domján Dániel via Phabricator via cfe-commits
isuckatcs added a comment.

> If so, shouldn't be some dependencies across these revisions?

I don't think they are that closely related.

This patch is about fixing an assertion failure. This assertion failure happens 
because we don't handle a case not because the checker doesn't exist.
Also the checker alone wouldn't solve the problem, because if it's turned off, 
the same crash will happen.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130974

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


[PATCH] D131580: [clang][SVE] Undefine preprocessor macro defined in

2022-08-10 Thread Paul Walker via Phabricator via cfe-commits
paulwalker-arm added inline comments.



Comment at: clang/utils/TableGen/SveEmitter.cpp:1285
   OS << "#endif\n\n";
+  OS << "#undef __ai\n\n";
   OS << "#endif /*__ARM_FEATURE_SVE */\n\n";

Can you also do this for `__aio`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131580

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


[clang] 06fc5a7 - Driver: Refactor and support per target dirs in baremetal

2022-08-10 Thread Manoj Gupta via cfe-commits

Author: Manoj Gupta
Date: 2022-08-10T09:13:30-07:00
New Revision: 06fc5a7714621324b121fb3ee03ac15eb018cf99

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

LOG: Driver: Refactor and support per target dirs in baremetal

Refactor baremetal driver code to reduce the bespoke
additions and base class overrides.
This lets us use the per target runtimes like other clang
targets. E.g. clang -target armv7m-cros-none-eabi will now
be able to use the runtimes installed at
/lib/armv7m-cros-none-eabi instead of the hardcoded
path /lib/baremetal.
The older code paths should still continue to work as before if
/lib/ does not exist.

Reviewed By: MaskRay, barannikov88

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

Added: 

clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/lib/armv7m-vendor-none-eabi/libclang_rt.builtins.a

Modified: 
clang/include/clang/Driver/ToolChain.h
clang/lib/Driver/ToolChain.cpp
clang/lib/Driver/ToolChains/BareMetal.cpp
clang/lib/Driver/ToolChains/BareMetal.h
clang/test/Driver/baremetal.cpp
clang/test/Driver/print-libgcc-file-name-clangrt.c

Removed: 




diff  --git a/clang/include/clang/Driver/ToolChain.h 
b/clang/include/clang/Driver/ToolChain.h
index f20ab164531b8..8915c3b804139 100644
--- a/clang/include/clang/Driver/ToolChain.h
+++ b/clang/include/clang/Driver/ToolChain.h
@@ -532,7 +532,7 @@ class ToolChain {
 
   /// Add an additional -fdebug-prefix-map entry.
   virtual std::string GetGlobalDebugPathRemapping() const { return {}; }
-  
+
   // Return the DWARF version to emit, in the absence of arguments
   // to the contrary.
   virtual unsigned GetDefaultDwarfVersion() const { return 5; }
@@ -575,6 +575,9 @@ class ToolChain {
   /// isThreadModelSupported() - Does this target support a thread model?
   virtual bool isThreadModelSupported(const StringRef Model) const;
 
+  /// isBareMetal - Is this a bare metal target.
+  virtual bool isBareMetal() const { return false; }
+
   virtual std::string getMultiarchTriple(const Driver &D,
  const llvm::Triple &TargetTriple,
  StringRef SysRoot) const {

diff  --git a/clang/lib/Driver/ToolChain.cpp b/clang/lib/Driver/ToolChain.cpp
index 7a4319ea680f9..bc86e5be655fe 100644
--- a/clang/lib/Driver/ToolChain.cpp
+++ b/clang/lib/Driver/ToolChain.cpp
@@ -422,6 +422,9 @@ static StringRef getArchNameForCompilerRTLib(const 
ToolChain &TC,
   const llvm::Triple &Triple = TC.getTriple();
   bool IsWindows = Triple.isOSWindows();
 
+  if (TC.isBareMetal())
+return Triple.getArchName();
+
   if (TC.getArch() == llvm::Triple::arm || TC.getArch() == llvm::Triple::armeb)
 return (arm::getARMFloatABI(TC, Args) == arm::FloatABI::Hard && !IsWindows)
? "armhf"
@@ -459,7 +462,10 @@ StringRef ToolChain::getOSLibName() const {
 
 std::string ToolChain::getCompilerRTPath() const {
   SmallString<128> Path(getDriver().ResourceDir);
-  if (Triple.isOSUnknown()) {
+  if (isBareMetal()) {
+llvm::sys::path::append(Path, "lib", getOSLibName());
+Path += SelectedMultilib.gccSuffix();
+  } else if (Triple.isOSUnknown()) {
 llvm::sys::path::append(Path, "lib");
   } else {
 llvm::sys::path::append(Path, "lib", getOSLibName());

diff  --git a/clang/lib/Driver/ToolChains/BareMetal.cpp 
b/clang/lib/Driver/ToolChains/BareMetal.cpp
index 5f1638a159d52..75b06d5e7d0d5 100644
--- a/clang/lib/Driver/ToolChains/BareMetal.cpp
+++ b/clang/lib/Driver/ToolChains/BareMetal.cpp
@@ -92,7 +92,7 @@ static bool findRISCVMultilibs(const Driver &D,
 }
 
 BareMetal::BareMetal(const Driver &D, const llvm::Triple &Triple,
-   const ArgList &Args)
+ const ArgList &Args)
 : ToolChain(D, Triple, Args) {
   getProgramPaths().push_back(getDriver().getInstalledDir());
   if (getDriver().getInstalledDir() != getDriver().Dir)
@@ -173,21 +173,6 @@ Tool *BareMetal::buildLinker() const {
   return new tools::baremetal::Linker(*this);
 }
 
-std::string BareMetal::getCompilerRTPath() const { return getRuntimesDir(); }
-
-std::string BareMetal::buildCompilerRTBasename(const llvm::opt::ArgList &,
-   StringRef, FileType,
-   bool) const {
-  return ("libclang_rt.builtins-" + getTriple().getArchName() + ".a").str();
-}
-
-std::string BareMetal::getRuntimesDir() const {
-  SmallString<128> Dir(getDriver().ResourceDir);
-  llvm::sys::path::append(Dir, "lib", "baremetal");
-  Dir += SelectedMultilib.gccSuffix();
-  return std::string(Dir.str());
-}
-
 std::string BareMetal::computeSysRoot() const {
   if (!getDriver().SysRoot.empty())
 return getDriver().SysRoot + SelectedMultilib.osSuffix();
@@ 

[PATCH] D131225: Driver: Refactor and support per target dirs in baremetal

2022-08-10 Thread Manoj Gupta via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG06fc5a771462: Driver: Refactor and support per target dirs 
in baremetal (authored by manojgupta).

Changed prior to commit:
  https://reviews.llvm.org/D131225?vs=451352&id=451517#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131225

Files:
  clang/include/clang/Driver/ToolChain.h
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/BareMetal.cpp
  clang/lib/Driver/ToolChains/BareMetal.h
  
clang/test/Driver/Inputs/resource_dir_with_per_target_subdir/lib/armv7m-vendor-none-eabi/libclang_rt.builtins.a
  clang/test/Driver/baremetal.cpp
  clang/test/Driver/print-libgcc-file-name-clangrt.c

Index: clang/test/Driver/print-libgcc-file-name-clangrt.c
===
--- clang/test/Driver/print-libgcc-file-name-clangrt.c
+++ clang/test/Driver/print-libgcc-file-name-clangrt.c
@@ -48,3 +48,9 @@
 // RUN: -resource-dir=%S/Inputs/resource_dir_with_arch_subdir \
 // RUN:   | FileCheck --check-prefix=CHECK-CLANGRT-ARM-BAREMETAL %s
 // CHECK-CLANGRT-ARM-BAREMETAL: libclang_rt.builtins-armv7m.a
+
+// RUN: %clang -rtlib=compiler-rt -print-libgcc-file-name 2>&1 \
+// RUN: --target=armv7m-vendor-none-eabi \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN:   | FileCheck --check-prefix=CHECK-CLANGRT-ARM-BAREMETAL-PER-TARGET %s
+// CHECK-CLANGRT-ARM-BAREMETAL-PER-TARGET: libclang_rt.builtins.a
Index: clang/test/Driver/baremetal.cpp
===
--- clang/test/Driver/baremetal.cpp
+++ clang/test/Driver/baremetal.cpp
@@ -31,6 +31,20 @@
 // RUN:   | FileCheck --check-prefix=CHECK-V6M-LIBINC %s
 // CHECK-V6M-LIBINC-NOT: "-internal-isystem"
 
+// RUN: %clang -no-canonical-prefixes -rtlib=compiler-rt %s -### -o %t.o 2>&1 \
+// RUN: -target armv7m-vendor-none-eabi \
+// RUN: --sysroot=%S/Inputs/baremetal_arm \
+// RUN: -resource-dir=%S/Inputs/resource_dir_with_per_target_subdir \
+// RUN:   | FileCheck --check-prefix=CHECK-ARMV7M-PER-TARGET %s
+// CHECK-ARMV7M-PER-TARGET: "-resource-dir" "[[RESOURCE_DIR:[^"]+]]"
+// CHECK-ARMV7M-PER-TARGET: "-isysroot" "[[SYSROOT:[^"]*]]"
+// CHECK-ARMV7M-PER-TARGET: "-x" "c++" "{{.*}}baremetal.cpp"
+// CHECK-ARMV7M-PER-TARGET: "{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}" "{{.*}}.o" "-Bstatic"
+// CHECK-ARMV7M-PER-TARGET: "-L[[SYSROOT:[^"]+]]{{[/\\]+}}lib"
+// CHECK-ARMV7M-PER-TARGET: "-L[[RESOURCE_DIR:[^"]+]]{{[/\\]+}}lib{{[/\\]+}}armv7m-vendor-none-eabi
+// CHECK-ARMV7M-PER-TARGET: "-lc" "-lm" "-lclang_rt.builtins"
+// CHECK-ARMV7M-PER-TARGET: "-o" "{{.*}}.o"
+
 // RUN: %clangxx -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target armv6m-none-eabi \
 // RUN: --sysroot=%S/Inputs/baremetal_arm \
Index: clang/lib/Driver/ToolChains/BareMetal.h
===
--- clang/lib/Driver/ToolChains/BareMetal.h
+++ clang/lib/Driver/ToolChains/BareMetal.h
@@ -1,4 +1,4 @@
-//===--- BareMetal.h - Bare Metal Tool and ToolChain -*- C++ -*-===//
+//===--- BareMetal.h - Bare Metal Tool and ToolChain *- C++-*-===//
 //
 // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 // See https://llvm.org/LICENSE.txt for license information.
@@ -33,13 +33,9 @@
 protected:
   Tool *buildLinker() const override;
 
-  std::string buildCompilerRTBasename(const llvm::opt::ArgList &Args,
-  StringRef Component,
-  FileType Type = ToolChain::FT_Static,
-  bool AddArch = true) const override;
-
 public:
   bool useIntegratedAs() const override { return true; }
+  bool isBareMetal() const override { return true; }
   bool isCrossCompiling() const override { return true; }
   bool isPICDefault() const override { return false; }
   bool isPIEDefault(const llvm::opt::ArgList &Args) const override {
@@ -50,8 +46,6 @@
 
   StringRef getOSLibName() const override { return "baremetal"; }
 
-  std::string getCompilerRTPath() const override;
-
   RuntimeLibType GetDefaultRuntimeLibType() const override {
 return ToolChain::RLT_CompilerRT;
   }
@@ -61,12 +55,13 @@
 
   const char *getDefaultLinker() const override { return "ld.lld"; }
 
-  std::string getRuntimesDir() const;
-  void AddClangSystemIncludeArgs(const llvm::opt::ArgList &DriverArgs,
- llvm::opt::ArgStringList &CC1Args) const override;
-  void addClangTargetOptions(const llvm::opt::ArgList &DriverArgs,
- llvm::opt::ArgStringList &CC1Args,
- Action::OffloadKind DeviceOffloadKind) const override;
+  void
+  AddClangSystemIncludeArgs(const llvm::opt::ArgList &DriverArgs,
+llvm::opt::ArgStringL

[PATCH] D131590: Fixed page title for abseil-no-internal-dependencies check documentation

2022-08-10 Thread Vladimir Plyashkun via Phabricator via cfe-commits
vladimir.plyashkun created this revision.
vladimir.plyashkun added reviewers: aaron.ballman, ivanmurashko, njames93.
vladimir.plyashkun added a project: clang-tools-extra.
Herald added a project: All.
vladimir.plyashkun requested review of this revision.
Herald added a subscriber: cfe-commits.

It seems that documentation for abseil-no-internal-dependencies has invalid 
title.
This can be checked by looking at the actual web-site - 
https://clang.llvm.org/extra/clang-tidy/checks/abseil/no-internal-dependencies.html
There is redundant "subl.. title:: clang-tidy - 
abseil-no-internal-dependencies" paragraph in the beginning.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D131590

Files:
  clang-tools-extra/docs/clang-tidy/checks/abseil/no-internal-dependencies.rst


Index: 
clang-tools-extra/docs/clang-tidy/checks/abseil/no-internal-dependencies.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/abseil/no-internal-dependencies.rst
+++ clang-tools-extra/docs/clang-tidy/checks/abseil/no-internal-dependencies.rst
@@ -1,4 +1,4 @@
-subl.. title:: clang-tidy - abseil-no-internal-dependencies
+.. title:: clang-tidy - abseil-no-internal-dependencies
 
 abseil-no-internal-dependencies
 ===


Index: clang-tools-extra/docs/clang-tidy/checks/abseil/no-internal-dependencies.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/abseil/no-internal-dependencies.rst
+++ clang-tools-extra/docs/clang-tidy/checks/abseil/no-internal-dependencies.rst
@@ -1,4 +1,4 @@
-subl.. title:: clang-tidy - abseil-no-internal-dependencies
+.. title:: clang-tidy - abseil-no-internal-dependencies
 
 abseil-no-internal-dependencies
 ===
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D131514: [analyzer] [NFC] Add more test cases for equality tracking

2022-08-10 Thread Denys Petrov via Phabricator via cfe-commits
ASDenysPetrov updated this revision to Diff 451527.
ASDenysPetrov added a comment.

C-standard does not support templates. Replaced function template with the 
function.


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

https://reviews.llvm.org/D131514

Files:
  clang/test/Analysis/equality_tracking.c

Index: clang/test/Analysis/equality_tracking.c
===
--- clang/test/Analysis/equality_tracking.c
+++ clang/test/Analysis/equality_tracking.c
@@ -8,6 +8,7 @@
 #define CHAR_MAX (char)(UCHAR_MAX & (UCHAR_MAX >> 1))
 #define CHAR_MIN (char)(UCHAR_MAX & ~(UCHAR_MAX >> 1))
 
+void clang_analyzer_value(int);
 void clang_analyzer_eval(int);
 void clang_analyzer_warnIfReached(void);
 
@@ -233,3 +234,139 @@
 clang_analyzer_eval(a != b); // expected-warning{{TRUE}}
   }
 }
+
+void deletePointBefore(int x, int tmp) {
+  if(tmp == 0)
+if(x != tmp)
+ clang_analyzer_value(x); // expected-warning {{32s:{ [-2147483648, -1], [1, 2147483647] }}}
+}
+
+void deletePointAfter(int x, int tmp) {
+  if(x != tmp)
+if(tmp == 2147483647)
+  clang_analyzer_value(x); // expected-warning {{32s:{ [-2147483648, 2147483646] }}}
+}
+
+void deleteTwoPoints(int x, int tmp1, int tmp2) {
+  if(x != tmp1) {
+if (tmp1 == 42 && tmp2 == 87) {
+  clang_analyzer_value(x); // expected-warning {{32s:{ [-2147483648, 41], [43, 2147483647] }}}
+  if(x != tmp2)
+clang_analyzer_value(x); // expected-warning {{32s:{ [-2147483648, 41], [43, 86], [88, 2147483647] }}}
+}
+  }
+}
+
+void deleteAllPoints(unsigned char x, unsigned char *arr) {
+
+#define cond(n) \
+arr[n##0] == n##0 && \
+arr[n##1] == n##1 && \
+arr[n##2] == n##2 && \
+arr[n##3] == n##3 && \
+arr[n##4] == n##4 && \
+arr[n##5] == n##5 && \
+arr[n##6] == n##6 && \
+arr[n##7] == n##7 && \
+arr[n##8] == n##8 && \
+arr[n##9] == n##9 && \
+
+#define condX(n) \
+arr[n##0] != x && \
+arr[n##1] != x && \
+arr[n##2] != x && \
+arr[n##3] != x && \
+arr[n##4] != x && \
+arr[n##5] != x && \
+arr[n##6] != x && \
+arr[n##7] != x && \
+arr[n##8] != x && \
+arr[n##9] != x && \
+
+  clang_analyzer_value(x); // expected-warning {{{ [0, 255] }}}
+  if (
+cond()  // 0  .. 9
+cond(1) // 10 .. 19
+cond(2) // 20 .. 29
+cond(3) // 30 .. 39
+cond(4) // 40 .. 49
+cond(5) // 50 .. 59
+cond(6) // 60 .. 69
+cond(7) // 70 .. 79
+cond(8) // 80 .. 89
+cond(9) // 90 .. 99
+cond(10) // 100 .. 209
+cond(11) // 110 .. 219
+cond(12) // 120 .. 229
+cond(13) // 130 .. 239
+cond(14) // 140 .. 249
+cond(15) // 150 .. 259
+cond(16) // 160 .. 269
+cond(17) // 170 .. 279
+cond(18) // 180 .. 289
+cond(19) // 190 .. 199
+cond(20) // 200 .. 209
+cond(21) // 210 .. 219
+cond(22) // 220 .. 229
+cond(23) // 230 .. 239
+cond(24) // 240 .. 249
+arr[250] == 250 &&
+arr[251] == 251 &&
+arr[252] == 252 &&
+arr[253] == 253 &&
+arr[254] == 254 &&
+arr[255] == 255
+) {
+if (
+  condX()  // 0  .. 9
+  condX(1) // 10 .. 19
+  condX(2) // 20 .. 29
+  condX(3) // 30 .. 39
+  condX(4) // 40 .. 49
+  condX(5) // 50 .. 59
+  condX(6) // 60 .. 69
+  condX(7) // 70 .. 79
+  condX(8) // 80 .. 89
+  condX(9) // 90 .. 99
+  condX(10) // 100 .. 209
+  condX(11) // 110 .. 219
+  condX(12) // 120 .. 229
+  condX(13) // 130 .. 239
+  condX(14) // 140 .. 249
+  condX(15) // 150 .. 259
+  condX(16) // 160 .. 269
+  condX(17) // 170 .. 279
+  condX(18) // 180 .. 289
+  condX(19) // 190 .. 199
+  condX(20) // 200 .. 209
+  condX(21) // 210 .. 219
+  condX(22) // 220 .. 229
+  condX(23) // 230 .. 239
+  arr[240] != x &&
+  arr[241] != x &&
+  arr[242] != x &&
+  arr[243] != x &&
+  arr[244] != x &&
+  arr[245] != x &&
+  arr[246] != x &&
+  arr[247] != x &&
+  arr[248] != x &&
+  arr[249] != x
+  ) {
+  clang_analyzer_value(x); // expected-warning {{{ [250, 255] }}}
+  if (
+  arr[250] != x &&
+  arr[251] != x &&
+  //skip arr[252]
+  arr[253] != x &&
+  arr[254] != x &&
+  arr[255] != x
+  ) {
+clang_analyzer_value(x); // expected-warning {{32s:252}}
+if (arr[252] != x) {
+  clang_analyzer_warnIfReached(); // unreachable
+}
+  }
+}
+  }
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D131594: WORK IN PROGRESS Add Clang UEFI target to support "x86_64-unknown-uefi" triple

2022-08-10 Thread Prabhu Karthikeyan Rajasekaran via Phabricator via cfe-commits
Prabhuk created this revision.
Herald added a subscriber: hiraditya.
Herald added a project: All.
Prabhuk requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D131594

Files:
  clang/lib/Basic/Targets.cpp
  clang/lib/Basic/Targets/OSTargets.h
  llvm/include/llvm/ADT/Triple.h
  llvm/lib/Support/Triple.cpp
  llvm/unittests/ADT/TripleTest.cpp

Index: llvm/unittests/ADT/TripleTest.cpp
===
--- llvm/unittests/ADT/TripleTest.cpp
+++ llvm/unittests/ADT/TripleTest.cpp
@@ -790,6 +790,12 @@
   EXPECT_EQ(Triple::ShaderModel, T.getOS());
   EXPECT_EQ(Triple::Amplification, T.getEnvironment());
 
+  T = Triple("x86_64-unknown-uefi");
+  EXPECT_EQ(Triple::x86_64, T.getArch());
+  EXPECT_EQ(Triple::UnknownVendor, T.getVendor());
+  EXPECT_EQ(Triple::UEFI, T.getOS());
+  EXPECT_EQ(Triple::UnknownEnvironment, T.getEnvironment());
+
   T = Triple("huh");
   EXPECT_EQ(Triple::UnknownArch, T.getArch());
 }
Index: llvm/lib/Support/Triple.cpp
===
--- llvm/lib/Support/Triple.cpp
+++ llvm/lib/Support/Triple.cpp
@@ -235,6 +235,7 @@
   case RTEMS: return "rtems";
   case Solaris: return "solaris";
   case TvOS: return "tvos";
+  case UEFI: return "uefi";
   case WASI: return "wasi";
   case WatchOS: return "watchos";
   case Win32: return "windows";
@@ -562,6 +563,7 @@
 .StartsWith("netbsd", Triple::NetBSD)
 .StartsWith("openbsd", Triple::OpenBSD)
 .StartsWith("solaris", Triple::Solaris)
+.StartsWith("uefi", Triple::UEFI)
 .StartsWith("win32", Triple::Win32)
 .StartsWith("windows", Triple::Win32)
 .StartsWith("zos", Triple::ZOS)
Index: llvm/include/llvm/ADT/Triple.h
===
--- llvm/include/llvm/ADT/Triple.h
+++ llvm/include/llvm/ADT/Triple.h
@@ -195,6 +195,7 @@
 NetBSD,
 OpenBSD,
 Solaris,
+UEFI,
 Win32,
 ZOS,
 Haiku,
@@ -567,6 +568,10 @@
 return getOS() == Triple::Haiku;
   }
 
+  bool isOSUEFI() const {
+return getOS() == Triple::UEFI;
+  }
+
   /// Tests whether the OS is Windows.
   bool isOSWindows() const {
 return getOS() == Triple::Win32;
Index: clang/lib/Basic/Targets/OSTargets.h
===
--- clang/lib/Basic/Targets/OSTargets.h
+++ clang/lib/Basic/Targets/OSTargets.h
@@ -919,6 +919,22 @@
   }
 };
 
+// UEFI Target
+template 
+class LLVM_LIBRARY_VISIBILITY UEFITargetInfo : public OSTargetInfo {
+protected:
+  void getOSDefines(const LangOptions &Opts, const llvm::Triple &Triple,
+MacroBuilder &Builder) const override {
+//TODO(prabhukr): How to iniialize this info? Copy from Win?
+  }
+
+public:
+  UEFITargetInfo(const llvm::Triple &Triple, const TargetOptions &Opts)
+  : OSTargetInfo(Triple, Opts) {
+//TODO(prabhukr): How to iniialize this info? Copy from Win?
+  }
+};
+
 // Fuchsia Target
 template 
 class LLVM_LIBRARY_VISIBILITY FuchsiaTargetInfo : public OSTargetInfo {
Index: clang/lib/Basic/Targets.cpp
===
--- clang/lib/Basic/Targets.cpp
+++ clang/lib/Basic/Targets.cpp
@@ -575,6 +575,9 @@
   return new KFreeBSDTargetInfo(Triple, Opts);
 case llvm::Triple::Solaris:
   return new SolarisTargetInfo(Triple, Opts);
+case llvm::Triple::UEFI:
+  //TODO(prabhukr): Template param check if required for other architectures
+  return new UEFITargetInfo(Triple, Opts);
 case llvm::Triple::Win32: {
   switch (Triple.getEnvironment()) {
   case llvm::Triple::Cygnus:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 7e2b995 - [analyzer] [NFC] Add more test cases for equality tracking

2022-08-10 Thread Denys Petrov via cfe-commits

Author: Denys Petrov
Date: 2022-08-10T19:52:55+03:00
New Revision: 7e2b995e0cced8a292c3de9e4ec6a503223de38a

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

LOG: [analyzer] [NFC] Add more test cases for equality tracking

Summary: Cover `ConstraintAssignor::assign(EquivalenceClass, RangeSet)` 
function with more regression tests.

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

Added: 


Modified: 
clang/test/Analysis/equality_tracking.c

Removed: 




diff  --git a/clang/test/Analysis/equality_tracking.c 
b/clang/test/Analysis/equality_tracking.c
index 681453b1fe29b..e33b95700d002 100644
--- a/clang/test/Analysis/equality_tracking.c
+++ b/clang/test/Analysis/equality_tracking.c
@@ -8,6 +8,7 @@
 #define CHAR_MAX (char)(UCHAR_MAX & (UCHAR_MAX >> 1))
 #define CHAR_MIN (char)(UCHAR_MAX & ~(UCHAR_MAX >> 1))
 
+void clang_analyzer_value(int);
 void clang_analyzer_eval(int);
 void clang_analyzer_warnIfReached(void);
 
@@ -233,3 +234,139 @@ void implyDisequalityFromLT(int a, int b) {
 clang_analyzer_eval(a != b); // expected-warning{{TRUE}}
   }
 }
+
+void deletePointBefore(int x, int tmp) {
+  if(tmp == 0)
+if(x != tmp)
+ clang_analyzer_value(x); // expected-warning {{32s:{ [-2147483648, -1], 
[1, 2147483647] }}}
+}
+
+void deletePointAfter(int x, int tmp) {
+  if(x != tmp)
+if(tmp == 2147483647)
+  clang_analyzer_value(x); // expected-warning {{32s:{ [-2147483648, 
2147483646] }}}
+}
+
+void deleteTwoPoints(int x, int tmp1, int tmp2) {
+  if(x != tmp1) {
+if (tmp1 == 42 && tmp2 == 87) {
+  clang_analyzer_value(x); // expected-warning {{32s:{ [-2147483648, 41], 
[43, 2147483647] }}}
+  if(x != tmp2)
+clang_analyzer_value(x); // expected-warning {{32s:{ [-2147483648, 
41], [43, 86], [88, 2147483647] }}}
+}
+  }
+}
+
+void deleteAllPoints(unsigned char x, unsigned char *arr) {
+
+#define cond(n) \
+arr[n##0] == n##0 && \
+arr[n##1] == n##1 && \
+arr[n##2] == n##2 && \
+arr[n##3] == n##3 && \
+arr[n##4] == n##4 && \
+arr[n##5] == n##5 && \
+arr[n##6] == n##6 && \
+arr[n##7] == n##7 && \
+arr[n##8] == n##8 && \
+arr[n##9] == n##9 && \
+
+#define condX(n) \
+arr[n##0] != x && \
+arr[n##1] != x && \
+arr[n##2] != x && \
+arr[n##3] != x && \
+arr[n##4] != x && \
+arr[n##5] != x && \
+arr[n##6] != x && \
+arr[n##7] != x && \
+arr[n##8] != x && \
+arr[n##9] != x && \
+
+  clang_analyzer_value(x); // expected-warning {{{ [0, 255] }}}
+  if (
+cond()  // 0  .. 9
+cond(1) // 10 .. 19
+cond(2) // 20 .. 29
+cond(3) // 30 .. 39
+cond(4) // 40 .. 49
+cond(5) // 50 .. 59
+cond(6) // 60 .. 69
+cond(7) // 70 .. 79
+cond(8) // 80 .. 89
+cond(9) // 90 .. 99
+cond(10) // 100 .. 209
+cond(11) // 110 .. 219
+cond(12) // 120 .. 229
+cond(13) // 130 .. 239
+cond(14) // 140 .. 249
+cond(15) // 150 .. 259
+cond(16) // 160 .. 269
+cond(17) // 170 .. 279
+cond(18) // 180 .. 289
+cond(19) // 190 .. 199
+cond(20) // 200 .. 209
+cond(21) // 210 .. 219
+cond(22) // 220 .. 229
+cond(23) // 230 .. 239
+cond(24) // 240 .. 249
+arr[250] == 250 &&
+arr[251] == 251 &&
+arr[252] == 252 &&
+arr[253] == 253 &&
+arr[254] == 254 &&
+arr[255] == 255
+) {
+if (
+  condX()  // 0  .. 9
+  condX(1) // 10 .. 19
+  condX(2) // 20 .. 29
+  condX(3) // 30 .. 39
+  condX(4) // 40 .. 49
+  condX(5) // 50 .. 59
+  condX(6) // 60 .. 69
+  condX(7) // 70 .. 79
+  condX(8) // 80 .. 89
+  condX(9) // 90 .. 99
+  condX(10) // 100 .. 209
+  condX(11) // 110 .. 219
+  condX(12) // 120 .. 229
+  condX(13) // 130 .. 239
+  condX(14) // 140 .. 249
+  condX(15) // 150 .. 259
+  condX(16) // 160 .. 269
+  condX(17) // 170 .. 279
+  condX(18) // 180 .. 289
+  condX(19) // 190 .. 199
+  condX(20) // 200 .. 209
+  condX(21) // 210 .. 219
+  condX(22) // 220 .. 229
+  condX(23) // 230 .. 239
+  arr[240] != x &&
+  arr[241] != x &&
+  arr[242] != x &&
+  arr[243] != x &&
+  arr[244] != x &&
+  arr[245] != x &&
+  arr[246] != x &&
+  arr[247] != x &&
+  arr[248] != x &&
+  arr[249] != x
+  ) {
+  clang_analyzer_value(x); // expected-warning {{{ [250, 255] }}}
+  if (
+  arr[250] != x &&
+  arr[251] != x &&
+  //skip arr[252]
+  arr[253] != x &&
+  arr[254] != x &&
+  arr[255] != x
+  ) {
+clang_analyzer_value(x); // expected-warning {{32s:252}}
+if (arr[252] != x) {
+  clang_analyzer_warnIfReached(); // unreachable
+}
+  }
+}
+  }
+}



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.o

[PATCH] D131514: [analyzer] [NFC] Add more test cases for equality tracking

2022-08-10 Thread Denys Petrov 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 rG7e2b995e0cce: [analyzer] [NFC] Add more test cases for 
equality tracking (authored by ASDenysPetrov).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131514

Files:
  clang/test/Analysis/equality_tracking.c

Index: clang/test/Analysis/equality_tracking.c
===
--- clang/test/Analysis/equality_tracking.c
+++ clang/test/Analysis/equality_tracking.c
@@ -8,6 +8,7 @@
 #define CHAR_MAX (char)(UCHAR_MAX & (UCHAR_MAX >> 1))
 #define CHAR_MIN (char)(UCHAR_MAX & ~(UCHAR_MAX >> 1))
 
+void clang_analyzer_value(int);
 void clang_analyzer_eval(int);
 void clang_analyzer_warnIfReached(void);
 
@@ -233,3 +234,139 @@
 clang_analyzer_eval(a != b); // expected-warning{{TRUE}}
   }
 }
+
+void deletePointBefore(int x, int tmp) {
+  if(tmp == 0)
+if(x != tmp)
+ clang_analyzer_value(x); // expected-warning {{32s:{ [-2147483648, -1], [1, 2147483647] }}}
+}
+
+void deletePointAfter(int x, int tmp) {
+  if(x != tmp)
+if(tmp == 2147483647)
+  clang_analyzer_value(x); // expected-warning {{32s:{ [-2147483648, 2147483646] }}}
+}
+
+void deleteTwoPoints(int x, int tmp1, int tmp2) {
+  if(x != tmp1) {
+if (tmp1 == 42 && tmp2 == 87) {
+  clang_analyzer_value(x); // expected-warning {{32s:{ [-2147483648, 41], [43, 2147483647] }}}
+  if(x != tmp2)
+clang_analyzer_value(x); // expected-warning {{32s:{ [-2147483648, 41], [43, 86], [88, 2147483647] }}}
+}
+  }
+}
+
+void deleteAllPoints(unsigned char x, unsigned char *arr) {
+
+#define cond(n) \
+arr[n##0] == n##0 && \
+arr[n##1] == n##1 && \
+arr[n##2] == n##2 && \
+arr[n##3] == n##3 && \
+arr[n##4] == n##4 && \
+arr[n##5] == n##5 && \
+arr[n##6] == n##6 && \
+arr[n##7] == n##7 && \
+arr[n##8] == n##8 && \
+arr[n##9] == n##9 && \
+
+#define condX(n) \
+arr[n##0] != x && \
+arr[n##1] != x && \
+arr[n##2] != x && \
+arr[n##3] != x && \
+arr[n##4] != x && \
+arr[n##5] != x && \
+arr[n##6] != x && \
+arr[n##7] != x && \
+arr[n##8] != x && \
+arr[n##9] != x && \
+
+  clang_analyzer_value(x); // expected-warning {{{ [0, 255] }}}
+  if (
+cond()  // 0  .. 9
+cond(1) // 10 .. 19
+cond(2) // 20 .. 29
+cond(3) // 30 .. 39
+cond(4) // 40 .. 49
+cond(5) // 50 .. 59
+cond(6) // 60 .. 69
+cond(7) // 70 .. 79
+cond(8) // 80 .. 89
+cond(9) // 90 .. 99
+cond(10) // 100 .. 209
+cond(11) // 110 .. 219
+cond(12) // 120 .. 229
+cond(13) // 130 .. 239
+cond(14) // 140 .. 249
+cond(15) // 150 .. 259
+cond(16) // 160 .. 269
+cond(17) // 170 .. 279
+cond(18) // 180 .. 289
+cond(19) // 190 .. 199
+cond(20) // 200 .. 209
+cond(21) // 210 .. 219
+cond(22) // 220 .. 229
+cond(23) // 230 .. 239
+cond(24) // 240 .. 249
+arr[250] == 250 &&
+arr[251] == 251 &&
+arr[252] == 252 &&
+arr[253] == 253 &&
+arr[254] == 254 &&
+arr[255] == 255
+) {
+if (
+  condX()  // 0  .. 9
+  condX(1) // 10 .. 19
+  condX(2) // 20 .. 29
+  condX(3) // 30 .. 39
+  condX(4) // 40 .. 49
+  condX(5) // 50 .. 59
+  condX(6) // 60 .. 69
+  condX(7) // 70 .. 79
+  condX(8) // 80 .. 89
+  condX(9) // 90 .. 99
+  condX(10) // 100 .. 209
+  condX(11) // 110 .. 219
+  condX(12) // 120 .. 229
+  condX(13) // 130 .. 239
+  condX(14) // 140 .. 249
+  condX(15) // 150 .. 259
+  condX(16) // 160 .. 269
+  condX(17) // 170 .. 279
+  condX(18) // 180 .. 289
+  condX(19) // 190 .. 199
+  condX(20) // 200 .. 209
+  condX(21) // 210 .. 219
+  condX(22) // 220 .. 229
+  condX(23) // 230 .. 239
+  arr[240] != x &&
+  arr[241] != x &&
+  arr[242] != x &&
+  arr[243] != x &&
+  arr[244] != x &&
+  arr[245] != x &&
+  arr[246] != x &&
+  arr[247] != x &&
+  arr[248] != x &&
+  arr[249] != x
+  ) {
+  clang_analyzer_value(x); // expected-warning {{{ [250, 255] }}}
+  if (
+  arr[250] != x &&
+  arr[251] != x &&
+  //skip arr[252]
+  arr[253] != x &&
+  arr[254] != x &&
+  arr[255] != x
+  ) {
+clang_analyzer_value(x); // expected-warning {{32s:252}}
+if (arr[252] != x) {
+  clang_analyzer_warnIfReached(); // unreachable
+}
+  }
+}
+  }
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D130303: Handle template parameter-dependent bit field widths in libclang

2022-08-10 Thread Collin Baker via Phabricator via cfe-commits
collinbaker added a comment.

Pinging this


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130303

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


[PATCH] D131569: [clangd] Allow updates to be canceled after compile flags retrieval

2022-08-10 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov added a comment.

Could you please add a test with a compilation database that models the 
blocking behavior, attempts cancellation and ensures no diagnostics are 
produced?
I also suggest adding a callback similar to `Callbacks.onFailedAST`, which 
could be used for testing this behavior.
The test should also check that subsequent updates and reads get resolved 
properly.

We don't have an actual implementation for the client code that relies on this 
in-tree, but the unit test will help to ensure we don't break this contract.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131569

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


[PATCH] D131202: [Clang] Fix capture of values initialized by bitfields

2022-08-10 Thread Alexander Yermolovich via Phabricator via cfe-commits
ayermolo added a comment.

Thanks for reverting this.
Previous commit broke build of projects using fmt library.
https://github.com/fmtlib/fmt/blame/master/include/fmt/format.h

  fmt/fmt/include/fmt/format.h:1904:9: error: cannot capture a bit-field by 
reference
   if (sign) *it++ = detail::sign(sign);
   ^
   fmt/fmt/include/fmt/format.h:1814:8: note: 'sign' declared here
 auto sign = fspecs.sign;
  ^
   fmt/fmt/include/fmt/core.h:2741:10: note: bit-field is declared here
 sign_t sign : 8;




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D131202

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


  1   2   3   >