[PATCH] D106005: [Docs] Define matrix initialisation in MatrixTypes documentation

2021-07-22 Thread Saurabh Jha via Phabricator via cfe-commits
SaurabhJha added inline comments.



Comment at: clang/docs/MatrixTypes.rst:279
+The number of constituent arrays must equal the number rows in the matrix type 
M and the number of elements
+in each constituent array must equal the number of columns in the matrix type.
+

rjmccall wrote:
> This is contradicted by your first example.  I think you want to say 
> something like
> 
> > A value of matrix type `M` can be initialized with an initializer list:
> >
> > (examples)
> >
> > If the initializer list is empty, all elements of the matrix are 
> > zero-initialized.  Otherwise, the initializer list must consist of 
> > `M::rows` initializer lists, each of which must consist of `M::columns` 
> > expressions, each of which is used to initialize the corresponding element 
> > of the matrix (that is, `m[i][j]` is initialized by the `j`th expression of 
> > the `i`th initializer list in the initializer).  Element designators are 
> > not allowed.
> 
> That's assuming you want to allow `{}`, but I think that's probably a good 
> idea.  At the very least, you already have to define how objects of static 
> storage duration are zero-initialized, and having a way to do that explicitly 
> always seems wise to me.
That sounds great @rjmccall, thanks for your suggestions.

I think I got confused between whether to allow `{}` but as you suggested, I 
think we should.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106005

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


[PATCH] D105083: [clangd] Ensure Ref::Container refers to an indexed symbol

2021-07-22 Thread Nathan Ridge via Phabricator via cfe-commits
nridge updated this revision to Diff 360714.
nridge marked 3 inline comments as done.
nridge added a comment.

Address review comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105083

Files:
  clang-tools-extra/clangd/index/SymbolCollector.cpp
  clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp
  clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp

Index: clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
===
--- clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
+++ clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
@@ -811,8 +811,7 @@
   };
   EXPECT_EQ(Container("ref1a"),
 findSymbol(Symbols, "f2").ID); // function body (call)
-  // FIXME: This is wrongly contained by fptr and not f2.
-  EXPECT_NE(Container("ref1b"),
+  EXPECT_EQ(Container("ref1b"),
 findSymbol(Symbols, "f2").ID); // function body (address-of)
   EXPECT_EQ(Container("ref2"),
 findSymbol(Symbols, "v1").ID); // variable initializer
Index: clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp
===
--- clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp
+++ clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp
@@ -26,6 +26,22 @@
 
 namespace clang {
 namespace clangd {
+
+llvm::raw_ostream &operator<<(llvm::raw_ostream &Stream,
+  const CallHierarchyItem &Item) {
+  return Stream << Item.name << "@" << Item.selectionRange;
+}
+
+llvm::raw_ostream &operator<<(llvm::raw_ostream &Stream,
+  const CallHierarchyIncomingCall &Call) {
+  Stream << "{ from: " << Call.from << ", ranges: [";
+  for (const auto &R : Call.fromRanges) {
+Stream << R;
+Stream << ", ";
+  }
+  return Stream << "] }";
+}
+
 namespace {
 
 using ::testing::AllOf;
@@ -252,6 +268,40 @@
   CheckCallHierarchy(*AST, CalleeC.point(), testPath("callee.cc"));
 }
 
+TEST(CallHierarchy, CallInLocalVarDecl) {
+  // Tests that local variable declarations are not treated as callers
+  // (they're not indexed, so they can't be represented as call hierarchy
+  // items); instead, the caller should be the containing function.
+  // However, namespace-scope variable declarations should be treated as
+  // callers because those are indexed and there is no enclosing entity
+  // that would be a useful caller.
+  Annotations Source(R"cpp(
+int call^ee();
+void caller1() {
+  $call1[[callee]]();
+}
+void caller2() {
+  int localVar = $call2[[callee]]();
+}
+int caller3 = $call3[[callee]]();
+  )cpp");
+  TestTU TU = TestTU::withCode(Source.code());
+  auto AST = TU.build();
+  auto Index = TU.index();
+
+  std::vector Items =
+  prepareCallHierarchy(AST, Source.point(), testPath(TU.Filename));
+  ASSERT_THAT(Items, ElementsAre(WithName("callee")));
+
+  auto Incoming = incomingCalls(Items[0], Index.get());
+  ASSERT_THAT(
+  Incoming,
+  ElementsAre(
+  AllOf(From(WithName("caller1")), FromRanges(Source.range("call1"))),
+  AllOf(From(WithName("caller2")), FromRanges(Source.range("call2"))),
+  AllOf(From(WithName("caller3")), FromRanges(Source.range("call3");
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/index/SymbolCollector.cpp
===
--- clang-tools-extra/clangd/index/SymbolCollector.cpp
+++ clang-tools-extra/clangd/index/SymbolCollector.cpp
@@ -152,6 +152,31 @@
   return None;
 }
 
+// Given a ref contained in enclosing decl `Enclosing`, return
+// the decl that should be used as that ref's Ref::Container. This is
+// usually `Enclosing` itself, but in cases where `Enclosing` is not
+// indexed, we walk further up because Ref::Container should always be
+// an indexed symbol.
+// Note: we don't use DeclContext as the container as in some cases
+// it's useful to use a Decl which is not a DeclContext. For example,
+// for a ref occurring in the initializer of a namespace-scope variable,
+// it's useful to use that variable as the container, as otherwise the
+// next enclosing DeclContext would be a NamespaceDecl or TranslationUnitDecl,
+// which are both not indexed and less granular than we'd like for use cases
+// like call hierarchy.
+const Decl *getRefContainer(const Decl *Enclosing,
+const SymbolCollector::Options &Opts) {
+  while (Enclosing) {
+const auto *ND = dyn_cast(Enclosing);
+if (ND && SymbolCollector::shouldCollectSymbol(*ND, ND->getASTContext(),
+   Opts, true)) {
+  break;
+}
+Enclosing = dyn_cast_or_null(Enclosing->getDeclContext());
+  }
+  return Enclosing;
+}
+
 } // namespace
 
 // Encapsulates decisions about how to record

[clang-tools-extra] f443793 - [clangd] Ensure Ref::Container refers to an indexed symbol

2021-07-22 Thread Nathan Ridge via cfe-commits

Author: Nathan Ridge
Date: 2021-07-22T03:33:40-04:00
New Revision: f443793d26c39a78cfedea5a8cc2ad23e1253d84

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

LOG: [clangd] Ensure Ref::Container refers to an indexed symbol

Fixes https://github.com/clangd/clangd/issues/806

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

Added: 


Modified: 
clang-tools-extra/clangd/index/SymbolCollector.cpp
clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp
clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/index/SymbolCollector.cpp 
b/clang-tools-extra/clangd/index/SymbolCollector.cpp
index 9211dd3eb48a5..0591c5113a23a 100644
--- a/clang-tools-extra/clangd/index/SymbolCollector.cpp
+++ b/clang-tools-extra/clangd/index/SymbolCollector.cpp
@@ -152,6 +152,31 @@ llvm::Optional indexableRelation(const 
index::SymbolRelation &R) {
   return None;
 }
 
+// Given a ref contained in enclosing decl `Enclosing`, return
+// the decl that should be used as that ref's Ref::Container. This is
+// usually `Enclosing` itself, but in cases where `Enclosing` is not
+// indexed, we walk further up because Ref::Container should always be
+// an indexed symbol.
+// Note: we don't use DeclContext as the container as in some cases
+// it's useful to use a Decl which is not a DeclContext. For example,
+// for a ref occurring in the initializer of a namespace-scope variable,
+// it's useful to use that variable as the container, as otherwise the
+// next enclosing DeclContext would be a NamespaceDecl or TranslationUnitDecl,
+// which are both not indexed and less granular than we'd like for use cases
+// like call hierarchy.
+const Decl *getRefContainer(const Decl *Enclosing,
+const SymbolCollector::Options &Opts) {
+  while (Enclosing) {
+const auto *ND = dyn_cast(Enclosing);
+if (ND && SymbolCollector::shouldCollectSymbol(*ND, ND->getASTContext(),
+   Opts, true)) {
+  break;
+}
+Enclosing = dyn_cast_or_null(Enclosing->getDeclContext());
+  }
+  return Enclosing;
+}
+
 } // namespace
 
 // Encapsulates decisions about how to record header paths in the index,
@@ -478,8 +503,8 @@ bool SymbolCollector::handleDeclOccurrence(
   !isa(ND) &&
   (Opts.RefsInHeaders ||
SM.getFileID(SM.getFileLoc(Loc)) == SM.getMainFileID()))
-DeclRefs[ND].push_back(
-SymbolRef{SM.getFileLoc(Loc), Roles, ASTNode.Parent});
+DeclRefs[ND].push_back(SymbolRef{SM.getFileLoc(Loc), Roles,
+ getRefContainer(ASTNode.Parent, Opts)});
   // Don't continue indexing if this is a mere reference.
   if (IsOnlyRef)
 return true;

diff  --git a/clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp 
b/clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp
index 8b5069d8dae80..6f63ea2bc18b3 100644
--- a/clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp
+++ b/clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp
@@ -26,6 +26,22 @@
 
 namespace clang {
 namespace clangd {
+
+llvm::raw_ostream &operator<<(llvm::raw_ostream &Stream,
+  const CallHierarchyItem &Item) {
+  return Stream << Item.name << "@" << Item.selectionRange;
+}
+
+llvm::raw_ostream &operator<<(llvm::raw_ostream &Stream,
+  const CallHierarchyIncomingCall &Call) {
+  Stream << "{ from: " << Call.from << ", ranges: [";
+  for (const auto &R : Call.fromRanges) {
+Stream << R;
+Stream << ", ";
+  }
+  return Stream << "] }";
+}
+
 namespace {
 
 using ::testing::AllOf;
@@ -252,6 +268,40 @@ TEST(CallHierarchy, IncomingMultiFile) {
   CheckCallHierarchy(*AST, CalleeC.point(), testPath("callee.cc"));
 }
 
+TEST(CallHierarchy, CallInLocalVarDecl) {
+  // Tests that local variable declarations are not treated as callers
+  // (they're not indexed, so they can't be represented as call hierarchy
+  // items); instead, the caller should be the containing function.
+  // However, namespace-scope variable declarations should be treated as
+  // callers because those are indexed and there is no enclosing entity
+  // that would be a useful caller.
+  Annotations Source(R"cpp(
+int call^ee();
+void caller1() {
+  $call1[[callee]]();
+}
+void caller2() {
+  int localVar = $call2[[callee]]();
+}
+int caller3 = $call3[[callee]]();
+  )cpp");
+  TestTU TU = TestTU::withCode(Source.code());
+  auto AST = TU.build();
+  auto Index = TU.index();
+
+  std::vector Items =
+  prepareCallHierarchy(AST, Source.point(), testPath(TU.Filename));
+  ASSERT_THAT(Items, ElementsAre(WithName("callee")));
+
+  auto Incoming = incomingCalls(Items[0], Index.get());

[PATCH] D105083: [clangd] Ensure Ref::Container refers to an indexed symbol

2021-07-22 Thread Nathan Ridge 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 rGf443793d26c3: [clangd] Ensure Ref::Container refers to an 
indexed symbol (authored by nridge).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105083

Files:
  clang-tools-extra/clangd/index/SymbolCollector.cpp
  clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp
  clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp

Index: clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
===
--- clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
+++ clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
@@ -811,8 +811,7 @@
   };
   EXPECT_EQ(Container("ref1a"),
 findSymbol(Symbols, "f2").ID); // function body (call)
-  // FIXME: This is wrongly contained by fptr and not f2.
-  EXPECT_NE(Container("ref1b"),
+  EXPECT_EQ(Container("ref1b"),
 findSymbol(Symbols, "f2").ID); // function body (address-of)
   EXPECT_EQ(Container("ref2"),
 findSymbol(Symbols, "v1").ID); // variable initializer
Index: clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp
===
--- clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp
+++ clang-tools-extra/clangd/unittests/CallHierarchyTests.cpp
@@ -26,6 +26,22 @@
 
 namespace clang {
 namespace clangd {
+
+llvm::raw_ostream &operator<<(llvm::raw_ostream &Stream,
+  const CallHierarchyItem &Item) {
+  return Stream << Item.name << "@" << Item.selectionRange;
+}
+
+llvm::raw_ostream &operator<<(llvm::raw_ostream &Stream,
+  const CallHierarchyIncomingCall &Call) {
+  Stream << "{ from: " << Call.from << ", ranges: [";
+  for (const auto &R : Call.fromRanges) {
+Stream << R;
+Stream << ", ";
+  }
+  return Stream << "] }";
+}
+
 namespace {
 
 using ::testing::AllOf;
@@ -252,6 +268,40 @@
   CheckCallHierarchy(*AST, CalleeC.point(), testPath("callee.cc"));
 }
 
+TEST(CallHierarchy, CallInLocalVarDecl) {
+  // Tests that local variable declarations are not treated as callers
+  // (they're not indexed, so they can't be represented as call hierarchy
+  // items); instead, the caller should be the containing function.
+  // However, namespace-scope variable declarations should be treated as
+  // callers because those are indexed and there is no enclosing entity
+  // that would be a useful caller.
+  Annotations Source(R"cpp(
+int call^ee();
+void caller1() {
+  $call1[[callee]]();
+}
+void caller2() {
+  int localVar = $call2[[callee]]();
+}
+int caller3 = $call3[[callee]]();
+  )cpp");
+  TestTU TU = TestTU::withCode(Source.code());
+  auto AST = TU.build();
+  auto Index = TU.index();
+
+  std::vector Items =
+  prepareCallHierarchy(AST, Source.point(), testPath(TU.Filename));
+  ASSERT_THAT(Items, ElementsAre(WithName("callee")));
+
+  auto Incoming = incomingCalls(Items[0], Index.get());
+  ASSERT_THAT(
+  Incoming,
+  ElementsAre(
+  AllOf(From(WithName("caller1")), FromRanges(Source.range("call1"))),
+  AllOf(From(WithName("caller2")), FromRanges(Source.range("call2"))),
+  AllOf(From(WithName("caller3")), FromRanges(Source.range("call3");
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/index/SymbolCollector.cpp
===
--- clang-tools-extra/clangd/index/SymbolCollector.cpp
+++ clang-tools-extra/clangd/index/SymbolCollector.cpp
@@ -152,6 +152,31 @@
   return None;
 }
 
+// Given a ref contained in enclosing decl `Enclosing`, return
+// the decl that should be used as that ref's Ref::Container. This is
+// usually `Enclosing` itself, but in cases where `Enclosing` is not
+// indexed, we walk further up because Ref::Container should always be
+// an indexed symbol.
+// Note: we don't use DeclContext as the container as in some cases
+// it's useful to use a Decl which is not a DeclContext. For example,
+// for a ref occurring in the initializer of a namespace-scope variable,
+// it's useful to use that variable as the container, as otherwise the
+// next enclosing DeclContext would be a NamespaceDecl or TranslationUnitDecl,
+// which are both not indexed and less granular than we'd like for use cases
+// like call hierarchy.
+const Decl *getRefContainer(const Decl *Enclosing,
+const SymbolCollector::Options &Opts) {
+  while (Enclosing) {
+const auto *ND = dyn_cast(Enclosing);
+if (ND && SymbolCollector::shouldCollectSymbol(*ND, ND->getASTContext(),
+   Opts, true)) {
+  break;
+}
+Enclosing = dyn_cast_or_null(Enclosing->getDe

[PATCH] D106005: [Docs] Define matrix initialisation in MatrixTypes documentation

2021-07-22 Thread Saurabh Jha via Phabricator via cfe-commits
SaurabhJha updated this revision to Diff 360716.
SaurabhJha added a comment.

Address second round of comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106005

Files:
  clang/docs/MatrixTypes.rst


Index: clang/docs/MatrixTypes.rst
===
--- clang/docs/MatrixTypes.rst
+++ clang/docs/MatrixTypes.rst
@@ -266,6 +266,20 @@
   }
 
 
+Initialization Syntax
+-
+A value of a matrix type M can be initialized with an initializer list:
+
+.. code-block:: c++
+
+  constexpr M m1 = {};
+  constexpr M m2 = {{a, b, c}, {d, e, f}};
+
+If the initializer list is empty, all elements of the matrix are 
zero-initialized. Otherwise, the initializer list
+must consist of M::rows initializer lists, each of which must consist of 
M::columns expressions, each of which is used
+to initialize the corresponding element of the matrix. For example, m[i][j] is 
initialized by the jth expression of the
+ith initializer list in the initializer. Element designators are not allowed.
+
 TODOs
 -
 
@@ -274,9 +288,6 @@
 convenient. The alternative is using template deduction to extract this
 information. Also add spelling for C.
 
-Future Work: Initialization syntax.
-
-
 Decisions for the Implementation in Clang
 =
 


Index: clang/docs/MatrixTypes.rst
===
--- clang/docs/MatrixTypes.rst
+++ clang/docs/MatrixTypes.rst
@@ -266,6 +266,20 @@
   }
 
 
+Initialization Syntax
+-
+A value of a matrix type M can be initialized with an initializer list:
+
+.. code-block:: c++
+
+  constexpr M m1 = {};
+  constexpr M m2 = {{a, b, c}, {d, e, f}};
+
+If the initializer list is empty, all elements of the matrix are zero-initialized. Otherwise, the initializer list
+must consist of M::rows initializer lists, each of which must consist of M::columns expressions, each of which is used
+to initialize the corresponding element of the matrix. For example, m[i][j] is initialized by the jth expression of the
+ith initializer list in the initializer. Element designators are not allowed.
+
 TODOs
 -
 
@@ -274,9 +288,6 @@
 convenient. The alternative is using template deduction to extract this
 information. Also add spelling for C.
 
-Future Work: Initialization syntax.
-
-
 Decisions for the Implementation in Clang
 =
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D106527: [clangd] Canonicalize compile flags before applying edits

2021-07-22 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet created this revision.
kadircet added a reviewer: sammccall.
Herald added subscribers: usaxena95, arphaman.
kadircet requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang-tools-extra.

Pushes input for the compile action to the end while separating with a
`--` before applying other manglings. This ensures edits that effect only the
arguments that come after them works, like changing parse language via -x.

Fixes https://github.com/clangd/clangd/issues/555.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D106527

Files:
  clang-tools-extra/clangd/CompileCommands.cpp
  clang-tools-extra/clangd/test/did-change-configuration-params.test
  clang-tools-extra/clangd/unittests/BackgroundIndexTests.cpp
  clang-tools-extra/clangd/unittests/CompileCommandsTests.cpp

Index: clang-tools-extra/clangd/unittests/CompileCommandsTests.cpp
===
--- clang-tools-extra/clangd/unittests/CompileCommandsTests.cpp
+++ clang-tools-extra/clangd/unittests/CompileCommandsTests.cpp
@@ -11,6 +11,7 @@
 #include "TestFS.h"
 #include "support/Context.h"
 
+#include "clang/Tooling/ArgumentsAdjusters.h"
 #include "llvm/ADT/ScopeExit.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/Support/FileSystem.h"
@@ -199,13 +200,15 @@
 for (char &C : Arg)
   C = llvm::toUpper(C);
 });
-Cfg.CompileFlags.Edits.push_back(
-[](std::vector &Argv) { Argv.push_back("--hello"); });
+Cfg.CompileFlags.Edits.push_back([](std::vector &Argv) {
+  Argv = tooling::getInsertArgumentAdjuster("--hello")(Argv, "");
+});
 WithContextValue WithConfig(Config::Key, std::move(Cfg));
 Mangler.adjust(Cmd);
   }
-  // Edits are applied in given order and before other mangling.
-  EXPECT_THAT(Cmd, ElementsAre(_, "FOO.CC", "--hello", "-fsyntax-only"));
+  // Edits are applied in given order and before other mangling and they always
+  // go before filename.
+  EXPECT_THAT(Cmd, ElementsAre(_, "--hello", "-fsyntax-only", "--", "FOO.CC"));
 }
 
 static std::string strip(llvm::StringRef Arg, llvm::StringRef Argv) {
Index: clang-tools-extra/clangd/unittests/BackgroundIndexTests.cpp
===
--- clang-tools-extra/clangd/unittests/BackgroundIndexTests.cpp
+++ clang-tools-extra/clangd/unittests/BackgroundIndexTests.cpp
@@ -133,8 +133,9 @@
   Opts.ContextProvider = [](PathRef P) {
 Config C;
 if (P.endswith("foo.cpp"))
-  C.CompileFlags.Edits.push_back(
-  [](std::vector &Argv) { Argv.push_back("-Done=two"); });
+  C.CompileFlags.Edits.push_back([](std::vector &Argv) {
+Argv = tooling::getInsertArgumentAdjuster("-Done=two")(Argv, "");
+  });
 if (P.endswith("baz.cpp"))
   C.Index.Background = Config::BackgroundPolicy::Skip;
 return Context::current().derive(Config::Key, std::move(C));
Index: clang-tools-extra/clangd/test/did-change-configuration-params.test
===
--- clang-tools-extra/clangd/test/did-change-configuration-params.test
+++ clang-tools-extra/clangd/test/did-change-configuration-params.test
@@ -48,7 +48,7 @@
 #
 # ERR: ASTWorker building file {{.*}}foo.c version 0 with command
 # ERR: [{{.*}}clangd-test2]
-# ERR: clang -c foo.c -Wall -Werror
+# ERR: clang -c -Wall -Werror {{.*}} -- foo.c
 ---
 {"jsonrpc":"2.0","id":5,"method":"shutdown"}
 ---
Index: clang-tools-extra/clangd/CompileCommands.cpp
===
--- clang-tools-extra/clangd/CompileCommands.cpp
+++ clang-tools-extra/clangd/CompileCommands.cpp
@@ -9,9 +9,12 @@
 #include "CompileCommands.h"
 #include "Config.h"
 #include "support/Logger.h"
+#include "support/Trace.h"
 #include "clang/Driver/Options.h"
 #include "clang/Frontend/CompilerInvocation.h"
 #include "clang/Tooling/ArgumentsAdjusters.h"
+#include "llvm/ADT/SmallVector.h"
+#include "llvm/Option/ArgList.h"
 #include "llvm/Option/Option.h"
 #include "llvm/Support/Allocator.h"
 #include "llvm/Support/Debug.h"
@@ -185,23 +188,36 @@
   return Result;
 }
 
-CommandMangler CommandMangler::forTests() {
-  return CommandMangler();
-}
+CommandMangler CommandMangler::forTests() { return CommandMangler(); }
 
 void CommandMangler::adjust(std::vector &Cmd) const {
+  trace::Span S("AdjustCompileFlags");
+  auto &OptTable = clang::driver::getDriverOptTable();
+  // OriginalArgs needs to outlive ArgList.
+  llvm::SmallVector OriginalArgs;
+  OriginalArgs.reserve(Cmd.size());
+  for (const std::string &S : Cmd)
+OriginalArgs.push_back(S.c_str());
+  // ParseArgs propagates missig arg/opt counts on error, but preserves
+  // everything it could parse in ArgList. So we just ignore those counts.
+  unsigned IgnoredCount;
+  auto ArgList = OptTable.ParseArgs(OriginalArgs, IgnoredCount, IgnoredCount);
+
+  // Move the inputs to the end, separa

[PATCH] D106344: [PowerPC] Implement XL compatible behavior of __compare_and_swap

2021-07-22 Thread Kai Luo via Phabricator via cfe-commits
lkail updated this revision to Diff 360721.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106344

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-ppc-xlcompat-cas.c
  llvm/test/CodeGen/PowerPC/opt-builtins-ppc-xlcompat-cas.ll

Index: llvm/test/CodeGen/PowerPC/opt-builtins-ppc-xlcompat-cas.ll
===
--- /dev/null
+++ llvm/test/CodeGen/PowerPC/opt-builtins-ppc-xlcompat-cas.ll
@@ -0,0 +1,70 @@
+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
+; RUN: opt -enable-new-pm=1 -S -passes='default' %s -o - | FileCheck %s
+define void @test_builtin_ppc_compare_and_swaplp(i64 %a, i64 %b, i64 %c) {
+; CHECK-LABEL: @test_builtin_ppc_compare_and_swaplp(
+; CHECK-NEXT:  entry:
+; CHECK-NEXT:[[A_ADDR:%.*]] = alloca i64, align 8
+; CHECK-NEXT:store i64 [[A:%.*]], i64* [[A_ADDR]], align 8
+; CHECK-NEXT:[[TMP0:%.*]] = cmpxchg weak volatile i64* [[A_ADDR]], i64 [[B:%.*]], i64 [[C:%.*]] monotonic monotonic, align 8
+; CHECK-NEXT:ret void
+;
+entry:
+  %a.addr = alloca i64, align 8
+  %b.addr = alloca i64, align 8
+  %c.addr = alloca i64, align 8
+  store i64 %a, i64* %a.addr, align 8
+  store i64 %b, i64* %b.addr, align 8
+  store i64 %c, i64* %c.addr, align 8
+  %0 = load i64, i64* %c.addr, align 8
+  %1 = load i64, i64* %b.addr, align 8
+  %2 = cmpxchg weak volatile i64* %a.addr, i64 %1, i64 %0 monotonic monotonic, align 8
+  %3 = extractvalue { i64, i1 } %2, 0
+  %4 = extractvalue { i64, i1 } %2, 1
+  store i64 %3, i64* %b.addr, align 8
+  ret void
+}
+
+define dso_local void @test_builtin_ppc_compare_and_swaplp_loop(i64* %a) {
+; CHECK-LABEL: @test_builtin_ppc_compare_and_swaplp_loop(
+; CHECK-NEXT:  entry:
+; CHECK-NEXT:[[CALL:%.*]] = tail call i64 bitcast (i64 (...)* @bar to i64 ()*)()
+; CHECK-NEXT:br label [[DO_BODY:%.*]]
+; CHECK:   do.body:
+; CHECK-NEXT:[[X_0:%.*]] = phi i64 [ [[CALL]], [[ENTRY:%.*]] ], [ [[TMP1:%.*]], [[DO_BODY]] ]
+; CHECK-NEXT:[[ADD:%.*]] = add nsw i64 [[X_0]], 1
+; CHECK-NEXT:[[TMP0:%.*]] = cmpxchg weak volatile i64* [[A:%.*]], i64 [[X_0]], i64 [[ADD]] monotonic monotonic, align 8
+; CHECK-NEXT:[[TMP1]] = extractvalue { i64, i1 } [[TMP0]], 0
+; CHECK-NEXT:[[TMP2:%.*]] = extractvalue { i64, i1 } [[TMP0]], 1
+; CHECK-NEXT:br i1 [[TMP2]], label [[DO_BODY]], label [[DO_END:%.*]]
+; CHECK:   do.end:
+; CHECK-NEXT:ret void
+;
+entry:
+  %a.addr = alloca i64*, align 8
+  %x = alloca i64, align 8
+  store i64* %a, i64** %a.addr, align 8
+  %call = call i64 bitcast (i64 (...)* @bar to i64 ()*)()
+  store i64 %call, i64* %x, align 8
+  br label %do.body
+
+do.body:  ; preds = %do.cond, %entry
+  br label %do.cond
+
+do.cond:  ; preds = %do.body
+  %0 = load i64*, i64** %a.addr, align 8
+  %1 = load i64, i64* %x, align 8
+  %add = add nsw i64 %1, 1
+  %2 = load i64*, i64** %a.addr, align 8
+  %3 = load i64, i64* %x, align 8
+  %4 = cmpxchg weak volatile i64* %2, i64 %3, i64 %add monotonic monotonic, align 8
+  %5 = extractvalue { i64, i1 } %4, 0
+  %6 = extractvalue { i64, i1 } %4, 1
+  store i64 %5, i64* %x, align 8
+  %tobool = icmp ne i1 %6, false
+  br i1 %tobool, label %do.body, label %do.end
+
+do.end:   ; preds = %do.cond
+  ret void
+}
+
+declare i64 @bar(...)
Index: clang/test/CodeGen/builtins-ppc-xlcompat-cas.c
===
--- clang/test/CodeGen/builtins-ppc-xlcompat-cas.c
+++ clang/test/CodeGen/builtins-ppc-xlcompat-cas.c
@@ -19,6 +19,7 @@
 // CHECK-NEXT:[[TMP2:%.*]] = cmpxchg weak volatile i32* [[A_ADDR]], i32 [[TMP1]], i32 [[TMP0]] monotonic monotonic, align 4
 // CHECK-NEXT:[[TMP3:%.*]] = extractvalue { i32, i1 } [[TMP2]], 0
 // CHECK-NEXT:[[TMP4:%.*]] = extractvalue { i32, i1 } [[TMP2]], 1
+// CHECK-NEXT:store i32 [[TMP3]], i32* [[B_ADDR]], align 4
 // CHECK-NEXT:ret void
 //
 void test_builtin_ppc_compare_and_swap(int a, int b, int c) {
@@ -39,6 +40,7 @@
 // CHECK-NEXT:[[TMP2:%.*]] = cmpxchg weak volatile i64* [[A_ADDR]], i64 [[TMP1]], i64 [[TMP0]] monotonic monotonic, align 8
 // CHECK-NEXT:[[TMP3:%.*]] = extractvalue { i64, i1 } [[TMP2]], 0
 // CHECK-NEXT:[[TMP4:%.*]] = extractvalue { i64, i1 } [[TMP2]], 1
+// CHECK-NEXT:store i64 [[TMP3]], i64* [[B_ADDR]], align 8
 // CHECK-NEXT:ret void
 //
 void test_builtin_ppc_compare_and_swaplp(long a, long b, long c) {
Index: clang/lib/CodeGen/CGBuiltin.cpp
===
--- clang/lib/CodeGen/CGBuiltin.cpp
+++ clang/lib/CodeGen/CGBuiltin.cpp
@@ -15662,6 +15662,15 @@
 auto Pair = EmitAtomicCompareExchange(
 LV, RValue::get(OldVal), RValue::get(Ops[2]), E->getExprLoc(),
 llvm::AtomicOrdering::Monotonic, llvm::Atomic

[PATCH] D105690: [RISCV] Rename assembler mnemonic of unordered floating-point reductions for v1.0-rc change

2021-07-22 Thread Jianjian Guan via Phabricator via cfe-commits
jacquesguan added a comment.

Ping.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105690

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


[PATCH] D106347: [PoC][RISCV] Encode arch information in a new module flag meatadata 'riscv-isa-bits'.

2021-07-22 Thread Zakk Chen via Phabricator via cfe-commits
khchen updated this revision to Diff 360723.
khchen added a comment.

store target-features string as module flag.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106347

Files:
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/CodeGen/RISCV/riscv-metadata-isa-features-empty-target-feature.cpp
  clang/test/CodeGen/RISCV/riscv-metadata-isa-features-ifunc.c
  clang/test/CodeGen/RISCV/riscv-metadata-isa-features.c
  llvm/include/llvm/Support/RISCVISAInfo.h
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVTargetStreamer.cpp
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVTargetStreamer.h
  llvm/lib/Target/RISCV/RISCVAsmPrinter.cpp
  llvm/test/CodeGen/RISCV/riscv-isa-features.ll

Index: llvm/test/CodeGen/RISCV/riscv-isa-features.ll
===
--- /dev/null
+++ llvm/test/CodeGen/RISCV/riscv-isa-features.ll
@@ -0,0 +1,35 @@
+; RUN: llc -o - < %s | FileCheck %s
+; -mattr option would overwrite target-feature and module flag riscv-isa-features
+; RUN: llc -o - -mattr=+f,+d < %s | FileCheck %s -check-prefix=ISA-F-D
+; RUN: llc --filetype=obj -o - < %s | llvm-readelf -A - \
+; RUN:   | FileCheck %s -check-prefix=OBJFILE
+
+; CHECK:   .attribute  5, "rv64i2p0_m2p0_a2p0_c2p0"
+; ISA-F-D: .attribute  5, "rv64i2p0_f2p0_d2p0"
+
+; OBJFILE: TagName: arch
+; OBJFILE: Value: rv64i2p0_m2p0_a2p0_c2p0
+
+target triple = "riscv64-unknown-linux-gnu"
+
+define float @foo0(i32 %a) nounwind #0 {
+; CHECK:   call__floatsisf@plt
+; ISA-F-D: fcvt.s.wft0, a0
+  %conv = sitofp i32 %a to float
+  ret float %conv
+}
+
+define float @foo1(i32 %a) nounwind #1 {
+; CHECK:   fcvt.s.wft0, a0
+; ISA-F-D: fcvt.s.wft0, a0
+  %conv = sitofp i32 %a to float
+  ret float %conv
+}
+
+attributes #0 = { "target-features"="+64bit,+a,+c,+m"}
+attributes #1 = { "target-features"="+64bit,+a,+c,+d,+f,+m"}
+
+!llvm.module.flags = !{!0}
+
+!0 = !{i32 6, !"riscv-isa-features", !1}
+!1 = !{!"+a", !"+c", !"+m"}
Index: llvm/lib/Target/RISCV/RISCVAsmPrinter.cpp
===
--- llvm/lib/Target/RISCV/RISCVAsmPrinter.cpp
+++ llvm/lib/Target/RISCV/RISCVAsmPrinter.cpp
@@ -27,6 +27,7 @@
 #include "llvm/MC/MCInst.h"
 #include "llvm/MC/MCStreamer.h"
 #include "llvm/MC/MCSymbol.h"
+#include "llvm/Support/RISCVISAInfo.h"
 #include "llvm/Support/TargetRegistry.h"
 #include "llvm/Support/raw_ostream.h"
 using namespace llvm;
@@ -178,10 +179,27 @@
 }
 
 void RISCVAsmPrinter::emitStartOfAsmFile(Module &M) {
-  if (TM.getTargetTriple().isOSBinFormatELF())
-emitAttributes();
+  if (TM.getTargetTriple().isOSBinFormatELF()) {
+RISCVTargetStreamer &RTS =
+static_cast(*OutStreamer->getTargetStreamer());
+const auto *ISAFeatureNodes =
+dyn_cast_or_null(M.getModuleFlag("riscv-isa-features"));
+if (STI->getFeatureString().empty() && ISAFeatureNodes) {
+  std::vector Features;
+  for (const MDOperand &Feature : ISAFeatureNodes->operands()) {
+auto MAttr = cast(Feature.get())->getString();
+Features.push_back(MAttr.str());
+  }
+  unsigned XLEN =
+  TM.getTargetTriple().getArch() == llvm::Triple::riscv32 ? 32 : 64;
+  RISCVISAInfo ISAInfo;
+  ISAInfo.parse(XLEN, Features);
+  RTS.emitTargetAttributes(ISAInfo);
+} else {
+  RTS.emitTargetAttributes(*STI);
+}
+  }
 }
-
 void RISCVAsmPrinter::emitEndOfAsmFile(Module &M) {
   RISCVTargetStreamer &RTS =
   static_cast(*OutStreamer->getTargetStreamer());
Index: llvm/lib/Target/RISCV/MCTargetDesc/RISCVTargetStreamer.h
===
--- llvm/lib/Target/RISCV/MCTargetDesc/RISCVTargetStreamer.h
+++ llvm/lib/Target/RISCV/MCTargetDesc/RISCVTargetStreamer.h
@@ -11,6 +11,7 @@
 
 #include "llvm/MC/MCStreamer.h"
 #include "llvm/MC/MCSubtargetInfo.h"
+#include "llvm/Support/RISCVISAInfo.h"
 
 namespace llvm {
 
@@ -36,6 +37,7 @@
 StringRef StringValue);
 
   void emitTargetAttributes(const MCSubtargetInfo &STI);
+  void emitTargetAttributes(const RISCVISAInfo &ISAInfo);
 };
 
 // This part is for ascii assembly output
Index: llvm/lib/Target/RISCV/MCTargetDesc/RISCVTargetStreamer.cpp
===
--- llvm/lib/Target/RISCV/MCTargetDesc/RISCVTargetStreamer.cpp
+++ llvm/lib/Target/RISCV/MCTargetDesc/RISCVTargetStreamer.cpp
@@ -49,9 +49,15 @@
   unsigned XLen = STI.hasFeature(RISCV::Feature64Bit) ? 64 : 32;
   std::vector FeatureVector;
   RISCVFeatures::toFeatureVector(FeatureVector, STI.getFeatureBits());
-
   ISAInfo.parse(XLen, FeatureVector);
+  emitTargetAttributes(ISAInfo);
+}
 
+void RISCVTargetStreamer::emitTargetAttributes(const RISCVISAInfo &ISAInfo) {
+  if (ISAInfo.hasExtension("e"))
+emitAttribute(RISCVAttrs::STACK_ALIGN, RISCVAttrs::ALIGN_4);
+  el

[PATCH] D105354: [clang][AST] Add support for DecompositionDecl to ASTImporter.

2021-07-22 Thread Gabor Marton via Phabricator via cfe-commits
martong accepted this revision.
martong added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/lib/AST/ASTImporter.cpp:2305-2309
+  BindingDecl *ToD;
+  if (GetImportedOrCreateDecl(ToD, D, Importer.getToContext(), DC, Loc,
+  Name.getAsIdentifierInfo()))
+return ToD;
+

balazske wrote:
> shafik wrote:
> > martong wrote:
> > > So, we moved the import of the binding before importing the decomposition 
> > > decl to avoid an infinite recursion. But why can't we have an infinit 
> > > recursion this way?
> > > 
> > > Perhaps, it would be useful to have a test case that triggered the 
> > > infinity in case of the original order of the import calls.
> > Yes, I agree, I would also like to understand better why this avoids the 
> > infinite recursion problem, a test case would be helpful as well as an 
> > explanation of the steps that leads us to the problem.
> With the import at original place, in `VisitVarDecl` the bindings (which are 
> `BindingDecl`) are imported before create of the `DecompositionDecl` 
> instance, and in `VisitBindingDecl` the decomposition (a `DecompositionDecl` 
> that is `VarDecl`) is imported before create of the `BindingDecl` instance. 
> This causes the recursion with the most simple import of a 
> `DecompositionDecl`. This is triggered by the existing simple test (actually 
> I discovered the problem at the test failure). If the decomposition is 
> imported after create of the `BindingDecl` the same `BindingDecl` is not 
> imported again because it already exists.
Ok, thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105354

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


[PATCH] D106005: [Docs] Define matrix initialisation in MatrixTypes documentation

2021-07-22 Thread Florian Hahn via Phabricator via cfe-commits
fhahn added a comment.

Thank you very much for working on this! Are you planning on implementing the 
new specification as well? It would probably be good to land the update to the 
spec in close succession to the implementation, to avoid confusing users.




Comment at: clang/docs/MatrixTypes.rst:279
+The number of constituent arrays must equal the number rows in the matrix type 
M and the number of elements
+in each constituent array must equal the number of columns in the matrix type.
+

SaurabhJha wrote:
> rjmccall wrote:
> > This is contradicted by your first example.  I think you want to say 
> > something like
> > 
> > > A value of matrix type `M` can be initialized with an initializer list:
> > >
> > > (examples)
> > >
> > > If the initializer list is empty, all elements of the matrix are 
> > > zero-initialized.  Otherwise, the initializer list must consist of 
> > > `M::rows` initializer lists, each of which must consist of `M::columns` 
> > > expressions, each of which is used to initialize the corresponding 
> > > element of the matrix (that is, `m[i][j]` is initialized by the `j`th 
> > > expression of the `i`th initializer list in the initializer).  Element 
> > > designators are not allowed.
> > 
> > That's assuming you want to allow `{}`, but I think that's probably a good 
> > idea.  At the very least, you already have to define how objects of static 
> > storage duration are zero-initialized, and having a way to do that 
> > explicitly always seems wise to me.
> That sounds great @rjmccall, thanks for your suggestions.
> 
> I think I got confused between whether to allow `{}` but as you suggested, I 
> think we should.
That looks good, thanks! 

Another thing to consider is whether we would like to provide a convenient 
syntax to initialise all elements with an user-specified value, i.e. should we 
allow something like `m = {99};`, which would broadcast 99 to all elements of 
the matrix?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106005

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


[PATCH] D106528: [clangd] Improve performance of dex by 45-60%

2021-07-22 Thread Kirill Bobyrev via Phabricator via cfe-commits
kbobyrev created this revision.
kbobyrev added a reviewer: sammccall.
Herald added subscribers: usaxena95, arphaman.
kbobyrev requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added a project: clang-tools-extra.

Take full advantage of AND's iterator children size estimation: use early reset
in sync() and prevent large overhead. This change was tested on a comprehensive
query dataset. The performance boost increases with the average length of the
query, on small queries it is close to 45% but the longer they go the closer it
gets to 60% and beyond.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D106528

Files:
  clang-tools-extra/clangd/index/dex/Iterator.cpp


Index: clang-tools-extra/clangd/index/dex/Iterator.cpp
===
--- clang-tools-extra/clangd/index/dex/Iterator.cpp
+++ clang-tools-extra/clangd/index/dex/Iterator.cpp
@@ -109,6 +109,9 @@
 if (Child->peek() > SyncID) {
   SyncID = Child->peek();
   NeedsAdvance = true;
+  // Reset and make sure advanceTo happens much less frequently on
+  // large posting lists. This accounts for 45-60% performance boost.
+  break;
 }
   }
 } while (NeedsAdvance);


Index: clang-tools-extra/clangd/index/dex/Iterator.cpp
===
--- clang-tools-extra/clangd/index/dex/Iterator.cpp
+++ clang-tools-extra/clangd/index/dex/Iterator.cpp
@@ -109,6 +109,9 @@
 if (Child->peek() > SyncID) {
   SyncID = Child->peek();
   NeedsAdvance = true;
+  // Reset and make sure advanceTo happens much less frequently on
+  // large posting lists. This accounts for 45-60% performance boost.
+  break;
 }
   }
 } while (NeedsAdvance);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D105491: [clang] Use i64 for the !srcloc metadata on asm IR nodes.

2021-07-22 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

@lattner, thanks for the help. In this case, the real question is whether 
there's any use case for `!srcloc` that involves writing it out into a bitcode 
or IR file and then having a separate instance of clang load it back in again.

I think that no such case can possibly give a useful mapping back to the 
original source, because IR doesn't serialise the SourceManager that knows how 
to turn source locations back into a useful error message.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105491

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


[clang-tools-extra] 473eff1 - [clang-tidy] Fix crash and handle AttributedType in 'bugprone-easily-swappable-parameters'

2021-07-22 Thread via cfe-commits

Author: Whisperity
Date: 2021-07-22T10:20:17+02:00
New Revision: 473eff1c3057185758bf35f0c052a873b1bdb6a9

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

LOG: [clang-tidy] Fix crash and handle AttributedType in 
'bugprone-easily-swappable-parameters'

@vabridgers identified a way to crash the check by running on code that
involve `AttributedType`s. This patch fixes the check to first and
foremost not crash, but also improves the logic handling qualifiers.

If the types contain any additional (not just CVR) qualifiers that are
not the same, they will not be deemed mixable. The logic for CVR-Mixing
and the `QualifiersMix` check option remain unchanged.

Reviewed By: aaron.ballman, vabridgers

Differential Revision: http://reviews.llvm.org/D106361

Added: 


Modified: 
clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp

clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp

clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-qualifiermixing.cpp

Removed: 




diff  --git 
a/clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp 
b/clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp
index 8e972298adcec..3cb4734e553b0 100644
--- a/clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp
+++ b/clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp
@@ -470,17 +470,18 @@ struct MixData {
   }
 
   /// Add the specified qualifiers to the common type in the Mix.
-  MixData qualify(Qualifiers Quals) const {
-SplitQualType Split = CommonType.split();
-Split.Quals.addQualifiers(Quals);
-QualType CommonType{Split.Ty, Split.Quals.getAsOpaqueValue()};
+  MixData qualify(Qualifiers Quals, const ASTContext &Ctx) const {
+if (CommonType.isNull())
+  return *this;
+
+QualType NewCommonType = Ctx.getQualifiedType(CommonType, Quals);
 
 if (CreatedFromOneWayConversion) {
   MixData M{Flags, Conversion};
-  M.CommonType = CommonType;
+  M.CommonType = NewCommonType;
   return M;
 }
-return {Flags, CommonType, Conversion, ConversionRTL};
+return {Flags, NewCommonType, Conversion, ConversionRTL};
   }
 };
 
@@ -566,7 +567,41 @@ approximateImplicitConversion(const TheCheck &Check, 
QualType LType,
   ImplicitConversionModellingMode ImplicitMode);
 
 static inline bool isUselessSugar(const Type *T) {
-  return isa(T);
+  return isa(T);
+}
+
+/// Returns if the two types are qualified in a way that ever after equating or
+/// removing local CVR qualification, even if the unqualified types would mix,
+/// the qualified ones don't, because there are some other local qualifiers
+/// that aren't equal.
+static bool hasNonCVRMixabilityBreakingQualifiers(const ASTContext &Ctx,
+  QualType LType,
+  QualType RType) {
+  LLVM_DEBUG(
+  llvm::dbgs() << ">>> hasNonCVRMixabilityBreakingQualifiers for LType:\n";
+  LType.dump(llvm::dbgs(), Ctx); llvm::dbgs() << "\nand RType:\n";
+  RType.dump(llvm::dbgs(), Ctx); llvm::dbgs() << '\n';);
+  Qualifiers LQual = LType.getLocalQualifiers(),
+ RQual = RType.getLocalQualifiers();
+
+  // Strip potential CVR. That is handled by the check option QualifiersMix.
+  LQual.removeCVRQualifiers();
+  RQual.removeCVRQualifiers();
+
+  Qualifiers CommonQuals = Qualifiers::removeCommonQualifiers(LQual, RQual);
+  (void)CommonQuals;
+
+  LLVM_DEBUG(llvm::dbgs() << "--- hasNonCVRMixabilityBreakingQualifiers. "
+ "Removed common qualifiers: ";
+ CommonQuals.print(llvm::dbgs(), Ctx.getPrintingPolicy());
+ llvm::dbgs() << "\n\tremaining on LType: ";
+ LQual.print(llvm::dbgs(), Ctx.getPrintingPolicy());
+ llvm::dbgs() << "\n\tremaining on RType: ";
+ RQual.print(llvm::dbgs(), Ctx.getPrintingPolicy());
+ llvm::dbgs() << '\n';);
+
+  // If there are any remaining qualifiers, consider the two types distinct.
+  return LQual.hasQualifiers() || RQual.hasQualifiers();
 }
 
 /// Approximate the way how LType and RType might refer to "essentially the
@@ -585,12 +620,6 @@ calculateMixability(const TheCheck &Check, QualType LType, 
QualType RType,
   LLVM_DEBUG(llvm::dbgs() << ">>> calculateMixability for LType:\n";
  LType.dump(llvm::dbgs(), Ctx); llvm::dbgs() << "\nand RType:\n";
  RType.dump(llvm::dbgs(), Ctx); llvm::dbgs() << '\n';);
-
-  // Certain constructs match on the last catch-all getCanonicalType() 
equality,
-  // which is perhaps something not what we want. If this variable is true,
-  // the canonica

[PATCH] D106361: [clang-tidy] Fix crash and handle AttributedTypes in 'bugprone-easily-swappable-parameters'

2021-07-22 Thread Whisperity via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG473eff1c3057: [clang-tidy] Fix crash and handle 
AttributedType in 'bugprone-easily-swappable… (authored by whisperity).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106361

Files:
  clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp
  
clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-qualifiermixing.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-qualifiermixing.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-qualifiermixing.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-qualifiermixing.cpp
@@ -113,3 +113,14 @@
 // CHECK-MESSAGES: :[[@LINE-2]]:20: note: the first parameter in the range is 'Dest'
 // CHECK-MESSAGES: :[[@LINE-3]]:29: note: the last parameter in the range is 'Source'
 // CHECK-MESSAGES: :[[@LINE-4]]:26: note: 'const T *' and 'T *' parameters accept and bind the same kind of values
+
+void attributedParam2(__attribute__((address_space(256))) int *One,
+  const __attribute__((address_space(256))) MyInt1 *Two) {}
+// CHECK-MESSAGES: :[[@LINE-2]]:23: warning: 2 adjacent parameters of 'attributedParam2' of similar type are
+// CHECK-MESSAGES: :[[@LINE-3]]:64: note: the first parameter in the range is 'One'
+// CHECK-MESSAGES: :[[@LINE-3]]:73: note: the last parameter in the range is 'Two'
+// CHECK-MESSAGES: :[[@LINE-5]]:23: note: after resolving type aliases, the common type of '__attribute__((address_space(256))) int *' and 'const __attribute__((address_space(256))) MyInt1 *' is 'int'
+// CHECK-MESSAGES: :[[@LINE-5]]:23: note: '__attribute__((address_space(256))) int *' and 'const __attribute__((address_space(256))) MyInt1 *' parameters accept and bind the same kind of values
+// FIXME: The last diagnostic line is a bit bad: the common type should be a
+// pointer type -- it is not clear right now, how it would be possible to
+// properly wire a logic in that fixes it.
Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-easily-swappable-parameters-len2.cpp
@@ -346,3 +346,31 @@
 
 void functionPrototypeLosesNoexcept(void (*NonThrowing)() noexcept, void (*Throwing)()) {}
 // NO-WARN: This call cannot be swapped, even if "getCanonicalType()" believes otherwise.
+
+void attributedParam1(const __attribute__((address_space(256))) int *One,
+  const __attribute__((address_space(256))) int *Two) {}
+// CHECK-MESSAGES: :[[@LINE-2]]:23: warning: 2 adjacent parameters of 'attributedParam1' of similar type ('const __attribute__((address_space(256))) int *') are
+// CHECK-MESSAGES: :[[@LINE-3]]:70: note: the first parameter in the range is 'One'
+// CHECK-MESSAGES: :[[@LINE-3]]:70: note: the last parameter in the range is 'Two'
+
+void attributedParam1Typedef(const __attribute__((address_space(256))) int *One,
+ const __attribute__((address_space(256))) MyInt1 *Two) {}
+// CHECK-MESSAGES: :[[@LINE-2]]:30: warning: 2 adjacent parameters of 'attributedParam1Typedef' of similar type are
+// CHECK-MESSAGES: :[[@LINE-3]]:77: note: the first parameter in the range is 'One'
+// CHECK-MESSAGES: :[[@LINE-3]]:80: note: the last parameter in the range is 'Two'
+// CHECK-MESSAGES: :[[@LINE-5]]:30: note: after resolving type aliases, the common type of 'const __attribute__((address_space(256))) int *' and 'const __attribute__((address_space(256))) MyInt1 *' is 'const __attribute__((address_space(256))) int'
+// FIXME: The last diagnostic line is a bit bad: the common type should be a
+// pointer type -- it is not clear right now, how it would be possible to
+// properly wire a logic in that fixes it.
+
+void attributedParam2(__attribute__((address_space(256))) int *One,
+  const __attribute__((address_space(256))) MyInt1 *Two) {}
+// NO-WARN: One is CVR-qualified, the other is not.
+
+void attributedParam3(const int *One,
+  const __attribute__((address_space(256))) MyInt1 *Two) {}
+// NO-WARN: One is attributed, the other is not.
+
+void attributedParam4(const __attribute__((address_space(512))) int *One,
+  const __attribute__((address_space(256))) MyInt1 *Two) {}
+// NO-WARN: Different value of the attribute.
Index: clang-tools-extra/clang-tidy/bugprone/EasilySwappableParametersCheck.cpp
===

[PATCH] D106416: [analyzer] Fix build dependency issues for SATest

2021-07-22 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko accepted this revision.
vsavchenko added a comment.
This revision is now accepted and ready to land.

Awesome!  Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106416

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


[PATCH] D106530: [PowerPC] Change altivec indexed load/store builtins argument type

2021-07-22 Thread Qiu Chaofan via Phabricator via cfe-commits
qiucf created this revision.
qiucf added reviewers: jsji, nemanjai, shchenz, anhtuyen, PowerPC.
Herald added subscribers: arphaman, kbarton.
qiucf requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This patch changes the index argument of `lvxl?/lve[bhw]x/stvxl?/stve[bhw]x` 
builtins from `int` to `long`. Because on 64-bit subtargets, an extra `extsw` 
will always been generated, which is incorrect.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D106530

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/Headers/altivec.h
  clang/test/CodeGen/ppc-emmintrin.c
  clang/test/CodeGen/ppc-xmmintrin.c

Index: clang/test/CodeGen/ppc-xmmintrin.c
===
--- clang/test/CodeGen/ppc-xmmintrin.c
+++ clang/test/CodeGen/ppc-xmmintrin.c
@@ -953,7 +953,7 @@
 // CHECK-LABEL: @test_load
 
 // CHECK: define available_externally <4 x float> @_mm_load_ps
-// CHECK: [[REG469:[0-9a-zA-Z_%.]+]] = call <4 x float> @vec_ld(int, float vector[4] const*)
+// CHECK: [[REG469:[0-9a-zA-Z_%.]+]] = call <4 x float> @vec_ld(long, float vector[4] const*)
 // CHECK-NEXT: ret <4 x float> [[REG469]]
 
 // CHECK: define available_externally <4 x float> @_mm_load_ps1
@@ -993,7 +993,7 @@
 // CHECK-NEXT: ret <4 x float> [[REG490]]
 
 // CHECK: define available_externally <4 x float> @_mm_loadr_ps
-// CHECK: [[REG491:[0-9a-zA-Z_%.]+]] = call <4 x float> @vec_ld(int, float vector[4] const*)
+// CHECK: [[REG491:[0-9a-zA-Z_%.]+]] = call <4 x float> @vec_ld(long, float vector[4] const*)
 // CHECK-NEXT: store <4 x float> [[REG491]], <4 x float>* [[REG492:[0-9a-zA-Z_%.]+]], align 16
 // CHECK-NEXT: [[REG493:[0-9a-zA-Z_%.]+]] = load <4 x float>, <4 x float>* [[REG492]], align 16
 // CHECK-NEXT: [[REG494:[0-9a-zA-Z_%.]+]] = load <4 x float>, <4 x float>* [[REG492]], align 16
@@ -1828,7 +1828,7 @@
 // CHECK-NEXT: [[REG939:[0-9a-zA-Z_%.]+]] = load <4 x float>, <4 x float>* {{[0-9a-zA-Z_%.]+}}, align 16
 // CHECK-NEXT: [[REG940:[0-9a-zA-Z_%.]+]] = load float*, float** {{[0-9a-zA-Z_%.]+}}, align 8
 // CHECK-NEXT: [[REG941:[0-9a-zA-Z_%.]+]] = bitcast float* [[REG940]] to <4 x float>*
-// CHECK-NEXT: call void @vec_st(float vector[4], int, float vector[4]*)(<4 x float> [[REG939]], i32 signext 0, <4 x float>* [[REG941]])
+// CHECK-NEXT: call void @vec_st(float vector[4], long, float vector[4]*)(<4 x float> [[REG939]], i64 0, <4 x float>* [[REG941]])
 // CHECK-NEXT: ret void
 
 // CHECK: define available_externally void @_mm_store_ps1
Index: clang/test/CodeGen/ppc-emmintrin.c
===
--- clang/test/CodeGen/ppc-emmintrin.c
+++ clang/test/CodeGen/ppc-emmintrin.c
@@ -1361,7 +1361,7 @@
 // CHECK: store double* [[REG917]], double** [[REG918:[0-9a-zA-Z_%.]+]], align 8
 // CHECK-NEXT: [[REG919:[0-9a-zA-Z_%.]+]] = load double*, double** [[REG918]], align 8
 // CHECK-NEXT: [[REG920:[0-9a-zA-Z_%.]+]] = bitcast double* [[REG919]] to <16 x i8>*
-// CHECK-NEXT: [[REG921:[0-9a-zA-Z_%.]+]] = call <16 x i8> @vec_ld(int, unsigned char vector[16] const*)(i32 signext 0, <16 x i8>* [[REG920]])
+// CHECK-NEXT: [[REG921:[0-9a-zA-Z_%.]+]] = call <16 x i8> @vec_ld(long, unsigned char vector[16] const*)(i64 0, <16 x i8>* [[REG920]])
 // CHECK-NEXT: [[REG922:[0-9a-zA-Z_%.]+]] = bitcast <16 x i8> [[REG921]] to <2 x double>
 // CHECK-NEXT: ret <2 x double> [[REG922]]
 
@@ -2915,7 +2915,7 @@
 // CHECK-NEXT: [[REG1925:[0-9a-zA-Z_%.]+]] = bitcast <2 x double> [[REG1924]] to <16 x i8>
 // CHECK-NEXT: [[REG1926:[0-9a-zA-Z_%.]+]] = load double*, double** [[REG1922]], align 8
 // CHECK-NEXT: [[REG1927:[0-9a-zA-Z_%.]+]] = bitcast double* [[REG1926]] to <16 x i8>*
-// CHECK-NEXT: call void @vec_st(unsigned char vector[16], int, unsigned char vector[16]*)(<16 x i8> [[REG1925]], i32 signext 0, <16 x i8>* [[REG1927]])
+// CHECK-NEXT: call void @vec_st(unsigned char vector[16], long, unsigned char vector[16]*)(<16 x i8> [[REG1925]], i64 0, <16 x i8>* [[REG1927]])
 // CHECK-NEXT: ret void
 
 // CHECK: define available_externally void @_mm_store_pd1(double* [[REG1928:[0-9a-zA-Z_%.]+]], <2 x double> [[REG1929:[0-9a-zA-Z_%.]+]])
@@ -2942,7 +2942,7 @@
 // CHECK-NEXT: [[REG1946:[0-9a-zA-Z_%.]+]] = bitcast <2 x i64> [[REG1945]] to <16 x i8>
 // CHECK-NEXT: [[REG1947:[0-9a-zA-Z_%.]+]] = load <2 x i64>*, <2 x i64>** [[REG1943]], align 8
 // CHECK-NEXT: [[REG1948:[0-9a-zA-Z_%.]+]] = bitcast <2 x i64>* [[REG1947]] to <16 x i8>*
-// CHECK-NEXT: call void @vec_st(unsigned char vector[16], int, unsigned char vector[16]*)(<16 x i8> [[REG1946]], i32 signext 0, <16 x i8>* [[REG1948]])
+// CHECK-NEXT: call void @vec_st(unsigned char vector[16], long, unsigned char vector[16]*)(<16 x i8> [[REG1946]], i64 0, <16 x i8>* [[REG1948]])
 // CHECK-NEXT: ret void
 
 // CHECK: define available_externally void @_mm_store1_pd(double* [[REG1949:[0-9a-zA-Z_%.]+]], <2 x double> [[REG1950:[0-9a-zA-Z_%.]+]])
Index: clang/lib/Headers/alti

[PATCH] D105703: [hwasan] Use stack safety analysis.

2021-07-22 Thread Florian Mayer via Phabricator via cfe-commits
fmayer updated this revision to Diff 360735.
fmayer added a comment.

formatting.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105703

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  clang/test/CodeGen/hwasan-stack-safety-analysis.c
  llvm/include/llvm/Transforms/Instrumentation/HWAddressSanitizer.h
  llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
  llvm/test/Instrumentation/HWAddressSanitizer/stack-safety-analysis.ll

Index: llvm/test/Instrumentation/HWAddressSanitizer/stack-safety-analysis.ll
===
--- /dev/null
+++ llvm/test/Instrumentation/HWAddressSanitizer/stack-safety-analysis.ll
@@ -0,0 +1,42 @@
+; RUN: opt -hwasan -hwasan-use-stack-safety=1 -hwasan-generate-tags-with-calls -S < %s | FileCheck %s --check-prefixes=SAFETY
+; RUN: opt -hwasan -hwasan-use-stack-safety=0 -hwasan-generate-tags-with-calls -S < %s | FileCheck %s --check-prefixes=NOSAFETY
+
+target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
+target triple = "aarch64-unknown-linux-gnu"
+
+; Check a safe alloca to ensure it does not get a tag.
+define i32 @test_load(i32* %a) sanitize_hwaddress {
+entry:
+  ; NOSAFETY: call {{.*}}__hwasan_generate_tag
+  ; SAFETY-NOT: call {{.*}}__hwasan_generate_tag
+  %buf.sroa.0 = alloca i8, align 4
+  call void @llvm.lifetime.start.p0i8(i64 1, i8* nonnull %buf.sroa.0)
+  store volatile i8 0, i8* %buf.sroa.0, align 4, !tbaa !8
+  call void @llvm.lifetime.end.p0i8(i64 1, i8* nonnull %buf.sroa.0)
+  ret i32 0
+}
+
+; Check a non-safe alloca to ensure it gets a tag.
+define i32 @test_use(i32* %a) sanitize_hwaddress {
+entry:
+  ; NOSAFETY: call {{.*}}__hwasan_generate_tag
+  ; SAFETY: call {{.*}}__hwasan_generate_tag
+  %buf.sroa.0 = alloca i8, align 4
+  call void @use(i8* nonnull %buf.sroa.0)
+  call void @llvm.lifetime.start.p0i8(i64 1, i8* nonnull %buf.sroa.0)
+  store volatile i8 0, i8* %buf.sroa.0, align 4, !tbaa !8
+  call void @llvm.lifetime.end.p0i8(i64 1, i8* nonnull %buf.sroa.0)
+  ret i32 0
+}
+
+; Function Attrs: argmemonly mustprogress nofree nosync nounwind willreturn
+declare void @llvm.lifetime.start.p0i8(i64 immarg, i8* nocapture)
+
+; Function Attrs: argmemonly mustprogress nofree nosync nounwind willreturn
+declare void @llvm.lifetime.end.p0i8(i64 immarg, i8* nocapture)
+
+declare void @use(i8* nocapture)
+
+!8 = !{!9, !9, i64 0}
+!9 = !{!"omnipotent char", !10, i64 0}
+!10 = !{!"Simple C/C++ TBAA"}
Index: llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
===
--- llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
+++ llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
@@ -17,6 +17,7 @@
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/Triple.h"
+#include "llvm/Analysis/StackSafetyAnalysis.h"
 #include "llvm/BinaryFormat/ELF.h"
 #include "llvm/IR/Attributes.h"
 #include "llvm/IR/BasicBlock.h"
@@ -109,6 +110,11 @@
cl::desc("instrument stack (allocas)"),
cl::Hidden, cl::init(true));
 
+static cl::opt
+ClUseStackSafety("hwasan-use-stack-safety", cl::Hidden, cl::init(true),
+ cl::Hidden, cl::desc("Use Stack Safety analysis results"),
+ cl::Optional);
+
 static cl::opt ClUARRetagToZero(
 "hwasan-uar-retag-to-zero",
 cl::desc("Clear alloca tags before returning from the function to allow "
@@ -216,11 +222,23 @@
 #endif
 }
 
+bool mightUseStackSafetyAnalysis(bool DisableOptimization) {
+  return ClUseStackSafety.getNumOccurrences() ? ClUseStackSafety
+  : !DisableOptimization;
+}
+
+bool shouldUseStackSafetyAnalysis(const Triple &TargetTriple,
+  bool DisableOptimization) {
+  return shouldInstrumentStack(TargetTriple) &&
+ mightUseStackSafetyAnalysis(DisableOptimization);
+}
 /// An instrumentation pass implementing detection of addressability bugs
 /// using tagged pointers.
 class HWAddressSanitizer {
 public:
-  HWAddressSanitizer(Module &M, bool CompileKernel, bool Recover) : M(M) {
+  HWAddressSanitizer(Module &M, bool CompileKernel, bool Recover,
+ const StackSafetyGlobalInfo *SSI)
+  : M(M), SSI(SSI) {
 this->Recover = ClRecover.getNumOccurrences() > 0 ? ClRecover : Recover;
 this->CompileKernel = ClEnableKhwasan.getNumOccurrences() > 0
   ? ClEnableKhwasan
@@ -229,6 +247,8 @@
 initializeModule();
   }
 
+  void setSSI(const StackSafetyGlobalInfo *S) { SSI = S; }
+
   bool sanitizeFunction(Function &F);
   void initializeModule();
   void createHwasanCtorComdat();
@@ -281,6 +301,7 @@
 private:
   LLVMContext *C;
   Module &M;
+  const StackSafetyGlobalInfo *SSI;
   Triple TargetTriple;
   FunctionCallee HWAsanM

[PATCH] D105690: [RISCV] Rename assembler mnemonic of unordered floating-point reductions for v1.0-rc change

2021-07-22 Thread Fraser Cormack via Phabricator via cfe-commits
frasercrmck added inline comments.



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoV.td:10
 /// This file describes the RISC-V instructions from the standard 'V' Vector
 /// extension, version 0.10.
 /// This version is still experimental as the 'V' extension hasn't been

khchen wrote:
> jacquesguan wrote:
> > khchen wrote:
> > > Do we need to update 0.10 to 1.0-rc?
> > > If the answer is yes, I think maybe we also need to update the clang part 
> > > (ex. arch parsing, predefine macro) in follow-up patches.
> > > 
> > > 
> > Maybe update it after finishing all changes in 1.0-rc?
> > Maybe update it after finishing all changes in 1.0-rc?
> Yes.
> 
> The other questions like how do you encode `rc1` in `march` or predefined 
> architecture extension macro.
> or maybe we could just use 1.0 directly because v is still an experiential 
> extension.
> 
> @luismarques  @frasercrmck @craig.topper @HsiangKai What do you think?
Maybe we can discuss in the call today, but my initial thoughts would be to 
just say 1.0 for the reasons you specified.

Perhaps there's already precedent in dealing with release-candidate specs for 
the base ISA or other extensions?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105690

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


[clang] bd41136 - [clang] Use i64 for the !srcloc metadata on asm IR nodes.

2021-07-22 Thread Simon Tatham via cfe-commits

Author: Simon Tatham
Date: 2021-07-22T10:24:52+01:00
New Revision: bd41136746a0b47882914cee5a8d1ac6714288d1

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

LOG: [clang] Use i64 for the !srcloc metadata on asm IR nodes.

This is part of a patch series working towards the ability to make
SourceLocation into a 64-bit type to handle larger translation units.

!srcloc is generated in clang codegen, and pulled back out by llvm
functions like AsmPrinter::emitInlineAsm that need to report errors in
the inline asm. From there it goes to LLVMContext::emitError, is
stored in DiagnosticInfoInlineAsm, and ends up back in clang, at
BackendConsumer::InlineAsmDiagHandler(), which reconstitutes a true
clang::SourceLocation from the integer cookie.

Throughout this code path, it's now 64-bit rather than 32, which means
that if SourceLocation is expanded to a 64-bit type, this error report
won't lose half of the data.

The compiler will tolerate both of i32 and i64 !srcloc metadata in
input IR without faulting. Test added in llvm/MC. (The semantic
accuracy of the metadata is another matter, but I don't know of any
situation where that matters: if you're reading an IR file written by
a previous run of clang, you don't have the SourceManager that can
relate those source locations back to the original source files.)

Original version of the patch by Mikhail Maltsev.

Reviewed By: dexonsmith

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

Added: 


Modified: 
clang/lib/CodeGen/CGStmt.cpp
llvm/include/llvm/IR/DiagnosticInfo.h
llvm/include/llvm/IR/LLVMContext.h
llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp
llvm/lib/CodeGen/MachineInstr.cpp
llvm/lib/IR/LLVMContext.cpp
llvm/test/MC/ARM/inline-asm-srcloc.ll

Removed: 




diff  --git a/clang/lib/CodeGen/CGStmt.cpp b/clang/lib/CodeGen/CGStmt.cpp
index 6f6dcfa58a7f1..aeb319ca15819 100644
--- a/clang/lib/CodeGen/CGStmt.cpp
+++ b/clang/lib/CodeGen/CGStmt.cpp
@@ -2158,7 +2158,7 @@ static llvm::MDNode *getAsmSrcLocInfo(const StringLiteral 
*Str,
   SmallVector Locs;
   // Add the location of the first line to the MDNode.
   Locs.push_back(llvm::ConstantAsMetadata::get(llvm::ConstantInt::get(
-  CGF.Int32Ty, Str->getBeginLoc().getRawEncoding(;
+  CGF.Int64Ty, Str->getBeginLoc().getRawEncoding(;
   StringRef StrVal = Str->getString();
   if (!StrVal.empty()) {
 const SourceManager &SM = CGF.CGM.getContext().getSourceManager();
@@ -2173,7 +2173,7 @@ static llvm::MDNode *getAsmSrcLocInfo(const StringLiteral 
*Str,
   SourceLocation LineLoc = Str->getLocationOfByte(
   i + 1, SM, LangOpts, CGF.getTarget(), &StartToken, &ByteOffset);
   Locs.push_back(llvm::ConstantAsMetadata::get(
-  llvm::ConstantInt::get(CGF.Int32Ty, LineLoc.getRawEncoding(;
+  llvm::ConstantInt::get(CGF.Int64Ty, LineLoc.getRawEncoding(;
 }
   }
 
@@ -2210,8 +2210,8 @@ static void UpdateAsmCallInst(llvm::CallBase &Result, 
bool HasSideEffect,
getAsmSrcLocInfo(gccAsmStmt->getAsmString(), CGF));
   else {
 // At least put the line number on MS inline asm blobs.
-llvm::Constant *Loc = llvm::ConstantInt::get(CGF.Int32Ty,
-S.getAsmLoc().getRawEncoding());
+llvm::Constant *Loc =
+llvm::ConstantInt::get(CGF.Int64Ty, S.getAsmLoc().getRawEncoding());
 Result.setMetadata("srcloc",
llvm::MDNode::get(CGF.getLLVMContext(),
  llvm::ConstantAsMetadata::get(Loc)));

diff  --git a/llvm/include/llvm/IR/DiagnosticInfo.h 
b/llvm/include/llvm/IR/DiagnosticInfo.h
index 9134ca12600b2..5064f4f4edf77 100644
--- a/llvm/include/llvm/IR/DiagnosticInfo.h
+++ b/llvm/include/llvm/IR/DiagnosticInfo.h
@@ -131,7 +131,7 @@ using DiagnosticHandlerFunction = std::function;
 class DiagnosticInfoInlineAsm : public DiagnosticInfo {
 private:
   /// Optional line information. 0 if not set.
-  unsigned LocCookie = 0;
+  uint64_t LocCookie = 0;
   /// Message to be reported.
   const Twine &MsgStr;
   /// Optional origin of the problem.
@@ -149,7 +149,7 @@ class DiagnosticInfoInlineAsm : public DiagnosticInfo {
   /// \p MsgStr gives the message.
   /// This class does not copy \p MsgStr, therefore the reference must be valid
   /// for the whole life time of the Diagnostic.
-  DiagnosticInfoInlineAsm(unsigned LocCookie, const Twine &MsgStr,
+  DiagnosticInfoInlineAsm(uint64_t LocCookie, const Twine &MsgStr,
   DiagnosticSeverity Severity = DS_Error)
   : DiagnosticInfo(DK_InlineAsm, Severity), LocCookie(LocCookie),
 MsgStr(MsgStr) {}
@@ -162,7 +162,7 @@ class DiagnosticInfoInlineAsm : public DiagnosticInfo {
   DiagnosticInfoInlineAsm(const Instructi

[PATCH] D105491: [clang] Use i64 for the !srcloc metadata on asm IR nodes.

2021-07-22 Thread Simon Tatham via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
simon_tatham marked an inline comment as done.
Closed by commit rGbd41136746a0: [clang] Use i64 for the !srcloc metadata on 
asm IR nodes. (authored by simon_tatham).

Changed prior to commit:
  https://reviews.llvm.org/D105491?vs=360098&id=360743#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105491

Files:
  clang/lib/CodeGen/CGStmt.cpp
  llvm/include/llvm/IR/DiagnosticInfo.h
  llvm/include/llvm/IR/LLVMContext.h
  llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp
  llvm/lib/CodeGen/MachineInstr.cpp
  llvm/lib/IR/LLVMContext.cpp
  llvm/test/MC/ARM/inline-asm-srcloc.ll

Index: llvm/test/MC/ARM/inline-asm-srcloc.ll
===
--- llvm/test/MC/ARM/inline-asm-srcloc.ll
+++ llvm/test/MC/ARM/inline-asm-srcloc.ll
@@ -20,6 +20,8 @@
 ; CHECK: note: !srcloc = 181
   call void asm sideeffect " .word -foo", ""() #1, !srcloc !5
 ; CHECK: note: !srcloc = 257
+  call void asm sideeffect " .word -stoat", ""() #1, !srcloc !6
+; CHECK: note: !srcloc = 534
   ret void
 }
 
@@ -33,5 +35,11 @@
 !1 = !{i32 1, !"min_enum_size", i32 4}
 !2 = !{!"clang version 5.0.0 "}
 !3 = !{i32 107}
+
+; These !srcloc metadata nodes are intentionally not all the same type: D105491
+; changed the creation of !srcloc to generate i64 instead of the previous i32.
+; So one thing we're testing here is that both types are acceptable on input,
+; i.e. IR generated both before and after the change can be consumed.
 !4 = !{i32 181}
 !5 = !{i32 257}
+!6 = !{i64 534}
Index: llvm/lib/IR/LLVMContext.cpp
===
--- llvm/lib/IR/LLVMContext.cpp
+++ llvm/lib/IR/LLVMContext.cpp
@@ -248,7 +248,7 @@
 exit(1);
 }
 
-void LLVMContext::emitError(unsigned LocCookie, const Twine &ErrorStr) {
+void LLVMContext::emitError(uint64_t LocCookie, const Twine &ErrorStr) {
   diagnose(DiagnosticInfoInlineAsm(LocCookie, ErrorStr));
 }
 
Index: llvm/lib/CodeGen/MachineInstr.cpp
===
--- llvm/lib/CodeGen/MachineInstr.cpp
+++ llvm/lib/CodeGen/MachineInstr.cpp
@@ -2083,7 +2083,7 @@
 
 void MachineInstr::emitError(StringRef Msg) const {
   // Find the source location cookie.
-  unsigned LocCookie = 0;
+  uint64_t LocCookie = 0;
   const MDNode *LocMD = nullptr;
   for (unsigned i = getNumOperands(); i != 0; --i) {
 if (getOperand(i-1).isMetadata() &&
Index: llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp
===
--- llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp
+++ llvm/lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp
@@ -130,7 +130,7 @@
 
 static void EmitMSInlineAsmStr(const char *AsmStr, const MachineInstr *MI,
MachineModuleInfo *MMI, AsmPrinter *AP,
-   unsigned LocCookie, raw_ostream &OS) {
+   uint64_t LocCookie, raw_ostream &OS) {
   // Switch to the inline assembly variant.
   OS << "\t.intel_syntax\n\t";
 
@@ -272,7 +272,7 @@
 
 static void EmitGCCInlineAsmStr(const char *AsmStr, const MachineInstr *MI,
 MachineModuleInfo *MMI, const MCAsmInfo *MAI,
-AsmPrinter *AP, unsigned LocCookie,
+AsmPrinter *AP, uint64_t LocCookie,
 raw_ostream &OS) {
   int CurVariant = -1;// The number of the {.|.|.} region we are in.
   const char *LastEmitted = AsmStr; // One past the last character emitted.
@@ -483,7 +483,7 @@
 
   // Get the !srcloc metadata node if we have it, and decode the loc cookie from
   // it.
-  unsigned LocCookie = 0;
+  uint64_t LocCookie = 0;
   const MDNode *LocMD = nullptr;
   for (unsigned i = MI->getNumOperands(); i != 0; --i) {
 if (MI->getOperand(i-1).isMetadata() &&
Index: llvm/include/llvm/IR/LLVMContext.h
===
--- llvm/include/llvm/IR/LLVMContext.h
+++ llvm/include/llvm/IR/LLVMContext.h
@@ -290,7 +290,7 @@
   /// be prepared to drop the erroneous construct on the floor and "not crash".
   /// The generated code need not be correct.  The error message will be
   /// implicitly prefixed with "error: " and should not end with a ".".
-  void emitError(unsigned LocCookie, const Twine &ErrorStr);
+  void emitError(uint64_t LocCookie, const Twine &ErrorStr);
   void emitError(const Instruction *I, const Twine &ErrorStr);
   void emitError(const Twine &ErrorStr);
 
Index: llvm/include/llvm/IR/DiagnosticInfo.h
===
--- llvm/include/llvm/IR/DiagnosticInfo.h
+++ llvm/include/llvm/IR/DiagnosticInfo.h
@@ -131,7 +131,7 @@
 class DiagnosticInfoInlineA

[PATCH] D105491: [clang] Use i64 for the !srcloc metadata on asm IR nodes.

2021-07-22 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham added a comment.

(But I've pushed this patch anyway, because I'm reasonably confident of the 
answer; if it turns out that there's some case along those lines that I should 
have taken care of, I'll fix or revert.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105491

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


[PATCH] D104601: [Preprocessor] Implement -fminimize-whitespace.

2021-07-22 Thread Michael Kruse via Phabricator via cfe-commits
Meinersbur updated this revision to Diff 360745.
Meinersbur marked 2 inline comments as done.
Meinersbur added a comment.

- Error if -fminimize-whitespace is applied to asm files
- Join lines with escaped newlines
- Added some FIXMEs for grandfathered bugs


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104601

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Options.td
  clang/include/clang/Frontend/PreprocessorOutputOptions.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/PrintPreprocessedOutput.cpp
  clang/lib/Lex/Preprocessor.cpp
  clang/test/CXX/lex/lex.pptoken/p3-2a.cpp
  clang/test/Preprocessor/c99-6_10_3_4_p5.c
  clang/test/Preprocessor/c99-6_10_3_4_p6.c
  clang/test/Preprocessor/comment_save.c
  clang/test/Preprocessor/first-line-indent.c
  clang/test/Preprocessor/hash_line.c
  clang/test/Preprocessor/line-directive-output-mincol.c
  clang/test/Preprocessor/line-directive-output.c
  clang/test/Preprocessor/macro_space.c
  clang/test/Preprocessor/minimize-whitespace-messages.c
  clang/test/Preprocessor/minimize-whitespace.c
  clang/test/Preprocessor/print_line_include.c
  clang/test/Preprocessor/stringize_space.c

Index: clang/test/Preprocessor/stringize_space.c
===
--- clang/test/Preprocessor/stringize_space.c
+++ clang/test/Preprocessor/stringize_space.c
@@ -1,16 +1,18 @@
 // RUN: %clang_cc1 -E %s | FileCheck --strict-whitespace %s
+// RUN: %clang_cc1 -E -P -fminimize-whitespace %s | FileCheck --strict-whitespace %s --check-prefix=MINWS
 
 #define A(b) -#b  ,  - #b  ,  -# b  ,  - # b
 A()
 
 // CHECK: {{^}}-"" , - "" , -"" , - ""{{$}}
-
+// MINWS: {{^}}-"",-"",-"",-""
 
 #define t(x) #x
 t(a
 c)
 
 // CHECK: {{^}}"a c"{{$}}
+// MINWS-SAME: "a c"
 
 #define str(x) #x
 #define f(x) str(-x)
@@ -18,6 +20,7 @@
 1)
 
 // CHECK: {{^}}"-1"
+// MINWS-SAME: "-1"
 
 #define paste(a,b) str(a&1 | FileCheck %s --strict-whitespace --check-prefix=MINCOL
+// RUN: %clang_cc1 -fminimize-whitespace -E -C %s 2>&1 | FileCheck %s --strict-whitespace --check-prefix=MINCCOL
+// RUN: %clang_cc1 -fminimize-whitespace -E -P %s 2>&1 | FileCheck %s --strict-whitespace --check-prefix=MINWS
+// RUN: %clang_cc1 -fminimize-whitespace -E -C -P %s 2>&1 | FileCheck %s --strict-whitespace --check-prefix=MINCWS
+
+#define NOT_OMP  omp  something
+#define HASH #
+
+  int  a; /*  span-comment  */
+  int  b  ;   //  line-comment
+  _Pragma  (  "omp  barrier"  ) x //  more line-comments
+  #pragma  omp  nothing  //  another comment
+HASH  pragma  NOT_OMP
+  int  e;// again a line
+  int  \
+f  ;
+
+
+// MINCOL:  {{^}}# 9 "{{.*}}minimize-whitespace.c"{{$}}
+// MINCOL:  {{^}}int a;{{$}}
+// MINCOL-NEXT: {{^}}int b;{{$}}
+// MINCOL-NEXT: {{^}}#pragma omp barrier{{$}}
+// MINCOL-NEXT: # 11 "{{.*}}minimize-whitespace.c"
+// MINCOL-NEXT: {{^}}x{{$}}
+// MINCOL-NEXT: {{^}}#pragma omp nothing{{$}}
+// MINCOL-NEXT: {{^ }}#pragma omp something{{$}}
+// MINCOL-NEXT: {{^}}int e;{{$}}
+// MINCOL-NEXT: {{^}}int f;{{$}}
+
+// FIXME: Comments after pragmas disappear, even without -fminimize-whitespace
+// MINCCOL:  {{^}}# 9 "{{.*}}minimize-whitespace.c"{{$}}
+// MINCCOL:  {{^}}int a;/*  span-comment  */{{$}}
+// MINCCOL-NEXT: {{^}}int b;//  line-comment{{$}}
+// MINCCOL-NEXT: {{^}}#pragma omp barrier{{$}}
+// MINCCOL-NEXT: # 11 "{{.*}}minimize-whitespace.c"
+// MINCCOL-NEXT: {{^}}x//  more line-comments{{$}}
+// MINCCOL-NEXT: {{^}}#pragma omp nothing{{$}}
+// MINCCOL-NEXT: {{^ }}#pragma omp something{{$}}
+// MINCCOL-NEXT: {{^}}int e;// again a line{{$}}
+// MINCCOL-NEXT: {{^}}int f;{{$}}
+
+// MINWS:  {{^}}int a;int b;{{$}}
+// MINWS-NEXT: {{^}}#pragma omp barrier{{$}}
+// MINWS-NEXT: {{^}}x{{$}}
+// MINWS-NEXT: {{^}}#pragma omp nothing{{$}}
+// MINWS-NEXT: {{^ }}#pragma omp something int e;int f;{{$}}
+
+// FIXME: Comments after pragmas disappear, even without -fminimize-whitespace
+// MINCWS:  {{^}}int a;/*  span-comment  */int b;//  line-comment{{$}}
+// MINCWS-NEXT: {{^}}#pragma omp barrier{{$}}
+// MINCWS-NEXT: {{^}}x//  more line-comments{{$}}
+// MINCWS-NEXT: {{^}}#pragma omp nothing{{$}}
+// MINCWS-NEXT: {{^ }}#pragma omp something int e;// again a line{{$}}
+// MINCWS-NEXT: {{^}}int f;
+
Index: clang/test/Preprocessor/minimize-whitespace-messages.c
===
--- /dev/null
+++ clang/test/Preprocessor/minimize-whitespace-messages.c
@@ -0,0 +1,8 @@
+// RUN: not %clang -c -fminimize-whitespace %s 2>&1 | FileCheck %s --check-prefix=ON
+// ON: error: invalid argument '-fminimize-whitespace' only allowed with '-E'
+
+// RUN: not %clang -c -fno-minimize-whitespace %s 2>&1 | FileCheck %s  --check-prefix=OFF
+// OFF: error: invalid argument '-fno-minimize-whitespace' only allowed with '-E'
+
+// RUN: not %clang -E -fmi

[PATCH] D106504: [OpenCL] Change default standard version to CL1.2

2021-07-22 Thread Sven van Haastregt via Phabricator via cfe-commits
svenvh added a comment.

LGTM, just a small question.




Comment at: clang/test/CodeGenOpenCL/spir_version.cl:2
+// RUN: %clang_cc1 %s -triple "spir-unknown-unknown" -emit-llvm -o - 
-cl-std=CL1.0 | FileCheck %s --check-prefix=CHECK-SPIR-CL10
 // RUN: %clang_cc1 %s -triple "spir-unknown-unknown" -emit-llvm -o - 
-cl-std=CL1.2 | FileCheck %s --check-prefix=CHECK-SPIR-CL12
 // RUN: %clang_cc1 %s -triple "spir-unknown-unknown" -emit-llvm -o - 
-cl-std=CL2.0 | FileCheck %s --check-prefix=CHECK-SPIR-CL20

Would it be worth having an invocation without any `-cl-std=` and verifying 
that it produces the same version metadata as CL1.2?


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

https://reviews.llvm.org/D106504

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


[PATCH] D106535: [clangd] Use CommandMangler in TestTU

2021-07-22 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet created this revision.
kadircet added a reviewer: sammccall.
Herald added subscribers: usaxena95, arphaman.
kadircet requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, ilya-biryukov.
Herald added projects: clang, clang-tools-extra.

This makes testing setup look closer to production.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D106535

Files:
  clang-tools-extra/clangd/unittests/TestTU.cpp
  clang/lib/Frontend/CreateInvocationFromCommandLine.cpp


Index: clang/lib/Frontend/CreateInvocationFromCommandLine.cpp
===
--- clang/lib/Frontend/CreateInvocationFromCommandLine.cpp
+++ clang/lib/Frontend/CreateInvocationFromCommandLine.cpp
@@ -10,15 +10,17 @@
 //
 
//===--===//
 
-#include "clang/Frontend/Utils.h"
 #include "clang/Basic/DiagnosticOptions.h"
+#include "clang/Driver/Action.h"
 #include "clang/Driver/Compilation.h"
 #include "clang/Driver/Driver.h"
-#include "clang/Driver/Action.h"
 #include "clang/Driver/Options.h"
 #include "clang/Driver/Tool.h"
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/FrontendDiagnostic.h"
+#include "clang/Frontend/Utils.h"
+#include "llvm/ADT/STLExtras.h"
+#include "llvm/ADT/StringRef.h"
 #include "llvm/Option/ArgList.h"
 #include "llvm/Support/Host.h"
 using namespace clang;
@@ -37,7 +39,10 @@
   SmallVector Args(ArgList.begin(), ArgList.end());
 
   // FIXME: Find a cleaner way to force the driver into restricted modes.
-  Args.push_back("-fsyntax-only");
+  Args.insert(
+  llvm::find_if(
+  Args, [](const char *Elem) { return llvm::StringRef(Elem) == "--"; 
}),
+  "-fsyntax-only");
 
   // FIXME: We shouldn't have to pass in the path info.
   driver::Driver TheDriver(Args[0], llvm::sys::getDefaultTargetTriple(), 
*Diags,
Index: clang-tools-extra/clangd/unittests/TestTU.cpp
===
--- clang-tools-extra/clangd/unittests/TestTU.cpp
+++ clang-tools-extra/clangd/unittests/TestTU.cpp
@@ -7,6 +7,7 @@
 
//===--===//
 
 #include "TestTU.h"
+#include "CompileCommands.h"
 #include "Compiler.h"
 #include "Diagnostics.h"
 #include "TestFS.h"
@@ -56,6 +57,9 @@
   // Put the file name at the end -- this allows the extra arg (-xc++) to
   // override the language setting.
   Argv.push_back(FullFilename);
+
+  auto Mangler = CommandMangler::forTests();
+  Mangler.adjust(Inputs.CompileCommand.CommandLine);
   Inputs.CompileCommand.Filename = FullFilename;
   Inputs.CompileCommand.Directory = testRoot();
   Inputs.Contents = Code;


Index: clang/lib/Frontend/CreateInvocationFromCommandLine.cpp
===
--- clang/lib/Frontend/CreateInvocationFromCommandLine.cpp
+++ clang/lib/Frontend/CreateInvocationFromCommandLine.cpp
@@ -10,15 +10,17 @@
 //
 //===--===//
 
-#include "clang/Frontend/Utils.h"
 #include "clang/Basic/DiagnosticOptions.h"
+#include "clang/Driver/Action.h"
 #include "clang/Driver/Compilation.h"
 #include "clang/Driver/Driver.h"
-#include "clang/Driver/Action.h"
 #include "clang/Driver/Options.h"
 #include "clang/Driver/Tool.h"
 #include "clang/Frontend/CompilerInstance.h"
 #include "clang/Frontend/FrontendDiagnostic.h"
+#include "clang/Frontend/Utils.h"
+#include "llvm/ADT/STLExtras.h"
+#include "llvm/ADT/StringRef.h"
 #include "llvm/Option/ArgList.h"
 #include "llvm/Support/Host.h"
 using namespace clang;
@@ -37,7 +39,10 @@
   SmallVector Args(ArgList.begin(), ArgList.end());
 
   // FIXME: Find a cleaner way to force the driver into restricted modes.
-  Args.push_back("-fsyntax-only");
+  Args.insert(
+  llvm::find_if(
+  Args, [](const char *Elem) { return llvm::StringRef(Elem) == "--"; }),
+  "-fsyntax-only");
 
   // FIXME: We shouldn't have to pass in the path info.
   driver::Driver TheDriver(Args[0], llvm::sys::getDefaultTargetTriple(), *Diags,
Index: clang-tools-extra/clangd/unittests/TestTU.cpp
===
--- clang-tools-extra/clangd/unittests/TestTU.cpp
+++ clang-tools-extra/clangd/unittests/TestTU.cpp
@@ -7,6 +7,7 @@
 //===--===//
 
 #include "TestTU.h"
+#include "CompileCommands.h"
 #include "Compiler.h"
 #include "Diagnostics.h"
 #include "TestFS.h"
@@ -56,6 +57,9 @@
   // Put the file name at the end -- this allows the extra arg (-xc++) to
   // override the language setting.
   Argv.push_back(FullFilename);
+
+  auto Mangler = CommandMangler::forTests();
+  Mangler.adjust(Inputs.CompileCommand.CommandLine);
   Inputs.CompileCommand.Filename = FullFilename;
   Inputs.CompileCommand.Directory = testRoot();
   Inputs.Contents = Code;
__

[PATCH] D106535: [clangd] Use CommandMangler in TestTU

2021-07-22 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

I guess this is technically untested, but will be covered after D106527 
?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106535

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


[clang] aa245dd - [clang][lex] NFC: Add explicit cast to silence -Wsign-compare

2021-07-22 Thread Jan Svoboda via cfe-commits

Author: Jan Svoboda
Date: 2021-07-22T12:21:12+02:00
New Revision: aa245ddd4627c98083eb372b95e049073aeb36d2

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

LOG: [clang][lex] NFC: Add explicit cast to silence -Wsign-compare

Added: 


Modified: 
clang/lib/Lex/LiteralSupport.cpp

Removed: 




diff  --git a/clang/lib/Lex/LiteralSupport.cpp 
b/clang/lib/Lex/LiteralSupport.cpp
index bfcb3c478b62d..85d826ce9c6f7 100644
--- a/clang/lib/Lex/LiteralSupport.cpp
+++ b/clang/lib/Lex/LiteralSupport.cpp
@@ -1660,7 +1660,8 @@ void StringLiteralParser::init(ArrayRef 
StringToks){
   constexpr unsigned MaxRawStrDelimLen = 16;
 
   const char *Prefix = ThisTokBuf;
-  while (ThisTokBuf - Prefix < MaxRawStrDelimLen && ThisTokBuf[0] != '(')
+  while (static_cast(ThisTokBuf - Prefix) < MaxRawStrDelimLen &&
+ ThisTokBuf[0] != '(')
 ++ThisTokBuf;
   if (ThisTokBuf[0] != '(')
 return DiagnoseLexingError(StringToks[i].getLocation());



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


[PATCH] D104601: [Preprocessor] Implement -fminimize-whitespace.

2021-07-22 Thread Michael Kruse via Phabricator via cfe-commits
Meinersbur added a comment.

I compiled the Linux kernel (default config, excludes most drivers. Takes 
~18mins to compile) and indeed found two problems:

1. Linux contains `assembler-with-cpp` files. When compiling with clang, it 
processes it with `-E` before passing the result to `as`. There are different 
rules on whether whitespace can be completely removed (`AvoidConcat`) in asm 
files. I changed `ccache` to not pass `-fminimize-whitespace` to assembler 
files and added an error if one tries.

2. Line breaks outside of macros are (more) significant in assembler files. I 
tried to rely more on `Tok.getLocation()` than `Tok.isAtStartOfLine()` (which 
is pretty unreliable) to determine line breaks, which unfortunately caused 
differences even without `-fminimize-whitespace`. The patch is using 
`Tok.isAtStartOfLine()` again.

The clang-13 release branch will be created on July 27. Is there any hope to 
get this merged by then?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104601

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


[PATCH] D104601: [Preprocessor] Implement -fminimize-whitespace.

2021-07-22 Thread Michael Kruse via Phabricator via cfe-commits
Meinersbur updated this revision to Diff 360753.
Meinersbur added a comment.

- Revert test changes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104601

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Options.td
  clang/include/clang/Frontend/PreprocessorOutputOptions.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/PrintPreprocessedOutput.cpp
  clang/lib/Lex/Preprocessor.cpp
  clang/test/Preprocessor/comment_save.c
  clang/test/Preprocessor/first-line-indent.c
  clang/test/Preprocessor/hash_line.c
  clang/test/Preprocessor/line-directive-output-mincol.c
  clang/test/Preprocessor/line-directive-output.c
  clang/test/Preprocessor/macro_space.c
  clang/test/Preprocessor/minimize-whitespace-messages.c
  clang/test/Preprocessor/minimize-whitespace.c
  clang/test/Preprocessor/print_line_include.c
  clang/test/Preprocessor/stringize_space.c

Index: clang/test/Preprocessor/stringize_space.c
===
--- clang/test/Preprocessor/stringize_space.c
+++ clang/test/Preprocessor/stringize_space.c
@@ -1,16 +1,18 @@
 // RUN: %clang_cc1 -E %s | FileCheck --strict-whitespace %s
+// RUN: %clang_cc1 -E -P -fminimize-whitespace %s | FileCheck --strict-whitespace %s --check-prefix=MINWS
 
 #define A(b) -#b  ,  - #b  ,  -# b  ,  - # b
 A()
 
 // CHECK: {{^}}-"" , - "" , -"" , - ""{{$}}
-
+// MINWS: {{^}}-"",-"",-"",-""
 
 #define t(x) #x
 t(a
 c)
 
 // CHECK: {{^}}"a c"{{$}}
+// MINWS-SAME: "a c"
 
 #define str(x) #x
 #define f(x) str(-x)
@@ -18,6 +20,7 @@
 1)
 
 // CHECK: {{^}}"-1"
+// MINWS-SAME: "-1"
 
 #define paste(a,b) str(a&1 | FileCheck %s --strict-whitespace --check-prefix=MINCOL
+// RUN: %clang_cc1 -fminimize-whitespace -E -C %s 2>&1 | FileCheck %s --strict-whitespace --check-prefix=MINCCOL
+// RUN: %clang_cc1 -fminimize-whitespace -E -P %s 2>&1 | FileCheck %s --strict-whitespace --check-prefix=MINWS
+// RUN: %clang_cc1 -fminimize-whitespace -E -C -P %s 2>&1 | FileCheck %s --strict-whitespace --check-prefix=MINCWS
+
+#define NOT_OMP  omp  something
+#define HASH #
+
+  int  a; /*  span-comment  */
+  int  b  ;   //  line-comment
+  _Pragma  (  "omp  barrier"  ) x //  more line-comments
+  #pragma  omp  nothing  //  another comment
+HASH  pragma  NOT_OMP
+  int  e;// again a line
+  int  \
+f  ;
+
+
+// MINCOL:  {{^}}# 9 "{{.*}}minimize-whitespace.c"{{$}}
+// MINCOL:  {{^}}int a;{{$}}
+// MINCOL-NEXT: {{^}}int b;{{$}}
+// MINCOL-NEXT: {{^}}#pragma omp barrier{{$}}
+// MINCOL-NEXT: # 11 "{{.*}}minimize-whitespace.c"
+// MINCOL-NEXT: {{^}}x{{$}}
+// MINCOL-NEXT: {{^}}#pragma omp nothing{{$}}
+// MINCOL-NEXT: {{^ }}#pragma omp something{{$}}
+// MINCOL-NEXT: {{^}}int e;{{$}}
+// MINCOL-NEXT: {{^}}int f;{{$}}
+
+// FIXME: Comments after pragmas disappear, even without -fminimize-whitespace
+// MINCCOL:  {{^}}# 9 "{{.*}}minimize-whitespace.c"{{$}}
+// MINCCOL:  {{^}}int a;/*  span-comment  */{{$}}
+// MINCCOL-NEXT: {{^}}int b;//  line-comment{{$}}
+// MINCCOL-NEXT: {{^}}#pragma omp barrier{{$}}
+// MINCCOL-NEXT: # 11 "{{.*}}minimize-whitespace.c"
+// MINCCOL-NEXT: {{^}}x//  more line-comments{{$}}
+// MINCCOL-NEXT: {{^}}#pragma omp nothing{{$}}
+// MINCCOL-NEXT: {{^ }}#pragma omp something{{$}}
+// MINCCOL-NEXT: {{^}}int e;// again a line{{$}}
+// MINCCOL-NEXT: {{^}}int f;{{$}}
+
+// MINWS:  {{^}}int a;int b;{{$}}
+// MINWS-NEXT: {{^}}#pragma omp barrier{{$}}
+// MINWS-NEXT: {{^}}x{{$}}
+// MINWS-NEXT: {{^}}#pragma omp nothing{{$}}
+// MINWS-NEXT: {{^ }}#pragma omp something int e;int f;{{$}}
+
+// FIXME: Comments after pragmas disappear, even without -fminimize-whitespace
+// MINCWS:  {{^}}int a;/*  span-comment  */int b;//  line-comment{{$}}
+// MINCWS-NEXT: {{^}}#pragma omp barrier{{$}}
+// MINCWS-NEXT: {{^}}x//  more line-comments{{$}}
+// MINCWS-NEXT: {{^}}#pragma omp nothing{{$}}
+// MINCWS-NEXT: {{^ }}#pragma omp something int e;// again a line{{$}}
+// MINCWS-NEXT: {{^}}int f;
+
Index: clang/test/Preprocessor/minimize-whitespace-messages.c
===
--- /dev/null
+++ clang/test/Preprocessor/minimize-whitespace-messages.c
@@ -0,0 +1,8 @@
+// RUN: not %clang -c -fminimize-whitespace %s 2>&1 | FileCheck %s --check-prefix=ON
+// ON: error: invalid argument '-fminimize-whitespace' only allowed with '-E'
+
+// RUN: not %clang -c -fno-minimize-whitespace %s 2>&1 | FileCheck %s  --check-prefix=OFF
+// OFF: error: invalid argument '-fno-minimize-whitespace' only allowed with '-E'
+
+// RUN: not %clang -E -fminimize-whitespace -x assembler-with-cpp %s 2>&1 | FileCheck %s --check-prefix=ASM
+// ASM: error: '-fminimize-whitespace' invalid for input file type
Index: clang/test/Preprocessor/macro_space.c
===
--- clang/test/Preprocesso

[PATCH] D106518: [RISCV] Disable EEW=64 for index values when XLEN=32.

2021-07-22 Thread Fraser Cormack via Phabricator via cfe-commits
frasercrmck added inline comments.



Comment at: clang/include/clang/Basic/riscv_vector.td:555
 
+defvar Xlen32EEWList = [["8", "(Log2EEW:3)"],
+["16", "(Log2EEW:4)"],

jrtc27 wrote:
> Ignoring whether the change is actually correct, this should be capitalised 
> as XLen32EEWList, but really this should actually be RV32 not XLen32 as 
> that's not a term we use.
While we're here I'm wondering whether a top-level 
`Xlen32EEWList`/`RV32EEWList` is conveying the wrong thing. It's only the loads 
and stores that have a different EEW list on RV32, isn't it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106518

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


Re: [PATCH] D106535: [clangd] Use CommandMangler in TestTU

2021-07-22 Thread Kadir Çetinkaya via cfe-commits
yes that's right.

On Thu, Jul 22, 2021 at 12:20 PM Sam McCall via Phabricator <
revi...@reviews.llvm.org> wrote:

> sammccall added a comment.
>
> I guess this is technically untested, but will be covered after D106527 <
> https://reviews.llvm.org/D106527>?
>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D106535/new/
>
> https://reviews.llvm.org/D106535
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D106371: [AIX] Generate large code model relocations when mcmodel=medium on AIX

2021-07-22 Thread Shivam Gupta via Phabricator via cfe-commits
xgupta added a comment.

In D106371#2894736 , @anjankgk wrote:

> Anjan Kumar Guttahalli Krishna 
>
> Thank you!

Seems you are contributing with an official mail, I think you can ask for 
commit access, if you want to continue contributing, bar is quite low in LLVM 
community.
May follow: 
https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access


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

https://reviews.llvm.org/D106371

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


[PATCH] D106527: [clangd] Canonicalize compile flags before applying edits

2021-07-22 Thread Sam McCall via Phabricator via cfe-commits
sammccall accepted this revision.
sammccall added inline comments.
This revision is now accepted and ready to land.



Comment at: clang-tools-extra/clangd/CompileCommands.cpp:210
+  if (!ArgList.hasArgNoClaim(driver::options::OPT__DASH_DASH)) {
+// In theory there might be more than one input, but clangd can't deal with
+// them anyway.

More than one input is a really annoying error to diagnose, would we want to 
detect and log it here? Downside is this code runs *really* often.



Comment at: clang-tools-extra/clangd/CompileCommands.cpp:221
 
-  // Check whether the flag exists, either as -flag or -flag=*
-  auto Has = [&](llvm::StringRef Flag) {
-for (llvm::StringRef Arg : Cmd) {
-  if (Arg.consume_front(Flag) && (Arg.empty() || Arg[0] == '='))
-return true;
-}
-return false;
-  };
-
   // clangd should not write files to disk, including dependency files
   // requested on the command line.

These are copies of the rendered arg list, i think many of them we could 
replace with calls to ArgList.erase before rendering the arg list.
(e.g. syntax-only... if we erased -save-temps and turned off color diagnostics 
in Compiler.cpp, I think that covers everything)

... but wait, is "rendering the arglist" even possible?

(I want to expand the scope of this patch unneccesarily, but it might be a way 
to offset the extra costs...)



Comment at: clang-tools-extra/clangd/CompileCommands.cpp:232
+  if (ResourceDir &&
+  !ArgList.hasArgNoClaim(driver::options::OPT_resource_dir,
+ driver::options::OPT_resource_dir_EQ))

Technically the hasArgNoClaim is stale, we've applied edits to the command 
since then. Probably fine though, not much use for setting resource-dir. (maybe 
we should even drop this check)

hasArgNoClaim is probably cheaper than the old scan we were doing, but its impl 
is crazy: not a simple scan, but also not a simple lookup.



Comment at: clang-tools-extra/clangd/CompileCommands.cpp:238
   // `--sysroot` is a superset of the `-isysroot` argument.
-  if (Sysroot && !Has("-isysroot") && !Has("--sysroot")) {
+  if (Sysroot && !ArgList.hasArgNoClaim(driver::options::OPT__sysroot,
+driver::options::OPT__sysroot_EQ,

OTOH the edits may well set sysroot or isysroot, i'm not sure this is valid :-(



Comment at: clang-tools-extra/clangd/CompileCommands.cpp:246
   if (!ToAppend.empty()) {
 Cmd = tooling::getInsertArgumentAdjuster(
 std::move(ToAppend), tooling::ArgumentInsertPosition::END)(Cmd, "");

while here and worrying about efficiency - should we just search for '--' 
ourselves?
This is an extra copy (due to the ArgsAdjuster interface)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106527

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


[clang] 41adc09 - [clang][AST] Add support for DecompositionDecl to ASTImporter.

2021-07-22 Thread Balázs Kéri via cfe-commits

Author: Balázs Kéri
Date: 2021-07-22T13:09:42+02:00
New Revision: 41adc09b221170065e227f43c7fd21ffce5e2a6e

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

LOG: [clang][AST] Add support for DecompositionDecl to ASTImporter.

BindingDecl was added recently but the related DecompositionDecl is needed
to make C++17 structured bindings importable.
Import of BindingDecl was changed to avoid infinite import loop.

Reviewed By: martong

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

Added: 


Modified: 
clang/lib/AST/ASTImporter.cpp
clang/unittests/AST/ASTImporterTest.cpp

Removed: 




diff  --git a/clang/lib/AST/ASTImporter.cpp b/clang/lib/AST/ASTImporter.cpp
index 8fb55488e836a..787e02029dae7 100644
--- a/clang/lib/AST/ASTImporter.cpp
+++ b/clang/lib/AST/ASTImporter.cpp
@@ -2302,6 +2302,11 @@ ExpectedDecl 
ASTNodeImporter::VisitBindingDecl(BindingDecl *D) {
   if (ToND)
 return ToND;
 
+  BindingDecl *ToD;
+  if (GetImportedOrCreateDecl(ToD, D, Importer.getToContext(), DC, Loc,
+  Name.getAsIdentifierInfo()))
+return ToD;
+
   Error Err = Error::success();
   QualType ToType = importChecked(Err, D->getType());
   Expr *ToBinding = importChecked(Err, D->getBinding());
@@ -2309,11 +2314,6 @@ ExpectedDecl 
ASTNodeImporter::VisitBindingDecl(BindingDecl *D) {
   if (Err)
 return std::move(Err);
 
-  BindingDecl *ToD;
-  if (GetImportedOrCreateDecl(ToD, D, Importer.getToContext(), DC, Loc,
-  Name.getAsIdentifierInfo()))
-return ToD;
-
   ToD->setBinding(ToType, ToBinding);
   ToD->setDecomposedDecl(ToDecomposedDecl);
   addDeclToContexts(D, ToD);
@@ -4098,14 +4098,26 @@ ExpectedDecl ASTNodeImporter::VisitVarDecl(VarDecl *D) {
   if (Err)
 return std::move(Err);
 
-  // Create the imported variable.
   VarDecl *ToVar;
-  if (GetImportedOrCreateDecl(ToVar, D, Importer.getToContext(), DC,
-  ToInnerLocStart, Loc,
-  Name.getAsIdentifierInfo(),
-  ToType, ToTypeSourceInfo,
-  D->getStorageClass()))
-return ToVar;
+  if (auto *FromDecomp = dyn_cast(D)) {
+SmallVector Bindings(FromDecomp->bindings().size());
+if (Error Err =
+ImportArrayChecked(FromDecomp->bindings(), Bindings.begin()))
+  return std::move(Err);
+DecompositionDecl *ToDecomp;
+if (GetImportedOrCreateDecl(
+ToDecomp, FromDecomp, Importer.getToContext(), DC, ToInnerLocStart,
+Loc, ToType, ToTypeSourceInfo, D->getStorageClass(), Bindings))
+  return ToDecomp;
+ToVar = ToDecomp;
+  } else {
+// Create the imported variable.
+if (GetImportedOrCreateDecl(ToVar, D, Importer.getToContext(), DC,
+ToInnerLocStart, Loc,
+Name.getAsIdentifierInfo(), ToType,
+ToTypeSourceInfo, D->getStorageClass()))
+  return ToVar;
+  }
 
   ToVar->setTSCSpec(D->getTSCSpec());
   ToVar->setQualifierInfo(ToQualifierLoc);

diff  --git a/clang/unittests/AST/ASTImporterTest.cpp 
b/clang/unittests/AST/ASTImporterTest.cpp
index 3536b1cfcbffc..d49e7c0cd1fef 100644
--- a/clang/unittests/AST/ASTImporterTest.cpp
+++ b/clang/unittests/AST/ASTImporterTest.cpp
@@ -3725,6 +3725,32 @@ TEST_P(ImportVariables, ImportBindingDecl) {
   VerifyImport("y3");
 }
 
+TEST_P(ImportVariables, ImportDecompositionDeclArray) {
+  Decl *From, *To;
+  std::tie(From, To) = getImportedDecl(
+  R"(
+  void declToImport() {
+int a[2] = {1,2};
+auto [x1,y1] = a;
+  };
+  )",
+  Lang_CXX17, "", Lang_CXX17);
+
+  TranslationUnitDecl *FromTU = From->getTranslationUnitDecl();
+  auto *FromDecomp =
+  FirstDeclMatcher().match(FromTU, decompositionDecl());
+  auto *ToDecomp = Import(FromDecomp, Lang_CXX17);
+  EXPECT_TRUE(ToDecomp);
+
+  ArrayRef FromB = FromDecomp->bindings();
+  ArrayRef ToB = ToDecomp->bindings();
+  EXPECT_EQ(FromB.size(), ToB.size());
+  for (unsigned int I = 0; I < FromB.size(); ++I) {
+auto *ToBI = Import(FromB[I], Lang_CXX17);
+EXPECT_EQ(ToBI, ToB[I]);
+  }
+}
+
 struct ImportClasses : ASTImporterOptionSpecificTestBase {};
 
 TEST_P(ImportClasses, ImportDefinitionWhenProtoIsInNestedToContext) {



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


[PATCH] D105354: [clang][AST] Add support for DecompositionDecl to ASTImporter.

2021-07-22 Thread Balázs Kéri 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 rG41adc09b2211: [clang][AST] Add support for DecompositionDecl 
to ASTImporter. (authored by balazske).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105354

Files:
  clang/lib/AST/ASTImporter.cpp
  clang/unittests/AST/ASTImporterTest.cpp


Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -3725,6 +3725,32 @@
   VerifyImport("y3");
 }
 
+TEST_P(ImportVariables, ImportDecompositionDeclArray) {
+  Decl *From, *To;
+  std::tie(From, To) = getImportedDecl(
+  R"(
+  void declToImport() {
+int a[2] = {1,2};
+auto [x1,y1] = a;
+  };
+  )",
+  Lang_CXX17, "", Lang_CXX17);
+
+  TranslationUnitDecl *FromTU = From->getTranslationUnitDecl();
+  auto *FromDecomp =
+  FirstDeclMatcher().match(FromTU, decompositionDecl());
+  auto *ToDecomp = Import(FromDecomp, Lang_CXX17);
+  EXPECT_TRUE(ToDecomp);
+
+  ArrayRef FromB = FromDecomp->bindings();
+  ArrayRef ToB = ToDecomp->bindings();
+  EXPECT_EQ(FromB.size(), ToB.size());
+  for (unsigned int I = 0; I < FromB.size(); ++I) {
+auto *ToBI = Import(FromB[I], Lang_CXX17);
+EXPECT_EQ(ToBI, ToB[I]);
+  }
+}
+
 struct ImportClasses : ASTImporterOptionSpecificTestBase {};
 
 TEST_P(ImportClasses, ImportDefinitionWhenProtoIsInNestedToContext) {
Index: clang/lib/AST/ASTImporter.cpp
===
--- clang/lib/AST/ASTImporter.cpp
+++ clang/lib/AST/ASTImporter.cpp
@@ -2302,6 +2302,11 @@
   if (ToND)
 return ToND;
 
+  BindingDecl *ToD;
+  if (GetImportedOrCreateDecl(ToD, D, Importer.getToContext(), DC, Loc,
+  Name.getAsIdentifierInfo()))
+return ToD;
+
   Error Err = Error::success();
   QualType ToType = importChecked(Err, D->getType());
   Expr *ToBinding = importChecked(Err, D->getBinding());
@@ -2309,11 +2314,6 @@
   if (Err)
 return std::move(Err);
 
-  BindingDecl *ToD;
-  if (GetImportedOrCreateDecl(ToD, D, Importer.getToContext(), DC, Loc,
-  Name.getAsIdentifierInfo()))
-return ToD;
-
   ToD->setBinding(ToType, ToBinding);
   ToD->setDecomposedDecl(ToDecomposedDecl);
   addDeclToContexts(D, ToD);
@@ -4098,14 +4098,26 @@
   if (Err)
 return std::move(Err);
 
-  // Create the imported variable.
   VarDecl *ToVar;
-  if (GetImportedOrCreateDecl(ToVar, D, Importer.getToContext(), DC,
-  ToInnerLocStart, Loc,
-  Name.getAsIdentifierInfo(),
-  ToType, ToTypeSourceInfo,
-  D->getStorageClass()))
-return ToVar;
+  if (auto *FromDecomp = dyn_cast(D)) {
+SmallVector Bindings(FromDecomp->bindings().size());
+if (Error Err =
+ImportArrayChecked(FromDecomp->bindings(), Bindings.begin()))
+  return std::move(Err);
+DecompositionDecl *ToDecomp;
+if (GetImportedOrCreateDecl(
+ToDecomp, FromDecomp, Importer.getToContext(), DC, ToInnerLocStart,
+Loc, ToType, ToTypeSourceInfo, D->getStorageClass(), Bindings))
+  return ToDecomp;
+ToVar = ToDecomp;
+  } else {
+// Create the imported variable.
+if (GetImportedOrCreateDecl(ToVar, D, Importer.getToContext(), DC,
+ToInnerLocStart, Loc,
+Name.getAsIdentifierInfo(), ToType,
+ToTypeSourceInfo, D->getStorageClass()))
+  return ToVar;
+  }
 
   ToVar->setTSCSpec(D->getTSCSpec());
   ToVar->setQualifierInfo(ToQualifierLoc);


Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -3725,6 +3725,32 @@
   VerifyImport("y3");
 }
 
+TEST_P(ImportVariables, ImportDecompositionDeclArray) {
+  Decl *From, *To;
+  std::tie(From, To) = getImportedDecl(
+  R"(
+  void declToImport() {
+int a[2] = {1,2};
+auto [x1,y1] = a;
+  };
+  )",
+  Lang_CXX17, "", Lang_CXX17);
+
+  TranslationUnitDecl *FromTU = From->getTranslationUnitDecl();
+  auto *FromDecomp =
+  FirstDeclMatcher().match(FromTU, decompositionDecl());
+  auto *ToDecomp = Import(FromDecomp, Lang_CXX17);
+  EXPECT_TRUE(ToDecomp);
+
+  ArrayRef FromB = FromDecomp->bindings();
+  ArrayRef ToB = ToDecomp->bindings();
+  EXPECT_EQ(FromB.size(), ToB.size());
+  for (unsigned int I = 0; I < FromB.size(); ++I) {
+auto *ToBI = Import(FromB[I], Lang_CXX17);
+EXPECT_EQ(ToBI, ToB[I]);
+  }
+}
+
 struct ImportClasses : ASTImporterOptionSpecificTestBase {};
 
 TEST_P(ImportClasses, 

[PATCH] D106266: [C++4OpenCL] Add run line standard aliases clc++1.0 and CLC++1.0

2021-07-22 Thread Raphael Isemann via Phabricator via cfe-commits
teemperor added a comment.

Quick note to prevent some confusion: I saw this patch and realized that the 
LLDB change was only necessary because some Clang code got copy pasted into 
LLDB. I removed that copy in https://reviews.llvm.org/D106537 so if you see 
merge conflicts while merging this, you can just drop the LLDB changes as they 
shouldn't be necessary once my patch landed. Thanks!


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

https://reviews.llvm.org/D106266

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


[clang] bde9415 - [hwasan] Use stack safety analysis.

2021-07-22 Thread Florian Mayer via cfe-commits

Author: Florian Mayer
Date: 2021-07-22T12:04:54+01:00
New Revision: bde9415fef25e9ff6e10595a2f4f5004dd62f10a

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

LOG: [hwasan] Use stack safety analysis.

This avoids unnecessary instrumentation.

Reviewed By: eugenis, vitalybuka

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

Added: 
clang/test/CodeGen/hwasan-stack-safety-analysis.c
llvm/test/Instrumentation/HWAddressSanitizer/stack-safety-analysis.ll

Modified: 
clang/lib/CodeGen/BackendUtil.cpp
llvm/include/llvm/Transforms/Instrumentation/HWAddressSanitizer.h
llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/BackendUtil.cpp 
b/clang/lib/CodeGen/BackendUtil.cpp
index 9aa67ed2a67ba..481f5347d978b 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -314,14 +314,19 @@ static void addHWAddressSanitizerPasses(const 
PassManagerBuilder &Builder,
   static_cast(Builder);
   const CodeGenOptions &CGOpts = BuilderWrapper.getCGOpts();
   bool Recover = CGOpts.SanitizeRecover.has(SanitizerKind::HWAddress);
-  PM.add(
-  createHWAddressSanitizerLegacyPassPass(/*CompileKernel*/ false, 
Recover));
+  PM.add(createHWAddressSanitizerLegacyPassPass(
+  /*CompileKernel*/ false, Recover,
+  /*DisableOptimization*/ CGOpts.OptimizationLevel == 0));
 }
 
 static void addKernelHWAddressSanitizerPasses(const PassManagerBuilder 
&Builder,
-legacy::PassManagerBase &PM) {
+  legacy::PassManagerBase &PM) {
+  const PassManagerBuilderWrapper &BuilderWrapper =
+  static_cast(Builder);
+  const CodeGenOptions &CGOpts = BuilderWrapper.getCGOpts();
   PM.add(createHWAddressSanitizerLegacyPassPass(
-  /*CompileKernel*/ true, /*Recover*/ true));
+  /*CompileKernel*/ true, /*Recover*/ true,
+  /*DisableOptimization*/ CGOpts.OptimizationLevel == 0));
 }
 
 static void addGeneralOptsForMemorySanitizer(const PassManagerBuilder &Builder,
@@ -1164,7 +1169,9 @@ static void addSanitizers(const Triple &TargetTriple,
 auto HWASanPass = [&](SanitizerMask Mask, bool CompileKernel) {
   if (LangOpts.Sanitize.has(Mask)) {
 bool Recover = CodeGenOpts.SanitizeRecover.has(Mask);
-MPM.addPass(HWAddressSanitizerPass(CompileKernel, Recover));
+MPM.addPass(HWAddressSanitizerPass(
+CompileKernel, Recover,
+/*DisableOptimization=*/CodeGenOpts.OptimizationLevel == 0));
   }
 };
 HWASanPass(SanitizerKind::HWAddress, false);

diff  --git a/clang/test/CodeGen/hwasan-stack-safety-analysis.c 
b/clang/test/CodeGen/hwasan-stack-safety-analysis.c
new file mode 100644
index 0..5c4f34027bacd
--- /dev/null
+++ b/clang/test/CodeGen/hwasan-stack-safety-analysis.c
@@ -0,0 +1,15 @@
+// RUN: %clang -fsanitize=hwaddress -target aarch64-linux-gnu -S -emit-llvm 
-mllvm -hwasan-use-stack-safety=true -mllvm -hwasan-generate-tags-with-calls 
-O2 %s -o - | FileCheck %s --check-prefix=SAFETY
+// RUN: %clang -fsanitize=hwaddress -target aarch64-linux-gnu -S -emit-llvm 
-mllvm -hwasan-use-stack-safety=false -mllvm -hwasan-generate-tags-with-calls 
-O2 %s -o - | FileCheck %s --check-prefix=NOSAFETY
+
+// Default when optimizing, but not with O0.
+// RUN: %clang -fsanitize=hwaddress -target aarch64-linux-gnu -S -emit-llvm 
-mllvm -hwasan-generate-tags-with-calls -O2 %s -o - | FileCheck %s 
--check-prefix=SAFETY
+// RUN: %clang -fsanitize=hwaddress -target aarch64-linux-gnu -S -emit-llvm 
-mllvm -hwasan-generate-tags-with-calls -O0 %s -o - | FileCheck %s 
--check-prefix=NOSAFETY
+
+int main(int argc, char **argv) {
+  char buf[10];
+  volatile char *x = buf;
+  *x = 0;
+  return buf[0];
+  // NOSAFETY: __hwasan_generate_tag
+  // SAFETY-NOT: __hwasan_generate_tag
+}

diff  --git a/llvm/include/llvm/Transforms/Instrumentation/HWAddressSanitizer.h 
b/llvm/include/llvm/Transforms/Instrumentation/HWAddressSanitizer.h
index 76e02f06435c3..2e4f3338030a4 100644
--- a/llvm/include/llvm/Transforms/Instrumentation/HWAddressSanitizer.h
+++ b/llvm/include/llvm/Transforms/Instrumentation/HWAddressSanitizer.h
@@ -25,17 +25,21 @@ namespace llvm {
 class HWAddressSanitizerPass : public PassInfoMixin {
 public:
   explicit HWAddressSanitizerPass(bool CompileKernel = false,
-  bool Recover = false);
+  bool Recover = false,
+  bool DisableOptimization = false);
   PreservedAnalyses run(Module &M, ModuleAnalysisManager &MAM);
   static bool isRequired() { return true; }
 
 private:
   bool CompileKernel;
   bool Recover;
+  bool DisableOptimization;
 };
 
-FunctionPass *createHWAdd

[PATCH] D105703: [hwasan] Use stack safety analysis.

2021-07-22 Thread Florian Mayer via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
fmayer marked 4 inline comments as done.
Closed by commit rGbde9415fef25: [hwasan] Use stack safety analysis. (authored 
by fmayer).

Changed prior to commit:
  https://reviews.llvm.org/D105703?vs=360735&id=360761#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105703

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  clang/test/CodeGen/hwasan-stack-safety-analysis.c
  llvm/include/llvm/Transforms/Instrumentation/HWAddressSanitizer.h
  llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
  llvm/test/Instrumentation/HWAddressSanitizer/stack-safety-analysis.ll

Index: llvm/test/Instrumentation/HWAddressSanitizer/stack-safety-analysis.ll
===
--- /dev/null
+++ llvm/test/Instrumentation/HWAddressSanitizer/stack-safety-analysis.ll
@@ -0,0 +1,42 @@
+; RUN: opt -hwasan -hwasan-use-stack-safety=1 -hwasan-generate-tags-with-calls -S < %s | FileCheck %s --check-prefixes=SAFETY
+; RUN: opt -hwasan -hwasan-use-stack-safety=0 -hwasan-generate-tags-with-calls -S < %s | FileCheck %s --check-prefixes=NOSAFETY
+
+target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
+target triple = "aarch64-unknown-linux-gnu"
+
+; Check a safe alloca to ensure it does not get a tag.
+define i32 @test_load(i32* %a) sanitize_hwaddress {
+entry:
+  ; NOSAFETY: call {{.*}}__hwasan_generate_tag
+  ; SAFETY-NOT: call {{.*}}__hwasan_generate_tag
+  %buf.sroa.0 = alloca i8, align 4
+  call void @llvm.lifetime.start.p0i8(i64 1, i8* nonnull %buf.sroa.0)
+  store volatile i8 0, i8* %buf.sroa.0, align 4, !tbaa !8
+  call void @llvm.lifetime.end.p0i8(i64 1, i8* nonnull %buf.sroa.0)
+  ret i32 0
+}
+
+; Check a non-safe alloca to ensure it gets a tag.
+define i32 @test_use(i32* %a) sanitize_hwaddress {
+entry:
+  ; NOSAFETY: call {{.*}}__hwasan_generate_tag
+  ; SAFETY: call {{.*}}__hwasan_generate_tag
+  %buf.sroa.0 = alloca i8, align 4
+  call void @use(i8* nonnull %buf.sroa.0)
+  call void @llvm.lifetime.start.p0i8(i64 1, i8* nonnull %buf.sroa.0)
+  store volatile i8 0, i8* %buf.sroa.0, align 4, !tbaa !8
+  call void @llvm.lifetime.end.p0i8(i64 1, i8* nonnull %buf.sroa.0)
+  ret i32 0
+}
+
+; Function Attrs: argmemonly mustprogress nofree nosync nounwind willreturn
+declare void @llvm.lifetime.start.p0i8(i64 immarg, i8* nocapture)
+
+; Function Attrs: argmemonly mustprogress nofree nosync nounwind willreturn
+declare void @llvm.lifetime.end.p0i8(i64 immarg, i8* nocapture)
+
+declare void @use(i8* nocapture)
+
+!8 = !{!9, !9, i64 0}
+!9 = !{!"omnipotent char", !10, i64 0}
+!10 = !{!"Simple C/C++ TBAA"}
Index: llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
===
--- llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
+++ llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
@@ -17,6 +17,7 @@
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/Triple.h"
+#include "llvm/Analysis/StackSafetyAnalysis.h"
 #include "llvm/BinaryFormat/ELF.h"
 #include "llvm/IR/Attributes.h"
 #include "llvm/IR/BasicBlock.h"
@@ -109,6 +110,11 @@
cl::desc("instrument stack (allocas)"),
cl::Hidden, cl::init(true));
 
+static cl::opt
+ClUseStackSafety("hwasan-use-stack-safety", cl::Hidden, cl::init(true),
+ cl::Hidden, cl::desc("Use Stack Safety analysis results"),
+ cl::Optional);
+
 static cl::opt ClUARRetagToZero(
 "hwasan-uar-retag-to-zero",
 cl::desc("Clear alloca tags before returning from the function to allow "
@@ -204,11 +210,23 @@
   return ClInstrumentWithCalls || TargetTriple.getArch() == Triple::x86_64;
 }
 
+bool mightUseStackSafetyAnalysis(bool DisableOptimization) {
+  return ClUseStackSafety.getNumOccurrences() ? ClUseStackSafety
+  : !DisableOptimization;
+}
+
+bool shouldUseStackSafetyAnalysis(const Triple &TargetTriple,
+  bool DisableOptimization) {
+  return shouldInstrumentStack(TargetTriple) &&
+ mightUseStackSafetyAnalysis(DisableOptimization);
+}
 /// An instrumentation pass implementing detection of addressability bugs
 /// using tagged pointers.
 class HWAddressSanitizer {
 public:
-  HWAddressSanitizer(Module &M, bool CompileKernel, bool Recover) : M(M) {
+  HWAddressSanitizer(Module &M, bool CompileKernel, bool Recover,
+ const StackSafetyGlobalInfo *SSI)
+  : M(M), SSI(SSI) {
 this->Recover = ClRecover.getNumOccurrences() > 0 ? ClRecover : Recover;
 this->CompileKernel = ClEnableKhwasan.getNumOccurrences() > 0
   ? ClEnableKhwasan
@@ -217,6 +235,8 @@
 initi

[PATCH] D106518: [RISCV] Disable EEW=64 for index values when XLEN=32.

2021-07-22 Thread Jianjian Guan via Phabricator via cfe-commits
jacquesguan added inline comments.



Comment at: clang/include/clang/Basic/riscv_vector.td:555
 
+defvar Xlen32EEWList = [["8", "(Log2EEW:3)"],
+["16", "(Log2EEW:4)"],

frasercrmck wrote:
> jrtc27 wrote:
> > Ignoring whether the change is actually correct, this should be capitalised 
> > as XLen32EEWList, but really this should actually be RV32 not XLen32 as 
> > that's not a term we use.
> While we're here I'm wondering whether a top-level 
> `Xlen32EEWList`/`RV32EEWList` is conveying the wrong thing. It's only the 
> loads and stores that have a different EEW list on RV32, isn't it?
Yes, only for index load/store, we should add the macro to the generated header 
to make `EEW=64` just available on RV64.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106518

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


[PATCH] D106504: [OpenCL] Change default standard version to CL1.2

2021-07-22 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added inline comments.



Comment at: clang/test/CodeGenOpenCL/spir_version.cl:2
+// RUN: %clang_cc1 %s -triple "spir-unknown-unknown" -emit-llvm -o - 
-cl-std=CL1.0 | FileCheck %s --check-prefix=CHECK-SPIR-CL10
 // RUN: %clang_cc1 %s -triple "spir-unknown-unknown" -emit-llvm -o - 
-cl-std=CL1.2 | FileCheck %s --check-prefix=CHECK-SPIR-CL12
 // RUN: %clang_cc1 %s -triple "spir-unknown-unknown" -emit-llvm -o - 
-cl-std=CL2.0 | FileCheck %s --check-prefix=CHECK-SPIR-CL20

svenvh wrote:
> Would it be worth having an invocation without any `-cl-std=` and verifying 
> that it produces the same version metadata as CL1.2?
From a unit test perspective, I personally think that it is sufficient to test 
that the default version is CL1.2 separately and then test the expected 
functionality of CL1.2 separately. Otherwise when we change the default version 
later we will need to modify all the tests again. I don't see a value in this.


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

https://reviews.llvm.org/D106504

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


[clang] 789a4a2 - Revert "[hwasan] Use stack safety analysis."

2021-07-22 Thread Florian Mayer via cfe-commits

Author: Florian Mayer
Date: 2021-07-22T12:16:16+01:00
New Revision: 789a4a2e5c30b3eee632446d5b99bba808587836

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

LOG: Revert "[hwasan] Use stack safety analysis."

This reverts commit bde9415fef25e9ff6e10595a2f4f5004dd62f10a.

Added: 


Modified: 
clang/lib/CodeGen/BackendUtil.cpp
llvm/include/llvm/Transforms/Instrumentation/HWAddressSanitizer.h
llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp

Removed: 
clang/test/CodeGen/hwasan-stack-safety-analysis.c
llvm/test/Instrumentation/HWAddressSanitizer/stack-safety-analysis.ll



diff  --git a/clang/lib/CodeGen/BackendUtil.cpp 
b/clang/lib/CodeGen/BackendUtil.cpp
index 481f5347d978b..9aa67ed2a67ba 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -314,19 +314,14 @@ static void addHWAddressSanitizerPasses(const 
PassManagerBuilder &Builder,
   static_cast(Builder);
   const CodeGenOptions &CGOpts = BuilderWrapper.getCGOpts();
   bool Recover = CGOpts.SanitizeRecover.has(SanitizerKind::HWAddress);
-  PM.add(createHWAddressSanitizerLegacyPassPass(
-  /*CompileKernel*/ false, Recover,
-  /*DisableOptimization*/ CGOpts.OptimizationLevel == 0));
+  PM.add(
+  createHWAddressSanitizerLegacyPassPass(/*CompileKernel*/ false, 
Recover));
 }
 
 static void addKernelHWAddressSanitizerPasses(const PassManagerBuilder 
&Builder,
-  legacy::PassManagerBase &PM) {
-  const PassManagerBuilderWrapper &BuilderWrapper =
-  static_cast(Builder);
-  const CodeGenOptions &CGOpts = BuilderWrapper.getCGOpts();
+legacy::PassManagerBase &PM) {
   PM.add(createHWAddressSanitizerLegacyPassPass(
-  /*CompileKernel*/ true, /*Recover*/ true,
-  /*DisableOptimization*/ CGOpts.OptimizationLevel == 0));
+  /*CompileKernel*/ true, /*Recover*/ true));
 }
 
 static void addGeneralOptsForMemorySanitizer(const PassManagerBuilder &Builder,
@@ -1169,9 +1164,7 @@ static void addSanitizers(const Triple &TargetTriple,
 auto HWASanPass = [&](SanitizerMask Mask, bool CompileKernel) {
   if (LangOpts.Sanitize.has(Mask)) {
 bool Recover = CodeGenOpts.SanitizeRecover.has(Mask);
-MPM.addPass(HWAddressSanitizerPass(
-CompileKernel, Recover,
-/*DisableOptimization=*/CodeGenOpts.OptimizationLevel == 0));
+MPM.addPass(HWAddressSanitizerPass(CompileKernel, Recover));
   }
 };
 HWASanPass(SanitizerKind::HWAddress, false);

diff  --git a/clang/test/CodeGen/hwasan-stack-safety-analysis.c 
b/clang/test/CodeGen/hwasan-stack-safety-analysis.c
deleted file mode 100644
index 5c4f34027bacd..0
--- a/clang/test/CodeGen/hwasan-stack-safety-analysis.c
+++ /dev/null
@@ -1,15 +0,0 @@
-// RUN: %clang -fsanitize=hwaddress -target aarch64-linux-gnu -S -emit-llvm 
-mllvm -hwasan-use-stack-safety=true -mllvm -hwasan-generate-tags-with-calls 
-O2 %s -o - | FileCheck %s --check-prefix=SAFETY
-// RUN: %clang -fsanitize=hwaddress -target aarch64-linux-gnu -S -emit-llvm 
-mllvm -hwasan-use-stack-safety=false -mllvm -hwasan-generate-tags-with-calls 
-O2 %s -o - | FileCheck %s --check-prefix=NOSAFETY
-
-// Default when optimizing, but not with O0.
-// RUN: %clang -fsanitize=hwaddress -target aarch64-linux-gnu -S -emit-llvm 
-mllvm -hwasan-generate-tags-with-calls -O2 %s -o - | FileCheck %s 
--check-prefix=SAFETY
-// RUN: %clang -fsanitize=hwaddress -target aarch64-linux-gnu -S -emit-llvm 
-mllvm -hwasan-generate-tags-with-calls -O0 %s -o - | FileCheck %s 
--check-prefix=NOSAFETY
-
-int main(int argc, char **argv) {
-  char buf[10];
-  volatile char *x = buf;
-  *x = 0;
-  return buf[0];
-  // NOSAFETY: __hwasan_generate_tag
-  // SAFETY-NOT: __hwasan_generate_tag
-}

diff  --git a/llvm/include/llvm/Transforms/Instrumentation/HWAddressSanitizer.h 
b/llvm/include/llvm/Transforms/Instrumentation/HWAddressSanitizer.h
index 2e4f3338030a4..76e02f06435c3 100644
--- a/llvm/include/llvm/Transforms/Instrumentation/HWAddressSanitizer.h
+++ b/llvm/include/llvm/Transforms/Instrumentation/HWAddressSanitizer.h
@@ -25,21 +25,17 @@ namespace llvm {
 class HWAddressSanitizerPass : public PassInfoMixin {
 public:
   explicit HWAddressSanitizerPass(bool CompileKernel = false,
-  bool Recover = false,
-  bool DisableOptimization = false);
+  bool Recover = false);
   PreservedAnalyses run(Module &M, ModuleAnalysisManager &MAM);
   static bool isRequired() { return true; }
 
 private:
   bool CompileKernel;
   bool Recover;
-  bool DisableOptimization;
 };
 
-FunctionPass *
-createHWAddressSanitizerLegacyPassPass(bool CompileKernel = false,

[PATCH] D105703: [hwasan] Use stack safety analysis.

2021-07-22 Thread Florian Mayer via Phabricator via cfe-commits
fmayer reopened this revision.
fmayer added a comment.
This revision is now accepted and ready to land.

Sorry. broke a buildbot again: 
https://lab.llvm.org/buildbot/#/builders/139/builds/7613/steps/6/logs/FAIL__Clang__asan_c

I am not sure why I cannot reproduce this locally.

  Pass 'HWAddressSanitizer' is not initialized.
  Verify if there is a pass dependency cycle.
  Required Passes:
  clang: 
/home/buildbot/buildbot-root/llvm-clang-x86_64-sie-ubuntu-fast/llvm-project/llvm/lib/IR/LegacyPassManager.cpp:715:
 void llvm::PMTopLevelManager::schedulePass(llvm::Pass*): Assertion `PI && 
"Expected required passes to be initialized"' failed.
  PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash 
backtrace, preprocessed source, and associated run script.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105703

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


[PATCH] D99436: [OPENMP]Fix PR49366: crash on VLAs in task untied regions.

2021-07-22 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

Better to fix this before the next release.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99436

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


[PATCH] D106266: [C++4OpenCL] Add run line standard aliases clc++1.0 and CLC++1.0

2021-07-22 Thread Justas Janickas via Phabricator via cfe-commits
Topotuna added a comment.

That is good to know. Thank you for sorting it out


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

https://reviews.llvm.org/D106266

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


[PATCH] D99350: [OPENMP]Fix PR49649: The introduction of $ref globals is not always valid.

2021-07-22 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

Better to fix this before the next release.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99350

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


[PATCH] D105297: [OPENMP]Fix PR50347: Mapping of global scope deep object fails.

2021-07-22 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

Better to fix this before the next release.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105297

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


[PATCH] D105151: [OPENMP]Fix PR50733: unexpected final value of list-item in linear clause in loop construct.

2021-07-22 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

If the problem exists, better to fix it before the next release.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105151

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


[PATCH] D106504: [OpenCL] Change default standard version to CL1.2

2021-07-22 Thread Sven van Haastregt via Phabricator via cfe-commits
svenvh accepted this revision.
svenvh added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/test/CodeGenOpenCL/spir_version.cl:2
+// RUN: %clang_cc1 %s -triple "spir-unknown-unknown" -emit-llvm -o - 
-cl-std=CL1.0 | FileCheck %s --check-prefix=CHECK-SPIR-CL10
 // RUN: %clang_cc1 %s -triple "spir-unknown-unknown" -emit-llvm -o - 
-cl-std=CL1.2 | FileCheck %s --check-prefix=CHECK-SPIR-CL12
 // RUN: %clang_cc1 %s -triple "spir-unknown-unknown" -emit-llvm -o - 
-cl-std=CL2.0 | FileCheck %s --check-prefix=CHECK-SPIR-CL20

Anastasia wrote:
> svenvh wrote:
> > Would it be worth having an invocation without any `-cl-std=` and verifying 
> > that it produces the same version metadata as CL1.2?
> From a unit test perspective, I personally think that it is sufficient to 
> test that the default version is CL1.2 separately and then test the expected 
> functionality of CL1.2 separately. Otherwise when we change the default 
> version later we will need to modify all the tests again. I don't see a value 
> in this.
Agreed, and `clang/test/Preprocessor/predefined-macros.c` seems to do that 
already.


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

https://reviews.llvm.org/D106504

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


[PATCH] D106005: [Docs] Define matrix initialisation in MatrixTypes documentation

2021-07-22 Thread Saurabh Jha via Phabricator via cfe-commits
SaurabhJha added a comment.

In D106005#2895716 , @fhahn wrote:

> Thank you very much for working on this! Are you planning on implementing the 
> new specification as well? It would probably be good to land the update to 
> the spec in close succession to the implementation, to avoid confusing users.

Yes, that's my plan. Once this is in, I will start working on the 
implementation right away.




Comment at: clang/docs/MatrixTypes.rst:279
+The number of constituent arrays must equal the number rows in the matrix type 
M and the number of elements
+in each constituent array must equal the number of columns in the matrix type.
+

fhahn wrote:
> SaurabhJha wrote:
> > rjmccall wrote:
> > > This is contradicted by your first example.  I think you want to say 
> > > something like
> > > 
> > > > A value of matrix type `M` can be initialized with an initializer list:
> > > >
> > > > (examples)
> > > >
> > > > If the initializer list is empty, all elements of the matrix are 
> > > > zero-initialized.  Otherwise, the initializer list must consist of 
> > > > `M::rows` initializer lists, each of which must consist of `M::columns` 
> > > > expressions, each of which is used to initialize the corresponding 
> > > > element of the matrix (that is, `m[i][j]` is initialized by the `j`th 
> > > > expression of the `i`th initializer list in the initializer).  Element 
> > > > designators are not allowed.
> > > 
> > > That's assuming you want to allow `{}`, but I think that's probably a 
> > > good idea.  At the very least, you already have to define how objects of 
> > > static storage duration are zero-initialized, and having a way to do that 
> > > explicitly always seems wise to me.
> > That sounds great @rjmccall, thanks for your suggestions.
> > 
> > I think I got confused between whether to allow `{}` but as you suggested, 
> > I think we should.
> That looks good, thanks! 
> 
> Another thing to consider is whether we would like to provide a convenient 
> syntax to initialise all elements with an user-specified value, i.e. should 
> we allow something like `m = {99};`, which would broadcast 99 to all elements 
> of the matrix?
That sounds good. Do we have a way to infer the number of rows and columns for 
a matrix object `m` so that we could broadcast correctly? I will amend the docs 
later today.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106005

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


[PATCH] D104931: [AArch64] Wire up ILP32 ABI support in Clang

2021-07-22 Thread Amanieu d'Antras via Phabricator via cfe-commits
Amanieu added a comment.

Ping.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104931

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


[PATCH] D106527: [clangd] Canonicalize compile flags before applying edits

2021-07-22 Thread Sam McCall via Phabricator via cfe-commits
sammccall added inline comments.



Comment at: clang-tools-extra/clangd/CompileCommands.cpp:210
+  if (!ArgList.hasArgNoClaim(driver::options::OPT__DASH_DASH)) {
+// In theory there might be more than one input, but clangd can't deal with
+// them anyway.

sammccall wrote:
> More than one input is a really annoying error to diagnose, would we want to 
> detect and log it here? Downside is this code runs *really* often.
Another option would be to delete all the OPT_INPUTs and append the actual 
filename (CompileCommand::Filename)

This seems like it would define this class of errors out of existence, maybe?

Layering doesn't make it easy to do that right here, though :-\


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106527

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


[PATCH] D104601: [Preprocessor] Implement -fminimize-whitespace.

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

In D104601#2895941 , @Meinersbur 
wrote:

> I compiled the Linux kernel (default config, excludes most drivers. Takes 
> ~18mins to compile) and indeed found two problems:

Thank you, that's super helpful validation!

> The clang-13 release branch will be created on July 27. Is there any hope to 
> get this merged by then?

I think there is, but I'm an eternal optimist. :-) This LGTM, but you should 
wait a day or two before landing it in case @dblaikie or @rsmith have concerns.




Comment at: clang/lib/Driver/ToolChains/Clang.cpp:6059-6062
+if (!types::isCXX(InputType) && !types::isOpenCL(InputType) &&
+!types::isObjC(InputType) && !types::isCuda(InputType) &&
+!types::isHIP(InputType) && InputType != types::TY_PP_C &&
+InputType != types::TY_C)

One downside to this approach as opposed to using a `switch` is that it'll be 
easy to add new languages and forget to update this. However, we don't do that 
particularly often and this will loudly tell users about the lack of support, 
so I think it's fine as-is.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104601

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


[PATCH] D106434: [OpenCL] Add cl_khr_integer_dot_product

2021-07-22 Thread Stuart Brady via Phabricator via cfe-commits
stuart accepted this revision.
stuart added a comment.

LGTM, too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106434

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


[clang] b9b696b - [clang][fpenv][patch] Change clang option -ffp-model=precise to select ffp-contract=on

2021-07-22 Thread Melanie Blower via cfe-commits

Author: Melanie Blower
Date: 2021-07-22T07:59:18-04:00
New Revision: b9b696bba6702a31ac0995a494cd31c730ade5ec

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

LOG: [clang][fpenv][patch] Change clang option -ffp-model=precise to select 
ffp-contract=on

Change the ffp-model=precise to enables -ffp-contract=on (previously
-ffp-model=precise enabled -ffp-contract=fast). This is a follow-up
to Andy Kaylor's comments in the llvm-dev discussion "Floating Point
semantic modes". From the same email thread, I put Andy's distillation
of floating point options and floating point modes into UsersManual.rst
Also fixes bugs.llvm.org/show_bug.cgi?id=50222

Reviewed By: rjmccall, andrew.kaylor

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

Added: 


Modified: 
clang/docs/UsersManual.rst
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/CodeGen/ffp-contract-option.c
clang/test/CodeGen/ppc-emmintrin.c
clang/test/CodeGen/ppc-xmmintrin.c
clang/test/Driver/fp-model.c

Removed: 




diff  --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst
index f7f76ed3f3e20..e5c343124eb29 100644
--- a/clang/docs/UsersManual.rst
+++ b/clang/docs/UsersManual.rst
@@ -1260,8 +1260,50 @@ installed.
 Controlling Floating Point Behavior
 ---
 
-Clang provides a number of ways to control floating point behavior. The options
-are listed below.
+Clang provides a number of ways to control floating point behavior, including
+with command line options and source pragmas. This section
+describes the various floating point semantic modes and the corresponding 
options.
+
+.. csv-table:: Floating Point Semantic Modes
+  :header: "Mode", "Values"
+  :widths: 15, 30, 30
+
+  "except_behavior", "{ignore, strict, may_trap}", "ffp-exception-behavior"
+  "fenv_access", "{off, on}", "(none)"
+  "rounding_mode", "{dynamic, tonearest, downward, upward, towardzero}", 
"frounding-math"
+  "contract", "{on, off, fast}", "ffp-contract"
+  "denormal_fp_math", "{IEEE, PreserveSign, PositiveZero}", "fdenormal-fp-math"
+  "denormal_fp32_math", "{IEEE, PreserveSign, PositiveZero}", 
"fdenormal-fp-math-fp32"
+  "support_math_errno", "{on, off}", "fmath-errno"
+  "no_honor_nans", "{on, off}", "fhonor-nans"
+  "no_honor_infinities", "{on, off}", "fhonor-infinities"
+  "no_signed_zeros", "{on, off}", "fsigned-zeros"
+  "allow_reciprocal", "{on, off}", "freciprocal-math"
+  "allow_approximate_fns", "{on, off}", "(none)"
+  "allow_reassociation", "{on, off}", "fassociative-math"
+
+
+This table describes the option settings that correspond to the three
+floating point semantic models: precise (the default), strict, and fast.
+
+
+.. csv-table:: Floating Point Models
+  :header: "Mode", "Precise", "Strict", "Fast"
+  :widths: 25, 15, 15, 15
+
+  "except_behavior", "ignore", "strict", "ignore"
+  "fenv_access", "off", "on", "off"
+  "rounding_mode", "tonearest", "dynamic", "tonearest"
+  "contract", "on", "off", "fast"
+  "denormal_fp_math", "IEEE", "IEEE", "PreserveSign"
+  "denormal_fp32_math", "IEEE","IEEE", "PreserveSign"
+  "support_math_errno", "on", "on", "off"
+  "no_honor_nans", "off", "off", "on"
+  "no_honor_infinities", "off", "off", "on"
+  "no_signed_zeros", "off", "off", "on"
+  "allow_reciprocal", "off", "off", "on"
+  "allow_approximate_fns", "off", "off", "on"
+  "allow_reassociation", "off", "off", "on"
 
 .. option:: -ffast-math
 
@@ -1456,7 +1498,7 @@ Note that floating-point operations performed as part of 
constant initialization
and ``fast``.
Details:
 
-   * ``precise`` Disables optimizations that are not value-safe on 
floating-point data, although FP contraction (FMA) is enabled 
(``-ffp-contract=fast``).  This is the default behavior.
+   * ``precise`` Disables optimizations that are not value-safe on 
floating-point data, although FP contraction (FMA) is enabled 
(``-ffp-contract=on``).  This is the default behavior.
* ``strict`` Enables ``-frounding-math`` and 
``-ffp-exception-behavior=strict``, and disables contractions (FMA).  All of 
the ``-ffast-math`` enablements are disabled. Enables ``STDC FENV_ACCESS``: by 
default ``FENV_ACCESS`` is disabled. This option setting behaves as though 
``#pragma STDC FENV_ACESS ON`` appeared at the top of the source file.
* ``fast`` Behaves identically to specifying both ``-ffast-math`` and 
``ffp-contract=fast``
 

diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 837ead86d6202..928fff7001b67 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -2637,7 +2637,7 @@ static void RenderFloatingPointOptions(const ToolChain 
&TC, const Driver &D,
 
   llvm::DenormalMode DenormalFPMath = DefaultDenormalFPMath;
   

[PATCH] D74436: Change clang option -ffp-model=precise to select ffp-contract=on

2021-07-22 Thread Melanie Blower via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGb9b696bba670: [clang][fpenv][patch] Change clang option 
-ffp-model=precise to select ffp… (authored by mibintc).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74436

Files:
  clang/docs/UsersManual.rst
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/ffp-contract-option.c
  clang/test/CodeGen/ppc-emmintrin.c
  clang/test/CodeGen/ppc-xmmintrin.c
  clang/test/Driver/fp-model.c

Index: clang/test/Driver/fp-model.c
===
--- clang/test/Driver/fp-model.c
+++ clang/test/Driver/fp-model.c
@@ -1,88 +1,90 @@
 // Test that incompatible combinations of -ffp-model= options
 // and other floating point options get a warning diagnostic.
-//
-// REQUIRES: clang-driver
 
-// RUN: %clang -### -ffp-model=fast -ffp-contract=off -c %s 2>&1 \
+// RUN: %clang -target x86_64 -### -ffp-model=fast -ffp-contract=off -c %s 2>&1 \
 // RUN:   | FileCheck --check-prefix=WARN %s
 // WARN: warning: overriding '-ffp-model=fast' option with '-ffp-contract=off' [-Woverriding-t-option]
 
-// RUN: %clang -### -ffp-model=fast -ffp-contract=on -c %s 2>&1 \
+// RUN: %clang -target x86_64 -### -ffp-model=fast -ffp-contract=on -c %s 2>&1 \
 // RUN:   | FileCheck --check-prefix=WARN1 %s
 // WARN1: warning: overriding '-ffp-model=fast' option with '-ffp-contract=on' [-Woverriding-t-option]
 
-// RUN: %clang -### -ffp-model=strict -fassociative-math -c %s 2>&1 \
+// RUN: %clang -target x86_64 -### -ffp-model=strict -fassociative-math -c %s 2>&1 \
 // RUN:   | FileCheck --check-prefix=WARN2 %s
 // WARN2: warning: overriding '-ffp-model=strict' option with '-fassociative-math' [-Woverriding-t-option]
 
-// RUN: %clang -### -ffp-model=strict -ffast-math -c %s 2>&1 \
+// RUN: %clang -target x86_64 -### -ffp-model=strict -ffast-math -c %s 2>&1 \
 // RUN:   | FileCheck --check-prefix=WARN3 %s
 // WARN3: warning: overriding '-ffp-model=strict' option with '-ffast-math' [-Woverriding-t-option]
 
-// RUN: %clang -### -ffp-model=strict -ffinite-math-only -c %s 2>&1 \
+// RUN: %clang -target x86_64 -### -ffp-model=strict -ffinite-math-only -c %s 2>&1 \
 // RUN:   | FileCheck --check-prefix=WARN4 %s
 // WARN4: warning: overriding '-ffp-model=strict' option with '-ffinite-math-only' [-Woverriding-t-option]
 
-// RUN: %clang -### -ffp-model=strict -ffp-contract=fast -c %s 2>&1 \
+// RUN: %clang -target x86_64 -### -ffp-model=strict -ffp-contract=fast -c %s 2>&1 \
 // RUN:   | FileCheck --check-prefix=WARN5 %s
 // WARN5: warning: overriding '-ffp-model=strict' option with '-ffp-contract=fast' [-Woverriding-t-option]
 
-// RUN: %clang -### -ffp-model=strict -ffp-contract=on -c %s 2>&1 \
+// RUN: %clang -target x86_64 -### -ffp-model=strict -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=WARN6 %s
+// WARN6: warning: overriding '-ffp-model=strict' option with '-ffp-contract=fast' [-Woverriding-t-option]
+
+// RUN: %clang -target x86_64 -### -ffp-model=strict -ffp-contract=on -c %s 2>&1 \
 // RUN:   | FileCheck --check-prefix=WARN7 %s
 // WARN7: warning: overriding '-ffp-model=strict' option with '-ffp-contract=on' [-Woverriding-t-option]
 
-// RUN: %clang -### -ffp-model=strict -fno-honor-infinities -c %s 2>&1 \
+// RUN: %clang -target x86_64 -### -ffp-model=strict -fno-honor-infinities -c %s 2>&1 \
 // RUN:   | FileCheck --check-prefix=WARN8 %s
 // WARN8: warning: overriding '-ffp-model=strict' option with '-fno-honor-infinities' [-Woverriding-t-option]
 
-// RUN: %clang -### -ffp-model=strict -fno-honor-nans -c %s 2>&1 \
+// RUN: %clang -target x86_64 -### -ffp-model=strict -fno-honor-nans -c %s 2>&1 \
 // RUN:   | FileCheck --check-prefix=WARN9 %s
 // WARN9: warning: overriding '-ffp-model=strict' option with '-fno-honor-nans' [-Woverriding-t-option]
 
-// RUN: %clang -### -ffp-model=strict -fno-rounding-math -c %s 2>&1 \
+// RUN: %clang -target x86_64 -### -ffp-model=strict -fno-rounding-math -c %s 2>&1 \
 // RUN:   | FileCheck --check-prefix=WARNa %s
 // WARNa: warning: overriding '-ffp-model=strict' option with '-fno-rounding-math' [-Woverriding-t-option]
 
-// RUN: %clang -### -ffp-model=strict -fno-signed-zeros -c %s 2>&1 \
+// RUN: %clang -target x86_64 -### -ffp-model=strict -fno-signed-zeros -c %s 2>&1 \
 // RUN:   | FileCheck --check-prefix=WARNb %s
 // WARNb: warning: overriding '-ffp-model=strict' option with '-fno-signed-zeros' [-Woverriding-t-option]
 
-// RUN: %clang -### -ffp-model=strict -fno-trapping-math -c %s 2>&1 \
+// RUN: %clang -target x86_64 -### -ffp-model=strict -fno-trapping-math -c %s 2>&1 \
 // RUN:   | FileCheck --check-prefix=WARNc %s
 // WARNc: warning: overriding '-ffp-model=strict' option with '-fno-trapping-math' [-Woverriding-t-option]
 
-// RUN: %clang -### -ffp-model=strict -freciprocal-math -c %s 2>&1 \
+// RUN: %clang -target x86_64 -### -ffp-model=strict

[PATCH] D105555: [PoC][RISCV][Clang] Compute the default target-abi if it's empty.

2021-07-22 Thread Alex Bradbury via Phabricator via cfe-commits
asb added a comment.

This looks like a good improvement to me - anything that still makes it a 
"[PoC]" proof of concept?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D10

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


[PATCH] D106504: [OpenCL] Change default standard version to CL1.2

2021-07-22 Thread Anton Zabaznov via Phabricator via cfe-commits
azabaznov added inline comments.



Comment at: clang/test/Parser/opencl-atomics-cl20.cl:7
 
-#if defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ >= CL_VERSION_1_2
+#if defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ >= CL_VERSION_2_0
 #define LANG_VER_OK

As OpenCL C version defaults to 1.2, I think LANG_VER_OK should always be 
defined now (due to run lines). But OpenCL C 1.2 has never been tested in this 
test... Is it a mistake in current rest?


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

https://reviews.llvm.org/D106504

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


[PATCH] D103938: Diagnose -Wunused-value in constant evaluation context

2021-07-22 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/test/Sema/i-c-e.c:77-78
+  // expected-warning {{expression result unused}}
+int comma3[(1, 2)];   // expected-warning {{variable length array folded to 
constant array as an extension}} \
+  // expected-warning {{expression result unused}}
 

ychen wrote:
> aaron.ballman wrote:
> > I think this diagnostic is kind of unfortunate because it increases my 
> > confusion -- the expression result is most assuredly *not* unused in these 
> > cases because it's used in the definition of the type.
> > the expression result is most assuredly *not* unused in these cases because 
> > it's used in the definition of the type.
>  
> Do you mean "1" is used in the definition of the type? The warning is for "1" 
> in this case. If I change `1` to any other number, the type of `comma3` 
> should not change, I think that means `1` is not used.
> Do you mean "1" is used in the definition of the type? The warning is for "1" 
> in this case. If I change 1 to any other number, the type of comma3 should 
> not change, I think that means 1 is not used.

I agree that the `1` is unused.

The trouble is that the diagnostic doesn't make that clear -- it just says the 
expression result is unused, which makes it sound like the entire comma 
expression result value is unused (which is not the case). I think the 
diagnostic should more clearly specify *what* is unused in this case, otherwise 
users may think the diagnostic is a false positive.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103938

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


[PATCH] D106349: [clang-format] respect AfterEnum for enums

2021-07-22 Thread Michael Zimmermann via Phabricator via cfe-commits
m1cha updated this revision to Diff 360776.
m1cha edited the summary of this revision.
m1cha added a comment.

- rebased to `main`
- fixed the test `IndentAccessModifiers`


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

https://reviews.llvm.org/D106349

Files:
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/unittests/Format/FormatTest.cpp


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -2451,6 +2451,14 @@
   Style.AllowShortEnumsOnASingleLine = true;
   verifyFormat("enum { A, B, C } ShortEnum1, ShortEnum2;", Style);
   Style.AllowShortEnumsOnASingleLine = false;
+  verifyFormat("enum {\n"
+   "  A,\n"
+   "  B,\n"
+   "  C\n"
+   "} ShortEnum1, ShortEnum2;",
+   Style);
+  Style.BreakBeforeBraces = FormatStyle::BS_Custom;
+  Style.BraceWrapping.AfterEnum = true;
   verifyFormat("enum\n"
"{\n"
"  A,\n"
@@ -22123,8 +22131,7 @@
Style);
   // Enumerations are not records and should be unaffected.
   Style.AllowShortEnumsOnASingleLine = false;
-  verifyFormat("enum class E\n"
-   "{\n"
+  verifyFormat("enum class E {\n"
"  A,\n"
"  B\n"
"};\n",
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -706,6 +706,8 @@
 return Style.BraceWrapping.AfterUnion;
   if (InitialToken.is(tok::kw_struct))
 return Style.BraceWrapping.AfterStruct;
+  if (InitialToken.is(tok::kw_enum))
+return Style.BraceWrapping.AfterEnum;
   return false;
 }
 
@@ -2511,6 +2513,8 @@
 }
 
 bool UnwrappedLineParser::parseEnum() {
+  const FormatToken &InitialToken = *FormatTok;
+
   // Won't be 'enum' for NS_ENUMs.
   if (FormatTok->Tok.is(tok::kw_enum))
 nextToken();
@@ -2561,7 +2565,8 @@
 return true;
   }
 
-  if (!Style.AllowShortEnumsOnASingleLine)
+  if (!Style.AllowShortEnumsOnASingleLine &&
+  ShouldBreakBeforeBrace(Style, InitialToken))
 addUnwrappedLine();
   // Parse enum body.
   nextToken();


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -2451,6 +2451,14 @@
   Style.AllowShortEnumsOnASingleLine = true;
   verifyFormat("enum { A, B, C } ShortEnum1, ShortEnum2;", Style);
   Style.AllowShortEnumsOnASingleLine = false;
+  verifyFormat("enum {\n"
+   "  A,\n"
+   "  B,\n"
+   "  C\n"
+   "} ShortEnum1, ShortEnum2;",
+   Style);
+  Style.BreakBeforeBraces = FormatStyle::BS_Custom;
+  Style.BraceWrapping.AfterEnum = true;
   verifyFormat("enum\n"
"{\n"
"  A,\n"
@@ -22123,8 +22131,7 @@
Style);
   // Enumerations are not records and should be unaffected.
   Style.AllowShortEnumsOnASingleLine = false;
-  verifyFormat("enum class E\n"
-   "{\n"
+  verifyFormat("enum class E {\n"
"  A,\n"
"  B\n"
"};\n",
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -706,6 +706,8 @@
 return Style.BraceWrapping.AfterUnion;
   if (InitialToken.is(tok::kw_struct))
 return Style.BraceWrapping.AfterStruct;
+  if (InitialToken.is(tok::kw_enum))
+return Style.BraceWrapping.AfterEnum;
   return false;
 }
 
@@ -2511,6 +2513,8 @@
 }
 
 bool UnwrappedLineParser::parseEnum() {
+  const FormatToken &InitialToken = *FormatTok;
+
   // Won't be 'enum' for NS_ENUMs.
   if (FormatTok->Tok.is(tok::kw_enum))
 nextToken();
@@ -2561,7 +2565,8 @@
 return true;
   }
 
-  if (!Style.AllowShortEnumsOnASingleLine)
+  if (!Style.AllowShortEnumsOnASingleLine &&
+  ShouldBreakBeforeBrace(Style, InitialToken))
 addUnwrappedLine();
   // Parse enum body.
   nextToken();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D105555: [PoC][RISCV][Clang] Compute the default target-abi if it's empty.

2021-07-22 Thread Alexander Richardson via Phabricator via cfe-commits
arichardson added inline comments.



Comment at: llvm/include/llvm/Support/TargetParser.h:177
 StringRef resolveTuneCPUAlias(StringRef TuneCPU, bool IsRV64);
+StringRef computeABIByArch(bool HasD, bool HasE, bool IsRV64);
 

Maybe this should be `computeDefaultABIFromArch()`? If `llvm::RISCVISAInfo` can 
be used here passing `const llvm::RISCVISAInfo&` to the function would also 
avoid some duplicated lines.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D10

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


[PATCH] D106216: Disallow narrowing conversions to bool in explicit specififers.

2021-07-22 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/lib/Sema/SemaOverload.cpp:5638
   ImplicitConversionSequence ICS =
-  CCE == Sema::CCEK_ExplicitBool
-  ? TryContextuallyConvertToBool(S, From)
-  : TryCopyInitialization(S, From, T,
-  /*SuppressUserConversions=*/false,
-  /*InOverloadResolution=*/false,
-  /*AllowObjCWritebackConversion=*/false,
-  /*AllowExplicit=*/false);
+  TryCopyInitialization(S, From, T,
+/*SuppressUserConversions=*/false,

This function is checking converted constant expressions which was not touched 
by p1401r5, and it looks like this will break anything attempting to to 
contextual conversion constant expressions of type bool per 
http://eel.is/c++draft/expr.const#10 because it's removing the attempt to 
contextually convert to bool here.



Comment at: clang/lib/Sema/SemaOverload.cpp:5638
   ImplicitConversionSequence ICS =
-  CCE == Sema::CCEK_ExplicitBool
-  ? TryContextuallyConvertToBool(S, From)
-  : TryCopyInitialization(S, From, T,
-  /*SuppressUserConversions=*/false,
-  /*InOverloadResolution=*/false,
-  /*AllowObjCWritebackConversion=*/false,
-  /*AllowExplicit=*/false);
+  TryCopyInitialization(S, From, T,
+/*SuppressUserConversions=*/false,

aaron.ballman wrote:
> This function is checking converted constant expressions which was not 
> touched by p1401r5, and it looks like this will break anything attempting to 
> to contextual conversion constant expressions of type bool per 
> http://eel.is/c++draft/expr.const#10 because it's removing the attempt to 
> contextually convert to bool here.
Also, I don't think P1401 was applied as a DR (but we should double check!) so 
I'd expect some checks for the language standard to gate the behavior. If P1401 
was applied as a DR, then we should add some tests to clang/test/CXX with the 
proper DR markings so that our DR status page gets updated.



Comment at: clang/test/SemaCXX/cxx2a-explicit-bool.cpp:731
+
+namespace P1401 {
+

Curiously, these tests already have this behavior without this patch applied: 
https://godbolt.org/z/13PojdWEe


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106216

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


[PATCH] D106431: [clang-tidy] Fix cppcoreguidelines-init-variables with enum judgement

2021-07-22 Thread gehry via Phabricator via cfe-commits
Sockke added a comment.

At present, Our views on preventing UB are basically the same, so a warning 
still needs to be reported (BTW, the original version will not report warnings 
for enum class types). The final question is what is the recommended value for 
initialization and whether to provide the automatic fix.  Hope you can give us 
a direction, thanks!@aaron.ballman


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106431

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


[PATCH] D106084: [DebugInfo] Switch to using constructor homing (-debug-info-kind=constructor) by default when debug info is enabled

2021-07-22 Thread Paul Robinson via Phabricator via cfe-commits
probinson added inline comments.



Comment at: clang/lib/Frontend/CompilerInvocation.cpp:1636
+if (Opts.getDebugInfo() == codegenoptions::DebugInfoConstructor)
+  Opts.setDebugInfo(codegenoptions::LimitedDebugInfo);
 

No... you want to check both options in one call, otherwise 
`-fno-use-ctor-homing -fuse-ctor-homing` will prefer the `no` version instead 
of last-one-wins.

I suggest fiddling the options should be done separately.
Also if you want to make it a clang option, the option name should have `debug` 
in it; pretty sure all the -f options related to debug info do that, and in any 
case it's a good idea.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106084

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


[clang] 6bb042e - Implement _ExtInt conversion rules

2021-07-22 Thread Aaron Ballman via cfe-commits

Author: Aaron Ballman
Date: 2021-07-22T09:10:36-04:00
New Revision: 6bb042e70024354acc65457e153b40d50cada4f5

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

LOG: Implement _ExtInt conversion rules

Clang implemented the _ExtInt datatype as a bit-precise integer type,
which was then proposed to WG14. WG14 has accepted the proposal
(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2709.pdf), but Clang
requires some additional work as a result.

In the original Clang implementation, we elected to disallow implicit
conversions involving these types until after WG14 finalized the rules.
This patch implements the rules decided by WG14: no integer promotion
for bit-precise types, conversions prefer the larger of the two types
and in the event of a tie (say _ExtInt(32) and a 32-bit int), the
standard type wins.

There are more changes still needed to conform to N2709, but those will
be handled in follow-up patches.

Added: 


Modified: 
clang/lib/Sema/SemaExpr.cpp
clang/test/Sema/ext-int.c
clang/test/SemaCXX/ext-int.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaExpr.cpp b/clang/lib/Sema/SemaExpr.cpp
index 80f9c1e1b372..3926c49077ce 100644
--- a/clang/lib/Sema/SemaExpr.cpp
+++ b/clang/lib/Sema/SemaExpr.cpp
@@ -1541,11 +1541,6 @@ QualType Sema::UsualArithmeticConversions(ExprResult 
&LHS, ExprResult &RHS,
   if (LHSType == RHSType)
 return LHSType;
 
-  // ExtInt types aren't subject to conversions between them or normal 
integers,
-  // so this fails.
-  if(LHSType->isExtIntType() || RHSType->isExtIntType())
-return QualType();
-
   // At this point, we have two 
diff erent arithmetic types.
 
   // Diagnose attempts to convert between __float128 and long double where

diff  --git a/clang/test/Sema/ext-int.c b/clang/test/Sema/ext-int.c
index 6996942a204b..9cca3d296ada 100644
--- a/clang/test/Sema/ext-int.c
+++ b/clang/test/Sema/ext-int.c
@@ -1,12 +1,75 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s -Wimplicit-int-conversion -triple 
x86_64-gnu-linux
+// RUN: %clang_cc1 -fsyntax-only -verify %s -Wimplicit-int-conversion 
-Wno-unused -triple x86_64-gnu-linux
 
 typedef _ExtInt(31) EI31;
 
 void Ternary(_ExtInt(30) s30, EI31 s31a, _ExtInt(31) s31b,
  _ExtInt(32) s32, int b) {
-  b ? s30 : s31a; // expected-error{{incompatible operand types}}
-  b ? s31a : s30; // expected-error{{incompatible operand types}}
-  b ? s32 : 0; // expected-error{{incompatible operand types}}
+  b ? s30 : s31a;
+  b ? s31a : s30;
+  b ? s32 : 0;
   (void)(b ? s31a : s31b);
   (void)(s30 ? s31a : s31b);
 }
+
+struct CursedBitField {
+  _ExtInt(4) A : 8; // expected-error {{width of bit-field 'A' (8 bits) 
exceeds the width of its type (4 bits)}}
+};
+
+#define EXPR_HAS_TYPE(EXPR, TYPE) _Generic((EXPR), default : 0, TYPE : 1)
+
+void Ops(void) {
+  _ExtInt(4) x4_s = 1;
+  _ExtInt(32) x32_s = 1;
+  _ExtInt(43) x43_s = 1;
+  unsigned _ExtInt(4) x4_u = 1;
+  unsigned _ExtInt(43) x43_u = 1;
+  unsigned _ExtInt(32) x32_u = 1;
+  int x_int = 1;
+  unsigned x_uint = 1;
+
+  // Same size/sign ops don't change type.
+  _Static_assert(EXPR_HAS_TYPE(x43_s + x43_s, _ExtInt(43)), "");
+  _Static_assert(EXPR_HAS_TYPE(x4_s - x4_s, _ExtInt(4)), "");
+  _Static_assert(EXPR_HAS_TYPE(x43_u * x43_u, unsigned _ExtInt(43)), "");
+  _Static_assert(EXPR_HAS_TYPE(x4_u / x4_u, unsigned _ExtInt(4)), "");
+
+  // Unary ops shouldn't go through integer promotions.
+  _Static_assert(EXPR_HAS_TYPE(x4_s++, _ExtInt(4)), "");
+  _Static_assert(EXPR_HAS_TYPE(++x4_s, _ExtInt(4)), "");
+  _Static_assert(EXPR_HAS_TYPE(x4_u++, unsigned _ExtInt(4)), "");
+  _Static_assert(EXPR_HAS_TYPE(++x4_u, unsigned _ExtInt(4)), "");
+  _Static_assert(EXPR_HAS_TYPE(+x4_s, _ExtInt(4)), "");
+  _Static_assert(EXPR_HAS_TYPE(-x4_s, _ExtInt(4)), "");
+  _Static_assert(EXPR_HAS_TYPE(~x4_u, unsigned _ExtInt(4)), "");
+
+  // This one really does convert to a 
diff erent result type though.
+  _Static_assert(EXPR_HAS_TYPE(!x4_u, int), "");
+
+  // Test binary ops pick the correct common type.
+  _Static_assert(EXPR_HAS_TYPE(x43_s + x_int, _ExtInt(43)), "");
+  _Static_assert(EXPR_HAS_TYPE(x43_u + x_int, unsigned _ExtInt(43)), "");
+  _Static_assert(EXPR_HAS_TYPE(x32_s + x_int, int), "");
+  _Static_assert(EXPR_HAS_TYPE(x32_u + x_int, unsigned int), "");
+  _Static_assert(EXPR_HAS_TYPE(x32_s + x_uint, unsigned int), "");
+  _Static_assert(EXPR_HAS_TYPE(x32_u + x_uint, unsigned int), "");
+  _Static_assert(EXPR_HAS_TYPE(x4_s + x_int, int), "");
+  _Static_assert(EXPR_HAS_TYPE(x4_u + x_int, int), "");
+  _Static_assert(EXPR_HAS_TYPE(x4_s + x_uint, unsigned int), "");
+  _Static_assert(EXPR_HAS_TYPE(x4_u + x_uint, unsigned int), "");
+}
+
+void FromPaper1(void) {
+  // Test the examples of conversion and promotion rules from C2x 6.3.1.8.
+  _

[PATCH] D106431: [clang-tidy] Fix cppcoreguidelines-init-variables with enum judgement

2021-07-22 Thread Whisperity via Phabricator via cfe-commits
whisperity added a comment.

The problem with enums is that translating //zero// (0, 0.0, nullptr, etc...) 
to the enum case is not always apparent. A warning **should** always be given. 
And //if// you can find a zero member in the enum, we can report an automated 
suggestion for that.

To give an example

  enum class BaseColour { BLACK, RED, GREEN, BLUE, WHITE };

`BLACK` is the `0`, so we can fix-it. If the `0` is the first member (usually 
in enums that have a well-defined "default" or "None" case...), then, it is 
alright to use that as the automated fix.

However, if there isn't a "zero case" in the enum, for example:

  enum class Something {
FOO = -2,
BAR, // This will be -1
BAZ = 84,
QUX  // This will be 85
  };

then simply using the first member might not be the best fitting action, so in 
such case, I would opt for //no FixIt//. But, obviously, yes for giving a 
warning.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106431

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


[PATCH] D105997: Implement _ExtInt conversion rules

2021-07-22 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman closed this revision.
aaron.ballman added a comment.

Thanks for the reviews; I've committed in 
6bb042e70024354acc65457e153b40d50cada4f5 
.


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

https://reviews.llvm.org/D105997

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


[PATCH] D106542: [OPENMP]Fix PR49787: Codegen for calling __tgt_target_teams_nowait_mapper has too few arguments.

2021-07-22 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev created this revision.
ABataev added reviewers: jdoerfert, mikerice, jyu2.
Herald added subscribers: guansong, yaxunl.
ABataev requested review of this revision.
Herald added subscribers: llvm-commits, sstefan1.
Herald added projects: clang, LLVM.

Added missed arguments in
__tgt_target_teams_nowait_mapper/__tgt_target_nowait_mapper runtime
functions calls.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D106542

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/test/OpenMP/declare_mapper_codegen.cpp
  clang/test/OpenMP/target_codegen.cpp
  clang/test/OpenMP/target_depend_codegen.cpp
  clang/test/OpenMP/target_parallel_codegen.cpp
  clang/test/OpenMP/target_parallel_depend_codegen.cpp
  clang/test/OpenMP/target_parallel_for_codegen.cpp
  clang/test/OpenMP/target_parallel_for_depend_codegen.cpp
  clang/test/OpenMP/target_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/target_parallel_for_simd_depend_codegen.cpp
  clang/test/OpenMP/target_simd_codegen.cpp
  clang/test/OpenMP/target_simd_depend_codegen.cpp
  clang/test/OpenMP/target_teams_codegen.cpp
  clang/test/OpenMP/target_teams_depend_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_depend_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_depend_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_simd_depend_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_simd_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_simd_depend_codegen.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPKinds.def

Index: llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
===
--- llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
+++ llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
@@ -381,12 +381,14 @@
 __OMP_RTL(__kmpc_push_target_tripcount_mapper, false, Void, IdentPtr, Int64, Int64)
 __OMP_RTL(__tgt_target_mapper, false, Int32, IdentPtr, Int64, VoidPtr, Int32, VoidPtrPtr,
   VoidPtrPtr, Int64Ptr, Int64Ptr, VoidPtrPtr, VoidPtrPtr)
-__OMP_RTL(__tgt_target_nowait_mapper, false, Int32, IdentPtr, Int64, VoidPtr, Int32,
-  VoidPtrPtr, VoidPtrPtr, Int64Ptr, Int64Ptr, VoidPtrPtr, VoidPtrPtr)
+__OMP_RTL(__tgt_target_nowait_mapper, false, Int32, IdentPtr, Int64, VoidPtr,
+  Int32, VoidPtrPtr, VoidPtrPtr, Int64Ptr, Int64Ptr, VoidPtrPtr,
+  VoidPtrPtr, Int32, VoidPtr, Int32, VoidPtr)
 __OMP_RTL(__tgt_target_teams_mapper, false, Int32, IdentPtr, Int64, VoidPtr, Int32,
   VoidPtrPtr, VoidPtrPtr, Int64Ptr, Int64Ptr, VoidPtrPtr, VoidPtrPtr, Int32, Int32)
-__OMP_RTL(__tgt_target_teams_nowait_mapper, false, Int32, IdentPtr, Int64, VoidPtr, Int32,
-  VoidPtrPtr, VoidPtrPtr, Int64Ptr, Int64Ptr, VoidPtrPtr, VoidPtrPtr, Int32, Int32)
+__OMP_RTL(__tgt_target_teams_nowait_mapper, false, Int32, IdentPtr, Int64,
+  VoidPtr, Int32, VoidPtrPtr, VoidPtrPtr, Int64Ptr, Int64Ptr,
+  VoidPtrPtr, VoidPtrPtr, Int32, Int32, Int32, VoidPtr, Int32, VoidPtr)
 __OMP_RTL(__tgt_register_requires, false, Void, Int64)
 __OMP_RTL(__tgt_target_data_begin_mapper, false, Void, IdentPtr, Int64, Int32, VoidPtrPtr,
   VoidPtrPtr, Int64Ptr, Int64Ptr, VoidPtrPtr, VoidPtrPtr)
Index: clang/test/OpenMP/target_teams_distribute_simd_depend_codegen.cpp
===
--- clang/test/OpenMP/target_teams_distribute_simd_depend_codegen.cpp
+++ clang/test/OpenMP/target_teams_distribute_simd_depend_codegen.cpp
@@ -242,8 +242,8 @@
 // OMP50-32:   [[DEVICE_CAP:%.+]] = getelementptr inbounds %{{.+}}, %{{.+}}* %{{.+}}, i32 0, i32 3
 // CHECK:   [[DEV:%.+]] = load i32, i32* [[DEVICE_CAP]],
 // CHECK:   [[DEVICE:%.+]] = sext i32 [[DEV]] to i64
-// OMP45:   [[RET:%.+]] = call i32 @__tgt_target_teams_nowait_mapper(%struct.ident_t* @{{.+}}, i64 [[DEVICE]], i8* @{{[^,]+}}, i32 2, i8** [[BPR:%[^,]+]], i8** [[PR:%[^,]+]], i64* [[SZT]], i64* getelementptr inbounds ([2 x i64], [2 x i64]* [[MAPT]], i32 0, i32 0), i8** null, i8** null, i32 0, i32 1)
-// OMP50:   [[RET:%.+]] = call i32 @__tgt_target_teams_nowait_mapper(%struct.ident_t* @{{.+}}, i64 [[DEVICE]], i8* @{{[^,]+}}, i32 3, i8** [[BPR:%[^,]+]], i8** [[PR:%[^,]+]], i64* [[SZT]], i64* getelementptr inbounds ([3 x i64], [3 x i64]* [[MAPT]], i32 0, i32 0), i8** null, i8** null, i32 0, i32 1)
+// OMP45:   [[RET:%.+]] = call i32 @__tgt_target_teams_nowait_mapper(%struct.ident_t* @{{.+}}, i64 [[DEVICE]], i8* @{{[^,]+}}, i32 2, i8** [[BPR:%[^,]+]], i8** [[PR:%[^,]+]], i64* [[SZT]], i64* getelementptr inbounds ([2 x i64], [2 x i64]* [[MAPT]], i32 0, i32 0), i8** null, i8** null, i32 0, i32 1, i32 0, i8* null, i32 0, i8* null)
+// OMP50:   [[RET:%.+]] = call i32 @__tgt_target_teams_nowait_mapper(%struct.ident_t* @{{.+}}, i64 [[DEVICE]], i8* @{{[^,]+}}, i32 3, i8** [[BPR:%[^,]+]], i8** [[PR:%[^,]+]], i64* [[SZT]], i64* getelementptr inbounds ([3 x i64], [3 x i64]* [[MAP

[PATCH] D105821: [analyzer] [WIP] Model destructor for std::unique_ptr

2021-07-22 Thread Deep Majumder via Phabricator via cfe-commits
RedDocMD added a comment.

> But before we go there we should decide whether we want to actually go for 
> inlining (or otherwise default-evaluating) these destructors. If we do, we 
> should probably not spend too much time on improving invalidation in the 
> checker, because default evaluation would do that properly for us anyway 
> (well, it doesn't really dodge any problems such as the absence of the 
> necessary AST so we'll probably have to solve all these problems anyway, just 
> in a different setting). So it's great that we've fixed `evalCall` for 
> destructors, this could definitely land as a separate patch (tested via 
> `debug.AnalysisOrder`), but we really need to think what to do next here. So 
> I recommend gathering some data to see if proper destructor evaluation is 
> actually a real problem.

`MallocChecker` doesn't seem to mind not evaluating destructors properly. With 
the current version of the patch, the following code doesn't emit any warnings:

  class SillyPtr {
int *ptr;
bool wasMalloced;
  public:
SillyPtr(int *ptr, bool wasMalloced = false) : 
ptr(ptr), 
wasMalloced(wasMalloced) {}
~SillyPtr() {
if (wasMalloced) free(ptr);
else delete ptr;
}
  };
  
  void foo() {
int *ptr = new int(13);
SillyPtr silly(ptr);
// No leak here!
  }

I am going to remove the debug dumps and run this patch on the projects in the 
`clang/utils/analyzer/projects` folder. If I don't find any false positives 
being caused due to this lack of modelling, then I think we can defer the 
proper handling of destructors (ie, finish up the invalidation) and move on to 
the other remaining problems (notes on get for an instance).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105821

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


[PATCH] D103385: [clang-tidy] bugprone-forwarding-reference-overload: support non-type template parameters

2021-07-22 Thread Jesse Towner via Phabricator via cfe-commits
jwtowner added a comment.

Friendly bump in case this was missed. Without this fix, 
bugprone-forwarding-reference-overload is not currently usable in a lot of 
codebases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103385

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


[clang] 4296d63 - Revert "[clang][fpenv][patch] Change clang option -ffp-model=precise to select ffp-contract=on"

2021-07-22 Thread Melanie Blower via cfe-commits

Author: Melanie Blower
Date: 2021-07-22T09:40:54-04:00
New Revision: 4296d633b08dcfc5bfb2df0800995df4b30ac196

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

LOG: Revert "[clang][fpenv][patch] Change clang option -ffp-model=precise to 
select ffp-contract=on"

This reverts commit b9b696bba6702a31ac0995a494cd31c730ade5ec.
Buildbot failures see https://lab.llvm.org/buildbot#builders/118/builds/4138
and https://lab.llvm.org/buildbot#builders/110/builds/5112

Added: 


Modified: 
clang/docs/UsersManual.rst
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/CodeGen/ffp-contract-option.c
clang/test/CodeGen/ppc-emmintrin.c
clang/test/CodeGen/ppc-xmmintrin.c
clang/test/Driver/fp-model.c

Removed: 




diff  --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst
index e5c343124eb29..f7f76ed3f3e20 100644
--- a/clang/docs/UsersManual.rst
+++ b/clang/docs/UsersManual.rst
@@ -1260,50 +1260,8 @@ installed.
 Controlling Floating Point Behavior
 ---
 
-Clang provides a number of ways to control floating point behavior, including
-with command line options and source pragmas. This section
-describes the various floating point semantic modes and the corresponding 
options.
-
-.. csv-table:: Floating Point Semantic Modes
-  :header: "Mode", "Values"
-  :widths: 15, 30, 30
-
-  "except_behavior", "{ignore, strict, may_trap}", "ffp-exception-behavior"
-  "fenv_access", "{off, on}", "(none)"
-  "rounding_mode", "{dynamic, tonearest, downward, upward, towardzero}", 
"frounding-math"
-  "contract", "{on, off, fast}", "ffp-contract"
-  "denormal_fp_math", "{IEEE, PreserveSign, PositiveZero}", "fdenormal-fp-math"
-  "denormal_fp32_math", "{IEEE, PreserveSign, PositiveZero}", 
"fdenormal-fp-math-fp32"
-  "support_math_errno", "{on, off}", "fmath-errno"
-  "no_honor_nans", "{on, off}", "fhonor-nans"
-  "no_honor_infinities", "{on, off}", "fhonor-infinities"
-  "no_signed_zeros", "{on, off}", "fsigned-zeros"
-  "allow_reciprocal", "{on, off}", "freciprocal-math"
-  "allow_approximate_fns", "{on, off}", "(none)"
-  "allow_reassociation", "{on, off}", "fassociative-math"
-
-
-This table describes the option settings that correspond to the three
-floating point semantic models: precise (the default), strict, and fast.
-
-
-.. csv-table:: Floating Point Models
-  :header: "Mode", "Precise", "Strict", "Fast"
-  :widths: 25, 15, 15, 15
-
-  "except_behavior", "ignore", "strict", "ignore"
-  "fenv_access", "off", "on", "off"
-  "rounding_mode", "tonearest", "dynamic", "tonearest"
-  "contract", "on", "off", "fast"
-  "denormal_fp_math", "IEEE", "IEEE", "PreserveSign"
-  "denormal_fp32_math", "IEEE","IEEE", "PreserveSign"
-  "support_math_errno", "on", "on", "off"
-  "no_honor_nans", "off", "off", "on"
-  "no_honor_infinities", "off", "off", "on"
-  "no_signed_zeros", "off", "off", "on"
-  "allow_reciprocal", "off", "off", "on"
-  "allow_approximate_fns", "off", "off", "on"
-  "allow_reassociation", "off", "off", "on"
+Clang provides a number of ways to control floating point behavior. The options
+are listed below.
 
 .. option:: -ffast-math
 
@@ -1498,7 +1456,7 @@ Note that floating-point operations performed as part of 
constant initialization
and ``fast``.
Details:
 
-   * ``precise`` Disables optimizations that are not value-safe on 
floating-point data, although FP contraction (FMA) is enabled 
(``-ffp-contract=on``).  This is the default behavior.
+   * ``precise`` Disables optimizations that are not value-safe on 
floating-point data, although FP contraction (FMA) is enabled 
(``-ffp-contract=fast``).  This is the default behavior.
* ``strict`` Enables ``-frounding-math`` and 
``-ffp-exception-behavior=strict``, and disables contractions (FMA).  All of 
the ``-ffast-math`` enablements are disabled. Enables ``STDC FENV_ACCESS``: by 
default ``FENV_ACCESS`` is disabled. This option setting behaves as though 
``#pragma STDC FENV_ACESS ON`` appeared at the top of the source file.
* ``fast`` Behaves identically to specifying both ``-ffast-math`` and 
``ffp-contract=fast``
 

diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 928fff7001b67..837ead86d6202 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -2637,7 +2637,7 @@ static void RenderFloatingPointOptions(const ToolChain 
&TC, const Driver &D,
 
   llvm::DenormalMode DenormalFPMath = DefaultDenormalFPMath;
   llvm::DenormalMode DenormalFP32Math = DefaultDenormalFP32Math;
-  StringRef FPContract = "on";
+  StringRef FPContract = "";
   bool StrictFPModel = false;
 
 
@@ -2662,7 +2662,7 @@ static void RenderFloatingPointOptions(const ToolChain 
&TC, const Driver &D,
   ReciprocalMath =

[PATCH] D74436: Change clang option -ffp-model=precise to select ffp-contract=on

2021-07-22 Thread Melanie Blower via Phabricator via cfe-commits
mibintc reopened this revision.
mibintc added a comment.
This revision is now accepted and ready to land.

I had to revert again, it's still failing on Intel buildbots. Cannot reproduce 
on Intel-internal Broadwell server.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74436

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


[PATCH] D103385: [clang-tidy] bugprone-forwarding-reference-overload: support non-type template parameters

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

Thank you for the ping, this fell off my radar. LGTM aside from some small nits.




Comment at: 
clang-tools-extra/docs/clang-tidy/checks/bugprone-forwarding-reference-overload.rst:34
+  template,A&&...>,int> = 0>
+  explicit Person(A&&... a) {}





Comment at: 
clang-tools-extra/docs/clang-tidy/checks/bugprone-forwarding-reference-overload.rst:56
+constructor is guarded.
\ No newline at end of file


Can you add the newline back?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103385

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


[PATCH] D105690: [RISCV] Rename assembler mnemonic of unordered floating-point reductions for v1.0-rc change

2021-07-22 Thread Kito Cheng via Phabricator via cfe-commits
kito-cheng added inline comments.



Comment at: llvm/test/MC/RISCV/rvv/aliases.s:86
+# NO-ALIAS: vfwredusum.vs v8, v4, v20, v0.t  # encoding: [0x57,0x14,0x4a,0xc4]
+vfwredusum.vs v8, v4, v20, v0.t

I guess you want to verify `vfredsum.vs`  and `vfwredsum.vs` here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105690

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


[PATCH] D106431: [clang-tidy] Fix cppcoreguidelines-init-variables with enum judgement

2021-07-22 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D106431#2896206 , @whisperity 
wrote:

> The problem with enums is that translating //zero// (0, 0.0, nullptr, etc...) 
> to the enum case is not always apparent. A warning **should** always be 
> given. And //if// you can find a zero member in the enum, we can report an 
> automated suggestion for that.

I think we shouldn't give any fix-it for enumerations. Zero doesn't always mean 
"the right default value" -- for example, another common idiom is for the 
*last* member of the enumeration to be a sentinel value.




Comment at: 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-init-variables.cpp:103
+  // Expect no warning given here.
+  Color color;
+  // Expect no warning given here.

MTC wrote:
> steven.zhang wrote:
> > Technical speaking, we should warn about such case, ad the color is 
> > undefined now. Can we initialize it to the lowerest value of the enum type ?
> Good point! However, which value should be chosen as automatic fix is a 
> problem worth discussing.
FWIW, I'd expect a warning but no fix-it for these.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106431

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


[PATCH] D106509: [OpenMP][OpenACC] Implement `hold` map type modifier extension in Clang (1/2)

2021-07-22 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

That's strange that we need to ignore `delete` modifier, I would say that most 
probably there is a bug in the user's code.

> Questions:



> Clang currently doesn't support OpenMP 5.1 features unless 
> -fopenmp-version=51. Does it make sense to have an option to enable 
> extensions? Instead of a separate option, we could accept something like 
> -fopenmp-version=51,hold,foo.

I would just add a new options `-fopenmp-extension` or something like this just 
toenable all non-standard extensions, better to keep `-fopenmp-version` as is.

> In Clang diagnostics, this patch does not add hold to the list of acceptable 
> map type modifiers because it's an extension. Should it? If there were a 
> command-line option to enable extensions, that would make the path clearer.

Yes, with the extensions enabled it should generate the list of all supported 
modifiers.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106509

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


[PATCH] D106442: [clang-tidy] Improve "common type" diagnostic output in 'bugprone-easily-swappable-parameters'

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

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106442

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


[PATCH] D106528: [clangd] Improve performance of dex by 45-60%

2021-07-22 Thread Sam McCall via Phabricator via cfe-commits
sammccall accepted this revision.
sammccall added a comment.
This revision is now accepted and ready to land.

Nice find!




Comment at: clang-tools-extra/clangd/index/dex/Iterator.cpp:91
   /// sync.
   void sync() {
 ReachedEnd |= Children.front()->reachedEnd();

I stared at this for a while and this change makes me think about the whole 
algo differently.

Effectively, we're just iterating through the items C of front trying to find a 
valid sync point.
With the slight optimization that when some other child skips over C to X, we 
catch up the front to X.

This leads to two possible simplifications (strictly, unrelated to this patch 
and totally up to you):
 
1. The initial setup and outer loop has unclear bounds - it's basically a loop 
over the items of Children.front() but that's not clear.

Consider rather:

```
auto &Front = *Children.front(); // smallest
while ((ReachedEnd |= Front->reachedEnd())) {
  auto SyncID = Front.peek();
  bool ValidSync = true;
  for (auto &Child : Children {
...
if (Child->peek() > SyncID) {
  Front->advanceTo(Child->peek()); // XXX
  ValidSync = false;
  break;
}
...
  }
  if (ValidSync)
return;
}
```

This seems basically equivalent and I find the flow control easier to reason 
about.

2. Is the "slight optimization" important? i.e. is 
`Front->advanceTo(Child->peek())` actually a significant win over 
`Front->advance()`? I think the flow control is even clearer in this version:

```
for (auto &Front = *Children.front() ;(ReachedEnd |= Front->reachedEnd()); 
Front.advance()) {
  auto SyncID = Front.peek();
  bool ValidSync = true;
  for (auto &Child : Children {
...
if (Child->peek() > SyncID) {
  ValidSync = false;
  break;
}
...
  }
  if (ValidSync)
return;
}
```
Because now the outer loop is *entirely* just a loop over the items of Front.

Intuitively the average number that advanceTo() advances by here is between 1 
and 2 (we know it's at least 1, but the remaining items are mostly from the 
longer iterator so we probably don't skip over any from the shorter iterator).
And advanceTo is more complicated, if advanceTo turns out to be 2x as expensive 
as advance in practice, this isn't a win. So this is maybe worth checking.



Comment at: clang-tools-extra/clangd/index/dex/Iterator.cpp:112
   NeedsAdvance = true;
+  // Reset and make sure advanceTo happens much less frequently on
+  // large posting lists. This accounts for 45-60% performance boost.

First, say why:
 
Now we try again with a new sync point.
We always syncing with the first child as this is the cheapest (smallest). We 
only call advanceTo on the large posting lists once we have a fairly likely 
sync point.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106528

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


[PATCH] D106431: [clang-tidy] Fix cppcoreguidelines-init-variables with enum judgement

2021-07-22 Thread Whisperity via Phabricator via cfe-commits
whisperity added a comment.

In D106431#2896334 , @aaron.ballman 
wrote:

> In D106431#2896206 , @whisperity 
> wrote:
>
>> The problem with enums is that translating //zero// (0, 0.0, nullptr, 
>> etc...) to the enum case is not always apparent. A warning **should** always 
>> be given. And //if// you can find a zero member in the enum, we can report 
>> an automated suggestion for that.
>
> I think we shouldn't give any fix-it for enumerations. Zero doesn't always 
> mean "the right default value" -- for example, another common idiom is for 
> the *last* member of the enumeration to be a sentinel value.

I agree with you, but we need to consider that the checker works in a way that 
it gives the "zero" for integers. If we are here, was that the right decision? 
I mean... I wonder how much //consistency// we should shoot for. (`nullptr` for 
the pointers as default is at least somewhat sensible.)

But definitely, the //warning// must be given, that is true.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106431

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


[PATCH] D106484: [PowerPC] Add PowerPC "__stbcx" builtin and intrinsic for XL compatibility

2021-07-22 Thread Victor Huang via Phabricator via cfe-commits
NeHuang updated this revision to Diff 360803.
NeHuang added a comment.

- Addressed review comments from Lei
- Rebased the patch


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106484

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/Basic/Targets/PPC.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/builtins-ppc-xlcompat-pwr8.c
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCInstrInfo.td
  llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-LoadReserve-StoreCond.ll

Index: llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-LoadReserve-StoreCond.ll
===
--- llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-LoadReserve-StoreCond.ll
+++ llvm/test/CodeGen/PowerPC/builtins-ppc-xlcompat-LoadReserve-StoreCond.ll
@@ -29,6 +29,28 @@
   ret i32 %0
 }
 
+declare i32 @llvm.ppc.stbcx(i8*, i32)
+define signext i32 @test_stbcx(i8* %addr, i8 signext %val) {
+; CHECK-64-LABEL: test_stbcx:
+; CHECK-64:   # %bb.0: # %entry
+; CHECK-64-NEXT:stbcx. 4, 0, 3
+; CHECK-64-NEXT:mfocrf 3, 128
+; CHECK-64-NEXT:srwi 3, 3, 28
+; CHECK-64-NEXT:extsw 3, 3
+; CHECK-64-NEXT:blr
+;
+; CHECK-32-LABEL: test_stbcx:
+; CHECK-32:   # %bb.0: # %entry
+; CHECK-32-NEXT:stbcx. 4, 0, 3
+; CHECK-32-NEXT:mfocrf 3, 128
+; CHECK-32-NEXT:srwi 3, 3, 28
+; CHECK-32-NEXT:blr
+entry:
+  %conv = sext i8 %val to i32
+  %0 = tail call i32 @llvm.ppc.stbcx(i8* %addr, i32 %conv)
+  ret i32 %0
+}
+
 declare i32 @llvm.ppc.stwcx(i8*, i32)
 define dso_local signext i32 @test_stwcx(i32* %a, i32 signext %b) {
 ; CHECK-64-LABEL: test_stwcx:
Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td
===
--- llvm/lib/Target/PowerPC/PPCInstrInfo.td
+++ llvm/lib/Target/PowerPC/PPCInstrInfo.td
@@ -5463,6 +5463,8 @@
 
 def : Pat<(int_ppc_stwcx ForceXForm:$dst, gprc:$A),
   (STWCX gprc:$A, ForceXForm:$dst)>;
+def : Pat<(int_ppc_stbcx ForceXForm:$dst, gprc:$A),
+  (STBCX gprc:$A, ForceXForm:$dst)>;
 def : Pat<(int_ppc_tw gprc:$A, gprc:$B, i32:$IMM),
   (TW $IMM, $A, $B)>;
 def : Pat<(int_ppc_trap gprc:$A),
Index: llvm/include/llvm/IR/IntrinsicsPowerPC.td
===
--- llvm/include/llvm/IR/IntrinsicsPowerPC.td
+++ llvm/include/llvm/IR/IntrinsicsPowerPC.td
@@ -1558,6 +1558,9 @@
   Intrinsic<[],[],[]>;
   def int_ppc_iospace_eieio : GCCBuiltin<"__builtin_ppc_iospace_eieio">,
   Intrinsic<[],[],[]>;
+  def int_ppc_stbcx : GCCBuiltin<"__builtin_ppc_stbcx">,
+  Intrinsic<[llvm_i32_ty], [llvm_ptr_ty, llvm_i32_ty],
+[IntrWriteMem]>;
   def int_ppc_stdcx : GCCBuiltin<"__builtin_ppc_stdcx">,
   Intrinsic<[llvm_i32_ty], [llvm_ptr_ty, llvm_i64_ty],
 [IntrWriteMem]>;
Index: clang/test/CodeGen/builtins-ppc-xlcompat-pwr8.c
===
--- clang/test/CodeGen/builtins-ppc-xlcompat-pwr8.c
+++ clang/test/CodeGen/builtins-ppc-xlcompat-pwr8.c
@@ -15,6 +15,8 @@
 // RUN:   -target-cpu pwr7 -o - 2>&1 | FileCheck %s -check-prefix=CHECK-NOPWR8
 
 extern void *a;
+extern volatile char *c_addr;
+extern char c;
 
 void test_icbt() {
 // CHECK-LABEL: @test_icbt(
@@ -31,3 +33,14 @@
 // CHECK-PWR8: call void @llvm.ppc.icbt(i8* %0)
 // CHECK-NOPWR8: error: this builtin is only valid on POWER8 or later CPUs
 }
+
+int test_builtin_ppc_stbcx() {
+// CHECK-PWR8-LABEL: @test_builtin_ppc_stbcx(
+// CHECK-PWR8: [[TMP0:%.*]] = load i8*, i8** @c_addr, align {{[0-9]+}}
+// CHECK-PWR8-NEXT:[[TMP1:%.*]] = load i8, i8* @c, align 1
+// CHECK-PWR8-NEXT:[[TMP2:%.*]] = sext i8 [[TMP1]] to i32
+// CHECK-PWR8-NEXT:[[TMP3:%.*]] = call i32 @llvm.ppc.stbcx(i8* [[TMP0]], i32 [[TMP2]])
+// CHECK-PWR8-NEXT:ret i32 [[TMP3]]
+// CHECK-NOPWR8: error: this builtin is only valid on POWER8 or later CPUs
+  return __builtin_ppc_stbcx(c_addr, c);
+}
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -3434,6 +3434,7 @@
   case PPC::BI__builtin_ppc_rdlam:
 return SemaValueIsRunOfOnes(TheCall, 2);
   case PPC::BI__builtin_ppc_icbt:
+  case PPC::BI__builtin_ppc_stbcx:
 return SemaFeatureCheck(*this, TheCall, "isa-v207-instructions",
 diag::err_ppc_builtin_only_on_arch, "8");
   case PPC::BI__builtin_ppc_sthcx:
Index: clang/lib/Basic/Targets/PPC.cpp
===
--- clang/lib/Basic/Targets/PPC.cpp
+++ clang/lib/Basic/Targets/PPC.cpp
@@ -121,6 +121,7 @@
   Builder.defineMacro("__lharx", "__builtin_ppc_lharx");
   Builder.defineMacro("__lbarx", "

[PATCH] D106484: [PowerPC] Add PowerPC "__stbcx" builtin and intrinsic for XL compatibility

2021-07-22 Thread Victor Huang via Phabricator via cfe-commits
NeHuang marked an inline comment as done.
NeHuang added inline comments.



Comment at: clang/test/CodeGen/builtins-ppc-xlcompat-pwr8.c:31
+  return __builtin_ppc_stbcx(c_addr, c);
+}

lei wrote:
> Why not just add this tc to 
> `clang/test/CodeGen/builtins-ppc-xlcompat-LoadReseve-StoreCond.c`?
> The other related store functions are tested there.
`__stbcx` is only valid with `pwr8` (or later cpu)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106484

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


[PATCH] D106509: [OpenMP][OpenACC] Implement `hold` map type modifier extension in Clang (1/2)

2021-07-22 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added a comment.

I would propose we prefix these new clauses and such with `ompx_`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106509

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


[PATCH] D106509: [OpenMP][OpenACC] Implement `hold` map type modifier extension in Clang (1/2)

2021-07-22 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

In D106509#2896398 , @jdoerfert wrote:

> I would propose we prefix these new clauses and such with `ompx_`.

+1 here


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106509

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


[PATCH] D106542: [OPENMP]Fix PR49787: Codegen for calling __tgt_target_teams_nowait_mapper has too few arguments.

2021-07-22 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert accepted this revision.
jdoerfert added a comment.
This revision is now accepted and ready to land.

LG, thx


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106542

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


[PATCH] D106484: [PowerPC] Add PowerPC "__stbcx" builtin and intrinsic for XL compatibility

2021-07-22 Thread Nemanja Ivanovic via Phabricator via cfe-commits
nemanjai accepted this revision.
nemanjai added a comment.
This revision is now accepted and ready to land.

LGTM aside from a small nit.




Comment at: clang/lib/Basic/Targets/PPC.cpp:124
   Builder.defineMacro("__stfiw", "__builtin_ppc_stfiw");
+  Builder.defineMacro("__stbcx", "__builtin_ppc_stbcx");
   Builder.defineMacro("__stdcx", "__builtin_ppc_stdcx");

Nit: move just under `sthcx` so the order makes sense: doubleword, word, 
haflword, byte.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106484

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


[PATCH] D106484: [PowerPC] Add PowerPC "__stbcx" builtin and intrinsic for XL compatibility

2021-07-22 Thread Albion Fung via Phabricator via cfe-commits
Conanap added inline comments.



Comment at: clang/lib/Sema/SemaChecking.cpp:3437
   case PPC::BI__builtin_ppc_icbt:
+  case PPC::BI__builtin_ppc_stbcx:
 return SemaFeatureCheck(*this, TheCall, "isa-v207-instructions",

would prefer if this joined the list of `sthcx`, `lharx` and `lbarx` right 
below this case


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106484

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


[PATCH] D105690: [RISCV] Rename assembler mnemonic of unordered floating-point reductions for v1.0-rc change

2021-07-22 Thread Hsiangkai Wang via Phabricator via cfe-commits
HsiangKai added inline comments.



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoV.td:10
 /// This file describes the RISC-V instructions from the standard 'V' Vector
 /// extension, version 0.10.
 /// This version is still experimental as the 'V' extension hasn't been

frasercrmck wrote:
> khchen wrote:
> > jacquesguan wrote:
> > > khchen wrote:
> > > > Do we need to update 0.10 to 1.0-rc?
> > > > If the answer is yes, I think maybe we also need to update the clang 
> > > > part (ex. arch parsing, predefine macro) in follow-up patches.
> > > > 
> > > > 
> > > Maybe update it after finishing all changes in 1.0-rc?
> > > Maybe update it after finishing all changes in 1.0-rc?
> > Yes.
> > 
> > The other questions like how do you encode `rc1` in `march` or predefined 
> > architecture extension macro.
> > or maybe we could just use 1.0 directly because v is still an experiential 
> > extension.
> > 
> > @luismarques  @frasercrmck @craig.topper @HsiangKai What do you think?
> Maybe we can discuss in the call today, but my initial thoughts would be to 
> just say 1.0 for the reasons you specified.
> 
> Perhaps there's already precedent in dealing with release-candidate specs for 
> the base ISA or other extensions?
I expect v1.0-rc1 will have no big change, especially for these renaming 
issues. I vote for 1.0 for the experimental extension.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105690

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


[clang] 9ce931b - [HIP] Fix no matching constructor for init of shared_ptr and malloc

2021-07-22 Thread Aaron En Ye Shi via cfe-commits

Author: Aaron En Ye Shi
Date: 2021-07-22T14:32:41Z
New Revision: 9ce931bd71855ced2146f77120df07e4bf381cec

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

LOG: [HIP] Fix no matching constructor for init of shared_ptr and malloc

Allow standard header versions of malloc and free to be defined
before introducing the device versions.

Fixes: SWDEV-295901

Reviewed By: yaxunl

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

Added: 


Modified: 
clang/lib/Headers/__clang_hip_runtime_wrapper.h

Removed: 




diff  --git a/clang/lib/Headers/__clang_hip_runtime_wrapper.h 
b/clang/lib/Headers/__clang_hip_runtime_wrapper.h
index 59d5cfef2df8..73021d256cba 100644
--- a/clang/lib/Headers/__clang_hip_runtime_wrapper.h
+++ b/clang/lib/Headers/__clang_hip_runtime_wrapper.h
@@ -46,6 +46,28 @@ extern "C" {
 }
 #endif //__cplusplus
 
+#if !defined(__HIPCC_RTC__)
+#include 
+#include 
+#include 
+#else
+typedef __SIZE_TYPE__ size_t;
+// Define macros which are needed to declare HIP device API's without standard
+// C/C++ headers. This is for readability so that these API's can be written
+// the same way as non-hipRTC use case. These macros need to be popped so that
+// they do not pollute users' name space.
+#pragma push_macro("NULL")
+#pragma push_macro("uint32_t")
+#pragma push_macro("uint64_t")
+#pragma push_macro("CHAR_BIT")
+#pragma push_macro("INT_MAX")
+#define NULL (void *)0
+#define uint32_t __UINT32_TYPE__
+#define uint64_t __UINT64_TYPE__
+#define CHAR_BIT __CHAR_BIT__
+#define INT_MAX __INTMAX_MAX__
+#endif // __HIPCC_RTC__
+
 typedef __SIZE_TYPE__ __hip_size_t;
 
 #ifdef __cplusplus
@@ -64,11 +86,11 @@ __attribute__((weak)) inline __device__ void *free(void 
*__ptr) {
 #else
 __attribute__((weak)) inline __device__ void *malloc(__hip_size_t __size) {
   __builtin_trap();
-  return nullptr;
+  return (void *)0;
 }
 __attribute__((weak)) inline __device__ void *free(void *__ptr) {
   __builtin_trap();
-  return nullptr;
+  return (void *)0;
 }
 #endif
 
@@ -76,28 +98,6 @@ __attribute__((weak)) inline __device__ void *free(void 
*__ptr) {
 } // extern "C"
 #endif //__cplusplus
 
-#if !defined(__HIPCC_RTC__)
-#include 
-#include 
-#include 
-#else
-typedef __SIZE_TYPE__ size_t;
-// Define macros which are needed to declare HIP device API's without standard
-// C/C++ headers. This is for readability so that these API's can be written
-// the same way as non-hipRTC use case. These macros need to be popped so that
-// they do not pollute users' name space.
-#pragma push_macro("NULL")
-#pragma push_macro("uint32_t")
-#pragma push_macro("uint64_t")
-#pragma push_macro("CHAR_BIT")
-#pragma push_macro("INT_MAX")
-#define NULL (void *)0
-#define uint32_t __UINT32_TYPE__
-#define uint64_t __UINT64_TYPE__
-#define CHAR_BIT __CHAR_BIT__
-#define INT_MAX __INTMAX_MAX__
-#endif // __HIPCC_RTC__
-
 #include <__clang_hip_libdevice_declares.h>
 #include <__clang_hip_math.h>
 



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


[PATCH] D106463: [HIP] Fix no matching constructor for init of shared_ptr and malloc

2021-07-22 Thread Aaron Enye Shi 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 rG9ce931bd7185: [HIP] Fix no matching constructor for init of 
shared_ptr and malloc (authored by ashi1).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106463

Files:
  clang/lib/Headers/__clang_hip_runtime_wrapper.h


Index: clang/lib/Headers/__clang_hip_runtime_wrapper.h
===
--- clang/lib/Headers/__clang_hip_runtime_wrapper.h
+++ clang/lib/Headers/__clang_hip_runtime_wrapper.h
@@ -46,6 +46,28 @@
 }
 #endif //__cplusplus
 
+#if !defined(__HIPCC_RTC__)
+#include 
+#include 
+#include 
+#else
+typedef __SIZE_TYPE__ size_t;
+// Define macros which are needed to declare HIP device API's without standard
+// C/C++ headers. This is for readability so that these API's can be written
+// the same way as non-hipRTC use case. These macros need to be popped so that
+// they do not pollute users' name space.
+#pragma push_macro("NULL")
+#pragma push_macro("uint32_t")
+#pragma push_macro("uint64_t")
+#pragma push_macro("CHAR_BIT")
+#pragma push_macro("INT_MAX")
+#define NULL (void *)0
+#define uint32_t __UINT32_TYPE__
+#define uint64_t __UINT64_TYPE__
+#define CHAR_BIT __CHAR_BIT__
+#define INT_MAX __INTMAX_MAX__
+#endif // __HIPCC_RTC__
+
 typedef __SIZE_TYPE__ __hip_size_t;
 
 #ifdef __cplusplus
@@ -64,11 +86,11 @@
 #else
 __attribute__((weak)) inline __device__ void *malloc(__hip_size_t __size) {
   __builtin_trap();
-  return nullptr;
+  return (void *)0;
 }
 __attribute__((weak)) inline __device__ void *free(void *__ptr) {
   __builtin_trap();
-  return nullptr;
+  return (void *)0;
 }
 #endif
 
@@ -76,28 +98,6 @@
 } // extern "C"
 #endif //__cplusplus
 
-#if !defined(__HIPCC_RTC__)
-#include 
-#include 
-#include 
-#else
-typedef __SIZE_TYPE__ size_t;
-// Define macros which are needed to declare HIP device API's without standard
-// C/C++ headers. This is for readability so that these API's can be written
-// the same way as non-hipRTC use case. These macros need to be popped so that
-// they do not pollute users' name space.
-#pragma push_macro("NULL")
-#pragma push_macro("uint32_t")
-#pragma push_macro("uint64_t")
-#pragma push_macro("CHAR_BIT")
-#pragma push_macro("INT_MAX")
-#define NULL (void *)0
-#define uint32_t __UINT32_TYPE__
-#define uint64_t __UINT64_TYPE__
-#define CHAR_BIT __CHAR_BIT__
-#define INT_MAX __INTMAX_MAX__
-#endif // __HIPCC_RTC__
-
 #include <__clang_hip_libdevice_declares.h>
 #include <__clang_hip_math.h>
 


Index: clang/lib/Headers/__clang_hip_runtime_wrapper.h
===
--- clang/lib/Headers/__clang_hip_runtime_wrapper.h
+++ clang/lib/Headers/__clang_hip_runtime_wrapper.h
@@ -46,6 +46,28 @@
 }
 #endif //__cplusplus
 
+#if !defined(__HIPCC_RTC__)
+#include 
+#include 
+#include 
+#else
+typedef __SIZE_TYPE__ size_t;
+// Define macros which are needed to declare HIP device API's without standard
+// C/C++ headers. This is for readability so that these API's can be written
+// the same way as non-hipRTC use case. These macros need to be popped so that
+// they do not pollute users' name space.
+#pragma push_macro("NULL")
+#pragma push_macro("uint32_t")
+#pragma push_macro("uint64_t")
+#pragma push_macro("CHAR_BIT")
+#pragma push_macro("INT_MAX")
+#define NULL (void *)0
+#define uint32_t __UINT32_TYPE__
+#define uint64_t __UINT64_TYPE__
+#define CHAR_BIT __CHAR_BIT__
+#define INT_MAX __INTMAX_MAX__
+#endif // __HIPCC_RTC__
+
 typedef __SIZE_TYPE__ __hip_size_t;
 
 #ifdef __cplusplus
@@ -64,11 +86,11 @@
 #else
 __attribute__((weak)) inline __device__ void *malloc(__hip_size_t __size) {
   __builtin_trap();
-  return nullptr;
+  return (void *)0;
 }
 __attribute__((weak)) inline __device__ void *free(void *__ptr) {
   __builtin_trap();
-  return nullptr;
+  return (void *)0;
 }
 #endif
 
@@ -76,28 +98,6 @@
 } // extern "C"
 #endif //__cplusplus
 
-#if !defined(__HIPCC_RTC__)
-#include 
-#include 
-#include 
-#else
-typedef __SIZE_TYPE__ size_t;
-// Define macros which are needed to declare HIP device API's without standard
-// C/C++ headers. This is for readability so that these API's can be written
-// the same way as non-hipRTC use case. These macros need to be popped so that
-// they do not pollute users' name space.
-#pragma push_macro("NULL")
-#pragma push_macro("uint32_t")
-#pragma push_macro("uint64_t")
-#pragma push_macro("CHAR_BIT")
-#pragma push_macro("INT_MAX")
-#define NULL (void *)0
-#define uint32_t __UINT32_TYPE__
-#define uint64_t __UINT64_TYPE__
-#define CHAR_BIT __CHAR_BIT__
-#define INT_MAX __INTMAX_MAX__
-#endif // __HIPCC_RTC__
-
 #include <__clang_hip_libdevice_declares.h>
 #include <__clang_hip_math.h>
 
___

[PATCH] D106431: [clang-tidy] Fix cppcoreguidelines-init-variables with enum judgement

2021-07-22 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D106431#2896367 , @whisperity 
wrote:

> In D106431#2896334 , @aaron.ballman 
> wrote:
>
>> In D106431#2896206 , @whisperity 
>> wrote:
>>
>>> The problem with enums is that translating //zero// (0, 0.0, nullptr, 
>>> etc...) to the enum case is not always apparent. A warning **should** 
>>> always be given. And //if// you can find a zero member in the enum, we can 
>>> report an automated suggestion for that.
>>
>> I think we shouldn't give any fix-it for enumerations. Zero doesn't always 
>> mean "the right default value" -- for example, another common idiom is for 
>> the *last* member of the enumeration to be a sentinel value.
>
> I agree with you, but we need to consider that the checker works in a way 
> that it gives the "zero" for integers. If we are here, was that the right 
> decision?

If we're here, I think the right decision would have been to not support the 
C++ Core Guidelines in clang-tidy in the first place because of the lack of 
attention that's been paid to enforcement for the rules by the authors. ;-) But 
snark aside, I think `= 0` is a somewhat defensible naïve default value for 
integers, but today I would prefer it give its fix-it on a note rather than on 
the warning. When there's only one fix-it to be applied to a warning, it's 
possible to apply the fix-it without any per-case user intervention and that 
default value isn't statically known to be safe. With `nullptr` for pointers, 
it's more defensible because that's a well-understood sentinel value that code 
*should* be checking for (and there's good tooling to catch null pointer 
dereferences for the other situations). With `NAN` for floats, it's more 
defensible because that (usually!) is a "sticky" value that poisons further 
uses of the type. There's nothing quite like that for integers.

> I mean... I wonder how much //consistency// we should shoot for. (`nullptr` 
> for the pointers as default is at least somewhat sensible.)

There are at least two ways to chase consistency here -- one is being 
consistent with other fix-its in the check, the other is being consistent with 
other fix-its across the project. My feeling is we should aim for consistency 
with the rest of the toolchain, which is to only issue a fix-it on a warning 
when the fix is known to be correct. 
https://clang.llvm.org/docs/InternalsManual.html#fix-it-hints

Perhaps one way forward would be to issue the integer fix-it on a note rather 
than a warning, and for enumerations, we could issue up to two fix-its on a 
note, one for the first and one for the last enumerator in an enumeration (and 
if the enum only contains one enumerator, there's only one fix-it to generate 
which suggests it could be on the warning rather than a note, but that seems 
like a lot of trouble for an unlikely scenario). However, I don't recall how 
clang-tidy interacts with fix-its on notes off the top of my head, so I'm 
making an assumption that clang-tidy's automatic fixit applying mode handles 
notes the same way as clang and we should double-check that assumption.

Another way forward would be to not issue a fix-it for integers or enumerations.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106431

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


[PATCH] D106550: [PowerPC] Allow MMA builtins to accpet restrict qualified pointers

2021-07-22 Thread Ahsan Saghir via Phabricator via cfe-commits
saghir created this revision.
Herald added subscribers: steven.zhang, shchenz, kbarton, nemanjai.
saghir requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This patch allows MMA builtins on PowerPC to accept restrict
qualified pointers.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D106550

Files:
  clang/lib/Sema/SemaChecking.cpp
  clang/test/Sema/ppc-pair-mma-types.c


Index: clang/test/Sema/ppc-pair-mma-types.c
===
--- clang/test/Sema/ppc-pair-mma-types.c
+++ clang/test/Sema/ppc-pair-mma-types.c
@@ -333,3 +333,8 @@
   __vector_pair vp = __builtin_vsx_lxvp(ll, v); // expected-error {{passing 
'__vector int' (vector of 4 'int' values) to parameter of incompatible type 
'const __vector_pair *'}}
   __builtin_vsx_stxvp(vp, ll, s);   // expected-error {{passing 
'unsigned short' to parameter of incompatible type 'const __vector_pair *'}}
 }
+
+void testRestrictQualifiedPointer(__vector_quad *__restrict acc) {
+  vector float arr[4];
+  __builtin_mma_disassemble_acc((void*)arr, acc);
+}
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -7303,7 +7303,8 @@
 
 if ((ExpectedType->isVoidPointerType() && !ArgType->isPointerType()) ||
 (!ExpectedType->isVoidPointerType() &&
-   ArgType.getCanonicalType() != ExpectedType))
+ (!ArgType.isRestrictQualified() &&
+  ArgType.getCanonicalType() != ExpectedType)))
   return Diag(Arg->getBeginLoc(), diag::err_typecheck_convert_incompatible)
  << ArgType << ExpectedType << 1 << 0 << 0;
 


Index: clang/test/Sema/ppc-pair-mma-types.c
===
--- clang/test/Sema/ppc-pair-mma-types.c
+++ clang/test/Sema/ppc-pair-mma-types.c
@@ -333,3 +333,8 @@
   __vector_pair vp = __builtin_vsx_lxvp(ll, v); // expected-error {{passing '__vector int' (vector of 4 'int' values) to parameter of incompatible type 'const __vector_pair *'}}
   __builtin_vsx_stxvp(vp, ll, s);   // expected-error {{passing 'unsigned short' to parameter of incompatible type 'const __vector_pair *'}}
 }
+
+void testRestrictQualifiedPointer(__vector_quad *__restrict acc) {
+  vector float arr[4];
+  __builtin_mma_disassemble_acc((void*)arr, acc);
+}
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -7303,7 +7303,8 @@
 
 if ((ExpectedType->isVoidPointerType() && !ArgType->isPointerType()) ||
 (!ExpectedType->isVoidPointerType() &&
-   ArgType.getCanonicalType() != ExpectedType))
+ (!ArgType.isRestrictQualified() &&
+  ArgType.getCanonicalType() != ExpectedType)))
   return Diag(Arg->getBeginLoc(), diag::err_typecheck_convert_incompatible)
  << ArgType << ExpectedType << 1 << 0 << 0;
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D106344: [PowerPC] Implement XL compatible behavior of __compare_and_swap

2021-07-22 Thread Jinsong Ji via Phabricator via cfe-commits
jsji accepted this revision as: jsji.
jsji added a comment.
This revision is now accepted and ready to land.

> that looks like a historical issue which exists for 13yrs

Hmm... OK.. Let us leave it as it is for now.

Thanks for the new tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106344

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


[clang] b455f7f - [OPENMP]Fix PR49787: Codegen for calling __tgt_target_teams_nowait_mapper has too few arguments.

2021-07-22 Thread Alexey Bataev via cfe-commits

Author: Alexey Bataev
Date: 2021-07-22T07:53:37-07:00
New Revision: b455f7f22564a096c043b02fa159ab16669c121c

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

LOG: [OPENMP]Fix PR49787: Codegen for calling __tgt_target_teams_nowait_mapper 
has too few arguments.

Added missed arguments in
__tgt_target_teams_nowait_mapper/__tgt_target_nowait_mapper runtime
functions calls.

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

Added: 


Modified: 
clang/lib/CodeGen/CGOpenMPRuntime.cpp
clang/test/OpenMP/declare_mapper_codegen.cpp
clang/test/OpenMP/target_codegen.cpp
clang/test/OpenMP/target_depend_codegen.cpp
clang/test/OpenMP/target_parallel_codegen.cpp
clang/test/OpenMP/target_parallel_depend_codegen.cpp
clang/test/OpenMP/target_parallel_for_codegen.cpp
clang/test/OpenMP/target_parallel_for_depend_codegen.cpp
clang/test/OpenMP/target_parallel_for_simd_codegen.cpp
clang/test/OpenMP/target_parallel_for_simd_depend_codegen.cpp
clang/test/OpenMP/target_simd_codegen.cpp
clang/test/OpenMP/target_simd_depend_codegen.cpp
clang/test/OpenMP/target_teams_codegen.cpp
clang/test/OpenMP/target_teams_depend_codegen.cpp
clang/test/OpenMP/target_teams_distribute_codegen.cpp
clang/test/OpenMP/target_teams_distribute_depend_codegen.cpp
clang/test/OpenMP/target_teams_distribute_parallel_for_depend_codegen.cpp

clang/test/OpenMP/target_teams_distribute_parallel_for_simd_depend_codegen.cpp
clang/test/OpenMP/target_teams_distribute_simd_codegen.cpp
clang/test/OpenMP/target_teams_distribute_simd_depend_codegen.cpp
llvm/include/llvm/Frontend/OpenMP/OMPKinds.def

Removed: 




diff  --git a/clang/lib/CodeGen/CGOpenMPRuntime.cpp 
b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
index 7310b5c3f8d0..e7aa84ef3d90 100644
--- a/clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -10160,18 +10160,27 @@ void CGOpenMPRuntime::emitTargetCall(
   // passed to the runtime library - a 32-bit integer with the value zero.
   assert(NumThreads && "Thread limit expression should be available along "
"with number of teams.");
-  llvm::Value *OffloadingArgs[] = {RTLoc,
-   DeviceID,
-   OutlinedFnID,
-   PointerNum,
-   
InputInfo.BasePointersArray.getPointer(),
-   InputInfo.PointersArray.getPointer(),
-   InputInfo.SizesArray.getPointer(),
-   MapTypesArray,
-   MapNamesArray,
-   InputInfo.MappersArray.getPointer(),
-   NumTeams,
-   NumThreads};
+  SmallVector OffloadingArgs = {
+  RTLoc,
+  DeviceID,
+  OutlinedFnID,
+  PointerNum,
+  InputInfo.BasePointersArray.getPointer(),
+  InputInfo.PointersArray.getPointer(),
+  InputInfo.SizesArray.getPointer(),
+  MapTypesArray,
+  MapNamesArray,
+  InputInfo.MappersArray.getPointer(),
+  NumTeams,
+  NumThreads};
+  if (HasNowait) {
+// Add int32_t depNum = 0, void *depList = nullptr, int32_t
+// noAliasDepNum = 0, void *noAliasDepList = nullptr.
+OffloadingArgs.push_back(CGF.Builder.getInt32(0));
+
OffloadingArgs.push_back(llvm::ConstantPointerNull::get(CGM.VoidPtrTy));
+OffloadingArgs.push_back(CGF.Builder.getInt32(0));
+
OffloadingArgs.push_back(llvm::ConstantPointerNull::get(CGM.VoidPtrTy));
+  }
   Return = CGF.EmitRuntimeCall(
   OMPBuilder.getOrCreateRuntimeFunction(
   CGM.getModule(), HasNowait
@@ -10179,16 +10188,25 @@ void CGOpenMPRuntime::emitTargetCall(
: OMPRTL___tgt_target_teams_mapper),
   OffloadingArgs);
 } else {
-  llvm::Value *OffloadingArgs[] = {RTLoc,
-   DeviceID,
-   OutlinedFnID,
-   PointerNum,
-   
InputInfo.BasePointersArray.getPointer(),
-   InputInfo.PointersArray.getPointer(),
-   InputInfo.SizesArray.getPointer(),
-   MapTypesArray,
-   MapNamesArray,
-   InputInfo.MappersArray.getPointer()};
+  SmallVector OffloadingArgs = {
+  RTLoc,
+  Device

[PATCH] D106542: [OPENMP]Fix PR49787: Codegen for calling __tgt_target_teams_nowait_mapper has too few arguments.

2021-07-22 Thread Alexey Bataev 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 rGb455f7f22564: [OPENMP]Fix PR49787: Codegen for calling 
__tgt_target_teams_nowait_mapper has… (authored by ABataev).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106542

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  clang/test/OpenMP/declare_mapper_codegen.cpp
  clang/test/OpenMP/target_codegen.cpp
  clang/test/OpenMP/target_depend_codegen.cpp
  clang/test/OpenMP/target_parallel_codegen.cpp
  clang/test/OpenMP/target_parallel_depend_codegen.cpp
  clang/test/OpenMP/target_parallel_for_codegen.cpp
  clang/test/OpenMP/target_parallel_for_depend_codegen.cpp
  clang/test/OpenMP/target_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/target_parallel_for_simd_depend_codegen.cpp
  clang/test/OpenMP/target_simd_codegen.cpp
  clang/test/OpenMP/target_simd_depend_codegen.cpp
  clang/test/OpenMP/target_teams_codegen.cpp
  clang/test/OpenMP/target_teams_depend_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_depend_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_depend_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_simd_depend_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_simd_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_simd_depend_codegen.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPKinds.def

Index: llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
===
--- llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
+++ llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
@@ -381,12 +381,14 @@
 __OMP_RTL(__kmpc_push_target_tripcount_mapper, false, Void, IdentPtr, Int64, Int64)
 __OMP_RTL(__tgt_target_mapper, false, Int32, IdentPtr, Int64, VoidPtr, Int32, VoidPtrPtr,
   VoidPtrPtr, Int64Ptr, Int64Ptr, VoidPtrPtr, VoidPtrPtr)
-__OMP_RTL(__tgt_target_nowait_mapper, false, Int32, IdentPtr, Int64, VoidPtr, Int32,
-  VoidPtrPtr, VoidPtrPtr, Int64Ptr, Int64Ptr, VoidPtrPtr, VoidPtrPtr)
+__OMP_RTL(__tgt_target_nowait_mapper, false, Int32, IdentPtr, Int64, VoidPtr,
+  Int32, VoidPtrPtr, VoidPtrPtr, Int64Ptr, Int64Ptr, VoidPtrPtr,
+  VoidPtrPtr, Int32, VoidPtr, Int32, VoidPtr)
 __OMP_RTL(__tgt_target_teams_mapper, false, Int32, IdentPtr, Int64, VoidPtr, Int32,
   VoidPtrPtr, VoidPtrPtr, Int64Ptr, Int64Ptr, VoidPtrPtr, VoidPtrPtr, Int32, Int32)
-__OMP_RTL(__tgt_target_teams_nowait_mapper, false, Int32, IdentPtr, Int64, VoidPtr, Int32,
-  VoidPtrPtr, VoidPtrPtr, Int64Ptr, Int64Ptr, VoidPtrPtr, VoidPtrPtr, Int32, Int32)
+__OMP_RTL(__tgt_target_teams_nowait_mapper, false, Int32, IdentPtr, Int64,
+  VoidPtr, Int32, VoidPtrPtr, VoidPtrPtr, Int64Ptr, Int64Ptr,
+  VoidPtrPtr, VoidPtrPtr, Int32, Int32, Int32, VoidPtr, Int32, VoidPtr)
 __OMP_RTL(__tgt_register_requires, false, Void, Int64)
 __OMP_RTL(__tgt_target_data_begin_mapper, false, Void, IdentPtr, Int64, Int32, VoidPtrPtr,
   VoidPtrPtr, Int64Ptr, Int64Ptr, VoidPtrPtr, VoidPtrPtr)
Index: clang/test/OpenMP/target_teams_distribute_simd_depend_codegen.cpp
===
--- clang/test/OpenMP/target_teams_distribute_simd_depend_codegen.cpp
+++ clang/test/OpenMP/target_teams_distribute_simd_depend_codegen.cpp
@@ -242,8 +242,8 @@
 // OMP50-32:   [[DEVICE_CAP:%.+]] = getelementptr inbounds %{{.+}}, %{{.+}}* %{{.+}}, i32 0, i32 3
 // CHECK:   [[DEV:%.+]] = load i32, i32* [[DEVICE_CAP]],
 // CHECK:   [[DEVICE:%.+]] = sext i32 [[DEV]] to i64
-// OMP45:   [[RET:%.+]] = call i32 @__tgt_target_teams_nowait_mapper(%struct.ident_t* @{{.+}}, i64 [[DEVICE]], i8* @{{[^,]+}}, i32 2, i8** [[BPR:%[^,]+]], i8** [[PR:%[^,]+]], i64* [[SZT]], i64* getelementptr inbounds ([2 x i64], [2 x i64]* [[MAPT]], i32 0, i32 0), i8** null, i8** null, i32 0, i32 1)
-// OMP50:   [[RET:%.+]] = call i32 @__tgt_target_teams_nowait_mapper(%struct.ident_t* @{{.+}}, i64 [[DEVICE]], i8* @{{[^,]+}}, i32 3, i8** [[BPR:%[^,]+]], i8** [[PR:%[^,]+]], i64* [[SZT]], i64* getelementptr inbounds ([3 x i64], [3 x i64]* [[MAPT]], i32 0, i32 0), i8** null, i8** null, i32 0, i32 1)
+// OMP45:   [[RET:%.+]] = call i32 @__tgt_target_teams_nowait_mapper(%struct.ident_t* @{{.+}}, i64 [[DEVICE]], i8* @{{[^,]+}}, i32 2, i8** [[BPR:%[^,]+]], i8** [[PR:%[^,]+]], i64* [[SZT]], i64* getelementptr inbounds ([2 x i64], [2 x i64]* [[MAPT]], i32 0, i32 0), i8** null, i8** null, i32 0, i32 1, i32 0, i8* null, i32 0, i8* null)
+// OMP50:   [[RET:%.+]] = call i32 @__tgt_target_teams_nowait_mapper(%struct.ident_t* @{{.+}}, i64 [[DEVICE]], i8* @{{[^,]+}}, i32 3, i8** [[BPR:%[^,]+]], i8** [[PR:%[^,]+]], i64* [[SZT]], i64* getelementptr inbounds ([3 x i64], [3 x i64]* [[MAPT]], i32 0, i32 0), i8** null, i8** 

[PATCH] D106431: [clang-tidy] Fix cppcoreguidelines-init-variables with enum judgement

2021-07-22 Thread Whisperity via Phabricator via cfe-commits
whisperity added a comment.

In D106431#2896441 , @aaron.ballman 
wrote:

> However, I don't recall how clang-tidy interacts with fix-its on notes off 
> the top of my head, so I'm making an assumption that clang-tidy's automatic 
> fixit applying mode handles notes the same way as clang and we should 
> double-check that assumption.

I have one information from January that if you're viewing the diagnostic 
output as a sequence of `[warning, note, note, ...]` elements (so you "group 
by" warning), Clang-Tidy will apply the //first// fix (be it on the warning or 
the note) in the order of `diag()` calls. (There was a (never-upstreamed) check 
in which I had to abuse this fact.) This behaviour could've changed, though...

In D106431#2896441 , @aaron.ballman 
wrote:

> Another way forward would be to not issue a fix-it for integers or 
> enumerations.

This might be the best course of action, and could be fixed in the same patch 
(this one)...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106431

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


[PATCH] D106375: Thread safety analysis: Mock getter for private mutexes can be undefined

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

LGTM! It took me a minute to convince myself it wasn't really an ODR use (the 
argument goes through the usual expression evaluation parsing and sema bits), 
but because the arguments to these attributes never wind up being used in 
codegen, they're not really a use as far as the ODR is concerned.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106375

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


[PATCH] D106431: [clang-tidy] Fix cppcoreguidelines-init-variables with enum judgement

2021-07-22 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D106431#2896472 , @whisperity 
wrote:

> In D106431#2896441 , @aaron.ballman 
> wrote:
>
>> However, I don't recall how clang-tidy interacts with fix-its on notes off 
>> the top of my head, so I'm making an assumption that clang-tidy's automatic 
>> fixit applying mode handles notes the same way as clang and we should 
>> double-check that assumption.
>
> I have one information from January that if you're viewing the diagnostic 
> output as a sequence of `[warning, note, note, ...]` elements (so you "group 
> by" warning), Clang-Tidy will apply the //first// fix (be it on the warning 
> or the note) in the order of `diag()` calls. (There was a (never-upstreamed) 
> check in which I had to abuse this fact.) This behaviour could've changed, 
> though...
>
> In D106431#2896441 , @aaron.ballman 
> wrote:
>
>> Another way forward would be to not issue a fix-it for integers or 
>> enumerations.
>
> This might be the best course of action, and could be fixed in the same patch 
> (this one)...

I think that's a reasonable way forward, though I don't insist on changing the 
integer behavior if others have strong opinions that it is correct. I do have 
strong opinions on fixing the enumeration behavior because that fix-it is wrong 
for C++ code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106431

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


[PATCH] D106542: [OPENMP]Fix PR49787: Codegen for calling __tgt_target_teams_nowait_mapper has too few arguments.

2021-07-22 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield added a comment.

Nice, thanks


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106542

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


[PATCH] D95588: [RISCV] Implement the MC layer support of P extension

2021-07-22 Thread Jim Lin via Phabricator via cfe-commits
Jim added a comment.

ping? Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95588

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


[clang] f828f0a - Revert "[OPENMP]Fix PR49787: Codegen for calling __tgt_target_teams_nowait_mapper has too few arguments."

2021-07-22 Thread Alexey Bataev via cfe-commits

Author: Alexey Bataev
Date: 2021-07-22T08:06:29-07:00
New Revision: f828f0a90fb14d10dbb5ac2d55c62d9dafdf8721

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

LOG: Revert "[OPENMP]Fix PR49787: Codegen for calling 
__tgt_target_teams_nowait_mapper has too few arguments."

This reverts commit b455f7f22564a096c043b02fa159ab16669c121c to fix
buildbots.

Added: 


Modified: 
clang/lib/CodeGen/CGOpenMPRuntime.cpp
clang/test/OpenMP/declare_mapper_codegen.cpp
clang/test/OpenMP/target_codegen.cpp
clang/test/OpenMP/target_depend_codegen.cpp
clang/test/OpenMP/target_parallel_codegen.cpp
clang/test/OpenMP/target_parallel_depend_codegen.cpp
clang/test/OpenMP/target_parallel_for_codegen.cpp
clang/test/OpenMP/target_parallel_for_depend_codegen.cpp
clang/test/OpenMP/target_parallel_for_simd_codegen.cpp
clang/test/OpenMP/target_parallel_for_simd_depend_codegen.cpp
clang/test/OpenMP/target_simd_codegen.cpp
clang/test/OpenMP/target_simd_depend_codegen.cpp
clang/test/OpenMP/target_teams_codegen.cpp
clang/test/OpenMP/target_teams_depend_codegen.cpp
clang/test/OpenMP/target_teams_distribute_codegen.cpp
clang/test/OpenMP/target_teams_distribute_depend_codegen.cpp
clang/test/OpenMP/target_teams_distribute_parallel_for_depend_codegen.cpp

clang/test/OpenMP/target_teams_distribute_parallel_for_simd_depend_codegen.cpp
clang/test/OpenMP/target_teams_distribute_simd_codegen.cpp
clang/test/OpenMP/target_teams_distribute_simd_depend_codegen.cpp
llvm/include/llvm/Frontend/OpenMP/OMPKinds.def

Removed: 




diff  --git a/clang/lib/CodeGen/CGOpenMPRuntime.cpp 
b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
index e7aa84ef3d90..7310b5c3f8d0 100644
--- a/clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -10160,27 +10160,18 @@ void CGOpenMPRuntime::emitTargetCall(
   // passed to the runtime library - a 32-bit integer with the value zero.
   assert(NumThreads && "Thread limit expression should be available along "
"with number of teams.");
-  SmallVector OffloadingArgs = {
-  RTLoc,
-  DeviceID,
-  OutlinedFnID,
-  PointerNum,
-  InputInfo.BasePointersArray.getPointer(),
-  InputInfo.PointersArray.getPointer(),
-  InputInfo.SizesArray.getPointer(),
-  MapTypesArray,
-  MapNamesArray,
-  InputInfo.MappersArray.getPointer(),
-  NumTeams,
-  NumThreads};
-  if (HasNowait) {
-// Add int32_t depNum = 0, void *depList = nullptr, int32_t
-// noAliasDepNum = 0, void *noAliasDepList = nullptr.
-OffloadingArgs.push_back(CGF.Builder.getInt32(0));
-
OffloadingArgs.push_back(llvm::ConstantPointerNull::get(CGM.VoidPtrTy));
-OffloadingArgs.push_back(CGF.Builder.getInt32(0));
-
OffloadingArgs.push_back(llvm::ConstantPointerNull::get(CGM.VoidPtrTy));
-  }
+  llvm::Value *OffloadingArgs[] = {RTLoc,
+   DeviceID,
+   OutlinedFnID,
+   PointerNum,
+   
InputInfo.BasePointersArray.getPointer(),
+   InputInfo.PointersArray.getPointer(),
+   InputInfo.SizesArray.getPointer(),
+   MapTypesArray,
+   MapNamesArray,
+   InputInfo.MappersArray.getPointer(),
+   NumTeams,
+   NumThreads};
   Return = CGF.EmitRuntimeCall(
   OMPBuilder.getOrCreateRuntimeFunction(
   CGM.getModule(), HasNowait
@@ -10188,25 +10179,16 @@ void CGOpenMPRuntime::emitTargetCall(
: OMPRTL___tgt_target_teams_mapper),
   OffloadingArgs);
 } else {
-  SmallVector OffloadingArgs = {
-  RTLoc,
-  DeviceID,
-  OutlinedFnID,
-  PointerNum,
-  InputInfo.BasePointersArray.getPointer(),
-  InputInfo.PointersArray.getPointer(),
-  InputInfo.SizesArray.getPointer(),
-  MapTypesArray,
-  MapNamesArray,
-  InputInfo.MappersArray.getPointer()};
-  if (HasNowait) {
-// Add int32_t depNum = 0, void *depList = nullptr, int32_t
-// noAliasDepNum = 0, void *noAliasDepList = nullptr.
-OffloadingArgs.push_back(CGF.Builder.getInt32(0));
-
OffloadingArgs.push_back(llvm::ConstantPointerNull::get(CGM.VoidPtrTy));
-OffloadingArgs.push_back(CGF.Builder.getInt32(0));
-
OffloadingArgs.push_back(llvm::Consta

[PATCH] D106277: [SVE] Remove the interface for getMaxVScale in favour of the IR attributes

2021-07-22 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added inline comments.



Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:504
  VScale, VScale));
+  } else if (getContext().getTargetInfo().hasFeature("sve")) {
+CurFn->addFnAttr(

Is there any way we can check that the target is ARM before checking an "sve" 
on a target independent interface? If any other target uses the name "sve" this 
will trigger.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106277

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


  1   2   3   >