[PATCH] D84136: [clang] Fix visitation of ConceptSpecializationExpr in constrained-parameter

[Nathan Ridge via Phabricator via cfe-commits]

nridge added inline comments.



Comment at: clang/include/clang/AST/RecursiveASTVisitor.h:1843
+  if (const auto *TC = D->getTypeConstraint()) {
+TRY_TO(TraverseStmt(TC->getImmediatelyDeclaredConstraint()));
 TRY_TO(TraverseConceptReference(*TC));

hokein wrote:
> nridge wrote:
> > hokein wrote:
> > > Looks like we may visit some nodes in `ConceptReference` twice:
> > > -  getImmediatelyDeclaredConstraint returns a `ConceptSpecializationExpr` 
> > > (most cases?) which is a subclass of `ConceptReference`;
> > > - `TraverseStmt(ConceptSpecializationExpr*)` will dispatch to 
> > > `TraverseConceptSpecializationExpr` which invokes 
> > > `TraverseConceptReference` (see Line 2719);
> > > 
> > > 
> > > It is sad that we don't have enough test coverage, could you write some 
> > > tests in `clang/unittests/Tooling/RecursiveASTVisitorTests/`?
> > It is true that there will be two calls to `TraverseConceptReference()`. 
> > However, they are called on two different `ConceptReference` objects:
> > 
> >   * the call in `TraverseConceptSpecializationExpr` will visit the base 
> > subobject of the `ConceptSpecializationExpr` (which inherits from 
> > `ConceptReference`)
> >   * the call in `TraverseTemplateTypeParmDecl` will visit the base 
> > subobject of the `TypeConstraint` (which also inherits from 
> > `ConceptReference`).
> > 
> > So, I think this is fine -- there are two distinct `ConceptReference` 
> > objects in the AST, and with this patch we visit both of them.
> I understand that they are two different `ConceptReference` objects, but they 
> have members (`FoundDecl`, `ArgsAsWritten`) that may refer to the same AST 
> nodes.
> 
> ```
> template 
> concept binary_concept = true;
> struct Foo {};
> 
> template T> // the template argument Foo will be visited 
> twice.
> void k2();
> ```
> 
> I'm not sure what's is the right approach here, I can see two options:
> 
> - traverse TC + immediately-declared-constraint expr, this seem to cause some 
> ast nodes visited twice (maybe not a big deal?)
> - just traverse immediately-declared-constraint expr, this seems not breaking 
> any tests, but the immediately-declared-constraint expr could be nullptr 
> (e.g. broken code, missing required template arguments); or the 
> immediately-declared-constraint expr could be a `CXXFoldExpr`, which will 
> make some members in `ConceptReference` not be visited;
> 
> @rsmith, do you have any idea about this?
> 
From clangd's point of view, it would be sufficient to visit the 
immediately-declared-constraint-expr without visiting any of its descendants. 
However, I'm not sure how to accomplish this using `RecursiveASTVisitor`. (I 
think I'd want to call `WalkUpFromXXX(TC->getImmediatelyDeclaredConstraint())`, 
where `XXX` is the dynamic type of the immediately-delcared-constraint, but I 
don't know how to dispatch to that dynamic type; `RecursiveASTVisitor` seems to 
be designed to do the dispatch on `Traverse` calls, not `WalkUpFrom` calls).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84136

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

[PATCH] D85146: [SyntaxTree] Fix crash on pointer to member function

[Eduardo Caldas via Phabricator via cfe-commits]

eduucaldas updated this revision to Diff 282814.
eduucaldas marked 2 inline comments as done.
eduucaldas added a comment.

answer comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85146

Files:
  clang/lib/Tooling/Syntax/BuildTree.cpp
  clang/unittests/Tooling/Syntax/TreeTest.cpp

Index: clang/unittests/Tooling/Syntax/TreeTest.cpp
===
--- clang/unittests/Tooling/Syntax/TreeTest.cpp
+++ clang/unittests/Tooling/Syntax/TreeTest.cpp
@@ -4067,6 +4067,99 @@
 )txt"));
 }
 
+TEST_P(SyntaxTreeTest, MemberFunctionPointer) {
+  if (!GetParam().isCXX()) {
+return;
+  }
+  EXPECT_TRUE(treeDumpEqual(
+  R"cpp(
+struct X {
+  struct Y {};
+};
+void (X::*xp)();
+void (X::**xpp)(const int*);
+// FIXME: Generate the right syntax tree for this type,
+// i.e. create a syntax node for the outer member pointer
+void (X::Y::*xyp)(const int*, char);
+)cpp",
+  R"txt(
+*: TranslationUnit
+|-SimpleDeclaration
+| |-struct
+| |-X
+| |-{
+| |-SimpleDeclaration
+| | |-struct
+| | |-Y
+| | |-{
+| | |-}
+| | `-;
+| |-}
+| `-;
+|-SimpleDeclaration
+| |-void
+| |-SimpleDeclarator
+| | |-ParenDeclarator
+| | | |-(
+| | | |-MemberPointer
+| | | | |-X
+| | | | |-::
+| | | | `-*
+| | | |-xp
+| | | `-)
+| | `-ParametersAndQualifiers
+| |   |-(
+| |   `-)
+| `-;
+|-SimpleDeclaration
+| |-void
+| |-SimpleDeclarator
+| | |-ParenDeclarator
+| | | |-(
+| | | |-MemberPointer
+| | | | |-X
+| | | | |-::
+| | | | `-*
+| | | |-*
+| | | |-xpp
+| | | `-)
+| | `-ParametersAndQualifiers
+| |   |-(
+| |   |-SimpleDeclaration
+| |   | |-const
+| |   | |-int
+| |   | `-SimpleDeclarator
+| |   |   `-*
+| |   `-)
+| `-;
+`-SimpleDeclaration
+  |-void
+  |-SimpleDeclarator
+  | |-ParenDeclarator
+  | | |-(
+  | | |-X
+  | | |-::
+  | | |-MemberPointer
+  | | | |-Y
+  | | | |-::
+  | | | `-*
+  | | |-xyp
+  | | `-)
+  | `-ParametersAndQualifiers
+  |   |-(
+  |   |-SimpleDeclaration
+  |   | |-const
+  |   | |-int
+  |   | `-SimpleDeclarator
+  |   |   `-*
+  |   |-,
+  |   |-SimpleDeclaration
+  |   | `-char
+  |   `-)
+  `-;
+)txt"));
+}
+
 TEST_P(SyntaxTreeTest, ComplexDeclarator) {
   EXPECT_TRUE(treeDumpEqual(
   R"cpp(
Index: clang/lib/Tooling/Syntax/BuildTree.cpp
===
--- clang/lib/Tooling/Syntax/BuildTree.cpp
+++ clang/lib/Tooling/Syntax/BuildTree.cpp
@@ -939,6 +939,8 @@
 return true;
   }
 
+  // FIXME: Deleting the `TraverseParenTypeLoc` override doesn't change test
+  // results. Find test coverage or remove it.
   bool TraverseParenTypeLoc(ParenTypeLoc L) {
 // We reverse order of traversal to get the proper syntax structure.
 if (!WalkUpFromParenTypeLoc(L))
@@ -987,6 +989,16 @@
 return WalkUpFromFunctionTypeLoc(L);
   }
 
+  bool TraverseMemberPointerTypeLoc(MemberPointerTypeLoc L) {
+// In the source code "void (Y::*mp)()" `MemberPointerTypeLoc` corresponds
+// to "Y::*" but it points to a `ParenTypeLoc` that corresponds to
+// "(Y::*mp)" We thus reverse the order of traversal to get the proper
+// syntax structure.
+if (!WalkUpFromMemberPointerTypeLoc(L))
+  return false;
+return TraverseTypeLoc(L.getPointeeLoc());
+  }
+
   bool WalkUpFromMemberPointerTypeLoc(MemberPointerTypeLoc L) {
 auto SR = L.getLocalSourceRange();
 Builder.foldNode(Builder.getRange(SR),
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D84520: [Analyzer] Improve invalid dereference bug reporting in DereferenceChecker.

[Endre Fülöp via Phabricator via cfe-commits]

gamesh411 added a comment.

I would add one more test for the undefined case. Like a local array variable 
that is uninitialized. That could mirror some of the null-dereference cases.




Comment at: clang/lib/StaticAnalyzer/Checkers/DereferenceChecker.cpp:135
+DerefKindStr = "dereference of an undefined pointer value";
+break;
+  };

balazske wrote:
> Add "results in a " here?
IMHO I would add the "results in a " part here, as this is part of the process 
of creating the diagnostic anyway.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84520

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

[PATCH] D84412: [clang][Driver] Don't hardcode --as-needed/--no-as-needed on Illumos

[Rainer Orth via Phabricator via cfe-commits]

ro added a reviewer: MaskRay.
ro added a comment.

Ping?  It's been two weeks now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84412

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

[clang-tools-extra] 7c4782c - [clang-tidy] Fix regression in RenamerClangTidy

[Nathan James via cfe-commits]

Author: Nathan James
Date: 2020-08-04T09:27:01+01:00
New Revision: 7c4782ce91d66a8447a851362b99bb86a42b7c08

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

LOG: [clang-tidy] Fix regression in RenamerClangTidy

See bug https://bugs.llvm.org/show_bug.cgi\?id\=46976

Added: 


Modified: 
clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp
clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming.cpp

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp 
b/clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp
index 040378d980f1a..2d67ca4a16180 100644
--- a/clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp
+++ b/clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp
@@ -157,6 +157,9 @@ void RenamerClangTidyCheck::addUsage(
   RenamerClangTidyCheck::NamingCheckFailure &Failure =
   NamingCheckFailures[Decl];
 
+  if (!Failure.RawUsageLocs.insert(FixLocation.getRawEncoding()).second)
+return;
+
   if (!Failure.ShouldFix())
 return;
 
@@ -165,8 +168,6 @@ void RenamerClangTidyCheck::addUsage(
 
   if (!utils::rangeCanBeFixed(Range, SourceMgr))
 Failure.FixStatus = RenamerClangTidyCheck::ShouldFixStatus::InsideMacro;
-
-  Failure.RawUsageLocs.insert(FixLocation.getRawEncoding());
 }
 
 void RenamerClangTidyCheck::addUsage(const NamedDecl *Decl, SourceRange Range,

diff  --git 
a/clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming.cpp 
b/clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming.cpp
index 24c1c4270dec8..fed362bbecdec 100644
--- 
a/clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming.cpp
+++ 
b/clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming.cpp
@@ -578,3 +578,8 @@ void Foo() {
 #undef M1
 #undef DUP
 } // namespace scratchspace
+
+template
+auto GetRes(type_t& Param) -> decltype(Param.res());
+// CHECK-MESSAGES: :[[@LINE-1]]:21: warning: invalid case style for parameter 
'Param'
+// CHECK-FIXES: auto GetRes(type_t& a_param) -> decltype(a_param.res());



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

[PATCH] D85185: [SyntaxTree] Add test coverage for `->*` operator

[Eduardo Caldas via Phabricator via cfe-commits]

eduucaldas created this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
eduucaldas requested review of this revision.

This was the last binary operator that we supported but didn't have any
test coverage. The recent fix in a crash in member pointers allowed us
to add this test.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D85185

Files:
  clang/unittests/Tooling/Syntax/TreeTest.cpp


Index: clang/unittests/Tooling/Syntax/TreeTest.cpp
===
--- clang/unittests/Tooling/Syntax/TreeTest.cpp
+++ clang/unittests/Tooling/Syntax/TreeTest.cpp
@@ -2322,16 +2322,18 @@
   friend bool operator<(const X&, const X&);
   friend X operator<<(X&, const X&);
   X operator,(X&);
-  // TODO: Fix crash on member function pointer and add a test for `->*`
-  // TODO: Unbox operators in syntax tree. 
+  X operator->*(int);
+  // TODO: Unbox operators in syntax tree.
   // Represent operators by `+` instead of `IdExpression-UnqualifiedId-+`
 };
-void test(X x, X y) {
+int X::*pmi;
+void test(X x, X y, X* xp) {
   x = y;
   x + y;
   x < y;
   x << y;
   x, y;
+  xp->*pmi;
 }
 )cpp",
   R"txt(
@@ -2430,8 +2432,28 @@
 | | |   |   `-&
 | | |   `-)
 | | `-;
+| |-SimpleDeclaration
+| | |-X
+| | |-SimpleDeclarator
+| | | |-operator
+| | | |-->*
+| | | `-ParametersAndQualifiers
+| | |   |-(
+| | |   |-SimpleDeclaration
+| | |   | `-int
+| | |   `-)
+| | `-;
 | |-}
 | `-;
+|-SimpleDeclaration
+| |-int
+| |-SimpleDeclarator
+| | |-MemberPointer
+| | | |-X
+| | | |-::
+| | | `-*
+| | `-pmi
+| `-;
 `-SimpleDeclaration
   |-void
   |-SimpleDeclarator
@@ -2447,6 +2469,12 @@
   |   | |-X
   |   | `-SimpleDeclarator
   |   |   `-y
+  |   |-,
+  |   |-SimpleDeclaration
+  |   | |-X
+  |   | `-SimpleDeclarator
+  |   |   |-*
+  |   |   `-xp
   |   `-)
   `-CompoundStatement
 |-{
@@ -2511,6 +2539,16 @@
 | |   `-UnqualifiedId
 | | `-y
 | `-;
+|-ExpressionStatement
+| |-BinaryOperatorExpression
+| | |-IdExpression
+| | | `-UnqualifiedId
+| | |   `-xp
+| | |-->*
+| | `-IdExpression
+| |   `-UnqualifiedId
+| | `-pmi
+| `-;
 `-}
 )txt"));
 }


Index: clang/unittests/Tooling/Syntax/TreeTest.cpp
===
--- clang/unittests/Tooling/Syntax/TreeTest.cpp
+++ clang/unittests/Tooling/Syntax/TreeTest.cpp
@@ -2322,16 +2322,18 @@
   friend bool operator<(const X&, const X&);
   friend X operator<<(X&, const X&);
   X operator,(X&);
-  // TODO: Fix crash on member function pointer and add a test for `->*`
-  // TODO: Unbox operators in syntax tree. 
+  X operator->*(int);
+  // TODO: Unbox operators in syntax tree.
   // Represent operators by `+` instead of `IdExpression-UnqualifiedId-+`
 };
-void test(X x, X y) {
+int X::*pmi;
+void test(X x, X y, X* xp) {
   x = y;
   x + y;
   x < y;
   x << y;
   x, y;
+  xp->*pmi;
 }
 )cpp",
   R"txt(
@@ -2430,8 +2432,28 @@
 | | |   |   `-&
 | | |   `-)
 | | `-;
+| |-SimpleDeclaration
+| | |-X
+| | |-SimpleDeclarator
+| | | |-operator
+| | | |-->*
+| | | `-ParametersAndQualifiers
+| | |   |-(
+| | |   |-SimpleDeclaration
+| | |   | `-int
+| | |   `-)
+| | `-;
 | |-}
 | `-;
+|-SimpleDeclaration
+| |-int
+| |-SimpleDeclarator
+| | |-MemberPointer
+| | | |-X
+| | | |-::
+| | | `-*
+| | `-pmi
+| `-;
 `-SimpleDeclaration
   |-void
   |-SimpleDeclarator
@@ -2447,6 +2469,12 @@
   |   | |-X
   |   | `-SimpleDeclarator
   |   |   `-y
+  |   |-,
+  |   |-SimpleDeclaration
+  |   | |-X
+  |   | `-SimpleDeclarator
+  |   |   |-*
+  |   |   `-xp
   |   `-)
   `-CompoundStatement
 |-{
@@ -2511,6 +2539,16 @@
 | |   `-UnqualifiedId
 | | `-y
 | `-;
+|-ExpressionStatement
+| |-BinaryOperatorExpression
+| | |-IdExpression
+| | | `-UnqualifiedId
+| | |   `-xp
+| | |-->*
+| | `-IdExpression
+| |   `-UnqualifiedId
+| | `-pmi
+| `-;
 `-}
 )txt"));
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D85186: [SyntaxTree] Add support for `LiteralExpression`

[Eduardo Caldas via Phabricator via cfe-commits]

eduucaldas created this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
eduucaldas requested review of this revision.

We use inheritance to model the grammar's disjunction rule:
literal:

  integer-literal
  character-literal
  floating-point-literal
  string-literal
  boolean-literal
  pointer-literal
  user-defined-literal


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D85186

Files:
  clang/include/clang/Tooling/Syntax/Nodes.h
  clang/lib/Tooling/Syntax/Nodes.cpp

Index: clang/lib/Tooling/Syntax/Nodes.cpp
===
--- clang/lib/Tooling/Syntax/Nodes.cpp
+++ clang/lib/Tooling/Syntax/Nodes.cpp
@@ -230,37 +230,7 @@
   findChild(syntax::NodeRole::CloseParen));
 }
 
-syntax::Leaf *syntax::IntegerLiteralExpression::literalToken() {
-  return llvm::cast_or_null(
-  findChild(syntax::NodeRole::LiteralToken));
-}
-
-syntax::Leaf *syntax::CharacterLiteralExpression::literalToken() {
-  return llvm::cast_or_null(
-  findChild(syntax::NodeRole::LiteralToken));
-}
-
-syntax::Leaf *syntax::FloatingLiteralExpression::literalToken() {
-  return llvm::cast_or_null(
-  findChild(syntax::NodeRole::LiteralToken));
-}
-
-syntax::Leaf *syntax::StringLiteralExpression::literalToken() {
-  return llvm::cast_or_null(
-  findChild(syntax::NodeRole::LiteralToken));
-}
-
-syntax::Leaf *syntax::BoolLiteralExpression::literalToken() {
-  return llvm::cast_or_null(
-  findChild(syntax::NodeRole::LiteralToken));
-}
-
-syntax::Leaf *syntax::CxxNullPtrExpression::nullPtrKeyword() {
-  return llvm::cast_or_null(
-  findChild(syntax::NodeRole::LiteralToken));
-}
-
-syntax::Leaf *syntax::UserDefinedLiteralExpression::literalToken() {
+syntax::Leaf *syntax::LiteralExpression::literalToken() {
   return llvm::cast_or_null(
   findChild(syntax::NodeRole::LiteralToken));
 }
Index: clang/include/clang/Tooling/Syntax/Nodes.h
===
--- clang/include/clang/Tooling/Syntax/Nodes.h
+++ clang/include/clang/Tooling/Syntax/Nodes.h
@@ -267,66 +267,82 @@
   syntax::Leaf *closeParen();
 };
 
+/// Expression for literals. C++ [lex.literal]
+class LiteralExpression : public Expression {
+public:
+  LiteralExpression(NodeKind K) : Expression(K) {}
+  static bool classof(const Node *N) {
+return N->kind() == NodeKind::IntegerLiteralExpression ||
+   N->kind() == NodeKind::CharacterLiteralExpression ||
+   N->kind() == NodeKind::FloatingLiteralExpression ||
+   N->kind() == NodeKind::StringLiteralExpression ||
+   N->kind() == NodeKind::BoolLiteralExpression ||
+   N->kind() == NodeKind::CxxNullPtrExpression ||
+   N->kind() == NodeKind::IntegerUserDefinedLiteralExpression ||
+   N->kind() == NodeKind::FloatUserDefinedLiteralExpression ||
+   N->kind() == NodeKind::CharUserDefinedLiteralExpression ||
+   N->kind() == NodeKind::StringUserDefinedLiteralExpression;
+  }
+  syntax::Leaf *literalToken();
+};
+
 /// Expression for integer literals. C++ [lex.icon]
-class IntegerLiteralExpression final : public Expression {
+class IntegerLiteralExpression final : public LiteralExpression {
 public:
-  IntegerLiteralExpression() : Expression(NodeKind::IntegerLiteralExpression) {}
+  IntegerLiteralExpression()
+  : LiteralExpression(NodeKind::IntegerLiteralExpression) {}
   static bool classof(const Node *N) {
 return N->kind() == NodeKind::IntegerLiteralExpression;
   }
-  syntax::Leaf *literalToken();
 };
 
 /// Expression for character literals. C++ [lex.ccon]
-class CharacterLiteralExpression final : public Expression {
+class CharacterLiteralExpression final : public LiteralExpression {
 public:
   CharacterLiteralExpression()
-  : Expression(NodeKind::CharacterLiteralExpression) {}
+  : LiteralExpression(NodeKind::CharacterLiteralExpression) {}
   static bool classof(const Node *N) {
 return N->kind() == NodeKind::CharacterLiteralExpression;
   }
-  syntax::Leaf *literalToken();
 };
 
 /// Expression for floating-point literals. C++ [lex.fcon]
-class FloatingLiteralExpression final : public Expression {
+class FloatingLiteralExpression final : public LiteralExpression {
 public:
   FloatingLiteralExpression()
-  : Expression(NodeKind::FloatingLiteralExpression) {}
+  : LiteralExpression(NodeKind::FloatingLiteralExpression) {}
   static bool classof(const Node *N) {
 return N->kind() == NodeKind::FloatingLiteralExpression;
   }
-  syntax::Leaf *literalToken();
 };
 
 /// Expression for string-literals. C++ [lex.string]
-class StringLiteralExpression final : public Expression {
+class StringLiteralExpression final : public LiteralExpression {
 public:
-  StringLiteralExpression() : Expression(NodeKind::StringLiteralExpression) {}
+  StringLiteralExpression()
+  : LiteralExpression(NodeKind::StringLiteralExpression) {}
   static bool classof(const Node *N) 

[clang] 141cb8a - [analyzer] Model iterator random incrementation symmetrically

[Endre Fulop via cfe-commits]

Author: Endre Fülöp
Date: 2020-08-04T11:04:12+02:00
New Revision: 141cb8a1eecc0c843cdd4e788a28d2b6715e4dc5

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

LOG: [analyzer] Model iterator random incrementation symmetrically

Summary:
In case a pointer iterator is incremented in a binary plus expression
(operator+), where the iterator is on the RHS, IteratorModeling should
now detect, and track the resulting value.

Reviewers: Szelethus, baloghadamsoftware

Reviewed By: baloghadamsoftware

Subscribers: rnkovacs, whisperity, xazax.hun, baloghadamsoftware, szepet, 
a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, Charusso, steakhal, 
martong, ASDenysPetrov, cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
clang/test/Analysis/iterator-modeling.cpp

Removed: 




diff  --git a/clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp 
b/clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
index 632de9e5dc83..ab5e6a1c9991 100644
--- a/clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
@@ -109,7 +109,7 @@ class IteratorModeling
bool Postfix) const;
   void handleRandomIncrOrDecr(CheckerContext &C, const Expr *CE,
   OverloadedOperatorKind Op, const SVal &RetVal,
-  const SVal &LHS, const SVal &RHS) const;
+  const SVal &Iterator, const SVal &Amount) const;
   void handlePtrIncrOrDecr(CheckerContext &C, const Expr *Iterator,
OverloadedOperatorKind OK, SVal Offset) const;
   void handleAdvance(CheckerContext &C, const Expr *CE, SVal RetVal, SVal Iter,
@@ -262,20 +262,30 @@ void IteratorModeling::checkPostStmt(const UnaryOperator 
*UO,
 
 void IteratorModeling::checkPostStmt(const BinaryOperator *BO,
  CheckerContext &C) const {
-  ProgramStateRef State = C.getState();
-  BinaryOperatorKind OK = BO->getOpcode();
-  SVal RVal = State->getSVal(BO->getRHS(), C.getLocationContext());
+  const ProgramStateRef State = C.getState();
+  const BinaryOperatorKind OK = BO->getOpcode();
+  const Expr *const LHS = BO->getLHS();
+  const Expr *const RHS = BO->getRHS();
+  const SVal LVal = State->getSVal(LHS, C.getLocationContext());
+  const SVal RVal = State->getSVal(RHS, C.getLocationContext());
 
   if (isSimpleComparisonOperator(BO->getOpcode())) {
-SVal LVal = State->getSVal(BO->getLHS(), C.getLocationContext());
 SVal Result = State->getSVal(BO, C.getLocationContext());
 handleComparison(C, BO, Result, LVal, RVal,
  BinaryOperator::getOverloadedOperator(OK));
   } else if (isRandomIncrOrDecrOperator(OK)) {
-if (!BO->getRHS()->getType()->isIntegralOrEnumerationType())
+// In case of operator+ the iterator can be either on the LHS (eg.: it + 
1),
+// or on the RHS (eg.: 1 + it). Both cases are modeled.
+const bool IsIterOnLHS = BO->getLHS()->getType()->isPointerType();
+const Expr *const &IterExpr = IsIterOnLHS ? LHS : RHS;
+const Expr *const &AmountExpr = IsIterOnLHS ? RHS : LHS;
+
+// The non-iterator side must have an integral or enumeration type.
+if (!AmountExpr->getType()->isIntegralOrEnumerationType())
   return;
-handlePtrIncrOrDecr(C, BO->getLHS(),
-BinaryOperator::getOverloadedOperator(OK), RVal);
+const SVal &AmountVal = IsIterOnLHS ? RVal : LVal;
+handlePtrIncrOrDecr(C, IterExpr, BinaryOperator::getOverloadedOperator(OK),
+AmountVal);
   }
 }
 
@@ -368,11 +378,24 @@ IteratorModeling::handleOverloadedOperator(CheckerContext 
&C,
  InstCall->getCXXThisVal(), 
Call.getArgSVal(0));
   return;
 }
-  } else {
-if (Call.getNumArgs() >= 2 &&
-  Call.getArgExpr(1)->getType()->isIntegralOrEnumerationType()) {
+  } else if (Call.getNumArgs() >= 2) {
+const Expr *FirstArg = Call.getArgExpr(0);
+const Expr *SecondArg = Call.getArgExpr(1);
+const QualType FirstType = FirstArg->getType();
+const QualType SecondType = SecondArg->getType();
+
+if (FirstType->isIntegralOrEnumerationType() ||
+SecondType->isIntegralOrEnumerationType()) {
+  // In case of operator+ the iterator can be either on the LHS (eg.:
+  // it + 1), or on the RHS (eg.: 1 + it). Both cases are modeled.
+  const bool IsIterFirst = FirstType->isStructureOrClassType();
+  const SVal FirstArg = Call.getArgSVal(0);
+  const SVal SecondArg = Call.getArgSVal(1);
+  const SVal &Iterator =

[PATCH] D83190: [analyzer] Model iterator random incrementation symmetrically

[Endre Fülöp 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 rG141cb8a1eecc: [analyzer] Model iterator random 
incrementation symmetrically (authored by gamesh411).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83190

Files:
  clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
  clang/test/Analysis/iterator-modeling.cpp

Index: clang/test/Analysis/iterator-modeling.cpp
===
--- clang/test/Analysis/iterator-modeling.cpp
+++ clang/test/Analysis/iterator-modeling.cpp
@@ -149,7 +149,7 @@
   clang_analyzer_express(clang_analyzer_iterator_position(i2)); // expected-warning-re {{$v.end(){{$
 }
 
-void plus(const std::vector &v) {
+void plus_lhs(const std::vector &v) {
   auto i1 = v.begin();
 
   clang_analyzer_denote(clang_analyzer_container_begin(v), "$v.begin()");
@@ -161,7 +161,19 @@
   clang_analyzer_express(clang_analyzer_iterator_position(i2)); // expected-warning-re{{$v.begin() + 2{{$
 }
 
-void plus_negative(const std::vector &v) {
+void plus_rhs(const std::vector &v) {
+  auto i1 = v.begin();
+
+  clang_analyzer_denote(clang_analyzer_container_begin(v), "$v.begin()");
+
+  auto i2 = 2 + i1;
+
+  clang_analyzer_eval(clang_analyzer_iterator_container(i2) == &v); // expected-warning{{TRUE}}
+  clang_analyzer_express(clang_analyzer_iterator_position(i1)); // expected-warning-re{{$v.begin(){{$
+  clang_analyzer_express(clang_analyzer_iterator_position(i2)); // expected-warning-re{{$v.begin() + 2{{$
+}
+
+void plus_lhs_negative(const std::vector &v) {
   auto i1 = v.end();
 
   clang_analyzer_denote(clang_analyzer_container_end(v), "$v.end()");
@@ -173,6 +185,18 @@
   clang_analyzer_express(clang_analyzer_iterator_position(i2)); // expected-warning-re {{$v.end() - 2{{$
 }
 
+void plus_rhs_negative(const std::vector &v) {
+  auto i1 = v.end();
+
+  clang_analyzer_denote(clang_analyzer_container_end(v), "$v.end()");
+
+  auto i2 = (-2) + i1;
+
+  clang_analyzer_eval(clang_analyzer_iterator_container(i2) == &v); // expected-warning{{TRUE}}
+  clang_analyzer_express(clang_analyzer_iterator_position(i1)); // expected-warning-re {{$v.end(){{$
+  clang_analyzer_express(clang_analyzer_iterator_position(i2)); // expected-warning-re {{$v.end() - 2{{$
+}
+
 void minus(const std::vector &v) {
   auto i1 = v.end();
 
@@ -1955,7 +1979,7 @@
   i -= n; // no-crash
 }
 
-void plus_ptr_iterator(const cont_with_ptr_iterator &c) {
+void plus_lhs_ptr_iterator(const cont_with_ptr_iterator &c) {
   auto i1 = c.begin();
 
   clang_analyzer_denote(clang_analyzer_container_begin(c), "$c.begin()");
@@ -1967,6 +1991,18 @@
   clang_analyzer_express(clang_analyzer_iterator_position(i2)); // expected-warning{{$c.begin() + 2}}
 }
 
+void plus_rhs_ptr_iterator(const cont_with_ptr_iterator &c) {
+  auto i1 = c.begin();
+
+  clang_analyzer_denote(clang_analyzer_container_begin(c), "$c.begin()");
+
+  auto i2 = 2 + i1;
+
+  clang_analyzer_eval(clang_analyzer_iterator_container(i2) == &c); // expected-warning{{TRUE}}
+  clang_analyzer_express(clang_analyzer_iterator_position(i1)); // expected-warning{{$c.begin()}}
+  clang_analyzer_express(clang_analyzer_iterator_position(i2)); // expected-warning{{$c.begin() + 2}}
+}
+
 void minus_ptr_iterator(const cont_with_ptr_iterator &c) {
   auto i1 = c.end();
 
Index: clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
+++ clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
@@ -109,7 +109,7 @@
bool Postfix) const;
   void handleRandomIncrOrDecr(CheckerContext &C, const Expr *CE,
   OverloadedOperatorKind Op, const SVal &RetVal,
-  const SVal &LHS, const SVal &RHS) const;
+  const SVal &Iterator, const SVal &Amount) const;
   void handlePtrIncrOrDecr(CheckerContext &C, const Expr *Iterator,
OverloadedOperatorKind OK, SVal Offset) const;
   void handleAdvance(CheckerContext &C, const Expr *CE, SVal RetVal, SVal Iter,
@@ -262,20 +262,30 @@
 
 void IteratorModeling::checkPostStmt(const BinaryOperator *BO,
  CheckerContext &C) const {
-  ProgramStateRef State = C.getState();
-  BinaryOperatorKind OK = BO->getOpcode();
-  SVal RVal = State->getSVal(BO->getRHS(), C.getLocationContext());
+  const ProgramStateRef State = C.getState();
+  const BinaryOperatorKind OK = BO->getOpcode();
+  const Expr *const LHS = BO->getLHS();
+  const Expr *const RHS = BO->getRHS();
+  const SVal LVal = State->getSVal(LHS, C.getLocationContext());
+  const SVal RVal = State->getSVal(RHS, C.getLocationContext());
 
   if (isSimpleCompa

[PATCH] D83717: [clang-tidy] Add check fo SEI CERT item ENV32-C

[Endre Fülöp via Phabricator via cfe-commits]

gamesh411 updated this revision to Diff 282837.
gamesh411 marked an inline comment as done.
gamesh411 added a comment.

rename file name in header


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83717

Files:
  clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp
  clang-tools-extra/clang-tidy/cert/CMakeLists.txt
  clang-tools-extra/clang-tidy/cert/ExitHandlerCheck.cpp
  clang-tools-extra/clang-tidy/cert/ExitHandlerCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/cert-env32-c.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/checkers/cert-env32-c.c
  llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/cert/BUILD.gn

Index: llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/cert/BUILD.gn
===
--- llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/cert/BUILD.gn
+++ llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/cert/BUILD.gn
@@ -19,6 +19,7 @@
 "CommandProcessorCheck.cpp",
 "DefaultOperatorNewAlignmentCheck.cpp",
 "DontModifyStdNamespaceCheck.cpp",
+"ExitHandlerCheck.cpp",
 "FloatLoopCounter.cpp",
 "LimitedRandomnessCheck.cpp",
 "MutatingCopyCheck.cpp",
Index: clang-tools-extra/test/clang-tidy/checkers/cert-env32-c.c
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/cert-env32-c.c
@@ -0,0 +1,324 @@
+// RUN: %check_clang_tidy %s cert-env32-c %t
+
+// --
+// EXIT FUNCTIONS
+// --
+
+// No handlers are invoked when _Exit is called.
+void _Exit(int __status);
+
+// Handlers registered by atexit are invoked in reverse order when exit is
+// called.
+void exit(int __status);
+
+// Handlers registered by at_quick_exit are invoked in reverse order when
+// quick_exit is called.
+void quick_exit(int __status);
+
+// 
+// HANDLER REGISTRATION
+// 
+
+// Register handlers to run when exit is called.
+int atexit(void (*__func)(void));
+
+// Register handlers to run when exit is called.
+int at_quick_exit(void (*__func)(void));
+
+// --
+// Setjmp/longjmp
+// --
+// C99 requires jmp_buf to be an array type.
+typedef int jmp_buf[1];
+int setjmp(jmp_buf);
+void longjmp(jmp_buf, int);
+
+// Compliant solutions
+
+void cleanup1() {
+  // do cleanup
+}
+
+void cleanup2() {
+  // do cleanup
+}
+
+void test_atexit_single_compliant() {
+  (void)atexit(cleanup1);
+}
+
+void test_atexit_multiple_compliant() {
+  (void)atexit(cleanup1);
+  (void)atexit(cleanup2);
+}
+
+void test_at_quick_exit_single_compliant() {
+  (void)at_quick_exit(cleanup1);
+}
+
+void test_at_quick_exit_multiple_compliant() {
+  (void)at_quick_exit(cleanup1);
+  (void)at_quick_exit(cleanup2);
+}
+
+// Non-compliant solutions calling _Exit
+
+void call__Exit() {
+  _Exit(0);
+}
+
+void call_call__Exit() {
+  call__Exit();
+}
+
+extern int unknown__Exit_flag;
+
+void call__Exit_conditionally() {
+  if (unknown__Exit_flag)
+call__Exit();
+}
+
+void call_call__Exit_conditionally() {
+  call__Exit_conditionally();
+}
+
+void test__Exit_called_directly() {
+  (void)atexit(call__Exit);
+  // CHECK-NOTES: :[[@LINE-1]]:9: warning: exit-handler potentially calls an exit function. Handlers should terminate by returning [cert-env32-c]
+  // CHECK-NOTES: :[[@LINE-22]]:1: note: handler function declared here
+  // CHECK-NOTES: :[[@LINE-22]]:3: note: exit function called here
+  (void)at_quick_exit(call__Exit);
+  // CHECK-NOTES: :[[@LINE-1]]:9: warning: exit-handler potentially calls an exit function. Handlers should terminate by returning [cert-env32-c]
+  // CHECK-NOTES: :[[@LINE-26]]:1: note: handler function declared here
+  // CHECK-NOTES: :[[@LINE-26]]:3: note: exit function called here
+};
+
+void test__Exit_called_indirectly() {
+  (void)atexit(call_call__Exit);
+  // CHECK-NOTES: :[[@LINE-1]]:9: warning: exit-handler potentially calls an exit function. Handlers should terminate by returning [cert-env32-c]
+  // CHECK-NOTES: :[[@LINE-29]]:1: note: handler function declared here
+  // CHECK-NOTES: :[[@LINE-33]]:3: note: exit function called here
+  (void)at_quick_exit(call_call__Exit);
+  // CHECK-NOTES: :[[@LINE-1]]:9: warning: exit-handler potentially calls an exit function. Handlers should terminate by returning [cert-env32-c]
+  // CHECK-NOTES: :[[@LINE-33]]:1: note: handler function declared here
+  // CHECK-NOTES: :[[@LINE-37]]:3: note: exit function called here
+};
+
+void test_conditional__Exit_called_directly() {
+  (void)atexit(call__Exit_conditionally);
+  // CHECK-NOTES: :[[@LINE-1]]:9: warning: exit-handler potentially calls an exit function. Handlers should terminate by returning [cert-env32-c]
+  // CHECK-NOTES: :[[@LINE-34]]:1: note: handler function declared here
+  // CHECK-NOTES: :[[@LINE-44]]:3: note: exit funct

[PATCH] D67422: [analyzer] NFC: Move path diagnostic consumer implementations to libAnalysis.

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus added a comment.

In D67422#2192407 , @NoQ wrote:

> One bit that's not directly related but i decided to keep it from the 
> original patch was moving the plist-html diagnostic builder function into its 
> own file.

That is a great call indeed.

>> I'm also starting to wonder whether this diagnostics infrastructure should 
>> be in its own library, not in libAnalysis -- what do you think?
>
> Maybe! libAnalysis is currently a mess; it's basically a collection of all 
> static-analyzer-ish things that are also used outside of the static analyzer. 
> That's indeed not a good definition for a library. It incorporates a number 
> of completely unrelated things.

Not to mention my new plugins were knocked around all over the place, and 
eventually they also landed in it. I think libAnalysis is indeed well overdue 
for a revision, maybe sooner rather then later. There aren't too many other 
changes in this patch, maybe its worth doing this right away? I don't insist.


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

https://reviews.llvm.org/D67422

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

[PATCH] D85128: [Prototype][SVE] Support arm_sve_vector_bits attribute

[Cullen Rhodes via Phabricator via cfe-commits]

c-rhodes added a comment.

In D85128#2191108 , @tschuett wrote:

> Stupid questions.
>
> - Is it for convenience? You get arrays, global variables, structs, ... . 
> Vectorization becomes easier ...

Yes, this allows the definition of types that can be used in constructs 
sizeless types cannot. In earlier revisions of the ACLE there was the concept 
of sizeless structs defined by a `__sizeless_struct` keyword that could have 
members of sizeless type in addition to members of sized type, although there 
was push back on the idea of sizeless aggregates in general and that idea was 
dropped. If you're interested in the background there's more information here 
[1][2].

[1] https://gcc.gnu.org/legacy-ml/gcc/2019-11/msg00088.html
[2] https://gcc.gnu.org/legacy-ml/gcc-patches/2018-10/msg00868.html

> - Are there any potential performance benefits over scalable vectors?

If VLSTs are represented as fixed-length vectors in LLVM as they are in this 
prototype then hopefully we can take advantage of existing optimisations, 
although I think there is work to be done there especially around the 
interaction with scalable vectors and supporting those in existing passes. This 
patch required a few changes to existing passes to bail out for scalable 
vectors so we're already hitting parts of the codebase we've yet to hit that 
would be good candidates for optimisation work. This also ties into the 
fixed-length code generation work @paulwalker-arm has been doing which is still 
early days. I'm not sure if that answers your question, but ultimately the 
compiler should have more information about these types given the vector size 
is explicit so it should be able to do a better job at optimisation.

> - Is it compatible with GCC?

Support for this attribute landed in GCC 10 and it's more complete than what 
this patch implements. We've yet to implement the behaviour guarded by the 
`__ARM_FEATURE_SVE_VECTOR_OPERATORS` and 
`__ARM_FEATURE_SVE_PREDICATE_OPERATORS` feature macros, so the GNU 
`__attribute__((vector_size))` extension is not available and operators such as 
binary '+' are not supported for VLSTs. Support for this is intended to be 
addressed by later patches.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85128

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

[PATCH] D85097: [Sema] add warning for comparisons like 'x<=y<=z'

[Vince Bridgers via Phabricator via cfe-commits]

vabridgers updated this revision to Diff 282852.
vabridgers added a comment.

isRelationalOp


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85097

Files:
  clang/docs/DiagnosticsReference.rst
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaExpr.cpp
  clang/test/Misc/warning-wall.c
  clang/test/Sema/warn-compare-op-parentheses.c

Index: clang/test/Sema/warn-compare-op-parentheses.c
===
--- /dev/null
+++ clang/test/Sema/warn-compare-op-parentheses.c
@@ -0,0 +1,176 @@
+// RUN: %clang_cc1 -fsyntax-only -Wcompare-op-parentheses -verify %s
+
+int tests(int p1, int p2, int p3, int p4, int p5, int p6) {
+  int b = 0;
+  b = p1 < p2 < p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '<' expression to silence this warning}}
+  b = p1 < p2 <= p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '<' expression to silence this warning}}
+  b = p1 <= p2 <= p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '<=' expression to silence this warning}}
+  b = p1 <= p2 < p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '<=' expression to silence this warning}}
+
+  b = p1 > p2 > p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '>' expression to silence this warning}}
+  b = p1 > p2 >= p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '>' expression to silence this warning}}
+  b = p1 >= p2 >= p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '>=' expression to silence this warning}}
+  b = p1 >= p2 > p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '>=' expression to silence this warning}}
+
+  b = p1 > p2 < p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '>' expression to silence this warning}}
+  b = p1 p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '<' expression to silence this warning}}
+
+  b = p1 > p2 <= p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '>' expression to silence this warning}}
+  b = p1 < p2 >= p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '<' expression to silence this warning}}
+
+  b = p1 >= p2 < p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '>=' expression to silence this warning}}
+  b = p1 <= p2 > p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '<=' expression to silence this warning}}
+
+  b = p1 >= p2 <= p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '>=' expression to silence this warning}}
+  b = p1 <= p2 >= p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '<=' expression to silence this warning}}
+
+  b = p1 < p2 < p3 < p4;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '<' expression to silence this warning}}
+  // expected-warning@-3 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-4 {{place parentheses around the '<' expression to silence this warning}}
+  b = (p1 < p2) < p3 < p4;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '<' expression to silence this warning}}
+  b = p1 < (p2 < p3) < p4;
+  // expected-warning@-1 {{comparisons like '

[PATCH] D85097: [Sema] add warning for comparisons like 'x<=y<=z'

[Vince Bridgers via Phabricator via cfe-commits]

vabridgers updated this revision to Diff 282854.
vabridgers added a comment.

fix misc test formatting


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85097

Files:
  clang/docs/DiagnosticsReference.rst
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaExpr.cpp
  clang/test/Misc/warning-wall.c
  clang/test/Sema/warn-compare-op-parentheses.c

Index: clang/test/Sema/warn-compare-op-parentheses.c
===
--- /dev/null
+++ clang/test/Sema/warn-compare-op-parentheses.c
@@ -0,0 +1,176 @@
+// RUN: %clang_cc1 -fsyntax-only -Wcompare-op-parentheses -verify %s
+
+int tests(int p1, int p2, int p3, int p4, int p5, int p6) {
+  int b = 0;
+  b = p1 < p2 < p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '<' expression to silence this warning}}
+  b = p1 < p2 <= p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '<' expression to silence this warning}}
+  b = p1 <= p2 <= p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '<=' expression to silence this warning}}
+  b = p1 <= p2 < p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '<=' expression to silence this warning}}
+
+  b = p1 > p2 > p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '>' expression to silence this warning}}
+  b = p1 > p2 >= p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '>' expression to silence this warning}}
+  b = p1 >= p2 >= p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '>=' expression to silence this warning}}
+  b = p1 >= p2 > p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '>=' expression to silence this warning}}
+
+  b = p1 > p2 < p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '>' expression to silence this warning}}
+  b = p1 p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '<' expression to silence this warning}}
+
+  b = p1 > p2 <= p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '>' expression to silence this warning}}
+  b = p1 < p2 >= p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '<' expression to silence this warning}}
+
+  b = p1 >= p2 < p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '>=' expression to silence this warning}}
+  b = p1 <= p2 > p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '<=' expression to silence this warning}}
+
+  b = p1 >= p2 <= p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '>=' expression to silence this warning}}
+  b = p1 <= p2 >= p3;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '<=' expression to silence this warning}}
+
+  b = p1 < p2 < p3 < p4;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '<' expression to silence this warning}}
+  // expected-warning@-3 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-4 {{place parentheses around the '<' expression to silence this warning}}
+  b = (p1 < p2) < p3 < p4;
+  // expected-warning@-1 {{comparisons like 'x<=y<=z' are interpreted as '(x<=y ? 1 : 0) <= z'}}
+  // expected-note@-2 {{place parentheses around the '<' expression to silence this warning}}
+  b = p1 < (p2 < p3) < p4;
+  // expected-warning@-1 {{comparis

[PATCH] D85097: [Sema] add warning for comparisons like 'x<=y<=z'

[Vince Bridgers via Phabricator via cfe-commits]

vabridgers marked 2 inline comments as done.
vabridgers added inline comments.



Comment at: clang/lib/Sema/SemaExpr.cpp:14047
 
+static bool isComparisonOpSamePrecedence(BinaryOperatorKind Opc) {
+  switch (Opc) {

njames93 wrote:
> Quuxplusone wrote:
> > Same precedence as what?
> > I think this should just be called `isRelationalOperator`, and I would bet 
> > money that such a classifier function already exists somewhere in the 
> > codebase.
> `isRelationalOp` and its a member function of `BinaryOperator` so there is no 
> need to even access the OperatorKind.
Fixed, thanks



Comment at: clang/lib/Sema/SemaExpr.cpp:14047
 
+static bool isComparisonOpSamePrecedence(BinaryOperatorKind Opc) {
+  switch (Opc) {

vabridgers wrote:
> njames93 wrote:
> > Quuxplusone wrote:
> > > Same precedence as what?
> > > I think this should just be called `isRelationalOperator`, and I would 
> > > bet money that such a classifier function already exists somewhere in the 
> > > codebase.
> > `isRelationalOp` and its a member function of `BinaryOperator` so there is 
> > no need to even access the OperatorKind.
> Fixed, thanks
Fixed, thanks



Comment at: clang/lib/Sema/SemaExpr.cpp:14010
+  << Bop->getSourceRange() << OpLoc;
+  SuggestParentheses(Self, Bop->getOperatorLoc(),
+ Self.PDiag(diag::note_precedence_silence)

njames93 wrote:
> Quuxplusone wrote:
> > vabridgers wrote:
> > > vabridgers wrote:
> > > > lebedev.ri wrote:
> > > > > Should we also suggest the fix to rewrite into what user likely 
> > > > > intended?
> > > > > `(x op1 y) && (y op2 z)`
> > > > I'll work on this, post in a next update. Thank you!
> > > Hi @lebedev.ri , the warning emits a note that says "place parentheses 
> > > around the '' expression to silence this warning" (see the test cases 
> > > below). Is this sufficient, or are you looking for something else?
> > https://godbolt.org/z/d1dG1o
> > For the very similar situation `(x & 1 == 0)`, Clang suggests //two 
> > different fixits//, and I believe Roman was suggesting that you should do 
> > the same kind of thing here.
> > ```
> > :3:16: warning: & has lower precedence than ==; == will be 
> > evaluated first [-Wparentheses]
> > int y = (x & 1 == 0);
> >^~~~
> > :3:16: note: place parentheses around the '==' expression to 
> > silence this warning
> > int y = (x & 1 == 0);
> >^
> >  ( )
> > :3:16: note: place parentheses around the & expression to evaluate 
> > it first
> > int y = (x & 1 == 0);
> >^
> >  ()
> > ```
> > For our situation here it would be something like
> > ```
> > :3:16: warning: chained comparisons like 'x<=y<=z' are interpreted 
> > as '(x<=y ? 1 : 0) <= z' [-Wcompare-op-parentheses]
> > int w = (x < y < z);
> >^~~~
> > :3:16: note: place parentheses around the first '<' expression to 
> > silence this warning
> > int w = (x < y < z);
> >  ^
> >  ()
> > :3:16: note: separate the expression into two clauses to give it 
> > the mathematical meaning
> > int y = (x < y < z);
> >^
> >  () && (y)
> > ```
> > Watch out that you don't suggest a wrong fixit for `(0 <= sideeffect() < 
> > 10)`, though. I seem to recall another warning that recently had a lot of 
> > trouble phrasing its fixit in a way that wouldn't invoke UB or change the 
> > behavior of the code in corner cases, but I forget the details.
> Surely you'd just need to check `y` for side effects before creating the 
> fix-it.
Still working on these, thanks



Comment at: clang/lib/Sema/SemaExpr.cpp:14010
+  << Bop->getSourceRange() << OpLoc;
+  SuggestParentheses(Self, Bop->getOperatorLoc(),
+ Self.PDiag(diag::note_precedence_silence)

vabridgers wrote:
> njames93 wrote:
> > Quuxplusone wrote:
> > > vabridgers wrote:
> > > > vabridgers wrote:
> > > > > lebedev.ri wrote:
> > > > > > Should we also suggest the fix to rewrite into what user likely 
> > > > > > intended?
> > > > > > `(x op1 y) && (y op2 z)`
> > > > > I'll work on this, post in a next update. Thank you!
> > > > Hi @lebedev.ri , the warning emits a note that says "place parentheses 
> > > > around the '' expression to silence this warning" (see the test 
> > > > cases below). Is this sufficient, or are you looking for something else?
> > > https://godbolt.org/z/d1dG1o
> > > For the very similar situation `(x & 1 == 0)`, Clang suggests //two 
> > > different fixits//, and I believe Roman was suggesting that you should do 
> > > the same kind of thing here.
> > > ```
> > > :3:16: warning: & has lower precedence than ==; == will be 
> > > evaluated first [-Wparentheses]
> > > int y = (x & 1 == 0);
> > >^~~~
> > > :3:16: note: place parentheses around the '==' expressi

[PATCH] D84520: [Analyzer] Improve invalid dereference bug reporting in DereferenceChecker.

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus added a comment.

We definitely need more tests. The idea overall however is amazing, thanks!




Comment at: clang/test/Analysis/misc-ps-region-store.m:1160
   struct list_pr8141 *items;
-  for (;; items = ({ do { } while (0); items->tail; })) // 
expected-warning{{Dereference of undefined pointer value}}
+  for (;; items = ({ do { } while (0); items->tail; })) // 
expected-warning{{dereference of an undefined pointer value}}
 {

Is this the entire message? Because traditionally, analyzer warnings start with 
an upper case and don't terminate.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84520

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

[PATCH] D82949: [Driver][ARM] Disable bf16 when hardware FP support is missing

[Momchil Velikov via Phabricator via cfe-commits]

chill added a comment.

Is this patch needed anymore?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82949

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

[PATCH] D82949: [Driver][ARM] Disable bf16 when hardware FP support is missing

[Victor Campos via Phabricator via cfe-commits]

vhscampos added a comment.

Not really. Closing it


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82949

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

[PATCH] D72705: [analyzer] Added new checker 'alpha.unix.ErrorReturn'.

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus added a comment.

Would it be possible to publish these results on a public CodeChecker server?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72705

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

[PATCH] D85128: [Prototype][SVE] Support arm_sve_vector_bits attribute

[Cullen Rhodes via Phabricator via cfe-commits]

c-rhodes added a comment.

In D85128#2191401 , @efriedma wrote:

> Not going to write detailed review comments, but this looks like the right 
> approach in general.

Thanks for taking a look! I'll split this up into separate patches soon.

> One high-level thing to consider: we could still decide that in IR 
> generation, we want to represent VLSTs registers using scalable vector types, 
> like the original patch did.  This would allow avoiding the awkward "bitcast" 
> implementation.  That interacts with a relatively narrow slice of clang 
> CodeGen, though; we could easily change it later without impacting the rest 
> of the changes.

Yeah now that the VLST is part of the canonical type with the new vector kinds 
we have more information if we were to go the CodeGenTypes route if that's what 
you're referring to as the narrow slice of CodeGen. That would still require 
converting between VLAT/VLST, I quite like this approach as it gives me more 
confidence we're not missing bitcasts when doing it as part of a cast 
operation. I guess with what you're suggesting the bitcast could still be 
emitted there but the cast operations could be limited in Sema to cases where 
ultimately `ConvertType` would return a type that requires bitcasting, or are 
you saying that could be avoided completely?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85128

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

[PATCH] D85191: [AST] Get field size in chars rather than bits in RecordLayoutBuilder.

[Bevin Hansson via Phabricator via cfe-commits]

ebevhan created this revision.
ebevhan added reviewers: jasonliu, efriedma.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
ebevhan requested review of this revision.

In D79719 , LayoutField was refactored to 
fetch the size of field
types in bits and then convert to chars, rather than fetching
them in chars directly. This is not ideal, since it makes the
calculations char size dependent, and breaks for sizes that
are not a multiple of the char size.

This patch changes it to use getTypeInfoInChars instead of
getTypeInfo.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D85191

Files:
  clang/lib/AST/RecordLayoutBuilder.cpp


Index: clang/lib/AST/RecordLayoutBuilder.cpp
===
--- clang/lib/AST/RecordLayoutBuilder.cpp
+++ clang/lib/AST/RecordLayoutBuilder.cpp
@@ -1838,14 +1838,13 @@
   CharUnits EffectiveFieldSize;
 
   auto setDeclInfo = [&](bool IsIncompleteArrayType) {
-TypeInfo TI = Context.getTypeInfo(D->getType());
-FieldAlign = Context.toCharUnitsFromBits(TI.Align);
+auto TI = Context.getTypeInfoInChars(D->getType());
+FieldAlign = TI.second;
 // Flexible array members don't have any size, but they have to be
 // aligned appropriately for their element type.
 EffectiveFieldSize = FieldSize =
-IsIncompleteArrayType ? CharUnits::Zero()
-  : Context.toCharUnitsFromBits(TI.Width);
-AlignIsRequired = TI.AlignIsRequired;
+IsIncompleteArrayType ? CharUnits::Zero() : TI.first;
+AlignIsRequired = Context.getTypeInfo(D->getType()).AlignIsRequired;
   };
 
   if (D->getType()->isIncompleteArrayType()) {


Index: clang/lib/AST/RecordLayoutBuilder.cpp
===
--- clang/lib/AST/RecordLayoutBuilder.cpp
+++ clang/lib/AST/RecordLayoutBuilder.cpp
@@ -1838,14 +1838,13 @@
   CharUnits EffectiveFieldSize;
 
   auto setDeclInfo = [&](bool IsIncompleteArrayType) {
-TypeInfo TI = Context.getTypeInfo(D->getType());
-FieldAlign = Context.toCharUnitsFromBits(TI.Align);
+auto TI = Context.getTypeInfoInChars(D->getType());
+FieldAlign = TI.second;
 // Flexible array members don't have any size, but they have to be
 // aligned appropriately for their element type.
 EffectiveFieldSize = FieldSize =
-IsIncompleteArrayType ? CharUnits::Zero()
-  : Context.toCharUnitsFromBits(TI.Width);
-AlignIsRequired = TI.AlignIsRequired;
+IsIncompleteArrayType ? CharUnits::Zero() : TI.first;
+AlignIsRequired = Context.getTypeInfo(D->getType()).AlignIsRequired;
   };
 
   if (D->getType()->isIncompleteArrayType()) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D79719: [AIX] Implement AIX special alignment rule about double/long double

[Bevin Hansson via Phabricator via cfe-commits]

ebevhan added a comment.

I submitted a patch with the changes at D85191 
.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79719

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

[PATCH] D85128: [Prototype][SVE] Support arm_sve_vector_bits attribute

[Cullen Rhodes via Phabricator via cfe-commits]

c-rhodes added a comment.

In D85128#2192867 , @c-rhodes wrote:

> In D85128#2191108 , @tschuett wrote:
>
>> - Is it compatible with GCC?
>
> Support for this attribute landed in GCC 10 and it's more complete than what 
> this patch implements. We've yet to implement the behaviour guarded by the 
> `__ARM_FEATURE_SVE_VECTOR_OPERATORS` and 
> `__ARM_FEATURE_SVE_PREDICATE_OPERATORS` feature macros, so the GNU 
> `__attribute__((vector_size))` extension is not available and operators such 
> as binary '+' are not supported for VLSTs. Support for this is intended to be 
> addressed by later patches.

Just to clarify, GCC doesn't have support for vectors of booleans or operations 
on them (`__ARM_FEATURE_SVE_PREDICATE_OPERATORS`) yet either but does support 
the behaviour indicated by the other macro.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85128

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

[PATCH] D80791: [AArch64] Generate .note.gnu.property based on module flags.

[Momchil Velikov via Phabricator via cfe-commits]

chill added a comment.

In D80791#2164543 , @danielkiss wrote:

>> If any function has the attribute "sign-return-address", then the output note
>> section should have PAC bit set. The return address signing is completely 
>> local
>> to the function, and functions with or without return address signing can be
>> freely mixed with each other.
>
> That is true PAC and non-PAC functions can be mixed. 
> Does one function makes the "all executable sections" pac-ret enabled?

Yes, the presence of even a single function is a clear indication of what the 
user whats - enable PAC/BTI.
The default is not having PAC/BTI code gen, therefore its presence is a result 
of a deliberate action by the user, 
therefore unambiguously conveys the user's intent.

> BTW `GNU_PROPERTY_AARCH64_FEATURE_1_PAC` is not really used for anything.

I may not be used today in GNU/Linux, but still, it has to have sensible 
semantics.

> One of the reasons of the introduction of these macros is the management of 
> the function attributes.
> For example:
>
>   #ifdef __ARM_FEATURE_PAC_DEFAULT
>   #ifdef __ARM_FEATURE_BTI_DEFAULT
>   #define NO_PAC_FUNC __attribute__((target("branch-protection=bti")))
>   #else
>   #define NO_PAC_FUNC __attribute__((target("branch-protection=none")))
>   #endif /* __ARM_FEATURE_BTI_DEFAULT */
>   ...

I don't see how this example is relevant to the discussion of what notes to 
emit.
Our starting point is we have some default state (in module flags or whatever), 
some
individual function state and we have to decide what notes to emit, 
//regardless of the specific way
we came up with those function attributes.//

> In my humble opinion the function attribute is there to alter global setting.
> I considered to propagate the function attribute to the module flags but 
> that would lead to inconsistent compilation with the macros that I'd avoid.

The compilation of a single given function does not necessarily need to be
consistent with the value of these macros. Quite the opposite really, the 
macros themselves are
suffixed by `_DEFAULT` in order to explicitly acknowledge that possibility.

>> What do to if there are no functions in the compile unit?
>>
>> Technically, objects produced from such a unit are fully compatible with 
>> both PAC and BTI, which
>> means both flags should be set. But looking at the (non-existent) function 
>> attributes alone does
>> not allow us to unambiguously derive a user's intent to use PAC/BTI. In this 
>> case, I would suggest
>> setting the ELF note flags, according to the LLVM IR module flags.
>
> I think the only clear indication from the user to use PAC/BTI is the 
> explicit use of `-mbranch-protection=...` command-line option.

Using the attribute is no less clear and even carries more weight, as it 
overrides the command line option.

> A few function attributes that would turn PAC/BTI on just on those few 
> functions makes no sense for me in any real world application.

Turning on/off PAC/BTI is completely symmetrical - one can achieve exactly the 
same effect with:

- command-line options enabling PAC/BTI and individual attributes disabling BTI
- command-line options disabling PAC/BIT (e.g. not having a command-line option 
at all) and individual attributes enabling it

We shouldn't be guessing and prescribing how applications should use the 
mechanisms we make available and certainly
shouldn't be judging what is a real-world application and what is not.

> Valid to turn off PAC/BTI on selected functions while the whole application 
> compiled with them.
>
> We need to turn PAC off on the code path where we change\manage the keys for 
> example.
> Exaggerated example for BTI: https://godbolt.org/z/Y9bhe9  Current version of 
> llvm issues a warning and won't emit the note while I think it should.

Just as valid is to turn on PAC/BTI on selected functions, while the while 
compilation unit (*not* application) is compiled without them.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80791

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

[PATCH] D75181: [AArch64] Handle BTI/PAC in case of generated functions.

[Momchil Velikov via Phabricator via cfe-commits]

chill added a comment.

This approach looks way too hackish to me with multiple opposing attributes 
("sign-return-address" vs. "ignore-sign-return-address")
and some convoluted logic to resolve the contradiction.


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

https://reviews.llvm.org/D75181

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

[PATCH] D85118: [clang][AArch64] Correct return type of Neon vqmovun intrinsics

[David Spickett via Phabricator via cfe-commits]

DavidSpickett added a comment.

I was surprised too. Perhaps there is a way to write the test file such that 
any type mismatch is a warning and compile with -Werror (maybe a new file, the 
IR might get messy). I will spend some time looking into this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85118

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

[PATCH] D85193: [clang] Do not use an invalid expression to update the initializer.

[Aleksandr Platonov via Phabricator via cfe-commits]

ArcsinX created this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
ArcsinX requested review of this revision.

This patch prevents `InitListChecker::UpdateStructuredListElement()` call with 
`expr == nullptr` which could cause a crash.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D85193

Files:
  clang/lib/Sema/SemaInit.cpp
  clang/test/Sema/init-invalid-struct-array.c


Index: clang/test/Sema/init-invalid-struct-array.c
===
--- /dev/null
+++ clang/test/Sema/init-invalid-struct-array.c
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 %s -verify -fsyntax-only
+
+struct S {
+  Unknown u; // expected-error {{unknown type name 'Unknown'}}
+  int i;
+};
+// Should not crash
+struct S s[] = {
+  [0].i = 0,
+  [1].i = 1,
+  {  }
+};
Index: clang/lib/Sema/SemaInit.cpp
===
--- clang/lib/Sema/SemaInit.cpp
+++ clang/lib/Sema/SemaInit.cpp
@@ -1378,9 +1378,9 @@
 ExprResult Result = Seq.Perform(SemaRef, TmpEntity, Kind, expr);
 if (Result.isInvalid())
   hadError = true;
-
-UpdateStructuredListElement(StructuredList, StructuredIndex,
-Result.getAs());
+else
+  UpdateStructuredListElement(StructuredList, StructuredIndex,
+  Result.getAs());
   } else if (!Seq) {
 hadError = true;
   } else if (StructuredList) {
@@ -1436,8 +1436,9 @@
 if (ExprRes.isInvalid())
   hadError = true;
   }
-  UpdateStructuredListElement(StructuredList, StructuredIndex,
-  ExprRes.getAs());
+  if (!hadError)
+UpdateStructuredListElement(StructuredList, StructuredIndex,
+ExprRes.getAs());
   ++Index;
   return;
 }


Index: clang/test/Sema/init-invalid-struct-array.c
===
--- /dev/null
+++ clang/test/Sema/init-invalid-struct-array.c
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 %s -verify -fsyntax-only
+
+struct S {
+  Unknown u; // expected-error {{unknown type name 'Unknown'}}
+  int i;
+};
+// Should not crash
+struct S s[] = {
+  [0].i = 0,
+  [1].i = 1,
+  {  }
+};
Index: clang/lib/Sema/SemaInit.cpp
===
--- clang/lib/Sema/SemaInit.cpp
+++ clang/lib/Sema/SemaInit.cpp
@@ -1378,9 +1378,9 @@
 ExprResult Result = Seq.Perform(SemaRef, TmpEntity, Kind, expr);
 if (Result.isInvalid())
   hadError = true;
-
-UpdateStructuredListElement(StructuredList, StructuredIndex,
-Result.getAs());
+else
+  UpdateStructuredListElement(StructuredList, StructuredIndex,
+  Result.getAs());
   } else if (!Seq) {
 hadError = true;
   } else if (StructuredList) {
@@ -1436,8 +1436,9 @@
 if (ExprRes.isInvalid())
   hadError = true;
   }
-  UpdateStructuredListElement(StructuredList, StructuredIndex,
-  ExprRes.getAs());
+  if (!hadError)
+UpdateStructuredListElement(StructuredList, StructuredIndex,
+ExprRes.getAs());
   ++Index;
   return;
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D77229: [Analyzer] Avoid handling of LazyCompundVals in IteratorModeling

[Balogh , Ádám via Phabricator via cfe-commits]

baloghadamsoftware updated this revision to Diff 282876.
baloghadamsoftware added a comment.

`else` branch merged with inner `if`.


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

https://reviews.llvm.org/D77229

Files:
  clang/lib/StaticAnalyzer/Checkers/ContainerModeling.cpp
  clang/lib/StaticAnalyzer/Checkers/InvalidatedIteratorChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/Iterator.cpp
  clang/lib/StaticAnalyzer/Checkers/Iterator.h
  clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
  clang/lib/StaticAnalyzer/Checkers/IteratorRangeChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/MismatchedIteratorChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/STLAlgorithmModeling.cpp

Index: clang/lib/StaticAnalyzer/Checkers/STLAlgorithmModeling.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/STLAlgorithmModeling.cpp
+++ clang/lib/StaticAnalyzer/Checkers/STLAlgorithmModeling.cpp
@@ -24,12 +24,12 @@
 namespace {
 
 class STLAlgorithmModeling : public Checker {
-  bool evalFind(CheckerContext &C, const CallExpr *CE) const;
+  void evalFind(CheckerContext &C, const CallExpr *CE, SVal Begin,
+SVal End) const;
 
-  void Find(CheckerContext &C, const CallExpr *CE, unsigned paramNum) const;
-
-  using FnCheck = bool (STLAlgorithmModeling::*)(CheckerContext &,
-const CallExpr *) const;
+  using FnCheck = void (STLAlgorithmModeling::*)(CheckerContext &,
+ const CallExpr *, SVal Begin,
+ SVal End) const;
 
   const CallDescriptionMap Callbacks = {
 {{{"std", "find"}, 3}, &STLAlgorithmModeling::evalFind},
@@ -67,51 +67,53 @@
 
 bool STLAlgorithmModeling::evalCall(const CallEvent &Call,
 CheckerContext &C) const {
-  const auto *CE = dyn_cast_or_null(Call.getOriginExpr());
-  if (!CE)
-return false;
-
-  const FnCheck *Handler = Callbacks.lookup(Call);
-  if (!Handler)
-return false;
-
-  return (this->**Handler)(C, CE);
-}
-
-bool STLAlgorithmModeling::evalFind(CheckerContext &C,
-const CallExpr *CE) const {
   // std::find()-like functions either take their primary range in the first
   // two parameters, or if the first parameter is "execution policy" then in
   // the second and third. This means that the second parameter must always be
   // an iterator.
-  if (!isIteratorType(CE->getArg(1)->getType()))
+  if (Call.getNumArgs() < 2 || !isIteratorType(Call.getArgExpr(1)->getType()))
 return false;
 
+  unsigned ArgNum = 999;
+
   // If no "execution policy" parameter is used then the first argument is the
   // beginning of the range.
-  if (isIteratorType(CE->getArg(0)->getType())) {
-Find(C, CE, 0);
-return true;
+  if (isIteratorType(Call.getArgExpr(0)->getType())) {
+ArgNum = 0;
   }
 
   // If "execution policy" parameter is used then the second argument is the
   // beginning of the range.
-  if (isIteratorType(CE->getArg(2)->getType())) {
-Find(C, CE, 1);
-return true;
+  if (ArgNum > 0 &&
+  Call.getNumArgs() > 2 && isIteratorType(Call.getArgExpr(2)->getType())) {
+ArgNum = 1;
   }
 
-  return false;
+  if (ArgNum == 999)
+return false;
+
+  SVal ArgB = getIteratorArg(Call, ArgNum, C.blockCount());
+  SVal ArgE = getIteratorArg(Call, ArgNum + 1, C.blockCount());
+
+  const auto *CE = dyn_cast_or_null(Call.getOriginExpr());
+  if (!CE)
+return false;
+
+  const FnCheck *Handler = Callbacks.lookup(Call);
+  if (!Handler)
+return false;
+
+  (this->**Handler)(C, CE, ArgB, ArgE);
+  return true;
 }
 
-void STLAlgorithmModeling::Find(CheckerContext &C, const CallExpr *CE,
-unsigned paramNum) const {
+void STLAlgorithmModeling::evalFind(CheckerContext &C, const CallExpr *CE,
+SVal Begin, SVal End) const {
   auto State = C.getState();
   auto &SVB = C.getSValBuilder();
   const auto *LCtx = C.getLocationContext();
 
   SVal RetVal = SVB.conjureSymbolVal(nullptr, CE, LCtx, C.blockCount());
-  SVal Param = State->getSVal(CE->getArg(paramNum), LCtx);
 
   auto StateFound = State->BindExpr(CE, LCtx, RetVal);
 
@@ -119,7 +121,7 @@
   // assume that in case of successful search the position of the found element
   // is not ahead of it.
   // FIXME: Reverse iterators
-  const auto *Pos = getIteratorPosition(State, Param);
+  const auto *Pos = getIteratorPosition(State, Begin);
   if (Pos) {
 StateFound = createIteratorPosition(StateFound, RetVal, Pos->getContainer(),
 CE, LCtx, C.blockCount());
@@ -135,13 +137,11 @@
 StateFound = StateFound->assume(GreaterOrEqual.castAs(), true);
   }
 
-  Param = State->getSVal(CE->getArg(paramNum + 1), LCtx);
-
   // If we have an iterator position for the range-end argument then we can
   // assume that in case 

[PATCH] D81083: [Clang] Allow "vector_size" applied to Booleans

[Simon Moll via Phabricator via cfe-commits]

simoll added inline comments.



Comment at: clang/docs/LanguageExtensions.rst:473
+architectures.  The size parameter of a boolean vector type is the number of
+bits in the vector (for all non-bool vectors, the number refers to the number
+of bytes in the vector).

rsandifo-arm wrote:
> simoll wrote:
> > lenary wrote:
> > > It would be nice if this aside about non-bool vectors was more 
> > > prominently displayed - it's something I hadn't realised before.
> > Yep. that caught me by surprise too. I'll move that sentence to the 
> > paragraph about GCC vectors above.
> Sorry for the extremely late comment.  Like @lenary I hadn't thought about 
> this.  I'd assumed that the vector woiuld still be a multiple of 8 bits in 
> size, but I agree that's probably too restrictive to be the only option 
> available.
> 
> In that case, would it make sense to add a separate attribute instead?  I 
> think it's too surprising to change the units of the existing attribute based 
> on the element type.  Perhaps we should even make it take two parameters: the 
> total number of elements, and the number of bits per element.  That might be 
> more natural for some AVX and SVE combinations.  We wouldn't need to supporrt 
> all combinations from the outset, it's just a question whether we should make 
> the syntax general enough to support it in future.
> 
> Perhaps we could do both: support `vector_size` for `bool` using byte sizes 
> (and not allowing subbyte vector lengths), and add a new, more general 
> attribute that allows subbyte lengths and explicit subbyte element sizes.
> In that case, would it make sense to add a separate attribute instead? I 
> think it's too surprising to change the units of the existing attribute based 
> on the element type. Perhaps we should even make it take two parameters: the 
> total number of elements, and the number of bits per element. That might be 
> more natural for some AVX and SVE combinations. We wouldn't need to supporrt 
> all combinations from the outset, it's just a question whether we should make 
> the syntax general enough to support it in future.

I guess adding a new attribute makes sense mid to long term. For now, i'd want 
something that just does the job... ie, what is proposed here. We should 
absolutely document the semantics of vector_size properly.. it already is 
counterintuitive (broken, if you ask me).


> Perhaps we could do both: support vector_size for bool using byte sizes (and 
> not allowing subbyte vector lengths), and add a new, more general attribute 
> that allows subbyte lengths and explicit subbyte element sizes.

Disallowing subbyte bool vectors actually makes this more complicated because 
these types are produced implicitly by compares of (legal) vector types. 
Consider this:

  typedef int int3 __attribute__((vector_size(3 * sizeof(int;
  int3 A = ...;
  int3 B = ...;
  auto Z = A < B; // vector compare yielding a `bool vector_size(3)`-typed 
value.


Regarding your proposal for a separate subbyte element size and subbyte length, 
that may or may not make sense but it is surely something that should be 
discussed more broadly with its own proposal.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81083

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

[PATCH] D77062: [analyzer] Improve zero assumption in CStringChecke::assumeZero

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov added a comment.
Herald added a subscriber: steakhal.

Ping!




Comment at: clang/lib/StaticAnalyzer/Checkers/CStringChecker.cpp:199
   // Utility methods
-  std::pair
-  static assumeZero(CheckerContext &C,
-ProgramStateRef state, SVal V, QualType Ty);
+  std::pair static assumeZero(
+  ProgramStateRef state, SVal V);

vsavchenko wrote:
> Can you please put `static` before return type, it will be more consistent 
> with other static methods nearby.
Sure, I just didn't pay attention to that.


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

https://reviews.llvm.org/D77062

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

[PATCH] D81923: [clang-tidy] Add modernize-use-ranges check.

[Nathan James via Phabricator via cfe-commits]

njames93 updated this revision to Diff 282890.
njames93 added a comment.

rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81923

Files:
  clang-tools-extra/clang-tidy/modernize/CMakeLists.txt
  clang-tools-extra/clang-tidy/modernize/ModernizeTidyModule.cpp
  clang-tools-extra/clang-tidy/modernize/UseRangesCheck.cpp
  clang-tools-extra/clang-tidy/modernize/UseRangesCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-use-ranges.rst
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/modernize-use-ranges/algorithm
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/modernize-use-ranges/execution
  clang-tools-extra/test/clang-tidy/checkers/Inputs/modernize-use-ranges/vector
  clang-tools-extra/test/clang-tidy/checkers/modernize-use-ranges.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/modernize-use-ranges.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/modernize-use-ranges.cpp
@@ -0,0 +1,135 @@
+// RUN: %check_clang_tidy -std=c++20 %s modernize-use-ranges %t -- --config="{CheckOptions: [ \
+// RUN: {key: modernize-use-ranges.HandleReverseRanges, value: true}]}" \
+// RUN: -- -isystem %S/Inputs/modernize-use-ranges
+
+// Ensure no warnings are generated when not in c++20 mode
+// RUN: clang-tidy %s -checks=-*,modernize-use-ranges --warnings-as-errors=modernize-use-ranges -- -nostdinc++ -std=c++17 -isystem %S/Inputs/modernize-use-ranges
+
+#include 
+#include 
+#include 
+// CHECK-FIXES: #include 
+
+template 
+class smart_pointer {
+public:
+  T &operator*();
+  T *operator->();
+};
+
+void goodBeginEndCalls(const std::vector &Vec) {
+  std::find(Vec.begin(), Vec.end(), 1);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: replace find with std::ranges::find
+  std::find(Vec.cbegin(), Vec.cend(), 1);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: replace find with std::ranges::find
+  std::find(std::begin(Vec), std::end(Vec), 1);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: replace find with std::ranges::find
+  std::find(std::cbegin(Vec), std::cend(Vec), 1);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: replace find with std::ranges::find
+  std::find(std::execution::parallel_policy(), Vec.begin(), Vec.end(), 1);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: replace find with std::ranges::find
+
+  // CHECK-FIXES:  std::ranges::find(Vec, 1);
+  // CHECK-FIXES-NEXT: //
+  // CHECK-FIXES-NEXT: std::ranges::find(Vec, 1);
+  // CHECK-FIXES-NEXT: //
+  // CHECK-FIXES-NEXT: std::ranges::find(Vec, 1);
+  // CHECK-FIXES-NEXT: //
+  // CHECK-FIXES-NEXT: std::ranges::find(Vec, 1);
+  // CHECK-FIXES-NEXT: //
+  // CHECK-FIXES-NEXT: std::ranges::find(std::execution::parallel_policy(), Vec, 1);
+  // CHECK-FIXES-NEXT: //
+}
+
+void badBeginEndCalls(const std::vector &Vec,
+  const std::vector &Vec2) {
+  // end, begin.
+  std::find(Vec.end(), Vec.begin(), 1);
+  std::find(Vec.cend(), Vec.cbegin(), 1);
+  std::find(std::end(Vec), std::begin(Vec), 1);
+  std::find(std::cend(Vec), std::cbegin(Vec), 1);
+
+  // begin, begin.
+  std::find(Vec.begin(), Vec.begin(), 1);
+  // end, end.
+  std::find(Vec.end(), Vec.end(), 1);
+
+  // Different containers, definitely bad, but not what this check is for.
+  std::find(Vec.begin(), Vec2.end(), 1);
+}
+
+void maybeDualArg(const std::vector &Vec1, std::vector &Vec2) {
+  std::equal(Vec1.begin(), Vec1.end(), Vec2.begin());
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: replace equal with std::ranges::equal
+  std::equal(Vec1.begin(), Vec1.end(), Vec2.begin(), Vec2.end());
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: replace equal with std::ranges::equal
+  std::equal(std::execution::sequenced_policy(), Vec1.begin(), Vec1.end(), Vec2.begin());
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: replace equal with std::ranges::equal
+  std::equal(std::execution::unsequenced_policy(), Vec1.begin(), Vec1.end(), Vec2.begin(), Vec2.end());
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: replace equal with std::ranges::equal
+
+  // CHECK-FIXES:  std::ranges::equal(Vec1, Vec2.begin());
+  // CHECK-FIXES-NEXT: //
+  // CHECK-FIXES-NEXT: std::ranges::equal(Vec1, Vec2);
+  // CHECK-FIXES-NEXT: //
+  // CHECK-FIXES-NEXT: std::ranges::equal(std::execution::sequenced_policy(), Vec1, Vec2.begin());
+  // CHECK-FIXES-NEXT: //
+  // CHECK-FIXES-NEXT: std::ranges::equal(std::execution::unsequenced_policy(), Vec1, Vec2);
+  // CHECK-FIXES-NEXT: //
+}
+
+void dualArg(const std::vector &Vec1, const std::vector &Vec2) {
+  std::includes(Vec1.begin(), Vec1.end(), Vec2.begin(), Vec2.end());
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: replace includes with std::ranges::includes
+  std::includes(std::execution::parallel_unsequenced_policy(), Vec1.begin(), Vec1.end(), Vec2.begin(), Vec2.end());
+  // 

[PATCH] D81083: [Clang] Allow "vector_size" applied to Booleans

[Richard Sandiford via Phabricator via cfe-commits]

rsandifo-arm added inline comments.



Comment at: clang/docs/LanguageExtensions.rst:473
+architectures.  The size parameter of a boolean vector type is the number of
+bits in the vector (for all non-bool vectors, the number refers to the number
+of bytes in the vector).

simoll wrote:
> rsandifo-arm wrote:
> > simoll wrote:
> > > lenary wrote:
> > > > It would be nice if this aside about non-bool vectors was more 
> > > > prominently displayed - it's something I hadn't realised before.
> > > Yep. that caught me by surprise too. I'll move that sentence to the 
> > > paragraph about GCC vectors above.
> > Sorry for the extremely late comment.  Like @lenary I hadn't thought about 
> > this.  I'd assumed that the vector woiuld still be a multiple of 8 bits in 
> > size, but I agree that's probably too restrictive to be the only option 
> > available.
> > 
> > In that case, would it make sense to add a separate attribute instead?  I 
> > think it's too surprising to change the units of the existing attribute 
> > based on the element type.  Perhaps we should even make it take two 
> > parameters: the total number of elements, and the number of bits per 
> > element.  That might be more natural for some AVX and SVE combinations.  We 
> > wouldn't need to supporrt all combinations from the outset, it's just a 
> > question whether we should make the syntax general enough to support it in 
> > future.
> > 
> > Perhaps we could do both: support `vector_size` for `bool` using byte sizes 
> > (and not allowing subbyte vector lengths), and add a new, more general 
> > attribute that allows subbyte lengths and explicit subbyte element sizes.
> > In that case, would it make sense to add a separate attribute instead? I 
> > think it's too surprising to change the units of the existing attribute 
> > based on the element type. Perhaps we should even make it take two 
> > parameters: the total number of elements, and the number of bits per 
> > element. That might be more natural for some AVX and SVE combinations. We 
> > wouldn't need to supporrt all combinations from the outset, it's just a 
> > question whether we should make the syntax general enough to support it in 
> > future.
> 
> I guess adding a new attribute makes sense mid to long term. For now, i'd 
> want something that just does the job... ie, what is proposed here. We should 
> absolutely document the semantics of vector_size properly.. it already is 
> counterintuitive (broken, if you ask me).
> 
> 
> > Perhaps we could do both: support vector_size for bool using byte sizes 
> > (and not allowing subbyte vector lengths), and add a new, more general 
> > attribute that allows subbyte lengths and explicit subbyte element sizes.
> 
> Disallowing subbyte bool vectors actually makes this more complicated because 
> these types are produced implicitly by compares of (legal) vector types. 
> Consider this:
> 
>   typedef int int3 __attribute__((vector_size(3 * sizeof(int;
>   int3 A = ...;
>   int3 B = ...;
>   auto Z = A < B; // vector compare yielding a `bool vector_size(3)`-typed 
> value.
> 
> 
> Regarding your proposal for a separate subbyte element size and subbyte 
> length, that may or may not make sense but it is surely something that should 
> be discussed more broadly with its own proposal.
> > Perhaps we could do both: support vector_size for bool using byte sizes 
> > (and not allowing subbyte vector lengths), and add a new, more general 
> > attribute that allows subbyte lengths and explicit subbyte element sizes.
> 
> Disallowing subbyte bool vectors actually makes this more complicated because 
> these types are produced implicitly by compares of (legal) vector types. 
> Consider this:
> 
>   typedef int int3 __attribute__((vector_size(3 * sizeof(int;
>   int3 A = ...;
>   int3 B = ...;
>   auto Z = A < B; // vector compare yielding a `bool vector_size(3)`-typed 
> value.

Yeah, I understand the need for some way of creating subbyte vectors.  I'm just 
not sure using the existing `vector_size` attribute would be the best choice 
for that case.  I.e. the objection wasn't based on “keeping things simple” but 
more “keeping things consistent“.

That doesn't mean that the above code should be invalid.  It just means that it 
wouldn't be possible to write the type of Z using the existing `vector_size` 
attribute.

(FWIW, `vector_size` was originally a GNUism and GCC stil requires vector sizes 
to be a power of 2, but I realise that isn't relevant here.  And the same 
principle applies with s/3/4 in the above example anyway.)

> Regarding your proposal for a separate subbyte element size and subbyte 
> length, that may or may not make sense but it is surely something that should 
> be discussed more broadly with its own proposal.

Yeah, I agree any new attribute would need to be discussed more widely.


Repository:
  rG LLVM Github Monorepo

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

https:

[PATCH] D85157: [Sema] Add casting check for fixed to fixed point conversions

[Vince Bridgers via Phabricator via cfe-commits]

vabridgers updated this revision to Diff 282902.
vabridgers edited the summary of this revision.
vabridgers added a comment.

ok, I think it's all sorted out now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85157

Files:
  clang/lib/Sema/SemaCast.cpp
  clang/test/Sema/warn-bad-function-cast.c


Index: clang/test/Sema/warn-bad-function-cast.c
===
--- clang/test/Sema/warn-bad-function-cast.c
+++ clang/test/Sema/warn-bad-function-cast.c
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 %s -fsyntax-only -Wno-unused-value -Wbad-function-cast 
-triple x86_64-unknown-unknown -verify
+// RUN: %clang_cc1 %s -fsyntax-only -Wno-unused-value -Wbad-function-cast 
-ffixed-point -triple x86_64-unknown-unknown -verify
 // rdar://9103192
 
 void vf(void);
@@ -12,6 +12,7 @@
 _Bool bf(void);
 char *pf1(void);
 int *pf2(void);
+_Fract ff1(void);
 
 void
 foo(void)
@@ -43,5 +44,10 @@
   (int)bf(); /* expected-warning {{cast from function call of type '_Bool' to 
non-matching type 'int'}} */
   (__SIZE_TYPE__)pf1(); /* expected-warning {{cast from function call of type 
'char *' to non-matching type 'unsigned long'}} */
   (__PTRDIFF_TYPE__)pf2(); /* expected-warning {{cast from function call of 
type 'int *' to non-matching type 'long'}} */
+
+  (_Fract) if1(); /* expected-warning{{cast from function call of type 'int' 
to non-matching type '_Fract'}} */
+  ff1();  /* no warning */ 
+  (_Fract)ff1();  /* no warning */ 
+  (int)ff1();  /* expected-warning{{cast from function call of type '_Fract' 
to non-matching type 'int'}} */ 
 }
 
Index: clang/lib/Sema/SemaCast.cpp
===
--- clang/lib/Sema/SemaCast.cpp
+++ clang/lib/Sema/SemaCast.cpp
@@ -2657,6 +2657,8 @@
 return;
   if (SrcType->isComplexIntegerType() && DestType->isComplexIntegerType())
 return;
+  if (SrcType->isFixedPointType() && DestType->isFixedPointType())
+return;
 
   Self.Diag(SrcExpr.get()->getExprLoc(),
 diag::warn_bad_function_cast)


Index: clang/test/Sema/warn-bad-function-cast.c
===
--- clang/test/Sema/warn-bad-function-cast.c
+++ clang/test/Sema/warn-bad-function-cast.c
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 %s -fsyntax-only -Wno-unused-value -Wbad-function-cast -triple x86_64-unknown-unknown -verify
+// RUN: %clang_cc1 %s -fsyntax-only -Wno-unused-value -Wbad-function-cast -ffixed-point -triple x86_64-unknown-unknown -verify
 // rdar://9103192
 
 void vf(void);
@@ -12,6 +12,7 @@
 _Bool bf(void);
 char *pf1(void);
 int *pf2(void);
+_Fract ff1(void);
 
 void
 foo(void)
@@ -43,5 +44,10 @@
   (int)bf(); /* expected-warning {{cast from function call of type '_Bool' to non-matching type 'int'}} */
   (__SIZE_TYPE__)pf1(); /* expected-warning {{cast from function call of type 'char *' to non-matching type 'unsigned long'}} */
   (__PTRDIFF_TYPE__)pf2(); /* expected-warning {{cast from function call of type 'int *' to non-matching type 'long'}} */
+
+  (_Fract) if1(); /* expected-warning{{cast from function call of type 'int' to non-matching type '_Fract'}} */
+  ff1();  /* no warning */ 
+  (_Fract)ff1();  /* no warning */ 
+  (int)ff1();  /* expected-warning{{cast from function call of type '_Fract' to non-matching type 'int'}} */ 
 }
 
Index: clang/lib/Sema/SemaCast.cpp
===
--- clang/lib/Sema/SemaCast.cpp
+++ clang/lib/Sema/SemaCast.cpp
@@ -2657,6 +2657,8 @@
 return;
   if (SrcType->isComplexIntegerType() && DestType->isComplexIntegerType())
 return;
+  if (SrcType->isFixedPointType() && DestType->isFixedPointType())
+return;
 
   Self.Diag(SrcExpr.get()->getExprLoc(),
 diag::warn_bad_function_cast)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D85128: [Prototype][SVE] Support arm_sve_vector_bits attribute

[Thorsten via Phabricator via cfe-commits]

tschuett added a comment.

Sorry. I meant ABI. Can link GCC .o files with Clang .o files using the 
attributes?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85128

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

[PATCH] D85157: [Sema] Add casting check for fixed to fixed point conversions

[Vince Bridgers via Phabricator via cfe-commits]

vabridgers added a subscriber: bevinh.
vabridgers added a comment.

ok, I think it's all sorted out now. Thanks @bevinh for the desk review. Let's 
start at the beginning again :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85157

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

[PATCH] D76590: [Analyzer] Model `empty()` member function of containers

[Balogh , Ádám via Phabricator via cfe-commits]

baloghadamsoftware marked 2 inline comments as done.
baloghadamsoftware added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/ContainerModeling.cpp:56
+SVal RetVal) const;
+  void handleErase(CheckerContext &C, const Expr *CE, SVal Cont, SVal Iter,
+   SVal RetVal) const;

martong wrote:
> I understand that the container SVal is no longer `const`, but why did the 
> iterator loose its constness?
We passed it earlier as a constant reference, but `SVal` is small, it should be 
passed by value.



Comment at: clang/lib/StaticAnalyzer/Checkers/ContainerModeling.cpp:277
 void ContainerModeling::handleBegin(CheckerContext &C, const Expr *CE,
-   const SVal &RetVal, const SVal &Cont) const 
{
+   SVal RetVal, SVal Cont) const {
   const auto *ContReg = Cont.getAsRegion();

martong wrote:
> Why do we skip the `const` qualifiers here?
Do you mean for `SVal`? See above.



Comment at: clang/lib/StaticAnalyzer/Checkers/ContainerModeling.cpp:436
+if (!StateEmpty && !StateNonEmpty) {
+  C.generateSink(State, C.getPredecessor());
+  return;

martong wrote:
> Is there really no sense to continue the analysis here? In what state we are 
> here exactly? Is there an inconsistency between the `begin` , `end` and the 
> return value?
Yes, see the comment I added. If data about emptiness based on the difference 
of begin and and and the return value of `empty()` contradict each other then 
we are on an impossible branch.



Comment at: clang/lib/StaticAnalyzer/Checkers/Iterator.cpp:19
 
+ProgramStateRef relateSymbols(ProgramStateRef State, SymbolRef Sym1,
+  SymbolRef Sym2, bool Equal);

martong wrote:
> Docs, docs, docs.
This function is moved here, it is nothing new.



Comment at: clang/lib/StaticAnalyzer/Checkers/Iterator.cpp:274
+assumeComparison(ProgramStateRef State, SymbolRef Sym1, SymbolRef Sym2,
+ DefinedSVal RetVal, OverloadedOperatorKind Op) {
+  if (const auto TruthVal = RetVal.getAs()) {

martong wrote:
> Perhaps we should guard `Op` with an assert, I mean it should be either == or 
> !=.
Actually, this works for any comparison operator. So it is enough to assume 
that `Op` is a comparison operator.



Comment at: clang/lib/StaticAnalyzer/Checkers/Iterator.cpp:290
+  if (StateTrue)
+StateTrue = StateTrue->assume(RetVal, true);
+  if (StateFalse)

martong wrote:
> Why do we `assume` here again? We already had an assume in `relateSymbols`, 
> hadn't we?
In `relateSymbols` we assumed the comparison of the two symbols. Here we assume 
the `RetVal`. The new states are `nullptr` if we cannot assume the same for 
both.



Comment at: clang/lib/StaticAnalyzer/Checkers/Iterator.cpp:297
+
+ProgramStateRef relateSymbols(ProgramStateRef State, SymbolRef Sym1,
+  SymbolRef Sym2, bool Equal) {

martong wrote:
> Would `assumeEqual` be a better name?
This method is just moved from another source file.



Comment at: clang/lib/StaticAnalyzer/Checkers/Iterator.cpp:301
+
+  // FIXME: This code should be reworked as follows:
+  // 1. Subtract the operands using evalBinOp().

martong wrote:
> Please explain in the comment what is the problem with the current impl.
Ditto. The community requested a future refactoring.



Comment at: clang/lib/StaticAnalyzer/Checkers/Iterator.cpp:313-314
+
+  auto NewState = State->assume(comparison.castAs(), Equal);
+  if (!NewState)
+return nullptr;

martong wrote:
> Could we merge the declaration of the new state into the parens of the `if`?
No, because we use it later in the function. (See below.)



Comment at: clang/test/Analysis/container-modeling.cpp:19
 
+extern void __assert_fail (__const char *__assertion, __const char *__file,
+unsigned int __line, __const char *__function)

martong wrote:
> It seems like we don't use it anywhere.
We use this in the definition of the `assert()` macro. And we use that macro in 
the new test cases.


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

https://reviews.llvm.org/D76590

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

[PATCH] D85124: [Concepts] Include the found concept decl when dumping the ConceptSpecializationExpr

[Haojian Wu via Phabricator via cfe-commits]

hokein updated this revision to Diff 282906.
hokein marked an inline comment as done.
hokein added a comment.

address comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85124

Files:
  clang/include/clang/AST/TextNodeDumper.h
  clang/lib/AST/TextNodeDumper.cpp
  clang/test/AST/ast-dump-concepts.cpp


Index: clang/test/AST/ast-dump-concepts.cpp
===
--- clang/test/AST/ast-dump-concepts.cpp
+++ clang/test/AST/ast-dump-concepts.cpp
@@ -15,7 +15,7 @@
 template 
 struct Foo {
   // CHECK:  TemplateTypeParmDecl {{.*}} referenced Concept {{.*}} 
'binary_concept'
-  // CHECK-NEXT: |-ConceptSpecializationExpr {{.*}}  'bool'
+  // CHECK-NEXT: |-ConceptSpecializationExpr {{.*}}  'bool' 
Concept {{.*}} 'binary_concept'
   // CHECK-NEXT: `-TemplateArgument {{.*}} type 'int'
   template  R>
   Foo(R);
Index: clang/lib/AST/TextNodeDumper.cpp
===
--- clang/lib/AST/TextNodeDumper.cpp
+++ clang/lib/AST/TextNodeDumper.cpp
@@ -1340,6 +1340,12 @@
   }
 }
 
+void TextNodeDumper::VisitConceptSpecializationExpr(
+const ConceptSpecializationExpr *Node) {
+  OS << " ";
+  dumpBareDeclRef(Node->getFoundDecl());
+}
+
 void TextNodeDumper::VisitRValueReferenceType(const ReferenceType *T) {
   if (T->isSpelledAsLValue())
 OS << " written as lvalue reference";
Index: clang/include/clang/AST/TextNodeDumper.h
===
--- clang/include/clang/AST/TextNodeDumper.h
+++ clang/include/clang/AST/TextNodeDumper.h
@@ -295,6 +295,7 @@
   void VisitObjCIvarRefExpr(const ObjCIvarRefExpr *Node);
   void VisitObjCBoolLiteralExpr(const ObjCBoolLiteralExpr *Node);
   void VisitOMPIteratorExpr(const OMPIteratorExpr *Node);
+  void VisitConceptSpecializationExpr(const ConceptSpecializationExpr *Node);
 
   void VisitRValueReferenceType(const ReferenceType *T);
   void VisitArrayType(const ArrayType *T);


Index: clang/test/AST/ast-dump-concepts.cpp
===
--- clang/test/AST/ast-dump-concepts.cpp
+++ clang/test/AST/ast-dump-concepts.cpp
@@ -15,7 +15,7 @@
 template 
 struct Foo {
   // CHECK:  TemplateTypeParmDecl {{.*}} referenced Concept {{.*}} 'binary_concept'
-  // CHECK-NEXT: |-ConceptSpecializationExpr {{.*}}  'bool'
+  // CHECK-NEXT: |-ConceptSpecializationExpr {{.*}}  'bool' Concept {{.*}} 'binary_concept'
   // CHECK-NEXT: `-TemplateArgument {{.*}} type 'int'
   template  R>
   Foo(R);
Index: clang/lib/AST/TextNodeDumper.cpp
===
--- clang/lib/AST/TextNodeDumper.cpp
+++ clang/lib/AST/TextNodeDumper.cpp
@@ -1340,6 +1340,12 @@
   }
 }
 
+void TextNodeDumper::VisitConceptSpecializationExpr(
+const ConceptSpecializationExpr *Node) {
+  OS << " ";
+  dumpBareDeclRef(Node->getFoundDecl());
+}
+
 void TextNodeDumper::VisitRValueReferenceType(const ReferenceType *T) {
   if (T->isSpelledAsLValue())
 OS << " written as lvalue reference";
Index: clang/include/clang/AST/TextNodeDumper.h
===
--- clang/include/clang/AST/TextNodeDumper.h
+++ clang/include/clang/AST/TextNodeDumper.h
@@ -295,6 +295,7 @@
   void VisitObjCIvarRefExpr(const ObjCIvarRefExpr *Node);
   void VisitObjCBoolLiteralExpr(const ObjCBoolLiteralExpr *Node);
   void VisitOMPIteratorExpr(const OMPIteratorExpr *Node);
+  void VisitConceptSpecializationExpr(const ConceptSpecializationExpr *Node);
 
   void VisitRValueReferenceType(const ReferenceType *T);
   void VisitArrayType(const ArrayType *T);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 1c0a0df - [Concepts] Include the found concept decl when dumping the ConceptSpecializationExpr

[Haojian Wu via cfe-commits]

Author: Haojian Wu
Date: 2020-08-04T15:58:12+02:00
New Revision: 1c0a0dfa0236514fd1fbb1bccd8ad29f9d64e915

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

LOG: [Concepts] Include the found concept decl when dumping the 
ConceptSpecializationExpr

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

Added: 


Modified: 
clang/include/clang/AST/TextNodeDumper.h
clang/lib/AST/TextNodeDumper.cpp
clang/test/AST/ast-dump-concepts.cpp

Removed: 




diff  --git a/clang/include/clang/AST/TextNodeDumper.h 
b/clang/include/clang/AST/TextNodeDumper.h
index 8e8084aec3c1..f68a5dbfc2a0 100644
--- a/clang/include/clang/AST/TextNodeDumper.h
+++ b/clang/include/clang/AST/TextNodeDumper.h
@@ -295,6 +295,7 @@ class TextNodeDumper
   void VisitObjCIvarRefExpr(const ObjCIvarRefExpr *Node);
   void VisitObjCBoolLiteralExpr(const ObjCBoolLiteralExpr *Node);
   void VisitOMPIteratorExpr(const OMPIteratorExpr *Node);
+  void VisitConceptSpecializationExpr(const ConceptSpecializationExpr *Node);
 
   void VisitRValueReferenceType(const ReferenceType *T);
   void VisitArrayType(const ArrayType *T);

diff  --git a/clang/lib/AST/TextNodeDumper.cpp 
b/clang/lib/AST/TextNodeDumper.cpp
index 5b6c6085e02c..3d47d5cb66d2 100644
--- a/clang/lib/AST/TextNodeDumper.cpp
+++ b/clang/lib/AST/TextNodeDumper.cpp
@@ -1340,6 +1340,12 @@ void TextNodeDumper::VisitOMPIteratorExpr(const 
OMPIteratorExpr *Node) {
   }
 }
 
+void TextNodeDumper::VisitConceptSpecializationExpr(
+const ConceptSpecializationExpr *Node) {
+  OS << " ";
+  dumpBareDeclRef(Node->getFoundDecl());
+}
+
 void TextNodeDumper::VisitRValueReferenceType(const ReferenceType *T) {
   if (T->isSpelledAsLValue())
 OS << " written as lvalue reference";

diff  --git a/clang/test/AST/ast-dump-concepts.cpp 
b/clang/test/AST/ast-dump-concepts.cpp
index 7050ee0fb449..630a953976fc 100644
--- a/clang/test/AST/ast-dump-concepts.cpp
+++ b/clang/test/AST/ast-dump-concepts.cpp
@@ -15,7 +15,7 @@ concept binary_concept = true;
 template 
 struct Foo {
   // CHECK:  TemplateTypeParmDecl {{.*}} referenced Concept {{.*}} 
'binary_concept'
-  // CHECK-NEXT: |-ConceptSpecializationExpr {{.*}}  'bool'
+  // CHECK-NEXT: |-ConceptSpecializationExpr {{.*}}  'bool' 
Concept {{.*}} 'binary_concept'
   // CHECK-NEXT: `-TemplateArgument {{.*}} type 'int'
   template  R>
   Foo(R);



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

[PATCH] D85124: [Concepts] Include the found concept decl when dumping the ConceptSpecializationExpr

[Haojian Wu via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG1c0a0dfa0236: [Concepts] Include the found concept decl when 
dumping the… (authored by hokein).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85124

Files:
  clang/include/clang/AST/TextNodeDumper.h
  clang/lib/AST/TextNodeDumper.cpp
  clang/test/AST/ast-dump-concepts.cpp


Index: clang/test/AST/ast-dump-concepts.cpp
===
--- clang/test/AST/ast-dump-concepts.cpp
+++ clang/test/AST/ast-dump-concepts.cpp
@@ -15,7 +15,7 @@
 template 
 struct Foo {
   // CHECK:  TemplateTypeParmDecl {{.*}} referenced Concept {{.*}} 
'binary_concept'
-  // CHECK-NEXT: |-ConceptSpecializationExpr {{.*}}  'bool'
+  // CHECK-NEXT: |-ConceptSpecializationExpr {{.*}}  'bool' 
Concept {{.*}} 'binary_concept'
   // CHECK-NEXT: `-TemplateArgument {{.*}} type 'int'
   template  R>
   Foo(R);
Index: clang/lib/AST/TextNodeDumper.cpp
===
--- clang/lib/AST/TextNodeDumper.cpp
+++ clang/lib/AST/TextNodeDumper.cpp
@@ -1340,6 +1340,12 @@
   }
 }
 
+void TextNodeDumper::VisitConceptSpecializationExpr(
+const ConceptSpecializationExpr *Node) {
+  OS << " ";
+  dumpBareDeclRef(Node->getFoundDecl());
+}
+
 void TextNodeDumper::VisitRValueReferenceType(const ReferenceType *T) {
   if (T->isSpelledAsLValue())
 OS << " written as lvalue reference";
Index: clang/include/clang/AST/TextNodeDumper.h
===
--- clang/include/clang/AST/TextNodeDumper.h
+++ clang/include/clang/AST/TextNodeDumper.h
@@ -295,6 +295,7 @@
   void VisitObjCIvarRefExpr(const ObjCIvarRefExpr *Node);
   void VisitObjCBoolLiteralExpr(const ObjCBoolLiteralExpr *Node);
   void VisitOMPIteratorExpr(const OMPIteratorExpr *Node);
+  void VisitConceptSpecializationExpr(const ConceptSpecializationExpr *Node);
 
   void VisitRValueReferenceType(const ReferenceType *T);
   void VisitArrayType(const ArrayType *T);


Index: clang/test/AST/ast-dump-concepts.cpp
===
--- clang/test/AST/ast-dump-concepts.cpp
+++ clang/test/AST/ast-dump-concepts.cpp
@@ -15,7 +15,7 @@
 template 
 struct Foo {
   // CHECK:  TemplateTypeParmDecl {{.*}} referenced Concept {{.*}} 'binary_concept'
-  // CHECK-NEXT: |-ConceptSpecializationExpr {{.*}}  'bool'
+  // CHECK-NEXT: |-ConceptSpecializationExpr {{.*}}  'bool' Concept {{.*}} 'binary_concept'
   // CHECK-NEXT: `-TemplateArgument {{.*}} type 'int'
   template  R>
   Foo(R);
Index: clang/lib/AST/TextNodeDumper.cpp
===
--- clang/lib/AST/TextNodeDumper.cpp
+++ clang/lib/AST/TextNodeDumper.cpp
@@ -1340,6 +1340,12 @@
   }
 }
 
+void TextNodeDumper::VisitConceptSpecializationExpr(
+const ConceptSpecializationExpr *Node) {
+  OS << " ";
+  dumpBareDeclRef(Node->getFoundDecl());
+}
+
 void TextNodeDumper::VisitRValueReferenceType(const ReferenceType *T) {
   if (T->isSpelledAsLValue())
 OS << " written as lvalue reference";
Index: clang/include/clang/AST/TextNodeDumper.h
===
--- clang/include/clang/AST/TextNodeDumper.h
+++ clang/include/clang/AST/TextNodeDumper.h
@@ -295,6 +295,7 @@
   void VisitObjCIvarRefExpr(const ObjCIvarRefExpr *Node);
   void VisitObjCBoolLiteralExpr(const ObjCBoolLiteralExpr *Node);
   void VisitOMPIteratorExpr(const OMPIteratorExpr *Node);
+  void VisitConceptSpecializationExpr(const ConceptSpecializationExpr *Node);
 
   void VisitRValueReferenceType(const ReferenceType *T);
   void VisitArrayType(const ArrayType *T);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 860cbbd - [SyntaxTree] Add support for `LiteralExpression`

[Eduardo Caldas via cfe-commits]

Author: Eduardo Caldas
Date: 2020-08-04T14:05:09Z
New Revision: 860cbbdd6b84017e6d37e1752b0358a05da6b115

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

LOG: [SyntaxTree] Add support for `LiteralExpression`

We use inheritance to model the grammar's disjunction rule:
literal:
  integer-literal
  character-literal
  floating-point-literal
  string-literal
  boolean-literal
  pointer-literal
  user-defined-literal

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

Added: 


Modified: 
clang/include/clang/Tooling/Syntax/Nodes.h
clang/lib/Tooling/Syntax/Nodes.cpp

Removed: 




diff  --git a/clang/include/clang/Tooling/Syntax/Nodes.h 
b/clang/include/clang/Tooling/Syntax/Nodes.h
index d97b127638bb..8a873f9d5273 100644
--- a/clang/include/clang/Tooling/Syntax/Nodes.h
+++ b/clang/include/clang/Tooling/Syntax/Nodes.h
@@ -267,66 +267,82 @@ class ParenExpression final : public Expression {
   syntax::Leaf *closeParen();
 };
 
+/// Expression for literals. C++ [lex.literal]
+class LiteralExpression : public Expression {
+public:
+  LiteralExpression(NodeKind K) : Expression(K) {}
+  static bool classof(const Node *N) {
+return N->kind() == NodeKind::IntegerLiteralExpression ||
+   N->kind() == NodeKind::CharacterLiteralExpression ||
+   N->kind() == NodeKind::FloatingLiteralExpression ||
+   N->kind() == NodeKind::StringLiteralExpression ||
+   N->kind() == NodeKind::BoolLiteralExpression ||
+   N->kind() == NodeKind::CxxNullPtrExpression ||
+   N->kind() == NodeKind::IntegerUserDefinedLiteralExpression ||
+   N->kind() == NodeKind::FloatUserDefinedLiteralExpression ||
+   N->kind() == NodeKind::CharUserDefinedLiteralExpression ||
+   N->kind() == NodeKind::StringUserDefinedLiteralExpression;
+  }
+  syntax::Leaf *literalToken();
+};
+
 /// Expression for integer literals. C++ [lex.icon]
-class IntegerLiteralExpression final : public Expression {
+class IntegerLiteralExpression final : public LiteralExpression {
 public:
-  IntegerLiteralExpression() : Expression(NodeKind::IntegerLiteralExpression) 
{}
+  IntegerLiteralExpression()
+  : LiteralExpression(NodeKind::IntegerLiteralExpression) {}
   static bool classof(const Node *N) {
 return N->kind() == NodeKind::IntegerLiteralExpression;
   }
-  syntax::Leaf *literalToken();
 };
 
 /// Expression for character literals. C++ [lex.ccon]
-class CharacterLiteralExpression final : public Expression {
+class CharacterLiteralExpression final : public LiteralExpression {
 public:
   CharacterLiteralExpression()
-  : Expression(NodeKind::CharacterLiteralExpression) {}
+  : LiteralExpression(NodeKind::CharacterLiteralExpression) {}
   static bool classof(const Node *N) {
 return N->kind() == NodeKind::CharacterLiteralExpression;
   }
-  syntax::Leaf *literalToken();
 };
 
 /// Expression for floating-point literals. C++ [lex.fcon]
-class FloatingLiteralExpression final : public Expression {
+class FloatingLiteralExpression final : public LiteralExpression {
 public:
   FloatingLiteralExpression()
-  : Expression(NodeKind::FloatingLiteralExpression) {}
+  : LiteralExpression(NodeKind::FloatingLiteralExpression) {}
   static bool classof(const Node *N) {
 return N->kind() == NodeKind::FloatingLiteralExpression;
   }
-  syntax::Leaf *literalToken();
 };
 
 /// Expression for string-literals. C++ [lex.string]
-class StringLiteralExpression final : public Expression {
+class StringLiteralExpression final : public LiteralExpression {
 public:
-  StringLiteralExpression() : Expression(NodeKind::StringLiteralExpression) {}
+  StringLiteralExpression()
+  : LiteralExpression(NodeKind::StringLiteralExpression) {}
   static bool classof(const Node *N) {
 return N->kind() == NodeKind::StringLiteralExpression;
   }
-  syntax::Leaf *literalToken();
 };
 
 /// Expression for boolean literals. C++ [lex.bool]
-class BoolLiteralExpression final : public Expression {
+class BoolLiteralExpression final : public LiteralExpression {
 public:
-  BoolLiteralExpression() : Expression(NodeKind::BoolLiteralExpression) {}
+  BoolLiteralExpression()
+  : LiteralExpression(NodeKind::BoolLiteralExpression) {}
   static bool classof(const Node *N) {
 return N->kind() == NodeKind::BoolLiteralExpression;
   }
-  syntax::Leaf *literalToken();
 };
 
 /// Expression for the `nullptr` literal. C++ [lex.nullptr]
-class CxxNullPtrExpression final : public Expression {
+class CxxNullPtrExpression final : public LiteralExpression {
 public:
-  CxxNullPtrExpression() : Expression(NodeKind::CxxNullPtrExpression) {}
+  CxxNullPtrExpression() : LiteralExpression(NodeKind::CxxNullPtrExpression) {}
   static bool classof(const Node *N) {
 return N->kind() =

[PATCH] D76590: [Analyzer] Model `empty()` member function of containers

[Balogh , Ádám via Phabricator via cfe-commits]

baloghadamsoftware updated this revision to Diff 282909.
baloghadamsoftware added a comment.

Updated according to the comments.


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

https://reviews.llvm.org/D76590

Files:
  clang/lib/StaticAnalyzer/Checkers/ContainerModeling.cpp
  clang/lib/StaticAnalyzer/Checkers/Iterator.cpp
  clang/lib/StaticAnalyzer/Checkers/Iterator.h
  clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
  clang/test/Analysis/Inputs/system-header-simulator-cxx.h
  clang/test/Analysis/container-modeling.cpp
  clang/test/Analysis/diagnostics/explicit-suppression.cpp

Index: clang/test/Analysis/diagnostics/explicit-suppression.cpp
===
--- clang/test/Analysis/diagnostics/explicit-suppression.cpp
+++ clang/test/Analysis/diagnostics/explicit-suppression.cpp
@@ -19,6 +19,6 @@
 void testCopyNull(C *I, C *E) {
   std::copy(I, E, (C *)0);
 #ifndef SUPPRESSED
-  // expected-warning@../Inputs/system-header-simulator-cxx.h:699 {{Called C++ object pointer is null}}
+  // expected-warning@../Inputs/system-header-simulator-cxx.h:707 {{Called C++ object pointer is null}}
 #endif
 }
Index: clang/test/Analysis/container-modeling.cpp
===
--- clang/test/Analysis/container-modeling.cpp
+++ clang/test/Analysis/container-modeling.cpp
@@ -16,6 +16,12 @@
 void clang_analyzer_eval(bool);
 void clang_analyzer_warnIfReached();
 
+extern void __assert_fail (__const char *__assertion, __const char *__file,
+unsigned int __line, __const char *__function)
+ __attribute__ ((__noreturn__));
+#define assert(expr) \
+  ((expr)  ? (void)(0)  : __assert_fail (#expr, __FILE__, __LINE__, __func__))
+
 void begin(const std::vector &V) {
   V.begin();
 
@@ -56,6 +62,40 @@
// expected-note@-1{{TRUE}}
 }
 
+
+///
+/// C O N T A I N E R   C A P A C I T Y
+///
+
+
+/// empty()
+
+void empty(const std::vector &V) {
+  for (auto n: V) {}
+  clang_analyzer_eval(clang_analyzer_container_begin(V) ==
+  clang_analyzer_container_end(V));
+  // expected-warning@-2{{TRUE}} expected-warning@-2{{FALSE}}
+  // expected-note@-3   {{TRUE}} expected-note@-3   {{FALSE}}
+}
+
+void non_empty1(const std::vector &V) {
+  assert(!V.empty()); // expected-note{{'?' condition is true}}
+  for (auto n: V) {}
+  clang_analyzer_eval(clang_analyzer_container_begin(V) ==
+  clang_analyzer_container_end(V));
+  // expected-warning@-2{{FALSE}}
+  // expected-note@-3   {{FALSE}}
+}
+
+void non_empty2(const std::vector &V) {
+  for (auto n: V) {}
+  assert(!V.empty()); // expected-note{{'?' condition is true}}
+  clang_analyzer_eval(clang_analyzer_container_begin(V) ==
+  clang_analyzer_container_end(V));
+  // expected-warning@-2{{FALSE}}
+  // expected-note@-3   {{FALSE}}
+}
+
 
 ///
 /// C O N T A I N E R   M O D I F I E R S
Index: clang/test/Analysis/Inputs/system-header-simulator-cxx.h
===
--- clang/test/Analysis/Inputs/system-header-simulator-cxx.h
+++ clang/test/Analysis/Inputs/system-header-simulator-cxx.h
@@ -334,6 +334,8 @@
 const T& front() const { return *begin(); }
 T& back() { return *(end() - 1); }
 const T& back() const { return *(end() - 1); }
+
+bool empty() const;
   };
   
   template
@@ -405,6 +407,8 @@
 const T& front() const { return *begin(); }
 T& back() { return *--end(); }
 const T& back() const { return *--end(); }
+
+bool empty() const;
   };
 
   template
@@ -486,6 +490,8 @@
 const T& front() const { return *begin(); }
 T& back() { return *(end() - 1); }
 const T& back() const { return *(end() - 1); }
+
+bool empty() const;
   };
 
   template
@@ -550,6 +556,8 @@
 
 T& front() { return *begin(); }
 const T& front() const { return *begin(); }
+
+bool empty() const;
   };
 
   template 
Index: clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
+++ clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
@@ -158,8 +158,6 @@
 bool isSimpleComparisonOperator(OverloadedOperatorKind OK);
 bool isSimpleComparisonOperator(BinaryOperatorKind OK);
 ProgramStateRef removeIteratorPosition(ProgramStateRef State, SVal Val);
-ProgramStateRef relateSymbols(ProgramStateRef State, SymbolRef Sym1,
-  SymbolRef Sym2, bool Equal);
 const ExplodedNode *findCallEnter(const ExplodedNode *Node, const Expr *Call);
 
 } // namespace
@@ -465,37 +463,24 @@
 State = State->Bi

[PATCH] D85186: [SyntaxTree] Add support for `LiteralExpression`

[Eduardo Caldas 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 rG860cbbdd6b84: [SyntaxTree] Add support for 
`LiteralExpression` (authored by eduucaldas).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85186

Files:
  clang/include/clang/Tooling/Syntax/Nodes.h
  clang/lib/Tooling/Syntax/Nodes.cpp

Index: clang/lib/Tooling/Syntax/Nodes.cpp
===
--- clang/lib/Tooling/Syntax/Nodes.cpp
+++ clang/lib/Tooling/Syntax/Nodes.cpp
@@ -230,37 +230,7 @@
   findChild(syntax::NodeRole::CloseParen));
 }
 
-syntax::Leaf *syntax::IntegerLiteralExpression::literalToken() {
-  return llvm::cast_or_null(
-  findChild(syntax::NodeRole::LiteralToken));
-}
-
-syntax::Leaf *syntax::CharacterLiteralExpression::literalToken() {
-  return llvm::cast_or_null(
-  findChild(syntax::NodeRole::LiteralToken));
-}
-
-syntax::Leaf *syntax::FloatingLiteralExpression::literalToken() {
-  return llvm::cast_or_null(
-  findChild(syntax::NodeRole::LiteralToken));
-}
-
-syntax::Leaf *syntax::StringLiteralExpression::literalToken() {
-  return llvm::cast_or_null(
-  findChild(syntax::NodeRole::LiteralToken));
-}
-
-syntax::Leaf *syntax::BoolLiteralExpression::literalToken() {
-  return llvm::cast_or_null(
-  findChild(syntax::NodeRole::LiteralToken));
-}
-
-syntax::Leaf *syntax::CxxNullPtrExpression::nullPtrKeyword() {
-  return llvm::cast_or_null(
-  findChild(syntax::NodeRole::LiteralToken));
-}
-
-syntax::Leaf *syntax::UserDefinedLiteralExpression::literalToken() {
+syntax::Leaf *syntax::LiteralExpression::literalToken() {
   return llvm::cast_or_null(
   findChild(syntax::NodeRole::LiteralToken));
 }
Index: clang/include/clang/Tooling/Syntax/Nodes.h
===
--- clang/include/clang/Tooling/Syntax/Nodes.h
+++ clang/include/clang/Tooling/Syntax/Nodes.h
@@ -267,66 +267,82 @@
   syntax::Leaf *closeParen();
 };
 
+/// Expression for literals. C++ [lex.literal]
+class LiteralExpression : public Expression {
+public:
+  LiteralExpression(NodeKind K) : Expression(K) {}
+  static bool classof(const Node *N) {
+return N->kind() == NodeKind::IntegerLiteralExpression ||
+   N->kind() == NodeKind::CharacterLiteralExpression ||
+   N->kind() == NodeKind::FloatingLiteralExpression ||
+   N->kind() == NodeKind::StringLiteralExpression ||
+   N->kind() == NodeKind::BoolLiteralExpression ||
+   N->kind() == NodeKind::CxxNullPtrExpression ||
+   N->kind() == NodeKind::IntegerUserDefinedLiteralExpression ||
+   N->kind() == NodeKind::FloatUserDefinedLiteralExpression ||
+   N->kind() == NodeKind::CharUserDefinedLiteralExpression ||
+   N->kind() == NodeKind::StringUserDefinedLiteralExpression;
+  }
+  syntax::Leaf *literalToken();
+};
+
 /// Expression for integer literals. C++ [lex.icon]
-class IntegerLiteralExpression final : public Expression {
+class IntegerLiteralExpression final : public LiteralExpression {
 public:
-  IntegerLiteralExpression() : Expression(NodeKind::IntegerLiteralExpression) {}
+  IntegerLiteralExpression()
+  : LiteralExpression(NodeKind::IntegerLiteralExpression) {}
   static bool classof(const Node *N) {
 return N->kind() == NodeKind::IntegerLiteralExpression;
   }
-  syntax::Leaf *literalToken();
 };
 
 /// Expression for character literals. C++ [lex.ccon]
-class CharacterLiteralExpression final : public Expression {
+class CharacterLiteralExpression final : public LiteralExpression {
 public:
   CharacterLiteralExpression()
-  : Expression(NodeKind::CharacterLiteralExpression) {}
+  : LiteralExpression(NodeKind::CharacterLiteralExpression) {}
   static bool classof(const Node *N) {
 return N->kind() == NodeKind::CharacterLiteralExpression;
   }
-  syntax::Leaf *literalToken();
 };
 
 /// Expression for floating-point literals. C++ [lex.fcon]
-class FloatingLiteralExpression final : public Expression {
+class FloatingLiteralExpression final : public LiteralExpression {
 public:
   FloatingLiteralExpression()
-  : Expression(NodeKind::FloatingLiteralExpression) {}
+  : LiteralExpression(NodeKind::FloatingLiteralExpression) {}
   static bool classof(const Node *N) {
 return N->kind() == NodeKind::FloatingLiteralExpression;
   }
-  syntax::Leaf *literalToken();
 };
 
 /// Expression for string-literals. C++ [lex.string]
-class StringLiteralExpression final : public Expression {
+class StringLiteralExpression final : public LiteralExpression {
 public:
-  StringLiteralExpression() : Expression(NodeKind::StringLiteralExpression) {}
+  StringLiteralExpression()
+  : LiteralExpression(NodeKind::StringLiteralExpression) {}
   static bool classof(const Node *N) {
 return N->kind() == NodeKind::StringLiteralExpress

[PATCH] D84622: [PowerPC] Implement Vector Extract Low/High Order Builtins in LLVM/Clang

[Amy Kwan via Phabricator via cfe-commits]

amyk accepted this revision.
amyk added a comment.

I think overall it LGTM and the indentation can be addressed when committing.




Comment at: clang/lib/Headers/altivec.h:17082
 
+/* vec_extractl */
+static __inline__ vector unsigned long long __ATTRS_o_ai vec_extractl(

nit: space after this comment



Comment at: clang/lib/Headers/altivec.h:17124
+
+/* vec_extracth */
+static __inline__ vector unsigned long long __ATTRS_o_ai vec_extracth(

nit: space after this comment



Comment at: clang/lib/Headers/altivec.h:17156
+static __inline__ vector unsigned long long __ATTRS_o_ai
+vec_extracth(vector unsigned long long __a, vector unsigned long long __b,
+ unsigned int __c) {

I know you said previously that having the function names in one way caused 
errors with clang format, but could we have the function names declared in the 
same way for consistency?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84622

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

[PATCH] D81083: [Clang] Allow "vector_size" applied to Booleans

[Simon Moll via Phabricator via cfe-commits]

simoll added inline comments.



Comment at: clang/docs/LanguageExtensions.rst:473
+architectures.  The size parameter of a boolean vector type is the number of
+bits in the vector (for all non-bool vectors, the number refers to the number
+of bytes in the vector).

rsandifo-arm wrote:
> simoll wrote:
> > rsandifo-arm wrote:
> > > simoll wrote:
> > > > lenary wrote:
> > > > > It would be nice if this aside about non-bool vectors was more 
> > > > > prominently displayed - it's something I hadn't realised before.
> > > > Yep. that caught me by surprise too. I'll move that sentence to the 
> > > > paragraph about GCC vectors above.
> > > Sorry for the extremely late comment.  Like @lenary I hadn't thought 
> > > about this.  I'd assumed that the vector woiuld still be a multiple of 8 
> > > bits in size, but I agree that's probably too restrictive to be the only 
> > > option available.
> > > 
> > > In that case, would it make sense to add a separate attribute instead?  I 
> > > think it's too surprising to change the units of the existing attribute 
> > > based on the element type.  Perhaps we should even make it take two 
> > > parameters: the total number of elements, and the number of bits per 
> > > element.  That might be more natural for some AVX and SVE combinations.  
> > > We wouldn't need to supporrt all combinations from the outset, it's just 
> > > a question whether we should make the syntax general enough to support it 
> > > in future.
> > > 
> > > Perhaps we could do both: support `vector_size` for `bool` using byte 
> > > sizes (and not allowing subbyte vector lengths), and add a new, more 
> > > general attribute that allows subbyte lengths and explicit subbyte 
> > > element sizes.
> > > In that case, would it make sense to add a separate attribute instead? I 
> > > think it's too surprising to change the units of the existing attribute 
> > > based on the element type. Perhaps we should even make it take two 
> > > parameters: the total number of elements, and the number of bits per 
> > > element. That might be more natural for some AVX and SVE combinations. We 
> > > wouldn't need to supporrt all combinations from the outset, it's just a 
> > > question whether we should make the syntax general enough to support it 
> > > in future.
> > 
> > I guess adding a new attribute makes sense mid to long term. For now, i'd 
> > want something that just does the job... ie, what is proposed here. We 
> > should absolutely document the semantics of vector_size properly.. it 
> > already is counterintuitive (broken, if you ask me).
> > 
> > 
> > > Perhaps we could do both: support vector_size for bool using byte sizes 
> > > (and not allowing subbyte vector lengths), and add a new, more general 
> > > attribute that allows subbyte lengths and explicit subbyte element sizes.
> > 
> > Disallowing subbyte bool vectors actually makes this more complicated 
> > because these types are produced implicitly by compares of (legal) vector 
> > types. Consider this:
> > 
> >   typedef int int3 __attribute__((vector_size(3 * sizeof(int;
> >   int3 A = ...;
> >   int3 B = ...;
> >   auto Z = A < B; // vector compare yielding a `bool vector_size(3)`-typed 
> > value.
> > 
> > 
> > Regarding your proposal for a separate subbyte element size and subbyte 
> > length, that may or may not make sense but it is surely something that 
> > should be discussed more broadly with its own proposal.
> > > Perhaps we could do both: support vector_size for bool using byte sizes 
> > > (and not allowing subbyte vector lengths), and add a new, more general 
> > > attribute that allows subbyte lengths and explicit subbyte element sizes.
> > 
> > Disallowing subbyte bool vectors actually makes this more complicated 
> > because these types are produced implicitly by compares of (legal) vector 
> > types. Consider this:
> > 
> >   typedef int int3 __attribute__((vector_size(3 * sizeof(int;
> >   int3 A = ...;
> >   int3 B = ...;
> >   auto Z = A < B; // vector compare yielding a `bool vector_size(3)`-typed 
> > value.
> 
> Yeah, I understand the need for some way of creating subbyte vectors.  I'm 
> just not sure using the existing `vector_size` attribute would be the best 
> choice for that case.  I.e. the objection wasn't based on “keeping things 
> simple” but more “keeping things consistent“.
> 
> That doesn't mean that the above code should be invalid.  It just means that 
> it wouldn't be possible to write the type of Z using the existing 
> `vector_size` attribute.
> 
> (FWIW, `vector_size` was originally a GNUism and GCC stil requires vector 
> sizes to be a power of 2, but I realise that isn't relevant here.  And the 
> same principle applies with s/3/4 in the above example anyway.)
> 
> > Regarding your proposal for a separate subbyte element size and subbyte 
> > length, that may or may not make sense but it is surely something that 
> > should be discussed more broadly with its own

[PATCH] D76590: [Analyzer] Model `empty()` member function of containers

[Balogh , Ádám via Phabricator via cfe-commits]

baloghadamsoftware updated this revision to Diff 282914.
baloghadamsoftware marked 2 inline comments as done.
baloghadamsoftware added a comment.

Minor fix.


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

https://reviews.llvm.org/D76590

Files:
  clang/lib/StaticAnalyzer/Checkers/ContainerModeling.cpp
  clang/lib/StaticAnalyzer/Checkers/Iterator.cpp
  clang/lib/StaticAnalyzer/Checkers/Iterator.h
  clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
  clang/test/Analysis/Inputs/system-header-simulator-cxx.h
  clang/test/Analysis/container-modeling.cpp
  clang/test/Analysis/diagnostics/explicit-suppression.cpp

Index: clang/test/Analysis/diagnostics/explicit-suppression.cpp
===
--- clang/test/Analysis/diagnostics/explicit-suppression.cpp
+++ clang/test/Analysis/diagnostics/explicit-suppression.cpp
@@ -19,6 +19,6 @@
 void testCopyNull(C *I, C *E) {
   std::copy(I, E, (C *)0);
 #ifndef SUPPRESSED
-  // expected-warning@../Inputs/system-header-simulator-cxx.h:699 {{Called C++ object pointer is null}}
+  // expected-warning@../Inputs/system-header-simulator-cxx.h:707 {{Called C++ object pointer is null}}
 #endif
 }
Index: clang/test/Analysis/container-modeling.cpp
===
--- clang/test/Analysis/container-modeling.cpp
+++ clang/test/Analysis/container-modeling.cpp
@@ -16,6 +16,12 @@
 void clang_analyzer_eval(bool);
 void clang_analyzer_warnIfReached();
 
+extern void __assert_fail (__const char *__assertion, __const char *__file,
+unsigned int __line, __const char *__function)
+ __attribute__ ((__noreturn__));
+#define assert(expr) \
+  ((expr)  ? (void)(0)  : __assert_fail (#expr, __FILE__, __LINE__, __func__))
+
 void begin(const std::vector &V) {
   V.begin();
 
@@ -56,6 +62,40 @@
// expected-note@-1{{TRUE}}
 }
 
+
+///
+/// C O N T A I N E R   C A P A C I T Y
+///
+
+
+/// empty()
+
+void empty(const std::vector &V) {
+  for (auto n: V) {}
+  clang_analyzer_eval(clang_analyzer_container_begin(V) ==
+  clang_analyzer_container_end(V));
+  // expected-warning@-2{{TRUE}} expected-warning@-2{{FALSE}}
+  // expected-note@-3   {{TRUE}} expected-note@-3   {{FALSE}}
+}
+
+void non_empty1(const std::vector &V) {
+  assert(!V.empty()); // expected-note{{'?' condition is true}}
+  for (auto n: V) {}
+  clang_analyzer_eval(clang_analyzer_container_begin(V) ==
+  clang_analyzer_container_end(V));
+  // expected-warning@-2{{FALSE}}
+  // expected-note@-3   {{FALSE}}
+}
+
+void non_empty2(const std::vector &V) {
+  for (auto n: V) {}
+  assert(!V.empty()); // expected-note{{'?' condition is true}}
+  clang_analyzer_eval(clang_analyzer_container_begin(V) ==
+  clang_analyzer_container_end(V));
+  // expected-warning@-2{{FALSE}}
+  // expected-note@-3   {{FALSE}}
+}
+
 
 ///
 /// C O N T A I N E R   M O D I F I E R S
Index: clang/test/Analysis/Inputs/system-header-simulator-cxx.h
===
--- clang/test/Analysis/Inputs/system-header-simulator-cxx.h
+++ clang/test/Analysis/Inputs/system-header-simulator-cxx.h
@@ -334,6 +334,8 @@
 const T& front() const { return *begin(); }
 T& back() { return *(end() - 1); }
 const T& back() const { return *(end() - 1); }
+
+bool empty() const;
   };
   
   template
@@ -405,6 +407,8 @@
 const T& front() const { return *begin(); }
 T& back() { return *--end(); }
 const T& back() const { return *--end(); }
+
+bool empty() const;
   };
 
   template
@@ -486,6 +490,8 @@
 const T& front() const { return *begin(); }
 T& back() { return *(end() - 1); }
 const T& back() const { return *(end() - 1); }
+
+bool empty() const;
   };
 
   template
@@ -550,6 +556,8 @@
 
 T& front() { return *begin(); }
 const T& front() const { return *begin(); }
+
+bool empty() const;
   };
 
   template 
Index: clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
+++ clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
@@ -158,8 +158,6 @@
 bool isSimpleComparisonOperator(OverloadedOperatorKind OK);
 bool isSimpleComparisonOperator(BinaryOperatorKind OK);
 ProgramStateRef removeIteratorPosition(ProgramStateRef State, SVal Val);
-ProgramStateRef relateSymbols(ProgramStateRef State, SymbolRef Sym1,
-  SymbolRef Sym2, bool Equal);
 const ExplodedNode *findCallEnter(const ExplodedNode *Node, const Expr *Call);
 
 } // namespace
@@ -465,37 +463

[PATCH] D85191: [AST] Get field size in chars rather than bits in RecordLayoutBuilder.

[Xiangling Liao via Phabricator via cfe-commits]

Xiangling_L added inline comments.



Comment at: clang/lib/AST/RecordLayoutBuilder.cpp:1841
   auto setDeclInfo = [&](bool IsIncompleteArrayType) {
-TypeInfo TI = Context.getTypeInfo(D->getType());
-FieldAlign = Context.toCharUnitsFromBits(TI.Align);
+auto TI = Context.getTypeInfoInChars(D->getType());
+FieldAlign = TI.second;

In most cases, `getTypeInfoInChars` invokes `getTypeInfo` underneath. So to 
make people be careful about this, I would suggest to leave a comment 
explaining/claiming we have to call `getTypeInfoInChars` here. And also maybe 
adding a testcase to guard the scenario you were talking about would be helpful 
to prevent someone to use `getTypeInfo` here in the future.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85191

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

[PATCH] D84637: [AST] Enhance the const expression evaluator to support error-dependent exprs.

[Haojian Wu via Phabricator via cfe-commits]

hokein updated this revision to Diff 282916.
hokein added a comment.

address review comments:

- treat contains-errors expression as being potentially constant;
- handle the value-dependent expressions for EvaluateInPlace;
- remove the bailing out for constructor initializers that contains errors;


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84637

Files:
  clang/lib/AST/ExprConstant.cpp
  clang/test/SemaCXX/constexpr-function-recovery-crash.cpp
  clang/test/SemaCXX/enable_if.cpp
  clang/test/SemaCXX/invalid-constructor-init.cpp
  clang/test/SemaCXX/recovery-expr-type.cpp

Index: clang/test/SemaCXX/recovery-expr-type.cpp
===
--- clang/test/SemaCXX/recovery-expr-type.cpp
+++ clang/test/SemaCXX/recovery-expr-type.cpp
@@ -53,14 +53,12 @@
 return 2;
   }
   static constexpr int foo2() {
-return AA::getB(); // expected-error{{no matching function for call to 'getB'}} \
-  // expected-note {{subexpression not valid in a constant expression}}
+return AA::getB(); // expected-error{{no matching function for call to 'getB'}}
   }
 };
 // FIXME: should we suppress the "be initialized by a constant expression" diagnostic?
 constexpr auto x2 = AA::foo2(); // expected-error {{be initialized by a constant expression}} \
- // expected-note {{in instantiation of member function}} \
- // expected-note {{in call to}}
+ // expected-note {{in instantiation of member function}}
 }
 
 // verify no assertion failure on violating value category.
Index: clang/test/SemaCXX/invalid-constructor-init.cpp
===
--- clang/test/SemaCXX/invalid-constructor-init.cpp
+++ clang/test/SemaCXX/invalid-constructor-init.cpp
@@ -2,7 +2,7 @@
 
 struct X {
   int Y;
-  constexpr X() // expected-error {{constexpr constructor never produces}}
+  constexpr X()
   : Y(foo()) {} // expected-error {{use of undeclared identifier 'foo'}}
 };
 // no crash on evaluating the constexpr ctor.
@@ -16,7 +16,7 @@
 
 struct X3 {
   int Y;
-  constexpr X3() // expected-error {{constexpr constructor never produces}}
+  constexpr X3()
   : Y(({foo();})) {} // expected-error {{use of undeclared identifier 'foo'}}
 };
 
Index: clang/test/SemaCXX/enable_if.cpp
===
--- clang/test/SemaCXX/enable_if.cpp
+++ clang/test/SemaCXX/enable_if.cpp
@@ -415,7 +415,7 @@
 template  constexpr int callTemplated() { return templated(); }
 
 constexpr int B = 10 + // expected-error {{initialized by a constant expression}}
-callTemplated<0>(); // expected-error@-3{{no matching function for call to 'templated'}} expected-note{{in instantiation of function template}} expected-note@-10{{candidate disabled}} expected-note {{in call to 'callTemplated()'}} expected-note@-3 {{subexpression not valid in a constant expression}}
+callTemplated<0>(); // expected-error@-3{{no matching function for call to 'templated'}} expected-note{{in instantiation of function template}} expected-note@-10{{candidate disabled}}
 static_assert(callTemplated<1>() == 1, "");
 }
 
Index: clang/test/SemaCXX/constexpr-function-recovery-crash.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/constexpr-function-recovery-crash.cpp
@@ -0,0 +1,35 @@
+// RUN: %clang_cc1 %s -std=c++20 -fsyntax-only -verify
+
+// verify no value-dependent-assertion crash in constexpr function body.
+class Foo {
+  constexpr Foo() {
+while (invalid()) {} // expected-error {{use of undeclared identifier}}
+if (invalid()) {} // expected-error {{use of undeclared identifier}}
+  }
+};
+
+constexpr void test1() {
+  while (invalid()) {} // expected-error {{use of undeclared identifier}}
+  if (invalid()) {} // expected-error {{use of undeclared identifier}}
+}
+
+struct A {
+  int* p = new int(invalid()); // expected-error {{use of undeclared identifier}}
+  constexpr ~A() { delete p; }
+};
+constexpr int test2() {
+  A a;
+  return 1;
+}
+
+constexpr int test3() {
+  return invalid(); // expected-error {{use of undeclared identifier}}
+}
+
+constexpr int test4() { // expected-error {{constexpr function never produces a constant expression}}
+  if (invalid()) // expected-error {{use of undeclared identifier}}
+return 1;
+  else
+return 0;
+// FIXME: remove the "control reached end" diagnostic note.
+}  // expected-note {{control reached end of constexpr function}}
Index: clang/lib/AST/ExprConstant.cpp
===
--- clang/lib/AST/ExprConstant.cpp
+++ clang/lib/AST/ExprConstant.cpp
@@ -1868,6 +1868,7 @@
 /// result.
 /// \return \c true if the caller should keep evaluating.
 static bool EvaluateI

[PATCH] D84637: [AST] Enhance the const expression evaluator to support error-dependent exprs.

[Haojian Wu via Phabricator via cfe-commits]

hokein updated this revision to Diff 282917.
hokein added a comment.

update


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84637

Files:
  clang/lib/AST/ExprConstant.cpp
  clang/test/SemaCXX/constexpr-function-recovery-crash.cpp
  clang/test/SemaCXX/enable_if.cpp
  clang/test/SemaCXX/invalid-constructor-init.cpp
  clang/test/SemaCXX/recovery-expr-type.cpp

Index: clang/test/SemaCXX/recovery-expr-type.cpp
===
--- clang/test/SemaCXX/recovery-expr-type.cpp
+++ clang/test/SemaCXX/recovery-expr-type.cpp
@@ -53,14 +53,12 @@
 return 2;
   }
   static constexpr int foo2() {
-return AA::getB(); // expected-error{{no matching function for call to 'getB'}} \
-  // expected-note {{subexpression not valid in a constant expression}}
+return AA::getB(); // expected-error{{no matching function for call to 'getB'}}
   }
 };
 // FIXME: should we suppress the "be initialized by a constant expression" diagnostic?
 constexpr auto x2 = AA::foo2(); // expected-error {{be initialized by a constant expression}} \
- // expected-note {{in instantiation of member function}} \
- // expected-note {{in call to}}
+ // expected-note {{in instantiation of member function}}
 }
 
 // verify no assertion failure on violating value category.
Index: clang/test/SemaCXX/invalid-constructor-init.cpp
===
--- clang/test/SemaCXX/invalid-constructor-init.cpp
+++ clang/test/SemaCXX/invalid-constructor-init.cpp
@@ -2,7 +2,7 @@
 
 struct X {
   int Y;
-  constexpr X() // expected-error {{constexpr constructor never produces}}
+  constexpr X()
   : Y(foo()) {} // expected-error {{use of undeclared identifier 'foo'}}
 };
 // no crash on evaluating the constexpr ctor.
@@ -16,7 +16,7 @@
 
 struct X3 {
   int Y;
-  constexpr X3() // expected-error {{constexpr constructor never produces}}
+  constexpr X3()
   : Y(({foo();})) {} // expected-error {{use of undeclared identifier 'foo'}}
 };
 
Index: clang/test/SemaCXX/enable_if.cpp
===
--- clang/test/SemaCXX/enable_if.cpp
+++ clang/test/SemaCXX/enable_if.cpp
@@ -415,7 +415,7 @@
 template  constexpr int callTemplated() { return templated(); }
 
 constexpr int B = 10 + // expected-error {{initialized by a constant expression}}
-callTemplated<0>(); // expected-error@-3{{no matching function for call to 'templated'}} expected-note{{in instantiation of function template}} expected-note@-10{{candidate disabled}} expected-note {{in call to 'callTemplated()'}} expected-note@-3 {{subexpression not valid in a constant expression}}
+callTemplated<0>(); // expected-error@-3{{no matching function for call to 'templated'}} expected-note{{in instantiation of function template}} expected-note@-10{{candidate disabled}}
 static_assert(callTemplated<1>() == 1, "");
 }
 
Index: clang/test/SemaCXX/constexpr-function-recovery-crash.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/constexpr-function-recovery-crash.cpp
@@ -0,0 +1,35 @@
+// RUN: %clang_cc1 %s -std=c++20 -fsyntax-only -verify
+
+// verify no value-dependent-assertion crash in constexpr function body.
+class Foo {
+  constexpr Foo() {
+while (invalid()) {} // expected-error {{use of undeclared identifier}}
+if (invalid()) {} // expected-error {{use of undeclared identifier}}
+  }
+};
+
+constexpr void test1() {
+  while (invalid()) {} // expected-error {{use of undeclared identifier}}
+  if (invalid()) {} // expected-error {{use of undeclared identifier}}
+}
+
+struct A {
+  int* p = new int(invalid()); // expected-error {{use of undeclared identifier}}
+  constexpr ~A() { delete p; }
+};
+constexpr int test2() {
+  A a;
+  return 1;
+}
+
+constexpr int test3() {
+  return invalid(); // expected-error {{use of undeclared identifier}}
+}
+
+constexpr int test4() { // expected-error {{constexpr function never produces a constant expression}}
+  if (invalid()) // expected-error {{use of undeclared identifier}}
+return 1;
+  else
+return 0;
+// FIXME: remove the "control reached end" diagnostic note.
+}  // expected-note {{control reached end of constexpr function}}
Index: clang/lib/AST/ExprConstant.cpp
===
--- clang/lib/AST/ExprConstant.cpp
+++ clang/lib/AST/ExprConstant.cpp
@@ -1868,6 +1868,7 @@
 /// result.
 /// \return \c true if the caller should keep evaluating.
 static bool EvaluateIgnoredValue(EvalInfo &Info, const Expr *E) {
+  assert(!E->isValueDependent());
   APValue Scratch;
   if (!Evaluate(Scratch, Info, E))
 // We don't need the value, but we might have skipped a side effect here.
@@ -2369

[clang] 8ce15f7 - [SyntaxTree] Fix crash on pointer to member function

[Eduardo Caldas via cfe-commits]

Author: Eduardo Caldas
Date: 2020-08-04T14:31:12Z
New Revision: 8ce15f7eeb122c0bba4b676d797217359dd57c30

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

LOG: [SyntaxTree] Fix crash on pointer to member function

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

Added: 


Modified: 
clang/lib/Tooling/Syntax/BuildTree.cpp
clang/unittests/Tooling/Syntax/TreeTest.cpp

Removed: 




diff  --git a/clang/lib/Tooling/Syntax/BuildTree.cpp 
b/clang/lib/Tooling/Syntax/BuildTree.cpp
index 1f192180ec45..15b7c8fab198 100644
--- a/clang/lib/Tooling/Syntax/BuildTree.cpp
+++ b/clang/lib/Tooling/Syntax/BuildTree.cpp
@@ -939,6 +939,8 @@ class BuildTreeVisitor : public 
RecursiveASTVisitor {
 return true;
   }
 
+  // FIXME: Deleting the `TraverseParenTypeLoc` override doesn't change test
+  // results. Find test coverage or remove it.
   bool TraverseParenTypeLoc(ParenTypeLoc L) {
 // We reverse order of traversal to get the proper syntax structure.
 if (!WalkUpFromParenTypeLoc(L))
@@ -987,6 +989,16 @@ class BuildTreeVisitor : public 
RecursiveASTVisitor {
 return WalkUpFromFunctionTypeLoc(L);
   }
 
+  bool TraverseMemberPointerTypeLoc(MemberPointerTypeLoc L) {
+// In the source code "void (Y::*mp)()" `MemberPointerTypeLoc` corresponds
+// to "Y::*" but it points to a `ParenTypeLoc` that corresponds to
+// "(Y::*mp)" We thus reverse the order of traversal to get the proper
+// syntax structure.
+if (!WalkUpFromMemberPointerTypeLoc(L))
+  return false;
+return TraverseTypeLoc(L.getPointeeLoc());
+  }
+
   bool WalkUpFromMemberPointerTypeLoc(MemberPointerTypeLoc L) {
 auto SR = L.getLocalSourceRange();
 Builder.foldNode(Builder.getRange(SR),

diff  --git a/clang/unittests/Tooling/Syntax/TreeTest.cpp 
b/clang/unittests/Tooling/Syntax/TreeTest.cpp
index a722ca2b1a45..3ccfabb95da9 100644
--- a/clang/unittests/Tooling/Syntax/TreeTest.cpp
+++ b/clang/unittests/Tooling/Syntax/TreeTest.cpp
@@ -4074,6 +4074,99 @@ const int X::* b;
 )txt"));
 }
 
+TEST_P(SyntaxTreeTest, MemberFunctionPointer) {
+  if (!GetParam().isCXX()) {
+return;
+  }
+  EXPECT_TRUE(treeDumpEqual(
+  R"cpp(
+struct X {
+  struct Y {};
+};
+void (X::*xp)();
+void (X::**xpp)(const int*);
+// FIXME: Generate the right syntax tree for this type,
+// i.e. create a syntax node for the outer member pointer
+void (X::Y::*xyp)(const int*, char);
+)cpp",
+  R"txt(
+*: TranslationUnit
+|-SimpleDeclaration
+| |-struct
+| |-X
+| |-{
+| |-SimpleDeclaration
+| | |-struct
+| | |-Y
+| | |-{
+| | |-}
+| | `-;
+| |-}
+| `-;
+|-SimpleDeclaration
+| |-void
+| |-SimpleDeclarator
+| | |-ParenDeclarator
+| | | |-(
+| | | |-MemberPointer
+| | | | |-X
+| | | | |-::
+| | | | `-*
+| | | |-xp
+| | | `-)
+| | `-ParametersAndQualifiers
+| |   |-(
+| |   `-)
+| `-;
+|-SimpleDeclaration
+| |-void
+| |-SimpleDeclarator
+| | |-ParenDeclarator
+| | | |-(
+| | | |-MemberPointer
+| | | | |-X
+| | | | |-::
+| | | | `-*
+| | | |-*
+| | | |-xpp
+| | | `-)
+| | `-ParametersAndQualifiers
+| |   |-(
+| |   |-SimpleDeclaration
+| |   | |-const
+| |   | |-int
+| |   | `-SimpleDeclarator
+| |   |   `-*
+| |   `-)
+| `-;
+`-SimpleDeclaration
+  |-void
+  |-SimpleDeclarator
+  | |-ParenDeclarator
+  | | |-(
+  | | |-X
+  | | |-::
+  | | |-MemberPointer
+  | | | |-Y
+  | | | |-::
+  | | | `-*
+  | | |-xyp
+  | | `-)
+  | `-ParametersAndQualifiers
+  |   |-(
+  |   |-SimpleDeclaration
+  |   | |-const
+  |   | |-int
+  |   | `-SimpleDeclarator
+  |   |   `-*
+  |   |-,
+  |   |-SimpleDeclaration
+  |   | `-char
+  |   `-)
+  `-;
+)txt"));
+}
+
 TEST_P(SyntaxTreeTest, ComplexDeclarator) {
   EXPECT_TRUE(treeDumpEqual(
   R"cpp(



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

[PATCH] D85146: [SyntaxTree] Fix crash on pointer to member function

[Eduardo Caldas via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG8ce15f7eeb12: [SyntaxTree] Fix crash on pointer to member 
function (authored by eduucaldas).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85146

Files:
  clang/lib/Tooling/Syntax/BuildTree.cpp
  clang/unittests/Tooling/Syntax/TreeTest.cpp

Index: clang/unittests/Tooling/Syntax/TreeTest.cpp
===
--- clang/unittests/Tooling/Syntax/TreeTest.cpp
+++ clang/unittests/Tooling/Syntax/TreeTest.cpp
@@ -4074,6 +4074,99 @@
 )txt"));
 }
 
+TEST_P(SyntaxTreeTest, MemberFunctionPointer) {
+  if (!GetParam().isCXX()) {
+return;
+  }
+  EXPECT_TRUE(treeDumpEqual(
+  R"cpp(
+struct X {
+  struct Y {};
+};
+void (X::*xp)();
+void (X::**xpp)(const int*);
+// FIXME: Generate the right syntax tree for this type,
+// i.e. create a syntax node for the outer member pointer
+void (X::Y::*xyp)(const int*, char);
+)cpp",
+  R"txt(
+*: TranslationUnit
+|-SimpleDeclaration
+| |-struct
+| |-X
+| |-{
+| |-SimpleDeclaration
+| | |-struct
+| | |-Y
+| | |-{
+| | |-}
+| | `-;
+| |-}
+| `-;
+|-SimpleDeclaration
+| |-void
+| |-SimpleDeclarator
+| | |-ParenDeclarator
+| | | |-(
+| | | |-MemberPointer
+| | | | |-X
+| | | | |-::
+| | | | `-*
+| | | |-xp
+| | | `-)
+| | `-ParametersAndQualifiers
+| |   |-(
+| |   `-)
+| `-;
+|-SimpleDeclaration
+| |-void
+| |-SimpleDeclarator
+| | |-ParenDeclarator
+| | | |-(
+| | | |-MemberPointer
+| | | | |-X
+| | | | |-::
+| | | | `-*
+| | | |-*
+| | | |-xpp
+| | | `-)
+| | `-ParametersAndQualifiers
+| |   |-(
+| |   |-SimpleDeclaration
+| |   | |-const
+| |   | |-int
+| |   | `-SimpleDeclarator
+| |   |   `-*
+| |   `-)
+| `-;
+`-SimpleDeclaration
+  |-void
+  |-SimpleDeclarator
+  | |-ParenDeclarator
+  | | |-(
+  | | |-X
+  | | |-::
+  | | |-MemberPointer
+  | | | |-Y
+  | | | |-::
+  | | | `-*
+  | | |-xyp
+  | | `-)
+  | `-ParametersAndQualifiers
+  |   |-(
+  |   |-SimpleDeclaration
+  |   | |-const
+  |   | |-int
+  |   | `-SimpleDeclarator
+  |   |   `-*
+  |   |-,
+  |   |-SimpleDeclaration
+  |   | `-char
+  |   `-)
+  `-;
+)txt"));
+}
+
 TEST_P(SyntaxTreeTest, ComplexDeclarator) {
   EXPECT_TRUE(treeDumpEqual(
   R"cpp(
Index: clang/lib/Tooling/Syntax/BuildTree.cpp
===
--- clang/lib/Tooling/Syntax/BuildTree.cpp
+++ clang/lib/Tooling/Syntax/BuildTree.cpp
@@ -939,6 +939,8 @@
 return true;
   }
 
+  // FIXME: Deleting the `TraverseParenTypeLoc` override doesn't change test
+  // results. Find test coverage or remove it.
   bool TraverseParenTypeLoc(ParenTypeLoc L) {
 // We reverse order of traversal to get the proper syntax structure.
 if (!WalkUpFromParenTypeLoc(L))
@@ -987,6 +989,16 @@
 return WalkUpFromFunctionTypeLoc(L);
   }
 
+  bool TraverseMemberPointerTypeLoc(MemberPointerTypeLoc L) {
+// In the source code "void (Y::*mp)()" `MemberPointerTypeLoc` corresponds
+// to "Y::*" but it points to a `ParenTypeLoc` that corresponds to
+// "(Y::*mp)" We thus reverse the order of traversal to get the proper
+// syntax structure.
+if (!WalkUpFromMemberPointerTypeLoc(L))
+  return false;
+return TraverseTypeLoc(L.getPointeeLoc());
+  }
+
   bool WalkUpFromMemberPointerTypeLoc(MemberPointerTypeLoc L) {
 auto SR = L.getLocalSourceRange();
 Builder.foldNode(Builder.getRange(SR),
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D83338: [PowerPC][Power10] Implemented Vector Shift Builtins

[Amy Kwan via Phabricator via cfe-commits]

amyk added inline comments.



Comment at: clang/lib/Headers/altivec.h:17217
+
+/* vs[l | r | ra] */
+static __inline__ vector unsigned __int128 __ATTRS_o_ai

Add a space after this comment.



Comment at: clang/lib/Headers/altivec.h:17227
+vec_sl(vector signed __int128 __a, vector unsigned __int128 __b) {
+  // return (vector signed __int128)vec_sl((vector unsigned __int128)__a, __b);
+  return __a << (__b %

Please remove any commented code.



Comment at: clang/lib/Headers/altivec.h:17243
+  // return (vector signed __int128)vec_sr((vector unsigned __int128)__a, __b);
+  return (vector signed __int128)(
+((vector unsigned __int128) __a) >>

Could you please fix the indentation of the returns to make them all consistent?



Comment at: llvm/lib/Target/PowerPC/PPCISelLowering.cpp:1100
+
+if (Subtarget.isISA3_1()) {
+  setOperationAction(ISD::SRA, MVT::v1i128, Legal);

No brackets are needed here.

Also, I think it might make sense to move this block into the previous 
`hasP9Altivec` condition since in there it has:
```
  setOperationAction(ISD::SHL, MVT::v1i128, Legal);
  setOperationAction(ISD::SRL, MVT::v1i128, Legal);
```



Comment at: llvm/lib/Target/PowerPC/PPCInstrPrefix.td:1141
+/* Vector shifts for ISA3_1 */
+let Predicates = [IsISA3_1] in {
+  def : Pat<(v1i128 (shl v1i128:$VRA, v1i128:$VRB)),

There is no need to make a new predicate block, you can put these anonymous 
patterns in the block above.



Comment at: llvm/lib/Target/PowerPC/PPCInstrPrefix.td:1144
+(v1i128 (VSLQ v1i128:$VRA, v1i128:$VRB))>;
+  def : Pat<(v1i128 (PPCshl v1i128:$VRA, v1i128:$VRB)),
+(v1i128 (VSLQ v1i128:$VRA, v1i128:$VRB))>;

I noticed that we have patterns for the PPCISD nodes, but I think no tests to 
show these patterns?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83338

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

[PATCH] D84637: [AST] Enhance the const expression evaluator to support error-dependent exprs.

[Haojian Wu via Phabricator via cfe-commits]

hokein marked an inline comment as done.
hokein added inline comments.



Comment at: clang/lib/AST/ExprConstant.cpp:4961
 }
+if (IS->getCond()->isValueDependent())
+  return EvaluateDependentExpr(IS->getCond(), Info);

The `if` stmt (the same to `while`, `for`) is tricky -- if the condition is 
value-dependent, then we don't know which branch we should run into.

- returning a ESR_Succeeded may lead to a bogus diagnostic ("reach the end of 
the function");
- returning a ESR_Failed may lead to a bogus diagnostic ("never produce a 
constexpr"); 

I guess what we want is to stop the evaluation, and indicate that we hit a 
value-dependent expression and we don't know how to evaluate it, but still 
treat the constexpr function as potential constexpr (but no extra diagnostics 
being emitted), but the current `EvalStmtResult` is not sufficient, maybe we 
need a new enum.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84637

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

[clang] 961da69 - Improve diagnostics for disallowed attributes used with multiversioning

[Erich Keane via cfe-commits]

Author: Erich Keane
Date: 2020-08-04T07:40:27-07:00
New Revision: 961da69d7eafe44411d5ac9719209653d196f9e2

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

LOG: Improve diagnostics for disallowed attributes used with multiversioning

Since we permit using SOME attributes (at the moment, just 1) with
multiversioning, we should improve the message as it still implies that
no attributes should be combined with multiversioning.

Added: 


Modified: 
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/Sema/SemaDecl.cpp
clang/test/Sema/attr-cpuspecific.c
clang/test/Sema/attr-target-mv.c

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 91112860a2d0..288e8232ca74 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -10751,9 +10751,9 @@ def err_multiversion_duplicate : Error<
   "multiversioned function redeclarations require identical target 
attributes">;
 def err_multiversion_noproto : Error<
   "multiversioned function must have a prototype">;
-def err_multiversion_no_other_attrs : Error<
+def err_multiversion_disallowed_other_attr : Error<
   "attribute '%select{target|cpu_specific|cpu_dispatch}0' multiversioning 
cannot be combined"
-  " with other attributes">;
+  " with attribute %1">;
 def err_multiversion_
diff  : Error<
   "multiversioned function declaration has a 
diff erent %select{calling convention"
   "|return type|constexpr specification|inline specification|storage class|"

diff  --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index 531c2801bf92..ba05b0d32cf4 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -10037,23 +10037,37 @@ static bool AttrCompatibleWithMultiVersion(attr::Kind 
Kind,
   }
 }
 
-static bool HasNonMultiVersionAttributes(const FunctionDecl *FD,
- MultiVersionKind MVType) {
+static bool checkNonMultiVersionCompatAttributes(Sema &S,
+ const FunctionDecl *FD,
+ const FunctionDecl *CausedFD,
+ MultiVersionKind MVType) {
+  bool IsCPUSpecificCPUDispatchMVType =
+  MVType == MultiVersionKind::CPUDispatch ||
+  MVType == MultiVersionKind::CPUSpecific;
+  const auto Diagnose = [FD, CausedFD, IsCPUSpecificCPUDispatchMVType](
+Sema &S, const Attr *A) {
+S.Diag(FD->getLocation(), diag::err_multiversion_disallowed_other_attr)
+<< IsCPUSpecificCPUDispatchMVType << A;
+if (CausedFD)
+  S.Diag(CausedFD->getLocation(), diag::note_multiversioning_caused_here);
+return true;
+  };
+
   for (const Attr *A : FD->attrs()) {
 switch (A->getKind()) {
 case attr::CPUDispatch:
 case attr::CPUSpecific:
   if (MVType != MultiVersionKind::CPUDispatch &&
   MVType != MultiVersionKind::CPUSpecific)
-return true;
+return Diagnose(S, A);
   break;
 case attr::Target:
   if (MVType != MultiVersionKind::Target)
-return true;
+return Diagnose(S, A);
   break;
 default:
   if (!AttrCompatibleWithMultiVersion(A->getKind(), MVType))
-return true;
+return Diagnose(S, A);
   break;
 }
   }
@@ -10189,16 +10203,12 @@ static bool CheckMultiVersionAdditionalRules(Sema &S, 
const FunctionDecl *OldFD,
 
   // For now, disallow all other attributes.  These should be opt-in, but
   // an analysis of all of them is a future FIXME.
-  if (CausesMV && OldFD && HasNonMultiVersionAttributes(OldFD, MVType)) {
-S.Diag(OldFD->getLocation(), diag::err_multiversion_no_other_attrs)
-<< IsCPUSpecificCPUDispatchMVType;
-S.Diag(NewFD->getLocation(), diag::note_multiversioning_caused_here);
+  if (CausesMV && OldFD &&
+  checkNonMultiVersionCompatAttributes(S, OldFD, NewFD, MVType))
 return true;
-  }
 
-  if (HasNonMultiVersionAttributes(NewFD, MVType))
-return S.Diag(NewFD->getLocation(), diag::err_multiversion_no_other_attrs)
-   << IsCPUSpecificCPUDispatchMVType;
+  if (checkNonMultiVersionCompatAttributes(S, NewFD, nullptr, MVType))
+return true;
 
   // Only allow transition to MultiVersion if it hasn't been used.
   if (OldFD && CausesMV && OldFD->isUsed(false))

diff  --git a/clang/test/Sema/attr-cpuspecific.c 
b/clang/test/Sema/attr-cpuspecific.c
index ae86742ca081..e32c7a22894d 100644
--- a/clang/test/Sema/attr-cpuspecific.c
+++ b/clang/test/Sema/attr-cpuspecific.c
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -triple x86_64-linux-gnu  -fsyntax-only -verify %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu  -fsynta

[clang] 0a8ac91 - Permit nowthrow and nonnull with multiversioning.

[Erich Keane via cfe-commits]

Author: Erich Keane
Date: 2020-08-04T07:40:27-07:00
New Revision: 0a8ac91a084504929b1ef4ec1fee693455bd796d

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

LOG: Permit nowthrow and nonnull with multiversioning.

Some shipped versions of stdlib.h use nonnull and nothrow with function
multiversioning.  Support these, as they are generally harmless.

Added: 


Modified: 
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/Sema/SemaDecl.cpp
clang/test/Sema/attr-cpuspecific.c
clang/test/Sema/attr-target-mv.c

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 288e8232ca74..054b81c4a72b 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -10754,6 +10754,9 @@ def err_multiversion_noproto : Error<
 def err_multiversion_disallowed_other_attr : Error<
   "attribute '%select{target|cpu_specific|cpu_dispatch}0' multiversioning 
cannot be combined"
   " with attribute %1">;
+def err_multiversion_mismatched_attrs
+: Error<"attributes on multiversioned functions must all match, attribute "
+"%0 %select{is missing|has 
diff erent arguments}1">;
 def err_multiversion_
diff  : Error<
   "multiversioned function declaration has a 
diff erent %select{calling convention"
   "|return type|constexpr specification|inline specification|storage class|"

diff  --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index ba05b0d32cf4..77e15f187e53 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -10029,11 +10029,16 @@ static bool CheckMultiVersionValue(Sema &S, const 
FunctionDecl *FD) {
 // multiversion functions.
 static bool AttrCompatibleWithMultiVersion(attr::Kind Kind,
MultiVersionKind MVType) {
+  // Note: this list/diagnosis must match the list in
+  // checkMultiversionAttributesAllSame.
   switch (Kind) {
   default:
 return false;
   case attr::Used:
 return MVType == MultiVersionKind::Target;
+  case attr::NonNull:
+  case attr::NoThrow:
+return true;
   }
 }
 
@@ -10201,8 +10206,6 @@ static bool CheckMultiVersionAdditionalRules(Sema &S, 
const FunctionDecl *OldFD,
   MVType == MultiVersionKind::CPUDispatch ||
   MVType == MultiVersionKind::CPUSpecific;
 
-  // For now, disallow all other attributes.  These should be opt-in, but
-  // an analysis of all of them is a future FIXME.
   if (CausesMV && OldFD &&
   checkNonMultiVersionCompatAttributes(S, OldFD, NewFD, MVType))
 return true;

diff  --git a/clang/test/Sema/attr-cpuspecific.c 
b/clang/test/Sema/attr-cpuspecific.c
index e32c7a22894d..9cfeef8a2356 100644
--- a/clang/test/Sema/attr-cpuspecific.c
+++ b/clang/test/Sema/attr-cpuspecific.c
@@ -115,3 +115,5 @@ int use3(void) {
 
 // expected-warning@+1 {{CPU list contains duplicate entries; attribute 
ignored}}
 int __attribute__((cpu_dispatch(pentium_iii, pentium_iii_no_xmm_regs))) 
dupe_p3(void);
+
+void __attribute__((cpu_specific(atom), nothrow, nonnull(1))) 
addtl_attrs(int*);

diff  --git a/clang/test/Sema/attr-target-mv.c 
b/clang/test/Sema/attr-target-mv.c
index 33a2c4fa54eb..3f072b19083f 100644
--- a/clang/test/Sema/attr-target-mv.c
+++ b/clang/test/Sema/attr-target-mv.c
@@ -101,3 +101,10 @@ __vectorcall int 
__attribute__((target("arch=sandybridge")))  
diff _cc(void);
 int __attribute__((target("sse4.2"))) 
diff _ret(void);
 // expected-error@+1 {{multiversioned function declaration has a 
diff erent return type}}
 short __attribute__((target("arch=sandybridge")))  
diff _ret(void);
+
+void __attribute__((target("sse4.2"), nothrow, used, nonnull(1))) 
addtl_attrs5(int*);
+void __attribute__((target("arch=sandybridge"))) addtl_attrs5(int*);
+
+void __attribute__((target("sse4.2"))) addtl_attrs6(int*);
+void __attribute__((target("arch=sandybridge"), nothrow, used, nonnull)) 
addtl_attrs6(int*);
+



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

[PATCH] D75181: [AArch64] Handle BTI/PAC in case of generated functions.

[Daniel Kiss via Phabricator via cfe-commits]

danielkiss added a comment.

Would it be better to add a new value to `"sign-return-address"` as `"none"`? I 
don't see any other alternative option, I'm open to any other idea.


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

https://reviews.llvm.org/D75181

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

[PATCH] D77150: [Analyzer] New Option for ContainerModeling: AggressiveEraseModeling

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus accepted this revision.
Szelethus added a reviewer: gamesh411.
Szelethus added a comment.

LGTM on my end, but please wait for approval from either @gamesh411 or @NoQ.

In D77150#2191049 , 
@baloghadamsoftware wrote:

> However, I think we should create a category "advanced" for options which 
> affect the internal modeling. Our users are programmers and the advanced 
> among them should see this option (and others similar to this one).

I think that is a discussion for another time, and definitely on cfe-dev.


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

https://reviews.llvm.org/D77150

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

[PATCH] D85213: Use --dsym-dir when compiling with a compiler that supports it

[Daniel Sanders via Phabricator via cfe-commits]

dsanders created this revision.
dsanders added reviewers: JDevlieghere, beanz, bogner.
Herald added subscribers: cfe-commits, dang, mgorny.
Herald added projects: clang, LLVM.
dsanders requested review of this revision.

As part of this, a couple tweaks to --dsym-dir have been made. It now starts
with a double dash since CMake is unable to detect it's availability otherwise.
clang's that lack it ended up passing the check anyway because of the -d group
accepting anything. Also added the --dsym-dir= variant as the behaviour of
Joined surprised me by including the = in the value otherwise.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D85213

Files:
  clang/include/clang/Driver/Options.td
  clang/test/Driver/darwin-dsymutil.c
  llvm/cmake/modules/AddLLVM.cmake


Index: llvm/cmake/modules/AddLLVM.cmake
===
--- llvm/cmake/modules/AddLLVM.cmake
+++ llvm/cmake/modules/AddLLVM.cmake
@@ -1981,21 +1981,29 @@
 set_property(TARGET ${name} APPEND_STRING PROPERTY
   LINK_FLAGS " ${empty_src}")
 if(LLVM_EXTERNALIZE_DEBUGINFO_OUTPUT_DIR)
-  # clang can currently only emit dSYM's to the same directory as the 
output
-  # binary. Workaround this by moving it after the build.
-  set(output_name "$.${file_ext}")
-  set(output_path 
"${LLVM_EXTERNALIZE_DEBUGINFO_OUTPUT_DIR}/${output_name}")
-  add_custom_command(TARGET ${name} POST_BUILD
-COMMAND ${CMAKE_COMMAND} -E make_directory 
"${LLVM_EXTERNALIZE_DEBUGINFO_OUTPUT_DIR}"
-# Remove any old versions if present
-COMMAND ${CMAKE_COMMAND} -E rm "-rf" "${output_path}"
-# Move the dSYM clang emitted next to the output binary where we want 
it
-# to be.
-COMMAND ${CMAKE_COMMAND}
--DFROM="$.${file_ext}"
--DTO="${output_path}"
--P ${LLVM_CMAKE_PATH}/MoveIfExists.cmake
-  )
+  check_cxx_compiler_flag("--dsym-dir=foo" HAS_DSYM_DIR)
+  if (HAS_DSYM_DIR)
+set_property(TARGET ${name} APPEND_STRING PROPERTY
+ LINK_FLAGS " 
--dsym-dir=${LLVM_EXTERNALIZE_DEBUGINFO_OUTPUT_DIR}")
+add_custom_command(TARGET ${name} PRE_BUILD
+  COMMAND ${CMAKE_COMMAND} -E make_directory 
"${LLVM_EXTERNALIZE_DEBUGINFO_OUTPUT_DIR}")
+  else()
+# clang can currently only emit dSYM's to the same directory as the 
output
+# binary. Workaround this by moving it after the build.
+set(output_name "$.${file_ext}")
+set(output_path 
"${LLVM_EXTERNALIZE_DEBUGINFO_OUTPUT_DIR}/${output_name}")
+add_custom_command(TARGET ${name} POST_BUILD
+  COMMAND ${CMAKE_COMMAND} -E make_directory 
"${LLVM_EXTERNALIZE_DEBUGINFO_OUTPUT_DIR}"
+  # Remove any old versions if present
+  COMMAND ${CMAKE_COMMAND} -E rm "-rf" "${output_path}"
+  # Move the dSYM clang emitted next to the output binary where we 
want it
+  # to be.
+  COMMAND ${CMAKE_COMMAND}
+  -DFROM="$.${file_ext}"
+  -DTO="${output_path}"
+  -P ${LLVM_CMAKE_PATH}/MoveIfExists.cmake
+)
+  endif()
 endif()
 add_custom_command(TARGET ${name} POST_BUILD
   COMMAND ${strip_command}
Index: clang/test/Driver/darwin-dsymutil.c
===
--- clang/test/Driver/darwin-dsymutil.c
+++ clang/test/Driver/darwin-dsymutil.c
@@ -35,7 +35,7 @@
 // RUN:   -check-prefix=CHECK-OUTPUT-NAME < %t %s
 //
 // RUN: %clang -target x86_64-apple-darwin10 -ccc-print-bindings \
-// RUN:   -o bar/foo -dsym-dir external %s -g 2> %t
+// RUN:   -o bar/foo --dsym-dir external %s -g 2> %t
 // RUN: FileCheck -Doutfile=bar/foo -Ddsymfile=external/foo.dSYM \
 // RUN:   -check-prefix=CHECK-OUTPUT-NAME < %t %s
 //
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -677,9 +677,10 @@
   HelpText<"Filename to write DOT-formatted header dependencies to">;
 def module_dependency_dir : Separate<["-"], "module-dependency-dir">,
   Flags<[CC1Option]>, HelpText<"Directory to dump module dependencies to">;
-def dsym_dir : JoinedOrSeparate<["-"], "dsym-dir">,
+def dsym_dir : Separate<["--"], "dsym-dir">,
   Flags<[DriverOption, RenderAsInput]>,
   HelpText<"Directory to output dSYM's (if any) to">, MetaVarName<"">;
+def dsym_dir_EQ : Joined<["--"], "dsym-dir=">, Alias;
 def dumpmachine : Flag<["-"], "dumpmachine">;
 def dumpspecs : Flag<["-"], "dumpspecs">, Flags<[Unsupported]>;
 def dumpversion : Flag<["-"], "dumpversion">;


Index: llvm/cmake/modules/AddLLVM.cmake
===
--- llvm/cmake/modules/AddLLVM.cmake
+++ llvm/cmake/modules/AddLLVM.cmake
@@ -1981,21 +1981,29 @@
 set_property(TARGET ${name} A

[PATCH] D85214: [OpenMP] Ensure testing for versions 4.5 and default - Part 3

[Saiyedul Islam via Phabricator via cfe-commits]

saiislam added a comment.

This patch updates 101 out 320 test files. Remaining will be posted as a 
separate patch to ease review.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85214

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

[PATCH] D82575: [OpenMP] OpenMP Clang tests without 50 version string after upgrading to 5.0

[Saiyedul Islam via Phabricator via cfe-commits]

saiislam abandoned this revision.
saiislam added a comment.

Abandoning in favor of D85214 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82575

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

[PATCH] D84844: [OpenMP] Ensure testing for versions 4.5 and default - Part 1

[Saiyedul Islam via Phabricator via cfe-commits]

saiislam added a comment.

Next two (independent) parts are: D85150  and 
D85214 . More to come.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84844

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

[clang] 5e0a9dc - Separate code-block tag with a newline to fix code snippet html output

[Simon Pilgrim via cfe-commits]

Author: Simon Pilgrim
Date: 2020-08-04T16:36:00+01:00
New Revision: 5e0a9dc0ad7704b7c49995101629010f5ff98cd2

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

LOG: Separate code-block tag with a newline to fix code snippet html output

Added: 


Modified: 
clang/include/clang/Basic/AttrDocs.td

Removed: 




diff  --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index b9fcf9af323b..76a075a97ee1 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -1084,6 +1084,7 @@ not made control-dependent on any additional values, 
e.g., unrolling a loop
 executed by all work items.
 
 Sample usage:
+
 .. code-block:: c
 
   void convfunc(void) __attribute__((convergent));



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

[PATCH] D83242: [clang][BPF] support type exist/size and enum exist/value relocations

[Yonghong Song 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 rG6d6750696400: [clang][BPF] support type exist/size and enum 
exist/value relocations (authored by yonghong-song).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83242

Files:
  clang/include/clang/Basic/BuiltinsBPF.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/builtins-bpf-preserve-field-info-3.c
  clang/test/CodeGen/builtins-bpf-preserve-field-info-4.c
  clang/test/Sema/builtins-bpf.c
  llvm/include/llvm/IR/IntrinsicsBPF.td

Index: llvm/include/llvm/IR/IntrinsicsBPF.td
===
--- llvm/include/llvm/IR/IntrinsicsBPF.td
+++ llvm/include/llvm/IR/IntrinsicsBPF.td
@@ -26,4 +26,10 @@
   def int_bpf_btf_type_id : GCCBuiltin<"__builtin_bpf_btf_type_id">,
   Intrinsic<[llvm_i32_ty], [llvm_any_ty, llvm_any_ty, llvm_i64_ty],
   [IntrNoMem]>;
+  def int_bpf_preserve_type_info : GCCBuiltin<"__builtin_bpf_preserve_type_info">,
+  Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i64_ty],
+  [IntrNoMem]>;
+  def int_bpf_preserve_enum_value : GCCBuiltin<"__builtin_bpf_preserve_enum_value">,
+  Intrinsic<[llvm_i64_ty], [llvm_i32_ty, llvm_ptr_ty, llvm_i64_ty],
+  [IntrNoMem]>;
 }
Index: clang/test/Sema/builtins-bpf.c
===
--- clang/test/Sema/builtins-bpf.c
+++ clang/test/Sema/builtins-bpf.c
@@ -1,7 +1,28 @@
 // RUN: %clang_cc1 -x c -triple bpf-pc-linux-gnu -dwarf-version=4 -fsyntax-only -verify %s
 
-struct s { int a; int b[4]; int c:1; };
-union u { int a; int b[4]; int c:1; };
+struct s {
+  int a;
+  int b[4];
+  int c:1;
+};
+union u {
+  int a;
+  int b[4];
+  int c:1;
+};
+typedef struct {
+  int a;
+  int b;
+} __t;
+typedef int (*__f)(void);
+enum AA {
+  VAL1 = 10,
+  VAL2 = 0x8000UL,
+};
+typedef enum {
+  VAL10 = 10,
+  VAL11 = 11,
+} __BB;
 
 unsigned invalid1(const int *arg) {
   return __builtin_preserve_field_info(arg, 1); // expected-error {{__builtin_preserve_field_info argument 1 not a field access}}
@@ -46,3 +67,38 @@
 unsigned invalid11(struct s *arg, int info_kind) {
   return __builtin_preserve_field_info(arg->a, info_kind); // expected-error {{__builtin_preserve_field_info argument 2 not a constant}}
 }
+
+unsigned valid12() {
+  const struct s t;
+  return __builtin_preserve_type_info(t, 0) +
+ __builtin_preserve_type_info(*(struct s *)0, 1);
+}
+
+unsigned valid13() {
+  __t t;
+  return __builtin_preserve_type_info(t, 1) +
+ __builtin_preserve_type_info(*(__t *)0, 0);
+}
+
+unsigned valid14() {
+  enum AA t;
+  return __builtin_preserve_type_info(t, 0) +
+ __builtin_preserve_type_info(*(enum AA *)0, 1);
+}
+
+unsigned valid15() {
+  return __builtin_preserve_enum_value(*(enum AA *)VAL1, 1) +
+ __builtin_preserve_enum_value(*(enum AA *)VAL2, 1);
+}
+
+unsigned invalid16() {
+  return __builtin_preserve_enum_value(*(enum AA *)0, 1); // expected-error {{__builtin_preserve_enum_value argument 1 invalid}}
+}
+
+unsigned invalid17() {
+  return __builtin_preserve_enum_value(*(enum AA *)VAL10, 1); // expected-error {{__builtin_preserve_enum_value argument 1 invalid}}
+}
+
+unsigned invalid18(struct s *arg) {
+  return __builtin_preserve_type_info(arg->a + 2, 0); // expected-error {{__builtin_preserve_type_info argument 1 invalid}}
+}
Index: clang/test/CodeGen/builtins-bpf-preserve-field-info-4.c
===
--- /dev/null
+++ clang/test/CodeGen/builtins-bpf-preserve-field-info-4.c
@@ -0,0 +1,32 @@
+// REQUIRES: bpf-registered-target
+// RUN: %clang -target bpf -emit-llvm -S -g %s -o - | FileCheck %s
+
+#define _(x, y) (__builtin_preserve_enum_value((x), (y)))
+
+enum AA {
+  VAL1 = 2,
+  VAL2 = 0x8000UL,
+};
+typedef enum { VAL10 = -2, VAL11 = 0x8000, }  __BB;
+
+unsigned unit1() {
+  return _(*(enum AA *)VAL1, 0) + _(*(__BB *)VAL10, 1);
+}
+
+unsigned unit2() {
+  return _(*(enum AA *)VAL2, 0) + _(*(__BB *)VAL11, 1);
+}
+
+// CHECK: @0 = private unnamed_addr constant [7 x i8] c"VAL1:2\00", align 1
+// CHECK: @1 = private unnamed_addr constant [9 x i8] c"VAL10:-2\00", align 1
+// CHECK: @2 = private unnamed_addr constant [17 x i8] c"VAL2:-2147483648\00", align 1
+// CHECK: @3 = private unnamed_addr constant [17 x i8] c"VAL11:4294934528\00", align 1
+
+// CHECK: call i64 @llvm.bpf.preserve.enum.value(i32 0, i8* getelementptr inbounds ([7 x i8], [7 x i8]* @0, i32 0, i32 0), i64 0), !dbg !{{[0-9]+}}, !llvm.preserve.access.index ![[ENUM_AA:[0-9]+]]
+// CHECK: call i64 @llvm.bpf.preserve.enum.value(i32 1, i8* getelementptr inbounds ([9 x i8], [9 x i8]* @1, i32 0, i32 0), i64 1), !dbg !

[clang] 6d67506 - [clang][BPF] support type exist/size and enum exist/value relocations

[Yonghong Song via cfe-commits]

Author: Yonghong Song
Date: 2020-08-04T08:39:53-07:00
New Revision: 6d6750696400e7ce988d66a1a00e1d0cb32815f8

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

LOG: [clang][BPF] support type exist/size and enum exist/value relocations

This patch added the following additional compile-once
run-everywhere (CO-RE) relocations:
  - existence/size of typedef, struct/union or enum type
  - enum value and enum value existence

These additional relocations will make CO-RE bpf programs more
adaptive for potential kernel internal data structure changes.

For existence/size relocations, the following two code patterns
are supported:
  1. uint32_t __builtin_preserve_type_info(*( *)0, flag);
  2.  var;
 uint32_t __builtin_preserve_field_info(var, flag);
flag = 0 for existence relocation and flag = 1 for size relocation.

For enum value existence and enum value relocations, the following code
pattern is supported:
  uint64_t __builtin_preserve_enum_value(*( *),
 flag);
flag = 0 means existence relocation and flag = 1 for enum value.
relocation. In the above  can be an enum type or
a typedef to enum type. The  needs to be an enumerator
value from the same enum type. The return type is uint64_t to
permit potential 64bit enumerator values.

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

Added: 
clang/test/CodeGen/builtins-bpf-preserve-field-info-3.c
clang/test/CodeGen/builtins-bpf-preserve-field-info-4.c

Modified: 
clang/include/clang/Basic/BuiltinsBPF.def
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/CodeGen/CGBuiltin.cpp
clang/lib/Sema/SemaChecking.cpp
clang/test/Sema/builtins-bpf.c
llvm/include/llvm/IR/IntrinsicsBPF.td

Removed: 




diff  --git a/clang/include/clang/Basic/BuiltinsBPF.def 
b/clang/include/clang/Basic/BuiltinsBPF.def
index 237e9dc8784b..04b45a52cbe7 100644
--- a/clang/include/clang/Basic/BuiltinsBPF.def
+++ b/clang/include/clang/Basic/BuiltinsBPF.def
@@ -23,5 +23,11 @@ TARGET_BUILTIN(__builtin_preserve_field_info, "Ui.", "t", "")
 // Get BTF type id.
 TARGET_BUILTIN(__builtin_btf_type_id, "Ui.", "t", "")
 
+// Get type information.
+TARGET_BUILTIN(__builtin_preserve_type_info, "Ui.", "t", "")
+
+// Preserve enum value.
+TARGET_BUILTIN(__builtin_preserve_enum_value, "Li.", "t", "")
+
 #undef BUILTIN
 #undef TARGET_BUILTIN

diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 054b81c4a72b..7bcff3eb4d8c 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -10865,6 +10865,14 @@ def err_preserve_field_info_not_const: Error<
   "__builtin_preserve_field_info argument %0 not a constant">;
 def err_btf_type_id_not_const: Error<
   "__builtin_btf_type_id argument %0 not a constant">;
+def err_preserve_type_info_invalid : Error<
+  "__builtin_preserve_type_info argument %0 invalid">;
+def err_preserve_type_info_not_const: Error<
+  "__builtin_preserve_type_info argument %0 not a constant">;
+def err_preserve_enum_value_invalid : Error<
+  "__builtin_preserve_enum_value argument %0 invalid">;
+def err_preserve_enum_value_not_const: Error<
+  "__builtin_preserve_enum_value argument %0 not a constant">;
 
 def err_bit_cast_non_trivially_copyable : Error<
   "__builtin_bit_cast %select{source|destination}0 type must be trivially 
copyable">;

diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index 2ef164b8b65a..18911184aa41 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -10921,9 +10921,16 @@ Value 
*CodeGenFunction::EmitAArch64BuiltinExpr(unsigned BuiltinID,
 Value *CodeGenFunction::EmitBPFBuiltinExpr(unsigned BuiltinID,
const CallExpr *E) {
   assert((BuiltinID == BPF::BI__builtin_preserve_field_info ||
-  BuiltinID == BPF::BI__builtin_btf_type_id) &&
+  BuiltinID == BPF::BI__builtin_btf_type_id ||
+  BuiltinID == BPF::BI__builtin_preserve_type_info ||
+  BuiltinID == BPF::BI__builtin_preserve_enum_value) &&
  "unexpected BPF builtin");
 
+  // A sequence number, injected into IR builtin functions, to
+  // prevent CSE given the only 
diff erence of the funciton
+  // may just be the debuginfo metadata.
+  static uint32_t BuiltinSeqNum;
+
   switch (BuiltinID) {
   default:
 llvm_unreachable("Unexpected BPF builtin");
@@ -11016,6 +11023,63 @@ Value *CodeGenFunction::EmitBPFBuiltinExpr(unsigned 
BuiltinID,
 Fn->setMetadata(LLVMContext::MD_preserve_access_index, DbgInfo);
 return Fn;
   }
+  case BPF::BI__builtin_preserve_type_info: {
+if (!getDebugInfo()) {
+  CGM.Error(E->getExprLoc(), "using buil

[PATCH] D85191: [AST] Get field size in chars rather than bits in RecordLayoutBuilder.

[Bevin Hansson via Phabricator via cfe-commits]

ebevhan added inline comments.



Comment at: clang/lib/AST/RecordLayoutBuilder.cpp:1841
   auto setDeclInfo = [&](bool IsIncompleteArrayType) {
-TypeInfo TI = Context.getTypeInfo(D->getType());
-FieldAlign = Context.toCharUnitsFromBits(TI.Align);
+auto TI = Context.getTypeInfoInChars(D->getType());
+FieldAlign = TI.second;

Xiangling_L wrote:
> In most cases, `getTypeInfoInChars` invokes `getTypeInfo` underneath. So to 
> make people be careful about this, I would suggest to leave a comment 
> explaining/claiming we have to call `getTypeInfoInChars` here. And also maybe 
> adding a testcase to guard the scenario you were talking about would be 
> helpful to prevent someone to use `getTypeInfo` here in the future.
I can do that.

I honestly don't think it would be a bad idea to add an assertion to 
toCharUnitsFromBits that checks for non-bytesize-multiple amounts. I wonder how 
much would fail if I did that, though.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85191

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

[PATCH] D84412: [clang][Driver] Don't hardcode --as-needed/--no-as-needed on Illumos

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

#clang  does not have many people. You 
might need to add people explicitly..




Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:633
 
+static const char *getAsNeededOption(const ToolChain &TC, bool ignore) {
+  // FIXME: Need to handle GNU ld on Solaris.

`ignore` seems strange. How about `start`?



Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:634
+static const char *getAsNeededOption(const ToolChain &TC, bool ignore) {
+  // FIXME: Need to handle GNU ld on Solaris.
+  if (TC.getTriple().isOSSolaris())

Can you improve the comment to mention that this is to work around illumnos ld?



Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:636
+  if (TC.getTriple().isOSSolaris())
+return ignore ? "-zignore" : "-zrecord";
+  else

I'll assume that `-zignore` has semantics similar to --as-needed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84412

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

[PATCH] D85191: [AST] Get field size in chars rather than bits in RecordLayoutBuilder.

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

> This is not ideal, since it makes the

calculations char size dependent, and breaks for sizes that
are not a multiple of the char size.

How can we have a non-bitfield member whose size is not a multiple of the size 
of a char?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85191

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

[PATCH] D84887: [OPENMP]Fix codegen for is_device_ptr component, captured by reference.

[Alexey Bataev via Phabricator via cfe-commits]

ABataev updated this revision to Diff 282942.
ABataev added a comment.

Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84887

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/test/OpenMP/target_is_device_ptr_codegen.cpp


Index: clang/test/OpenMP/target_is_device_ptr_codegen.cpp
===
--- clang/test/OpenMP/target_is_device_ptr_codegen.cpp
+++ clang/test/OpenMP/target_is_device_ptr_codegen.cpp
@@ -285,4 +285,42 @@
   ++arg;
 }
 #endif
+///==///
+// RUN: %clang_cc1 -DCK3 -verify -fopenmp 
-fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple 
powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck %s --check-prefix 
CK3 --check-prefix CK3-64
+// RUN: %clang_cc1 -DCK3 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu 
-x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ 
-triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s 
-emit-llvm -o - | FileCheck %s  --check-prefix CK3 --check-prefix CK3-64
+// RUN: %clang_cc1 -DCK3 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu 
-x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck %s  
--check-prefix CK3 --check-prefix CK3-32
+// RUN: %clang_cc1 -DCK3 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ 
-std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple 
i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | 
FileCheck %s  --check-prefix CK3 --check-prefix CK3-32
+
+// RUN: %clang_cc1 -DCK3 -verify -fopenmp-simd 
-fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple 
powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck --check-prefix 
SIMD-ONLY1 %s
+// RUN: %clang_cc1 -DCK3 -fopenmp-simd 
-fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple 
powerpc64le-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x 
c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s 
-emit-llvm -o - | FileCheck --check-prefix SIMD-ONLY1 %s
+// RUN: %clang_cc1 -DCK3 -verify -fopenmp-simd 
-fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown 
-emit-llvm %s -o - | FileCheck --check-prefix SIMD-ONLY1 %s
+// RUN: %clang_cc1 -DCK3 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x 
c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ 
-triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm 
-o - | FileCheck --check-prefix SIMD-ONLY1 %s
+// SIMD-ONLY1-NOT: {{__kmpc|__tgt}}
+#ifdef CK3
+
+
+// CK3-DAG: [[SIZES:@.+]] = {{.+}}constant [1 x i[[SZ:64|32]]] [i{{64|32}} 
{{8|4}}]
+// OMP_MAP_TARGET_PARAM = 0x20 | OMP_MAP_TO = 0x1 = 0x21
+// CK3-DAG: [[TYPES:@.+]] = {{.+}}constant [1 x i64] [i64 [[#0x21]]]
+void bar(){
+  __attribute__((aligned(64))) double *ptr;
+  // CK3-DAG: call i32 @__tgt_target_mapper(i64 {{.+}}, i8* {{.+}}, i32 1, 
i8** [[BPGEP:%[0-9]+]], i8** [[PGEP:%[0-9]+]], {{.+}}[[SIZES]]{{.+}}, 
{{.+}}[[TYPES]]{{.+}}, i8** null)
+  // CK3-DAG: [[BPGEP]] = getelementptr inbounds {{.+}}[[BPS:%[^,]+]], i32 0, 
i32 0
+  // CK3-DAG: [[PGEP]] = getelementptr inbounds {{.+}}[[PS:%[^,]+]], i32 0, 
i32 0
+  // CK3-DAG: [[BP1:%.+]] = getelementptr inbounds {{.+}}[[BPS]], i32 0, i32 0
+  // CK3-DAG: [[P1:%.+]] = getelementptr inbounds {{.+}}[[PS]], i32 0, i32 0
+  // CK3-DAG: [[CBP1:%.+]] = bitcast i8** [[BP1]] to double***
+  // CK3-DAG: [[CP1:%.+]] = bitcast i8** [[P1]] to double***
+  // CK3-DAG: store double** [[PTR:%.+]], double*** [[CBP1]]
+  // CK3-DAG: store double** [[PTR]], double*** [[CP1]]
+
+  // CK3: call void [[KERNEL:@.+]](double** [[PTR]])
+#pragma omp target is_device_ptr(ptr)
+  *ptr = 0;
+}
+#endif
 #endif
Index: clang/lib/CodeGen/CGOpenMPRuntime.cpp
===
--- clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -8497,10 +8497,12 @@
 if (DevPointersMap.count(VD)) {
   CombinedInfo.BasePointers.emplace_back(Arg, VD);
   CombinedInfo.Pointers.push_back(Arg);
-  CombinedInfo.Sizes.push_back(
-  
CGF.Builder.CreateIntCast(CGF.getTypeSize(CGF.getContext().VoidPtrTy),
-CGF.Int64Ty, /*isSigned=*/true));
-  CombinedInfo.Types.push_back(OMP_MAP_LITERAL | OMP_MAP_TARGET_PARAM);
+  CombinedInfo.Sizes.push_back(CGF.Builder.CreateIntCast(
+  CGF.getTypeSize(CGF.getContext().VoidPtrTy), CGF.Int64Ty,
+  /*isSigned=*/true));
+  CombinedInfo.Types.push_back(
+  (Cap->capturesVariable() ? OMP_MAP_TO : OMP_

[PATCH] D84534: [AIX] Static init frontend recovery and backend support

[Xiangling Liao via Phabricator via cfe-commits]

Xiangling_L marked 6 inline comments as done.
Xiangling_L added inline comments.



Comment at: clang/lib/CodeGen/CodeGenModule.h:1058
+  /// Add an sterm finalizer to its own llvm.global_dtors entry.
+  void AddCXXStermFinalizerToGlobalDtor(llvm::Function *StermFinalizer,
+int Priority) {

jasonliu wrote:
> This wrapper seems redundant. Calling ` AddGlobalDtor(StermFinalizer, 
> Priority);` directly from the callee side already convey what we are trying 
> to achieve here. 
I added this wrapper function to keep the symmetry between `AddGlobalCtor` and 
`AddGlobalDtor`. They are private functions within `CodeGenModule` class. And I 
feel it's kinda weird to only move `AddGlobalDtor` to a public function.



Comment at: clang/lib/CodeGen/ItaniumCXXABI.cpp:4602
+llvm::report_fatal_error(
+"prioritized __sinit and __sterm functions are not yet supported");
+  else if (isTemplateInstantiation(D.getTemplateSpecializationKind()) ||

jasonliu wrote:
> Could we trigger this error? If so, could we have a test for it? 
I should've put an assertion here. The init priority attribute has been 
disabled on AIX in the previous patch.



Comment at: llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp:1874
+  }
+  emitSpecialLLVMGlobal(&G);
+  continue;

jasonliu wrote:
> Have some suggestion on structure backend code change:
> 
> 1. Remove `isSpecialLLVMGlobalArrayForStaticInit` and 
> `isSpecialLLVMGlobalArrayToSkip`, and call `emitSpecialLLVMGlobal` directly 
> instead. This would handle all the `llvm.` variable for us. We would need do 
> early return for names start with `llvm.` in emitGlobalVariable as well, 
> since they are all handled here.
> 
> 2. We could override emitXXStructorList because how XCOFF handle the list is 
> vastly different than the other target. We could make the common part(i.e. 
> processing and sorting) a utility function, say "preprocessStructorList".
> 
> 3. It's not necessary to use the same name `emitXXStructor` if the interface 
> is different. It might not provide much help when we kinda know no other 
> target is going to use this interface. So we could turn it into a lambda 
> inside of the overrided emitXXStructorList, or simply no need for a new 
> function because the logic is fairly straightforward.
> 
1. As we discussed offline, we would leave the handling of `llvm.used` and 
`llvm.metadata` later and don't include them in the scope of this patch.


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

https://reviews.llvm.org/D84534

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

[PATCH] D81083: [Clang] Allow "vector_size" applied to Booleans

[Richard Sandiford via Phabricator via cfe-commits]

rsandifo-arm added inline comments.



Comment at: clang/docs/LanguageExtensions.rst:473
+architectures.  The size parameter of a boolean vector type is the number of
+bits in the vector (for all non-bool vectors, the number refers to the number
+of bytes in the vector).

simoll wrote:
> rsandifo-arm wrote:
> > simoll wrote:
> > > rsandifo-arm wrote:
> > > > simoll wrote:
> > > > > lenary wrote:
> > > > > > It would be nice if this aside about non-bool vectors was more 
> > > > > > prominently displayed - it's something I hadn't realised before.
> > > > > Yep. that caught me by surprise too. I'll move that sentence to the 
> > > > > paragraph about GCC vectors above.
> > > > Sorry for the extremely late comment.  Like @lenary I hadn't thought 
> > > > about this.  I'd assumed that the vector woiuld still be a multiple of 
> > > > 8 bits in size, but I agree that's probably too restrictive to be the 
> > > > only option available.
> > > > 
> > > > In that case, would it make sense to add a separate attribute instead?  
> > > > I think it's too surprising to change the units of the existing 
> > > > attribute based on the element type.  Perhaps we should even make it 
> > > > take two parameters: the total number of elements, and the number of 
> > > > bits per element.  That might be more natural for some AVX and SVE 
> > > > combinations.  We wouldn't need to supporrt all combinations from the 
> > > > outset, it's just a question whether we should make the syntax general 
> > > > enough to support it in future.
> > > > 
> > > > Perhaps we could do both: support `vector_size` for `bool` using byte 
> > > > sizes (and not allowing subbyte vector lengths), and add a new, more 
> > > > general attribute that allows subbyte lengths and explicit subbyte 
> > > > element sizes.
> > > > In that case, would it make sense to add a separate attribute instead? 
> > > > I think it's too surprising to change the units of the existing 
> > > > attribute based on the element type. Perhaps we should even make it 
> > > > take two parameters: the total number of elements, and the number of 
> > > > bits per element. That might be more natural for some AVX and SVE 
> > > > combinations. We wouldn't need to supporrt all combinations from the 
> > > > outset, it's just a question whether we should make the syntax general 
> > > > enough to support it in future.
> > > 
> > > I guess adding a new attribute makes sense mid to long term. For now, i'd 
> > > want something that just does the job... ie, what is proposed here. We 
> > > should absolutely document the semantics of vector_size properly.. it 
> > > already is counterintuitive (broken, if you ask me).
> > > 
> > > 
> > > > Perhaps we could do both: support vector_size for bool using byte sizes 
> > > > (and not allowing subbyte vector lengths), and add a new, more general 
> > > > attribute that allows subbyte lengths and explicit subbyte element 
> > > > sizes.
> > > 
> > > Disallowing subbyte bool vectors actually makes this more complicated 
> > > because these types are produced implicitly by compares of (legal) vector 
> > > types. Consider this:
> > > 
> > >   typedef int int3 __attribute__((vector_size(3 * sizeof(int;
> > >   int3 A = ...;
> > >   int3 B = ...;
> > >   auto Z = A < B; // vector compare yielding a `bool 
> > > vector_size(3)`-typed value.
> > > 
> > > 
> > > Regarding your proposal for a separate subbyte element size and subbyte 
> > > length, that may or may not make sense but it is surely something that 
> > > should be discussed more broadly with its own proposal.
> > > > Perhaps we could do both: support vector_size for bool using byte sizes 
> > > > (and not allowing subbyte vector lengths), and add a new, more general 
> > > > attribute that allows subbyte lengths and explicit subbyte element 
> > > > sizes.
> > > 
> > > Disallowing subbyte bool vectors actually makes this more complicated 
> > > because these types are produced implicitly by compares of (legal) vector 
> > > types. Consider this:
> > > 
> > >   typedef int int3 __attribute__((vector_size(3 * sizeof(int;
> > >   int3 A = ...;
> > >   int3 B = ...;
> > >   auto Z = A < B; // vector compare yielding a `bool 
> > > vector_size(3)`-typed value.
> > 
> > Yeah, I understand the need for some way of creating subbyte vectors.  I'm 
> > just not sure using the existing `vector_size` attribute would be the best 
> > choice for that case.  I.e. the objection wasn't based on “keeping things 
> > simple” but more “keeping things consistent“.
> > 
> > That doesn't mean that the above code should be invalid.  It just means 
> > that it wouldn't be possible to write the type of Z using the existing 
> > `vector_size` attribute.
> > 
> > (FWIW, `vector_size` was originally a GNUism and GCC stil requires vector 
> > sizes to be a power of 2, but I realise that isn't relevant here.  And the 
> > same principle applies with s/3/4 in the above example anyw

[PATCH] D84600: [Analyzer] Support note tags for smart ptr checker

[Nithin VR via Phabricator via cfe-commits]

vrnithinkumar added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/SmartPtrChecker.cpp:110
+  SmartPtrChecker *Checker = Mgr.registerChecker();
+  NullDereferenceBugTypePtr = &Checker->NullDereferenceBugType;
 }

NoQ wrote:
> Wait, i don't understand again. You're taking the bug type from that checker 
> and using it in that checker. Why did you need to make it global? I thought 
> your problem was about capturing the bug type from the //raw// null 
> dereference checker?
> Wait, i don't understand again. You're taking the bug type from that checker 
> and using it in that checker. Why did you need to make it global? I thought 
> your problem was about capturing the bug type from the //raw// null 
> dereference checker?

The check for bug type is in `SmartPtrModeling` but the bug type is defined in 
`SmartPtrChecker`



Comment at: clang/lib/StaticAnalyzer/Checkers/SmartPtrChecker.cpp:95-96
+
+  const auto *RecordDecl = MethodDecl->getParent();
+  if (RecordDecl && RecordDecl->getDeclName().isIdentifier()) {
+OS << " of type '" << RecordDecl->getQualifiedNameAsString() << "'";

NoQ wrote:
> vrnithinkumar wrote:
> > NoQ wrote:
> > > Aha, this time you checked for anonymous declarations! Good.
> > > 
> > > That said, i'm not sure type is actually useful for this warning, because 
> > > they're roughly all the same.
> > Okay. I was trying to be consistent with `MoveChecker`.
> > Just removed smart pointer type.
> These were important in `MoveChecker` because use-after-move rules for smart 
> pointers are different from use-after-move rules of any other class in the 
> standard library and the checker has to behave differently 
> (https://wiki.sei.cmu.edu/confluence/x/O3s-BQ).
Oh
That makes sense.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84600

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

[PATCH] D85218: In clang-tidy base checks prevent anonymous functions from triggering assertions

[Bogdan Serea via Phabricator via cfe-commits]

bogser01 created this revision.
bogser01 added reviewers: djasper, alexfh.
bogser01 added a project: clang-tools-extra.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
bogser01 requested review of this revision.

Skeleton checks generated by clang-tidy add_check.py cause assertions to fail 
when run over anonymous functions(lambda functions). This patch introduces an 
additional check to verify that the target function is not anonymous before 
calling getName(). 
The code snippet from the [[ 
https://clang.llvm.org/extra/clang-tidy/Contributing.html | clang-tidy tutorial 
 ]]is also updated.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D85218

Files:
  clang-tools-extra/clang-tidy/add_new_check.py
  clang-tools-extra/docs/clang-tidy/Contributing.rst


Index: clang-tools-extra/docs/clang-tidy/Contributing.rst
===
--- clang-tools-extra/docs/clang-tidy/Contributing.rst
+++ clang-tools-extra/docs/clang-tidy/Contributing.rst
@@ -201,8 +201,8 @@
   }
 
   void AwesomeFunctionNamesCheck::check(const MatchFinder::MatchResult 
&Result) {
-const auto *MatchedDecl = Result.Nodes.getNodeAs("x");
-if (MatchedDecl->getName().startswith("awesome_"))
+const auto *MatchedDecl = Result.Nodes.getNodeAs("x");
+if ((!MatchedDecl->getIdentifier()) || 
MatchedDecl->getName().startswith("awesome_"))
   return;
 diag(MatchedDecl->getLocation(), "function %0 is insufficiently awesome")
 << MatchedDecl
Index: clang-tools-extra/clang-tidy/add_new_check.py
===
--- clang-tools-extra/clang-tidy/add_new_check.py
+++ clang-tools-extra/clang-tidy/add_new_check.py
@@ -136,7 +136,7 @@
 void %(check_name)s::check(const MatchFinder::MatchResult &Result) {
   // FIXME: Add callback implementation.
   const auto *MatchedDecl = Result.Nodes.getNodeAs("x");
-  if (MatchedDecl->getName().startswith("awesome_"))
+  if ((!MatchedDecl->getIdentifier()) || 
MatchedDecl->getName().startswith("awesome_"))
 return;
   diag(MatchedDecl->getLocation(), "function %%0 is insufficiently awesome")
   << MatchedDecl;


Index: clang-tools-extra/docs/clang-tidy/Contributing.rst
===
--- clang-tools-extra/docs/clang-tidy/Contributing.rst
+++ clang-tools-extra/docs/clang-tidy/Contributing.rst
@@ -201,8 +201,8 @@
   }
 
   void AwesomeFunctionNamesCheck::check(const MatchFinder::MatchResult &Result) {
-const auto *MatchedDecl = Result.Nodes.getNodeAs("x");
-if (MatchedDecl->getName().startswith("awesome_"))
+const auto *MatchedDecl = Result.Nodes.getNodeAs("x");
+if ((!MatchedDecl->getIdentifier()) || MatchedDecl->getName().startswith("awesome_"))
   return;
 diag(MatchedDecl->getLocation(), "function %0 is insufficiently awesome")
 << MatchedDecl
Index: clang-tools-extra/clang-tidy/add_new_check.py
===
--- clang-tools-extra/clang-tidy/add_new_check.py
+++ clang-tools-extra/clang-tidy/add_new_check.py
@@ -136,7 +136,7 @@
 void %(check_name)s::check(const MatchFinder::MatchResult &Result) {
   // FIXME: Add callback implementation.
   const auto *MatchedDecl = Result.Nodes.getNodeAs("x");
-  if (MatchedDecl->getName().startswith("awesome_"))
+  if ((!MatchedDecl->getIdentifier()) || MatchedDecl->getName().startswith("awesome_"))
 return;
   diag(MatchedDecl->getLocation(), "function %%0 is insufficiently awesome")
   << MatchedDecl;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D81083: [Clang] Allow "vector_size" applied to Booleans

[Simon Moll via Phabricator via cfe-commits]

simoll added inline comments.



Comment at: clang/docs/LanguageExtensions.rst:473
+architectures.  The size parameter of a boolean vector type is the number of
+bits in the vector (for all non-bool vectors, the number refers to the number
+of bytes in the vector).

rsandifo-arm wrote:
> simoll wrote:
> > rsandifo-arm wrote:
> > > simoll wrote:
> > > > rsandifo-arm wrote:
> > > > > simoll wrote:
> > > > > > lenary wrote:
> > > > > > > It would be nice if this aside about non-bool vectors was more 
> > > > > > > prominently displayed - it's something I hadn't realised before.
> > > > > > Yep. that caught me by surprise too. I'll move that sentence to the 
> > > > > > paragraph about GCC vectors above.
> > > > > Sorry for the extremely late comment.  Like @lenary I hadn't thought 
> > > > > about this.  I'd assumed that the vector woiuld still be a multiple 
> > > > > of 8 bits in size, but I agree that's probably too restrictive to be 
> > > > > the only option available.
> > > > > 
> > > > > In that case, would it make sense to add a separate attribute 
> > > > > instead?  I think it's too surprising to change the units of the 
> > > > > existing attribute based on the element type.  Perhaps we should even 
> > > > > make it take two parameters: the total number of elements, and the 
> > > > > number of bits per element.  That might be more natural for some AVX 
> > > > > and SVE combinations.  We wouldn't need to supporrt all combinations 
> > > > > from the outset, it's just a question whether we should make the 
> > > > > syntax general enough to support it in future.
> > > > > 
> > > > > Perhaps we could do both: support `vector_size` for `bool` using byte 
> > > > > sizes (and not allowing subbyte vector lengths), and add a new, more 
> > > > > general attribute that allows subbyte lengths and explicit subbyte 
> > > > > element sizes.
> > > > > In that case, would it make sense to add a separate attribute 
> > > > > instead? I think it's too surprising to change the units of the 
> > > > > existing attribute based on the element type. Perhaps we should even 
> > > > > make it take two parameters: the total number of elements, and the 
> > > > > number of bits per element. That might be more natural for some AVX 
> > > > > and SVE combinations. We wouldn't need to supporrt all combinations 
> > > > > from the outset, it's just a question whether we should make the 
> > > > > syntax general enough to support it in future.
> > > > 
> > > > I guess adding a new attribute makes sense mid to long term. For now, 
> > > > i'd want something that just does the job... ie, what is proposed here. 
> > > > We should absolutely document the semantics of vector_size properly.. 
> > > > it already is counterintuitive (broken, if you ask me).
> > > > 
> > > > 
> > > > > Perhaps we could do both: support vector_size for bool using byte 
> > > > > sizes (and not allowing subbyte vector lengths), and add a new, more 
> > > > > general attribute that allows subbyte lengths and explicit subbyte 
> > > > > element sizes.
> > > > 
> > > > Disallowing subbyte bool vectors actually makes this more complicated 
> > > > because these types are produced implicitly by compares of (legal) 
> > > > vector types. Consider this:
> > > > 
> > > >   typedef int int3 __attribute__((vector_size(3 * sizeof(int;
> > > >   int3 A = ...;
> > > >   int3 B = ...;
> > > >   auto Z = A < B; // vector compare yielding a `bool 
> > > > vector_size(3)`-typed value.
> > > > 
> > > > 
> > > > Regarding your proposal for a separate subbyte element size and subbyte 
> > > > length, that may or may not make sense but it is surely something that 
> > > > should be discussed more broadly with its own proposal.
> > > > > Perhaps we could do both: support vector_size for bool using byte 
> > > > > sizes (and not allowing subbyte vector lengths), and add a new, more 
> > > > > general attribute that allows subbyte lengths and explicit subbyte 
> > > > > element sizes.
> > > > 
> > > > Disallowing subbyte bool vectors actually makes this more complicated 
> > > > because these types are produced implicitly by compares of (legal) 
> > > > vector types. Consider this:
> > > > 
> > > >   typedef int int3 __attribute__((vector_size(3 * sizeof(int;
> > > >   int3 A = ...;
> > > >   int3 B = ...;
> > > >   auto Z = A < B; // vector compare yielding a `bool 
> > > > vector_size(3)`-typed value.
> > > 
> > > Yeah, I understand the need for some way of creating subbyte vectors.  
> > > I'm just not sure using the existing `vector_size` attribute would be the 
> > > best choice for that case.  I.e. the objection wasn't based on “keeping 
> > > things simple” but more “keeping things consistent“.
> > > 
> > > That doesn't mean that the above code should be invalid.  It just means 
> > > that it wouldn't be possible to write the type of Z using the existing 
> > > `vector_size` attribute.
> > > 
> > > (FWIW, `vector_size` was origi

[PATCH] D80858: [CUDA][HIP] Support accessing static device variable in host code for -fno-gpu-rdc

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl updated this revision to Diff 282952.
yaxunl retitled this revision from "[CUDA][HIP] Support accessing static device 
variable in host code" to "[CUDA][HIP] Support accessing static device variable 
in host code for -fno-gpu-rdc".
yaxunl edited the summary of this revision.
yaxunl added a comment.

revised for -fno-gpu-rdc case by Michael's comments.


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

https://reviews.llvm.org/D80858

Files:
  clang/include/clang/AST/ASTContext.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/CodeGenCUDA/static-device-var-no-rdc.cu

Index: clang/test/CodeGenCUDA/static-device-var-no-rdc.cu
===
--- /dev/null
+++ clang/test/CodeGenCUDA/static-device-var-no-rdc.cu
@@ -0,0 +1,86 @@
+// REQUIRES: x86-registered-target
+// REQUIRES: amdgpu-registered-target
+
+// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -fcuda-is-device \
+// RUN:   -emit-llvm -o - -x hip %s | FileCheck \
+// RUN:   -check-prefixes=DEV %s
+
+// RUN: %clang_cc1 -triple x86_64-gnu-linux \
+// RUN:   -emit-llvm -o - -x hip %s | FileCheck \
+// RUN:   -check-prefixes=HOST %s
+
+#include "Inputs/cuda.h"
+
+// Test function scope static device variable, which should not be externalized.
+// DEV-DAG: @_ZZ6kernelPiPPKiE1w = internal addrspace(4) constant i32 1
+
+// Check a static device variable referenced by host function is externalized.
+// DEV-DAG: @_ZL1x = addrspace(1) externally_initialized global i32 0
+// HOST-DAG: @_ZL1x = internal global i32 undef
+// HOST-DAG: @[[DEVNAMEX:[0-9]+]] = {{.*}}c"_ZL1x\00"
+
+static __device__ int x;
+
+// Check a static device variables referenced only by device functions and kernels
+// is not externalized.
+// DEV-DAG: @_ZL2x2 = internal addrspace(1) global i32 0
+static __device__ int x2;
+
+// Check a static device variable referenced by host device function is externalized.
+// DEV-DAG: @_ZL2x3 = addrspace(1) externally_initialized global i32 0
+static __device__ int x3;
+
+// Check a static device variable referenced in file scope is externalized.
+// DEV-DAG: @_ZL2x4 = addrspace(1) externally_initialized global i32 0
+static __device__ int x4;
+int& x4_ref = x4;
+
+// Check a static constant variable referenced by host is externalized.
+// DEV-DAG: @_ZL1y = addrspace(4) externally_initialized global i32 0
+// HOST-DAG: @_ZL1y = internal global i32 undef
+// HOST-DAG: @[[DEVNAMEY:[0-9]+]] = {{.*}}c"_ZL1y\00"
+
+static __constant__ int y;
+
+// Test static host variable, which should not be externalized nor registered.
+// HOST-DAG: @_ZL1z = internal global i32 0
+// DEV-NOT: @_ZL1z
+static int z;
+
+// Test static device variable in inline function, which should not be
+// externalized nor registered.
+// DEV-DAG: @_ZZ6devfunPPKiE1p = linkonce_odr addrspace(4) constant i32 2, comdat
+
+inline __device__ void devfun(const int ** b) {
+  const static int p = 2;
+  b[0] = &p;
+  b[1] = &x2;
+}
+
+__global__ void kernel(int *a, const int **b) {
+  const static int w = 1;
+  a[0] = x;
+  a[1] = y;
+  a[2] = x2;
+  a[3] = x3;
+  a[4] = x4;
+  b[0] = &w;
+  devfun(b);
+}
+
+__host__ __device__ void hdf(int *a) {
+  a[0] = x3;
+}
+
+int* getDeviceSymbol(int *x);
+
+void foo(int *a) {
+  getDeviceSymbol(&x);
+  getDeviceSymbol(&y);
+  z = 123;
+}
+
+// HOST: __hipRegisterVar({{.*}}@_ZL1x {{.*}}@[[DEVNAMEX]]
+// HOST: __hipRegisterVar({{.*}}@_ZL1y {{.*}}@[[DEVNAMEY]]
+// HOST-NOT: __hipRegisterVar({{.*}}@_ZZ6kernelPiPPKiE1w
+// HOST-NOT: __hipRegisterVar({{.*}}@_ZZ6devfunPPKiE1p
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -17873,6 +17873,25 @@
   if (Var->isInvalidDecl())
 return;
 
+  // Record a CUDA/HIP static device/constant variable if it is referenced
+  // by host code. This is done conservatively, when the variable is referenced
+  // in any of the following contexts:
+  //   - a non-function context
+  //   - a host function
+  //   - a host device function
+  // This also requires the reference of the static device/constant variable by
+  // host code to be visible in the device compilation for the compiler to be
+  // able to externalize the static device/constant variable.
+  if ((Var->hasAttr() || Var->hasAttr()) &&
+  Var->isFileVarDecl() && Var->getStorageClass() == SC_Static) {
+auto *CurContext = SemaRef.CurContext;
+if (!CurContext || !isa(CurContext) ||
+cast(CurContext)->hasAttr() ||
+(!cast(CurContext)->hasAttr() &&
+ !cast(CurContext)->hasAttr()))
+  SemaRef.getASTContext().CUDAStaticDeviceVarReferencedByHost.insert(Var);
+  }
+
   auto *MSI = Var->getMemberSpecializationInfo();
   TemplateSpecializationKind TSK = MSI ? MSI->getTemplateSpecializationKind()
: Var->getTemplateSpecializationKind();
Index: clang/lib/AST/ASTContext.cpp

[PATCH] D85223: [CUDA][HIP] Support accessing static device variable in host code for -fgpu-rdc

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl created this revision.
yaxunl added reviewers: tra, rjmccall, JonChesterfield, hliao.
Herald added a subscriber: dang.
yaxunl requested review of this revision.

This is separated from https://reviews.llvm.org/D80858

For -fgpu-rdc mode, static device vars in different TU's may have the same name.
To support accessing file-scope static device variables in host code, we need 
to give them
a distinct name and external linkage. This can be done by postfixing each 
static device variable with
a distinct CUID (Compilation Unit ID). Also we have to make sure the host 
compilation and device
compilation of the same compilation unit use identical CUID.

This patch added a distinct CUID for each input file, which is represented by 
InputAction.
clang initially creates an InputAction for each input file for the host 
compilation. In CUDA/HIP action
builder, each InputAction is given a CUID and cloned for each GPU arch, and the 
CUID is also cloned. In this way,
we guarantee the corresponding device and host compilation for the same file 
shared the
same CUID, therefore the postfixed device variable and shadow variable share 
the same name.
On the other hand, different compilation units have different CUID, therefore a 
static variable
with the same name but in a different compilation unit will have a different 
name.

Since the static device variables have different name across compilation units, 
now we let
them have external linkage so that they can be looked up by the runtime.

-fuse-cuid=random|hash|none is added to control the method to generate CUID. 
The default
is hash. -cuid=X is also added to specify CUID explicitly, which overrides 
-fuse-cuid.


https://reviews.llvm.org/D85223

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Basic/LangOptions.h
  clang/include/clang/Driver/Action.h
  clang/include/clang/Driver/Compilation.h
  clang/include/clang/Driver/Options.td
  clang/lib/AST/ASTContext.cpp
  clang/lib/CodeGen/CGCUDANV.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenModule.h
  clang/lib/Driver/Action.cpp
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGenCUDA/static-device-var-rdc.cu
  clang/test/Driver/hip-cuid.hip
  clang/test/Frontend/hip-cuid.hip
  clang/test/SemaCUDA/static-device-var.cu

Index: clang/test/SemaCUDA/static-device-var.cu
===
--- /dev/null
+++ clang/test/SemaCUDA/static-device-var.cu
@@ -0,0 +1,37 @@
+// REQUIRES: x86-registered-target
+// REQUIRES: amdgpu-registered-target
+
+// RUN: %clang_cc1 -triple nvptx -fcuda-is-device \
+// RUN:-emit-llvm -o - %s -fsyntax-only -verify
+
+// RUN: %clang_cc1 -triple x86_64-gnu-linux \
+// RUN:-emit-llvm -o - %s -fsyntax-only -verify
+
+#include "Inputs/cuda.h"
+
+__device__ void f1() {
+  const static int b = 123;
+  static int a;
+  // expected-error@-1 {{within a __device__ function, only __shared__ variables or const variables without device memory qualifier may be marked 'static'}}
+}
+
+__global__ void k1() {
+  const static int b = 123;
+  static int a;
+  // expected-error@-1 {{within a __global__ function, only __shared__ variables or const variables without device memory qualifier may be marked 'static'}}
+}
+
+static __device__ int x;
+static __constant__ int y;
+
+__global__ void kernel(int *a) {
+  a[0] = x;
+  a[1] = y;
+}
+
+int* getDeviceSymbol(int *x);
+
+void foo() {
+  getDeviceSymbol(&x);
+  getDeviceSymbol(&y);
+}
Index: clang/test/Frontend/hip-cuid.hip
===
--- /dev/null
+++ clang/test/Frontend/hip-cuid.hip
@@ -0,0 +1,6 @@
+// RUN: not %clang_cc1 -cuid=abc-123 -offload-arch=gfx906 %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=INVALID %s
+
+// INVALID: invalid value 'abc-123' in '-cuid=abc-123' (alphanumeric characters and underscore only)
+
+// RUN: %clang_cc1 -cuid=abc_123 -offload-arch=gfx906 %s
Index: clang/test/Driver/hip-cuid.hip
===
--- /dev/null
+++ clang/test/Driver/hip-cuid.hip
@@ -0,0 +1,130 @@
+// REQUIRES: clang-driver
+// REQUIRES: x86-registered-target
+// REQUIRES: amdgpu-registered-target
+
+// Check invalid -fuse-cuid= option.
+
+// RUN: not %clang -### -x hip \
+// RUN:   -target x86_64-unknown-linux-gnu \
+// RUN:   --offload-arch=gfx900 \
+// RUN:   --offload-arch=gfx906 \
+// RUN:   -c -nogpulib -fuse-cuid=invalid \
+// RUN:   %S/Inputs/hip_multiple_inputs/a.cu \
+// RUN:   %S/Inputs/hip_multiple_inputs/b.hip \
+// RUN: 2>&1 | FileCheck -check-prefixes=INVALID %s
+
+// INVALID: invalid value 'invalid' in '-fuse-cuid=invalid'
+
+// Check random CUID generator.
+
+// RUN: %clang -### -x hip \
+// RUN:   -target x86_64-unknown-linux-gnu \
+// RUN:   --offload-arch=gfx900 \
+// RUN:   --offload-arch=gfx906 \
+// RUN:   -c -nogpu

[PATCH] D81083: [Clang] Allow "vector_size" applied to Booleans

[Richard Sandiford via Phabricator via cfe-commits]

rsandifo-arm added inline comments.



Comment at: clang/docs/LanguageExtensions.rst:473
+architectures.  The size parameter of a boolean vector type is the number of
+bits in the vector (for all non-bool vectors, the number refers to the number
+of bytes in the vector).

simoll wrote:
> rsandifo-arm wrote:
> > simoll wrote:
> > > rsandifo-arm wrote:
> > > > simoll wrote:
> > > > > rsandifo-arm wrote:
> > > > > > simoll wrote:
> > > > > > > lenary wrote:
> > > > > > > > It would be nice if this aside about non-bool vectors was more 
> > > > > > > > prominently displayed - it's something I hadn't realised before.
> > > > > > > Yep. that caught me by surprise too. I'll move that sentence to 
> > > > > > > the paragraph about GCC vectors above.
> > > > > > Sorry for the extremely late comment.  Like @lenary I hadn't 
> > > > > > thought about this.  I'd assumed that the vector woiuld still be a 
> > > > > > multiple of 8 bits in size, but I agree that's probably too 
> > > > > > restrictive to be the only option available.
> > > > > > 
> > > > > > In that case, would it make sense to add a separate attribute 
> > > > > > instead?  I think it's too surprising to change the units of the 
> > > > > > existing attribute based on the element type.  Perhaps we should 
> > > > > > even make it take two parameters: the total number of elements, and 
> > > > > > the number of bits per element.  That might be more natural for 
> > > > > > some AVX and SVE combinations.  We wouldn't need to supporrt all 
> > > > > > combinations from the outset, it's just a question whether we 
> > > > > > should make the syntax general enough to support it in future.
> > > > > > 
> > > > > > Perhaps we could do both: support `vector_size` for `bool` using 
> > > > > > byte sizes (and not allowing subbyte vector lengths), and add a 
> > > > > > new, more general attribute that allows subbyte lengths and 
> > > > > > explicit subbyte element sizes.
> > > > > > In that case, would it make sense to add a separate attribute 
> > > > > > instead? I think it's too surprising to change the units of the 
> > > > > > existing attribute based on the element type. Perhaps we should 
> > > > > > even make it take two parameters: the total number of elements, and 
> > > > > > the number of bits per element. That might be more natural for some 
> > > > > > AVX and SVE combinations. We wouldn't need to supporrt all 
> > > > > > combinations from the outset, it's just a question whether we 
> > > > > > should make the syntax general enough to support it in future.
> > > > > 
> > > > > I guess adding a new attribute makes sense mid to long term. For now, 
> > > > > i'd want something that just does the job... ie, what is proposed 
> > > > > here. We should absolutely document the semantics of vector_size 
> > > > > properly.. it already is counterintuitive (broken, if you ask me).
> > > > > 
> > > > > 
> > > > > > Perhaps we could do both: support vector_size for bool using byte 
> > > > > > sizes (and not allowing subbyte vector lengths), and add a new, 
> > > > > > more general attribute that allows subbyte lengths and explicit 
> > > > > > subbyte element sizes.
> > > > > 
> > > > > Disallowing subbyte bool vectors actually makes this more complicated 
> > > > > because these types are produced implicitly by compares of (legal) 
> > > > > vector types. Consider this:
> > > > > 
> > > > >   typedef int int3 __attribute__((vector_size(3 * sizeof(int;
> > > > >   int3 A = ...;
> > > > >   int3 B = ...;
> > > > >   auto Z = A < B; // vector compare yielding a `bool 
> > > > > vector_size(3)`-typed value.
> > > > > 
> > > > > 
> > > > > Regarding your proposal for a separate subbyte element size and 
> > > > > subbyte length, that may or may not make sense but it is surely 
> > > > > something that should be discussed more broadly with its own proposal.
> > > > > > Perhaps we could do both: support vector_size for bool using byte 
> > > > > > sizes (and not allowing subbyte vector lengths), and add a new, 
> > > > > > more general attribute that allows subbyte lengths and explicit 
> > > > > > subbyte element sizes.
> > > > > 
> > > > > Disallowing subbyte bool vectors actually makes this more complicated 
> > > > > because these types are produced implicitly by compares of (legal) 
> > > > > vector types. Consider this:
> > > > > 
> > > > >   typedef int int3 __attribute__((vector_size(3 * sizeof(int;
> > > > >   int3 A = ...;
> > > > >   int3 B = ...;
> > > > >   auto Z = A < B; // vector compare yielding a `bool 
> > > > > vector_size(3)`-typed value.
> > > > 
> > > > Yeah, I understand the need for some way of creating subbyte vectors.  
> > > > I'm just not sure using the existing `vector_size` attribute would be 
> > > > the best choice for that case.  I.e. the objection wasn't based on 
> > > > “keeping things simple” but more “keeping things consistent“.
> > > > 
> > > > That doesn't mean that the above code

[clang] 83cb98f - Fix sphinx indentation warnings by adding explicit line breaks to address space hierarchy

[Simon Pilgrim via cfe-commits]

Author: Simon Pilgrim
Date: 2020-08-04T17:48:54+01:00
New Revision: 83cb98f9e7a57360e137b32b26500fca630df617

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

LOG: Fix sphinx indentation warnings by adding explicit line breaks to address 
space hierarchy

Added: 


Modified: 
clang/include/clang/Basic/AttrDocs.td

Removed: 




diff  --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index 76a075a97ee1..83990721d7f7 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -3134,11 +3134,12 @@ distinguish USM (Unified Shared Memory) pointers that 
access global device
 memory from those that access global host memory. These new address spaces are
 a subset of the ``__global/opencl_global`` address space, the full address 
space
 set model for OpenCL 2.0 with the extension looks as follows:
-  generic->global->host
- ->device
- ->private
- ->local
-  constant
+
+  | generic->global->host
+  |->device
+  |->private
+  |->local
+  | constant
 
 As ``global_device`` and ``global_host`` are a subset of
 ``__global/opencl_global`` address spaces it is allowed to convert



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

[PATCH] D81083: [Clang] Allow "vector_size" applied to Booleans

[Simon Moll via Phabricator via cfe-commits]

simoll planned changes to this revision.
simoll added a comment.

Thanks for the feedback!
Planned change: interpret the `N` in `vector_size(N)` as the number of bytes in 
the type, such that, for example, a `vector_size(2)` bool vector holds 16 bits


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D81083

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

[PATCH] D84457: [OPENMP]Fix PR37671: Privatize local(private) variables in untied tasks.

[Alexey Bataev via Phabricator via cfe-commits]

ABataev updated this revision to Diff 282958.
ABataev added a comment.

Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84457

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/lib/CodeGen/CGOpenMPRuntime.h
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/test/OpenMP/task_codegen.cpp

Index: clang/test/OpenMP/task_codegen.cpp
===
--- clang/test/OpenMP/task_codegen.cpp
+++ clang/test/OpenMP/task_codegen.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -verify -triple x86_64-apple-darwin10 -fopenmp -x c++ -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -verify -triple x86_64-apple-darwin10 -fopenmp -x c++ -emit-llvm %s -o - | FileCheck %s --check-prefix CHECK --check-prefix UNTIEDRT
 // RUN: %clang_cc1 -fopenmp -x c++ -triple x86_64-apple-darwin10 -emit-pch -o %t %s
 // RUN: %clang_cc1 -fopenmp -x c++ -triple x86_64-apple-darwin10 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s
 //
@@ -258,7 +258,7 @@
 a = 4;
 c = 5;
   }
-// CHECK: [[ORIG_TASK_PTR:%.+]] = call i8* @__kmpc_omp_task_alloc([[IDENT_T]]* @{{.+}}, i32 {{%.*}}, i32 0, i64 40, i64 1, i32 (i32, i8*)* bitcast (i32 (i32, [[KMP_TASK_T]]{{.*}}*)* [[TASK_ENTRY6:@.+]] to i32 (i32, i8*)*))
+// CHECK: [[ORIG_TASK_PTR:%.+]] = call i8* @__kmpc_omp_task_alloc([[IDENT_T]]* @{{.+}}, i32 {{%.*}}, i32 0, i64 48, i64 1, i32 (i32, i8*)* bitcast (i32 (i32, [[KMP_TASK_T]]{{.*}}*)* [[TASK_ENTRY6:@.+]] to i32 (i32, i8*)*))
 // CHECK: call i32 @__kmpc_omp_task([[IDENT_T]]* @{{.+}}, i32 {{%.*}}, i8* [[ORIG_TASK_PTR]])
 #pragma omp task untied
   {
@@ -295,26 +295,54 @@
 // CHECK: store i32 4, i32* [[A_PTR]]
 
 // CHECK: define internal i32 [[TASK_ENTRY6]](i32 %0, [[KMP_TASK_T]]{{.*}}* noalias %1)
-// CHECK: switch i32 %{{.+}}, label
+// UNTIEDRT: [[S1_ADDR_PTR:%.+]] = alloca %struct.S*,
+// UNTIEDRT: call void (i8*, ...) %{{.+}}(i8* %{{.+}}, %struct.S** [[S1_ADDR_PTR]])
+// UNTIEDRT: [[S1_ADDR:%.+]] = load %struct.S*, %struct.S** [[S1_ADDR_PTR]],
+// CHECK: switch i32 %{{.+}}, label %[[DONE:.+]] [
+
+// CHECK: [[DONE]]:
+// CHECK: br label %[[CLEANUP:[^,]+]]
+
 // CHECK: load i32*, i32** %
 // CHECK: store i32 1, i32* %
 // CHECK: call i32 @__kmpc_omp_task(%
+// UNTIEDRT: br label %[[EXIT:[^,]+]]
 
+// UNTIEDRT: call void [[CONSTR:@.+]](%struct.S* [[S1_ADDR]])
 // CHECK: call i8* @__kmpc_omp_task_alloc(
 // CHECK: call i32 @__kmpc_omp_task(%
 // CHECK: load i32*, i32** %
 // CHECK: store i32 2, i32* %
 // CHECK: call i32 @__kmpc_omp_task(%
+// UNTIEDRT: br label %[[EXIT]]
 
 // CHECK: call i32 @__kmpc_omp_taskyield(%
 // CHECK: load i32*, i32** %
 // CHECK: store i32 3, i32* %
 // CHECK: call i32 @__kmpc_omp_task(%
+// UNTIEDRT: br label %[[EXIT]]
+
+// s1 = S();
+// UNTIEDRT: call void [[CONSTR]](%struct.S* [[TMP:%.+]])
+// UNTIEDRT: [[DST:%.+]] = bitcast %struct.S* [[S1_ADDR]] to i8*
+// UNTIEDRT: [[SRC:%.+]] = bitcast %struct.S* [[TMP]] to i8*
+// UNTIEDRT: call void @llvm.memcpy.{{.+}}(i8* {{.*}}[[DST]], i8* {{.*}}[[SRC]], i64 4, i1 false)
+// UNTIEDRT: call void [[DESTR:@.+]](%struct.S* [[TMP]])
 
 // CHECK: call i32 @__kmpc_omp_taskwait(%
 // CHECK: load i32*, i32** %
 // CHECK: store i32 4, i32* %
 // CHECK: call i32 @__kmpc_omp_task(%
+// UNTIEDRT: br label %[[EXIT]]
+
+// UNTIEDRT: call void [[DESTR]](%struct.S* [[S1_ADDR]])
+// CHECK: br label %[[CLEANUP]]
+
+// CHECK: [[CLEANUP]]:
+// UNTIEDRT: br label %[[EXIT]]
+
+// UNTIEDRT:  [[EXIT]]:
+// UNTIEDRT-NEXT: ret i32 0
 
 struct S1 {
   int a;
Index: clang/lib/CodeGen/CGStmtOpenMP.cpp
===
--- clang/lib/CodeGen/CGStmtOpenMP.cpp
+++ clang/lib/CodeGen/CGStmtOpenMP.cpp
@@ -21,6 +21,7 @@
 #include "clang/AST/OpenMPClause.h"
 #include "clang/AST/Stmt.h"
 #include "clang/AST/StmtOpenMP.h"
+#include "clang/AST/StmtVisitor.h"
 #include "clang/Basic/OpenMPKinds.h"
 #include "clang/Basic/PrettyStackTrace.h"
 #include "llvm/Frontend/OpenMP/OMPConstants.h"
@@ -3787,6 +3788,42 @@
   checkForLastprivateConditionalUpdate(*this, S);
 }
 
+namespace {
+/// Get the list of variables declared in the context of the untied tasks.
+class CheckVarsEscapingUntiedTaskDeclContext final
+: public ConstStmtVisitor {
+  llvm::SmallVector PrivateDecls;
+
+public:
+  explicit CheckVarsEscapingUntiedTaskDeclContext() = default;
+  virtual ~CheckVarsEscapingUntiedTaskDeclContext() = default;
+  void VisitDeclStmt(const DeclStmt *S) {
+if (!S)
+  return;
+// Need to privatize only local vars, static locals can be processed as is.
+for (const Decl *D : S->decls()) {
+  if (const auto *VD = dyn_cast_or_null(D))
+if (VD->hasLocalStorage())
+  PrivateDecls.push_back(VD);
+}
+  }
+  void VisitOMPExecutableDirective(const OMPExecutableDirective *) { return; }
+  void VisitCapturedStmt(const CapturedStmt *) { return; }
+  void VisitLambdaExpr(const LambdaExpr *) { return; }

[PATCH] D85128: [Prototype][SVE] Support arm_sve_vector_bits attribute

[Eli Friedman via Phabricator via cfe-commits]

efriedma added a comment.

> I guess with what you're suggesting the bitcast could still be emitted there 
> but the cast operations could be limited in Sema to cases where ultimately 
> ConvertType would return a type that requires bitcasting, or are you saying 
> that could be avoided completely?

The bitcast operation would exist in Sema either way; it's necessary for the 
types to stay consistent.  My suggestion is just that bitcasting between a VLAT 
and the corresponding VLST it would be a no-op in CodeGen.

My suggestion is similar to the way the "bool" type works: in memory, it's an 
i8, but when you load it, it's truncated it to i1.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85128

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

[PATCH] D75574: RFC: Implement objc_direct_protocol attribute to remove protocol metadata

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Sorry, this slipped out of my mind.  I've started the process internally.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75574

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

[PATCH] D80858: [CUDA][HIP] Support accessing static device variable in host code for -fno-gpu-rdc

[Artem Belevich via Phabricator via cfe-commits]

tra accepted this revision.
tra added a comment.

What is expected to happen to device statics in anonymous name spaces? It may 
be worth adding them to the tests.

LGTM otherwise.


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

https://reviews.llvm.org/D80858

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

[PATCH] D83242: [clang][BPF] support type exist/size and enum exist/value relocations

[Andrii Nakryiko via Phabricator via cfe-commits]

anakryiko added a comment.

> This is different than testing whether a type exists or not where we want to 
> precisely test whether that type exists or not, so we want to preserve 
> `typedef` type vs. `struct t` type.

`typedef t` and `struct t` are also different for field relocations (those t is 
in different namespaces, actually), so it might be a good idea to disambiguate 
those for field relocations as well?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83242

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

[PATCH] D85102: [clang] improve diagnostics for misaligned and large atomics

[JF Bastien via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGe18c6ef6b41a: [clang] improve diagnostics for misaligned and 
large atomics (authored by tschuett, committed by jfb).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85102

Files:
  clang/include/clang/Basic/DiagnosticFrontendKinds.td
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/lib/CodeGen/CGAtomic.cpp
  clang/test/CodeGen/atomics-sema-alignment.c

Index: clang/test/CodeGen/atomics-sema-alignment.c
===
--- clang/test/CodeGen/atomics-sema-alignment.c
+++ clang/test/CodeGen/atomics-sema-alignment.c
@@ -12,10 +12,10 @@
 
 void func(IntPair *p) {
   IntPair res;
-  __atomic_load(p, &res, 0); // expected-warning {{misaligned atomic operation may incur significant performance penalty}}
-  __atomic_store(p, &res, 0); // expected-warning {{misaligned atomic operation may incur significant performance penalty}}
-  __atomic_fetch_add((unaligned_int *)p, 1, 2); // expected-warning {{misaligned atomic operation may incur significant performance penalty}}
-  __atomic_fetch_sub((unaligned_int *)p, 1, 3); // expected-warning {{misaligned atomic operation may incur significant performance penalty}}
+  __atomic_load(p, &res, 0);// expected-warning {{misaligned atomic operation may incur significant performance penalty; the expected alignment (8 bytes) exceeds the actual alignment (4 bytes)}}
+  __atomic_store(p, &res, 0);   // expected-warning {{misaligned atomic operation may incur significant performance penalty; the expected alignment (8 bytes) exceeds the actual alignment (4 bytes)}}
+  __atomic_fetch_add((unaligned_int *)p, 1, 2); // expected-warning {{misaligned atomic operation may incur significant performance penalty; the expected alignment (4 bytes) exceeds the actual alignment (1 bytes)}}
+  __atomic_fetch_sub((unaligned_int *)p, 1, 3); // expected-warning {{misaligned atomic operation may incur significant performance penalty; the expected alignment (4 bytes) exceeds the actual alignment (1 bytes)}}
 }
 
 void func1(LongStruct *p) {
@@ -25,3 +25,24 @@
   __atomic_fetch_add((int *)p, 1, 2);
   __atomic_fetch_sub((int *)p, 1, 3);
 }
+
+typedef struct {
+  void *a;
+  void *b;
+} Foo;
+
+typedef struct {
+  void *a;
+  void *b;
+  void *c;
+  void *d;
+} __attribute__((aligned(32))) ThirtyTwo;
+
+void braz(Foo *foo, ThirtyTwo *braz) {
+  Foo bar;
+  __atomic_load(foo, &bar, __ATOMIC_RELAXED); // expected-warning {{misaligned atomic operation may incur significant performance penalty; the expected alignment (16 bytes) exceeds the actual alignment (8 bytes)}}
+
+  ThirtyTwo thirtyTwo1;
+  ThirtyTwo thirtyTwo2;
+  __atomic_load(&thirtyTwo1, &thirtyTwo2, __ATOMIC_RELAXED); // expected-warning {{large atomic operation may incur significant performance penalty; the access size (32 bytes) exceeds the max lock-free size (16  bytes)}}
+}
Index: clang/lib/CodeGen/CGAtomic.cpp
===
--- clang/lib/CodeGen/CGAtomic.cpp
+++ clang/lib/CodeGen/CGAtomic.cpp
@@ -807,10 +807,20 @@
   bool Oversized = getContext().toBits(sizeChars) > MaxInlineWidthInBits;
   bool Misaligned = (Ptr.getAlignment() % sizeChars) != 0;
   bool UseLibcall = Misaligned | Oversized;
+  CharUnits MaxInlineWidth =
+  getContext().toCharUnitsFromBits(MaxInlineWidthInBits);
 
-  if (UseLibcall) {
-CGM.getDiags().Report(E->getBeginLoc(), diag::warn_atomic_op_misaligned)
-<< !Oversized;
+  DiagnosticsEngine &Diags = CGM.getDiags();
+
+  if (Misaligned) {
+Diags.Report(E->getBeginLoc(), diag::warn_atomic_op_misaligned)
+<< (int)sizeChars.getQuantity()
+<< (int)Ptr.getAlignment().getQuantity();
+  }
+
+  if (Oversized) {
+Diags.Report(E->getBeginLoc(), diag::warn_atomic_op_oversized)
+<< (int)sizeChars.getQuantity() << (int)MaxInlineWidth.getQuantity();
   }
 
   llvm::Value *Order = EmitScalarExpr(E->getOrder());
Index: clang/include/clang/Basic/DiagnosticGroups.td
===
--- clang/include/clang/Basic/DiagnosticGroups.td
+++ clang/include/clang/Basic/DiagnosticGroups.td
@@ -699,6 +699,7 @@
 def Reorder : DiagGroup<"reorder", [ReorderCtor, ReorderInitList]>;
 def UndeclaredSelector : DiagGroup<"undeclared-selector">;
 def ImplicitAtomic : DiagGroup<"implicit-atomic-properties">;
+def AtomicAlignment : DiagGroup<"atomic-alignment">;
 def CustomAtomic : DiagGroup<"custom-atomic-properties">;
 def AtomicProperties : DiagGroup<"atomic-properties",
  [ImplicitAtomic, CustomAtomic]>;
Index: clang/include/clang/Basic/DiagnosticFrontendKinds.td
===
--- clang/include/clang/Basic/DiagnosticFrontendKinds.td
+++ clang/include/clang/

[clang] e18c6ef - [clang] improve diagnostics for misaligned and large atomics

[JF Bastien via cfe-commits]

Author: Thorsten Schuett
Date: 2020-08-04T11:10:29-07:00
New Revision: e18c6ef6b41a59af73bf5c3d7d52a8c53a471e5d

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

LOG: [clang] improve diagnostics for misaligned and large atomics

"Listing the alignment and access size (== expected alignment) in the warning
seems like a good idea."

solves PR 46947

  struct Foo {
struct Bar {
  void * a;
  void * b;
};
Bar bar;
  };

  struct ThirtyTwo {
struct Large {
  void * a;
  void * b;
  void * c;
  void * d;
};
Large bar;
  };

  void braz(Foo *foo, ThirtyTwo *braz) {
Foo::Bar bar;
__atomic_load(&foo->bar, &bar, __ATOMIC_RELAXED);

ThirtyTwo::Large foobar;
__atomic_load(&braz->bar, &foobar, __ATOMIC_RELAXED);
  }

repro.cpp:21:3: warning: misaligned atomic operation may incur significant 
performance penalty; the expected (16 bytes) exceeds the actual alignment (8 
bytes) [-Watomic-alignment]
  __atomic_load(&foo->bar, &bar, __ATOMIC_RELAXED);
  ^
repro.cpp:24:3: warning: misaligned atomic operation may incur significant 
performance penalty; the expected (32 bytes) exceeds the actual alignment (8 
bytes) [-Watomic-alignment]
  __atomic_load(&braz->bar, &foobar, __ATOMIC_RELAXED);
  ^
repro.cpp:24:3: warning: large atomic operation may incur significant 
performance penalty; the access size (32 bytes) exceeds the max lock-free size 
(16  bytes) [-Watomic-alignment]
3 warnings generated.

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

Added: 


Modified: 
clang/include/clang/Basic/DiagnosticFrontendKinds.td
clang/include/clang/Basic/DiagnosticGroups.td
clang/lib/CodeGen/CGAtomic.cpp
clang/test/CodeGen/atomics-sema-alignment.c

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticFrontendKinds.td 
b/clang/include/clang/Basic/DiagnosticFrontendKinds.td
index b202d2abffa0..6434d92fd8fc 100644
--- a/clang/include/clang/Basic/DiagnosticFrontendKinds.td
+++ b/clang/include/clang/Basic/DiagnosticFrontendKinds.td
@@ -270,8 +270,16 @@ def err_ifunc_resolver_return : Error<
   "ifunc resolver function must return a pointer">;
 
 def warn_atomic_op_misaligned : Warning<
-  "%select{large|misaligned}0 atomic operation may incur "
-  "significant performance penalty">, InGroup>;
+  "misaligned atomic operation may incur "
+  "significant performance penalty"
+  "; the expected alignment (%0 bytes) exceeds the actual alignment (%1 
bytes)">,
+  InGroup;
+
+def warn_atomic_op_oversized : Warning<
+  "large atomic operation may incur "
+  "significant performance penalty"
+  "; the access size (%0 bytes) exceeds the max lock-free size (%1  bytes)">,
+InGroup;
 
 def warn_alias_with_section : Warning<
   "%select{alias|ifunc}1 will not be in section '%0' but in the same section "

diff  --git a/clang/include/clang/Basic/DiagnosticGroups.td 
b/clang/include/clang/Basic/DiagnosticGroups.td
index 1e829be4028e..be62461faef4 100644
--- a/clang/include/clang/Basic/DiagnosticGroups.td
+++ b/clang/include/clang/Basic/DiagnosticGroups.td
@@ -699,6 +699,7 @@ def ReorderInitList : DiagGroup<"reorder-init-list">;
 def Reorder : DiagGroup<"reorder", [ReorderCtor, ReorderInitList]>;
 def UndeclaredSelector : DiagGroup<"undeclared-selector">;
 def ImplicitAtomic : DiagGroup<"implicit-atomic-properties">;
+def AtomicAlignment : DiagGroup<"atomic-alignment">;
 def CustomAtomic : DiagGroup<"custom-atomic-properties">;
 def AtomicProperties : DiagGroup<"atomic-properties",
  [ImplicitAtomic, CustomAtomic]>;

diff  --git a/clang/lib/CodeGen/CGAtomic.cpp b/clang/lib/CodeGen/CGAtomic.cpp
index a58450ddd4c5..b7ada4ac7e3b 100644
--- a/clang/lib/CodeGen/CGAtomic.cpp
+++ b/clang/lib/CodeGen/CGAtomic.cpp
@@ -807,10 +807,20 @@ RValue CodeGenFunction::EmitAtomicExpr(AtomicExpr *E) {
   bool Oversized = getContext().toBits(sizeChars) > MaxInlineWidthInBits;
   bool Misaligned = (Ptr.getAlignment() % sizeChars) != 0;
   bool UseLibcall = Misaligned | Oversized;
+  CharUnits MaxInlineWidth =
+  getContext().toCharUnitsFromBits(MaxInlineWidthInBits);
 
-  if (UseLibcall) {
-CGM.getDiags().Report(E->getBeginLoc(), diag::warn_atomic_op_misaligned)
-<< !Oversized;
+  DiagnosticsEngine &Diags = CGM.getDiags();
+
+  if (Misaligned) {
+Diags.Report(E->getBeginLoc(), diag::warn_atomic_op_misaligned)
+<< (int)sizeChars.getQuantity()
+<< (int)Ptr.getAlignment().getQuantity();
+  }
+
+  if (Oversized) {
+Diags.Report(E->getBeginLoc(), diag::warn_atomic_op_oversized)
+<< (int)sizeChars.getQuantity() << (int)MaxInlineWidth.getQuantity();
   }
 
   llvm::Value *Order = EmitScalarExpr(E->getOrder());

diff  --git a/clang/test/CodeGen/atomics-sema-alignment.c 
b/clang/test/CodeGe

[PATCH] D85231: Protect against filenames with no extension at all.

[Sterling Augustine via Phabricator via cfe-commits]

saugustine created this revision.
saugustine added a reviewer: echristo.
Herald added a reviewer: JDevlieghere.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
saugustine requested review of this revision.

Such as the one in the darwin-dsymutil.c test.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D85231

Files:
  clang/lib/Driver/Driver.cpp


Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -4675,6 +4675,8 @@
 std::string::size_type End = std::string::npos;
 if (!types::appendSuffixForType(JA.getType()))
   End = BaseName.rfind('.');
+if (End == StringRef::npos)
+  End = BaseName.size();
 SmallString<128> Suffixed(BaseName.substr(0, End));
 Suffixed += OffloadingPrefix;
 if (MultipleArchs && !BoundArch.empty()) {


Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -4675,6 +4675,8 @@
 std::string::size_type End = std::string::npos;
 if (!types::appendSuffixForType(JA.getType()))
   End = BaseName.rfind('.');
+if (End == StringRef::npos)
+  End = BaseName.size();
 SmallString<128> Suffixed(BaseName.substr(0, End));
 Suffixed += OffloadingPrefix;
 if (MultipleArchs && !BoundArch.empty()) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D75574: RFC: Implement objc_direct_protocol attribute to remove protocol metadata

[Nathan Lanza via Phabricator via cfe-commits]

lanza added a comment.

No problem! Thank you, John!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75574

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

[PATCH] D79744: clang: Use byref for aggregate kernel arguments

[Matt Arsenault via Phabricator via cfe-commits]

arsenm added inline comments.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:1997
   case ABIArgInfo::Ignore:
+  case ABIArgInfo::IndirectAliased:
 return false;

rjmccall wrote:
> arsenm wrote:
> > rjmccall wrote:
> > > In principle, this can be `inreg` just as much as Indirect can.
> > The IR verifier currently will reject byref + inreg
> Why?  `inreg` is essentially orthogonal.
Mostly inherited from the other similar attribute handling. It can be lifted if 
there's a use


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

https://reviews.llvm.org/D79744

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

[PATCH] D84600: [Analyzer] Support note tags for smart ptr checker

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/SmartPtrChecker.cpp:110
+  SmartPtrChecker *Checker = Mgr.registerChecker();
+  NullDereferenceBugTypePtr = &Checker->NullDereferenceBugType;
 }

vrnithinkumar wrote:
> NoQ wrote:
> > Wait, i don't understand again. You're taking the bug type from that 
> > checker and using it in that checker. Why did you need to make it global? I 
> > thought your problem was about capturing the bug type from the //raw// null 
> > dereference checker?
> > Wait, i don't understand again. You're taking the bug type from that 
> > checker and using it in that checker. Why did you need to make it global? I 
> > thought your problem was about capturing the bug type from the //raw// null 
> > dereference checker?
> 
> The check for bug type is in `SmartPtrModeling` but the bug type is defined 
> in `SmartPtrChecker`
Aha, ok, i misunderstood again. So i guess we didn't need a new header then. 
That said, it's an interesting layering violation that we encounter in this 
design: it used to be up to the checker to attach a visitor and so should be 
activating a note tag, but note tags are part of modeling, not checking.

I guess that's just how it is and it's the responsibility of the checkers to 
inform the modeling about bug types. I guess the ultimate API could look like 
`BugReport->activateNoteTag(NoteTagTag TT)` (where `TT` is a crying smiley that 
cries about "tag tags" T_T). But that's a story for another time.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84600

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

[PATCH] D82675: [PowerPC] Implement Vector Extract Mask builtins in LLVM/Clang

[Baptiste Saleil via Phabricator via cfe-commits]

bsaleil accepted this revision as: bsaleil.
bsaleil added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82675

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

[PATCH] D84600: [Analyzer] Support note tags for smart ptr checker

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

Generally i think this is shaping up nicely, with the couple of minor nits 
addressed i'm happy to land this. Like, there are a few cornercases that we 
could address but we could do that in follow-up patches. Folks, do you see 
anything else here?




Comment at: clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp:131
+  }
+  return nullptr;
+}

You never ever check for this case. Therefore this function entirely boils down 
to `Call.getArgExpr(0)` which is shorter than `getFirstArgExpr(Call)` anyway.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84600

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

[PATCH] D85236: [CUDA] Work around a bug in rint() caused by a broken implementation provided by CUDA.

[Artem Belevich via Phabricator via cfe-commits]

tra created this revision.
tra added a reviewer: jlebar.
Herald added subscribers: sanjoy.google, bixia, yaxunl.
Herald added a project: clang.
tra requested review of this revision.

Normally math functions are forwarded to __nv_* counterparts provided by CUDA's
libdevice bitcode. However, __nv_rint*() functions there have a bug -- they use
round() which rounds *up* instead of rounding towards the nearest integer, so we
end up with rint(2.5f) producing 3.0 instead of expected 2.0. The broken bitcode
is not actually used by NVCC itself, which has both a work-around in CUDA
headers and, in recent versions, uses correct implementations in NVCC's 
built-ins.

This patch implements equivalent workaround and directs rint/rintf to
__builtin_rint/rintf that produce correct results.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D85236

Files:
  clang/lib/Headers/__clang_cuda_math.h


Index: clang/lib/Headers/__clang_cuda_math.h
===
--- clang/lib/Headers/__clang_cuda_math.h
+++ clang/lib/Headers/__clang_cuda_math.h
@@ -249,8 +249,9 @@
 __DEVICE__ float rhypotf(float __a, float __b) {
   return __nv_rhypotf(__a, __b);
 }
-__DEVICE__ double rint(double __a) { return __nv_rint(__a); }
-__DEVICE__ float rintf(float __a) { return __nv_rintf(__a); }
+// __nv_rint* in libdevice is buggy and produces incorrect results.
+__DEVICE__ double rint(double __a) { return __builtin_rint(__a); }
+__DEVICE__ float rintf(float __a) { return __builtin_rintf(__a); }
 __DEVICE__ double rnorm(int __a, const double *__b) {
   return __nv_rnorm(__a, __b);
 }


Index: clang/lib/Headers/__clang_cuda_math.h
===
--- clang/lib/Headers/__clang_cuda_math.h
+++ clang/lib/Headers/__clang_cuda_math.h
@@ -249,8 +249,9 @@
 __DEVICE__ float rhypotf(float __a, float __b) {
   return __nv_rhypotf(__a, __b);
 }
-__DEVICE__ double rint(double __a) { return __nv_rint(__a); }
-__DEVICE__ float rintf(float __a) { return __nv_rintf(__a); }
+// __nv_rint* in libdevice is buggy and produces incorrect results.
+__DEVICE__ double rint(double __a) { return __builtin_rint(__a); }
+__DEVICE__ float rintf(float __a) { return __builtin_rintf(__a); }
 __DEVICE__ double rnorm(int __a, const double *__b) {
   return __nv_rnorm(__a, __b);
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D85118: [clang][AArch64] Correct return type of Neon vqmovun intrinsics

[Eli Friedman via Phabricator via cfe-commits]

efriedma added a comment.

Probably the simplest way to verify return types would be using decltype.  
(`static_assert(std::is_same_v);`.)

For arguments, maybe more complicated.  I guess you could write a C++ class 
with conversion operators for every integer type, mark all of them except one 
"= delete", and pass it as an argument.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85118

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

[PATCH] D85236: [CUDA] Work around a bug in rint() caused by a broken implementation provided by CUDA.

[Justin Lebar via Phabricator via cfe-commits]

jlebar accepted this revision.
jlebar added a comment.
This revision is now accepted and ready to land.

LGTM, and can we write a test in the test-suite?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85236

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

[PATCH] D85239: [DOCS] Add more detail to stack protector documentation

[Peter Smith via Phabricator via cfe-commits]

psmith created this revision.
psmith added reviewers: jfb, Shayne, emaste, kristof.beyls, mattdr, ojhunt, 
probinson, reames, serge-sans-paille, dim.
Herald added a subscriber: dexonsmith.
psmith requested review of this revision.

The Clang -fstack-protector documentation mentions what functions are 
considered vulnerable but does not mention the details of the
implementation such as the use of a global variable for the guard value. This 
brings the documentation more in line with the GCC
documentation at: 
https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html and gives 
someone using the option more idea about what is protected.

This partly addresses https://bugs.llvm.org/show_bug.cgi?id=42764


https://reviews.llvm.org/D85239

Files:
  clang/docs/ClangCommandLineReference.rst


Index: clang/docs/ClangCommandLineReference.rst
===
--- clang/docs/ClangCommandLineReference.rst
+++ clang/docs/ClangCommandLineReference.rst
@@ -2136,7 +2136,7 @@
 
 .. option:: -fstack-protector, -fno-stack-protector
 
-Enable stack protectors for some functions vulnerable to stack smashing. This 
uses a loose heuristic which considers functions vulnerable if they contain a 
char (or 8bit integer) array or constant sized calls to alloca, which are of 
greater size than ssp-buffer-size (default: 8 bytes). All variable sized calls 
to alloca are considered vulnerable
+Enable stack protectors for some functions vulnerable to stack smashing. This 
uses a loose heuristic which considers functions vulnerable if they contain a 
char (or 8bit integer) array or constant sized calls to alloca, which are of 
greater size than ssp-buffer-size (default: 8 bytes). All variable sized calls 
to alloca are considered vulnerable. A function with a stack protector has a 
guard value added to the stack frame that is checked on function exit. The 
guard value must be positioned in the stack frame such that a buffer overflow 
from a vulnerable variable will overwrite to the guard value before overwriting 
the function's return address. The reference stack guard value is stored in a 
global variable.
 
 .. option:: -fstack-protector-all
 


Index: clang/docs/ClangCommandLineReference.rst
===
--- clang/docs/ClangCommandLineReference.rst
+++ clang/docs/ClangCommandLineReference.rst
@@ -2136,7 +2136,7 @@
 
 .. option:: -fstack-protector, -fno-stack-protector
 
-Enable stack protectors for some functions vulnerable to stack smashing. This uses a loose heuristic which considers functions vulnerable if they contain a char (or 8bit integer) array or constant sized calls to alloca, which are of greater size than ssp-buffer-size (default: 8 bytes). All variable sized calls to alloca are considered vulnerable
+Enable stack protectors for some functions vulnerable to stack smashing. This uses a loose heuristic which considers functions vulnerable if they contain a char (or 8bit integer) array or constant sized calls to alloca, which are of greater size than ssp-buffer-size (default: 8 bytes). All variable sized calls to alloca are considered vulnerable. A function with a stack protector has a guard value added to the stack frame that is checked on function exit. The guard value must be positioned in the stack frame such that a buffer overflow from a vulnerable variable will overwrite to the guard value before overwriting the function's return address. The reference stack guard value is stored in a global variable.
 
 .. option:: -fstack-protector-all
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D84780: Setting the /bigobj option globally for Windows debug build. https://bugs.llvm.org/show_bug.cgi?id=46733

[Lei Zhang via Phabricator via cfe-commits]

antiagainst accepted this revision.
antiagainst added a comment.
This revision is now accepted and ready to land.

LGTM for SPIR-V side.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84780

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

[PATCH] D85239: [DOCS] Add more detail to stack protector documentation

[Paul Robinson via Phabricator via cfe-commits]

probinson added a comment.

Looks okay (one grammar nit), probably worth waiting for someone else to chime 
in.




Comment at: clang/docs/ClangCommandLineReference.rst:2139
 
-Enable stack protectors for some functions vulnerable to stack smashing. This 
uses a loose heuristic which considers functions vulnerable if they contain a 
char (or 8bit integer) array or constant sized calls to alloca, which are of 
greater size than ssp-buffer-size (default: 8 bytes). All variable sized calls 
to alloca are considered vulnerable
+Enable stack protectors for some functions vulnerable to stack smashing. This 
uses a loose heuristic which considers functions vulnerable if they contain a 
char (or 8bit integer) array or constant sized calls to alloca, which are of 
greater size than ssp-buffer-size (default: 8 bytes). All variable sized calls 
to alloca are considered vulnerable. A function with a stack protector has a 
guard value added to the stack frame that is checked on function exit. The 
guard value must be positioned in the stack frame such that a buffer overflow 
from a vulnerable variable will overwrite to the guard value before overwriting 
the function's return address. The reference stack guard value is stored in a 
global variable.
 

"overwrite to the guard variable" -> "overwrite the guard variable"


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

https://reviews.llvm.org/D85239

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

[clang] 47f7174 - [WebAssembly] Use "signed char" instead of "char" in SIMD intrinsics.

[Dan Gohman via cfe-commits]

Author: Dan Gohman
Date: 2020-08-04T12:48:40-07:00
New Revision: 47f7174ffa71d339c1a65d1dd9a2ac5ff2abc95d

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

LOG: [WebAssembly] Use "signed char" instead of "char" in SIMD intrinsics.

This allows people to use `int8_t` instead of `char`, -funsigned-char,
and generally decouples SIMD from the specialness of `char`.

And it makes intrinsics like `__builtin_wasm_add_saturate_s_i8x16`
and `__builtin_wasm_add_saturate_u_i8x16` use signed and unsigned
element types, respectively.

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

Added: 


Modified: 
clang/include/clang/Basic/BuiltinsWebAssembly.def
clang/lib/Headers/wasm_simd128.h
clang/test/CodeGen/builtins-wasm.c

Removed: 




diff  --git a/clang/include/clang/Basic/BuiltinsWebAssembly.def 
b/clang/include/clang/Basic/BuiltinsWebAssembly.def
index 39f29740cf56d..c0ac74686cf1c 100644
--- a/clang/include/clang/Basic/BuiltinsWebAssembly.def
+++ b/clang/include/clang/Basic/BuiltinsWebAssembly.def
@@ -66,67 +66,67 @@ TARGET_BUILTIN(__builtin_wasm_trunc_saturate_s_i64_f64, 
"LLid", "nc", "nontrappi
 TARGET_BUILTIN(__builtin_wasm_trunc_saturate_u_i64_f64, "LLid", "nc", 
"nontrapping-fptoint")
 
 // SIMD builtins
-TARGET_BUILTIN(__builtin_wasm_swizzle_v8x16, "V16cV16cV16c", "nc", "simd128")
+TARGET_BUILTIN(__builtin_wasm_swizzle_v8x16, "V16ScV16ScV16Sc", "nc", 
"simd128")
 
-TARGET_BUILTIN(__builtin_wasm_extract_lane_s_i8x16, "iV16cIi", "nc", "simd128")
-TARGET_BUILTIN(__builtin_wasm_extract_lane_u_i8x16, "iV16cIi", "nc", "simd128")
+TARGET_BUILTIN(__builtin_wasm_extract_lane_s_i8x16, "iV16ScIi", "nc", 
"simd128")
+TARGET_BUILTIN(__builtin_wasm_extract_lane_u_i8x16, "iV16UcIUi", "nc", 
"simd128")
 TARGET_BUILTIN(__builtin_wasm_extract_lane_s_i16x8, "iV8sIi", "nc", "simd128")
-TARGET_BUILTIN(__builtin_wasm_extract_lane_u_i16x8, "iV8sIi", "nc", "simd128")
+TARGET_BUILTIN(__builtin_wasm_extract_lane_u_i16x8, "iV8UsIUi", "nc", 
"simd128")
 TARGET_BUILTIN(__builtin_wasm_extract_lane_i32x4, "iV4iIi", "nc", "simd128")
 TARGET_BUILTIN(__builtin_wasm_extract_lane_i64x2, "LLiV2LLiIi", "nc", 
"simd128")
 TARGET_BUILTIN(__builtin_wasm_extract_lane_f32x4, "fV4fIi", "nc", "simd128")
 TARGET_BUILTIN(__builtin_wasm_extract_lane_f64x2, "dV2dIi", "nc", "simd128")
 
-TARGET_BUILTIN(__builtin_wasm_replace_lane_i8x16, "V16cV16cIii", "nc", 
"simd128")
+TARGET_BUILTIN(__builtin_wasm_replace_lane_i8x16, "V16ScV16ScIii", "nc", 
"simd128")
 TARGET_BUILTIN(__builtin_wasm_replace_lane_i16x8, "V8sV8sIii", "nc", "simd128")
 TARGET_BUILTIN(__builtin_wasm_replace_lane_i32x4, "V4iV4iIii", "nc", "simd128")
 TARGET_BUILTIN(__builtin_wasm_replace_lane_i64x2, "V2LLiV2LLiIiLLi", "nc", 
"simd128")
 TARGET_BUILTIN(__builtin_wasm_replace_lane_f32x4, "V4fV4fIif", "nc", "simd128")
 TARGET_BUILTIN(__builtin_wasm_replace_lane_f64x2, "V2dV2dIid", "nc", "simd128")
 
-TARGET_BUILTIN(__builtin_wasm_add_saturate_s_i8x16, "V16cV16cV16c", "nc", 
"simd128")
-TARGET_BUILTIN(__builtin_wasm_add_saturate_u_i8x16, "V16cV16cV16c", "nc", 
"simd128")
+TARGET_BUILTIN(__builtin_wasm_add_saturate_s_i8x16, "V16ScV16ScV16Sc", "nc", 
"simd128")
+TARGET_BUILTIN(__builtin_wasm_add_saturate_u_i8x16, "V16UcV16UcV16Uc", "nc", 
"simd128")
 TARGET_BUILTIN(__builtin_wasm_add_saturate_s_i16x8, "V8sV8sV8s", "nc", 
"simd128")
-TARGET_BUILTIN(__builtin_wasm_add_saturate_u_i16x8, "V8sV8sV8s", "nc", 
"simd128")
+TARGET_BUILTIN(__builtin_wasm_add_saturate_u_i16x8, "V8UsV8UsV8Us", "nc", 
"simd128")
 
-TARGET_BUILTIN(__builtin_wasm_sub_saturate_s_i8x16, "V16cV16cV16c", "nc", 
"simd128")
-TARGET_BUILTIN(__builtin_wasm_sub_saturate_u_i8x16, "V16cV16cV16c", "nc", 
"simd128")
+TARGET_BUILTIN(__builtin_wasm_sub_saturate_s_i8x16, "V16ScV16ScV16Sc", "nc", 
"simd128")
+TARGET_BUILTIN(__builtin_wasm_sub_saturate_u_i8x16, "V16UcV16UcV16Uc", "nc", 
"simd128")
 TARGET_BUILTIN(__builtin_wasm_sub_saturate_s_i16x8, "V8sV8sV8s", "nc", 
"simd128")
-TARGET_BUILTIN(__builtin_wasm_sub_saturate_u_i16x8, "V8sV8sV8s", "nc", 
"simd128")
+TARGET_BUILTIN(__builtin_wasm_sub_saturate_u_i16x8, "V8UsV8UsV8Us", "nc", 
"simd128")
 
-TARGET_BUILTIN(__builtin_wasm_abs_i8x16, "V16cV16c", "nc", "simd128")
+TARGET_BUILTIN(__builtin_wasm_abs_i8x16, "V16ScV16Sc", "nc", "simd128")
 TARGET_BUILTIN(__builtin_wasm_abs_i16x8, "V8sV8s", "nc", "simd128")
 TARGET_BUILTIN(__builtin_wasm_abs_i32x4, "V4iV4i", "nc", "simd128")
 
-TARGET_BUILTIN(__builtin_wasm_min_s_i8x16, "V16cV16cV16c", "nc", "simd128")
-TARGET_BUILTIN(__builtin_wasm_min_u_i8x16, "V16cV16cV16c", "nc", "simd128")
-TARGET_BUILTIN(__builtin_wasm_max_s_i8x16, "V16cV16cV16c", "nc", "simd128")
-TARGET_BUILTIN(__builtin_wasm_max_u_i8x16, "V16cV16cV16c", "nc", "simd128")
+TARGET_BUILTIN(__builtin_wasm_min_s_i8x16, "V16ScV16ScV16Sc", "nc", "simd128")

[PATCH] D85074: [WebAssembly] Use "signed char" instead of "char" in SIMD intrinsics.

[sunfishcode 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 rG47f7174ffa71: [WebAssembly] Use "signed char" 
instead of "char" in SIMD intrinsics. (authored by sunfishcode).

Changed prior to commit:
  https://reviews.llvm.org/D85074?vs=282608&id=283004#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85074

Files:
  clang/include/clang/Basic/BuiltinsWebAssembly.def
  clang/lib/Headers/wasm_simd128.h
  clang/test/CodeGen/builtins-wasm.c

Index: clang/test/CodeGen/builtins-wasm.c
===
--- clang/test/CodeGen/builtins-wasm.c
+++ clang/test/CodeGen/builtins-wasm.c
@@ -3,7 +3,7 @@
 // RUN: not %clang_cc1 -triple wasm64-unknown-unknown -target-feature +nontrapping-fptoint -target-feature +exception-handling -target-feature +bulk-memory -target-feature +atomics -flax-vector-conversions=none -O3 -emit-llvm -o - %s 2>&1 | FileCheck %s -check-prefixes MISSING-SIMD
 
 // SIMD convenience types
-typedef char i8x16 __attribute((vector_size(16)));
+typedef signed char i8x16 __attribute((vector_size(16)));
 typedef short i16x8 __attribute((vector_size(16)));
 typedef int i32x4 __attribute((vector_size(16)));
 typedef long long i64x2 __attribute((vector_size(16)));
@@ -201,7 +201,7 @@
   // WEBASSEMBLY-NEXT: ret
 }
 
-int extract_lane_u_i8x16(i8x16 v) {
+int extract_lane_u_i8x16(u8x16 v) {
   return __builtin_wasm_extract_lane_u_i8x16(v, 13);
   // WEBASSEMBLY: extractelement <16 x i8> %v, i32 13
   // WEBASSEMBLY-NEXT: zext
@@ -215,7 +215,7 @@
   // WEBASSEMBLY-NEXT: ret
 }
 
-int extract_lane_u_i16x8(i16x8 v) {
+int extract_lane_u_i16x8(u16x8 v) {
   return __builtin_wasm_extract_lane_u_i16x8(v, 7);
   // WEBASSEMBLY: extractelement <8 x i16> %v, i32 7
   // WEBASSEMBLY-NEXT: zext
@@ -291,7 +291,7 @@
   // WEBASSEMBLY-NEXT: ret
 }
 
-i8x16 add_saturate_u_i8x16(i8x16 x, i8x16 y) {
+u8x16 add_saturate_u_i8x16(u8x16 x, u8x16 y) {
   return __builtin_wasm_add_saturate_u_i8x16(x, y);
   // WEBASSEMBLY: call <16 x i8> @llvm.uadd.sat.v16i8(
   // WEBASSEMBLY-SAME: <16 x i8> %x, <16 x i8> %y)
@@ -305,7 +305,7 @@
   // WEBASSEMBLY-NEXT: ret
 }
 
-i16x8 add_saturate_u_i16x8(i16x8 x, i16x8 y) {
+u16x8 add_saturate_u_i16x8(u16x8 x, u16x8 y) {
   return __builtin_wasm_add_saturate_u_i16x8(x, y);
   // WEBASSEMBLY: call <8 x i16> @llvm.uadd.sat.v8i16(
   // WEBASSEMBLY-SAME: <8 x i16> %x, <8 x i16> %y)
@@ -319,7 +319,7 @@
   // WEBASSEMBLY-NEXT: ret
 }
 
-i8x16 sub_saturate_u_i8x16(i8x16 x, i8x16 y) {
+u8x16 sub_saturate_u_i8x16(u8x16 x, u8x16 y) {
   return __builtin_wasm_sub_saturate_u_i8x16(x, y);
   // WEBASSEMBLY: call <16 x i8> @llvm.wasm.sub.saturate.unsigned.v16i8(
   // WEBASSEMBLY-SAME: <16 x i8> %x, <16 x i8> %y)
@@ -357,7 +357,7 @@
   // WEBASSEMBLY-NEXT: ret <16 x i8> %1
 }
 
-i8x16 min_u_i8x16(i8x16 x, i8x16 y) {
+u8x16 min_u_i8x16(u8x16 x, u8x16 y) {
   return __builtin_wasm_min_u_i8x16(x, y);
   // WEBASSEMBLY: %0 = icmp ult <16 x i8> %x, %y
   // WEBASSEMBLY-NEXT: %1 = select <16 x i1> %0, <16 x i8> %x, <16 x i8> %y
@@ -371,7 +371,7 @@
   // WEBASSEMBLY-NEXT: ret <16 x i8> %1
 }
 
-i8x16 max_u_i8x16(i8x16 x, i8x16 y) {
+u8x16 max_u_i8x16(u8x16 x, u8x16 y) {
   return __builtin_wasm_max_u_i8x16(x, y);
   // WEBASSEMBLY: %0 = icmp ugt <16 x i8> %x, %y
   // WEBASSEMBLY-NEXT: %1 = select <16 x i1> %0, <16 x i8> %x, <16 x i8> %y
@@ -385,7 +385,7 @@
   // WEBASSEMBLY-NEXT: ret <8 x i16> %1
 }
 
-i16x8 min_u_i16x8(i16x8 x, i16x8 y) {
+u16x8 min_u_i16x8(u16x8 x, u16x8 y) {
   return __builtin_wasm_min_u_i16x8(x, y);
   // WEBASSEMBLY: %0 = icmp ult <8 x i16> %x, %y
   // WEBASSEMBLY-NEXT: %1 = select <8 x i1> %0, <8 x i16> %x, <8 x i16> %y
@@ -399,7 +399,7 @@
   // WEBASSEMBLY-NEXT: ret <8 x i16> %1
 }
 
-i16x8 max_u_i16x8(i16x8 x, i16x8 y) {
+u16x8 max_u_i16x8(u16x8 x, u16x8 y) {
   return __builtin_wasm_max_u_i16x8(x, y);
   // WEBASSEMBLY: %0 = icmp ugt <8 x i16> %x, %y
   // WEBASSEMBLY-NEXT: %1 = select <8 x i1> %0, <8 x i16> %x, <8 x i16> %y
@@ -413,7 +413,7 @@
   // WEBASSEMBLY-NEXT: ret <4 x i32> %1
 }
 
-i32x4 min_u_i32x4(i32x4 x, i32x4 y) {
+u32x4 min_u_i32x4(u32x4 x, u32x4 y) {
   return __builtin_wasm_min_u_i32x4(x, y);
   // WEBASSEMBLY: %0 = icmp ult <4 x i32> %x, %y
   // WEBASSEMBLY-NEXT: %1 = select <4 x i1> %0, <4 x i32> %x, <4 x i32> %y
@@ -427,7 +427,7 @@
   // WEBASSEMBLY-NEXT: ret <4 x i32> %1
 }
 
-i32x4 max_u_i32x4(i32x4 x, i32x4 y) {
+u32x4 max_u_i32x4(u32x4 x, u32x4 y) {
   return __builtin_wasm_max_u_i32x4(x, y);
   // WEBASSEMBLY: %0 = icmp ugt <4 x i32> %x, %y
   // WEBASSEMBLY-NEXT: %1 = select <4 x i1> %0, <4 x i32> %x, <4 x i32> %y
@@ -441,21 +441,21 @@
   // WEBASSEMBLY-NEXT: ret
 }
 
-i16x8 sub_saturate_u_i16x8(i16x8 x, i16x8 y) {
+u16x8 sub_saturate_u_i16x8(u16x8 x, u16x8 y) {
   return __builtin_wasm_sub_saturate_u_i16x8(x, y);
   // WEBASSEMBLY: call <8 x

[PATCH] D84534: [AIX] Static init frontend recovery and backend support

[Xiangling Liao via Phabricator via cfe-commits]

Xiangling_L added inline comments.



Comment at: llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp:1865
+if (isSpecialLLVMGlobalArrayForStaticInit(&G)) {
+  if (GlobalUniqueModuleId.empty()) {
+GlobalUniqueModuleId = getUniqueModuleId(&M);

jasonliu wrote:
> We will need to move this part of the if statement to the overrided 
> `emitXXStructorList` as well. (If we think overriding `emitXXStructorList` 
> and calling `emitSpecialLLVMGlobal ` directly is a good idea.)
`getUniqueModuleId` takes `Module` as a parameter, if we want to invoke this 
function inside of `emitXXStructorList` through `emitSpecialLLVMGlobal`, we 
have to change the interface of them, which seems not ideal.


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

https://reviews.llvm.org/D84534

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

[PATCH] D85231: Protect against filenames with no extension at all.

[Jonas Devlieghere via Phabricator via cfe-commits]

JDevlieghere added a comment.

Can you add a test that exercises this code path?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85231

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