[PATCH] D90822: [X86] use macros to split GFNI intrinsics into different kinds

[Pengfei Wang via Phabricator via cfe-commits]

pengfei added inline comments.



Comment at: clang/lib/Headers/gfniintrin.h:24
+#ifdef __AVXINTRIN_H
+#ifdef __AVX512BWINTRIN_H
+#ifdef __AVX512VLINTRIN_H

`__AVX512VLBWINTRIN_H` is better.



Comment at: clang/lib/Headers/gfniintrin.h:52
 U, A, B, I)
-
+#endif
 

missing comments



Comment at: clang/lib/Headers/gfniintrin.h:190
 }
+#endif
 

comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90822

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

[PATCH] D89972: Add pipeline model for HiSilicon's TSV110

[Elvina Yakubova via Phabricator via cfe-commits]

Elvina added a comment.

@SjoerdMeijer thanks for the review! 
@bryanpkc does everything look fine? Can I commit it?


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

https://reviews.llvm.org/D89972

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

[PATCH] D90832: [clang-tidy] Extend IdentifierNamingCheck per file config

[Nathan James via Phabricator via cfe-commits]

njames93 created this revision.
njames93 added reviewers: aaron.ballman, alexfh, gribozavr2.
Herald added subscribers: cfe-commits, xazax.hun.
Herald added a project: clang.
njames93 requested review of this revision.

Add IgnoreMainLikeFunctions to the per file config. This can be extended for 
new options added to the check easily.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D90832

Files:
  clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp
  clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.h

Index: clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.h
===
--- clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.h
+++ clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.h
@@ -60,6 +60,15 @@
 std::string Suffix;
   };
 
+  struct FileStyle {
+FileStyle();
+FileStyle(SmallVectorImpl> &&Styles,
+  bool IgnoreMainLike)
+: Styles(std::move(Styles)), IgnoreMainLikeFunctions(IgnoreMainLike) {}
+SmallVector, 0> Styles;
+bool IgnoreMainLikeFunctions;
+  };
+
 private:
   llvm::Optional
   GetDeclFailureInfo(const NamedDecl *Decl,
@@ -70,19 +79,16 @@
   DiagInfo GetDiagInfo(const NamingCheckId &ID,
const NamingCheckFailure &Failure) const override;
 
-  ArrayRef>
-  getStyleForFile(StringRef FileName) const;
+  const FileStyle &getStyleForFile(StringRef FileName) const;
 
   /// Stores the style options as a vector, indexed by the specified \ref
   /// StyleKind, for a given directory.
-  mutable llvm::StringMap>>
-  NamingStylesCache;
-  ArrayRef> MainFileStyle;
+  mutable llvm::StringMap NamingStylesCache;
+  FileStyle *MainFileStyle;
   ClangTidyContext *const Context;
   const std::string CheckName;
   const bool GetConfigPerFile;
   const bool IgnoreFailedSplit;
-  const bool IgnoreMainLikeFunctions;
 };
 
 } // namespace readability
Index: clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp
===
--- clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp
+++ clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp
@@ -122,9 +122,9 @@
 #undef NAMING_KEYS
 // clang-format on
 
-static std::vector>
-getNamingStyles(const ClangTidyCheck::OptionsView &Options) {
-  std::vector> Styles(
+static IdentifierNamingCheck::FileStyle
+getFileStyle(const ClangTidyCheck::OptionsView &Options) {
+  SmallVector, 0> Styles(
   SK_Count);
   SmallString<64> StyleString;
   for (unsigned I = 0; I < SK_Count; ++I) {
@@ -145,50 +145,54 @@
   Styles[I].emplace(std::move(CaseOptional), std::move(Prefix),
 std::move(Postfix));
   }
-  return Styles;
+  bool IgnoreMainLike = Options.get("IgnoreMainLikeFunctions", false);
+  return {std::move(Styles), IgnoreMainLike};
 }
 
 IdentifierNamingCheck::IdentifierNamingCheck(StringRef Name,
  ClangTidyContext *Context)
 : RenamerClangTidyCheck(Name, Context), Context(Context), CheckName(Name),
   GetConfigPerFile(Options.get("GetConfigPerFile", true)),
-  IgnoreFailedSplit(Options.get("IgnoreFailedSplit", false)),
-  IgnoreMainLikeFunctions(Options.get("IgnoreMainLikeFunctions", false)) {
+  IgnoreFailedSplit(Options.get("IgnoreFailedSplit", false)) {
 
   auto IterAndInserted = NamingStylesCache.try_emplace(
   llvm::sys::path::parent_path(Context->getCurrentFile()),
-  getNamingStyles(Options));
+  getFileStyle(Options));
   assert(IterAndInserted.second && "Couldn't insert Style");
   // Holding a reference to the data in the vector is safe as it should never
   // move.
-  MainFileStyle = IterAndInserted.first->getValue();
+  MainFileStyle = &IterAndInserted.first->getValue();
 }
 
+IdentifierNamingCheck::FileStyle::FileStyle()
+: Styles(SK_Count), IgnoreMainLikeFunctions(false) {}
+
 IdentifierNamingCheck::~IdentifierNamingCheck() = default;
 
 void IdentifierNamingCheck::storeOptions(ClangTidyOptions::OptionMap &Opts) {
   RenamerClangTidyCheck::storeOptions(Opts);
   SmallString<64> StyleString;
   for (size_t I = 0; I < SK_Count; ++I) {
-if (!MainFileStyle[I])
+if (!MainFileStyle->Styles[I])
   continue;
 StyleString = StyleNames[I];
 size_t StyleSize = StyleString.size();
 StyleString.append("Prefix");
-Options.store(Opts, StyleString, MainFileStyle[I]->Prefix);
+Options.store(Opts, StyleString, MainFileStyle->Styles[I]->Prefix);
 // Fast replacement of [Pre]fix -> [Suf]fix.
 memcpy(&StyleString[StyleSize], "Suf", 3);
-Options.store(Opts, StyleString, MainFileStyle[I]->Suffix);
-if (MainFileStyle[I]->Case) {
+Options.store(Opts, StyleString, MainFileStyle->Styles[I]->Suffix);
+if (MainFileStyle->Styles[I]->Case) {
   memcpy(&StyleString[StyleSize], "Case", 4);
   StyleString.pop_back();
   StyleS

[PATCH] D89959: UBSAN: emit distinctive traps in trapping mode

[Tim Northover via Phabricator via cfe-commits]

t.p.northover added a comment.

With current CodeGen by the time you reach the trap you have no idea what came 
before so I think you'd still need a separate trap instruction per failure 
kind. So the Clang and generic LLVM side would be unaffected.

I suppose on X86 it could save a few bytes in .text and so maybe icache (though 
again we're talking about roughly 50% bloat for enabling UBSAN at all so this 
is kind of lost in the noise). On the whole I'm not a fan of inventing a new 
entirely separate scheme for that.


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

https://reviews.llvm.org/D89959

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

[PATCH] D89959: UBSAN: emit distinctive traps in trapping mode

[Tim Northover via Phabricator via cfe-commits]

t.p.northover marked an inline comment as done.
t.p.northover added a comment.

> Was this measured with all of -fsanitize=undefined enabled? If so, the actual 
> size overhead is likely lower, as only a subset of these checks get enabled 
> in production settings.

Yes, I used `-fsanitize=undefined -fsanitize-trap=all`. Fixed the LangRef but I 
won't upload another diff unless something more substantial changes.


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

https://reviews.llvm.org/D89959

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

[PATCH] D90240: [SyntaxTree] Add reverse links to syntax Nodes.

[Eduardo Caldas via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG23657d9cc332: [SyntaxTree] Add reverse links to syntax 
Nodes. (authored by eduucaldas).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90240

Files:
  clang/include/clang/Tooling/Syntax/Tree.h
  clang/lib/Tooling/Syntax/BuildTree.cpp
  clang/lib/Tooling/Syntax/Mutations.cpp
  clang/lib/Tooling/Syntax/Synthesis.cpp
  clang/lib/Tooling/Syntax/Tree.cpp

Index: clang/lib/Tooling/Syntax/Tree.cpp
===
--- clang/lib/Tooling/Syntax/Tree.cpp
+++ clang/lib/Tooling/Syntax/Tree.cpp
@@ -57,8 +57,9 @@
 }
 
 syntax::Node::Node(NodeKind Kind)
-: Parent(nullptr), NextSibling(nullptr), Kind(static_cast(Kind)),
-  Role(0), Original(false), CanModify(false) {
+: Parent(nullptr), NextSibling(nullptr), PreviousSibling(nullptr),
+  Kind(static_cast(Kind)), Role(0), Original(false),
+  CanModify(false) {
   this->setRole(NodeRole::Detached);
 }
 
@@ -74,6 +75,30 @@
   return N->getKind() > NodeKind::Leaf;
 }
 
+void syntax::Tree::appendChildLowLevel(Node *Child, NodeRole Role) {
+  assert(Child->getRole() == NodeRole::Detached);
+  assert(Role != NodeRole::Detached);
+
+  Child->setRole(Role);
+  appendChildLowLevel(Child);
+}
+
+void syntax::Tree::appendChildLowLevel(Node *Child) {
+  assert(Child->Parent == nullptr);
+  assert(Child->NextSibling == nullptr);
+  assert(Child->PreviousSibling == nullptr);
+  assert(Child->getRole() != NodeRole::Detached);
+
+  Child->Parent = this;
+  if (this->LastChild) {
+Child->PreviousSibling = this->LastChild;
+this->LastChild->NextSibling = Child;
+  } else
+this->FirstChild = Child;
+
+  this->LastChild = Child;
+}
+
 void syntax::Tree::prependChildLowLevel(Node *Child, NodeRole Role) {
   assert(Child->getRole() == NodeRole::Detached);
   assert(Role != NodeRole::Detached);
@@ -85,22 +110,26 @@
 void syntax::Tree::prependChildLowLevel(Node *Child) {
   assert(Child->Parent == nullptr);
   assert(Child->NextSibling == nullptr);
+  assert(Child->PreviousSibling == nullptr);
   assert(Child->getRole() != NodeRole::Detached);
 
   Child->Parent = this;
-  Child->NextSibling = this->FirstChild;
+  if (this->FirstChild) {
+Child->NextSibling = this->FirstChild;
+this->FirstChild->PreviousSibling = Child;
+  } else
+this->LastChild = Child;
+
   this->FirstChild = Child;
 }
 
-void syntax::Tree::replaceChildRangeLowLevel(Node *BeforeBegin, Node *End,
+void syntax::Tree::replaceChildRangeLowLevel(Node *Begin, Node *End,
  Node *New) {
-  assert((!BeforeBegin || BeforeBegin->Parent == this) &&
- "`BeforeBegin` is not a child of `this`.");
+  assert((!Begin || Begin->Parent == this) &&
+ "`Begin` is not a child of `this`.");
   assert((!End || End->Parent == this) && "`End` is not a child of `this`.");
   assert(canModify() && "Cannot modify `this`.");
 
-  Node *&Begin = BeforeBegin ? BeforeBegin->NextSibling : FirstChild;
-
 #ifndef NDEBUG
   for (auto *N = New; N; N = N->NextSibling) {
 assert(N->Parent == nullptr);
@@ -116,9 +145,8 @@
 return true;
 return false;
   };
-  assert(Reachable(FirstChild, BeforeBegin) &&
- "`BeforeBegin` is not reachable.");
-  assert(Reachable(Begin, End) && "`End` is not after `BeforeBegin`.");
+  assert(Reachable(FirstChild, Begin) && "`Begin` is not reachable.");
+  assert(Reachable(Begin, End) && "`End` is not after `Begin`.");
 #endif
 
   if (!New && Begin == End)
@@ -128,6 +156,10 @@
   for (auto *T = this; T && T->Original; T = T->Parent)
 T->Original = false;
 
+  // Save the node before the range to be removed. Later we insert the `New`
+  // range after this node.
+  auto *BeforeBegin = Begin ? Begin->PreviousSibling : LastChild;
+
   // Detach old nodes.
   for (auto *N = Begin; N != End;) {
 auto *Next = N->NextSibling;
@@ -135,24 +167,33 @@
 N->setRole(NodeRole::Detached);
 N->Parent = nullptr;
 N->NextSibling = nullptr;
+N->PreviousSibling = nullptr;
 if (N->Original)
   traverse(N, [](Node *C) { C->Original = false; });
 
 N = Next;
   }
 
+  // Attach new range.
+  auto *&NewFirst = BeforeBegin ? BeforeBegin->NextSibling : FirstChild;
+  auto *&NewLast = End ? End->PreviousSibling : LastChild;
+
   if (!New) {
-Begin = End;
+NewFirst = End;
+NewLast = BeforeBegin;
 return;
   }
-  // Attach new nodes.
-  Begin = New;
-  auto *Last = New;
+
+  New->PreviousSibling = BeforeBegin;
+  NewFirst = New;
+
+  Node *LastInNew;
   for (auto *N = New; N != nullptr; N = N->NextSibling) {
-Last = N;
+LastInNew = N;
 N->Parent = this;
   }
-  Last->NextSibling = End;
+  LastInNew->NextSibling = End;
+  NewLast = LastInNew;
 }
 
 namespace {
@@ -248,6 +289,11 @@
   assert(C.isO

[clang] 23657d9 - [SyntaxTree] Add reverse links to syntax Nodes.

[Eduardo Caldas via cfe-commits]

Author: Eduardo Caldas
Date: 2020-11-05T09:33:53Z
New Revision: 23657d9cc33282208bdac074abccd73bd4d4f8be

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

LOG: [SyntaxTree] Add reverse links to syntax Nodes.

Rationale:
Children of a syntax tree had forward links only, because there was no
need for reverse links.

This need appeared when we started mutating the syntax tree.
On a forward list, to remove a target node in O(1) we need a pointer to the 
node before the target. If we don't have this "before" pointer, we have to find 
it, and that requires O(n).
So in order to remove a syntax node from a tree, we would similarly need to 
find the node before to then remove. This is both not ergonomic nor does it 
have a good complexity.

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

Added: 


Modified: 
clang/include/clang/Tooling/Syntax/Tree.h
clang/lib/Tooling/Syntax/BuildTree.cpp
clang/lib/Tooling/Syntax/Mutations.cpp
clang/lib/Tooling/Syntax/Synthesis.cpp
clang/lib/Tooling/Syntax/Tree.cpp

Removed: 




diff  --git a/clang/include/clang/Tooling/Syntax/Tree.h 
b/clang/include/clang/Tooling/Syntax/Tree.h
index 4bfa15517ba4..b92e92305417 100644
--- a/clang/include/clang/Tooling/Syntax/Tree.h
+++ b/clang/include/clang/Tooling/Syntax/Tree.h
@@ -118,6 +118,8 @@ class Node {
 
   const Node *getNextSibling() const { return NextSibling; }
   Node *getNextSibling() { return NextSibling; }
+  const Node *getPreviousSibling() const { return PreviousSibling; }
+  Node *getPreviousSibling() { return PreviousSibling; }
 
   /// Dumps the structure of a subtree. For debugging and testing purposes.
   std::string dump(const SourceManager &SM) const;
@@ -144,6 +146,7 @@ class Node {
 
   Tree *Parent;
   Node *NextSibling;
+  Node *PreviousSibling;
   unsigned Kind : 16;
   unsigned Role : 8;
   unsigned Original : 1;
@@ -197,6 +200,8 @@ class Tree : public Node {
 
   Node *getFirstChild() { return FirstChild; }
   const Node *getFirstChild() const { return FirstChild; }
+  Node *getLastChild() { return LastChild; }
+  const Node *getLastChild() const { return LastChild; }
 
   const Leaf *findFirstLeaf() const;
   Leaf *findFirstLeaf() {
@@ -236,25 +241,32 @@ class Tree : public Node {
   using Node::Node;
 
 private:
-  /// Prepend \p Child to the list of children and and sets the parent pointer.
+  /// Append \p Child to the list of children and sets the parent pointer.
   /// A very low-level operation that does not check any invariants, only used
   /// by TreeBuilder and FactoryImpl.
   /// EXPECTS: Role != Detached.
+  void appendChildLowLevel(Node *Child, NodeRole Role);
+  /// Similar but prepends.
   void prependChildLowLevel(Node *Child, NodeRole Role);
-  /// Like the previous overload, but does not set role for \p Child.
+
+  /// Like the previous overloads, but does not set role for \p Child.
   /// EXPECTS: Child->Role != Detached
+  void appendChildLowLevel(Node *Child);
   void prependChildLowLevel(Node *Child);
   friend class TreeBuilder;
   friend class FactoryImpl;
 
-  /// Replace a range of children [BeforeBegin->NextSibling, End) with a list 
of
+  /// Replace a range of children [Begin, End) with a list of
   /// new nodes starting at \p New.
   /// Only used by MutationsImpl to implement higher-level mutation operations.
   /// (!) \p New can be null to model removal of the child range.
-  void replaceChildRangeLowLevel(Node *BeforeBegin, Node *End, Node *New);
+  /// (!) \p End can be null to model one past the end.
+  /// (!) \p Begin can be null to model an append.
+  void replaceChildRangeLowLevel(Node *Begin, Node *End, Node *New);
   friend class MutationsImpl;
 
   Node *FirstChild = nullptr;
+  Node *LastChild = nullptr;
 };
 
 // Provide missing non_const == const overload.

diff  --git a/clang/lib/Tooling/Syntax/BuildTree.cpp 
b/clang/lib/Tooling/Syntax/BuildTree.cpp
index 197590522e36..682e070d 100644
--- a/clang/lib/Tooling/Syntax/BuildTree.cpp
+++ b/clang/lib/Tooling/Syntax/BuildTree.cpp
@@ -636,12 +636,11 @@ class syntax::TreeBuilder {
   (EndChildren == Trees.end() || EndChildren->first == Tokens.end()) &&
   "fold crosses boundaries of existing subtrees");
 
-  // We need to go in reverse order, because we can only prepend.
-  for (auto It = EndChildren; It != BeginChildren; --It) {
-auto *C = std::prev(It)->second;
+  for (auto It = BeginChildren; It != EndChildren; ++It) {
+auto *C = It->second;
 if (C->getRole() == NodeRole::Detached)
   C->setRole(NodeRole::Unknown);
-Node->prependChildLowLevel(C);
+Node->appendChildLowLevel(C);
   }
 
   // Mark that this node came from the AST and is backed by the source 
code.

diff  --git a/clang/lib/

[PATCH] D90835: [RFC][clang-tidy] Ignore diagnostics due to macro expansion from not-interested headers

[Dmitry Polukhin via Phabricator via cfe-commits]

DmitryPolukhin created this revision.
DmitryPolukhin added reviewers: alexfh, njames93, thakis.
DmitryPolukhin added projects: clang, clang-tools-extra.
Herald added subscribers: kbarton, xazax.hun, nemanjai.
DmitryPolukhin requested review of this revision.

This diff is an attempt to workaround a common problem with clang-tidy 
deployment.
There are headers that might not be compatible with your project style guide 
but you
have to use macro from that headers so clang-tidy could report lots of style 
issues
that you cannot fix or is some cases even annotate with NOLINT. Solution 
proposed
in this diff is to avoid reporting diagnostics in macro expansion of the macro 
defined
in headers that doesn't match the desired `--header-filter`.

Just one real life example of this issue from a very popular gflags library.
This library requires using macro in use code like this:

  DEFINE_bool(some_bool_flag,
      "the default value should go here, not the description",
      false);

But the macro has outdated version of compiler assert that uses C-style arrays 
.
Therefore use code becomes incompatible with clang-tidy check 
`modernize-avoid-c-arrays`.
Another example of problematic is googletest/googlemock with lots of macro that 
you cannot avoid.

This diff implements new behavior by default but it might be also possible to
enable it behind some configuration flag.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D90835

Files:
  clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
  clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.h
  clang-tools-extra/clang-tidy/cppcoreguidelines/ProTypeVarargCheck.cpp
  clang-tools-extra/test/clang-tidy/infrastructure/macros.cpp
  clang-tools-extra/test/clang-tidy/infrastructure/macros.h
  clang-tools-extra/test/clang-tidy/infrastructure/macros_filter.h

Index: clang-tools-extra/test/clang-tidy/infrastructure/macros_filter.h
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/infrastructure/macros_filter.h
@@ -0,0 +1,3 @@
+#define HEADER_FILTER_MACRO_DIAG_IN_ARG(a) a
+#define HEADER_FILTER_MACRO_DIAG_IN_BODY int var_B1[10]
+#define HEADER_FILTER_MACRO_DIAG_IN_BODY2 int var_B2[10]
Index: clang-tools-extra/test/clang-tidy/infrastructure/macros.h
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/infrastructure/macros.h
@@ -0,0 +1,9 @@
+#define HEADER_MACRO_DIAG_IN_ARG(a) a
+#define HEADER_MACRO_DIAG_IN_BODY int var_C1[10]
+#define HEADER_MACRO_DIAG_IN_BODY2 int var_C2[10]
+
+#define DEFINE_bool(name, val)\
+  namespace fLB { \
+  typedef char FLAG_##name##_value_is_not_a_bool[(sizeof(val) != sizeof(bool)) ? -1 : 1]; \
+  }   \
+  bool FLAG_##name = val
Index: clang-tools-extra/test/clang-tidy/infrastructure/macros.cpp
===
--- clang-tools-extra/test/clang-tidy/infrastructure/macros.cpp
+++ clang-tools-extra/test/clang-tidy/infrastructure/macros.cpp
@@ -1,7 +1,41 @@
-// RUN: clang-tidy -checks='-*,google-explicit-constructor' %s -- | FileCheck %s
+// RUN: clang-tidy -checks='-*,google-explicit-constructor,modernize-avoid-c-arrays' --header-filter='macros_filter.h' %s -- | FileCheck %s
+
+#include "macros.h"
+#include "macros_filter.h"
 
 #define Q(name) class name { name(int i); }
 
 Q(A);
 // CHECK: :[[@LINE-1]]:3: warning: single-argument constructors must be marked explicit
-// CHECK: :3:30: note: expanded from macro 'Q'
+// CHECK: :[[@LINE-4]]:30: note: expanded from macro 'Q'
+
+#define MAIN_MACRO_DIAG_IN_ARG(a) a
+MAIN_MACRO_DIAG_IN_ARG(int var_A[10]);
+// CHECK: :[[@LINE-1]]:24: warning: do not declare C-style arrays, use std::array<> instead
+
+#define MAIN_MACRO_DIAG_IN_BODY int var_A1[10]
+MAIN_MACRO_DIAG_IN_BODY;
+// CHECK: :[[@LINE-1]]:1: warning: do not declare C-style arrays, use std::array<> instead
+// CHECK: :[[@LINE-3]]:33: note: expanded from macro 'MAIN_MACRO_DIAG_IN_BODY'
+
+HEADER_FILTER_MACRO_DIAG_IN_ARG(int var_B[10]);
+// CHECK: :[[@LINE-1]]:33: warning: do not declare C-style arrays, use std::array<> instead
+
+HEADER_FILTER_MACRO_DIAG_IN_BODY;
+// CHECK: :[[@LINE-1]]:1: warning: do not declare C-style arrays, use std::array<> instead
+// CHECK: note: expanded from macro 'HEADER_FILTER_MACRO_DIAG_IN_BODY'
+
+#define MAIN_MACRO_WRAPPER HEADER_FILTER_MACRO_DIAG_IN_BODY2
+MAIN_MACRO_WRAPPER;
+// CHECK: :[[@LINE-1]]:1: warning: do not declare C-style arrays, use std::array<> instead
+// CHECK: note: expanded from macro 'MAIN_MACRO_WRAPPER'
+// CHECK: note: expanded from macro 'HEADER_FILTER_MACRO_DIA

[PATCH] D90822: [X86] use macros to split GFNI intrinsics into different kinds

[Freddy, Ye via Phabricator via cfe-commits]

FreddyYe updated this revision to Diff 303073.
FreddyYe added a comment.

Reorganize intrinsic orders to avoid using nested macros.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90822

Files:
  clang/lib/Headers/gfniintrin.h

Index: clang/lib/Headers/gfniintrin.h
===
--- clang/lib/Headers/gfniintrin.h
+++ clang/lib/Headers/gfniintrin.h
@@ -14,28 +14,84 @@
 #ifndef __GFNIINTRIN_H
 #define __GFNIINTRIN_H
 
+/* Default attributes for simple form (no masking). */
+#define __DEFAULT_FN_ATTRS __attribute__((__always_inline__, __nodebug__, __target__("gfni"), __min_vector_width__(128)))
+
+/* Default attributes for YMM unmasked form. */
+#define __DEFAULT_FN_ATTRS_Y __attribute__((__always_inline__, __nodebug__, __target__("avx,gfni"), __min_vector_width__(256)))
+
+/* Default attributes for ZMM forms. */
+#define __DEFAULT_FN_ATTRS_Z __attribute__((__always_inline__, __nodebug__, __target__("avx512bw,gfni"), __min_vector_width__(512)))
+
+/* Default attributes for VLX forms. */
+#define __DEFAULT_FN_ATTRS_VL128 __attribute__((__always_inline__, __nodebug__, __target__("avx512bw,avx512vl,gfni"), __min_vector_width__(128)))
+#define __DEFAULT_FN_ATTRS_VL256 __attribute__((__always_inline__, __nodebug__, __target__("avx512bw,avx512vl,gfni"), __min_vector_width__(256)))
 
 #define _mm_gf2p8affineinv_epi64_epi8(A, B, I) \
   (__m128i)__builtin_ia32_vgf2p8affineinvqb_v16qi((__v16qi)(__m128i)(A),  \
   (__v16qi)(__m128i)(B),  \
   (char)(I))
 
+#define _mm_gf2p8affine_epi64_epi8(A, B, I) \
+  (__m128i)__builtin_ia32_vgf2p8affineqb_v16qi((__v16qi)(__m128i)(A), \
+  (__v16qi)(__m128i)(B),  \
+  (char)(I))
+
+static __inline__ __m128i __DEFAULT_FN_ATTRS
+_mm_gf2p8mul_epi8(__m128i __A, __m128i __B)
+{
+  return (__m128i) __builtin_ia32_vgf2p8mulb_v16qi((__v16qi) __A,
+  (__v16qi) __B);
+}
+
+#ifdef __AVXINTRIN_H
+#define _mm256_gf2p8affineinv_epi64_epi8(A, B, I) \
+  (__m256i)__builtin_ia32_vgf2p8affineinvqb_v32qi((__v32qi)(__m256i)(A),  \
+  (__v32qi)(__m256i)(B),  \
+  (char)(I))
+
+#define _mm256_gf2p8affine_epi64_epi8(A, B, I) \
+  (__m256i)__builtin_ia32_vgf2p8affineqb_v32qi((__v32qi)(__m256i)(A), \
+  (__v32qi)(__m256i)(B),  \
+  (char)(I))
+
+static __inline__ __m256i __DEFAULT_FN_ATTRS_Y
+_mm256_gf2p8mul_epi8(__m256i __A, __m256i __B)
+{
+  return (__m256i) __builtin_ia32_vgf2p8mulb_v32qi((__v32qi) __A,
+  (__v32qi) __B);
+}
+#endif /* __AVXINTRIN_H */
+
+#ifdef __AVX512BWINTRIN_H
+#define _mm512_gf2p8affineinv_epi64_epi8(A, B, I) \
+  (__m512i)__builtin_ia32_vgf2p8affineinvqb_v64qi((__v64qi)(__m512i)(A),  \
+  (__v64qi)(__m512i)(B),  \
+  (char)(I))
+
+#define _mm512_gf2p8affine_epi64_epi8(A, B, I) \
+  (__m512i)__builtin_ia32_vgf2p8affineqb_v64qi((__v64qi)(__m512i)(A), \
+  (__v64qi)(__m512i)(B),  \
+  (char)(I))
+
+static __inline__ __m512i __DEFAULT_FN_ATTRS_Z
+_mm512_gf2p8mul_epi8(__m512i __A, __m512i __B)
+{
+  return (__m512i) __builtin_ia32_vgf2p8mulb_v64qi((__v64qi) __A,
+  (__v64qi) __B);
+}
+#endif /* __AVX512BWINTRIN_H */
+
+#ifdef __AVX512VLBWINTRIN_H
 #define _mm_mask_gf2p8affineinv_epi64_epi8(S, U, A, B, I) \
   (__m128i)__builtin_ia32_selectb_128((__mmask16)(U), \
 (__v16qi)_mm_gf2p8affineinv_epi64_epi8(A, B, I),  \
 (__v16qi)(__m128i)(S))
 
-
 #define _mm_maskz_gf2p8affineinv_epi64_epi8(U, A, B, I) \
   (__m128i)_mm_mask_gf2p8affineinv_epi64_epi8((__m128i)_mm_setzero_si128(),   \
 U, A, B, I)
 
-
-#define _mm256_gf2p8affineinv_epi64_epi8(A, B, I) \
-  (__m256i)__builtin_ia32_vgf2p8affineinvqb_v32qi((__v32qi)(__m256i)(A),  \
-  (__v32qi)(__m256i)(B),  \
-  (char)(I))
-
 #define _mm256_mask_gf2p8affineinv_epi64_epi8(S, U, A, B, I) \
(__m256i)__builtin_ia32_selectb_256((__mmask32)(U),\
 (__v32qi)_mm256_gf2p8affineinv_epi64_epi8(A, B, I),   \
@@ -45,12 +101,6 @@
   (__m256i)_mm256_mask_gf2p8affineinv_epi64_epi8((__m256i)_mm256_setzero_si256(), \
 U, A, B, I)
 
-
-#define _mm512_gf2p8affineinv_

[PATCH] D90822: [X86] use macros to split GFNI intrinsics into different kinds

[Pengfei Wang via Phabricator via cfe-commits]

pengfei added inline comments.



Comment at: clang/lib/Headers/gfniintrin.h:104-111
 #define _mm512_mask_gf2p8affineinv_epi64_epi8(S, U, A, B, I) \
(__m512i)__builtin_ia32_selectb_512((__mmask64)(U), 
   \
 (__v64qi)_mm512_gf2p8affineinv_epi64_epi8(A, B, I),
   \
 (__v64qi)(__m512i)(S))
 
 #define _mm512_maskz_gf2p8affineinv_epi64_epi8(U, A, B, I) \
   
(__m512i)_mm512_mask_gf2p8affineinv_epi64_epi8((__m512i)_mm512_setzero_si512(), 
   \

These 2 functions need to move to __AVX512BWINTRIN_H



Comment at: clang/lib/Headers/gfniintrin.h:131-138
 #define _mm512_mask_gf2p8affine_epi64_epi8(S, U, A, B, I) \
(__m512i)__builtin_ia32_selectb_512((__mmask64)(U), 
   \
 (__v64qi)_mm512_gf2p8affine_epi64_epi8(A, B, I),   
   \
 (__v64qi)(__m512i)(S))
 
 #define _mm512_maskz_gf2p8affine_epi64_epi8(U, A, B, I) \
   (__m512i)_mm512_mask_gf2p8affine_epi64_epi8((__m512i)_mm512_setzero_si512(), 
  \

These 2 functions need to move to __AVX512BWINTRIN_H



Comment at: clang/lib/Headers/gfniintrin.h:170-183
 static __inline__ __m512i __DEFAULT_FN_ATTRS_Z
 _mm512_mask_gf2p8mul_epi8(__m512i __S, __mmask64 __U, __m512i __A, __m512i __B)
 {
   return (__m512i) __builtin_ia32_selectb_512(__U,
   (__v64qi) _mm512_gf2p8mul_epi8(__A, __B),
   (__v64qi) __S);
 }

These 2 functions need to move to __AVX512BWINTRIN_H


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90822

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

[PATCH] D90766: [OpenCL] Support vec_step in C++ for OpenCL mode

[Sven van Haastregt via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG8ac9bcc746b9: [OpenCL] Support vec_step in C++ for OpenCL 
mode (authored by svenvh).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90766

Files:
  clang/include/clang/Basic/TokenKinds.def
  clang/test/CodeGenOpenCLCXX/constexpr.cl


Index: clang/test/CodeGenOpenCLCXX/constexpr.cl
===
--- clang/test/CodeGenOpenCLCXX/constexpr.cl
+++ clang/test/CodeGenOpenCLCXX/constexpr.cl
@@ -52,3 +52,13 @@
 kernel void vecEval2(global int2 *x) {
   *x = fromConstexprFunc;
 }
+
+// Test evaluation of vec_step
+// CHECK-LABEL: define spir_kernel void @vec_step_test
+// CHECK: store i32 6
+constexpr int vsize1 = vec_step(fromConstexprFunc);
+constexpr int vsize2 = vec_step(int4);
+
+kernel void vec_step_test(global int *x) {
+  *x = vsize1 + vsize2;
+}
Index: clang/include/clang/Basic/TokenKinds.def
===
--- clang/include/clang/Basic/TokenKinds.def
+++ clang/include/clang/Basic/TokenKinds.def
@@ -586,7 +586,7 @@
 ALIAS("read_write", __read_write, KEYOPENCLC | KEYOPENCLCXX)
 // OpenCL builtins
 KEYWORD(__builtin_astype, KEYOPENCLC | KEYOPENCLCXX)
-UNARY_EXPR_OR_TYPE_TRAIT(vec_step, VecStep, KEYOPENCLC | KEYALTIVEC | 
KEYZVECTOR)
+UNARY_EXPR_OR_TYPE_TRAIT(vec_step, VecStep, KEYOPENCLC | KEYOPENCLCXX | 
KEYALTIVEC | KEYZVECTOR)
 #define GENERIC_IMAGE_TYPE(ImgType, Id) KEYWORD(ImgType##_t, KEYOPENCLC | 
KEYOPENCLCXX)
 #include "clang/Basic/OpenCLImageTypes.def"
 KEYWORD(pipe, KEYOPENCLC | KEYOPENCLCXX)


Index: clang/test/CodeGenOpenCLCXX/constexpr.cl
===
--- clang/test/CodeGenOpenCLCXX/constexpr.cl
+++ clang/test/CodeGenOpenCLCXX/constexpr.cl
@@ -52,3 +52,13 @@
 kernel void vecEval2(global int2 *x) {
   *x = fromConstexprFunc;
 }
+
+// Test evaluation of vec_step
+// CHECK-LABEL: define spir_kernel void @vec_step_test
+// CHECK: store i32 6
+constexpr int vsize1 = vec_step(fromConstexprFunc);
+constexpr int vsize2 = vec_step(int4);
+
+kernel void vec_step_test(global int *x) {
+  *x = vsize1 + vsize2;
+}
Index: clang/include/clang/Basic/TokenKinds.def
===
--- clang/include/clang/Basic/TokenKinds.def
+++ clang/include/clang/Basic/TokenKinds.def
@@ -586,7 +586,7 @@
 ALIAS("read_write", __read_write, KEYOPENCLC | KEYOPENCLCXX)
 // OpenCL builtins
 KEYWORD(__builtin_astype, KEYOPENCLC | KEYOPENCLCXX)
-UNARY_EXPR_OR_TYPE_TRAIT(vec_step, VecStep, KEYOPENCLC | KEYALTIVEC | KEYZVECTOR)
+UNARY_EXPR_OR_TYPE_TRAIT(vec_step, VecStep, KEYOPENCLC | KEYOPENCLCXX | KEYALTIVEC | KEYZVECTOR)
 #define GENERIC_IMAGE_TYPE(ImgType, Id) KEYWORD(ImgType##_t, KEYOPENCLC | KEYOPENCLCXX)
 #include "clang/Basic/OpenCLImageTypes.def"
 KEYWORD(pipe, KEYOPENCLC | KEYOPENCLCXX)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 8ac9bcc - [OpenCL] Support vec_step in C++ for OpenCL mode

[Sven van Haastregt via cfe-commits]

Author: Sven van Haastregt
Date: 2020-11-05T12:02:59Z
New Revision: 8ac9bcc746b9bb4b0ccdd71c6cbeda3b406e7b46

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

LOG: [OpenCL] Support vec_step in C++ for OpenCL mode

Enable the vec_step builtin in C++ for OpenCL mode for compatibility
with OpenCL C.

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

Added: 


Modified: 
clang/include/clang/Basic/TokenKinds.def
clang/test/CodeGenOpenCLCXX/constexpr.cl

Removed: 




diff  --git a/clang/include/clang/Basic/TokenKinds.def 
b/clang/include/clang/Basic/TokenKinds.def
index 7664269fb8da..d8a2016e9caa 100644
--- a/clang/include/clang/Basic/TokenKinds.def
+++ b/clang/include/clang/Basic/TokenKinds.def
@@ -586,7 +586,7 @@ ALIAS("write_only", __write_only, KEYOPENCLC | 
KEYOPENCLCXX)
 ALIAS("read_write", __read_write, KEYOPENCLC | KEYOPENCLCXX)
 // OpenCL builtins
 KEYWORD(__builtin_astype, KEYOPENCLC | KEYOPENCLCXX)
-UNARY_EXPR_OR_TYPE_TRAIT(vec_step, VecStep, KEYOPENCLC | KEYALTIVEC | 
KEYZVECTOR)
+UNARY_EXPR_OR_TYPE_TRAIT(vec_step, VecStep, KEYOPENCLC | KEYOPENCLCXX | 
KEYALTIVEC | KEYZVECTOR)
 #define GENERIC_IMAGE_TYPE(ImgType, Id) KEYWORD(ImgType##_t, KEYOPENCLC | 
KEYOPENCLCXX)
 #include "clang/Basic/OpenCLImageTypes.def"
 KEYWORD(pipe, KEYOPENCLC | KEYOPENCLCXX)

diff  --git a/clang/test/CodeGenOpenCLCXX/constexpr.cl 
b/clang/test/CodeGenOpenCLCXX/constexpr.cl
index 8c3fad08ea76..8eb9218c8f44 100644
--- a/clang/test/CodeGenOpenCLCXX/constexpr.cl
+++ b/clang/test/CodeGenOpenCLCXX/constexpr.cl
@@ -52,3 +52,13 @@ const int2 fromConstexprFunc = addOne(int2(2));
 kernel void vecEval2(global int2 *x) {
   *x = fromConstexprFunc;
 }
+
+// Test evaluation of vec_step
+// CHECK-LABEL: define spir_kernel void @vec_step_test
+// CHECK: store i32 6
+constexpr int vsize1 = vec_step(fromConstexprFunc);
+constexpr int vsize2 = vec_step(int4);
+
+kernel void vec_step_test(global int *x) {
+  *x = vsize1 + vsize2;
+}



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

[PATCH] D89649: Fix __has_unique_object_representations with no_unique_address

[Gabor Bencze via Phabricator via cfe-commits]

gbencze updated this revision to Diff 303082.
gbencze added a comment.
Herald added a subscriber: mgrang.

Sorry for the slow update on this. 
I fixed the behavior when reusing tail padding as mentioned by @rsmith and took 
a shot at unifying the code paths for base classes and fields. Let me know your 
thoughts on the approach!


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

https://reviews.llvm.org/D89649

Files:
  clang/lib/AST/ASTContext.cpp
  clang/test/SemaCXX/has_unique_object_reps_no_unique_addr.cpp

Index: clang/test/SemaCXX/has_unique_object_reps_no_unique_addr.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/has_unique_object_reps_no_unique_addr.cpp
@@ -0,0 +1,42 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fsyntax-only -verify -std=c++2a %s
+//  expected-no-diagnostics
+
+struct Empty {};
+
+struct A {
+  [[no_unique_address]] Empty e;
+  char x;
+};
+
+static_assert(__has_unique_object_representations(A));
+
+struct B {
+  char x;
+  [[no_unique_address]] Empty e;
+};
+
+static_assert(__has_unique_object_representations(B));
+
+struct C {
+  char x;
+  [[no_unique_address]] Empty e1;
+  [[no_unique_address]] Empty e2;
+};
+
+static_assert(!__has_unique_object_representations(C));
+
+namespace TailPaddingReuse {
+struct A {
+private:
+  int a;
+
+public:
+  char b;
+};
+
+struct B {
+  [[no_unique_address]] A a;
+  char c[3];
+};
+} // namespace TailPaddingReuse
+static_assert(__has_unique_object_representations(TailPaddingReuse::B));
Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -2549,16 +2549,66 @@
   return !RD->field_empty();
 }
 
-static bool isStructEmpty(QualType Ty) {
-  const RecordDecl *RD = Ty->castAs()->getDecl();
+static int64_t getSubobjectOffset(const FieldDecl *Field,
+  const ASTContext &Context,
+  const clang::ASTRecordLayout & /*Layout*/) {
+  return Context.getFieldOffset(Field);
+}
 
-  if (!RD->field_empty())
-return false;
+static int64_t getSubobjectOffset(const CXXRecordDecl *RD,
+  const ASTContext &Context,
+  const clang::ASTRecordLayout &Layout) {
+  return Context.toBits(Layout.getBaseClassOffset(RD));
+}
 
-  if (const auto *ClassDecl = dyn_cast(RD))
-return ClassDecl->isEmpty();
+static llvm::Optional
+structHasUniqueObjectRepresentations(const ASTContext &Context,
+ const RecordDecl *RD);
 
-  return true;
+static llvm::Optional
+getSubobjectSizeInBits(const FieldDecl *Field, const ASTContext &Context) {
+  if (Field->getType()->isRecordType()) {
+const RecordDecl *RD = Field->getType()->getAsRecordDecl();
+if (!RD->isUnion())
+  return structHasUniqueObjectRepresentations(Context, RD);
+  }
+  if (!Field->getType()->isReferenceType() &&
+  !Context.hasUniqueObjectRepresentations(Field->getType()))
+return llvm::None;
+
+  int64_t FieldSizeInBits =
+  Context.toBits(Context.getTypeSizeInChars(Field->getType()));
+  if (Field->isBitField()) {
+int64_t BitfieldSize = Field->getBitWidthValue(Context);
+if (BitfieldSize > FieldSizeInBits)
+  return llvm::None;
+FieldSizeInBits = BitfieldSize;
+  }
+  return FieldSizeInBits;
+}
+
+static llvm::Optional
+getSubobjectSizeInBits(const CXXRecordDecl *RD, const ASTContext &Context) {
+  return structHasUniqueObjectRepresentations(Context, RD);
+}
+
+template 
+static llvm::Optional structSubobjectsHaveUniqueObjectRepresentations(
+const RangeT &Subobjects, int64_t CurOffsetInBits, const ASTContext &Context,
+const clang::ASTRecordLayout &Layout) {
+  for (const auto *Subobject : Subobjects) {
+llvm::Optional SizeInBits =
+getSubobjectSizeInBits(Subobject, Context);
+if (!SizeInBits)
+  return llvm::None;
+if (*SizeInBits != 0) {
+  int64_t Offset = getSubobjectOffset(Subobject, Context, Layout);
+  if (Offset != CurOffsetInBits)
+return llvm::None;
+  CurOffsetInBits += *SizeInBits;
+}
+  }
+  return CurOffsetInBits;
 }
 
 static llvm::Optional
@@ -2572,58 +2622,32 @@
 if (ClassDecl->isDynamicClass())
   return llvm::None;
 
-SmallVector, 4> Bases;
+SmallVector Bases;
 for (const auto &Base : ClassDecl->bases()) {
   // Empty types can be inherited from, and non-empty types can potentially
   // have tail padding, so just make sure there isn't an error.
-  if (!isStructEmpty(Base.getType())) {
-llvm::Optional Size = structHasUniqueObjectRepresentations(
-Context, Base.getType()->castAs()->getDecl());
-if (!Size)
-  return llvm::None;
-Bases.emplace_back(Base.getType(), Size.getValue());
-  }
+  Bases.emplace_back(Base.getType()->getAsCXXRecordDecl ());
 }
 
-

[PATCH] D89649: Fix __has_unique_object_representations with no_unique_address

[Gabor Bencze via Phabricator via cfe-commits]

gbencze added inline comments.



Comment at: clang/test/SemaCXX/has_unique_object_reps_no_unique_addr.cpp:1
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fsyntax-only -verify 
-std=c++2a %s
+//  expected-no-diagnostics

Just to be sure: is the specifying the triple here enough to ensure that this 
always uses the Itanium ABI? I believe MSVC currently ignores the 
`no_unique_address` attribute. Or do I need to add some more flags?
Alternatively, the static_asserts could be modified to check `sizeof(T) > 
[expected size with Itanium ABI] || __has_unique_object_representations(T)`


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

https://reviews.llvm.org/D89649

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

[PATCH] D89031: [SVE] Add support to vectorize_width loop pragma for scalable vectors

[David Sherwood via Phabricator via cfe-commits]

david-arm added a comment.

I'll hold off on any more changes for now to give @fhahn a chance to reply to 
your comment @sdesmalen about the fallback behaviour when scalable 
vectorisation is unsupported.




Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:939
+def warn_pragma_attribute_scalable_unused : Warning<
+  "ignoring scalable vectorize_width flag due to lack of target support">,
+  InGroup;

sdesmalen wrote:
> From what I can see, the vectorize_width flag is not ignored, only the 
> scalable property is. That means this should be:
>   'scalable' not supported by the target so assuming 'fixed' instead.
OK. I guess it's just when the warning comes out it appears at the start of the 
line so I wanted to emphasise that this relates to the scalable property passed 
to the vectorize_width attribute (rather than other attributes) as there could 
potentially be several pragmas on one line. I think it would be good to mention 
the vectorize_width pragma/attribute somewhere in the warning message to make 
it clear. I'll see if I can reword it.


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

https://reviews.llvm.org/D89031

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

[PATCH] D90822: [X86] use macros to split GFNI intrinsics into different kinds

[Freddy, Ye via Phabricator via cfe-commits]

FreddyYe marked 3 inline comments as done.
FreddyYe added inline comments.



Comment at: clang/lib/Headers/gfniintrin.h:131-138
 #define _mm512_mask_gf2p8affine_epi64_epi8(S, U, A, B, I) \
(__m512i)__builtin_ia32_selectb_512((__mmask64)(U), 
   \
 (__v64qi)_mm512_gf2p8affine_epi64_epi8(A, B, I),   
   \
 (__v64qi)(__m512i)(S))
 
 #define _mm512_maskz_gf2p8affine_epi64_epi8(U, A, B, I) \
   (__m512i)_mm512_mask_gf2p8affine_epi64_epi8((__m512i)_mm512_setzero_si512(), 
  \

pengfei wrote:
> These 2 functions need to move to __AVX512BWINTRIN_H
Thanks for review!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90822

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

[PATCH] D90116: [clangd] Escape Unicode characters to fix Windows builds

[Ilya Golovenko via Phabricator via cfe-commits]

ilya-golovenko added a comment.

It is also possible to force MSVC to treat a certain source code files as UTF-8 
by adding the following pragma to the beginning of the file:

  #ifdef _MSVC_VER
  #pragma execution_character_set("utf-8");
  #endif


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90116

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

[PATCH] D90822: [X86] use macros to split GFNI intrinsics into different kinds

[Freddy, Ye via Phabricator via cfe-commits]

FreddyYe updated this revision to Diff 303087.
FreddyYe marked an inline comment as done.
FreddyYe added a comment.

Refine


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90822

Files:
  clang/lib/Headers/gfniintrin.h

Index: clang/lib/Headers/gfniintrin.h
===
--- clang/lib/Headers/gfniintrin.h
+++ clang/lib/Headers/gfniintrin.h
@@ -14,38 +14,56 @@
 #ifndef __GFNIINTRIN_H
 #define __GFNIINTRIN_H
 
+/* Default attributes for simple form (no masking). */
+#define __DEFAULT_FN_ATTRS __attribute__((__always_inline__, __nodebug__, __target__("gfni"), __min_vector_width__(128)))
+
+/* Default attributes for YMM unmasked form. */
+#define __DEFAULT_FN_ATTRS_Y __attribute__((__always_inline__, __nodebug__, __target__("avx,gfni"), __min_vector_width__(256)))
+
+/* Default attributes for ZMM forms. */
+#define __DEFAULT_FN_ATTRS_Z __attribute__((__always_inline__, __nodebug__, __target__("avx512bw,gfni"), __min_vector_width__(512)))
+
+/* Default attributes for VLX forms. */
+#define __DEFAULT_FN_ATTRS_VL128 __attribute__((__always_inline__, __nodebug__, __target__("avx512bw,avx512vl,gfni"), __min_vector_width__(128)))
+#define __DEFAULT_FN_ATTRS_VL256 __attribute__((__always_inline__, __nodebug__, __target__("avx512bw,avx512vl,gfni"), __min_vector_width__(256)))
 
 #define _mm_gf2p8affineinv_epi64_epi8(A, B, I) \
   (__m128i)__builtin_ia32_vgf2p8affineinvqb_v16qi((__v16qi)(__m128i)(A),  \
   (__v16qi)(__m128i)(B),  \
   (char)(I))
 
-#define _mm_mask_gf2p8affineinv_epi64_epi8(S, U, A, B, I) \
-  (__m128i)__builtin_ia32_selectb_128((__mmask16)(U), \
-(__v16qi)_mm_gf2p8affineinv_epi64_epi8(A, B, I),  \
-(__v16qi)(__m128i)(S))
-
-
-#define _mm_maskz_gf2p8affineinv_epi64_epi8(U, A, B, I) \
-  (__m128i)_mm_mask_gf2p8affineinv_epi64_epi8((__m128i)_mm_setzero_si128(),   \
-U, A, B, I)
+#define _mm_gf2p8affine_epi64_epi8(A, B, I) \
+  (__m128i)__builtin_ia32_vgf2p8affineqb_v16qi((__v16qi)(__m128i)(A), \
+  (__v16qi)(__m128i)(B),  \
+  (char)(I))
 
+static __inline__ __m128i __DEFAULT_FN_ATTRS
+_mm_gf2p8mul_epi8(__m128i __A, __m128i __B)
+{
+  return (__m128i) __builtin_ia32_vgf2p8mulb_v16qi((__v16qi) __A,
+  (__v16qi) __B);
+}
 
+#ifdef __AVXINTRIN_H
 #define _mm256_gf2p8affineinv_epi64_epi8(A, B, I) \
   (__m256i)__builtin_ia32_vgf2p8affineinvqb_v32qi((__v32qi)(__m256i)(A),  \
   (__v32qi)(__m256i)(B),  \
   (char)(I))
 
-#define _mm256_mask_gf2p8affineinv_epi64_epi8(S, U, A, B, I) \
-   (__m256i)__builtin_ia32_selectb_256((__mmask32)(U),\
-(__v32qi)_mm256_gf2p8affineinv_epi64_epi8(A, B, I),   \
-(__v32qi)(__m256i)(S))
-
-#define _mm256_maskz_gf2p8affineinv_epi64_epi8(U, A, B, I) \
-  (__m256i)_mm256_mask_gf2p8affineinv_epi64_epi8((__m256i)_mm256_setzero_si256(), \
-U, A, B, I)
+#define _mm256_gf2p8affine_epi64_epi8(A, B, I) \
+  (__m256i)__builtin_ia32_vgf2p8affineqb_v32qi((__v32qi)(__m256i)(A), \
+  (__v32qi)(__m256i)(B),  \
+  (char)(I))
 
+static __inline__ __m256i __DEFAULT_FN_ATTRS_Y
+_mm256_gf2p8mul_epi8(__m256i __A, __m256i __B)
+{
+  return (__m256i) __builtin_ia32_vgf2p8mulb_v32qi((__v32qi) __A,
+  (__v32qi) __B);
+}
+#endif /* __AVXINTRIN_H */
 
+#ifdef __AVX512BWINTRIN_H
 #define _mm512_gf2p8affineinv_epi64_epi8(A, B, I) \
   (__m512i)__builtin_ia32_vgf2p8affineinvqb_v64qi((__v64qi)(__m512i)(A),  \
   (__v64qi)(__m512i)(B),  \
@@ -60,27 +78,71 @@
   (__m512i)_mm512_mask_gf2p8affineinv_epi64_epi8((__m512i)_mm512_setzero_si512(),\
 U, A, B, I)
 
-#define _mm_gf2p8affine_epi64_epi8(A, B, I) \
-  (__m128i)__builtin_ia32_vgf2p8affineqb_v16qi((__v16qi)(__m128i)(A), \
-  (__v16qi)(__m128i)(B),  \
+#define _mm512_gf2p8affine_epi64_epi8(A, B, I) \
+  (__m512i)__builtin_ia32_vgf2p8affineqb_v64qi((__v64qi)(__m512i)(A), \
+  (__v64qi)(__m512i)(B),  \
   (char)(I))
 
+#define _mm512_mask_gf2p8affine_epi64_epi8(S, U, A, B, I) \
+   (__m512i)__builtin_ia32_selectb_512((__mmask64)(U),\
+(__v64qi)_mm512_gf2p8affine_epi64_epi8(A, B, I),  \
+  

[PATCH] D90180: [clang-tidy] find/fix unneeded semicolon after switch

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D90180#2374839 , @nickdesaulniers 
wrote:

> In D90180#2357247 , @aaron.ballman 
> wrote:
>
>> When you pass `-fix` to clang-tidy, it will apply fix-its from the compiler 
>> as well. See https://godbolt.org/z/7vzM4b and try adding a semicolon to the 
>> end of the `switch` statement and note how it's removed when recompilation 
>> happens. What's more, the frontend will generate fix-its on some compile 
>> errors as well, so passing `-fix` may generate more changes than just 
>> removing semicolons even if you disable all frontend warnings. So if I 
>> understand your use case properly, you'd want to disable all frontend 
>> warnings, run clang-tidy with just this check enabled and pass `-fix` to be 
>> able to automatically catch and fix *only* the case where there's a 
>> semicolon after a switch (and just sort of hope that fixits from compile 
>> errors are reasonable to look at). Is that any more practical of a scenario?
>
> Doesn't `-W` disable all warnings? If `-W -Wextra-semi-stmt` would only 
> warn/produce fixits related to `-Wextra-semi-stmt ` that might be feasible, 
> but it's not as easy to integrate into the Linux kernel's build system (parts 
> of the tree enable additional warnings), as compared to our current 
> clang-tidy integration (which "just works").

Thanks for the further explanation -- I was thinking of something along the 
lines of `-W -Wextra-semi-stmt` but wasn't aware of the build system 
particulars.

>> While we have a module for the Linux kernel and it's reasonable to argue 
>> that this check certainly applies there, I also think it's defensible to 
>> argue that this is a somewhat odd case that's better handled by an 
>> out-of-tree script rather than having the community carry around 
>> functionality that duplicates what the frontend already supports.
>
> I'm happy to take ownership of linuxkernel scoped clang-tidy checks, as the 
> Linux kernel maintainer for LLVM support.  Even after using this for a 
> tree-wide change, it's still useful IMO for us to automate clang-tidy runs to 
> prevent this pattern from recurring.  And anything we can do to promote LLVM 
> within the Linux kernel community, such as leveraging clang-tidy, is a huge 
> win for both projects.  And I wouldn't mind carrying checks for a brief 
> period and removing them if we find they no longer provide value.  Worst 
> case, just having the patch up on phab lets future travels find what was used 
> to make large sweeping changes and can be linked to from kernel commit 
> messages.

Thank you for volunteering! Having a primary point of contact who knows Linux 
kernel development for this module would be really helpful given the specific 
domain it's in.

>> Btw, I'd say that the whitespace is not really something we'd consider an 
>> issue -- we generally expect the user to format their code changes after 
>> applying fix-its.
>
> Heh, clang-tidy is another tool we're...hoping to promote the use of more.  
> That's it's own distinct battle.
>
> In D90180#2368604 , @aaron.ballman 
> wrote:
>
>> Given that we already have a module for Linux kernel-specific clang-tidy 
>> checks for this to live in, I can hold my nose on the fact that it's poorly 
>> replicating the frontend's work because other users won't be surprised by it 
>> (in theory). So I'll retract my disapproval; you have compelling rationale 
>> for why you want to do it this way.
>>
>> Since the plan is to produce multiple distinct checks for each extraneous 
>> semicolon situation, then I think this check should probably be renamed to 
>> something more generic and given options to control which distinct scenarios 
>> to check for.
>
> That's fair feedback.  Maybe something to note that this is more stylistic 
> and doesn't necessarily fix bugs?

I don't have strong opinions on stylistic vs not.

>> This will reduce the amount of compilation overhead for the clang-tidy 
>> project over time by not needing to introduce a new check (with new 
>> boilerplate) for each scenario but should hopefully still allow you to do 
>> what you need (with config files perhaps) in your CI. WDYT?
>
> I don't see how renaming the check changes "compilation overhead" or why we 
> think "compilation overhead" of clang tidy is a concern in this case?

I meant that if we had distinct checks `linuxkernel-switch-semi`, 
`linuxkernel-for-loop-semi`, `linuxkernel-middle-of-nowhere-semi`, etc that 
each one of those checks would require their own header file, source file, test 
files, documentation, etc. whereas if we had a single check, we'd reduce that 
overhead by only having one header, one source, one documentation, etc using 
config options, which makes fetching or building clang-tidy go ever-so-slightly 
faster.

> Maybe clarifying what you would prefer to see the check called and whether it 
> would be i

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

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/Attr.td:1435
+  let Spellings = [GCC<"leaf">];
+  let Subjects = SubjectList<[Function]>;
+  let Documentation = [Undocumented];

gulfem wrote:
> aaron.ballman wrote:
> > gulfem wrote:
> > > aaron.ballman wrote:
> > > > Should this attribute also be supported on things like ObjC method 
> > > > decls or other function-like interfaces?
> > > Do I need to do anything else to support this attribute in Objective-C as 
> > > well?
> > > I think we should support it in all the C languages family.
> > >I think we should support it in all the C languages family.
> > 
> > That's already happening automatically -- there's a C and C++ spelling 
> > available for it and the attribute doesn't specify that it requires a 
> > particular language mode or target.
> > 
> > > Do I need to do anything else to support this attribute in Objective-C as 
> > > well?
> > You can add multiple subjects to the list here, so you can have this apply 
> > to `Function, ObjCMethod` for both of those. Another one to consider is 
> > whether this attribute can be written on a block declaration (like a 
> > lambda, but with different syntax). Beyond that, it's mostly just 
> > documentation, devising the test cases to ensure the ObjC functionality 
> > behaves as expected, possibly some codegen changes, etc.
> AFAIK, users can specify function attributes in lambda expressions.
> Lambda functions can only be accessed/called by the functions in the same 
> translation unit, right?
> Leaf attribute does not have any effect on the functions that are defined in 
> the same translation unit.
> For this reason, I'm thinking that leaf attribute would not have any effect 
> if they are used in lambda expressions.
> Do you agree with me?
> AFAIK, users can specify function attributes in lambda expressions.

I always forget that you can do that for declaration attributes using GNU-style 
syntax...

> Lambda functions can only be accessed/called by the functions in the same 
> translation unit, right?

Not necessarily, you could pass one across TU boundaries like a function 
pointer, for instance. e.g.,
```
// TU1.cpp
void foo() {
  auto l = []() { ... };
  bar(l);
}

// TU2.cpp
void bar(auto func) {
  func();
}
```



Comment at: clang/include/clang/Basic/AttrDocs.td:3910
+in library functions. Functions marked with the ``leaf`` attribute are not 
allowed
+to jump back into the caller's translation unit, whether through invoking a
+callback function, a direct external function call, use of ``longjmp``, or 
other means.

gulfem wrote:
> aaron.ballman wrote:
> > gulfem wrote:
> > > I think this property is transitive. 
> > > If a leaf function somehow enters into caller's translation unit (either 
> > > via direct call or a via its call chain), it will violate the rule that 
> > > says "Calls to external functions with this attribute must return to the 
> > > current compilation unit only by return or by exception handling". 
> > > Entering via its call chain is not a return or an exception handling.
> > > Do you agree with that?
> > > I think this property is transitive. ... Do you agree with that?
> > 
> > That makes sense to me! I think I'd recommend a slight modification to the 
> > docs then:
> > 
> > ```
> > Functions marked with the ``leaf`` attribute are not allowed to jump back 
> > into the caller's translation unit, whether through invoking a callback 
> > function, a direct, possibly transitive, external function call, use of 
> > ``longjmp``, or other means.
> > ```
> > The last question is: by "direct" does the GCC docs imply that calls back 
> > to the caller's TU through a function *pointer* are not UB? I'd imagine 
> > those would also be bad, but I'd like to make sure (and perhaps we can 
> > remove the `direct` from the wording if calls through function pointers are 
> > disallowed).
> I think the idea is that the control-flow should never come back to the 
> caller's translation unit by any kind of control-flow changing mechanism 
> (direct/indirect and call/jump).
> The compiler might use this hint to do optimizations based on that 
> assumption, so the user should ensure that.
> Could you please explain what do you mean by calling back via function 
> pointer?
> I thought that callback function is basically calling back via a function 
> pointer. 
> Could you please explain what do you mean by calling back via function 
> pointer?
> I thought that callback function is basically calling back via a function 
> pointer.

I had confused myself -- I think @jdoerfert answered my confusion in an earlier 
comment and I just wasn't thinking about that case hard enough. I think we want 
to drop the word "direct" from "external function call" because it doesn't 
matter whether the user says:
```
void bar(void); // Assume calling this is bad
bar();
```
and
```
void bar(void); // Assume calling this is ba

[PATCH] D90714: [clang]Fix length threshold for MicrosoftMangle md5 hash

[Melanie Blower via Phabricator via cfe-commits]

mibintc added a comment.

In D90714#2374913 , @dblaikie wrote:

> Since the same code is used to mangle all these things, probably just test 
> one of them?
>
> Could use macros to stamp out longer names without having to write them out 
> manually?

Not sure what technique to use to stamp out longer names, I tried using token 
pasting but that doesn't work because the tokens aren't macro expanded before 
pasting?  I like the test source I added because it came from a program seen in 
the wild, and it demonstrates that reasonable length identifiers can generate 
enormous mangled names.
#define X50 xx
#define X45 x
#define X100 X50 ## X50  // X100 is X50X50


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90714

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

[PATCH] D90765: [ARM][AArch64] Adding Neoverse V1 CPU support

[Lucas Prates via Phabricator via cfe-commits]

pratlucas updated this revision to Diff 303091.
pratlucas added a comment.

Addressing comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90765

Files:
  clang/test/Driver/aarch64-cpus.c
  clang/test/Driver/arm-cortex-cpus.c
  llvm/include/llvm/MC/SubtargetFeature.h
  llvm/include/llvm/Support/AArch64TargetParser.def
  llvm/include/llvm/Support/ARMTargetParser.def
  llvm/lib/Target/AArch64/AArch64.td
  llvm/lib/Target/AArch64/AArch64Subtarget.cpp
  llvm/lib/Target/AArch64/AArch64Subtarget.h
  llvm/lib/Target/ARM/ARM.td
  llvm/lib/Target/ARM/ARMSubtarget.cpp
  llvm/lib/Target/ARM/ARMSubtarget.h
  llvm/test/CodeGen/AArch64/cpus.ll
  llvm/unittests/Support/TargetParserTest.cpp

Index: llvm/unittests/Support/TargetParserTest.cpp
===
--- llvm/unittests/Support/TargetParserTest.cpp
+++ llvm/unittests/Support/TargetParserTest.cpp
@@ -274,6 +274,12 @@
  ARM::AEK_HWDIVARM | ARM::AEK_HWDIVTHUMB |
  ARM::AEK_DSP | ARM::AEK_CRC | ARM::AEK_RAS,
  "8.2-A"));
+  EXPECT_TRUE(testARMCPU("neoverse-v1", "armv8.4-a", "crypto-neon-fp-armv8",
+ ARM::AEK_SEC | ARM::AEK_MP | ARM::AEK_VIRT |
+ ARM::AEK_HWDIVARM | ARM::AEK_HWDIVTHUMB |
+ ARM::AEK_DSP | ARM::AEK_CRC | ARM::AEK_RAS |
+ ARM::AEK_DOTPROD,
+ "8.4-A"));
   EXPECT_TRUE(testARMCPU("neoverse-n1", "armv8.2-a", "crypto-neon-fp-armv8",
 ARM::AEK_CRC | ARM::AEK_SEC | ARM::AEK_MP |
 ARM::AEK_VIRT | ARM::AEK_HWDIVARM |
@@ -322,7 +328,7 @@
  "7-S"));
 }
 
-static constexpr unsigned NumARMCPUArchs = 89;
+static constexpr unsigned NumARMCPUArchs = 90;
 
 TEST(TargetParserTest, testARMCPUArchList) {
   SmallVector List;
@@ -881,6 +887,14 @@
   AArch64::AEK_LSE | AArch64::AEK_FP16 | AArch64::AEK_DOTPROD |
   AArch64::AEK_RCPC | AArch64::AEK_SSBS,
   "8.2-A"));
+  EXPECT_TRUE(testAArch64CPU(
+  "neoverse-v1", "armv8.4-a", "crypto-neon-fp-armv8",
+  AArch64::AEK_RAS | AArch64::AEK_SVE | AArch64::AEK_SSBS |
+  AArch64::AEK_RCPC | AArch64::AEK_CRC | AArch64::AEK_FP |
+  AArch64::AEK_SIMD | AArch64::AEK_RAS | AArch64::AEK_LSE |
+  AArch64::AEK_RDM | AArch64::AEK_RCPC | AArch64::AEK_DOTPROD |
+  AArch64::AEK_CRYPTO,
+  "8.4-A"));
   EXPECT_TRUE(testAArch64CPU(
  "cortex-r82", "armv8-r", "crypto-neon-fp-armv8",
   AArch64::AEK_CRC | AArch64::AEK_RDM  | AArch64::AEK_SSBS|
@@ -1034,7 +1048,7 @@
   "8.2-A"));
 }
 
-static constexpr unsigned NumAArch64CPUArchs = 43;
+static constexpr unsigned NumAArch64CPUArchs = 44;
 
 TEST(TargetParserTest, testAArch64CPUArchList) {
   SmallVector List;
Index: llvm/test/CodeGen/AArch64/cpus.ll
===
--- llvm/test/CodeGen/AArch64/cpus.ll
+++ llvm/test/CodeGen/AArch64/cpus.ll
@@ -20,6 +20,7 @@
 ; RUN: llc < %s -mtriple=arm64-unknown-unknown -mcpu=cortex-x1 2>&1 | FileCheck %s
 ; RUN: llc < %s -mtriple=arm64-unknown-unknown -mcpu=neoverse-e1 2>&1 | FileCheck %s
 ; RUN: llc < %s -mtriple=arm64-unknown-unknown -mcpu=neoverse-n1 2>&1 | FileCheck %s
+; RUN: llc < %s -mtriple=arm64-unknown-unknown -mcpu=neoverse-v1 2>&1 | FileCheck %s
 ; RUN: llc < %s -mtriple=arm64-unknown-unknown -mcpu=exynos-m3 2>&1 | FileCheck %s
 ; RUN: llc < %s -mtriple=arm64-unknown-unknown -mcpu=exynos-m4 2>&1 | FileCheck %s
 ; RUN: llc < %s -mtriple=arm64-unknown-unknown -mcpu=exynos-m5 2>&1 | FileCheck %s
Index: llvm/lib/Target/ARM/ARMSubtarget.h
===
--- llvm/lib/Target/ARM/ARMSubtarget.h
+++ llvm/lib/Target/ARM/ARMSubtarget.h
@@ -76,6 +76,7 @@
 Krait,
 Kryo,
 NeoverseN1,
+NeoverseV1,
 Swift
   };
   enum ARMProcClassEnum {
Index: llvm/lib/Target/ARM/ARMSubtarget.cpp
===
--- llvm/lib/Target/ARM/ARMSubtarget.cpp
+++ llvm/lib/Target/ARM/ARMSubtarget.cpp
@@ -314,6 +314,7 @@
 PreISelOperandLatencyAdjustment = 1;
 break;
   case NeoverseN1:
+  case NeoverseV1:
 break;
   case Swift:
 MaxInterleaveFactor = 2;
Index: llvm/lib/Target/ARM/ARM.td
===
--- llvm/lib/Target/ARM/ARM.td
+++ llvm/lib/Target/ARM/ARM.td
@@ -601,6 +601,9 @@
 def ProcX1  : SubtargetFeature<"cortex-x1", "ARMProcFamily", "CortexX1",
"Cortex-X1 ARM processors", []>;
 
+def ProcV1  : SubtargetFeature<"neoverse-v1", "ARMProcFamily",
+   "NeoverseV1", "Neoverse-V1 ARM processors", []>;
+
 def ProcKrait   : SubtargetFeature<"krait", "ARMProcFamily", "Krait",
"Qualcomm Kr

[PATCH] D90832: [clang-tidy] Extend IdentifierNamingCheck per file config

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Is there a way to test this functionality out?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90832

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

[PATCH] D82317: [Clang/Test]: Update tests where `noundef` attribute is necessary

[Juneyoung Lee via Phabricator via cfe-commits]

aqjune added a comment.
Herald added a subscriber: frasercrmck.

In D82317#2201215 , @rjmccall wrote:

> second, it's yet another contribution towards the giant pile of attributes 
> that seem to have become necessary to do any work in LLVM

I don't think this is true. There are a few optimizations disabled (either 
fully or conditionally) because it is incorrect when its input is undefined 
(D85765 , D85684 
, a few optimizations in SimplifyCFG). There 
are even optimizations that are incorrect w.r.t. undef but still running simply 
because removing all of them isn't practical.
Giving a guarantee that a value is well defined is very helpful because these 
optimizations can be revived.
Currently, there is no such guarantee in function boundaries because it is 
legal to pass undef to a function argument. This explains dead argument 
elimination and function outlining (which may introduce fn call with undef).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82317

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

[PATCH] D90832: [clang-tidy] Extend IdentifierNamingCheck per file config

[Nathan James via Phabricator via cfe-commits]

njames93 added a comment.

In D90832#2375934 , @aaron.ballman 
wrote:

> Is there a way to test this functionality out?

There's already tests for loading the individual styles from other files, I'm 
sure I could extend that


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90832

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

[PATCH] D90849: [dllexport] Avoid multiple codegen assert for explicitly defaulted methods in explicit instantiation definitions (PR47683)

[Hans Wennborg via Phabricator via cfe-commits]

hans created this revision.
hans added a reviewer: rnk.
Herald added a project: clang.
hans requested review of this revision.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D90849

Files:
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/test/CodeGenCXX/dllexport.cpp


Index: clang/test/CodeGenCXX/dllexport.cpp
===
--- clang/test/CodeGenCXX/dllexport.cpp
+++ clang/test/CodeGenCXX/dllexport.cpp
@@ -915,6 +915,26 @@
 // M32-DAG: define dso_local x86_thiscallcc void 
@"??$baz@H@?$ExportedClassTemplate2@H@pr34849@@QAEXXZ"
 }
 
+namespace pr47683 {
+struct X { X() {} };
+
+template  struct S {
+  S() = default;
+  X x;
+};
+template struct __declspec(dllexport) S;
+// M32-DAG: define weak_odr dso_local dllexport x86_thiscallcc 
%"struct.pr47683::S"* @"??0?$S@H@pr47683@@QAE@XZ"
+
+template  struct T {
+  T() = default;
+  X x;
+};
+extern template struct T;
+template struct __declspec(dllexport) T;
+// Don't assert about multiple codegen for explicitly defaulted method in 
explicit instantiation def.
+// M32-DAG: define weak_odr dso_local dllexport x86_thiscallcc 
%"struct.pr47683::T"* @"??0?$T@H@pr47683@@QAE@XZ"
+}
+
 
//===--===//
 // Classes with template base classes
 
//===--===//
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -5904,9 +5904,14 @@
 // an operator can be taken and should compare equal across libraries.
 S.MarkFunctionReferenced(Class->getLocation(), MD);
 
-// There is no later point when we will see the definition of this
-// function, so pass it to the consumer now.
-S.Consumer.HandleTopLevelDecl(DeclGroupRef(MD));
+if (MD->isExplicitlyDefaulted() &&
+TSK == TSK_ExplicitInstantiationDefinition) {
+  // MD will get passed to the consumer as part of instantiation.
+} else {
+  // There is no later point when we will see the definition of this
+  // function, so pass it to the consumer now.
+  S.Consumer.HandleTopLevelDecl(DeclGroupRef(MD));
+}
   }
 }
   }


Index: clang/test/CodeGenCXX/dllexport.cpp
===
--- clang/test/CodeGenCXX/dllexport.cpp
+++ clang/test/CodeGenCXX/dllexport.cpp
@@ -915,6 +915,26 @@
 // M32-DAG: define dso_local x86_thiscallcc void @"??$baz@H@?$ExportedClassTemplate2@H@pr34849@@QAEXXZ"
 }
 
+namespace pr47683 {
+struct X { X() {} };
+
+template  struct S {
+  S() = default;
+  X x;
+};
+template struct __declspec(dllexport) S;
+// M32-DAG: define weak_odr dso_local dllexport x86_thiscallcc %"struct.pr47683::S"* @"??0?$S@H@pr47683@@QAE@XZ"
+
+template  struct T {
+  T() = default;
+  X x;
+};
+extern template struct T;
+template struct __declspec(dllexport) T;
+// Don't assert about multiple codegen for explicitly defaulted method in explicit instantiation def.
+// M32-DAG: define weak_odr dso_local dllexport x86_thiscallcc %"struct.pr47683::T"* @"??0?$T@H@pr47683@@QAE@XZ"
+}
+
 //===--===//
 // Classes with template base classes
 //===--===//
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -5904,9 +5904,14 @@
 // an operator can be taken and should compare equal across libraries.
 S.MarkFunctionReferenced(Class->getLocation(), MD);
 
-// There is no later point when we will see the definition of this
-// function, so pass it to the consumer now.
-S.Consumer.HandleTopLevelDecl(DeclGroupRef(MD));
+if (MD->isExplicitlyDefaulted() &&
+TSK == TSK_ExplicitInstantiationDefinition) {
+  // MD will get passed to the consumer as part of instantiation.
+} else {
+  // There is no later point when we will see the definition of this
+  // function, so pass it to the consumer now.
+  S.Consumer.HandleTopLevelDecl(DeclGroupRef(MD));
+}
   }
 }
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D90832: [clang-tidy] Extend IdentifierNamingCheck per file config

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D90832#2376009 , @njames93 wrote:

> In D90832#2375934 , @aaron.ballman 
> wrote:
>
>> Is there a way to test this functionality out?
>
> There's already tests for loading the individual styles from other files, I'm 
> sure I could extend that

I'd appreciate that, otherwise the changes here all seem reasonable to me so 
far (though if you wanted to split the formatting changes out into an NFC, 
those don't even require a review).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90832

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

[clang] 659f4bd - [clang] Add an option for hiding line numbers in diagnostics

[Raphael Isemann via cfe-commits]

Author: Raphael Isemann
Date: 2020-11-05T16:10:18+01:00
New Revision: 659f4bd87efc7cae379aa128814e03fc8b006471

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

LOG: [clang] Add an option for hiding line numbers in diagnostics

Clang offers a `-f[no]-show-column` flag for hiding the column numbers when
printing diagnostics but there is no option for doing the same with line
numbers.

In LLDB having this option would be useful, as LLDB sometimes only knows the
file name for a SourceLocation and just assigns it the dummy line/column `1:1`.
These fake line/column numbers are confusing to the user and LLDB should be able
to tell clang to hide *both* the column and the line number when rendering text
diagnostics.

This patch adds a flag for also hiding the line numbers. It's not exposed via
the command line flags as it's most likely not very useful for any user and can
lead to ambiguous output when the user decides to only hide either the line or
the column number (where `file:1: ...` could now refer to both line 1 or column
1 depending on the compiler flags). LLDB can just access the DiagnosticOptions
directly when constructing its internal Clang instance.

The effect doesn't apply to Vi/MSVC style diagnostics because it's not defined
how these diagnostic styles would show an omitted line number (MSVC doesn't have
such an option and Vi's line mode is theory only supporting line numbers if I
understand it correctly).

Reviewed By: thakis, MaskRay

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

Added: 
clang/unittests/Frontend/TextDiagnosticTest.cpp

Modified: 
clang/include/clang/Basic/DiagnosticOptions.def
clang/lib/Frontend/TextDiagnostic.cpp
clang/unittests/Frontend/CMakeLists.txt

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticOptions.def 
b/clang/include/clang/Basic/DiagnosticOptions.def
index a946b5c6be8e..927710a0cb9a 100644
--- a/clang/include/clang/Basic/DiagnosticOptions.def
+++ b/clang/include/clang/Basic/DiagnosticOptions.def
@@ -47,6 +47,7 @@ SEMANTIC_DIAGOPT(IgnoreWarnings, 1, 0)   /// -w
 DIAGOPT(NoRewriteMacros, 1, 0)  /// -Wno-rewrite-macros
 DIAGOPT(Pedantic, 1, 0) /// -pedantic
 DIAGOPT(PedanticErrors, 1, 0)   /// -pedantic-errors
+DIAGOPT(ShowLine, 1, 1) /// Show line number on diagnostics.
 DIAGOPT(ShowColumn, 1, 1)   /// Show column number on diagnostics.
 DIAGOPT(ShowLocation, 1, 1) /// Show source location information.
 DIAGOPT(ShowLevel, 1, 1)/// Show diagnostic level.

diff  --git a/clang/lib/Frontend/TextDiagnostic.cpp 
b/clang/lib/Frontend/TextDiagnostic.cpp
index 78acaaf9f96e..e781fd2c0229 100644
--- a/clang/lib/Frontend/TextDiagnostic.cpp
+++ b/clang/lib/Frontend/TextDiagnostic.cpp
@@ -827,7 +827,10 @@ void TextDiagnostic::emitDiagnosticLoc(FullSourceLoc Loc, 
PresumedLoc PLoc,
 
   emitFilename(PLoc.getFilename(), Loc.getManager());
   switch (DiagOpts->getFormat()) {
-  case DiagnosticOptions::Clang: OS << ':'  << LineNo; break;
+  case DiagnosticOptions::Clang:
+if (DiagOpts->ShowLine)
+  OS << ':' << LineNo;
+break;
   case DiagnosticOptions::MSVC:  OS << '('  << LineNo; break;
   case DiagnosticOptions::Vi:OS << " +" << LineNo; break;
   }

diff  --git a/clang/unittests/Frontend/CMakeLists.txt 
b/clang/unittests/Frontend/CMakeLists.txt
index d247089e9295..3c25b43e9530 100644
--- a/clang/unittests/Frontend/CMakeLists.txt
+++ b/clang/unittests/Frontend/CMakeLists.txt
@@ -12,6 +12,7 @@ add_clang_unittest(FrontendTests
   ParsedSourceLocationTest.cpp
   PCHPreambleTest.cpp
   OutputStreamTest.cpp
+  TextDiagnosticTest.cpp
   )
 clang_target_link_libraries(FrontendTests
   PRIVATE

diff  --git a/clang/unittests/Frontend/TextDiagnosticTest.cpp 
b/clang/unittests/Frontend/TextDiagnosticTest.cpp
new file mode 100644
index ..1e05104d9388
--- /dev/null
+++ b/clang/unittests/Frontend/TextDiagnosticTest.cpp
@@ -0,0 +1,100 @@
+//===- unittests/Frontend/TextDiagnosticTest.cpp - 
===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang/Frontend/TextDiagnostic.h"
+#include "clang/Basic/FileManager.h"
+#include "clang/Basic/LangOptions.h"
+#include "clang/Basic/SourceManager.h"
+#include "llvm/Support/SmallVectorMemoryBuffer.h"
+#include "gtest/gtest.h"
+
+using namespace llvm;
+using namespace clang;
+
+namespace {
+
+/// Prints a diagnostic with the given DiagnosticOptions and the given
+/// SourceLocation and returns the printed diagnostic text.
+static std::string PrintDiag(const Diagnos

[PATCH] D83038: [clang] Add an option for hiding line numbers in diagnostics

[Raphael Isemann via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG659f4bd87efc: [clang] Add an option for hiding line numbers 
in diagnostics (authored by teemperor).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83038

Files:
  clang/include/clang/Basic/DiagnosticOptions.def
  clang/lib/Frontend/TextDiagnostic.cpp
  clang/unittests/Frontend/CMakeLists.txt
  clang/unittests/Frontend/TextDiagnosticTest.cpp

Index: clang/unittests/Frontend/TextDiagnosticTest.cpp
===
--- /dev/null
+++ clang/unittests/Frontend/TextDiagnosticTest.cpp
@@ -0,0 +1,100 @@
+//===- unittests/Frontend/TextDiagnosticTest.cpp - ===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang/Frontend/TextDiagnostic.h"
+#include "clang/Basic/FileManager.h"
+#include "clang/Basic/LangOptions.h"
+#include "clang/Basic/SourceManager.h"
+#include "llvm/Support/SmallVectorMemoryBuffer.h"
+#include "gtest/gtest.h"
+
+using namespace llvm;
+using namespace clang;
+
+namespace {
+
+/// Prints a diagnostic with the given DiagnosticOptions and the given
+/// SourceLocation and returns the printed diagnostic text.
+static std::string PrintDiag(const DiagnosticOptions &Opts, FullSourceLoc Loc) {
+  std::string Out;
+  llvm::raw_string_ostream OS(Out);
+  clang::LangOptions LangOpts;
+  // Owned by TextDiagnostic.
+  DiagnosticOptions *DiagOpts = new DiagnosticOptions(Opts);
+  TextDiagnostic Diag(OS, LangOpts, DiagOpts);
+  // Emit a dummy diagnostic that is just 'message'.
+  Diag.emitDiagnostic(Loc, DiagnosticsEngine::Level::Warning, "message",
+  /*Ranges=*/{}, /*FixItHints=*/{});
+  OS.flush();
+  return Out;
+}
+
+TEST(TextDiagnostic, ShowLine) {
+  // Create dummy FileManager and SourceManager.
+  FileSystemOptions FSOpts;
+  FileManager FileMgr(FSOpts);
+  IntrusiveRefCntPtr DiagID(new DiagnosticIDs);
+  DiagnosticsEngine DiagEngine(DiagID, new DiagnosticOptions,
+   new IgnoringDiagConsumer());
+  SourceManager SrcMgr(DiagEngine, FileMgr);
+
+  // Create a dummy file with some contents to produce a test SourceLocation.
+  const llvm::StringRef file_path = "main.cpp";
+  const llvm::StringRef main_file_contents = "some\nsource\ncode\n";
+  const clang::FileEntry &fe = *FileMgr.getVirtualFile(
+  file_path,
+  /*Size=*/static_cast(main_file_contents.size()),
+  /*ModificationTime=*/0);
+
+  llvm::SmallVector buffer;
+  buffer.append(main_file_contents.begin(), main_file_contents.end());
+  auto file_contents = std::make_unique(
+  std::move(buffer), file_path);
+  SrcMgr.overrideFileContents(&fe, std::move(file_contents));
+
+  // Create the actual file id and use it as the main file.
+  clang::FileID fid =
+  SrcMgr.createFileID(&fe, SourceLocation(), clang::SrcMgr::C_User);
+  SrcMgr.setMainFileID(fid);
+
+  // Create the source location for the test diagnostic.
+  FullSourceLoc Loc(SrcMgr.translateLineCol(fid, /*Line=*/1, /*Col=*/2),
+SrcMgr);
+
+  DiagnosticOptions DiagOpts;
+  DiagOpts.ShowLine = true;
+  DiagOpts.ShowColumn = true;
+  // Hide printing the source line/caret to make the diagnostic shorter and it's
+  // not relevant for this test.
+  DiagOpts.ShowCarets = false;
+  EXPECT_EQ("main.cpp:1:2: warning: message\n", PrintDiag(DiagOpts, Loc));
+
+  // Check that ShowLine doesn't influence the Vi/MSVC diagnostic formats as its
+  // a Clang-specific diagnostic option.
+  DiagOpts.setFormat(TextDiagnosticFormat::Vi);
+  DiagOpts.ShowLine = false;
+  EXPECT_EQ("main.cpp +1:2: warning: message\n", PrintDiag(DiagOpts, Loc));
+
+  DiagOpts.setFormat(TextDiagnosticFormat::MSVC);
+  DiagOpts.ShowLine = false;
+  EXPECT_EQ("main.cpp(1,2): warning: message\n", PrintDiag(DiagOpts, Loc));
+
+  // Reset back to the Clang format.
+  DiagOpts.setFormat(TextDiagnosticFormat::Clang);
+
+  // Hide line number but show column.
+  DiagOpts.ShowLine = false;
+  EXPECT_EQ("main.cpp:2: warning: message\n", PrintDiag(DiagOpts, Loc));
+
+  // Show line number but hide column.
+  DiagOpts.ShowLine = true;
+  DiagOpts.ShowColumn = false;
+  EXPECT_EQ("main.cpp:1: warning: message\n", PrintDiag(DiagOpts, Loc));
+}
+
+} // anonymous namespace
Index: clang/unittests/Frontend/CMakeLists.txt
===
--- clang/unittests/Frontend/CMakeLists.txt
+++ clang/unittests/Frontend/CMakeLists.txt
@@ -12,6 +12,7 @@
   ParsedSourceLocationTest.cpp
   PCHPreambleTest.cpp
   OutputStreamTest.cpp
+  TextDiagnosticTe

[PATCH] D90802: [OpenMP] [DOCS] Update OMP5.1 feature status table [NFC]

[Deepak Eachempati via Phabricator via cfe-commits]

dreachem added inline comments.



Comment at: clang/docs/OpenMPSupport.rst:343
++--+--+--+---+
+| misc extension   | user-defined function variants with #ifdef 
protection| :part:`worked on`| D71179   
 |
++--+--+--+---+

jdoerfert wrote:
> What is missing here?
This is from the original table. Is this referring to begin/end declare variant 
feature, which I also added? If so, I should remove that one. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90802

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

[PATCH] D90851: [clang-tidy] Extending bugprone-signal-handler with POSIX functions.

[Balázs Kéri via Phabricator via cfe-commits]

balazske created this revision.
Herald added subscribers: cfe-commits, martong, gamesh411, Szelethus, dkrupp, 
xazax.hun, whisperity.
Herald added a project: clang.
balazske requested review of this revision.

An option is added to the check to select wich set of functions is
defined as asynchronous-safe functions.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D90851

Files:
  clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.h
  clang-tools-extra/docs/clang-tidy/checks/bugprone-signal-handler.rst
  clang-tools-extra/test/clang-tidy/checkers/Inputs/Headers/signal.h
  clang-tools-extra/test/clang-tidy/checkers/Inputs/Headers/stdlib.h
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/Headers/system-header-posix-api.h
  clang-tools-extra/test/clang-tidy/checkers/Inputs/Headers/system-other.h
  clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler-minimal.c
  clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler-posix.c
  clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler.c

Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler.c
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler.c
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler.c
@@ -1,8 +1,8 @@
-// RUN: %check_clang_tidy %s cert-sig30-c %t -- -- -isystem %S/Inputs/Headers
+// RUN: %check_clang_tidy %s bugprone-signal-handler %t -- -- -isystem %S/Inputs/Headers
 
-#include "signal.h"
 #include "stdio.h"
-#include "stdlib.h"
+#include "system-header-posix-api.h"
+#include "system-other.h"
 
 // The function should be classified as system call even if there is
 // declaration the in source file.
@@ -16,17 +16,9 @@
   abort();
 }
 
-void handler__Exit(int) {
-  _Exit(0);
-}
-
-void handler_quick_exit(int) {
-  quick_exit(0);
-}
-
 void handler_other(int) {
   printf("1234");
-  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [cert-sig30-c]
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
 }
 
 void handler_signal(int) {
@@ -40,7 +32,7 @@
 
 void f_bad() {
   printf("1234");
-  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [cert-sig30-c]
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
 }
 
 void f_extern();
@@ -55,13 +47,11 @@
 
 void handler_extern(int) {
   f_extern();
-  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'f_extern' may not be asynchronous-safe; calling it from a signal handler may be dangerous [cert-sig30-c]
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'f_extern' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
 }
 
 void test() {
   signal(SIGINT, handler_abort);
-  signal(SIGINT, handler__Exit);
-  signal(SIGINT, handler_quick_exit);
   signal(SIGINT, handler_signal);
   signal(SIGINT, handler_other);
 
@@ -69,9 +59,9 @@
   signal(SIGINT, handler_bad);
   signal(SIGINT, handler_extern);
 
-  signal(SIGINT, quick_exit);
+  signal(SIGINT, _Exit);
   signal(SIGINT, other_call);
-  // CHECK-MESSAGES: :[[@LINE-1]]:18: warning: 'other_call' may not be asynchronous-safe; calling it from a signal handler may be dangerous [cert-sig30-c]
+  // CHECK-MESSAGES: :[[@LINE-1]]:18: warning: 'other_call' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
 
   signal(SIGINT, SIG_IGN);
   signal(SIGINT, SIG_DFL);
Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler-posix.c
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-signal-handler-posix.c
@@ -0,0 +1,36 @@
+// RUN: %check_clang_tidy %s bugprone-signal-handler %t \
+// RUN: -config='{CheckOptions: \
+// RUN:  [{key: bugprone-signal-handler.AsyncSafeFunctionSet, value: "POSIX"}]}' \
+// RUN: -- -isystem %S/Inputs/Headers
+
+#include "stdio.h"
+#include "system-header-posix-api.h"
+
+void handler_bad1(int) {
+  printf("1234");
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+}
+
+void handler_bad2(int) {
+  quick_exit(0);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: 'quick_exit' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+}
+
+void handler_good1(int) {
+  _exit(0);
+  accept(1, 0, 0);
+  write(0, 0, 0);
+}
+
+void handler_good2(int) {
+  abort();
+  _Exit(0);
+  signal

[PATCH] D90851: [clang-tidy] Extending bugprone-signal-handler with POSIX functions.

[Eugene Zelenko via Phabricator via cfe-commits]

Eugene.Zelenko added inline comments.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/bugprone-signal-handler.rst:31
+  is not included). Default is ``POSIX``.
\ No newline at end of file


Please add newline.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90851

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

[PATCH] D90174: [HIP] Fix regressions due to fp contract change

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

@rjmccall ping. Any further concerns for this patch? Thanks.


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

https://reviews.llvm.org/D90174

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

[PATCH] D90634: Implement Lambda Conversion Operators for All CCs for MSVC.

[Erich Keane via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG6b104ea4b463: Implement Lambda Conversion Operators for All 
CCs for MSVC. (authored by erichkeane).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90634

Files:
  clang/lib/Sema/SemaLambda.cpp
  clang/test/CodeGenCXX/lambda-conversion-op-cc.cpp

Index: clang/test/CodeGenCXX/lambda-conversion-op-cc.cpp
===
--- clang/test/CodeGenCXX/lambda-conversion-op-cc.cpp
+++ clang/test/CodeGenCXX/lambda-conversion-op-cc.cpp
@@ -1,6 +1,6 @@
 // RUN: %clang_cc1 -emit-llvm %s -o - -triple=x86_64-linux-gnu | FileCheck %s --check-prefixes=CHECK,LIN64
 // RUN: %clang_cc1 -emit-llvm %s -o - -triple=x86_64-linux-gnu -DCC="__attribute__((vectorcall))" | FileCheck %s --check-prefixes=CHECK,VECCALL
-// RUN: %clang_cc1 -emit-llvm %s -o - -triple=i386-windows-pc -DWIN32 | FileCheck %s --check-prefixes=WIN32
+// RUN: %clang_cc1 -emit-llvm %s -o - -fms-compatibility -triple=i386-windows-pc -DWIN32 | FileCheck %s --check-prefixes=WIN32
 
 #ifndef CC
 #define CC
@@ -10,20 +10,36 @@
   auto lambda = [](int i, float f, double d) CC { return i + f + d; };
 
   double (*CC fp)(int, float, double) = lambda;
-  fp(0, 1.1, 2.2);
 #ifdef WIN32
   double (*__attribute__((thiscall)) fp2)(int, float, double) = lambda;
+  double (*__attribute__((stdcall)) fp3)(int, float, double) = lambda;
+  double (*__attribute__((fastcall)) fp4)(int, float, double) = lambda;
+  double (*__attribute__((vectorcall)) fp5)(int, float, double) = lambda;
+#endif // WIN32
+  fp(0, 1.1, 2.2);
+#ifdef WIN32
   fp2(0, 1.1, 2.2);
+  fp3(0, 1.1, 2.2);
+  fp4(0, 1.1, 2.2);
+  fp5(0, 1.1, 2.2);
 #endif // WIN32
+
+  auto x = +lambda;
 }
 
-// void usage function, calls convrsion operator.
+// void usage function, calls conversion operator.
 // LIN64: define void @_Z5usagev()
 // VECCALL: define void @_Z5usagev()
 // WIN32: define dso_local void @"?usage@@YAXXZ"()
 // CHECK: call double (i32, float, double)* @"_ZZ5usagevENK3$_0cvPFdifdEEv"
 // WIN32: call x86_thiscallcc double (i32, float, double)* @"??B@?0??usage@@YAXXZ@QBEP6A?A?@@HMN@ZXZ"
 // WIN32: call x86_thiscallcc double (i32, float, double)* @"??B@?0??usage@@YAXXZ@QBEP6E?A?@@HMN@ZXZ"
+// WIN32: call x86_thiscallcc double (i32, float, double)* @"??B@?0??usage@@YAXXZ@QBEP6G?A?@@HMN@ZXZ"
+// WIN32: call x86_thiscallcc double (i32, float, double)* @"??B@?0??usage@@YAXXZ@QBEP6I?A?@@HMN@ZXZ"
+// WIN32: call x86_thiscallcc double (i32, float, double)* @"??B@?0??usage@@YAXXZ@QBEP6Q?A?@@HMN@ZXZ"
+// Operator+ calls 'default' calling convention.
+// CHECK: call double (i32, float, double)* @"_ZZ5usagevENK3$_0cvPFdifdEEv"
+// WIN32: call x86_thiscallcc double (i32, float, double)* @"??B@?0??usage@@YAXXZ@QBEP6A?A?@@HMN@ZXZ"
 //
 // Conversion operator, returns __invoke.
 // CHECK: define internal double (i32, float, double)* @"_ZZ5usagevENK3$_0cvPFdifdEEv"
@@ -32,6 +48,12 @@
 // WIN32: ret double (i32, float, double)* @"?__invoke@@?0??usage@@YAXXZ@CA?A?@@HMN@Z"
 // WIN32: define internal x86_thiscallcc double (i32, float, double)* @"??B@?0??usage@@YAXXZ@QBEP6E?A?@@HMN@ZXZ"
 // WIN32: ret double (i32, float, double)* @"?__invoke@@?0??usage@@YAXXZ@CE?A?@@HMN@Z"
+// WIN32: define internal x86_thiscallcc double (i32, float, double)* @"??B@?0??usage@@YAXXZ@QBEP6G?A?@@HMN@ZXZ"
+// WIN32: ret double (i32, float, double)* @"?__invoke@@?0??usage@@YAXXZ@CG?A?@@HMN@Z"
+// WIN32: define internal x86_thiscallcc double (i32, float, double)* @"??B@?0??usage@@YAXXZ@QBEP6I?A?@@HMN@ZXZ"
+// WIN32: ret double (i32, float, double)* @"?__invoke@@?0??usage@@YAXXZ@CI?A?@@HMN@Z"
+// WIN32: define internal x86_thiscallcc double (i32, float, double)* @"??B@?0??usage@@YAXXZ@QBEP6Q?A?@@HMN@ZXZ"
+// WIN32: ret double (i32, float, double)* @"?__invoke@@?0??usage@@YAXXZ@CQ?A?@@HMN@Z"
 //
 // __invoke function, calls operator(). Win32 should call both.
 // LIN64: define internal double @"_ZZ5usagevEN3$_08__invokeEifd"
@@ -42,3 +64,9 @@
 // WIN32: call x86_thiscallcc double @"??R@?0??usage@@YAXXZ@QBE?A?@@HMN@Z"
 // WIN32: define internal x86_thiscallcc double @"?__invoke@@?0??usage@@YAXXZ@CE?A?@@HMN@Z"
 // WIN32: call x86_thiscallcc double @"??R@?0??usage@@YAXXZ@QBE?A?@@HMN@Z"
+// WIN32: define internal x86_stdcallcc double @"?__invoke@@?0??usage@@YAXXZ@CG?A?@@HMN@Z"
+// WIN32: call x86_thiscallcc double @"??R@?0??usage@@YAXXZ@QBE?A?@@HMN@Z"
+// WIN32: define internal x86_fastcallcc double @"?__invoke@@?0??usage@@YAXXZ@CI?A?@@HMN@Z"
+// WIN32: call x86_thiscallcc double @"??R@?0??usage@@YAXXZ@QBE?A?@@HMN@Z"
+// WIN32: define internal x86_vectorcallcc double @"?__invoke@@?0??usage@@YAXXZ@CQ?A?@@HMN@Z"
+// WIN32: call x86_thiscallcc double @"??R@?0??usage@@YAXXZ@QBE?A?@@HMN@Z"
Index: clang/lib/Sema/SemaLambda.cpp
===
--- clang/lib/S

[clang] 6b104ea - Implement Lambda Conversion Operators for All CCs for MSVC.

[Erich Keane via cfe-commits]

Author: Erich Keane
Date: 2020-11-05T07:25:44-08:00
New Revision: 6b104ea4b4630c2fa841c6d5f7c7a69b08d31979

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

LOG: Implement Lambda Conversion Operators for All CCs for MSVC.

As described here:
https://devblogs.microsoft.com/oldnewthing/20150220-00/?p=44623

In order to allow Lambdas to be used with traditional Win32 APIs, they
emit a conversion function for (what Raymond Chen claims is all) a
number of the calling conventions.  Through experimentation, we
discovered that the list isn't quite 'all'.

This patch implements this by taking the list of conversions that MSVC
emits (across 'all' architectures, I don't see any CCs on ARM), then
emits them if they are supported by the current target.

However, we also add 3 other options (which may be duplicates):
free-function, member-function, and operator() calling conventions.  We
do this because we have an extension where we generate both free and
member for these cases so th at people specifying a calling convention
on the lambda will have the expected behavior when specifying one of
those two.

MSVC doesn't seem to permit specifying calling-convention on lambdas,
but we do, so we need to make sure those are emitted as well. We do this
so that clang-only conventions are supported if the user specifies them.

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

Added: 


Modified: 
clang/lib/Sema/SemaLambda.cpp
clang/test/CodeGenCXX/lambda-conversion-op-cc.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaLambda.cpp b/clang/lib/Sema/SemaLambda.cpp
index 8242e89eb111..9e45709551c6 100644
--- a/clang/lib/Sema/SemaLambda.cpp
+++ b/clang/lib/Sema/SemaLambda.cpp
@@ -1272,6 +1272,34 @@ static void 
repeatForLambdaConversionFunctionCallingConvs(
   CallOpProto.isVariadic(), /*IsCXXMethod=*/true);
   CallingConv CallOpCC = CallOpProto.getCallConv();
 
+  /// Implement emitting a version of the operator for many of the calling
+  /// conventions for MSVC, as described here:
+  /// https://devblogs.microsoft.com/oldnewthing/20150220-00/?p=44623.
+  /// Experimentally, we determined that cdecl, stdcall, fastcall, and
+  /// vectorcall are generated by MSVC when it is supported by the target.
+  /// Additionally, we are ensuring that the default-free/default-member and
+  /// call-operator calling convention are generated as well.
+  /// NOTE: We intentionally generate a 'thiscall' on Win32 implicitly from the
+  /// 'member default', despite MSVC not doing so. We do this in order to 
ensure
+  /// that someone who intentionally places 'thiscall' on the lambda call
+  /// operator will still get that overload, since we don't have the a way of
+  /// detecting the attribute by the time we get here.
+  if (S.getLangOpts().MSVCCompat) {
+CallingConv Convs[] = {
+CC_C,CC_X86StdCall, CC_X86FastCall, CC_X86VectorCall,
+DefaultFree, DefaultMember, CallOpCC};
+llvm::sort(Convs);
+llvm::iterator_range Range(
+std::begin(Convs), std::unique(std::begin(Convs), std::end(Convs)));
+const TargetInfo &TI = S.getASTContext().getTargetInfo();
+
+for (CallingConv C : Range) {
+  if (TI.checkCallingConvention(C) == TargetInfo::CCCR_OK)
+F(C);
+}
+return;
+  }
+
   if (CallOpCC == DefaultMember && DefaultMember != DefaultFree) {
 F(DefaultFree);
 F(DefaultMember);
@@ -1475,9 +1503,6 @@ static void addFunctionPointerConversion(Sema &S, 
SourceRange IntroducerRange,
 /// C++11 [expr.prim.lambda]p6. Note that in most cases, this should emit only 
a
 /// single pointer conversion. In the event that the default calling convention
 /// for free and member functions is 
diff erent, it will emit both conventions.
-/// FIXME: Implement emitting a version of the operator for EVERY calling
-/// convention for MSVC, as described here:
-/// https://devblogs.microsoft.com/oldnewthing/20150220-00/?p=44623.
 static void addFunctionPointerConversions(Sema &S, SourceRange IntroducerRange,
   CXXRecordDecl *Class,
   CXXMethodDecl *CallOperator) {

diff  --git a/clang/test/CodeGenCXX/lambda-conversion-op-cc.cpp 
b/clang/test/CodeGenCXX/lambda-conversion-op-cc.cpp
index c2618925de15..cbb90e1f6078 100644
--- a/clang/test/CodeGenCXX/lambda-conversion-op-cc.cpp
+++ b/clang/test/CodeGenCXX/lambda-conversion-op-cc.cpp
@@ -1,6 +1,6 @@
 // RUN: %clang_cc1 -emit-llvm %s -o - -triple=x86_64-linux-gnu | FileCheck %s 
--check-prefixes=CHECK,LIN64
 // RUN: %clang_cc1 -emit-llvm %s -o - -triple=x86_64-linux-gnu 
-DCC="__attribute__((vectorcall))" | FileCheck %s --check-prefixes=CHECK,VECCALL
-// RUN: %clang_cc1 -emit-llvm %s -o - -triple=i386-windows-pc -DWIN32 | 
FileCheck %s 

[PATCH] D90832: [clang-tidy] Extend IdentifierNamingCheck per file config

[Nathan James via Phabricator via cfe-commits]

njames93 added a comment.

Didn't mean for there to be any formatting changes. I'll remove those later too


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90832

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

[PATCH] D90835: [RFC][clang-tidy] Ignore diagnostics due to macro expansion from not-interested headers

[Dmitry Polukhin via Phabricator via cfe-commits]

DmitryPolukhin updated this revision to Diff 303121.
DmitryPolukhin added a comment.

Fix clang-tidy warning


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90835

Files:
  clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp
  clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.h
  clang-tools-extra/clang-tidy/cppcoreguidelines/ProTypeVarargCheck.cpp
  clang-tools-extra/test/clang-tidy/infrastructure/macros.cpp
  clang-tools-extra/test/clang-tidy/infrastructure/macros.h
  clang-tools-extra/test/clang-tidy/infrastructure/macros_filter.h

Index: clang-tools-extra/test/clang-tidy/infrastructure/macros_filter.h
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/infrastructure/macros_filter.h
@@ -0,0 +1,3 @@
+#define HEADER_FILTER_MACRO_DIAG_IN_ARG(a) a
+#define HEADER_FILTER_MACRO_DIAG_IN_BODY int var_B1[10]
+#define HEADER_FILTER_MACRO_DIAG_IN_BODY2 int var_B2[10]
Index: clang-tools-extra/test/clang-tidy/infrastructure/macros.h
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/infrastructure/macros.h
@@ -0,0 +1,9 @@
+#define HEADER_MACRO_DIAG_IN_ARG(a) a
+#define HEADER_MACRO_DIAG_IN_BODY int var_C1[10]
+#define HEADER_MACRO_DIAG_IN_BODY2 int var_C2[10]
+
+#define DEFINE_bool(name, val)\
+  namespace fLB { \
+  typedef char FLAG_##name##_value_is_not_a_bool[(sizeof(val) != sizeof(bool)) ? -1 : 1]; \
+  }   \
+  bool FLAG_##name = val
Index: clang-tools-extra/test/clang-tidy/infrastructure/macros.cpp
===
--- clang-tools-extra/test/clang-tidy/infrastructure/macros.cpp
+++ clang-tools-extra/test/clang-tidy/infrastructure/macros.cpp
@@ -1,7 +1,41 @@
-// RUN: clang-tidy -checks='-*,google-explicit-constructor' %s -- | FileCheck %s
+// RUN: clang-tidy -checks='-*,google-explicit-constructor,modernize-avoid-c-arrays' --header-filter='macros_filter.h' %s -- | FileCheck %s
+
+#include "macros.h"
+#include "macros_filter.h"
 
 #define Q(name) class name { name(int i); }
 
 Q(A);
 // CHECK: :[[@LINE-1]]:3: warning: single-argument constructors must be marked explicit
-// CHECK: :3:30: note: expanded from macro 'Q'
+// CHECK: :[[@LINE-4]]:30: note: expanded from macro 'Q'
+
+#define MAIN_MACRO_DIAG_IN_ARG(a) a
+MAIN_MACRO_DIAG_IN_ARG(int var_A[10]);
+// CHECK: :[[@LINE-1]]:24: warning: do not declare C-style arrays, use std::array<> instead
+
+#define MAIN_MACRO_DIAG_IN_BODY int var_A1[10]
+MAIN_MACRO_DIAG_IN_BODY;
+// CHECK: :[[@LINE-1]]:1: warning: do not declare C-style arrays, use std::array<> instead
+// CHECK: :[[@LINE-3]]:33: note: expanded from macro 'MAIN_MACRO_DIAG_IN_BODY'
+
+HEADER_FILTER_MACRO_DIAG_IN_ARG(int var_B[10]);
+// CHECK: :[[@LINE-1]]:33: warning: do not declare C-style arrays, use std::array<> instead
+
+HEADER_FILTER_MACRO_DIAG_IN_BODY;
+// CHECK: :[[@LINE-1]]:1: warning: do not declare C-style arrays, use std::array<> instead
+// CHECK: note: expanded from macro 'HEADER_FILTER_MACRO_DIAG_IN_BODY'
+
+#define MAIN_MACRO_WRAPPER HEADER_FILTER_MACRO_DIAG_IN_BODY2
+MAIN_MACRO_WRAPPER;
+// CHECK: :[[@LINE-1]]:1: warning: do not declare C-style arrays, use std::array<> instead
+// CHECK: note: expanded from macro 'MAIN_MACRO_WRAPPER'
+// CHECK: note: expanded from macro 'HEADER_FILTER_MACRO_DIAG_IN_BODY2'
+
+HEADER_MACRO_DIAG_IN_ARG(int var_C[10]);
+HEADER_MACRO_DIAG_IN_BODY;
+
+#define MAIN_MACRO_WRAPPER2 HEADER_MACRO_DIAG_IN_BODY2
+MAIN_MACRO_WRAPPER2;
+
+DEFINE_bool(test, false);
+// CHECK-NOT: warning:
Index: clang-tools-extra/clang-tidy/cppcoreguidelines/ProTypeVarargCheck.cpp
===
--- clang-tools-extra/clang-tidy/cppcoreguidelines/ProTypeVarargCheck.cpp
+++ clang-tools-extra/clang-tidy/cppcoreguidelines/ProTypeVarargCheck.cpp
@@ -115,7 +115,10 @@
   }
 
   if (const auto *Matched = Result.Nodes.getNodeAs("va_use")) {
-diag(Matched->getExprLoc(),
+// va_arg is a macro defined in system header but diags from such macro
+// are not always reported so use expansion location instead to always
+// report
+diag(Result.SourceManager->getExpansionLoc(Matched->getExprLoc()),
  "do not use va_arg to define c-style vararg functions; "
  "use variadic templates instead");
   }
Index: clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.h
===
--- clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.h
+++ clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.h
@@ -177,6 +177,10 @@
 DiagEngine->getDiagnosticIDs()->getDesc

[PATCH] D89869: [OpenCL] Define OpenCL feature macros for all versions

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

I guess targets like SPIR will be supporting all features by default?

At this point, I would prefer that we only add the features that affect the 
parsing directly i.e. used in the clang source code.

FYI I think we need to explain the common design of features and extensions in 
comments and some code renaming somehow. But I am not clear yet and especially 
that it is likely some more refactoring will take place. Let's think about this 
in the meantime.




Comment at: clang/include/clang/Basic/OpenCLExtensions.def:110
+OPENCLFEAT_INTERNAL(__opencl_c_generic_address_space, 200, ~0U)
+OPENCLFEAT_INTERNAL(__opencl_c_work_group_collective_functions, 200, ~0U)
+OPENCLFEAT_INTERNAL(__opencl_c_atomic_order_acq_rel, 200, ~0U)

Does this need to be in the frontend?



Comment at: clang/include/clang/Basic/OpenCLExtensions.def:121
+OPENCLFEAT_INTERNAL(__opencl_c_fp64, 120, ~0U)
+OPENCLFEAT_INTERNAL(__opencl_c_int64, 100, ~0U)
+OPENCLFEAT_INTERNAL(__opencl_c_images, 100, ~0U)

if we are not going to change clang to make int64 conditional I would suggest 
we don't add this here for now.



Comment at: clang/include/clang/Basic/OpenCLOptions.h:105
 }
 OptMap[Ext].Supported = V;
   }

I guess we need to make sure that targets can't conditionally support features 
in OpenCL 2.0 or earlier standards.



Comment at: clang/lib/Frontend/CompilerInstance.cpp:950
+  if (getLangOpts().OpenCL)
+getTarget().getSupportedOpenCLOpts().adjustFeatures(getLangOpts());
+

Would it be possible to move this into `getTarget().adjust(getLangOpts())` just 
below. There is a FIXME that explains that we should be doing such adjustment 
differently but we haven't solved it with time so let's keep the flow as is for 
now. 



Comment at: clang/test/Preprocessor/opencl-feature-extension-simult.cl:15
+
+// RUN: %clang_cc1 %s -E -cl-std=CL3.0 -cl-ext=-all__opencl_c_fp64
+// RUN: %clang_cc1 %s -E -cl-std=CL3.0 -cl-ext=+__opencl_c_fp64

Is this a typo?

`all__opencl_c_fp64`


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

https://reviews.llvm.org/D89869

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

[PATCH] D89869: [OpenCL] Define OpenCL feature macros for all versions

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

PS I think it's better to move both test files to SemaOpenCL folder as they are 
not related to common parsing but OpenCL specifically.


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

https://reviews.llvm.org/D89869

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

Re: [PATCH] D87372: clang-cl: Ignore /Zc:externConstexpr and /Zc:throwingNew

[Ilia K via cfe-commits]

@hans they are ignored because Clang behaves like MSVC with these options
enabled (C++ standard conformance mode)

On Wed, Nov 4, 2020, 16:03 Hans Wennborg via Phabricator <
revi...@reviews.llvm.org> wrote:

> hans added a comment.
>
> I'm not sure ignoring these is the right thing to do.  Maybe they should
> be "Unsupported but parsed options" instead?
>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D87372/new/
>
> https://reviews.llvm.org/D87372
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D53866: [Preamble] Stop circular inclusion of main file when building preamble

[Jan Wassenberg via Phabricator via cfe-commits]

jan-wassenberg added a comment.

@nik here's an unusual but real-world example that triggers this.
https://github.com/google/highway compiles the same source multiple times (with 
different macros set) for generating code for multiple SIMD instruction sets.
The main source file sets a macro to its filename and includes a 
"foreach_target.h" which includes the file identified by that macro.

I understand this is complicated for analysis, so foreach_target.h does nothing 
if it detects that an IDE/analyzer are parsing. This relies on predefined 
macros such as
__CDT_PARSER__ __INTELLISENSE__ Q_CREATOR_RUN. Is there such a macro for clangd?


Repository:
  rC Clang

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

https://reviews.llvm.org/D53866

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

[PATCH] D90799: [PowerPC] Add paired vector load and store builtins and intrinsics

[Baptiste Saleil via Phabricator via cfe-commits]

bsaleil updated this revision to Diff 303132.
bsaleil added a comment.

Add support for the paired load/store intrinsics in `PPCLoopInstrFormPrep`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90799

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-ppc-mma.c
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCISelDAGToDAG.cpp
  llvm/lib/Target/PowerPC/PPCISelLowering.cpp
  llvm/lib/Target/PowerPC/PPCISelLowering.h
  llvm/lib/Target/PowerPC/PPCInstrInfo.td
  llvm/lib/Target/PowerPC/PPCInstrPrefix.td
  llvm/lib/Target/PowerPC/PPCLoopInstrFormPrep.cpp
  llvm/lib/Target/PowerPC/PPCTargetTransformInfo.cpp
  llvm/test/CodeGen/PowerPC/dform-pair-load-store.ll
  llvm/test/CodeGen/PowerPC/loop-p10-pair-prepare.ll
  llvm/test/CodeGen/PowerPC/mma-intrinsics.ll

Index: llvm/test/CodeGen/PowerPC/mma-intrinsics.ll
===
--- llvm/test/CodeGen/PowerPC/mma-intrinsics.ll
+++ llvm/test/CodeGen/PowerPC/mma-intrinsics.ll
@@ -698,3 +698,307 @@
 
 declare <512 x i1> @llvm.ppc.mma.pmxvf64gernn(<512 x i1>, <256 x i1>, <16 x i8>, i32, i32)
 declare <512 x i1> @llvm.ppc.mma.xvf64gernp(<512 x i1>, <256 x i1>, <16 x i8>)
+
+; Function Attrs: nounwind
+define void @test_ldst_1(<256 x i1>* %vpp, <256 x i1>* %vp2) {
+; CHECK-LABEL: test_ldst_1:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:lxvp vsp0, 0(r3)
+; CHECK-NEXT:stxvp vsp0, 0(r4)
+; CHECK-NEXT:blr
+;
+; CHECK-BE-LABEL: test_ldst_1:
+; CHECK-BE:   # %bb.0: # %entry
+; CHECK-BE-NEXT:lxvp vsp0, 0(r3)
+; CHECK-BE-NEXT:stxvp vsp0, 0(r4)
+; CHECK-BE-NEXT:blr
+entry:
+  %0 = bitcast <256 x i1>* %vpp to i8*
+  %1 = tail call <256 x i1> @llvm.ppc.mma.lxvp(i8* %0)
+  %2 = bitcast <256 x i1>* %vp2 to i8*
+  tail call void @llvm.ppc.mma.stxvp(<256 x i1> %1, i8* %2)
+  ret void
+}
+
+; Function Attrs: argmemonly nounwind readonly
+declare <256 x i1> @llvm.ppc.mma.lxvp(i8*)
+
+; Function Attrs: argmemonly nounwind writeonly
+declare void @llvm.ppc.mma.stxvp(<256 x i1>, i8*)
+
+; Function Attrs: nounwind
+define void @test_ldst_2(<256 x i1>* %vpp, i64 %offset, <256 x i1>* %vp2)  {
+; CHECK-LABEL: test_ldst_2:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:lxvpx vsp0, r3, r4
+; CHECK-NEXT:stxvpx vsp0, r5, r4
+; CHECK-NEXT:blr
+;
+; CHECK-BE-LABEL: test_ldst_2:
+; CHECK-BE:   # %bb.0: # %entry
+; CHECK-BE-NEXT:lxvpx vsp0, r3, r4
+; CHECK-BE-NEXT:stxvpx vsp0, r5, r4
+; CHECK-BE-NEXT:blr
+entry:
+  %0 = bitcast <256 x i1>* %vpp to i8*
+  %1 = getelementptr i8, i8* %0, i64 %offset
+  %2 = tail call <256 x i1> @llvm.ppc.mma.lxvp(i8* %1)
+  %3 = bitcast <256 x i1>* %vp2 to i8*
+  %4 = getelementptr i8, i8* %3, i64 %offset
+  tail call void @llvm.ppc.mma.stxvp(<256 x i1> %2, i8* %4)
+  ret void
+}
+
+; Function Attrs: nounwind
+define void @test_ldst_3(<256 x i1>* %vpp, <256 x i1>* %vp2)  {
+; CHECK-LABEL: test_ldst_3:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:plxvp vsp0, 18(r3), 0
+; CHECK-NEXT:pstxvp vsp0, 18(r4), 0
+; CHECK-NEXT:blr
+;
+; CHECK-BE-LABEL: test_ldst_3:
+; CHECK-BE:   # %bb.0: # %entry
+; CHECK-BE-NEXT:plxvp vsp0, 18(r3), 0
+; CHECK-BE-NEXT:pstxvp vsp0, 18(r4), 0
+; CHECK-BE-NEXT:blr
+entry:
+  %0 = bitcast <256 x i1>* %vpp to i8*
+  %1 = getelementptr i8, i8* %0, i64 18
+  %2 = tail call <256 x i1> @llvm.ppc.mma.lxvp(i8* %1)
+  %3 = bitcast <256 x i1>* %vp2 to i8*
+  %4 = getelementptr i8, i8* %3, i64 18
+  tail call void @llvm.ppc.mma.stxvp(<256 x i1> %2, i8* %4)
+  ret void
+}
+
+; Function Attrs: nounwind
+define void @test_ldst_4(<256 x i1>* %vpp, <256 x i1>* %vp2)  {
+; CHECK-LABEL: test_ldst_4:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:plxvp vsp0, 1(r3), 0
+; CHECK-NEXT:pstxvp vsp0, 1(r4), 0
+; CHECK-NEXT:blr
+;
+; CHECK-BE-LABEL: test_ldst_4:
+; CHECK-BE:   # %bb.0: # %entry
+; CHECK-BE-NEXT:plxvp vsp0, 1(r3), 0
+; CHECK-BE-NEXT:pstxvp vsp0, 1(r4), 0
+; CHECK-BE-NEXT:blr
+entry:
+  %0 = bitcast <256 x i1>* %vpp to i8*
+  %1 = getelementptr i8, i8* %0, i64 1
+  %2 = tail call <256 x i1> @llvm.ppc.mma.lxvp(i8* %1)
+  %3 = bitcast <256 x i1>* %vp2 to i8*
+  %4 = getelementptr i8, i8* %3, i64 1
+  tail call void @llvm.ppc.mma.stxvp(<256 x i1> %2, i8* %4)
+  ret void
+}
+
+; Function Attrs: nounwind
+define void @test_ldst_5(<256 x i1>* %vpp, <256 x i1>* %vp2)  {
+; CHECK-LABEL: test_ldst_5:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:plxvp vsp0, 42(r3), 0
+; CHECK-NEXT:pstxvp vsp0, 42(r4), 0
+; CHECK-NEXT:blr
+;
+; CHECK-BE-LABEL: test_ldst_5:
+; CHECK-BE:   # %bb.0: # %entry
+; CHECK-BE-NEXT:plxvp vsp0, 42(r3), 0
+; CHECK-BE-NEXT:pstxvp vsp0, 42(r4), 0
+; CHECK-BE-NEXT:blr
+entry:
+  %0 = bitcast <256 x i1>* %vpp to i8*
+  %1 = getelementptr i8, i8* %0, i64 42
+  %2 = tail call <256 x i1> @llv

[PATCH] D90765: [ARM][AArch64] Adding Neoverse V1 CPU support

[Dave Green via Phabricator via cfe-commits]

dmgreen added inline comments.



Comment at: llvm/include/llvm/Support/AArch64TargetParser.def:154-155
+AARCH64_CPU_NAME("neoverse-v1", ARMV8_4A, FK_CRYPTO_NEON_FP_ARMV8, false,
+ (AArch64::AEK_RAS | AArch64::AEK_SVE | AArch64::AEK_SSBS |
+  AArch64::AEK_RCPC))
 AARCH64_CPU_NAME("cyclone", ARMV8A, FK_CRYPTO_NEON_FP_ARMV8, false,

Target parser isn't my favourite part of llvm, but does this need FP16? BF16? 
Any others?



Comment at: llvm/include/llvm/Support/ARMTargetParser.def:303
  (ARM::AEK_FP16 | ARM::AEK_DOTPROD))
+ARM_CPU_NAME("neoverse-v1", ARMV8_4A, FK_CRYPTO_NEON_FP_ARMV8, false, 
ARM::AEK_RAS)
 ARM_CPU_NAME("cyclone", ARMV8A, FK_CRYPTO_NEON_FP_ARMV8, false, ARM::AEK_CRC)

Make sure this line isn't too long.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90765

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

[PATCH] D87372: clang-cl: Ignore /Zc:externConstexpr and /Zc:throwingNew

[Hans Wennborg via Phabricator via cfe-commits]

hans added a comment.

In D87372#2376305 , @ki.stfu wrote:

> @hans they are ignored because Clang behaves like MSVC with these options
> enabled (C++ standard conformance mode)

Ah, I got it backwards. Yeah, ignoring these makes sense.

Can you add the variants with trailing dash (e.g. /Zc:externConstexpr-) as 
parsed but unsupported?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87372

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

[PATCH] D90719: [DebugInfo] Modify ctor homing as workaround for unconstructed libcxx types

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

In D90719#2372656 , @dblaikie wrote:

> My understanding is that such code is UB, is that right?

I guess I'm not convinced it's UB, and need some language lawyering help to 
decide.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90719

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

[PATCH] D90849: [dllexport] Avoid multiple codegen assert for explicitly defaulted methods in explicit instantiation definitions (PR47683)

[Reid Kleckner via Phabricator via cfe-commits]

rnk added inline comments.



Comment at: clang/lib/Sema/SemaDeclCXX.cpp:5887-5915
   if (MD->isUserProvided()) {
 // Instantiate non-default class member functions ...
 
 // .. except for certain kinds of template specializations.
 if (TSK == TSK_ImplicitInstantiation && !ClassAttr->isInherited())
   continue;
 

I wonder if this code block could be simplified by calculating two booleans:
- ShouldReference: If true, call S.MarkFunctionReferenced
- ShouldHandleNow: if true, call HandleTopLevelDecl

We want to mark the vast majority of C++ method decls referenced. The 
conditions I see here are:
- user provided
- non-trivial
- trivial explicitly defaulted
- trivial copy assign & move assign
- an exception for non-inherited attributes on implicit specializations (?)
- an exception for defaulted explicit instantiations
I tried to come up with a simpler description of those conditions, and couldn't 
come up with one.

Nevermind. I don't think my suggestion will make the code any simpler, but I'll 
leave this as a comment for your consideration.



Comment at: clang/lib/Sema/SemaDeclCXX.cpp:5898
 // encountered.
   } else if (!MD->isTrivial() || MD->isExplicitlyDefaulted() ||
  MD->isCopyAssignmentOperator() ||

Part of me wants to handle explicitly defaulted things separately from implicit 
special members, so we don't have to check for explicitly defaulted-ness twice.



Comment at: clang/test/CodeGenCXX/dllexport.cpp:929
+template  struct T {
+  T() = default;
+  X x;

Let's also add a test case where the constructor is explicitly defaulted 
outside the body of the class. From reading the code, I know we will take the 
isUserProvided path instead, but I'd like to have it for completeness.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90849

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

[clang-tools-extra] f253823 - [clangd] Trivial: Log missing completion signals.

[Utkarsh Saxena via cfe-commits]

Author: Utkarsh Saxena
Date: 2020-11-05T18:52:44+01:00
New Revision: f253823398dd2894ee5d9333c541c534b7a407fb

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

LOG: [clangd] Trivial: Log missing completion signals.

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

Added: 


Modified: 
clang-tools-extra/clangd/Quality.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/Quality.cpp 
b/clang-tools-extra/clangd/Quality.cpp
index 96784c077d05..c206c97787db 100644
--- a/clang-tools-extra/clangd/Quality.cpp
+++ b/clang-tools-extra/clangd/Quality.cpp
@@ -257,6 +257,7 @@ llvm::raw_ostream &operator<<(llvm::raw_ostream &OS,
   OS << llvm::formatv("\tReferences: {0}\n", S.References);
   OS << llvm::formatv("\tDeprecated: {0}\n", S.Deprecated);
   OS << llvm::formatv("\tReserved name: {0}\n", S.ReservedName);
+  OS << llvm::formatv("\tImplementation detail: {0}\n", 
S.ImplementationDetail);
   OS << llvm::formatv("\tCategory: {0}\n", static_cast(S.Category));
   return OS;
 }
@@ -455,6 +456,7 @@ llvm::raw_ostream &operator<<(llvm::raw_ostream &OS,
   OS << llvm::formatv("\tForbidden: {0}\n", S.Forbidden);
   OS << llvm::formatv("\tNeedsFixIts: {0}\n", S.NeedsFixIts);
   OS << llvm::formatv("\tIsInstanceMember: {0}\n", S.IsInstanceMember);
+  OS << llvm::formatv("\tInBaseClass: {0}\n", S.InBaseClass);
   OS << llvm::formatv("\tContext: {0}\n", getCompletionKindString(S.Context));
   OS << llvm::formatv("\tQuery type: {0}\n", static_cast(S.Query));
   OS << llvm::formatv("\tScope: {0}\n", static_cast(S.Scope));



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

[PATCH] D90828: [clangd] Trivial: Log missing completion signals.

[Utkarsh Saxena 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 rGf253823398dd: [clangd] Trivial: Log missing completion 
signals. (authored by usaxena95).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90828

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


Index: clang-tools-extra/clangd/Quality.cpp
===
--- clang-tools-extra/clangd/Quality.cpp
+++ clang-tools-extra/clangd/Quality.cpp
@@ -257,6 +257,7 @@
   OS << llvm::formatv("\tReferences: {0}\n", S.References);
   OS << llvm::formatv("\tDeprecated: {0}\n", S.Deprecated);
   OS << llvm::formatv("\tReserved name: {0}\n", S.ReservedName);
+  OS << llvm::formatv("\tImplementation detail: {0}\n", 
S.ImplementationDetail);
   OS << llvm::formatv("\tCategory: {0}\n", static_cast(S.Category));
   return OS;
 }
@@ -455,6 +456,7 @@
   OS << llvm::formatv("\tForbidden: {0}\n", S.Forbidden);
   OS << llvm::formatv("\tNeedsFixIts: {0}\n", S.NeedsFixIts);
   OS << llvm::formatv("\tIsInstanceMember: {0}\n", S.IsInstanceMember);
+  OS << llvm::formatv("\tInBaseClass: {0}\n", S.InBaseClass);
   OS << llvm::formatv("\tContext: {0}\n", getCompletionKindString(S.Context));
   OS << llvm::formatv("\tQuery type: {0}\n", static_cast(S.Query));
   OS << llvm::formatv("\tScope: {0}\n", static_cast(S.Scope));


Index: clang-tools-extra/clangd/Quality.cpp
===
--- clang-tools-extra/clangd/Quality.cpp
+++ clang-tools-extra/clangd/Quality.cpp
@@ -257,6 +257,7 @@
   OS << llvm::formatv("\tReferences: {0}\n", S.References);
   OS << llvm::formatv("\tDeprecated: {0}\n", S.Deprecated);
   OS << llvm::formatv("\tReserved name: {0}\n", S.ReservedName);
+  OS << llvm::formatv("\tImplementation detail: {0}\n", S.ImplementationDetail);
   OS << llvm::formatv("\tCategory: {0}\n", static_cast(S.Category));
   return OS;
 }
@@ -455,6 +456,7 @@
   OS << llvm::formatv("\tForbidden: {0}\n", S.Forbidden);
   OS << llvm::formatv("\tNeedsFixIts: {0}\n", S.NeedsFixIts);
   OS << llvm::formatv("\tIsInstanceMember: {0}\n", S.IsInstanceMember);
+  OS << llvm::formatv("\tInBaseClass: {0}\n", S.InBaseClass);
   OS << llvm::formatv("\tContext: {0}\n", getCompletionKindString(S.Context));
   OS << llvm::formatv("\tQuery type: {0}\n", static_cast(S.Query));
   OS << llvm::formatv("\tScope: {0}\n", static_cast(S.Scope));
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D90799: [PowerPC] Add paired vector load and store builtins and intrinsics

[Baptiste Saleil via Phabricator via cfe-commits]

bsaleil updated this revision to Diff 303152.
bsaleil added a comment.

Rebase patch and add Sema check test case for the builtins


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90799

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-ppc-mma.c
  clang/test/Sema/ppc-mma-types.c
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCISelDAGToDAG.cpp
  llvm/lib/Target/PowerPC/PPCISelLowering.cpp
  llvm/lib/Target/PowerPC/PPCISelLowering.h
  llvm/lib/Target/PowerPC/PPCInstrInfo.td
  llvm/lib/Target/PowerPC/PPCInstrPrefix.td
  llvm/lib/Target/PowerPC/PPCLoopInstrFormPrep.cpp
  llvm/lib/Target/PowerPC/PPCTargetTransformInfo.cpp
  llvm/test/CodeGen/PowerPC/dform-pair-load-store.ll
  llvm/test/CodeGen/PowerPC/loop-p10-pair-prepare.ll
  llvm/test/CodeGen/PowerPC/mma-intrinsics.ll

Index: llvm/test/CodeGen/PowerPC/mma-intrinsics.ll
===
--- llvm/test/CodeGen/PowerPC/mma-intrinsics.ll
+++ llvm/test/CodeGen/PowerPC/mma-intrinsics.ll
@@ -698,3 +698,307 @@
 
 declare <512 x i1> @llvm.ppc.mma.pmxvf64gernn(<512 x i1>, <256 x i1>, <16 x i8>, i32, i32)
 declare <512 x i1> @llvm.ppc.mma.xvf64gernp(<512 x i1>, <256 x i1>, <16 x i8>)
+
+; Function Attrs: nounwind
+define void @test_ldst_1(<256 x i1>* %vpp, <256 x i1>* %vp2) {
+; CHECK-LABEL: test_ldst_1:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:lxvp vsp0, 0(r3)
+; CHECK-NEXT:stxvp vsp0, 0(r4)
+; CHECK-NEXT:blr
+;
+; CHECK-BE-LABEL: test_ldst_1:
+; CHECK-BE:   # %bb.0: # %entry
+; CHECK-BE-NEXT:lxvp vsp0, 0(r3)
+; CHECK-BE-NEXT:stxvp vsp0, 0(r4)
+; CHECK-BE-NEXT:blr
+entry:
+  %0 = bitcast <256 x i1>* %vpp to i8*
+  %1 = tail call <256 x i1> @llvm.ppc.mma.lxvp(i8* %0)
+  %2 = bitcast <256 x i1>* %vp2 to i8*
+  tail call void @llvm.ppc.mma.stxvp(<256 x i1> %1, i8* %2)
+  ret void
+}
+
+; Function Attrs: argmemonly nounwind readonly
+declare <256 x i1> @llvm.ppc.mma.lxvp(i8*)
+
+; Function Attrs: argmemonly nounwind writeonly
+declare void @llvm.ppc.mma.stxvp(<256 x i1>, i8*)
+
+; Function Attrs: nounwind
+define void @test_ldst_2(<256 x i1>* %vpp, i64 %offset, <256 x i1>* %vp2)  {
+; CHECK-LABEL: test_ldst_2:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:lxvpx vsp0, r3, r4
+; CHECK-NEXT:stxvpx vsp0, r5, r4
+; CHECK-NEXT:blr
+;
+; CHECK-BE-LABEL: test_ldst_2:
+; CHECK-BE:   # %bb.0: # %entry
+; CHECK-BE-NEXT:lxvpx vsp0, r3, r4
+; CHECK-BE-NEXT:stxvpx vsp0, r5, r4
+; CHECK-BE-NEXT:blr
+entry:
+  %0 = bitcast <256 x i1>* %vpp to i8*
+  %1 = getelementptr i8, i8* %0, i64 %offset
+  %2 = tail call <256 x i1> @llvm.ppc.mma.lxvp(i8* %1)
+  %3 = bitcast <256 x i1>* %vp2 to i8*
+  %4 = getelementptr i8, i8* %3, i64 %offset
+  tail call void @llvm.ppc.mma.stxvp(<256 x i1> %2, i8* %4)
+  ret void
+}
+
+; Function Attrs: nounwind
+define void @test_ldst_3(<256 x i1>* %vpp, <256 x i1>* %vp2)  {
+; CHECK-LABEL: test_ldst_3:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:plxvp vsp0, 18(r3), 0
+; CHECK-NEXT:pstxvp vsp0, 18(r4), 0
+; CHECK-NEXT:blr
+;
+; CHECK-BE-LABEL: test_ldst_3:
+; CHECK-BE:   # %bb.0: # %entry
+; CHECK-BE-NEXT:plxvp vsp0, 18(r3), 0
+; CHECK-BE-NEXT:pstxvp vsp0, 18(r4), 0
+; CHECK-BE-NEXT:blr
+entry:
+  %0 = bitcast <256 x i1>* %vpp to i8*
+  %1 = getelementptr i8, i8* %0, i64 18
+  %2 = tail call <256 x i1> @llvm.ppc.mma.lxvp(i8* %1)
+  %3 = bitcast <256 x i1>* %vp2 to i8*
+  %4 = getelementptr i8, i8* %3, i64 18
+  tail call void @llvm.ppc.mma.stxvp(<256 x i1> %2, i8* %4)
+  ret void
+}
+
+; Function Attrs: nounwind
+define void @test_ldst_4(<256 x i1>* %vpp, <256 x i1>* %vp2)  {
+; CHECK-LABEL: test_ldst_4:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:plxvp vsp0, 1(r3), 0
+; CHECK-NEXT:pstxvp vsp0, 1(r4), 0
+; CHECK-NEXT:blr
+;
+; CHECK-BE-LABEL: test_ldst_4:
+; CHECK-BE:   # %bb.0: # %entry
+; CHECK-BE-NEXT:plxvp vsp0, 1(r3), 0
+; CHECK-BE-NEXT:pstxvp vsp0, 1(r4), 0
+; CHECK-BE-NEXT:blr
+entry:
+  %0 = bitcast <256 x i1>* %vpp to i8*
+  %1 = getelementptr i8, i8* %0, i64 1
+  %2 = tail call <256 x i1> @llvm.ppc.mma.lxvp(i8* %1)
+  %3 = bitcast <256 x i1>* %vp2 to i8*
+  %4 = getelementptr i8, i8* %3, i64 1
+  tail call void @llvm.ppc.mma.stxvp(<256 x i1> %2, i8* %4)
+  ret void
+}
+
+; Function Attrs: nounwind
+define void @test_ldst_5(<256 x i1>* %vpp, <256 x i1>* %vp2)  {
+; CHECK-LABEL: test_ldst_5:
+; CHECK:   # %bb.0: # %entry
+; CHECK-NEXT:plxvp vsp0, 42(r3), 0
+; CHECK-NEXT:pstxvp vsp0, 42(r4), 0
+; CHECK-NEXT:blr
+;
+; CHECK-BE-LABEL: test_ldst_5:
+; CHECK-BE:   # %bb.0: # %entry
+; CHECK-BE-NEXT:plxvp vsp0, 42(r3), 0
+; CHECK-BE-NEXT:pstxvp vsp0, 42(r4), 0
+; CHECK-BE-NEXT:blr
+entry:
+  %0 = bitcast <256 x i1>* %vpp to i8*
+  %1 = getelementptr i8, i8* %0, i64 42
+  %2 = tail ca

[PATCH] D90822: [X86] use macros to split GFNI intrinsics into different kinds

[Craig Topper via Phabricator via cfe-commits]

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

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90822

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

[PATCH] D90809: [amdgpu] Add `llvm.amdgcn.endpgm` support.

[Stanislav Mekhanoshin via Phabricator via cfe-commits]

rampitec added inline comments.



Comment at: llvm/include/llvm/IR/IntrinsicsAMDGPU.td:1581
+def int_amdgcn_endpgm : GCCBuiltin<"__builtin_amdgcn_endpgm">,
+  Intrinsic<[], [], [IntrNoReturn, IntrNoMem, IntrHasSideEffects]
+>;

Mayby also IntrCold?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90809

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

[clang] c6a384d - [Sema] Special case -Werror-implicit-function-declaration and reject other -Werror-

[Fangrui Song via cfe-commits]

Author: Fangrui Song
Date: 2020-11-05T10:25:30-08:00
New Revision: c6a384df1f8ab85815160297543ab329e02560ef

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

LOG: [Sema] Special case -Werror-implicit-function-declaration and reject other 
-Werror-

This is the only -Werror- form warning option GCC supports (gcc/c-family/c.opt).
Fortunately no other form is used anywhere.

Added: 


Modified: 
clang/lib/Basic/Warnings.cpp
clang/test/CodeGen/vecshift.c
clang/test/Frontend/warning-options.cpp
clang/test/Modules/diagnose-missing-import.m
clang/test/Preprocessor/if_warning.c
clang/test/Sema/vecshift.c

Removed: 




diff  --git a/clang/lib/Basic/Warnings.cpp b/clang/lib/Basic/Warnings.cpp
index 2c909d9510d4..cc8c138233ca 100644
--- a/clang/lib/Basic/Warnings.cpp
+++ b/clang/lib/Basic/Warnings.cpp
@@ -130,11 +130,14 @@ void clang::ProcessWarningOptions(DiagnosticsEngine 
&Diags,
   }
 
   // -Werror/-Wno-error is a special case, not controlled by the option
-  // table. It also has the "specifier" form of -Werror=foo and 
-Werror-foo.
+  // table. It also has the "specifier" form of -Werror=foo. GCC supports
+  // the deprecated -Werror-implicit-function-declaration which is used by
+  // a few projects.
   if (Opt.startswith("error")) {
 StringRef Specifier;
 if (Opt.size() > 5) {  // Specifier must be present.
-  if ((Opt[5] != '=' && Opt[5] != '-') || Opt.size() == 6) {
+  if (Opt[5] != '=' &&
+  Opt.substr(5) != "-implicit-function-declaration") {
 if (Report)
   Diags.Report(diag::warn_unknown_warning_specifier)
 << "-Werror" << ("-W" + OrigOpt.str());

diff  --git a/clang/test/CodeGen/vecshift.c b/clang/test/CodeGen/vecshift.c
index 1fa047cd30b9..f37c5092875f 100644
--- a/clang/test/CodeGen/vecshift.c
+++ b/clang/test/CodeGen/vecshift.c
@@ -1,5 +1,5 @@
-// RUN: %clang_cc1  -Wno-error-vec-elem-size -emit-llvm %s -o - | FileCheck %s
-// RUN: %clang_cc1  -Wno-error-vec-elem-size -DEXT -emit-llvm %s -o - | 
FileCheck %s
+// RUN: %clang_cc1  -Wno-error=vec-elem-size -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1  -Wno-error=vec-elem-size -DEXT -emit-llvm %s -o - | 
FileCheck %s
 
 #ifdef EXT
 typedef __attribute__((__ext_vector_type__(8))) char vector_char8;

diff  --git a/clang/test/Frontend/warning-options.cpp 
b/clang/test/Frontend/warning-options.cpp
index 3c3396becaf8..444733c8b7f3 100644
--- a/clang/test/Frontend/warning-options.cpp
+++ b/clang/test/Frontend/warning-options.cpp
@@ -1,7 +1,8 @@
 // RUN: %clang_cc1 -Wmonkey -Wno-monkey -Wno-unused-command-line-arguments \
-// RUN:-Wno-unused-command-line-argument -Wmodule-build -Rmodule-built 
%s 2>&1 | FileCheck %s
+// RUN:-Wno-unused-command-line-argument -Wmodule-build -Werror-vla 
-Rmodule-built %s 2>&1 | FileCheck %s
 // CHECK: unknown warning option '-Wmonkey'
 // CHECK: unknown warning option '-Wno-monkey'
 // CHECK: unknown warning option '-Wno-unused-command-line-arguments'; did you 
mean '-Wno-unused-command-line-argument'?
 // CHECK: unknown warning option '-Wmodule-build'; did you mean 
'-Wmodule-conflict'?
+// CHECK-NEXT: unknown -Werror warning specifier: '-Werror-vla'
 // CHECK: unknown remark option '-Rmodule-built'; did you mean 
'-Rmodule-build'?

diff  --git a/clang/test/Modules/diagnose-missing-import.m 
b/clang/test/Modules/diagnose-missing-import.m
index 2c67e01944a9..f0e557ac09b0 100644
--- a/clang/test/Modules/diagnose-missing-import.m
+++ b/clang/test/Modules/diagnose-missing-import.m
@@ -2,6 +2,9 @@
 // RUN: %clang_cc1 -fmodules -fmodules-cache-path=%t 
-I%S/Inputs/diagnose-missing-import \
 // RUN:   -Werror=implicit-function-declaration -fsyntax-only \
 // RUN:   -fimplicit-module-maps -verify %s
+// RUN: %clang_cc1 -fmodules -fmodules-cache-path=%t 
-I%S/Inputs/diagnose-missing-import \
+// RUN:   -Werror-implicit-function-declaration -fsyntax-only \
+// RUN:   -fimplicit-module-maps -verify %s
 @import NCI;
 
 void foo() {

diff  --git a/clang/test/Preprocessor/if_warning.c 
b/clang/test/Preprocessor/if_warning.c
index 641ec3b1b970..47bc1c6b170a 100644
--- a/clang/test/Preprocessor/if_warning.c
+++ b/clang/test/Preprocessor/if_warning.c
@@ -1,5 +1,4 @@
 // RUN: %clang_cc1 %s -Eonly -Werror=undef -verify
-// RUN: %clang_cc1 %s -Eonly -Werror-undef -verify
 
 extern int x;
 

diff  --git a/clang/test/Sema/vecshift.c b/clang/test/Sema/vecshift.c
index 7b6a30ad60dd..7ad19b82093b 100644
--- a/clang/test/Sema/vecshift.c
+++ b/clang/test/Sema/vecshift.c
@@ -1,7 +1,5 @@
 // RUN: %clang_cc1 -fsyntax-only -DERR -verify %s
-// RUN: %clang_cc1 -fsyntax-only -Wno-error-vec-elem-size -verify %s
 // RUN: %clang_cc1 -fsyntax-only -DEXT -DERR -verify %s
-// RUN: %

[PATCH] D90714: [clang]Fix length threshold for MicrosoftMangle md5 hash

[Reid Kleckner via Phabricator via cfe-commits]

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

lgtm

I think the test case looks good as is, FWIW. Token pasting might make it more 
readable, but it's improving the existing test, and not necessarily in scope 
for this patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90714

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

[PATCH] D90719: [DebugInfo] Modify ctor homing as workaround for unconstructed libcxx types

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

In D90719#2376388 , @rnk wrote:

> In D90719#2372656 , @dblaikie wrote:
>
>> My understanding is that such code is UB, is that right?
>
> I guess I'm not convinced it's UB, and need some language lawyering help to 
> decide.

Fair enough. The code we're talking about essentially boils down to this, right:

  struct non_trivially_constructible {
non_trivially_constructible();
int i;
  };
  struct implicitly_non_trivially_constructible : non_trivially_constructible {
  };
  void f1() {
using T = implicitly_non_trivially_constructible;
alignas(T) unsigned char data[sizeof(T)];
T* t = static_cast(&data);
t->i = 3;
...
  }

Yeah? My understanding is that the lifetime of the T object hasn't started, 
because its ctor hasn't been run. For trivial types that's a bit fuzzier (eg: 
`int *i = (int*)malloc(sizeof(int)); *i = 3;` - we don't usually bother to call 
the pseudodestructor on this type) but for a non-trivially constructible thing, 
I'd think that was pretty well required/guaranteed by the language? (sort of by 
definition of non-trivially constructible)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90719

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

[PATCH] D90448: [clang] Add type check for explicit instantiation of static data members

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

How's this compare to the similar checks for variable templates? Is there some 
code/checking we could share here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90448

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

[clang] 82f86ae - APINotes: add APINotesYAMLCompiler

[Saleem Abdulrasool via cfe-commits]

Author: Saleem Abdulrasool
Date: 2020-11-05T18:55:13Z
New Revision: 82f86ae01a54ff8e3a5aaefd24745ef2b7b917ba

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

LOG: APINotes: add APINotesYAMLCompiler

This adds the skeleton of the YAML Compiler for APINotes.  This change
only adds the YAML IO model for the API Notes along with a new testing
tool `apinotes-test` which can be used to verify that can round trip the
YAML content properly.  It provides the basis for the future work which
will add a binary serialization and deserialization format to the data
model.

This is based on the code contributed by Apple at
https://github.com/llvm/llvm-project-staging/tree/staging/swift/apinotes.

Differential Revision: https://reviews.llvm.org/D88859
Reviewed By: Gabor Marton

Added: 
clang/include/clang/APINotes/APINotesYAMLCompiler.h
clang/include/clang/APINotes/Types.h
clang/lib/APINotes/APINotesYAMLCompiler.cpp
clang/lib/APINotes/CMakeLists.txt

clang/test/APINotes/Inputs/Frameworks/Simple.framework/Headers/Simple.apinotes
clang/test/APINotes/Inputs/Frameworks/Simple.framework/Headers/Simple.h

clang/test/APINotes/Inputs/Frameworks/SimpleKit.framework/Headers/SimpleKit.apinotes

clang/test/APINotes/Inputs/Frameworks/SimpleKit.framework/Headers/SimpleKit.h

clang/test/APINotes/Inputs/Frameworks/SimpleKit.framework/Headers/module.modulemap
clang/test/APINotes/yaml-roundtrip-2.test
clang/test/APINotes/yaml-roundtrip.test
clang/tools/apinotes-test/APINotesTest.cpp
clang/tools/apinotes-test/CMakeLists.txt

Modified: 
clang/lib/CMakeLists.txt
clang/test/CMakeLists.txt
clang/test/lit.cfg.py
clang/tools/CMakeLists.txt

Removed: 




diff  --git a/clang/include/clang/APINotes/APINotesYAMLCompiler.h 
b/clang/include/clang/APINotes/APINotesYAMLCompiler.h
new file mode 100644
index ..6098d0ee36fc
--- /dev/null
+++ b/clang/include/clang/APINotes/APINotesYAMLCompiler.h
@@ -0,0 +1,24 @@
+//===-- APINotesYAMLCompiler.h - API Notes YAML Format Reader ---*- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLVM_CLANG_APINOTES_APINOTESYAMLCOMPILER_H
+#define LLVM_CLANG_APINOTES_APINOTESYAMLCOMPILER_H
+
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/raw_ostream.h"
+
+namespace clang {
+namespace api_notes {
+/// Parses the APINotes YAML content and writes the representation back to the
+/// specified stream.  This provides a means of testing the YAML processing of
+/// the APINotes format.
+bool parseAndDumpAPINotes(llvm::StringRef YI, llvm::raw_ostream &OS);
+} // namespace api_notes
+} // namespace clang
+
+#endif

diff  --git a/clang/include/clang/APINotes/Types.h 
b/clang/include/clang/APINotes/Types.h
new file mode 100644
index ..be2a99ad6fd0
--- /dev/null
+++ b/clang/include/clang/APINotes/Types.h
@@ -0,0 +1,40 @@
+//===-- Types.h - API Notes Data Types --*- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef LLVM_CLANG_APINOTES_TYPES_H
+#define LLVM_CLANG_APINOTES_TYPES_H
+
+namespace clang {
+namespace api_notes {
+enum class RetainCountConventionKind {
+  None,
+  CFReturnsRetained,
+  CFReturnsNotRetained,
+  NSReturnsRetained,
+  NSReturnsNotRetained,
+};
+
+/// The payload for an enum_extensibility attribute. This is a tri-state rather
+/// than just a boolean because the presence of the attribute indicates
+/// auditing.
+enum class EnumExtensibilityKind {
+  None,
+  Open,
+  Closed,
+};
+
+/// The kind of a swift_wrapper/swift_newtype.
+enum class SwiftNewTypeKind {
+  None,
+  Struct,
+  Enum,
+};
+} // namespace api_notes
+} // namespace clang
+
+#endif

diff  --git a/clang/lib/APINotes/APINotesYAMLCompiler.cpp 
b/clang/lib/APINotes/APINotesYAMLCompiler.cpp
new file mode 100644
index ..997929a9bd22
--- /dev/null
+++ b/clang/lib/APINotes/APINotesYAMLCompiler.cpp
@@ -0,0 +1,597 @@
+//===-- APINotesYAMLCompiler.cpp - API Notes YAML Format Reader -*- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--

[PATCH] D88859: APINotes: add APINotesYAMLCompiler

[Saleem Abdulrasool 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 rG82f86ae01a54: APINotes: add APINotesYAMLCompiler (authored 
by compnerd).

Changed prior to commit:
  https://reviews.llvm.org/D88859?vs=302298&id=303192#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88859

Files:
  clang/include/clang/APINotes/APINotesYAMLCompiler.h
  clang/include/clang/APINotes/Types.h
  clang/lib/APINotes/APINotesYAMLCompiler.cpp
  clang/lib/APINotes/CMakeLists.txt
  clang/lib/CMakeLists.txt
  clang/test/APINotes/Inputs/Frameworks/Simple.framework/Headers/Simple.apinotes
  clang/test/APINotes/Inputs/Frameworks/Simple.framework/Headers/Simple.h
  
clang/test/APINotes/Inputs/Frameworks/SimpleKit.framework/Headers/SimpleKit.apinotes
  clang/test/APINotes/Inputs/Frameworks/SimpleKit.framework/Headers/SimpleKit.h
  
clang/test/APINotes/Inputs/Frameworks/SimpleKit.framework/Headers/module.modulemap
  clang/test/APINotes/yaml-roundtrip-2.test
  clang/test/APINotes/yaml-roundtrip.test
  clang/test/CMakeLists.txt
  clang/test/lit.cfg.py
  clang/tools/CMakeLists.txt
  clang/tools/apinotes-test/APINotesTest.cpp
  clang/tools/apinotes-test/CMakeLists.txt

Index: clang/tools/apinotes-test/CMakeLists.txt
===
--- /dev/null
+++ clang/tools/apinotes-test/CMakeLists.txt
@@ -0,0 +1,6 @@
+set(LLVM_LINK_COMPONENTS
+  Support)
+add_clang_executable(apinotes-test
+  APINotesTest.cpp)
+clang_target_link_libraries(apinotes-test PRIVATE
+  clangAPINotes)
Index: clang/tools/apinotes-test/APINotesTest.cpp
===
--- /dev/null
+++ clang/tools/apinotes-test/APINotesTest.cpp
@@ -0,0 +1,53 @@
+//===-- APINotesTest.cpp - API Notes Testing Tool -- C++ --===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang/APINotes/APINotesYAMLCompiler.h"
+#include "llvm/Support/CommandLine.h"
+#include "llvm/Support/Signals.h"
+#include "llvm/Support/ToolOutputFile.h"
+#include "llvm/Support/WithColor.h"
+
+static llvm::cl::list APINotes(llvm::cl::Positional,
+llvm::cl::desc("[ ...]"),
+llvm::cl::Required);
+
+static llvm::cl::opt
+OutputFileName("o", llvm::cl::desc("output filename"),
+   llvm::cl::value_desc("filename"), llvm::cl::init("-"));
+
+int main(int argc, const char **argv) {
+  const bool DisableCrashReporting = true;
+  llvm::sys::PrintStackTraceOnErrorSignal(argv[0], DisableCrashReporting);
+  llvm::cl::ParseCommandLineOptions(argc, argv);
+
+  auto Error = [](const llvm::Twine &Msg) {
+llvm::WithColor::error(llvm::errs(), "apinotes-test") << Msg << '\n';
+  };
+
+  std::error_code EC;
+  auto Out = std::make_unique(OutputFileName, EC,
+llvm::sys::fs::OF_None);
+  if (EC) {
+Error("failed to open '" + OutputFileName + "': " + EC.message());
+return EXIT_FAILURE;
+  }
+
+  for (const std::string &Notes : APINotes) {
+llvm::ErrorOr> NotesOrError =
+llvm::MemoryBuffer::getFileOrSTDIN(Notes);
+if (std::error_code EC = NotesOrError.getError()) {
+  llvm::errs() << EC.message() << '\n';
+  return EXIT_FAILURE;
+}
+
+clang::api_notes::parseAndDumpAPINotes((*NotesOrError)->getBuffer(),
+   Out->os());
+  }
+
+  return EXIT_SUCCESS;
+}
Index: clang/tools/CMakeLists.txt
===
--- clang/tools/CMakeLists.txt
+++ clang/tools/CMakeLists.txt
@@ -2,6 +2,7 @@
 
 add_clang_subdirectory(diagtool)
 add_clang_subdirectory(driver)
+add_clang_subdirectory(apinotes-test)
 add_clang_subdirectory(clang-diff)
 add_clang_subdirectory(clang-format)
 add_clang_subdirectory(clang-format-vs)
Index: clang/test/lit.cfg.py
===
--- clang/test/lit.cfg.py
+++ clang/test/lit.cfg.py
@@ -63,7 +63,8 @@
 tool_dirs = [config.clang_tools_dir, config.llvm_tools_dir]
 
 tools = [
-'c-index-test', 'clang-diff', 'clang-format', 'clang-tblgen', 'opt', 'llvm-ifs',
+'apinotes-test', 'c-index-test', 'clang-diff', 'clang-format',
+'clang-tblgen', 'opt', 'llvm-ifs',
 ToolSubst('%clang_extdef_map', command=FindTool(
 'clang-extdef-mapping'), unresolved='ignore'),
 ]
Index: clang/test/CMakeLists.txt
===
--- clang/test/CMakeLists.txt
+++ clang/test/CMakeLists.txt
@@ -58,6 +58,7 @@
 endif ()
 
 li

[clang] b69af88 - [gn build] (manually) port 82f86ae01

[Nico Weber via cfe-commits]

Author: Nico Weber
Date: 2020-11-05T14:11:26-05:00
New Revision: b69af88481aa88e04ff4490dc8d420ec570ec0f1

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

LOG: [gn build] (manually) port 82f86ae01

Added: 
llvm/utils/gn/secondary/clang/lib/APINotes/BUILD.gn
llvm/utils/gn/secondary/clang/tools/apinotes-test/BUILD.gn

Modified: 
clang/tools/apinotes-test/CMakeLists.txt
llvm/utils/gn/secondary/clang/test/BUILD.gn

Removed: 




diff  --git a/clang/tools/apinotes-test/CMakeLists.txt 
b/clang/tools/apinotes-test/CMakeLists.txt
index 39e82d90b74f..82c3b7bcb648 100644
--- a/clang/tools/apinotes-test/CMakeLists.txt
+++ b/clang/tools/apinotes-test/CMakeLists.txt
@@ -1,6 +1,7 @@
 set(LLVM_LINK_COMPONENTS
   Support)
 add_clang_executable(apinotes-test
-  APINotesTest.cpp)
+  APINotesTest.cpp
+  )
 clang_target_link_libraries(apinotes-test PRIVATE
   clangAPINotes)

diff  --git a/llvm/utils/gn/secondary/clang/lib/APINotes/BUILD.gn 
b/llvm/utils/gn/secondary/clang/lib/APINotes/BUILD.gn
new file mode 100644
index ..e49d3d08dc07
--- /dev/null
+++ b/llvm/utils/gn/secondary/clang/lib/APINotes/BUILD.gn
@@ -0,0 +1,9 @@
+static_library("APINotes") {
+  output_name = "clangAPINotes"
+  configs += [ "//llvm/utils/gn/build:clang_code" ]
+  deps = [
+"//clang/lib/Basic",
+"//llvm/lib/Support",
+  ]
+  sources = [ "APINotesYAMLCompiler.cpp" ]
+}

diff  --git a/llvm/utils/gn/secondary/clang/test/BUILD.gn 
b/llvm/utils/gn/secondary/clang/test/BUILD.gn
index a0680d984823..9219d2d7bfad 100644
--- a/llvm/utils/gn/secondary/clang/test/BUILD.gn
+++ b/llvm/utils/gn/secondary/clang/test/BUILD.gn
@@ -131,6 +131,7 @@ group("test") {
 ":lit_site_cfg",
 ":lit_unit_site_cfg",
 "//clang/lib/Headers",
+"//clang/tools/apinotes-test",
 "//clang/tools/c-index-test",
 "//clang/tools/clang-
diff ",
 "//clang/tools/clang-format",

diff  --git a/llvm/utils/gn/secondary/clang/tools/apinotes-test/BUILD.gn 
b/llvm/utils/gn/secondary/clang/tools/apinotes-test/BUILD.gn
new file mode 100644
index ..d9fce4156908
--- /dev/null
+++ b/llvm/utils/gn/secondary/clang/tools/apinotes-test/BUILD.gn
@@ -0,0 +1,7 @@
+executable("apinotes-test") {
+  configs += [ "//llvm/utils/gn/build:clang_code" ]
+  deps = [
+"//clang/lib/APINotes",
+  ]
+  sources = [ "APINotesTest.cpp" ]
+}



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

[PATCH] D90832: [clang-tidy] Extend IdentifierNamingCheck per file config

[Nathan James via Phabricator via cfe-commits]

njames93 updated this revision to Diff 303198.
njames93 added a comment.
Herald added a subscriber: aheejin.

Removed unnecessary formatting changes
Added test cases.

With the test cases I removed some cases that actually were never tested due to 
the order in which clang-tidy handles applying configurations. Right now there 
just isnt the infrastructure needed to fully test those cases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90832

Files:
  clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp
  clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.h
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-identifier-naming/global-style-disabled/.clang-tidy
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-identifier-naming/global-style-disabled/header.h
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-identifier-naming/global-style1/.clang-tidy
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-identifier-naming/global-style1/header.h
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-identifier-naming/global-style2/.clang-tidy
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-identifier-naming/global-style2/header.h
  
clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming-multiple-styles.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming-multiple-styles.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming-multiple-styles.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming-multiple-styles.cpp
@@ -13,6 +13,7 @@
 // RUN: readability-identifier-naming %t -- \
 // RUN:  -config='{ InheritParentConfig: true, CheckOptions: [ \
 // RUN:   {key: readability-identifier-naming.FunctionCase, value: camelBack}, \
+// RUN:   {key: readability-identifier-naming.ParameterCase, value: CamelCase}, \
 // RUN:   {key: readability-identifier-naming.GetConfigPerFile, value: true} \
 // RUN:  ]}' -header-filter='.*' -- -I%theaders
 
@@ -21,20 +22,14 @@
 // RUN: cp -R %S/Inputs/readability-identifier-naming/. %theaders
 // RUN: %check_clang_tidy -check-suffixes=DISABLED,SHARED -std=c++11 %s \
 // RUN: readability-identifier-naming %t -- \
-// RUN:  -config='{ InheritParentConfig: true, CheckOptions: [ \
+// RUN:  -config='{ InheritParentConfig: false, CheckOptions: [ \
 // RUN:   {key: readability-identifier-naming.FunctionCase, value: camelBack}, \
+// RUN:   {key: readability-identifier-naming.ParameterCase, value: CamelCase}, \
 // RUN:   {key: readability-identifier-naming.GetConfigPerFile, value: false} \
 // RUN:  ]}' -header-filter='.*' -- -I%theaders
 
-#include "global-style-disabled/header.h"
 #include "global-style1/header.h"
 #include "global-style2/header.h"
-// CHECK-MESSAGES-ENABLED-DAG: global-style1/header.h:5:6: warning: invalid case style for global function 'styleFirstBad'
-// CHECK-MESSAGES-ENABLED-DAG: global-style2/header.h:5:6: warning: invalid case style for global function 'styleSecondBad'
-// CHECK-MESSAGES-DISABLED-DAG: global-style1/header.h:3:6: warning: invalid case style for function 'style_first_good'
-// CHECK-MESSAGES-DISABLED-DAG: global-style2/header.h:3:6: warning: invalid case style for function 'STYLE_SECOND_GOOD'
-// CHECK-MESSAGES-DISABLED-DAG: global-style-disabled/header.h:1:6: warning: invalid case style for function 'disabled_style_1'
-// CHECK-MESSAGES-DISABLED-DAG: global-style-disabled/header.h:3:6: warning: invalid case style for function 'DISABLED_STYLE_3'
 
 void goodStyle() {
   style_first_good();
@@ -42,7 +37,7 @@
   //  CHECK-FIXES-DISABLED: styleFirstGood();
   // CHECK-FIXES-DISABLED-NEXT: styleSecondGood();
 }
-// CHECK-MESSAGES-SHARED-DAG: :[[@LINE+1]]:6: warning: invalid case style for function 'bad_style'
+// CHECK-MESSAGES-SHARED: :[[@LINE+1]]:6: warning: invalid case style for function 'bad_style'
 void bad_style() {
   styleFirstBad();
   styleSecondBad();
@@ -54,11 +49,14 @@
 //  CHECK-FIXES-ENABLED-NEXT:   STYLE_SECOND_BAD();
 //   CHECK-FIXES-SHARED-NEXT: }
 
-void expectNoStyle() {
-  disabled_style_1();
-  disabledStyle2();
-  DISABLED_STYLE_3();
-  //  CHECK-FIXES-DISABLED: disabledStyle1();
-  // CHECK-FIXES-DISABLED-NEXT: disabledStyle2();
-  // CHECK-FIXES-DISABLED-NEXT: disabledStyle3();
-}
+// CHECK-MESSAGES-DISABLED: global-style1/header.h:3:6: warning: invalid case style for function 'style_first_good'
+// CHECK-MESSAGES-ENABLED:  global-style1/header.h:5:6: warning: invalid case style for global function 'styleFirstBad'
+// CHECK-MESSAGES-ENABLED:  global-style1/header.h:7:5: warning: invalid case style for global function 'thisIsMainLikeIgnored'
+// CHECK-MESSAGES-DISABLED: global-style1/header.h:7:31: warning: invalid case style for parameter 'argc'
+// CHECK-MESSAGES-D

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

[Gulfem Savrun Yeniceri via Phabricator via cfe-commits]

gulfem updated this revision to Diff 303200.
gulfem added a comment.

Remove direct from description and ObjCMethod for Obj functionality


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90275

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/CodeGen/attr-leaf.c
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/Sema/attr-leaf.c
  llvm/include/llvm/Bitcode/LLVMBitCodes.h
  llvm/include/llvm/IR/Attributes.td
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/AsmParser/LLToken.h
  llvm/lib/Bitcode/Reader/BitcodeReader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/IR/Attributes.cpp
  llvm/lib/IR/Verifier.cpp
  llvm/lib/Transforms/Utils/CodeExtractor.cpp
  llvm/test/Bitcode/attributes.ll

Index: llvm/test/Bitcode/attributes.ll
===
--- llvm/test/Bitcode/attributes.ll
+++ llvm/test/Bitcode/attributes.ll
@@ -410,6 +410,12 @@
   ret void
 }
 
+; CHECK; define void @f70() #43
+define void @f70() nocallback
+{
+  ret void
+}
+
 ; CHECK: attributes #0 = { noreturn }
 ; CHECK: attributes #1 = { nounwind }
 ; CHECK: attributes #2 = { readnone }
@@ -453,4 +459,5 @@
 ; CHECK: attributes #40 = { null_pointer_is_valid }
 ; CHECK: attributes #41 = { mustprogress }
 ; CHECK: attributes #42 = { nossp }
+; CHECK: attributes #43 = { nocallback }
 ; CHECK: attributes #[[NOBUILTIN]] = { nobuiltin }
Index: llvm/lib/Transforms/Utils/CodeExtractor.cpp
===
--- llvm/lib/Transforms/Utils/CodeExtractor.cpp
+++ llvm/lib/Transforms/Utils/CodeExtractor.cpp
@@ -906,6 +906,7 @@
   case Attribute::NoRecurse:
   case Attribute::InlineHint:
   case Attribute::MinSize:
+  case Attribute::NoCallback:
   case Attribute::NoDuplicate:
   case Attribute::NoFree:
   case Attribute::NoImplicitFloat:
Index: llvm/lib/IR/Verifier.cpp
===
--- llvm/lib/IR/Verifier.cpp
+++ llvm/lib/IR/Verifier.cpp
@@ -1572,6 +1572,7 @@
   case Attribute::NoReturn:
   case Attribute::NoSync:
   case Attribute::WillReturn:
+  case Attribute::NoCallback:
   case Attribute::NoCfCheck:
   case Attribute::NoUnwind:
   case Attribute::NoInline:
Index: llvm/lib/IR/Attributes.cpp
===
--- llvm/lib/IR/Attributes.cpp
+++ llvm/lib/IR/Attributes.cpp
@@ -371,6 +371,8 @@
 return "noalias";
   if (hasAttribute(Attribute::NoBuiltin))
 return "nobuiltin";
+  if (hasAttribute(Attribute::NoCallback))
+return "nocallback";
   if (hasAttribute(Attribute::NoCapture))
 return "nocapture";
   if (hasAttribute(Attribute::NoDuplicate))
Index: llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
===
--- llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
+++ llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
@@ -643,6 +643,8 @@
 return bitc::ATTR_KIND_NO_ALIAS;
   case Attribute::NoBuiltin:
 return bitc::ATTR_KIND_NO_BUILTIN;
+  case Attribute::NoCallback:
+return bitc::ATTR_KIND_NO_CALLBACK;
   case Attribute::NoCapture:
 return bitc::ATTR_KIND_NO_CAPTURE;
   case Attribute::NoDuplicate:
Index: llvm/lib/Bitcode/Reader/BitcodeReader.cpp
===
--- llvm/lib/Bitcode/Reader/BitcodeReader.cpp
+++ llvm/lib/Bitcode/Reader/BitcodeReader.cpp
@@ -1433,6 +1433,8 @@
 return Attribute::NoAlias;
   case bitc::ATTR_KIND_NO_BUILTIN:
 return Attribute::NoBuiltin;
+  case bitc::ATTR_KIND_NO_CALLBACK:
+return Attribute::NoCallback;
   case bitc::ATTR_KIND_NO_CAPTURE:
 return Attribute::NoCapture;
   case bitc::ATTR_KIND_NO_DUPLICATE:
Index: llvm/lib/AsmParser/LLToken.h
===
--- llvm/lib/AsmParser/LLToken.h
+++ llvm/lib/AsmParser/LLToken.h
@@ -198,6 +198,7 @@
   kw_noalias,
   kw_noundef,
   kw_nobuiltin,
+  kw_nocallback,
   kw_nocapture,
   kw_noduplicate,
   kw_nofree,
Index: llvm/lib/AsmParser/LLParser.cpp
===
--- llvm/lib/AsmParser/LLParser.cpp
+++ llvm/lib/AsmParser/LLParser.cpp
@@ -1314,6 +1314,9 @@
   break;
 case lltok::kw_naked: B.addAttribute(Attribute::Naked); break;
 case lltok::kw_nobuiltin: B.addAttribute(Attribute::NoBuiltin); break;
+case lltok::kw_nocallback:
+  B.addAttribute(Attribute::NoCallback);
+  break;
 case lltok::kw_noduplicate: B.addAttribute(Attribute::NoDuplicate); break;
 case lltok::kw_nofree: B.addAttribute(Attribute::NoFree); break;
 case lltok::kw_noimplicitfloat:
Index: llvm/lib/AsmParser/LLLexer.cpp

[PATCH] D90714: [clang]Fix length threshold for MicrosoftMangle md5 hash

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

In D90714#2375911 , @mibintc wrote:

> In D90714#2374913 , @dblaikie wrote:
>
>> Since the same code is used to mangle all these things, probably just test 
>> one of them?
>>
>> Could use macros to stamp out longer names without having to write them out 
>> manually?
>
> Not sure what technique to use to stamp out longer names, I tried using token 
> pasting but that doesn't work because the tokens aren't macro expanded before 
> pasting?
> #define X50 xx
> #define X45 x
> #define X100 X50 ## X50  // X100 is X50X50

Yeah, there's a quirk of the preprocessor that means you need an extra level of 
indirection, like this:

  #define C(X) X ## X
  // X2: X * 2
  #define X2(X) C(X)
  // X8: X * 2^3 (8)
  #define X8(X) X2(X2(X2(X)))
  // X4096: X * 8^4 (4096)
  #define X4096(X) X8(X8(X8(X8(X
  void X4096(x)() {
  }

https://godbolt.org/z/r6Evae

>   I like the test source I added because it came from a program seen in the 
> wild, and it demonstrates that reasonable length identifiers can generate 
> enormous mangled names.

I think using a very plain name (like "lots of 'x'") helps clarify the test 
case is only about length - not about any other property of the name. A comment 
describing how templates (& especially template default parameters) can lead to 
long names could be good, though.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90714

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

[PATCH] D90832: [clang-tidy] Extend IdentifierNamingCheck per file config

[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 aside from some tiny nits!




Comment at: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp:172
   SmallString<64> StyleString;
+  auto Styles = MainFileStyle->getStyles();
   for (size_t I = 0; I < SK_Count; ++I) {

Don't use `auto` when the type isn't spelled out in the initialization.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming-multiple-styles.cpp:63
+// CHECK-MESSAGES-SHARED:   global-style2/header.h:7:52: warning: invalid case 
style for parameter 'argv'
\ No newline at end of file


Should end the newline back to the end of the file.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90832

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

[PATCH] D90870: [NFC][NewPM] Reuse PassBuilder callbacks with -O0

[Arthur Eubanks via Phabricator via cfe-commits]

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

This removes lots of duplicated code which was necessary before
https://reviews.llvm.org/D89158. Mostly sanitizer stuff.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D90870

Files:
  clang/lib/CodeGen/BackendUtil.cpp

Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -1057,67 +1057,6 @@
   MPM.addPass(createModuleToFunctionPassAdaptor(CoroCleanupPass()));
 }
 
-static void addSanitizersAtO0(ModulePassManager &MPM,
-  const Triple &TargetTriple,
-  const LangOptions &LangOpts,
-  const CodeGenOptions &CodeGenOpts) {
-  if (CodeGenOpts.SanitizeCoverageType ||
-  CodeGenOpts.SanitizeCoverageIndirectCalls ||
-  CodeGenOpts.SanitizeCoverageTraceCmp) {
-auto SancovOpts = getSancovOptsFromCGOpts(CodeGenOpts);
-MPM.addPass(ModuleSanitizerCoveragePass(
-SancovOpts, CodeGenOpts.SanitizeCoverageAllowlistFiles,
-CodeGenOpts.SanitizeCoverageBlocklistFiles));
-  }
-
-  auto ASanPass = [&](SanitizerMask Mask, bool CompileKernel) {
-MPM.addPass(RequireAnalysisPass());
-bool Recover = CodeGenOpts.SanitizeRecover.has(Mask);
-MPM.addPass(createModuleToFunctionPassAdaptor(AddressSanitizerPass(
-CompileKernel, Recover, CodeGenOpts.SanitizeAddressUseAfterScope)));
-bool ModuleUseAfterScope = asanUseGlobalsGC(TargetTriple, CodeGenOpts);
-MPM.addPass(
-ModuleAddressSanitizerPass(CompileKernel, Recover, ModuleUseAfterScope,
-   CodeGenOpts.SanitizeAddressUseOdrIndicator));
-  };
-
-  if (LangOpts.Sanitize.has(SanitizerKind::Address)) {
-ASanPass(SanitizerKind::Address, /*CompileKernel=*/false);
-  }
-
-  if (LangOpts.Sanitize.has(SanitizerKind::KernelAddress)) {
-ASanPass(SanitizerKind::KernelAddress, /*CompileKernel=*/true);
-  }
-
-  if (LangOpts.Sanitize.has(SanitizerKind::HWAddress)) {
-bool Recover = CodeGenOpts.SanitizeRecover.has(SanitizerKind::HWAddress);
-MPM.addPass(HWAddressSanitizerPass(
-/*CompileKernel=*/false, Recover));
-  }
-  if (LangOpts.Sanitize.has(SanitizerKind::KernelHWAddress)) {
-MPM.addPass(HWAddressSanitizerPass(
-/*CompileKernel=*/true, /*Recover=*/true));
-  }
-
-  if (LangOpts.Sanitize.has(SanitizerKind::Memory)) {
-bool Recover = CodeGenOpts.SanitizeRecover.has(SanitizerKind::Memory);
-int TrackOrigins = CodeGenOpts.SanitizeMemoryTrackOrigins;
-MPM.addPass(MemorySanitizerPass({TrackOrigins, Recover, false}));
-MPM.addPass(createModuleToFunctionPassAdaptor(
-MemorySanitizerPass({TrackOrigins, Recover, false})));
-  }
-
-  if (LangOpts.Sanitize.has(SanitizerKind::KernelMemory)) {
-MPM.addPass(createModuleToFunctionPassAdaptor(
-MemorySanitizerPass({0, false, /*Kernel=*/true})));
-  }
-
-  if (LangOpts.Sanitize.has(SanitizerKind::Thread)) {
-MPM.addPass(ThreadSanitizerPass());
-MPM.addPass(createModuleToFunctionPassAdaptor(ThreadSanitizerPass()));
-  }
-}
-
 /// A clean version of `EmitAssembly` that uses the new pass manager.
 ///
 /// Not all features are currently supported in this system, but where
@@ -1254,30 +1193,134 @@
 bool IsThinLTO = CodeGenOpts.PrepareForThinLTO;
 bool IsLTO = CodeGenOpts.PrepareForLTO;
 
-if (CodeGenOpts.OptimizationLevel == 0) {
-  // If we reached here with a non-empty index file name, then the index
-  // file was empty and we are not performing ThinLTO backend compilation
-  // (used in testing in a distributed build environment). Drop any the type
-  // test assume sequences inserted for whole program vtables so that
-  // codegen doesn't complain.
-  if (!CodeGenOpts.ThinLTOIndexFile.empty())
-MPM.addPass(LowerTypeTestsPass(/*ExportSummary=*/nullptr,
-   /*ImportSummary=*/nullptr,
-   /*DropTypeTests=*/true));
-  if (Optional Options = getGCOVOptions(CodeGenOpts, LangOpts))
-MPM.addPass(GCOVProfilerPass(*Options));
-  if (Optional Options =
-  getInstrProfOptions(CodeGenOpts, LangOpts))
-MPM.addPass(InstrProfiling(*Options, false));
+// If we reached here with a non-empty index file name, then the index
+// file was empty and we are not performing ThinLTO backend compilation
+// (used in testing in a distributed build environment). Drop any the type
+// test assume sequences inserted for whole program vtables so that
+// codegen doesn't complain.
+if (!CodeGenOpts.ThinLTOIndexFile.empty())
+  PB.registerPipelineStartEPCallback(
+  [](ModulePassManager &MPM, PassBuilder::OptimizationLevel Level) {
+MPM.addPass(Lo

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

[Gulfem Savrun Yeniceri via Phabricator via cfe-commits]

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



Comment at: clang/include/clang/Basic/Attr.td:1435
+  let Spellings = [GCC<"leaf">];
+  let Subjects = SubjectList<[Function]>;
+  let Documentation = [Undocumented];

aaron.ballman wrote:
> gulfem wrote:
> > aaron.ballman wrote:
> > > gulfem wrote:
> > > > aaron.ballman wrote:
> > > > > Should this attribute also be supported on things like ObjC method 
> > > > > decls or other function-like interfaces?
> > > > Do I need to do anything else to support this attribute in Objective-C 
> > > > as well?
> > > > I think we should support it in all the C languages family.
> > > >I think we should support it in all the C languages family.
> > > 
> > > That's already happening automatically -- there's a C and C++ spelling 
> > > available for it and the attribute doesn't specify that it requires a 
> > > particular language mode or target.
> > > 
> > > > Do I need to do anything else to support this attribute in Objective-C 
> > > > as well?
> > > You can add multiple subjects to the list here, so you can have this 
> > > apply to `Function, ObjCMethod` for both of those. Another one to 
> > > consider is whether this attribute can be written on a block declaration 
> > > (like a lambda, but with different syntax). Beyond that, it's mostly just 
> > > documentation, devising the test cases to ensure the ObjC functionality 
> > > behaves as expected, possibly some codegen changes, etc.
> > AFAIK, users can specify function attributes in lambda expressions.
> > Lambda functions can only be accessed/called by the functions in the same 
> > translation unit, right?
> > Leaf attribute does not have any effect on the functions that are defined 
> > in the same translation unit.
> > For this reason, I'm thinking that leaf attribute would not have any effect 
> > if they are used in lambda expressions.
> > Do you agree with me?
> > AFAIK, users can specify function attributes in lambda expressions.
> 
> I always forget that you can do that for declaration attributes using 
> GNU-style syntax...
> 
> > Lambda functions can only be accessed/called by the functions in the same 
> > translation unit, right?
> 
> Not necessarily, you could pass one across TU boundaries like a function 
> pointer, for instance. e.g.,
> ```
> // TU1.cpp
> void foo() {
>   auto l = []() { ... };
>   bar(l);
> }
> 
> // TU2.cpp
> void bar(auto func) {
>   func();
> }
> ```
> Not necessarily, you could pass one across TU boundaries like a function 
> pointer, for instance. e.g.,
As I mentioned before, leaf attribute is specifically intended for library 
functions and I think all the existing usage of leaf attribute is in the 
library function declarations. For this reason, I think we do not need to 
support them for lambdas. Is that reasonable?




Comment at: clang/include/clang/Basic/AttrDocs.td:3910
+in library functions. Functions marked with the ``leaf`` attribute are not 
allowed
+to jump back into the caller's translation unit, whether through invoking a
+callback function, a direct external function call, use of ``longjmp``, or 
other means.

aaron.ballman wrote:
> gulfem wrote:
> > aaron.ballman wrote:
> > > gulfem wrote:
> > > > I think this property is transitive. 
> > > > If a leaf function somehow enters into caller's translation unit 
> > > > (either via direct call or a via its call chain), it will violate the 
> > > > rule that says "Calls to external functions with this attribute must 
> > > > return to the current compilation unit only by return or by exception 
> > > > handling". 
> > > > Entering via its call chain is not a return or an exception handling.
> > > > Do you agree with that?
> > > > I think this property is transitive. ... Do you agree with that?
> > > 
> > > That makes sense to me! I think I'd recommend a slight modification to 
> > > the docs then:
> > > 
> > > ```
> > > Functions marked with the ``leaf`` attribute are not allowed to jump back 
> > > into the caller's translation unit, whether through invoking a callback 
> > > function, a direct, possibly transitive, external function call, use of 
> > > ``longjmp``, or other means.
> > > ```
> > > The last question is: by "direct" does the GCC docs imply that calls back 
> > > to the caller's TU through a function *pointer* are not UB? I'd imagine 
> > > those would also be bad, but I'd like to make sure (and perhaps we can 
> > > remove the `direct` from the wording if calls through function pointers 
> > > are disallowed).
> > I think the idea is that the control-flow should never come back to the 
> > caller's translation unit by any kind of control-flow changing mechanism 
> > (direct/indirect and call/jump).
> > The compiler might use this hint to do optimizations based on that 
> > assumption, so the user should ensure that.
> > Could you please explain what do you mean by calling back via function 
> > pointer?
> > I th

[PATCH] D90870: [NFC][NewPM] Reuse PassBuilder callbacks with -O0

[Arthur Eubanks via Phabricator via cfe-commits]

aeubanks updated this revision to Diff 303207.
aeubanks added a comment.

small cleanups


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90870

Files:
  clang/lib/CodeGen/BackendUtil.cpp

Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -1057,67 +1057,6 @@
   MPM.addPass(createModuleToFunctionPassAdaptor(CoroCleanupPass()));
 }
 
-static void addSanitizersAtO0(ModulePassManager &MPM,
-  const Triple &TargetTriple,
-  const LangOptions &LangOpts,
-  const CodeGenOptions &CodeGenOpts) {
-  if (CodeGenOpts.SanitizeCoverageType ||
-  CodeGenOpts.SanitizeCoverageIndirectCalls ||
-  CodeGenOpts.SanitizeCoverageTraceCmp) {
-auto SancovOpts = getSancovOptsFromCGOpts(CodeGenOpts);
-MPM.addPass(ModuleSanitizerCoveragePass(
-SancovOpts, CodeGenOpts.SanitizeCoverageAllowlistFiles,
-CodeGenOpts.SanitizeCoverageBlocklistFiles));
-  }
-
-  auto ASanPass = [&](SanitizerMask Mask, bool CompileKernel) {
-MPM.addPass(RequireAnalysisPass());
-bool Recover = CodeGenOpts.SanitizeRecover.has(Mask);
-MPM.addPass(createModuleToFunctionPassAdaptor(AddressSanitizerPass(
-CompileKernel, Recover, CodeGenOpts.SanitizeAddressUseAfterScope)));
-bool ModuleUseAfterScope = asanUseGlobalsGC(TargetTriple, CodeGenOpts);
-MPM.addPass(
-ModuleAddressSanitizerPass(CompileKernel, Recover, ModuleUseAfterScope,
-   CodeGenOpts.SanitizeAddressUseOdrIndicator));
-  };
-
-  if (LangOpts.Sanitize.has(SanitizerKind::Address)) {
-ASanPass(SanitizerKind::Address, /*CompileKernel=*/false);
-  }
-
-  if (LangOpts.Sanitize.has(SanitizerKind::KernelAddress)) {
-ASanPass(SanitizerKind::KernelAddress, /*CompileKernel=*/true);
-  }
-
-  if (LangOpts.Sanitize.has(SanitizerKind::HWAddress)) {
-bool Recover = CodeGenOpts.SanitizeRecover.has(SanitizerKind::HWAddress);
-MPM.addPass(HWAddressSanitizerPass(
-/*CompileKernel=*/false, Recover));
-  }
-  if (LangOpts.Sanitize.has(SanitizerKind::KernelHWAddress)) {
-MPM.addPass(HWAddressSanitizerPass(
-/*CompileKernel=*/true, /*Recover=*/true));
-  }
-
-  if (LangOpts.Sanitize.has(SanitizerKind::Memory)) {
-bool Recover = CodeGenOpts.SanitizeRecover.has(SanitizerKind::Memory);
-int TrackOrigins = CodeGenOpts.SanitizeMemoryTrackOrigins;
-MPM.addPass(MemorySanitizerPass({TrackOrigins, Recover, false}));
-MPM.addPass(createModuleToFunctionPassAdaptor(
-MemorySanitizerPass({TrackOrigins, Recover, false})));
-  }
-
-  if (LangOpts.Sanitize.has(SanitizerKind::KernelMemory)) {
-MPM.addPass(createModuleToFunctionPassAdaptor(
-MemorySanitizerPass({0, false, /*Kernel=*/true})));
-  }
-
-  if (LangOpts.Sanitize.has(SanitizerKind::Thread)) {
-MPM.addPass(ThreadSanitizerPass());
-MPM.addPass(createModuleToFunctionPassAdaptor(ThreadSanitizerPass()));
-  }
-}
-
 /// A clean version of `EmitAssembly` that uses the new pass manager.
 ///
 /// Not all features are currently supported in this system, but where
@@ -1254,188 +1193,140 @@
 bool IsThinLTO = CodeGenOpts.PrepareForThinLTO;
 bool IsLTO = CodeGenOpts.PrepareForLTO;
 
-if (CodeGenOpts.OptimizationLevel == 0) {
-  // If we reached here with a non-empty index file name, then the index
-  // file was empty and we are not performing ThinLTO backend compilation
-  // (used in testing in a distributed build environment). Drop any the type
-  // test assume sequences inserted for whole program vtables so that
-  // codegen doesn't complain.
-  if (!CodeGenOpts.ThinLTOIndexFile.empty())
-MPM.addPass(LowerTypeTestsPass(/*ExportSummary=*/nullptr,
-   /*ImportSummary=*/nullptr,
-   /*DropTypeTests=*/true));
-  if (Optional Options = getGCOVOptions(CodeGenOpts, LangOpts))
-MPM.addPass(GCOVProfilerPass(*Options));
-  if (Optional Options =
-  getInstrProfOptions(CodeGenOpts, LangOpts))
-MPM.addPass(InstrProfiling(*Options, false));
-
-  // Build a minimal pipeline based on the semantics required by Clang,
-  // which is just that always inlining occurs. Further, disable generating
-  // lifetime intrinsics to avoid enabling further optimizations during
-  // code generation.
-  // However, we need to insert lifetime intrinsics to avoid invalid access
-  // caused by multithreaded coroutines.
-  MPM.addPass(
-  AlwaysInlinerPass(/*InsertLifetimeIntrinsics=*/LangOpts.Coroutines));
-
-  // At -O0, we can still do PGO. Add all the requested passes for
-  // instrumentation PGO, if requested.
-  if (PGOOpt && (PGOOpt->Action =

[PATCH] D90714: [clang]Fix length threshold for MicrosoftMangle md5 hash

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

In D90714#2376667 , @rnk wrote:

> lgtm
>
> I think the test case looks good as is, FWIW. Token pasting might make it 
> more readable, but it's improving the existing test, and not necessarily in 
> scope for this patch.

Oh, sorry, didn't see that the big long contiguous identifiers were existing 
testing.

I'm even more inclined towards suggesting the new testing is not the way I'd 
prefer to go - especially in comparison to the existing testing. The new 
testing seems to really obscure that the length of the identifier is the 
important property, by adding a bunch of other features (templates, default 
template arguments, etc, etc) to the test that don't impact the logic under 
test - certainly for me that makes it quite a bit less clear what the goal of 
the test is, and so how to read and maintain it in the future.

(but yeah, sorry, didn't mean to suggest the token pasting cleanup as part of 
this test - I'd misread the delta - but if token pasting makes it easier to add 
a new test that could be consistent with (after cleaning up the old test - 
before or after this commit) other tests here, it seems relevant in that regard)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90714

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

[PATCH] D90507: Adding DWARF64 clang flag

[Alexander Yermolovich via Phabricator via cfe-commits]

ayermolo updated this revision to Diff 303209.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90507

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp


Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -905,6 +905,7 @@
   Args.hasFlag(OPT_fcoverage_mapping, OPT_fno_coverage_mapping, false);
   Opts.DumpCoverageMapping = Args.hasArg(OPT_dump_coverage_mapping);
   Opts.AsmVerbose = !Args.hasArg(OPT_fno_verbose_asm);
+  Opts.Dwarf64 = Args.hasArg(OPT_gdwarf64);
   Opts.PreserveAsmComments = !Args.hasArg(OPT_fno_preserve_as_comments);
   Opts.AssumeSaneOperatorNew = !Args.hasArg(OPT_fno_assume_sane_operator_new);
   Opts.ObjCAutoRefCountExceptions = Args.hasArg(OPT_fobjc_arc_exceptions);
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4760,6 +4760,9 @@
 IsIntegratedAssemblerDefault))
 CmdArgs.push_back("-fno-verbose-asm");
 
+  if (Args.hasArg(options::OPT_gdwarf64))
+CmdArgs.push_back("-gdwarf64");
+
   if (!TC.useIntegratedAs())
 CmdArgs.push_back("-no-integrated-as");
 
Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -561,6 +561,7 @@
   Options.MCOptions.MCFatalWarnings = CodeGenOpts.FatalWarnings;
   Options.MCOptions.MCNoWarn = CodeGenOpts.NoWarn;
   Options.MCOptions.AsmVerbose = CodeGenOpts.AsmVerbose;
+  Options.MCOptions.Dwarf64 = CodeGenOpts.Dwarf64;
   Options.MCOptions.PreserveAsmComments = CodeGenOpts.PreserveAsmComments;
   Options.MCOptions.ABIName = TargetOpts.ABI;
   for (const auto &Entry : HSOpts.UserEntries)
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -2084,6 +2084,8 @@
   HelpText<"Generate source-level debug information with dwarf version 4">;
 def gdwarf_5 : Flag<["-"], "gdwarf-5">, Group,
   HelpText<"Generate source-level debug information with dwarf version 5">;
+def gdwarf64 : Flag<["-"], "gdwarf64">, Group, Flags<[CC1Option]>,
+  HelpText<"Generate DWARF64 debug information.">;
 
 def gcodeview : Flag<["-"], "gcodeview">,
   HelpText<"Generate CodeView debug information">,
Index: clang/include/clang/Basic/CodeGenOptions.def
===
--- clang/include/clang/Basic/CodeGenOptions.def
+++ clang/include/clang/Basic/CodeGenOptions.def
@@ -32,6 +32,7 @@
 llvm::DebugCompressionType::None)
 CODEGENOPT(RelaxELFRelocations, 1, 0) ///< -Wa,--mrelax-relocations
 CODEGENOPT(AsmVerbose, 1, 0) ///< -dA, -fverbose-asm.
+CODEGENOPT(Dwarf64   , 1, 0) ///< -gdwarf64.
 CODEGENOPT(PreserveAsmComments, 1, 1) ///< -dA, -fno-preserve-as-comments.
 CODEGENOPT(AssumeSaneOperatorNew , 1, 1) ///< implicit __attribute__((malloc)) 
operator new
 CODEGENOPT(Autolink  , 1, 1) ///< -fno-autolink


Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -905,6 +905,7 @@
   Args.hasFlag(OPT_fcoverage_mapping, OPT_fno_coverage_mapping, false);
   Opts.DumpCoverageMapping = Args.hasArg(OPT_dump_coverage_mapping);
   Opts.AsmVerbose = !Args.hasArg(OPT_fno_verbose_asm);
+  Opts.Dwarf64 = Args.hasArg(OPT_gdwarf64);
   Opts.PreserveAsmComments = !Args.hasArg(OPT_fno_preserve_as_comments);
   Opts.AssumeSaneOperatorNew = !Args.hasArg(OPT_fno_assume_sane_operator_new);
   Opts.ObjCAutoRefCountExceptions = Args.hasArg(OPT_fobjc_arc_exceptions);
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4760,6 +4760,9 @@
 IsIntegratedAssemblerDefault))
 CmdArgs.push_back("-fno-verbose-asm");
 
+  if (Args.hasArg(options::OPT_gdwarf64))
+CmdArgs.push_back("-gdwarf64");
+
   if (!TC.useIntegratedAs())
 CmdArgs.push_back("-no-integrated-as");
 
Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -561,6 +561,7 @@
   Options.MCOptions.MCFatalWarnings = CodeGenOpts.FatalWarnings;
   Options.MCOpt

[PATCH] D90174: [HIP] Fix regressions due to fp contract change

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Okay.  It sounds like strict compatibility with GCC implies ignoring pragmas in 
fast, and that's what we're most concerned with, since this is originally a GCC 
option.  So the only question I have now is whether `faststd` is the best name 
for this.  Does anyone want to suggest an alternative?


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

https://reviews.llvm.org/D90174

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

[PATCH] D90767: Add new matchers for dependent names in templates

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:2838
 
+/// Matches template-dependent, but known, member names
+///

Missing full stop at the end of the comment.



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:2859
+AST_MATCHER_P(CXXDependentScopeMemberExpr, hasMemberName, std::string, N) {
+  return Node.getMember().getAsString() == N;
+}

This will allow users to match on members that don't have identifiers -- is 
that intentional? If not, my recommendation is to use something like:
```
if (const IdentifierInfo *II = Node.getMember().getAsIdentifierInfo())
  return II->isStr(N);
return false;
```
Either way, we should document and test what the expected behavior is for 
things like constructors/destructors, overloaded operators, and the likes. (But 
we don't have to test every kind of odd declaration name.)



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:2898
+  std::string, BindingID) {
+  auto MemberName = Node.getMember().getAsString();
+

Similar concerns here about matching members without identifiers.



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:2902
+  MemberName](const BoundNodesMap &Nodes) {
+auto BN = Nodes.getNode(this->BindingID);
+if (auto ND = BN.get()) {

I assume this is a `const auto &` and not a value type? If so, please update 
the type.



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:2903
+auto BN = Nodes.getNode(this->BindingID);
+if (auto ND = BN.get()) {
+  if (!(isa(ND) || isa(ND) || isa(ND)))

`const auto *`



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:2904
+if (auto ND = BN.get()) {
+  if (!(isa(ND) || isa(ND) || isa(ND)))
+return true;

`!isa(ND)`



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:2906-2908
+  if (ND->getName() == MemberName)
+return false;
+  return true;

`return ND->getName() != MemberName;`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90767

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

[PATCH] D90832: [clang-tidy] Extend IdentifierNamingCheck per file config

[Nathan James 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 rG3b9b90a1914f: [clang-tidy] Extend IdentifierNamingCheck per 
file config (authored by njames93).

Changed prior to commit:
  https://reviews.llvm.org/D90832?vs=303198&id=303214#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90832

Files:
  clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp
  clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.h
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-identifier-naming/global-style-disabled/.clang-tidy
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-identifier-naming/global-style-disabled/header.h
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-identifier-naming/global-style1/.clang-tidy
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-identifier-naming/global-style1/header.h
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-identifier-naming/global-style2/.clang-tidy
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-identifier-naming/global-style2/header.h
  
clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming-multiple-styles.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming-multiple-styles.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming-multiple-styles.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming-multiple-styles.cpp
@@ -13,6 +13,7 @@
 // RUN: readability-identifier-naming %t -- \
 // RUN:  -config='{ InheritParentConfig: true, CheckOptions: [ \
 // RUN:   {key: readability-identifier-naming.FunctionCase, value: camelBack}, \
+// RUN:   {key: readability-identifier-naming.ParameterCase, value: CamelCase}, \
 // RUN:   {key: readability-identifier-naming.GetConfigPerFile, value: true} \
 // RUN:  ]}' -header-filter='.*' -- -I%theaders
 
@@ -21,20 +22,14 @@
 // RUN: cp -R %S/Inputs/readability-identifier-naming/. %theaders
 // RUN: %check_clang_tidy -check-suffixes=DISABLED,SHARED -std=c++11 %s \
 // RUN: readability-identifier-naming %t -- \
-// RUN:  -config='{ InheritParentConfig: true, CheckOptions: [ \
+// RUN:  -config='{ InheritParentConfig: false, CheckOptions: [ \
 // RUN:   {key: readability-identifier-naming.FunctionCase, value: camelBack}, \
+// RUN:   {key: readability-identifier-naming.ParameterCase, value: CamelCase}, \
 // RUN:   {key: readability-identifier-naming.GetConfigPerFile, value: false} \
 // RUN:  ]}' -header-filter='.*' -- -I%theaders
 
-#include "global-style-disabled/header.h"
 #include "global-style1/header.h"
 #include "global-style2/header.h"
-// CHECK-MESSAGES-ENABLED-DAG: global-style1/header.h:5:6: warning: invalid case style for global function 'styleFirstBad'
-// CHECK-MESSAGES-ENABLED-DAG: global-style2/header.h:5:6: warning: invalid case style for global function 'styleSecondBad'
-// CHECK-MESSAGES-DISABLED-DAG: global-style1/header.h:3:6: warning: invalid case style for function 'style_first_good'
-// CHECK-MESSAGES-DISABLED-DAG: global-style2/header.h:3:6: warning: invalid case style for function 'STYLE_SECOND_GOOD'
-// CHECK-MESSAGES-DISABLED-DAG: global-style-disabled/header.h:1:6: warning: invalid case style for function 'disabled_style_1'
-// CHECK-MESSAGES-DISABLED-DAG: global-style-disabled/header.h:3:6: warning: invalid case style for function 'DISABLED_STYLE_3'
 
 void goodStyle() {
   style_first_good();
@@ -42,7 +37,7 @@
   //  CHECK-FIXES-DISABLED: styleFirstGood();
   // CHECK-FIXES-DISABLED-NEXT: styleSecondGood();
 }
-// CHECK-MESSAGES-SHARED-DAG: :[[@LINE+1]]:6: warning: invalid case style for function 'bad_style'
+// CHECK-MESSAGES-SHARED: :[[@LINE+1]]:6: warning: invalid case style for function 'bad_style'
 void bad_style() {
   styleFirstBad();
   styleSecondBad();
@@ -54,11 +49,14 @@
 //  CHECK-FIXES-ENABLED-NEXT:   STYLE_SECOND_BAD();
 //   CHECK-FIXES-SHARED-NEXT: }
 
-void expectNoStyle() {
-  disabled_style_1();
-  disabledStyle2();
-  DISABLED_STYLE_3();
-  //  CHECK-FIXES-DISABLED: disabledStyle1();
-  // CHECK-FIXES-DISABLED-NEXT: disabledStyle2();
-  // CHECK-FIXES-DISABLED-NEXT: disabledStyle3();
-}
+// CHECK-MESSAGES-DISABLED: global-style1/header.h:3:6: warning: invalid case style for function 'style_first_good'
+// CHECK-MESSAGES-ENABLED:  global-style1/header.h:5:6: warning: invalid case style for global function 'styleFirstBad'
+// CHECK-MESSAGES-ENABLED:  global-style1/header.h:7:5: warning: invalid case style for global function 'thisIsMainLikeIgnored'
+// CHECK-MESSAGES-DISABLED: global-style1/header.h:7:31: warning: invalid case style for parameter 'argc'
+// CHECK-MESSAGES-DISABLED: global-style1/header.h:7:49: warning: invalid case sty

[PATCH] D90809: [amdgpu] Add `llvm.amdgcn.endpgm` support.

[Michael Liao via Phabricator via cfe-commits]

hliao updated this revision to Diff 303213.
hliao added a comment.

Add `IntrCold`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90809

Files:
  clang/include/clang/Basic/BuiltinsAMDGPU.def
  clang/test/CodeGenCUDA/builtins-amdgcn.cu
  llvm/include/llvm/IR/IntrinsicsAMDGPU.td
  llvm/lib/Target/AMDGPU/SOPInstructions.td
  llvm/test/CodeGen/AMDGPU/amd.endpgm.ll

Index: llvm/test/CodeGen/AMDGPU/amd.endpgm.ll
===
--- /dev/null
+++ llvm/test/CodeGen/AMDGPU/amd.endpgm.ll
@@ -0,0 +1,50 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -march=amdgcn -mcpu=gfx900 -verify-machineinstrs < %s | FileCheck %s
+
+define amdgpu_kernel void @test0() {
+; CHECK-LABEL: test0:
+; CHECK:   ; %bb.0:
+; CHECK-NEXT:s_endpgm
+  tail call void @llvm.amdgcn.endpgm()
+  unreachable
+}
+
+define void @test1() {
+; CHECK-LABEL: test1:
+; CHECK:   ; %bb.0:
+; CHECK-NEXT:s_waitcnt vmcnt(0) expcnt(0) lgkmcnt(0)
+; CHECK-NEXT:s_endpgm
+  tail call void @llvm.amdgcn.endpgm()
+  unreachable
+}
+
+define amdgpu_kernel void @test2(i32* %p, i32 %x) {
+; CHECK-LABEL: test2:
+; CHECK:   ; %bb.0:
+; CHECK-NEXT:s_load_dword s2, s[0:1], 0x2c
+; CHECK-NEXT:s_waitcnt lgkmcnt(0)
+; CHECK-NEXT:s_cmp_lt_i32 s2, 1
+; CHECK-NEXT:s_cbranch_scc0 BB2_2
+; CHECK-NEXT:  ; %bb.1: ; %else
+; CHECK-NEXT:s_load_dwordx2 s[0:1], s[0:1], 0x24
+; CHECK-NEXT:v_mov_b32_e32 v2, s2
+; CHECK-NEXT:s_waitcnt lgkmcnt(0)
+; CHECK-NEXT:v_mov_b32_e32 v0, s0
+; CHECK-NEXT:v_mov_b32_e32 v1, s1
+; CHECK-NEXT:flat_store_dword v[0:1], v2
+; CHECK-NEXT:s_endpgm
+; CHECK-NEXT:  BB2_2: ; %then
+; CHECK-NEXT:s_endpgm
+  %cond = icmp sgt i32 %x, 0
+  br i1 %cond, label %then, label %else
+
+then:
+  tail call void @llvm.amdgcn.endpgm()
+  unreachable
+
+else:
+  store i32 %x, i32* %p
+  ret void
+}
+
+declare void @llvm.amdgcn.endpgm()
Index: llvm/lib/Target/AMDGPU/SOPInstructions.td
===
--- llvm/lib/Target/AMDGPU/SOPInstructions.td
+++ llvm/lib/Target/AMDGPU/SOPInstructions.td
@@ -1118,6 +1118,7 @@
 def S_ENDPGM : SOPP_Pseudo<"s_endpgm", (ins EndpgmImm:$simm16), "$simm16"> {
   let isBarrier = 1;
   let isReturn = 1;
+  let hasSideEffects = 1;
 }
 
 def S_ENDPGM_SAVED : SOPP_Pseudo<"s_endpgm_saved", (ins)> {
@@ -1328,6 +1329,11 @@
 (S_ENDPGM (i16 0))
 >;
 
+def : GCNPat <
+  (int_amdgcn_endpgm),
+(S_ENDPGM (i16 0))
+>;
+
 def : GCNPat <
   (i64 (ctpop i64:$src)),
 (i64 (REG_SEQUENCE SReg_64,
Index: llvm/include/llvm/IR/IntrinsicsAMDGPU.td
===
--- llvm/include/llvm/IR/IntrinsicsAMDGPU.td
+++ llvm/include/llvm/IR/IntrinsicsAMDGPU.td
@@ -1577,6 +1577,10 @@
 // FIXME: Should this be IntrNoMem, IntrHasSideEffects, or IntrWillReturn?
 def int_amdgcn_kill : Intrinsic<[], [llvm_i1_ty], []>;
 
+def int_amdgcn_endpgm : GCCBuiltin<"__builtin_amdgcn_endpgm">,
+  Intrinsic<[], [], [IntrNoReturn, IntrCold, IntrNoMem, IntrHasSideEffects]
+>;
+
 // Copies the active channels of the source value to the destination value,
 // with the guarantee that the source value is computed as if the entire
 // program were executed in Whole Wavefront Mode, i.e. with all channels
Index: clang/test/CodeGenCUDA/builtins-amdgcn.cu
===
--- clang/test/CodeGenCUDA/builtins-amdgcn.cu
+++ clang/test/CodeGenCUDA/builtins-amdgcn.cu
@@ -16,3 +16,9 @@
   __shared__ float shared;
   volatile float x = __builtin_amdgcn_ds_fmaxf(&shared, src, 0, 0, false);
 }
+
+// CHECK-LABEL: @_Z6endpgmv(
+// CHECK: call void @llvm.amdgcn.endpgm()
+__global__ void endpgm() {
+  __builtin_amdgcn_endpgm();
+}
Index: clang/include/clang/Basic/BuiltinsAMDGPU.def
===
--- clang/include/clang/Basic/BuiltinsAMDGPU.def
+++ clang/include/clang/Basic/BuiltinsAMDGPU.def
@@ -214,6 +214,8 @@
 BUILTIN(__builtin_amdgcn_read_exec_lo, "Ui", "nc")
 BUILTIN(__builtin_amdgcn_read_exec_hi, "Ui", "nc")
 
+BUILTIN(__builtin_amdgcn_endpgm, "v", "nr")
+
 //===--===//
 // R600-NI only builtins.
 //===--===//
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] 3b9b90a - [clang-tidy] Extend IdentifierNamingCheck per file config

[Nathan James via cfe-commits]

Author: Nathan James
Date: 2020-11-05T19:51:05Z
New Revision: 3b9b90a1914f1e470ba7d333b26bd34787337806

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

LOG: [clang-tidy] Extend IdentifierNamingCheck per file config

Add IgnoreMainLikeFunctions to the per file config. This can be extended for 
new options added to the check easily.

Reviewed By: aaron.ballman

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

Added: 


Modified: 
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp
clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.h

clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-identifier-naming/global-style1/.clang-tidy

clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-identifier-naming/global-style1/header.h

clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-identifier-naming/global-style2/.clang-tidy

clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-identifier-naming/global-style2/header.h

clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming-multiple-styles.cpp

Removed: 

clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-identifier-naming/global-style-disabled/.clang-tidy

clang-tools-extra/test/clang-tidy/checkers/Inputs/readability-identifier-naming/global-style-disabled/header.h



diff  --git 
a/clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp 
b/clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp
index 4af1b444cf02..5d63066490a6 100644
--- a/clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp
+++ b/clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp
@@ -122,9 +122,9 @@ static StringRef const StyleNames[] = {
 #undef NAMING_KEYS
 // clang-format on
 
-static std::vector>
-getNamingStyles(const ClangTidyCheck::OptionsView &Options) {
-  std::vector> Styles(
+static IdentifierNamingCheck::FileStyle
+getFileStyleFromOptions(const ClangTidyCheck::OptionsView &Options) {
+  SmallVector, 0> Styles(
   SK_Count);
   SmallString<64> StyleString;
   for (unsigned I = 0; I < SK_Count; ++I) {
@@ -145,23 +145,23 @@ getNamingStyles(const ClangTidyCheck::OptionsView 
&Options) {
   Styles[I].emplace(std::move(CaseOptional), std::move(Prefix),
 std::move(Postfix));
   }
-  return Styles;
+  bool IgnoreMainLike = Options.get("IgnoreMainLikeFunctions", false);
+  return {std::move(Styles), IgnoreMainLike};
 }
 
 IdentifierNamingCheck::IdentifierNamingCheck(StringRef Name,
  ClangTidyContext *Context)
 : RenamerClangTidyCheck(Name, Context), Context(Context), CheckName(Name),
   GetConfigPerFile(Options.get("GetConfigPerFile", true)),
-  IgnoreFailedSplit(Options.get("IgnoreFailedSplit", false)),
-  IgnoreMainLikeFunctions(Options.get("IgnoreMainLikeFunctions", false)) {
+  IgnoreFailedSplit(Options.get("IgnoreFailedSplit", false)) {
 
   auto IterAndInserted = NamingStylesCache.try_emplace(
   llvm::sys::path::parent_path(Context->getCurrentFile()),
-  getNamingStyles(Options));
+  getFileStyleFromOptions(Options));
   assert(IterAndInserted.second && "Couldn't insert Style");
   // Holding a reference to the data in the vector is safe as it should never
   // move.
-  MainFileStyle = IterAndInserted.first->getValue();
+  MainFileStyle = &IterAndInserted.first->getValue();
 }
 
 IdentifierNamingCheck::~IdentifierNamingCheck() = default;
@@ -169,26 +169,28 @@ IdentifierNamingCheck::~IdentifierNamingCheck() = default;
 void IdentifierNamingCheck::storeOptions(ClangTidyOptions::OptionMap &Opts) {
   RenamerClangTidyCheck::storeOptions(Opts);
   SmallString<64> StyleString;
+  ArrayRef> Styles = MainFileStyle->getStyles();
   for (size_t I = 0; I < SK_Count; ++I) {
-if (!MainFileStyle[I])
+if (!Styles[I])
   continue;
 StyleString = StyleNames[I];
 size_t StyleSize = StyleString.size();
 StyleString.append("Prefix");
-Options.store(Opts, StyleString, MainFileStyle[I]->Prefix);
+Options.store(Opts, StyleString, Styles[I]->Prefix);
 // Fast replacement of [Pre]fix -> [Suf]fix.
 memcpy(&StyleString[StyleSize], "Suf", 3);
-Options.store(Opts, StyleString, MainFileStyle[I]->Suffix);
-if (MainFileStyle[I]->Case) {
+Options.store(Opts, StyleString, Styles[I]->Suffix);
+if (Styles[I]->Case) {
   memcpy(&StyleString[StyleSize], "Case", 4);
   StyleString.pop_back();
   StyleString.pop_back();
-  Options.store(Opts, StyleString, *MainFileStyle[I]->Case);
+  Options.store(Opts, StyleString, *Styles[I]->Case);
 }
   }
   Options.store(Opts, "GetConfigPerFile", GetConfigPerFile);
   Options.store(Opts, "IgnoreF

[PATCH] D90809: [amdgpu] Add `llvm.amdgcn.endpgm` support.

[Michael Liao via Phabricator via cfe-commits]

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



Comment at: llvm/include/llvm/IR/IntrinsicsAMDGPU.td:1581
+def int_amdgcn_endpgm : GCCBuiltin<"__builtin_amdgcn_endpgm">,
+  Intrinsic<[], [], [IntrNoReturn, IntrNoMem, IntrHasSideEffects]
+>;

rampitec wrote:
> Mayby also IntrCold?
Good point!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90809

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

[PATCH] D90871: [Sema] Fold VLAs to constant arrays in a few more contexts

[Erik Pilkington via Phabricator via cfe-commits]

erik.pilkington created this revision.
erik.pilkington added reviewers: rsmith, rjmccall, arphaman.
Herald added subscribers: ributzka, jkorous.
erik.pilkington requested review of this revision.

D89523  removed support for promoting VLAs to 
constant arrays when the bounds isn't an ICE, since this can result in 
miscompiling a conforming program that assumes that the array is a VLA. 
Promoting VLAs for fields is still supported, since clang doesn't support VLAs 
in fields, so no conforming program could have a field VLA.

This change is really disruptive for us (hundreds of projects are failing to 
compile with this change), so I think we should carve out two more cases where 
we promote VLAs which can't miscompile a conforming program:

1. When the VLA appears in an ivar -- this seems like a corollary to the field 
thing
2. When the VLA has an initializer -- VLAs can't have an initializer

Thanks for taking a look!


https://reviews.llvm.org/D90871

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/test/Sema/decl-in-prototype.c
  clang/test/Sema/vla.c
  clang/test/SemaObjC/variable-size-ivar.m

Index: clang/test/SemaObjC/variable-size-ivar.m
===
--- /dev/null
+++ clang/test/SemaObjC/variable-size-ivar.m
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -fsyntax-only %s -verify
+
+const int ksize = 42;
+int size = 42;
+
+@interface X
+{
+  int arr1[ksize]; // expected-warning{{variable length array folded to constant array}}
+  int arr2[size]; // expected-error{{instance variables must have a constant size}}
+  int arr3[ksize-43]; // expected-error{{array size is negative}}
+}
+@end
Index: clang/test/Sema/vla.c
===
--- clang/test/Sema/vla.c
+++ clang/test/Sema/vla.c
@@ -100,3 +100,29 @@
 typedef struct {
   char c[pr44406_a]; // expected-warning {{folded to constant array as an extension}}
 } pr44406_s;
+
+void test_fold_to_constant_array() {
+  const int ksize = 4;
+
+  goto jump_over_a1; // expected-error{{cannot jump from this goto statement to its label}}
+  char a1[ksize]; // expected-note{{variable length array}}
+ jump_over_a1:;
+
+  char a2[ksize] = "foo"; // expected-warning{{variable length array folded to constant array as an extension}}
+
+  char a3[ksize] = {}; // expected-warning {{variable length array folded to constant array as an extension}} expected-warning{{use of GNU empty initializer}}
+
+  goto jump_over_a4; // expected-error{{cannot jump from this goto statement to its label}}
+  char a4[ksize][2]; // expected-note{{variable length array}}
+ jump_over_a4:;
+
+  char a5[ksize][2] = {}; // expected-warning {{variable length array folded to constant array as an extension}} expected-warning{{use of GNU empty initializer}}
+
+  int a6[ksize] = {1,2,3,4}; // expected-warning{{variable length array folded to constant array as an extension}}
+
+  // expected-warning@+1{{variable length array folded to constant array as an extension}}
+  int a7[ksize] __attribute__((annotate("foo"))) = {1,2,3,4};
+
+  // expected-warning@+1{{variable length array folded to constant array as an extension}}
+  char a8[2][ksize] = {{1,2,3,4},{4,3,2,1}};
+}
Index: clang/test/Sema/decl-in-prototype.c
===
--- clang/test/Sema/decl-in-prototype.c
+++ clang/test/Sema/decl-in-prototype.c
@@ -49,7 +49,7 @@
 // function.
 enum { BB = 0 };
 void enum_in_fun_in_fun(void (*fp)(enum { AA, BB } e)) { // expected-warning {{will not be visible}}
-  SA(1, AA == 5); // expected-error {{variable-sized object may not be initialized}}
+  SA(1, AA == 5); // expected-warning{{variable length array folded to constant array as an extension}}
   SA(2, BB == 0);
 }
 
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -5542,9 +5542,9 @@
   return false;
 }
 
-Decl *Sema::ActOnDeclarator(Scope *S, Declarator &D) {
+Decl *Sema::ActOnDeclarator(Scope *S, Declarator &D, bool NextTokIsEqual) {
   D.setFunctionDefinitionKind(FDK_Declaration);
-  Decl *Dcl = HandleDeclarator(S, D, MultiTemplateParamsArg());
+  Decl *Dcl = HandleDeclarator(S, D, MultiTemplateParamsArg(), NextTokIsEqual);
 
   if (OriginalLexicalContext && OriginalLexicalContext->isObjCContainer() &&
   Dcl && Dcl->getDeclContext()->isFileContext())
@@ -5678,7 +5678,8 @@
 }
 
 NamedDecl *Sema::HandleDeclarator(Scope *S, Declarator &D,
-  MultiTemplateParamsArg TemplateParamLists) {
+  MultiTemplateParamsArg TemplateParamLists,
+  bool NextTokIsEqual) {
   // TODO: consider using NameInfo for diagnostic.
   DeclarationNameInfo NameInfo = GetNameForDeclarator(D);
   DeclarationName Name = NameInfo.

[PATCH] D88859: APINotes: add APINotesYAMLCompiler

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

Looks like the test doesn't pass on Windows: 
http://45.33.8.238/win/27342/step_7.txt

Please take a look, and revert if it takes a while to fix.

Here's the output of the diff on that Win bot:

  thakis@thakis6-w MINGW64 /c/src/llvm-project (merge)
  $ diff --strip-trailing-cr 
out/gn/obj/clang/test/APINotes/Output/yaml-roundtrip.test.tmp.result 
clang/test/APINotes/Inputs/Frameworks/Simple.framework/Headers/Simple.apinotes
  1d0
  < ---
  8c7
  < Nullability: Nonnull
  ---
  > Nullability: N
  14c13
  < Nullability: Optional
  ---
  > Nullability: O
  20c19
  < Nullability: Unspecified
  ---
  > Nullability: U
  26c25
  < Nullability: Unspecified
  ---
  > Nullability: S
  29,30c28
  < Nullability: Unspecified
  < ...
  ---
  > Nullability: Scalar


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88859

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

[PATCH] D90809: [amdgpu] Add `llvm.amdgcn.endpgm` support.

[Brian Sumner via Phabricator via cfe-commits]

b-sumner added a comment.

Should this also be IntrConvergent?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90809

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

Re: [PATCH] D89500: Fix the error message with -fbasic-block-sections=list=

[David Blaikie via cfe-commits]

On Wed, Nov 4, 2020 at 9:07 PM Fāng-ruì Sòng  wrote:
>
> It is rare to report an error in BackendUtil.cpp . So I checked the
> other Diags.Report instance and noticed that -split-dwarf-file a.dwo
> -split-dwarf-output a.dwo (when a.dwo is not writable) suppresses the
> output. So there is no reason that -fbasic-block-sections=list= should
> not follow the convention.

Ah, thanks - I'm starting to see the connection, but it's still a few
extra steps for me. How'd you get from looking for Diags.Reports to
the split-dwarf-file case? Oh, because that produces an error (here:
https://github.com/llvm/llvm-project/blob/master/clang/lib/CodeGen/BackendUtil.cpp#L140
) & that error path suppresses output of any output files, not just
the one that couldn't be written to - right right.

Thanks for all the details!

Leaving the code review for now for Sri to take a look at. (good to
get some cross-pollination of reviewers/understanding of the issues in
the original code, etc)

>
> On Wed, Nov 4, 2020 at 8:18 PM David Blaikie  wrote:
> >
> >
> >
> > On Wed, Nov 4, 2020 at 8:08 PM Fāng-ruì Sòng  wrote:
> >>
> >> I checked chmod -w a.dwo; clang -cc1 -debug-info-kind=limited
> >> -dwarf-version=4 -split-dwarf-file a.dwo -split-dwarf-output a.dwo
> >> -emit-obj -o - split-debug-output.c
> >> which suppresses the output, so -fbasic-block-sections=list= should
> >> follow the convention as well.
> >
> >
> > I missed a step as to the inference between the split-dwarf example and the 
> > fbasic-block-sections example. Could you explain further what the 
> > split-dwarf test was intending to demonstrate/how it relates to the 
> > -fbasic-block-sections example?
> >
> >>
> >>
> >> Sent https://reviews.llvm.org/D90815
> >>
> >> On Wed, Nov 4, 2020 at 7:26 PM David Blaikie  wrote:
> >> >
> >> >
> >> >
> >> > On Tue, Oct 27, 2020 at 2:21 PM Sriraman Tallam via cfe-commits 
> >> >  wrote:
> >> >>
> >> >>
> >> >>
> >> >> On Tue, Oct 27, 2020 at 2:14 PM David Blaikie via Phabricator 
> >> >>  wrote:
> >> >>>
> >> >>> dblaikie added a comment.
> >> >>>
> >> >>> @tmsriram ping on the follow-up here
> >> >>
> >> >>
> >> >> I checked in the patch that emits llvm instead of obj which spews 
> >> >> garbage to the terminal as I wasn't redirecting it to /dev/null.  The 
> >> >> test seems stable. Is there a particular concern? Sorry if I missed 
> >> >> somethig here?
> >> >
> >> >
> >> > Oh, sorry - I missed your emails on-list, as they didn't end up on the 
> >> > review when viewed via Phabricator - that's most of the confusion. My 
> >> > mistake.
> >> >
> >> > Going back over it though - Yep, I totally missed the "ERROR" check line 
> >> > at the end (maybe worth an empty line between it and the UNIQUE check 
> >> > lines - as there's a break between UNIQUE and other lines (maybe the 
> >> > BB_* ones could use breaks too)).
> >> >
> >> > Though I'm still curious: Why is this command producing any 
> >> > object/binary output if it has produced an error message? That seems 
> >> > incorrect to me (generally if there's been any error, there wouldn't be 
> >> > output).
> >>
> >>
> >>
> >> --
> >> 宋方睿
>
>
>
> --
> 宋方睿
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D90329: [PowerPC] Fix va_arg in Objective-C on 32-bit ELF targets

[George Koehler via Phabricator via cfe-commits]

kernigh added inline comments.



Comment at: clang/lib/CodeGen/TargetInfo.cpp:4723
+  bool isInt = Ty->isIntegerType() || Ty->hasPointerRepresentation() ||
+   Ty->isAggregateType();
   bool isF64 = Ty->isFloatingType() && getContext().getTypeSize(Ty) == 64;

kernigh wrote:
> efriedma wrote:
> > I suspect this code doesn't handle C++ member pointers correctly.  But 
> > maybe we can leave that for a followup.
> > 
> > Could we simplify this to `bool isInt = !Ty->isFloatingType();`?
> Yes, C++ member pointers are broken. I declared a struct animal, tried 
> `typedef void (animal::*noise)(); ... va_arg(ap, noise)`, and it segfaulted. 
> In the disassembly, I saw 2 problems: (1) va_arg was looking at the 
> floating-point registers, and (2) va_arg was not indirecting through a 
> pointer. The caller had passed a pointer to a `noise` in a general-purpose 
> register.
> 
> I'm not sure about `bool isInt = !Ty->isFloatingType();`, because I haven't 
> checked whether it would break other types.
`bool isInt = !Ty->isFloatingType();` is working for me. I'm doing more checks; 
if it continues to work, I will update this diff.

Another change in `bool isIndirect = Ty->isAggregateType();` to instead call 
`isAggregateTypeForABI(Ty)` is fixing va_arg of a C++ member function pointer. 
I may want to put this change in the same diff because I will be running both 
changes together.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90329

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

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

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/Attr.td:1435
+  let Spellings = [GCC<"leaf">];
+  let Subjects = SubjectList<[Function]>;
+  let Documentation = [Undocumented];

gulfem wrote:
> aaron.ballman wrote:
> > gulfem wrote:
> > > aaron.ballman wrote:
> > > > gulfem wrote:
> > > > > aaron.ballman wrote:
> > > > > > Should this attribute also be supported on things like ObjC method 
> > > > > > decls or other function-like interfaces?
> > > > > Do I need to do anything else to support this attribute in 
> > > > > Objective-C as well?
> > > > > I think we should support it in all the C languages family.
> > > > >I think we should support it in all the C languages family.
> > > > 
> > > > That's already happening automatically -- there's a C and C++ spelling 
> > > > available for it and the attribute doesn't specify that it requires a 
> > > > particular language mode or target.
> > > > 
> > > > > Do I need to do anything else to support this attribute in 
> > > > > Objective-C as well?
> > > > You can add multiple subjects to the list here, so you can have this 
> > > > apply to `Function, ObjCMethod` for both of those. Another one to 
> > > > consider is whether this attribute can be written on a block 
> > > > declaration (like a lambda, but with different syntax). Beyond that, 
> > > > it's mostly just documentation, devising the test cases to ensure the 
> > > > ObjC functionality behaves as expected, possibly some codegen changes, 
> > > > etc.
> > > AFAIK, users can specify function attributes in lambda expressions.
> > > Lambda functions can only be accessed/called by the functions in the same 
> > > translation unit, right?
> > > Leaf attribute does not have any effect on the functions that are defined 
> > > in the same translation unit.
> > > For this reason, I'm thinking that leaf attribute would not have any 
> > > effect if they are used in lambda expressions.
> > > Do you agree with me?
> > > AFAIK, users can specify function attributes in lambda expressions.
> > 
> > I always forget that you can do that for declaration attributes using 
> > GNU-style syntax...
> > 
> > > Lambda functions can only be accessed/called by the functions in the same 
> > > translation unit, right?
> > 
> > Not necessarily, you could pass one across TU boundaries like a function 
> > pointer, for instance. e.g.,
> > ```
> > // TU1.cpp
> > void foo() {
> >   auto l = []() { ... };
> >   bar(l);
> > }
> > 
> > // TU2.cpp
> > void bar(auto func) {
> >   func();
> > }
> > ```
> > Not necessarily, you could pass one across TU boundaries like a function 
> > pointer, for instance. e.g.,
> As I mentioned before, leaf attribute is specifically intended for library 
> functions and I think all the existing usage of leaf attribute is in the 
> library function declarations. For this reason, I think we do not need to 
> support them for lambdas. Is that reasonable?
> 
> For this reason, I think we do not need to support them for lambdas. Is that 
> reasonable?

Is this considered a library function?

```
struct S {
  void f(); // Is this a library function?
  void operator()(); // How about this?
};
```
If the answer is "no", then I think we only need to support `FunctionDecl` and 
nothing else (not even `ObjCMethodDecl`, which is like a member function for 
ObjC). If the answer is "yes", then it's not clear to me whether lambdas should 
or should not be supported given that the attribute on the lambda expression is 
attached to the function call operator for the lambda declaration.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90275

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

[PATCH] D90874: [test] Properly test -Werror-implicit-function-declaration and -Wvec-elem-size

[Fangrui Song via Phabricator via cfe-commits]

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

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D90874

Files:
  clang/test/Modules/diagnose-missing-import.m
  clang/test/Sema/implicit-decl.c
  clang/test/Sema/vecshift.c

Index: clang/test/Sema/vecshift.c
===
--- clang/test/Sema/vecshift.c
+++ clang/test/Sema/vecshift.c
@@ -1,5 +1,7 @@
-// RUN: %clang_cc1 -fsyntax-only -DERR -verify %s
-// RUN: %clang_cc1 -fsyntax-only -DEXT -DERR -verify %s
+// RUN: %clang_cc1 -fsyntax-only -DERR -verify=expected,vecelemsize %s
+// RUN: %clang_cc1 -fsyntax-only -DEXT -DERR -verify=expected,vecelemsize %s
+// RUN: %clang_cc1 -fsyntax-only -DERR -verify %s -Wno-vec-elem-size
+// RUN: %clang_cc1 -fsyntax-only -DEXT -DERR -verify %s -Wno-vec-elem-size
 
 #ifdef EXT
 typedef __attribute__((__ext_vector_type__(8))) char vector_char8;
@@ -65,28 +67,28 @@
 
   vc8 = vc8 << vc8;
 #ifdef ERR
-  vi8 = vi8 << vuc8; // expected-error {{vector operands do not have the same elements sizes}}
-  vuc8 = vuc8 << vi8; // expected-error {{vector operands do not have the same elements sizes}}
-  vus8 = vus8 << vui8; // expected-error {{vector operands do not have the same elements sizes}}
-  vui8 = vui8 << vs8; // expected-error {{vector operands do not have the same elements sizes}}
+  vi8 = vi8 << vuc8; // vecelemsize-error {{vector operands do not have the same elements sizes}}
+  vuc8 = vuc8 << vi8; // vecelemsize-error {{vector operands do not have the same elements sizes}}
+  vus8 = vus8 << vui8; // vecelemsize-error {{vector operands do not have the same elements sizes}}
+  vui8 = vui8 << vs8; // vecelemsize-error {{vector operands do not have the same elements sizes}}
 #else
-  vi8 = vi8 << vuc8; // expected-warning {{vector operands do not have the same elements sizes}}
-  vuc8 = vuc8 << vi8; // expected-warning {{vector operands do not have the same elements sizes}}
-  vus8 = vus8 << vui8; // expected-warning {{vector operands do not have the same elements sizes}}
-  vui8 = vui8 << vs8; // expected-warning {{vector operands do not have the same elements sizes}}
+  vi8 = vi8 << vuc8; // vecelemsize-warning {{vector operands do not have the same elements sizes}}
+  vuc8 = vuc8 << vi8; // vecelemsize-warning {{vector operands do not have the same elements sizes}}
+  vus8 = vus8 << vui8; // vecelemsize-warning {{vector operands do not have the same elements sizes}}
+  vui8 = vui8 << vs8; // vecelemsize-warning {{vector operands do not have the same elements sizes}}
 #endif
 
   vc8 <<= vc8;
 #ifdef ERR
-  vi8 <<= vuc8; // expected-error {{vector operands do not have the same elements sizes}}
-  vuc8 <<= vi8; // expected-error {{vector operands do not have the same elements sizes}}
-  vus8 <<= vui8; // expected-error {{vector operands do not have the same elements sizes}}
-  vui8 <<= vs8; // expected-error {{vector operands do not have the same elements sizes}}
+  vi8 <<= vuc8; // vecelemsize-error {{vector operands do not have the same elements sizes}}
+  vuc8 <<= vi8; // vecelemsize-error {{vector operands do not have the same elements sizes}}
+  vus8 <<= vui8; // vecelemsize-error {{vector operands do not have the same elements sizes}}
+  vui8 <<= vs8; // vecelemsize-error {{vector operands do not have the same elements sizes}}
 #else
-  vi8 <<= vuc8; // expected-warning {{vector operands do not have the same elements sizes}}
-  vuc8 <<= vi8; // expected-warning {{vector operands do not have the same elements sizes}}
-  vus8 <<= vui8; // expected-warning {{vector operands do not have the same elements sizes}}
-  vui8 <<= vs8; // expected-warning {{vector operands do not have the same elements sizes}}
+  vi8 <<= vuc8; // vecelemsize-warning {{vector operands do not have the same elements sizes}}
+  vuc8 <<= vi8; // vecelemsize-warning {{vector operands do not have the same elements sizes}}
+  vus8 <<= vui8; // vecelemsize-warning {{vector operands do not have the same elements sizes}}
+  vui8 <<= vs8; // vecelemsize-warning {{vector operands do not have the same elements sizes}}
 #endif
 
   c <<= vc8; // expected-error {{assigning to 'char' from incompatible type}}
Index: clang/test/Sema/implicit-decl.c
===
--- clang/test/Sema/implicit-decl.c
+++ clang/test/Sema/implicit-decl.c
@@ -1,21 +1,25 @@
-// RUN: %clang_cc1 %s -verify -fsyntax-only -Werror
+// RUN: %clang_cc1 %s -verify=expected,implicit -fsyntax-only -Werror=implicit-function-declaration
+// RUN: %clang_cc1 %s -verify -fsyntax-only -Wno-implicit-function-declaration
+
+/// -Werror-implicit-function-declaration is a deprecated alias used by many projects.
+// RUN: %clang_cc1 %s -verify=expected,implicit -fsyntax-only -Werror-implicit-function-declaration
 
 typedef int int32_t;
 typedef unsigned char Bool

[PATCH] D90809: [amdgpu] Add `llvm.amdgcn.endpgm` support.

[Stanislav Mekhanoshin via Phabricator via cfe-commits]

rampitec added a comment.

In D90809#2376994 , @b-sumner wrote:

> Should this also be IntrConvergent?

Probably yes... This is control flow after all.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90809

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

[PATCH] D68997: Allow searching for prebuilt implicit modules.

[Alexandre Rames via Phabricator via cfe-commits]

arames marked an inline comment as done.
arames added a comment.

Fixed the trailing whitespace.

I also just got commit rights, so I will commit it myself.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68997

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

[clang] 1af037f - [PowerPC] Correct cpsgn's behaviour on PowerPC to match that of the ABI

[Albion Fung via cfe-commits]

Author: Albion Fung
Date: 2020-11-05T15:35:14-05:00
New Revision: 1af037f643fc5499f83d92e5aec199950871d475

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

LOG: [PowerPC] Correct cpsgn's behaviour on PowerPC to match that of the ABI

This patch fixes the reversed behaviour exhibited by cpsgn on PPC. It now 
matches the ABI.

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

Added: 


Modified: 
clang/lib/Headers/altivec.h
clang/test/CodeGen/builtins-ppc-vsx.c

Removed: 




diff  --git a/clang/lib/Headers/altivec.h b/clang/lib/Headers/altivec.h
index 2df420d640f1..24d600e95201 100644
--- a/clang/lib/Headers/altivec.h
+++ b/clang/lib/Headers/altivec.h
@@ -2996,12 +2996,12 @@ static __inline__ void __ATTRS_o_ai 
vec_xst_len_r(vector unsigned char __a,
 #ifdef __VSX__
 static __inline__ vector float __ATTRS_o_ai vec_cpsgn(vector float __a,
   vector float __b) {
-  return __builtin_vsx_xvcpsgnsp(__a, __b);
+  return __builtin_vsx_xvcpsgnsp(__b, __a);
 }
 
 static __inline__ vector double __ATTRS_o_ai vec_cpsgn(vector double __a,
vector double __b) {
-  return __builtin_vsx_xvcpsgndp(__a, __b);
+  return __builtin_vsx_xvcpsgndp(__b, __a);
 }
 #endif
 

diff  --git a/clang/test/CodeGen/builtins-ppc-vsx.c 
b/clang/test/CodeGen/builtins-ppc-vsx.c
index d99b0c1e8f41..18aa7d22fa3f 100644
--- a/clang/test/CodeGen/builtins-ppc-vsx.c
+++ b/clang/test/CodeGen/builtins-ppc-vsx.c
@@ -1850,3 +1850,47 @@ void testVectorInt128Pack(){
 // CHECK-NEXT-LE: %{{[0-9]+}} = extractelement <2 x i64> %[[V1]], i32 0
 
 }
+
+void test_vector_cpsgn_float(vector float a, vector float b) {
+// CHECK-LABEL: test_vector_cpsgn_float
+// CHECK-DAG: load{{.*}}%__a
+// CHECK-DAG: load{{.*}}%__b
+// CHECK-NOT: SEPARATOR
+// CHECK-DAG: [[RA:%[0-9]+]] = load <4 x float>, <4 x float>* %__a.addr
+// CHECK-DAG: [[RB:%[0-9]+]] = load <4 x float>, <4 x float>* %__b.addr
+// CHECK-NEXT: call <4 x float> @llvm.copysign.v4f32(<4 x float> [[RB]], <4 x 
float> [[RA]])
+  vec_cpsgn(a, b);
+}
+
+void test_vector_cpsgn_double(vector double a, vector double b) {
+// CHECK-LABEL: test_vector_cpsgn_double
+// CHECK-DAG: load{{.*}}%__a
+// CHECK-DAG: load{{.*}}%__b
+// CHECK-NOT: SEPARATOR
+// CHECK-DAG: [[RA:%[0-9]+]] = load <2 x double>, <2 x double>* %__a.addr
+// CHECK-DAG: [[RB:%[0-9]+]] = load <2 x double>, <2 x double>* %__b.addr
+// CHECK-NEXT: call <2 x double> @llvm.copysign.v2f64(<2 x double> [[RB]], <2 
x double> [[RA]])
+  vec_cpsgn(a, b);
+}
+
+void test_builtin_xvcpsgnsp(vector float a, vector float b) {
+// CHECK-LABEL: test_builtin_xvcpsgnsp
+// CHECK-DAG: load{{.*}}%a
+// CHECK-DAG: load{{.*}}%b
+// CHECK-NOT: SEPARATOR
+// CHECK-DAG: [[RA:%[0-9]+]] = load <4 x float>, <4 x float>* %a.addr
+// CHECK-DAG: [[RB:%[0-9]+]] = load <4 x float>, <4 x float>* %b.addr
+// CHECK-NEXT: call <4 x float> @llvm.copysign.v4f32(<4 x float> [[RA]], <4 x 
float> [[RB]])
+  __builtin_vsx_xvcpsgnsp(a, b);
+}
+
+void test_builtin_xvcpsgndp(vector double a, vector double b) {
+// CHECK-LABEL: test_builtin_xvcpsgndp
+// CHECK-DAG: load{{.*}}%a
+// CHECK-DAG: load{{.*}}%b
+// CHECK-NOT: SEPARATOR
+// CHECK-DAG: [[RA:%[0-9]+]] = load <2 x double>, <2 x double>* %a.addr
+// CHECK-DAG: [[RB:%[0-9]+]] = load <2 x double>, <2 x double>* %b.addr
+// CHECK-NEXT: call <2 x double> @llvm.copysign.v2f64(<2 x double> [[RA]], <2 
x double> [[RB]])
+  __builtin_vsx_xvcpsgndp(a, b);
+}



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

Re: [PATCH] D89500: Fix the error message with -fbasic-block-sections=list=

[Fāng-ruì Sòng via cfe-commits]

Yes, that's right. I think most errors are caught in Sema. There "if
there is an error, the output should be suppressed" should be a
consensus.
For some auxiliary files it was a bit fuzzy to me. So I checked .dwo
which is a similar auxiliary output - the output is suppressed with an
error - so it becomes clear to me that -fbasic-block-sections=list=
should behave consistently.

On Thu, Nov 5, 2020 at 12:06 PM David Blaikie  wrote:
>
> On Wed, Nov 4, 2020 at 9:07 PM Fāng-ruì Sòng  wrote:
> >
> > It is rare to report an error in BackendUtil.cpp . So I checked the
> > other Diags.Report instance and noticed that -split-dwarf-file a.dwo
> > -split-dwarf-output a.dwo (when a.dwo is not writable) suppresses the
> > output. So there is no reason that -fbasic-block-sections=list= should
> > not follow the convention.
>
> Ah, thanks - I'm starting to see the connection, but it's still a few
> extra steps for me. How'd you get from looking for Diags.Reports to
> the split-dwarf-file case? Oh, because that produces an error (here:
> https://github.com/llvm/llvm-project/blob/master/clang/lib/CodeGen/BackendUtil.cpp#L140
> ) & that error path suppresses output of any output files, not just
> the one that couldn't be written to - right right.
>
> Thanks for all the details!
>
> Leaving the code review for now for Sri to take a look at. (good to
> get some cross-pollination of reviewers/understanding of the issues in
> the original code, etc)
>
> >
> > On Wed, Nov 4, 2020 at 8:18 PM David Blaikie  wrote:
> > >
> > >
> > >
> > > On Wed, Nov 4, 2020 at 8:08 PM Fāng-ruì Sòng  wrote:
> > >>
> > >> I checked chmod -w a.dwo; clang -cc1 -debug-info-kind=limited
> > >> -dwarf-version=4 -split-dwarf-file a.dwo -split-dwarf-output a.dwo
> > >> -emit-obj -o - split-debug-output.c
> > >> which suppresses the output, so -fbasic-block-sections=list= should
> > >> follow the convention as well.
> > >
> > >
> > > I missed a step as to the inference between the split-dwarf example and 
> > > the fbasic-block-sections example. Could you explain further what the 
> > > split-dwarf test was intending to demonstrate/how it relates to the 
> > > -fbasic-block-sections example?
> > >
> > >>
> > >>
> > >> Sent https://reviews.llvm.org/D90815
> > >>
> > >> On Wed, Nov 4, 2020 at 7:26 PM David Blaikie  wrote:
> > >> >
> > >> >
> > >> >
> > >> > On Tue, Oct 27, 2020 at 2:21 PM Sriraman Tallam via cfe-commits 
> > >> >  wrote:
> > >> >>
> > >> >>
> > >> >>
> > >> >> On Tue, Oct 27, 2020 at 2:14 PM David Blaikie via Phabricator 
> > >> >>  wrote:
> > >> >>>
> > >> >>> dblaikie added a comment.
> > >> >>>
> > >> >>> @tmsriram ping on the follow-up here
> > >> >>
> > >> >>
> > >> >> I checked in the patch that emits llvm instead of obj which spews 
> > >> >> garbage to the terminal as I wasn't redirecting it to /dev/null.  The 
> > >> >> test seems stable. Is there a particular concern? Sorry if I missed 
> > >> >> somethig here?
> > >> >
> > >> >
> > >> > Oh, sorry - I missed your emails on-list, as they didn't end up on the 
> > >> > review when viewed via Phabricator - that's most of the confusion. My 
> > >> > mistake.
> > >> >
> > >> > Going back over it though - Yep, I totally missed the "ERROR" check 
> > >> > line at the end (maybe worth an empty line between it and the UNIQUE 
> > >> > check lines - as there's a break between UNIQUE and other lines (maybe 
> > >> > the BB_* ones could use breaks too)).
> > >> >
> > >> > Though I'm still curious: Why is this command producing any 
> > >> > object/binary output if it has produced an error message? That seems 
> > >> > incorrect to me (generally if there's been any error, there wouldn't 
> > >> > be output).
> > >>
> > >>
> > >>
> > >> --
> > >> 宋方睿
> >
> >
> >
> > --
> > 宋方睿



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

[PATCH] D84962: [PowerPC] Correct cpsgn's behaviour on PowerPC to match that of the ABI

[Albion Fung via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG1af037f643fc: [PowerPC] Correct cpsgn's behaviour on 
PowerPC to match that of the ABI (authored by Conanap).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84962

Files:
  clang/lib/Headers/altivec.h
  clang/test/CodeGen/builtins-ppc-vsx.c


Index: clang/test/CodeGen/builtins-ppc-vsx.c
===
--- clang/test/CodeGen/builtins-ppc-vsx.c
+++ clang/test/CodeGen/builtins-ppc-vsx.c
@@ -1850,3 +1850,47 @@
 // CHECK-NEXT-LE: %{{[0-9]+}} = extractelement <2 x i64> %[[V1]], i32 0
 
 }
+
+void test_vector_cpsgn_float(vector float a, vector float b) {
+// CHECK-LABEL: test_vector_cpsgn_float
+// CHECK-DAG: load{{.*}}%__a
+// CHECK-DAG: load{{.*}}%__b
+// CHECK-NOT: SEPARATOR
+// CHECK-DAG: [[RA:%[0-9]+]] = load <4 x float>, <4 x float>* %__a.addr
+// CHECK-DAG: [[RB:%[0-9]+]] = load <4 x float>, <4 x float>* %__b.addr
+// CHECK-NEXT: call <4 x float> @llvm.copysign.v4f32(<4 x float> [[RB]], <4 x 
float> [[RA]])
+  vec_cpsgn(a, b);
+}
+
+void test_vector_cpsgn_double(vector double a, vector double b) {
+// CHECK-LABEL: test_vector_cpsgn_double
+// CHECK-DAG: load{{.*}}%__a
+// CHECK-DAG: load{{.*}}%__b
+// CHECK-NOT: SEPARATOR
+// CHECK-DAG: [[RA:%[0-9]+]] = load <2 x double>, <2 x double>* %__a.addr
+// CHECK-DAG: [[RB:%[0-9]+]] = load <2 x double>, <2 x double>* %__b.addr
+// CHECK-NEXT: call <2 x double> @llvm.copysign.v2f64(<2 x double> [[RB]], <2 
x double> [[RA]])
+  vec_cpsgn(a, b);
+}
+
+void test_builtin_xvcpsgnsp(vector float a, vector float b) {
+// CHECK-LABEL: test_builtin_xvcpsgnsp
+// CHECK-DAG: load{{.*}}%a
+// CHECK-DAG: load{{.*}}%b
+// CHECK-NOT: SEPARATOR
+// CHECK-DAG: [[RA:%[0-9]+]] = load <4 x float>, <4 x float>* %a.addr
+// CHECK-DAG: [[RB:%[0-9]+]] = load <4 x float>, <4 x float>* %b.addr
+// CHECK-NEXT: call <4 x float> @llvm.copysign.v4f32(<4 x float> [[RA]], <4 x 
float> [[RB]])
+  __builtin_vsx_xvcpsgnsp(a, b);
+}
+
+void test_builtin_xvcpsgndp(vector double a, vector double b) {
+// CHECK-LABEL: test_builtin_xvcpsgndp
+// CHECK-DAG: load{{.*}}%a
+// CHECK-DAG: load{{.*}}%b
+// CHECK-NOT: SEPARATOR
+// CHECK-DAG: [[RA:%[0-9]+]] = load <2 x double>, <2 x double>* %a.addr
+// CHECK-DAG: [[RB:%[0-9]+]] = load <2 x double>, <2 x double>* %b.addr
+// CHECK-NEXT: call <2 x double> @llvm.copysign.v2f64(<2 x double> [[RA]], <2 
x double> [[RB]])
+  __builtin_vsx_xvcpsgndp(a, b);
+}
Index: clang/lib/Headers/altivec.h
===
--- clang/lib/Headers/altivec.h
+++ clang/lib/Headers/altivec.h
@@ -2996,12 +2996,12 @@
 #ifdef __VSX__
 static __inline__ vector float __ATTRS_o_ai vec_cpsgn(vector float __a,
   vector float __b) {
-  return __builtin_vsx_xvcpsgnsp(__a, __b);
+  return __builtin_vsx_xvcpsgnsp(__b, __a);
 }
 
 static __inline__ vector double __ATTRS_o_ai vec_cpsgn(vector double __a,
vector double __b) {
-  return __builtin_vsx_xvcpsgndp(__a, __b);
+  return __builtin_vsx_xvcpsgndp(__b, __a);
 }
 #endif
 


Index: clang/test/CodeGen/builtins-ppc-vsx.c
===
--- clang/test/CodeGen/builtins-ppc-vsx.c
+++ clang/test/CodeGen/builtins-ppc-vsx.c
@@ -1850,3 +1850,47 @@
 // CHECK-NEXT-LE: %{{[0-9]+}} = extractelement <2 x i64> %[[V1]], i32 0
 
 }
+
+void test_vector_cpsgn_float(vector float a, vector float b) {
+// CHECK-LABEL: test_vector_cpsgn_float
+// CHECK-DAG: load{{.*}}%__a
+// CHECK-DAG: load{{.*}}%__b
+// CHECK-NOT: SEPARATOR
+// CHECK-DAG: [[RA:%[0-9]+]] = load <4 x float>, <4 x float>* %__a.addr
+// CHECK-DAG: [[RB:%[0-9]+]] = load <4 x float>, <4 x float>* %__b.addr
+// CHECK-NEXT: call <4 x float> @llvm.copysign.v4f32(<4 x float> [[RB]], <4 x float> [[RA]])
+  vec_cpsgn(a, b);
+}
+
+void test_vector_cpsgn_double(vector double a, vector double b) {
+// CHECK-LABEL: test_vector_cpsgn_double
+// CHECK-DAG: load{{.*}}%__a
+// CHECK-DAG: load{{.*}}%__b
+// CHECK-NOT: SEPARATOR
+// CHECK-DAG: [[RA:%[0-9]+]] = load <2 x double>, <2 x double>* %__a.addr
+// CHECK-DAG: [[RB:%[0-9]+]] = load <2 x double>, <2 x double>* %__b.addr
+// CHECK-NEXT: call <2 x double> @llvm.copysign.v2f64(<2 x double> [[RB]], <2 x double> [[RA]])
+  vec_cpsgn(a, b);
+}
+
+void test_builtin_xvcpsgnsp(vector float a, vector float b) {
+// CHECK-LABEL: test_builtin_xvcpsgnsp
+// CHECK-DAG: load{{.*}}%a
+// CHECK-DAG: load{{.*}}%b
+// CHECK-NOT: SEPARATOR
+// CHECK-DAG: [[RA:%[0-9]+]] = load <4 x float>, <4 x float>* %a.addr
+// CHECK-DAG: [[RB:%[0-9]+]] = load <4 x float>, <4 x float>* %b.addr
+// CHECK-NEXT: call <4 x float> @llvm.copysign.v4f32(<4 x float> [[RA]], <4 x float> [[RB]])
+  __builtin_vsx_xvcpsgnsp(a, b);
+}
+
+void test_builtin_xvcpsgndp(vector doubl

[PATCH] D90835: [RFC][clang-tidy] Ignore diagnostics due to macro expansion from not-interested headers

[Nathan James via Phabricator via cfe-commits]

njames93 added inline comments.



Comment at: clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp:249-251
+  if (!HeaderFilter)
+HeaderFilter =
+std::make_unique(*getOptions().HeaderFilterRegex);

This should also check if the Optional has a value



Comment at: clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp:349-351
+  // Skip macro from system headers.
+  if (!*Context.getOptions().SystemHeaders && SM.isInSystemHeader(SpellingLoc))
+return true;

This looks suspicious, in clang-tidy land `SystemHeaders` is always set, 
however outside clang-tidy it may not be.
Perhaps `getValueOr(false)` should be used to prevent any asserts.

Also can a test be added to show this respecting the SystemHeaders setting.



Comment at: clang-tools-extra/clang-tidy/ClangTidyDiagnosticConsumer.cpp:358-360
+  if (!File) {
+return false;
+  }

Elide braces


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90835

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

[PATCH] D90763: Traverse-ignore explicit template instantiations

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/ASTMatchers/ASTMatchFinder.cpp:503
   TraversalKind Traversal, BindKind Bind) {
+auto ScopedTraversal = TraversingTemplateInstantiationNotSpelledInSource;
+

Please spell this type out rather than use auto.



Comment at: clang/lib/ASTMatchers/ASTMatchFinder.cpp:506
+if (const auto *CTSD = Node.get()) {
+  auto SK = CTSD->getSpecializationKind();
+  if (SK == TSK_ExplicitInstantiationDeclaration ||

Same here, though this could also be simplified to:
```
ScopedTraversal = (SK == TSK_ExplicitInstantiationDeclaration || SK == 
TSK_ExplicitInstantiationDefinition);
```



Comment at: clang/unittests/AST/ASTTraverserTest.cpp:1092
+
+// Explicit instantiation of template functions do not appear in the AST
+template float timesTwo(float);

Huh, do you have any idea if that's a bug? We have 
`ClassTemplateSpecializationDecl` and `VarTemplateSpecializationDecl`, but we 
have `FunctionTemplateSpecializationInfo` that doesn't generate an AST node and 
no mention of why in the comments that I've spotted yet.



Comment at: clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp:2280
+EXPECT_TRUE(matches(Code, traverse(TK_AsIs, M)));
+EXPECT_TRUE(matches(Code, traverse(TK_IgnoreUnlessSpelledInSource, M)));
+  }

Explicitly instantiating a function template in ignore mode returns false, but 
explicitly instantiating a class template returns true? Is this intentional or 
just fallout from the lack of explicit instantiation information in the AST for 
functions?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90763

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

[PATCH] D90630: [CodeGen] Fix Bug 47499: __unaligned extension inconsistent behaviour with C and C++

[Reid Kleckner via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGd2e7dca5ca92: [CodeGen] Fix Bug 47499: __unaligned extension 
inconsistent behaviour with C… (authored by j0le, committed by rnk).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90630

Files:
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/CodeGen/unaligned-struct-copy.c


Index: clang/test/CodeGen/unaligned-struct-copy.c
===
--- /dev/null
+++ clang/test/CodeGen/unaligned-struct-copy.c
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 -xc   -O2 -triple thumbv7a-unknown-windows-eabi 
-fms-extensions -emit-llvm < %s | FileCheck %s
+// RUN: %clang_cc1 -xc++ -O2 -triple thumbv7a-unknown-windows-eabi 
-fms-extensions -emit-llvm < %s | FileCheck %s
+// RUN: %clang_cc1 -xc   -O2 -triple x86_64-unknown-linux-gnu -fms-extensions 
-emit-llvm < %s | FileCheck %s
+// RUN: %clang_cc1 -xc++ -O2 -triple x86_64-unknown-linux-gnu -fms-extensions 
-emit-llvm < %s | FileCheck %s
+
+struct S1 {
+  unsigned long x;
+};
+
+// CHECK: define
+// CHECK-SAME: void
+// CHECK-SAME: test1
+
+void test1(__unaligned struct S1 *out) {
+  // CHECK: store
+  // CHECK-SAME: align 1
+  out->x = 5;
+  // CHECK: ret void
+}
+
+// CHECK: define
+// CHECK-SAME: void
+// CHECK-SAME: test2
+
+void test2(__unaligned struct S1 *out, __unaligned struct S1 *in) {
+  // CHECK: load
+  // CHECK-SAME: align 1
+  // CHECK: store
+  // CHECK-SAME: align 1
+  *out = *in;
+  // CHECK: ret void
+}
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -6197,16 +6197,17 @@
 *BaseInfo = LValueBaseInfo(AlignmentSource::Type);
 
   CharUnits Alignment;
-  // For C++ class pointees, we don't know whether we're pointing at a
-  // base or a complete object, so we generally need to use the
-  // non-virtual alignment.
   const CXXRecordDecl *RD;
-  if (forPointeeType && !AlignForArray && (RD = T->getAsCXXRecordDecl())) {
+  if (T.getQualifiers().hasUnaligned()) {
+Alignment = CharUnits::One();
+  } else if (forPointeeType && !AlignForArray &&
+ (RD = T->getAsCXXRecordDecl())) {
+// For C++ class pointees, we don't know whether we're pointing at a
+// base or a complete object, so we generally need to use the
+// non-virtual alignment.
 Alignment = getClassPointerAlignment(RD);
   } else {
 Alignment = getContext().getTypeAlignInChars(T);
-if (T.getQualifiers().hasUnaligned())
-  Alignment = CharUnits::One();
   }
 
   // Cap to the global maximum type alignment unless the alignment


Index: clang/test/CodeGen/unaligned-struct-copy.c
===
--- /dev/null
+++ clang/test/CodeGen/unaligned-struct-copy.c
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 -xc   -O2 -triple thumbv7a-unknown-windows-eabi -fms-extensions -emit-llvm < %s | FileCheck %s
+// RUN: %clang_cc1 -xc++ -O2 -triple thumbv7a-unknown-windows-eabi -fms-extensions -emit-llvm < %s | FileCheck %s
+// RUN: %clang_cc1 -xc   -O2 -triple x86_64-unknown-linux-gnu -fms-extensions -emit-llvm < %s | FileCheck %s
+// RUN: %clang_cc1 -xc++ -O2 -triple x86_64-unknown-linux-gnu -fms-extensions -emit-llvm < %s | FileCheck %s
+
+struct S1 {
+  unsigned long x;
+};
+
+// CHECK: define
+// CHECK-SAME: void
+// CHECK-SAME: test1
+
+void test1(__unaligned struct S1 *out) {
+  // CHECK: store
+  // CHECK-SAME: align 1
+  out->x = 5;
+  // CHECK: ret void
+}
+
+// CHECK: define
+// CHECK-SAME: void
+// CHECK-SAME: test2
+
+void test2(__unaligned struct S1 *out, __unaligned struct S1 *in) {
+  // CHECK: load
+  // CHECK-SAME: align 1
+  // CHECK: store
+  // CHECK-SAME: align 1
+  *out = *in;
+  // CHECK: ret void
+}
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -6197,16 +6197,17 @@
 *BaseInfo = LValueBaseInfo(AlignmentSource::Type);
 
   CharUnits Alignment;
-  // For C++ class pointees, we don't know whether we're pointing at a
-  // base or a complete object, so we generally need to use the
-  // non-virtual alignment.
   const CXXRecordDecl *RD;
-  if (forPointeeType && !AlignForArray && (RD = T->getAsCXXRecordDecl())) {
+  if (T.getQualifiers().hasUnaligned()) {
+Alignment = CharUnits::One();
+  } else if (forPointeeType && !AlignForArray &&
+ (RD = T->getAsCXXRecordDecl())) {
+// For C++ class pointees, we don't know whether we're pointing at a
+// base or a complete object, so we generally need to use the
+// non-virtual alignment.
 Alignment = getClassPointerAlignment(RD);
   } else {
 Alignment = getContext().getTypeAlignInChars(T);
-if (T.getQualifiers().hasUnaligned())
- 

[clang] d2e7dca - [CodeGen] Fix Bug 47499: __unaligned extension inconsistent behaviour with C and C++

[Reid Kleckner via cfe-commits]

Author: Jan Ole Hüser
Date: 2020-11-05T12:57:17-08:00
New Revision: d2e7dca5ca92c655e451d6fcb806df38d7f2d56b

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

LOG: [CodeGen] Fix Bug 47499: __unaligned extension inconsistent behaviour with 
C and C++

For the language C++ the keyword __unaligned (a Microsoft extension) had no 
effect on pointers.

The reason, why there was a difference between C and C++ for the keyword 
__unaligned:
For C, the Method getAsCXXREcordDecl() returns nullptr. That guarantees that 
hasUnaligned() is called.
If the language is C++, it is not guaranteed, that hasUnaligend() is called and 
evaluated.

Here are some links:

The Bug: https://bugs.llvm.org/show_bug.cgi?id=47499
Thread on the cfe-dev mailing list: 
http://lists.llvm.org/pipermail/cfe-dev/2020-September/066783.html
Diff, that introduced the check hasUnaligned() in getNaturalTypeAlignment(): 
https://reviews.llvm.org/D30166

Reviewed By: rnk

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

Added: 
clang/test/CodeGen/unaligned-struct-copy.c

Modified: 
clang/lib/CodeGen/CodeGenModule.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CodeGenModule.cpp 
b/clang/lib/CodeGen/CodeGenModule.cpp
index 24c067539f83..ccf5d24bb9eb 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -6197,16 +6197,17 @@ CharUnits 
CodeGenModule::getNaturalTypeAlignment(QualType T,
 *BaseInfo = LValueBaseInfo(AlignmentSource::Type);
 
   CharUnits Alignment;
-  // For C++ class pointees, we don't know whether we're pointing at a
-  // base or a complete object, so we generally need to use the
-  // non-virtual alignment.
   const CXXRecordDecl *RD;
-  if (forPointeeType && !AlignForArray && (RD = T->getAsCXXRecordDecl())) {
+  if (T.getQualifiers().hasUnaligned()) {
+Alignment = CharUnits::One();
+  } else if (forPointeeType && !AlignForArray &&
+ (RD = T->getAsCXXRecordDecl())) {
+// For C++ class pointees, we don't know whether we're pointing at a
+// base or a complete object, so we generally need to use the
+// non-virtual alignment.
 Alignment = getClassPointerAlignment(RD);
   } else {
 Alignment = getContext().getTypeAlignInChars(T);
-if (T.getQualifiers().hasUnaligned())
-  Alignment = CharUnits::One();
   }
 
   // Cap to the global maximum type alignment unless the alignment

diff  --git a/clang/test/CodeGen/unaligned-struct-copy.c 
b/clang/test/CodeGen/unaligned-struct-copy.c
new file mode 100644
index ..45a9670bc234
--- /dev/null
+++ b/clang/test/CodeGen/unaligned-struct-copy.c
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 -xc   -O2 -triple thumbv7a-unknown-windows-eabi 
-fms-extensions -emit-llvm < %s | FileCheck %s
+// RUN: %clang_cc1 -xc++ -O2 -triple thumbv7a-unknown-windows-eabi 
-fms-extensions -emit-llvm < %s | FileCheck %s
+// RUN: %clang_cc1 -xc   -O2 -triple x86_64-unknown-linux-gnu -fms-extensions 
-emit-llvm < %s | FileCheck %s
+// RUN: %clang_cc1 -xc++ -O2 -triple x86_64-unknown-linux-gnu -fms-extensions 
-emit-llvm < %s | FileCheck %s
+
+struct S1 {
+  unsigned long x;
+};
+
+// CHECK: define
+// CHECK-SAME: void
+// CHECK-SAME: test1
+
+void test1(__unaligned struct S1 *out) {
+  // CHECK: store
+  // CHECK-SAME: align 1
+  out->x = 5;
+  // CHECK: ret void
+}
+
+// CHECK: define
+// CHECK-SAME: void
+// CHECK-SAME: test2
+
+void test2(__unaligned struct S1 *out, __unaligned struct S1 *in) {
+  // CHECK: load
+  // CHECK-SAME: align 1
+  // CHECK: store
+  // CHECK-SAME: align 1
+  *out = *in;
+  // CHECK: ret void
+}



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

[clang] 71e108c - Allow searching for prebuilt implicit modules.

[Alexandre Rames via cfe-commits]

Author: Alexandre Rames
Date: 2020-11-05T13:10:53-08:00
New Revision: 71e108cd86e70b06c5fa3a63689dcb3555c3d13f

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

LOG: Allow searching for prebuilt implicit modules.

The behavior is controlled by the `-fprebuilt-implicit-modules` option, and
allows searching for implicit modules in the prebuilt module cache paths.

The current command-line options for prebuilt modules do not allow to easily
maintain and use multiple versions of modules. Both the producer and users of
prebuilt modules are required to know the relationships between compilation
options and module file paths. Using a particular version of a prebuilt module
requires passing a particular option on the command line (e.g.
`-fmodule-file=[=]` or `-fprebuilt-module-path=`).

However the compiler already knows how to distinguish and automatically locate
implicit modules. Hence this proposal to introduce the
`-fprebuilt-implicit-modules` option. When set, it enables searching for
implicit modules in the prebuilt module paths (specified via
`-fprebuilt-module-path`). To not modify existing behavior, this search takes
place after the standard search for prebuilt modules. If not

Here is a workflow illustrating how both the producer and consumer of prebuilt
modules would need to know what versions of prebuilt modules are available and
where they are located.

  clang -cc1 -x c modulemap -fmodules -emit-module -fmodule-name=foo 
-fmodules-cache-path=prebuilt_modules_v1 
  clang -cc1 -x c modulemap -fmodules -emit-module -fmodule-name=foo 
-fmodules-cache-path=prebuilt_modules_v2 
  clang -cc1 -x c modulemap -fmodules -emit-module -fmodule-name=foo 
-fmodules-cache-path=prebuilt_modules_v3 

  clang -cc1 -x c use.c -fmodules fmodule-map-file=modulemap 
-fprebuilt-module-path=prebuilt_modules_v1 
  clang -cc1 -x c use.c -fmodules fmodule-map-file=modulemap 

With prebuilt implicit modules, the producer can generate prebuilt modules as
usual, all in the same output directory. The same mechanisms as for implicit
modules take care of incorporating hashes in the path to distinguish between
module versions.

Note that we do not specify the output module filename, so `-o` implicit 
modules are generated in the cache path `prebuilt_modules`.

  clang -cc1 -x c modulemap -fmodules -emit-module -fmodule-name=foo 
-fmodules-cache-path=prebuilt_modules 
  clang -cc1 -x c modulemap -fmodules -emit-module -fmodule-name=foo 
-fmodules-cache-path=prebuilt_modules 
  clang -cc1 -x c modulemap -fmodules -emit-module -fmodule-name=foo 
-fmodules-cache-path=prebuilt_modules 

The user can now simply enable prebuilt implicit modules and point to the
prebuilt modules cache. No need to "parse" command-line options to decide
what prebuilt modules (paths) to use.

  clang -cc1 -x c use.c -fmodules fmodule-map-file=modulemap 
-fprebuilt-module-path=prebuilt_modules -fprebuilt-implicit-modules 
  clang -cc1 -x c use.c -fmodules fmodule-map-file=modulemap 
-fprebuilt-module-path=prebuilt_modules -fprebuilt-implicit-modules 


This is for example particularly useful in a use-case where compilation is
expensive, and the configurations expected to be used are predictable, but not
controlled by the producer of prebuilt modules. Modules for the set of
predictable configurations can be prebuilt, and using them does not require
"parsing" the configuration (command-line options).

Reviewed By: Bigcheese

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

Added: 
clang/test/Modules/Inputs/prebuilt-implicit-module/a.h
clang/test/Modules/Inputs/prebuilt-implicit-module/module.modulemap
clang/test/Modules/prebuilt-implicit-modules.m

Modified: 
clang/docs/Modules.rst
clang/include/clang/Driver/Options.td
clang/include/clang/Frontend/CompilerInstance.h
clang/include/clang/Lex/HeaderSearch.h
clang/include/clang/Lex/HeaderSearchOptions.h
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Frontend/CompilerInstance.cpp
clang/lib/Frontend/CompilerInvocation.cpp
clang/lib/Lex/HeaderSearch.cpp
clang/lib/Serialization/ASTReader.cpp
clang/lib/Serialization/ASTWriter.cpp

Removed: 




diff  --git a/clang/docs/Modules.rst b/clang/docs/Modules.rst
index 63f09f90fe6c..703ba86c68a0 100644
--- a/clang/docs/Modules.rst
+++ b/clang/docs/Modules.rst
@@ -225,6 +225,11 @@ Command-line parameters
 ``-fprebuilt-module-path=``
   Specify the path to the prebuilt modules. If specified, we will look for 
modules in this directory for a given top-level module name. We don't need a 
module map for loading prebuilt modules in this directory and the compiler will 
not try to rebuild these modules. This can be specified multiple times.
 
+``-fprebuilt-implicit-modules``
+  Enable prebuilt implicit mo

[PATCH] D68997: Allow searching for prebuilt implicit modules.

[Alexandre Rames 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 rG71e108cd86e7: Allow searching for prebuilt implicit modules. 
(authored by arames).

Changed prior to commit:
  https://reviews.llvm.org/D68997?vs=300780&id=303243#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68997

Files:
  clang/docs/Modules.rst
  clang/include/clang/Driver/Options.td
  clang/include/clang/Frontend/CompilerInstance.h
  clang/include/clang/Lex/HeaderSearch.h
  clang/include/clang/Lex/HeaderSearchOptions.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInstance.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Lex/HeaderSearch.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/Modules/Inputs/prebuilt-implicit-module/a.h
  clang/test/Modules/Inputs/prebuilt-implicit-module/module.modulemap
  clang/test/Modules/prebuilt-implicit-modules.m

Index: clang/test/Modules/prebuilt-implicit-modules.m
===
--- /dev/null
+++ clang/test/Modules/prebuilt-implicit-modules.m
@@ -0,0 +1,35 @@
+// RUN: rm -rf %t
+// RUN: %clang_cc1 -x objective-c -fmodules %S/Inputs/prebuilt-implicit-module/module.modulemap -emit-module -fmodule-name=module_a -fmodules-cache-path=%t
+// RUN: find %t -name "module_a*.pcm" | grep module_a
+
+// Check we use a prebuilt module when available, and do not build an implicit module.
+// RUN: rm -rf %t1
+// RUN: mkdir -p %t1
+// RUN: %clang_cc1 -x objective-c %s -I%S/Inputs/prebuilt-implicit-module -fmodules -fmodule-map-file=%S/Inputs/prebuilt-implicit-module/module.modulemap -fprebuilt-implicit-modules -fprebuilt-module-path=%t -fmodules-cache-path=%t1
+// RUN: find %t1 -name "module_a*.pcm" | not grep module_a
+
+// Check a module cache path is not required when all modules resolve to
+// prebuilt implicit modules.
+// RUN: rm -rf %t1
+// RUN: mkdir -p %t1
+// RUN: %clang_cc1 -x objective-c %s -I%S/Inputs/prebuilt-implicit-module -fmodules -fmodule-map-file=%S/Inputs/prebuilt-implicit-module/module.modulemap -fprebuilt-implicit-modules -fprebuilt-module-path=%t
+
+// Check that we correctly fall back to implicit modules if the prebuilt implicit module is not found.
+// RUN: rm -rf %t1
+// RUN: mkdir -p %t1
+// RUN: %clang_cc1 -x objective-c %s -I%S/Inputs/prebuilt-implicit-module -fmodules -fmodule-map-file=%S/Inputs/prebuilt-implicit-module/module.modulemap -fprebuilt-implicit-modules -fprebuilt-module-path=%t -fmodules-cache-path=%t1 -fno-signed-char
+// RUN: find %t1 -name "module_a*.pcm" | grep module_a
+
+// Check that non-implicit prebuilt modules are always preferred to prebuilt implicit modules.
+// RUN: rm -rf %t2
+// RUN: mkdir -p %t2
+// RUN: %clang_cc1 -x objective-c -fmodules %S/Inputs/prebuilt-implicit-module/module.modulemap -emit-module -fmodule-name=module_a -fmodules-cache-path=%t
+// RUN: %clang_cc1 -x objective-c -fmodules %S/Inputs/prebuilt-implicit-module/module.modulemap -emit-module -fmodule-name=module_a -o %t/module_a.pcm -fno-signed-char
+// RUN: not %clang_cc1 -x objective-c %s -I%S/Inputs/prebuilt-implicit-module -fmodules -fmodule-map-file=%S/Inputs/prebuilt-implicit-module/module.modulemap -fprebuilt-implicit-modules -fprebuilt-module-path=%t -fmodules-cache-path=%t2
+// RUN: find %t2 -name "module_a*.pcm" | not grep module_a
+
+// expected-no-diagnostics
+@import module_a;
+int test() {
+  return a;
+}
Index: clang/test/Modules/Inputs/prebuilt-implicit-module/module.modulemap
===
--- /dev/null
+++ clang/test/Modules/Inputs/prebuilt-implicit-module/module.modulemap
@@ -0,0 +1 @@
+module module_a { header "a.h" }
Index: clang/test/Modules/Inputs/prebuilt-implicit-module/a.h
===
--- /dev/null
+++ clang/test/Modules/Inputs/prebuilt-implicit-module/a.h
@@ -0,0 +1 @@
+const int a = 1;
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -1320,6 +1320,7 @@
   Record.push_back(HSOpts.DisableModuleHash);
   Record.push_back(HSOpts.ImplicitModuleMaps);
   Record.push_back(HSOpts.ModuleMapFileHomeIsCwd);
+  Record.push_back(HSOpts.EnablePrebuiltImplicitModules);
   Record.push_back(HSOpts.UseBuiltinIncludes);
   Record.push_back(HSOpts.UseStandardSystemIncludes);
   Record.push_back(HSOpts.UseStandardCXXIncludes);
Index: clang/lib/Serialization/ASTReader.cpp
===
--- clang/lib/Serialization/ASTReader.cpp
+++ clang/lib/Serialization/ASTReader.cpp
@@ -5844,6 +5844,7 @@
   HSOpts.DisableModuleHash = Record[Idx++];
   HSOpts.ImplicitModuleMaps = Record[Idx++

[PATCH] D90809: [amdgpu] Add `llvm.amdgcn.endpgm` support.

[Michael Liao via Phabricator via cfe-commits]

hliao marked an inline comment as done.
hliao added a comment.

In D90809#2377083 , @rampitec wrote:

> In D90809#2376994 , @b-sumner wrote:
>
>> Should this also be IntrConvergent?
>
> Probably yes... This is control flow after all.

The real effect of this intrinsic seems not changed if it's moved somewhere. 
For example,

convert this

  if (a || b)
endpgm();

to

  if (a)
endpgm();
  else if (b)
endpgm();

no matter a or b are divergent or not, it works the same as the original one as 
`s_endpgm` is a scalar instruction. Ofc, if we really doubt bad things may 
happen, I could add that for safety as we definitely will revise this later.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90809

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

[PATCH] D90714: [clang]Fix length threshold for MicrosoftMangle md5 hash

[Melanie Blower via Phabricator via cfe-commits]

mibintc added a comment.

I'm sorry, I don't see how to build up an identifier with an arbitrary number 
of characters using the token pasting, for example an ident with 4095 
characters is not a power of 2. I tried pasting together X2048 X1024 X512 etc 
but that doesn't work
fu.cpp:12:18: error: pasting ")" and "X16" does not give a valid preprocessing 
token
 #define FUN X32(x) ## X16(x)

  ^

fu.cpp:13:1: note: in expansion of macro ‘FUN’
I want the test case to show the transition between when md5 is not needed and 
when it's needed, i want to build strings that might not be power of root 
string.  I could add more comments to the test case, perhaps, "the strlen of 
the Microsoft mangled name is X" for the one case, and "the strlen of ... is 
X+1" for the other.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90714

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

[PATCH] D90174: [HIP] Fix regressions due to fp contract change

[Steve Canon via Phabricator via cfe-commits]

scanon added a comment.

I do not much like faststd, as there's nothing "standard" about it. I do not, 
however, have a better suggestion off the top of my head. Let's pause and 
consider the name a little bit longer, please?


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

https://reviews.llvm.org/D90174

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

[clang] e551578 - APINotes: repair the Windows builders

[Saleem Abdulrasool via cfe-commits]

Author: Saleem Abdulrasool
Date: 2020-11-05T21:25:52Z
New Revision: e55157874cf20acef55ca20a87699bf77b7cfd3a

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

LOG: APINotes: repair the Windows builders

Disable the test on Windows, which should've been obvious as being
needed.  The differences in diff implementations and line-endings make
this test difficult to execute on Windows.

Added: 


Modified: 
clang/test/APINotes/yaml-roundtrip.test

Removed: 




diff  --git a/clang/test/APINotes/yaml-roundtrip.test 
b/clang/test/APINotes/yaml-roundtrip.test
index 3379cbf3b6db..bd4c89d2cdd9 100644
--- a/clang/test/APINotes/yaml-roundtrip.test
+++ b/clang/test/APINotes/yaml-roundtrip.test
@@ -1,6 +1,10 @@
 RUN: apinotes-test 
%S/Inputs/Frameworks/Simple.framework/Headers/Simple.apinotes > %t.result
 RUN: not 
diff  --strip-trailing-cr 
%S/Inputs/Frameworks/Simple.framework/Headers/Simple.apinotes %t.result | 
FileCheck %s
 
+Avoid Windows as the 
diff  output 
diff ers due to line-endings and 
diff erent 
diff 
+implementations.
+UNSUPPORTED: system-windows
+
 We expect only the nullability to be 
diff erent as it is canonicalized during the
 roudtrip.
 



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

[PATCH] D68997: Allow searching for prebuilt implicit modules.

[Nico Weber via Phabricator via cfe-commits]

thakis added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:3382
 }
+if (Args.hasFlag(options::OPT_fprebuilt_implicit_modules, false))
+  CmdArgs.push_back("-fprebuilt-implicit-modules");

You need to use a fno_ flag as 2nd param if you want to use hasFlag, the 
default value is the third param: http://45.33.8.238/win/27354/step_4.txt


../../clang/lib/Driver/ToolChains/Clang.cpp(3382,63): error: conversion from 
'bool' to 'llvm::opt::OptSpecifier' is ambiguous
if (Args.hasFlag(options::OPT_fprebuilt_implicit_modules, false))
  ^
../../llvm/include\llvm/Option/OptSpecifier.h(24,16): note: candidate 
constructor
  /*implicit*/ OptSpecifier(unsigned ID) : ID(ID) {}
   ^
../../llvm/include\llvm/Option/OptSpecifier.h(25,16): note: candidate 
constructor
  /*implicit*/ OptSpecifier(const Option *Opt);
   ^
../../llvm/include\llvm/Option/ArgList.h(295,47): note: passing argument to 
parameter 'Neg' here
  bool hasFlag(OptSpecifier Pos, OptSpecifier Neg, bool Default=true) const;
  ^
1 error generated.
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68997

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

[PATCH] D90719: [DebugInfo] Modify ctor homing as workaround for unconstructed libcxx types

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

I had another thought, which is that even if it is UB, perhaps we really 
shouldn't be using UB as the basis for debug info emission. All programs have 
bugs, and most bugs invoke some form of UB. If we don't provide sufficient info 
when UB is involved, it can become harder to find the UB. The vtable type 
homing heuristic works because violating the heuristic assumptions typically 
results in a link error. Creating an object without calling the class's 
constructor is the kind of UB that is likely to manifest as runtime errors.

Which is to say, I'm in favor of Amy's change as written.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90719

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

[PATCH] D90802: [OpenMP] [DOCS] Update OMP5.1 feature status table [NFC]

[Johannes Doerfert via Phabricator via cfe-commits]

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

LGTM




Comment at: clang/docs/OpenMPSupport.rst:343
++--+--+--+---+
+| misc extension   | user-defined function variants with #ifdef 
protection| :part:`worked on`| D71179   
 |
++--+--+--+---+

dreachem wrote:
> jdoerfert wrote:
> > What is missing here?
> This is from the original table. Is this referring to begin/end declare 
> variant feature, which I also added? If so, I should remove that one. 
yes. remove this and mark `begin/end declare variant  ` as done.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90802

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

[PATCH] D90194: [Driver] split LangOptions::SSPOff into SSPOFF and SSPUnspecified

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

Why does `-cc1` need to distinguish between enabled, disabled, unset? The 
design philosophy is that the driver figures out all the target-specific 
configuration stuff, and then tells cc1 which features to enable. See, for 
example, -fexceptions, which is off by default in cc1, and removed by 
-fno-exceptions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90194

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

[PATCH] D89959: UBSAN: emit distinctive traps in trapping mode

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added inline comments.



Comment at: llvm/include/llvm/IR/Intrinsics.td:1242
+def int_ubsantrap : Intrinsic<[], [llvm_i8_ty],
+  [IntrNoReturn, IntrCold, ImmArg>]>;
 

should this be readonly and inaccesiblememonly?


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

https://reviews.llvm.org/D89959

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