[PATCH] D122064: [clang-format][docs] Fix incorrect 'clang-format 11' option markers

2022-04-07 Thread Krystian Kuzniarek via Phabricator via cfe-commits
kuzkry added a subscriber: owenpan.
kuzkry added a comment.

@owenpan, thank you for delivery.

> You just could ask for push rights, especially if you want to change 
> something more in the future.

I will request it then. Hopefully I get accepted as apparently they check for a 
good "record of submitting high quality patches" (from 
https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122064

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


[PATCH] D122808: [clang] Fix warnings when `-Wdeprecated-enum-enum-conversion` is enabled

2022-04-07 Thread Antonio Frighetto via Phabricator via cfe-commits
antoniofrighetto updated this revision to Diff 42.

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

https://reviews.llvm.org/D122808

Files:
  clang/include/clang/AST/DeclarationName.h
  llvm/include/llvm/ADT/STLExtras.h
  llvm/unittests/ADT/STLExtrasTest.cpp

Index: llvm/unittests/ADT/STLExtrasTest.cpp
===
--- llvm/unittests/ADT/STLExtrasTest.cpp
+++ llvm/unittests/ADT/STLExtrasTest.cpp
@@ -9,6 +9,7 @@
 #include "llvm/ADT/STLExtras.h"
 #include "gtest/gtest.h"
 
+#include 
 #include 
 #include 
 
@@ -989,4 +990,32 @@
   static_assert(!is_contained({1, 2, 3, 4}, 5), "It's not there :(");
 }
 
+TEST(STLExtrasTest, addEnumValues) {
+  enum A { Zero = 0, One = 1 };
+  enum B { IntMax = INT_MAX, ULongLongMax = ULLONG_MAX };
+  enum class C : unsigned { Two = 2 };
+
+  // Non-fixed underlying types, with same underlying types
+  static_assert(addEnumValues(Zero, One) == 1,
+"addEnumValues(Zero, One) failed.");
+  static_assert(addEnumValues(IntMax, ULongLongMax) ==
+INT_MAX + static_cast(ULLONG_MAX),
+"addEnumValues(IntMax, ULongLongMax) failed.");
+  // Non-fixed underlying types, with different underlying types
+  static_assert(addEnumValues(Zero, IntMax) == INT_MAX,
+"addEnumValues(Zero, IntMax) failed.");
+  static_assert(addEnumValues(One, ULongLongMax) ==
+1 + static_cast(ULLONG_MAX),
+"addEnumValues(One, ULongLongMax) failed.");
+  // Non-fixed underlying type enum and fixed underlying type enum, with same
+  // underlying types
+  static_assert(addEnumValues(One, C::Two) == 3,
+"addEnumValues(One, C::Two) failed.");
+  // Non-fixed underlying type enum and fixed underlying type enum, with
+  // different underlying types
+  static_assert(addEnumValues(ULongLongMax, C::Two) ==
+static_cast(ULLONG_MAX) + 2,
+"addEnumValues(ULongLongMax, C::Two) failed.");
+}
+
 } // namespace
Index: llvm/include/llvm/ADT/STLExtras.h
===
--- llvm/include/llvm/ADT/STLExtras.h
+++ llvm/include/llvm/ADT/STLExtras.h
@@ -203,6 +203,17 @@
 template 
 using TypeAtIndex = std::tuple_element_t>;
 
+/// Helper which adds two underlying types of enumeration type.
+/// Implicit conversion to a common type is accepted.
+template ::value,
+  std::underlying_type_t>,
+  typename UT2 = std::enable_if_t::value,
+  std::underlying_type_t>>
+constexpr auto addEnumValues(EnumTy1 LHS, EnumTy2 RHS) {
+  return static_cast(LHS) + static_cast(RHS);
+}
+
 //===--===//
 // Extra additions to 
 //===--===//
Index: clang/include/clang/AST/DeclarationName.h
===
--- clang/include/clang/AST/DeclarationName.h
+++ clang/include/clang/AST/DeclarationName.h
@@ -21,6 +21,7 @@
 #include "clang/Basic/SourceLocation.h"
 #include "llvm/ADT/DenseMapInfo.h"
 #include "llvm/ADT/FoldingSet.h"
+#include "llvm/ADT/STLExtras.h"
 #include "llvm/Support/Compiler.h"
 #include "llvm/Support/type_traits.h"
 #include 
@@ -192,6 +193,13 @@
 "The various classes that DeclarationName::Ptr can point to"
 " must be at least aligned to 8 bytes!");
 
+  static_assert(
+  std::is_same,
+   std::underlying_type_t<
+   detail::DeclarationNameExtra::ExtraKind>>::value,
+  "The various enums used to compute values for NameKind should "
+  "all have the same underlying type");
+
 public:
   /// The kind of the name stored in this DeclarationName.
   /// The first 7 enumeration values are stored inline and correspond
@@ -205,15 +213,18 @@
 CXXDestructorName = StoredCXXDestructorName,
 CXXConversionFunctionName = StoredCXXConversionFunctionName,
 CXXOperatorName = StoredCXXOperatorName,
-CXXDeductionGuideName = UncommonNameKindOffset +
-detail::DeclarationNameExtra::CXXDeductionGuideName,
-CXXLiteralOperatorName =
-UncommonNameKindOffset +
-detail::DeclarationNameExtra::CXXLiteralOperatorName,
-CXXUsingDirective = UncommonNameKindOffset +
-detail::DeclarationNameExtra::CXXUsingDirective,
-ObjCMultiArgSelector = UncommonNameKindOffset +
-   detail::DeclarationNameExtra::ObjCMultiArgSelector
+CXXDeductionGuideName = llvm::addEnumValues(
+UncommonNameKindOffset,
+detail::DeclarationNameExtra::CXXDeductionGuideName),
+CXXLiteralOperatorName = llvm::addEnumValues(
+UncommonNameKindOffset,
+detail::DeclarationNameExtra::CXXLiteralOperatorName),
+CXXUsingDirective =
+  

[clang-tools-extra] cc7ed0c - [clang-tidy] bugprone-signal-handler: Message improvement and code refactoring.

2022-04-07 Thread Balázs Kéri via cfe-commits

Author: Balázs Kéri
Date: 2022-04-07T09:38:58+02:00
New Revision: cc7ed0caaca58bb38c789dcf2e0aade5f68f1e02

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

LOG: [clang-tidy] bugprone-signal-handler: Message improvement and code 
refactoring.

Another change of the code design.
Code simplified again, now there is a single place to check
a handler function and less functions for bug report emitting.
More details are added to the bug report messages.

Reviewed By: whisperity

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

Added: 


Modified: 
clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.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

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp 
b/clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
index 983a7c0610d71..37d373905b693 100644
--- a/clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
+++ b/clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
@@ -11,215 +11,9 @@
 #include "llvm/ADT/DepthFirstIterator.h"
 #include "llvm/ADT/STLExtras.h"
 
-using namespace clang::ast_matchers;
-
-namespace clang {
-namespace tidy {
-
-template <>
-struct OptionEnumMapping<
-bugprone::SignalHandlerCheck::AsyncSafeFunctionSetType> {
-  static llvm::ArrayRef>
-  getEnumMapping() {
-static constexpr std::pair<
-bugprone::SignalHandlerCheck::AsyncSafeFunctionSetType, StringRef>
-Mapping[] = {
-{bugprone::SignalHandlerCheck::AsyncSafeFunctionSetType::Minimal,
- "minimal"},
-{bugprone::SignalHandlerCheck::AsyncSafeFunctionSetType::POSIX,
- "POSIX"},
-};
-return makeArrayRef(Mapping);
-  }
-};
-
-namespace bugprone {
-
-namespace {
-
-bool isSystemCall(const FunctionDecl *FD) {
-  // Find a possible redeclaration in system header.
-  // FIXME: Looking at the canonical declaration is not the most exact way
-  // to do this.
-
-  // Most common case will be inclusion directly from a header.
-  // This works fine by using canonical declaration.
-  // a.c
-  // #include 
-
-  // Next most common case will be extern declaration.
-  // Can't catch this with either approach.
-  // b.c
-  // extern void sysfunc(void);
-
-  // Canonical declaration is the first found declaration, so this works.
-  // c.c
-  // #include 
-  // extern void sysfunc(void); // redecl won't matter
-
-  // This does not work with canonical declaration.
-  // Probably this is not a frequently used case but may happen (the first
-  // declaration can be in a non-system header for example).
-  // d.c
-  // extern void sysfunc(void); // Canonical declaration, not in system header.
-  // #include 
-
-  return FD->getASTContext().getSourceManager().isInSystemHeader(
-  FD->getCanonicalDecl()->getLocation());
-}
-
-/// Given a call graph node of a function and another one that is called from
-/// this function, get a CallExpr of the corresponding function call.
-/// It is unspecified which call is found if multiple calls exist, but the 
order
-/// should be deterministic (depend only on the AST).
-Expr *findCallExpr(const CallGraphNode *Caller, const CallGraphNode *Callee) {
-  auto FoundCallee = llvm::find_if(
-  Caller->callees(), [Callee](const CallGraphNode::CallRecord &Call) {
-return Call.Callee == Callee;
-  });
-  assert(FoundCallee != Caller->end() &&
- "Callee should be called from the caller function here.");
-  return FoundCallee->CallExpr;
-}
-
-} // namespace
-
-AST_MATCHER(FunctionDecl, isSystemCall) { return isSystemCall(&Node); }
-
-SignalHandlerCheck::SignalHandlerCheck(StringRef Name,
-   ClangTidyContext *Context)
-: ClangTidyCheck(Name, Context),
-  AsyncSafeFunctionSet(
-  Options.get("AsyncSafeFunctionSet", 
AsyncSafeFunctionSetType::POSIX)),
-  ConformingFunctions(AsyncSafeFunctionSet ==
-  AsyncSafeFunctionSetType::Minimal
-  ? MinimalConformingFunctions
-  : POSIXConformingFunctions) {}
-
-void SignalHandlerCheck::storeOptions(ClangTidyOptions::OptionMap &Opts) {
-  Options.store(Opts, "AsyncSafeFunctionSet", AsyncSafeFunctionSet);
-}
-
-bool SignalHandlerCheck::isLanguageVersionSupported(
-const LangOptions &LangOpts) const {
-  // FIXME: Make the checker useful on C++ code.
-  if (LangOpts.CPlusPlus)
-return false;
-
-  return true;
-}
-
-void SignalHandlerCheck::registerMatc

[PATCH] D118370: [clang-tidy] bugprone-signal-handler: Message improvement and code refactoring.

2022-04-07 Thread Balázs Kéri via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGcc7ed0caaca5: [clang-tidy] bugprone-signal-handler: Message 
improvement and code refactoring. (authored by balazske).

Changed prior to commit:
  https://reviews.llvm.org/D118370?vs=416435&id=421112#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D118370

Files:
  clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.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
@@ -5,7 +5,7 @@
 #include "stdio.h"
 #include "system-other.h"
 
-// The function should be classified as system call even if there is
+// The function should be classified as standard function even if there is
 // declaration the in source file.
 // FIXME: The detection works only if the first declaration is in system
 // header.
@@ -17,7 +17,7 @@
 
 void handler_printf(int) {
   printf("1234");
-  // CHECK-NOTES: :[[@LINE-1]]:3: warning: 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+  // CHECK-NOTES: :[[@LINE-1]]:3: warning: standard function 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
   // CHECK-NOTES: :[[@LINE-2]]:3: note: function 'printf' called here from 'handler_printf'
   // CHECK-NOTES: :[[@LINE+4]]:18: note: function 'handler_printf' registered here as signal handler
 }
@@ -28,7 +28,7 @@
 
 void handler_extern(int) {
   f_extern();
-  // CHECK-NOTES: :[[@LINE-1]]:3: warning: 'f_extern' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+  // CHECK-NOTES: :[[@LINE-1]]:3: warning: cannot verify that external function 'f_extern' is asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
   // CHECK-NOTES: :[[@LINE-2]]:3: note: function 'f_extern' called here from 'handler_extern'
   // CHECK-NOTES: :[[@LINE+4]]:18: note: function 'handler_extern' registered here as signal handler
 }
@@ -51,7 +51,7 @@
 
 void f_bad(void) {
   printf("1234");
-  // CHECK-NOTES: :[[@LINE-1]]:3: warning: 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+  // CHECK-NOTES: :[[@LINE-1]]:3: warning: standard function 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
   // CHECK-NOTES: :[[@LINE-2]]:3: note: function 'printf' called here from 'f_bad'
   // CHECK-NOTES: :[[@LINE+5]]:3: note: function 'f_bad' called here from 'handler_bad'
   // CHECK-NOTES: :[[@LINE+8]]:18: note: function 'handler_bad' registered here as signal handler
@@ -67,7 +67,7 @@
 
 void f_bad1(void) {
   printf("1234");
-  // CHECK-NOTES: :[[@LINE-1]]:3: warning: 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+  // CHECK-NOTES: :[[@LINE-1]]:3: warning: standard function 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
   // CHECK-NOTES: :[[@LINE-2]]:3: note: function 'printf' called here from 'f_bad1'
   // CHECK-NOTES: :[[@LINE+6]]:3: note: function 'f_bad1' called here from 'f_bad2'
   // CHECK-NOTES: :[[@LINE+9]]:3: note: function 'f_bad2' called here from 'handler_bad1'
@@ -99,7 +99,7 @@
 void handler_false_condition(int) {
   if (0)
 printf("1234");
-  // CHECK-NOTES: :[[@LINE-1]]:5: warning: 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+  // CHECK-NOTES: :[[@LINE-1]]:5: warning: standard function 'printf' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
   // CHECK-NOTES: :[[@LINE-2]]:5: note: function 'printf' called here from 'handler_false_condition'
   // CHECK-NOTES: :[[@LINE+4]]:18: note: function 'handler_false_condition' registered here as signal handler
 }
@@ -110,11 +110,11 @@
 
 void handler_multiple_calls(int) {
   f_extern();
-  // CHECK-NOTES: :[[@LINE-1]]:3: warning: 'f_extern' may not be asynchronous-safe; calling it from a signal handler may be dangerous [bugprone-signal-handler]
+  // CHECK-NOTES: :[[@LINE-1]]:3: warning: cannot verify that external function 'f_extern' is asynchronous-safe; calling it from a signal handler may be dangerous [b

[PATCH] D123286: Patch for : omp nothing

2022-04-07 Thread Sunil K via Phabricator via cfe-commits
koops created this revision.
koops added reviewers: dreachem, soumitra, cchen, jdoerfert.
Herald added a project: All.
koops requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, sstefan1.
Herald added projects: clang, LLVM.

Patch to support "#pragma omp nothing"


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D123286

Files:
  clang/lib/Basic/OpenMPKinds.cpp
  clang/lib/Parse/ParseOpenMP.cpp
  clang/test/OpenMP/nothing_messages.cpp
  llvm/include/llvm/Frontend/OpenMP/OMP.td


Index: clang/test/OpenMP/nothing_messages.cpp
===
--- /dev/null
+++ clang/test/OpenMP/nothing_messages.cpp
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 -verify=expected -fopenmp -ferror-limit 100 %s 
-Wuninitialized
+
+int mixed() {
+  int x = 0;
+  int d = 4;
+  
+#pragma omp nothing
+  x=d;
+
+  if(!x) {
+#pragma omp nothing
+x=d;
+  }
+
+// expected-error@+2 {{#pragma omp nothing' cannot be an immediate 
substatement}}
+  if(!x)
+#pragma omp nothing
+x=d;
+
+// expected-warning@+2 {{extra tokens at the end of '#pragma omp nothing' are 
ignored}}
+  if(!x) {
+#pragma omp nothing seq_cst
+x=d;
+  }
+
+  return 0;
+}
Index: llvm/include/llvm/Frontend/OpenMP/OMP.td
===
--- llvm/include/llvm/Frontend/OpenMP/OMP.td
+++ llvm/include/llvm/Frontend/OpenMP/OMP.td
@@ -602,6 +602,7 @@
 VersionedClause
   ];
 }
+def OMP_Nothing : Directive<"nothing"> {}
 def OMP_TargetData : Directive<"target data"> {
   let allowedClauses = [
 VersionedClause,
Index: clang/lib/Parse/ParseOpenMP.cpp
===
--- clang/lib/Parse/ParseOpenMP.cpp
+++ clang/lib/Parse/ParseOpenMP.cpp
@@ -2488,6 +2488,17 @@
   bool HasAssociatedStatement = true;
 
   switch (DKind) {
+  case OMPD_nothing:
+if ((StmtCtx & ParsedStmtContext::AllowStandaloneOpenMPDirectives) ==
+ParsedStmtContext()) {
+  Diag(Tok, diag::err_omp_immediate_directive)
+<< getOpenMPDirectiveName(DKind) << 0;
+}
+ConsumeToken();
+skipUntilPragmaOpenMPEnd(DKind);
+if (Tok.is(tok::annot_pragma_openmp_end))
+  ConsumeAnnotationToken();
+break;
   case OMPD_metadirective: {
 ConsumeToken();
 SmallVector VMIs;
Index: clang/lib/Basic/OpenMPKinds.cpp
===
--- clang/lib/Basic/OpenMPKinds.cpp
+++ clang/lib/Basic/OpenMPKinds.cpp
@@ -714,6 +714,9 @@
   case OMPD_teams_loop:
 CaptureRegions.push_back(OMPD_teams);
 break;
+  case OMPD_nothing:
+CaptureRegions.push_back(OMPD_nothing);
+break;
   case OMPD_loop:
 // TODO: 'loop' may require different capture regions depending on the bind
 // clause or the parent directive when there is no bind clause. Use


Index: clang/test/OpenMP/nothing_messages.cpp
===
--- /dev/null
+++ clang/test/OpenMP/nothing_messages.cpp
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 -verify=expected -fopenmp -ferror-limit 100 %s -Wuninitialized
+
+int mixed() {
+  int x = 0;
+  int d = 4;
+  
+#pragma omp nothing
+  x=d;
+
+  if(!x) {
+#pragma omp nothing
+x=d;
+  }
+
+// expected-error@+2 {{#pragma omp nothing' cannot be an immediate substatement}}
+  if(!x)
+#pragma omp nothing
+x=d;
+
+// expected-warning@+2 {{extra tokens at the end of '#pragma omp nothing' are ignored}}
+  if(!x) {
+#pragma omp nothing seq_cst
+x=d;
+  }
+
+  return 0;
+}
Index: llvm/include/llvm/Frontend/OpenMP/OMP.td
===
--- llvm/include/llvm/Frontend/OpenMP/OMP.td
+++ llvm/include/llvm/Frontend/OpenMP/OMP.td
@@ -602,6 +602,7 @@
 VersionedClause
   ];
 }
+def OMP_Nothing : Directive<"nothing"> {}
 def OMP_TargetData : Directive<"target data"> {
   let allowedClauses = [
 VersionedClause,
Index: clang/lib/Parse/ParseOpenMP.cpp
===
--- clang/lib/Parse/ParseOpenMP.cpp
+++ clang/lib/Parse/ParseOpenMP.cpp
@@ -2488,6 +2488,17 @@
   bool HasAssociatedStatement = true;
 
   switch (DKind) {
+  case OMPD_nothing:
+if ((StmtCtx & ParsedStmtContext::AllowStandaloneOpenMPDirectives) ==
+ParsedStmtContext()) {
+  Diag(Tok, diag::err_omp_immediate_directive)
+<< getOpenMPDirectiveName(DKind) << 0;
+}
+ConsumeToken();
+skipUntilPragmaOpenMPEnd(DKind);
+if (Tok.is(tok::annot_pragma_openmp_end))
+  ConsumeAnnotationToken();
+break;
   case OMPD_metadirective: {
 ConsumeToken();
 SmallVector VMIs;
Index: clang/lib/Basic/OpenMPKinds.cpp
===
--- clang/lib/Basic/OpenMPKinds.cpp
+++ clang/lib/Basic/OpenMPKinds.cpp
@@ -714,6 +714,9 @@
   case OMPD_teams_loop:
 CaptureRegions.push_back(OMPD_teams);
 break;
+  case OMPD_nothing:
+Ca

[PATCH] D122808: [clang] Fix warnings when `-Wdeprecated-enum-enum-conversion` is enabled

2022-04-07 Thread Antonio Frighetto via Phabricator via cfe-commits
antoniofrighetto added inline comments.



Comment at: llvm/unittests/ADT/STLExtrasTest.cpp:994
+  enum A { Zero = 0, One = 1 };
+  enum B { IntMax = INT_MAX, ULongLongMax = ULLONG_MAX };
+  enum class C : unsigned { Two = 2 };

aaron.ballman wrote:
> It looks like you need to include `` for the macros.
Right, saw the CI, fixed, thanks! :)


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

https://reviews.llvm.org/D122808

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


[PATCH] D123070: [Driver][NFC] Simplify handling of flags in Options.td

2022-04-07 Thread Hans Wennborg via Phabricator via cfe-commits
hans added a comment.

In D123070#3430207 , @ekieri wrote:

> @hans , thanks, that is a valid concern. I was asked to add closing comments 
> on an earlier patch though, and I find them particularly useful (when 
> accurate...) in this file, which does not use indentation very much. But I am 
> happy to make the change if you insist, and welcome others to fill in with 
> their opinions.

I also find them useful, so having them seems like a plus.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123070

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


[PATCH] D123122: [OpaquePtr][Clang] Add CLANG_ENABLE_OPAQUE_POINTERS cmake option

2022-04-07 Thread Nikita Popov via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG5390606aa963: [OpaquePtr][Clang] Add 
CLANG_ENABLE_OPAQUE_POINTERS cmake option (authored by nikic).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D123122?vs=420738&id=421120#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123122

Files:
  clang/CMakeLists.txt
  clang/include/clang/Config/config.h.cmake
  clang/include/clang/Driver/Options.td


Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -5507,7 +5507,7 @@
 defm opaque_pointers : BoolOption<"",
   "opaque-pointers",
   CodeGenOpts<"OpaquePointers">,
-  DefaultFalse,
+  Default<"CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL">,
   PosFlag,
   NegFlag,
   BothFlags<[], " opaque pointers">>;
Index: clang/include/clang/Config/config.h.cmake
===
--- clang/include/clang/Config/config.h.cmake
+++ clang/include/clang/Config/config.h.cmake
@@ -89,4 +89,7 @@
 /* Spawn a new process clang.exe for the CC1 tool invocation, when necessary */
 #cmakedefine01 CLANG_SPAWN_CC1
 
+/* Whether to enable opaque pointers by default */
+#cmakedefine01 CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL
+
 #endif
Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -247,6 +247,17 @@
 
 option(CLANG_DEFAULT_PIE_ON_LINUX "Default to -fPIE and -pie on linux-gnu" ON)
 
+# Manually handle default so we can change the meaning of a cached default.
+set(CLANG_ENABLE_OPAQUE_POINTERS "DEFAULT" CACHE STRING
+"Enable opaque pointers by default")
+if(CLANG_ENABLE_OPAQUE_POINTERS STREQUAL "DEFAULT")
+  set(CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL OFF)
+elseif(CLANG_ENABLE_OPAQUE_POINTERS)
+  set(CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL ON)
+else()
+  set(CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL OFF)
+endif()
+
 # TODO: verify the values against LangStandards.def?
 set(CLANG_DEFAULT_STD_C "" CACHE STRING
   "Default standard to use for C/ObjC code (IDENT from LangStandards.def, 
empty for platform default)")


Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -5507,7 +5507,7 @@
 defm opaque_pointers : BoolOption<"",
   "opaque-pointers",
   CodeGenOpts<"OpaquePointers">,
-  DefaultFalse,
+  Default<"CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL">,
   PosFlag,
   NegFlag,
   BothFlags<[], " opaque pointers">>;
Index: clang/include/clang/Config/config.h.cmake
===
--- clang/include/clang/Config/config.h.cmake
+++ clang/include/clang/Config/config.h.cmake
@@ -89,4 +89,7 @@
 /* Spawn a new process clang.exe for the CC1 tool invocation, when necessary */
 #cmakedefine01 CLANG_SPAWN_CC1
 
+/* Whether to enable opaque pointers by default */
+#cmakedefine01 CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL
+
 #endif
Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -247,6 +247,17 @@
 
 option(CLANG_DEFAULT_PIE_ON_LINUX "Default to -fPIE and -pie on linux-gnu" ON)
 
+# Manually handle default so we can change the meaning of a cached default.
+set(CLANG_ENABLE_OPAQUE_POINTERS "DEFAULT" CACHE STRING
+"Enable opaque pointers by default")
+if(CLANG_ENABLE_OPAQUE_POINTERS STREQUAL "DEFAULT")
+  set(CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL OFF)
+elseif(CLANG_ENABLE_OPAQUE_POINTERS)
+  set(CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL ON)
+else()
+  set(CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL OFF)
+endif()
+
 # TODO: verify the values against LangStandards.def?
 set(CLANG_DEFAULT_STD_C "" CACHE STRING
   "Default standard to use for C/ObjC code (IDENT from LangStandards.def, empty for platform default)")
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 5390606 - [OpaquePtr][Clang] Add CLANG_ENABLE_OPAQUE_POINTERS cmake option

2022-04-07 Thread Nikita Popov via cfe-commits

Author: Nikita Popov
Date: 2022-04-07T10:14:56+02:00
New Revision: 5390606aa963a7b415da65aa8120efbbafd30401

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

LOG: [OpaquePtr][Clang] Add CLANG_ENABLE_OPAQUE_POINTERS cmake option

This option controls whether -opaque-pointers or -no-opaque-pointers
is the default. Once opaque pointers are enabled by default, this
will provide a simple way to temporarily opt-out of the change.

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

Added: 


Modified: 
clang/CMakeLists.txt
clang/include/clang/Config/config.h.cmake
clang/include/clang/Driver/Options.td

Removed: 




diff  --git a/clang/CMakeLists.txt b/clang/CMakeLists.txt
index 931eecd9c9681..3a77e7b0c8d60 100644
--- a/clang/CMakeLists.txt
+++ b/clang/CMakeLists.txt
@@ -247,6 +247,17 @@ set(CLANG_SPAWN_CC1 OFF CACHE BOOL
 
 option(CLANG_DEFAULT_PIE_ON_LINUX "Default to -fPIE and -pie on linux-gnu" ON)
 
+# Manually handle default so we can change the meaning of a cached default.
+set(CLANG_ENABLE_OPAQUE_POINTERS "DEFAULT" CACHE STRING
+"Enable opaque pointers by default")
+if(CLANG_ENABLE_OPAQUE_POINTERS STREQUAL "DEFAULT")
+  set(CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL OFF)
+elseif(CLANG_ENABLE_OPAQUE_POINTERS)
+  set(CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL ON)
+else()
+  set(CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL OFF)
+endif()
+
 # TODO: verify the values against LangStandards.def?
 set(CLANG_DEFAULT_STD_C "" CACHE STRING
   "Default standard to use for C/ObjC code (IDENT from LangStandards.def, 
empty for platform default)")

diff  --git a/clang/include/clang/Config/config.h.cmake 
b/clang/include/clang/Config/config.h.cmake
index 10a93293c0512..680cc7310f76d 100644
--- a/clang/include/clang/Config/config.h.cmake
+++ b/clang/include/clang/Config/config.h.cmake
@@ -89,4 +89,7 @@
 /* Spawn a new process clang.exe for the CC1 tool invocation, when necessary */
 #cmakedefine01 CLANG_SPAWN_CC1
 
+/* Whether to enable opaque pointers by default */
+#cmakedefine01 CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL
+
 #endif

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 486276546770a..0f7cfa7eb883f 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -5507,7 +5507,7 @@ defm enable_noundef_analysis : BoolOption<"",
 defm opaque_pointers : BoolOption<"",
   "opaque-pointers",
   CodeGenOpts<"OpaquePointers">,
-  DefaultFalse,
+  Default<"CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL">,
   PosFlag,
   NegFlag,
   BothFlags<[], " opaque pointers">>;



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


[PATCH] D112621: [analyzer][solver] Introduce reasoning for not equal to operator

2022-04-07 Thread Manas Gupta via Phabricator via cfe-commits
manas updated this revision to Diff 421122.
manas added a comment.

Fix comments and rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112621

Files:
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  clang/test/Analysis/constant-folding.c

Index: clang/test/Analysis/constant-folding.c
===
--- clang/test/Analysis/constant-folding.c
+++ clang/test/Analysis/constant-folding.c
@@ -281,3 +281,59 @@
 clang_analyzer_eval((b % a) < x + 10); // expected-warning{{TRUE}}
   }
 }
+
+void testDisequalityRules(unsigned int u1, unsigned int u2, unsigned int u3,
+int s1, int s2, int s3) {
+
+  // Checks when ranges are not overlapping
+  if (u1 <= 10 && u2 >= 20) {
+// u1: [0,10], u2: [20,UINT_MAX]
+clang_analyzer_eval(u1 != u2); // expected-warning{{TRUE}}
+  }
+
+  if (s1 <= INT_MIN + 10 && s2 >= INT_MAX - 10) {
+// s1: [INT_MIN,INT_MIN + 10], s2: [INT_MAX - 10,INT_MAX]
+clang_analyzer_eval(s1 != s2); // expected-warning{{TRUE}}
+  }
+
+  // Checks when ranges are completely overlapping and have more than one point
+  if (u1 >= 20 && u1 <= 50 && u2 >= 20 && u2 <= 50) {
+// u1: [20,50], u2: [20,50]
+clang_analyzer_eval(u1 != u2); // expected-warning{{UNKNOWN}}
+  }
+
+  if (s1 >= -20 && s1 <= 20 && s2 >= -20 && s2 <= 20) {
+// s1: [-20,20], s2: [-20,20]
+clang_analyzer_eval(s1 != s2); // expected-warning{{UNKNOWN}}
+  }
+
+  // Checks when ranges are partially overlapping
+  if (u1 >= 100 && u1 <= 200 && u2 >= 150 && u2 <= 300) {
+// u1: [100,200], u2: [150,300]
+clang_analyzer_eval(u1 != u2); // expected-warning{{UNKNOWN}}
+  }
+
+  if (s1 >= -80 && s1 <= -50 && s2 >= -100 && s2 <= -75) {
+// s1: [-80,-50], s2: [-100,-75]
+clang_analyzer_eval(s1 != s2); // expected-warning{{UNKNOWN}}
+  }
+
+  // Checks for ranges which are subset of one-another
+  if (u1 >= 500 && u1 <= 1000 && u2 >= 750 && u2 <= 1000) {
+// u1: [500,1000], u2: [750,1000]
+clang_analyzer_eval(u1 != u2); // expected-warning{{UNKNOWN}}
+  }
+
+  if (s1 >= -1000 && s1 <= -500 && s2 <= -500 && s2 >= -750) {
+// s1: [-1000,-500], s2: [-500,-750]
+clang_analyzer_eval(s1 != s2); // expected-warning{{UNKNOWN}}
+  }
+
+  // Checks for comparison between different types
+  // Using different variables as previous constraints may interfere in the
+  // reasoning.
+  if (u3 <= 255 && s3 < 0) {
+// u3: [0, 255], s3: [INT_MIN, -1]
+clang_analyzer_eval(u3 != s3); // expected-warning{{TRUE}}
+  }
+}
Index: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -20,8 +20,8 @@
 #include "llvm/ADT/FoldingSet.h"
 #include "llvm/ADT/ImmutableSet.h"
 #include "llvm/ADT/STLExtras.h"
-#include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/SmallSet.h"
+#include "llvm/ADT/StringExtras.h"
 #include "llvm/Support/Compiler.h"
 #include "llvm/Support/raw_ostream.h"
 #include 
@@ -1136,18 +1136,7 @@
   }
 
   RangeSet VisitBinaryOperator(RangeSet LHS, BinaryOperator::Opcode Op,
-   RangeSet RHS, QualType T) {
-switch (Op) {
-case BO_Or:
-  return VisitBinaryOperator(LHS, RHS, T);
-case BO_And:
-  return VisitBinaryOperator(LHS, RHS, T);
-case BO_Rem:
-  return VisitBinaryOperator(LHS, RHS, T);
-default:
-  return infer(T);
-}
-  }
+   RangeSet RHS, QualType T);
 
   //===--===//
   // Ranges and operators
@@ -1412,6 +1401,49 @@
 //   Range-based reasoning about symbolic operations
 //===--===//
 
+template <>
+RangeSet SymbolicRangeInferrer::VisitBinaryOperator(RangeSet LHS,
+   RangeSet RHS,
+   QualType T) {
+
+  // We must check for empty RangeSets. This gets done via VisitBinaryOperator
+  // for other operators, but BO_NE is handled specifically.
+  if (LHS.isEmpty() || RHS.isEmpty()) {
+return RangeFactory.getEmptySet();
+  }
+
+  Range CoarseLHS = fillGaps(LHS);
+  Range CoarseRHS = fillGaps(RHS);
+
+  APSIntType ResultType = ValueFactory.getAPSIntType(T);
+
+  auto ConvertedCoarseLHS = convert(CoarseLHS, ResultType);
+  auto ConvertedCoarseRHS = convert(CoarseRHS, ResultType);
+
+  if (!ConvertedCoarseLHS || !ConvertedCoarseRHS) {
+return infer(T);
+  }
+
+  // When both the Ranges are non-overlapping then all possible pairs of (x, y)
+  // in ConvertedLHS, ConvertedRHS respectively, will satisfy expression
+  // (x != y).
+  if ((ConvertedCoarseLHS->To() < Conv

[PATCH] D123211: [flang][driver] Add support for generating LLVM bytecode files

2022-04-07 Thread Diana Picus via Phabricator via cfe-commits
rovka accepted this revision.
rovka added a comment.
This revision is now accepted and ready to land.

In D123211#3433059 , @awarzynski 
wrote:

> Thanks for taking a look Diana!
>
>> Why not use the BackendAction for this?
>
> This action only requires the middle-end in LLVM :) The `BackendAction` will 
> use the backend, but that's not needed here.

Is there actually a significant difference, besides the naming (which is easy 
to change)? AFAICT the BackendAction isn't initializing anything 
backend-related except very close to where it's using it, so that can happen 
inside a switch/if branch.

>> There seems to be a lot of shared code, up until the point where you create 
>> and use the pass manager
>
> This is the bit that's shared:
>
>   CompilerInstance &ci = this->instance();
>   // Generate an LLVM module if it's not already present (it will already be
>   // present if the input file is an LLVM IR/BC file).
>   if (!llvmModule)
> GenerateLLVMIR();
>   
>   // Create and configure `Target`
>   std::string error;
>   std::string theTriple = llvmModule->getTargetTriple();
>   const llvm::Target *theTarget =
>   llvm::TargetRegistry::lookupTarget(theTriple, error);
>   assert(theTarget && "Failed to create Target");
>   
>   // Create and configure `TargetMachine`
>   std::unique_ptr TM;
>   
>   TM.reset(theTarget->createTargetMachine(theTriple, /*CPU=*/"",
>   /*Features=*/"", llvm::TargetOptions(), llvm::None));
>   assert(TM && "Failed to create TargetMachine");
>   llvmModule->setDataLayout(TM->createDataLayout());
>
> I wouldn't say it's "a lot", but probably enough for a dedicated method. I've 
> been conservative with regard to sharing code as I anticipate things to 
> change in the future (I expect `-O{0|1|2|3|s|z}` to complicate the logic a 
> bit).

I was thinking also about the code for generating the output file, which can be 
folded into the switch from BackendAction. If you consider that too, it becomes 
a very large percentage of EmitLLVMBitcodeAction::ExecuteAction that can be 
shared.

>> (and in the future, when the backend switches to the new pass manager, there 
>> will be even more shared code).
>
> I'm not sure about the timelines for this. And even then, the logic might be 
> quite different (again, middle-end vs back-end).

Ok. IMO the template method pattern would work well here (or less formally, 
just a simple switch to the same effect), but I can understand if you think 
it's premature to go that route. 
No other objections from my side, thanks :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123211

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


[PATCH] D123289: [clangd][SymbolCollector] Introduce a cache for SymbolID generation and some cleanups

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

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D123289

Files:
  clang-tools-extra/clangd/index/SymbolCollector.cpp
  clang-tools-extra/clangd/index/SymbolCollector.h

Index: clang-tools-extra/clangd/index/SymbolCollector.h
===
--- clang-tools-extra/clangd/index/SymbolCollector.h
+++ clang-tools-extra/clangd/index/SymbolCollector.h
@@ -8,18 +8,21 @@
 #ifndef LLVM_CLANG_TOOLS_EXTRA_CLANGD_INDEX_SYMBOLCOLLECTOR_H
 #define LLVM_CLANG_TOOLS_EXTRA_CLANGD_INDEX_SYMBOLCOLLECTOR_H
 
-#include "index/CanonicalIncludes.h"
 #include "CollectMacros.h"
+#include "index/CanonicalIncludes.h"
 #include "index/Ref.h"
 #include "index/Relation.h"
 #include "index/Symbol.h"
+#include "index/SymbolID.h"
 #include "index/SymbolOrigin.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/Decl.h"
+#include "clang/AST/DeclBase.h"
 #include "clang/Basic/SourceLocation.h"
 #include "clang/Basic/SourceManager.h"
 #include "clang/Index/IndexDataConsumer.h"
 #include "clang/Index/IndexSymbol.h"
+#include "clang/Lex/MacroInfo.h"
 #include "clang/Sema/CodeCompleteConsumer.h"
 #include "llvm/ADT/DenseMap.h"
 #include 
@@ -141,6 +144,11 @@
   llvm::Optional getTokenLocation(SourceLocation TokLoc);
 
   llvm::Optional getIncludeHeader(const Symbol &S, FileID);
+  SymbolID getSymbolIDCached(const Decl *D);
+  SymbolID getSymbolIDCached(const llvm::StringRef MacroName,
+ const MacroInfo *MI, const SourceManager &SM);
+  void addRef(SymbolID ID, SourceLocation RefLoc, FileID FID,
+  index::SymbolRoleSet Roles, const Decl *Container, bool Spelled);
 
   // All Symbols collected from the AST.
   SymbolSlab::Builder Symbols;
@@ -162,16 +170,8 @@
   std::shared_ptr CompletionAllocator;
   std::unique_ptr CompletionTUInfo;
   Options Opts;
-  struct SymbolRef {
-SourceLocation Loc;
-index::SymbolRoleSet Roles;
-const Decl *Container;
-  };
   // Symbols referenced from the current TU, flushed on finish().
-  llvm::DenseSet ReferencedDecls;
-  llvm::DenseSet ReferencedMacros;
-  llvm::DenseMap> DeclRefs;
-  llvm::DenseMap> MacroRefs;
+  llvm::DenseSet ReferencedSymbols;
   // Maps canonical declaration provided by clang to canonical declaration for
   // an index symbol, if clangd prefers a different declaration than that
   // provided by clang. For example, friend declaration might be considered
@@ -184,6 +184,8 @@
   // to insert for which symbol, etc.
   class HeaderFileURICache;
   std::unique_ptr HeaderFileURIs;
+  llvm::DenseMap DeclToIDCache;
+  llvm::DenseMap MacroToIDCache;
 };
 
 } // namespace clangd
Index: clang-tools-extra/clangd/index/SymbolCollector.cpp
===
--- clang-tools-extra/clangd/index/SymbolCollector.cpp
+++ clang-tools-extra/clangd/index/SymbolCollector.cpp
@@ -14,6 +14,7 @@
 #include "SourceCode.h"
 #include "URI.h"
 #include "index/CanonicalIncludes.h"
+#include "index/Ref.h"
 #include "index/Relation.h"
 #include "index/SymbolID.h"
 #include "index/SymbolLocation.h"
@@ -543,6 +544,9 @@
   const NamedDecl *ND = dyn_cast(D);
   if (!ND)
 return true;
+  auto ID = getSymbolIDCached(ND);
+  if (!ID)
+return true;
 
   // Mark D as referenced if this is a reference coming from the main file.
   // D may not be an interesting symbol, but it's cheaper to check at the end.
@@ -550,11 +554,7 @@
   if (Opts.CountReferences &&
   (Roles & static_cast(index::SymbolRole::Reference)) &&
   SM.getFileID(SM.getSpellingLoc(Loc)) == SM.getMainFileID())
-ReferencedDecls.insert(ND);
-
-  auto ID = getSymbolID(ND);
-  if (!ID)
-return true;
+ReferencedSymbols.insert(ID);
 
   // ND is the canonical (i.e. first) declaration. If it's in the main file
   // (which is not a header), then no public declaration was visible, so assume
@@ -575,13 +575,6 @@
   processRelations(*ND, ID, Relations);
 
   bool CollectRef = static_cast(Opts.RefFilter & toRefKind(Roles));
-  bool IsOnlyRef =
-  !(Roles & (static_cast(index::SymbolRole::Declaration) |
- static_cast(index::SymbolRole::Definition)));
-
-  if (IsOnlyRef && !CollectRef)
-return true;
-
   // Unlike other fields, e.g. Symbols (which use spelling locations), we use
   // file locations for references (as it aligns the behavior of clangd's
   // AST-based xref).
@@ -589,13 +582,33 @@
   if (CollectRef &&
   (!IsMainFileOnly || Opts.CollectMainFileRefs ||
ND->isExternallyVisible()) &&
-  !isa(ND) &&
-  (Opts.RefsInHeaders ||
-   SM.getFileID(SM.getFileLoc(Loc)) == SM.getMainFileID()))
-DeclRefs[ND].push_back(SymbolRef{SM.getFileLoc(Loc), Roles,
-  

[PATCH] D122008: [flang][driver] Add support for generating executables

2022-04-07 Thread Diana Picus via Phabricator via cfe-commits
rovka added a comment.

Just for the record, I'd like to speak in favor of option 2 - merge the patch 
now, but put the functionality behind a flag. This sounds like a good 
compromise to me. I think if we choose an inconspicuous name like 
-fexperimentail-test-driver-integration-with-cmake (or something even more 
obfuscated) we'll be off most users' radar, while at the same time making 
progress with cmake. We should probably first confirm that it would be 
acceptable for the cmake developers to go ahead with something like that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122008

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


[clang-tools-extra] 817df79 - [clang-tidy] Silence unused variable warning in release builds. NFCI.

2022-04-07 Thread Benjamin Kramer via cfe-commits

Author: Benjamin Kramer
Date: 2022-04-07T11:00:28+02:00
New Revision: 817df7999a71a5dbda0025b75612b54160fb5f9c

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

LOG: [clang-tidy] Silence unused variable warning in release builds. NFCI.

Added: 


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

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp 
b/clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
index 37d373905b693..dcc01589f1162 100644
--- a/clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
+++ b/clang-tools-extra/clang-tidy/bugprone/SignalHandlerCheck.cpp
@@ -335,12 +335,11 @@ void SignalHandlerCheck::registerMatchers(MatchFinder 
*Finder) {
 }
 
 void SignalHandlerCheck::check(const MatchFinder::MatchResult &Result) {
-  const auto *SignalCall = Result.Nodes.getNodeAs("register_call");
   const auto *HandlerDecl =
   Result.Nodes.getNodeAs("handler_decl");
   const auto *HandlerExpr = 
Result.Nodes.getNodeAs("handler_expr");
-  assert(SignalCall && HandlerDecl && HandlerExpr &&
- "All of these should exist in a match here.");
+  assert(Result.Nodes.getNodeAs("register_call") && HandlerDecl &&
+ HandlerExpr && "All of these should exist in a match here.");
 
   if (CG.size() <= 1) {
 // Call graph must be populated with the entire TU at the beginning.



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


[clang] 5479174 - [clang][ASTImporter] Not using consumeError at failed import of in-class initializer.

2022-04-07 Thread Balázs Kéri via cfe-commits

Author: Balázs Kéri
Date: 2022-04-07T11:07:15+02:00
New Revision: 5479174071ec7d4692959bbdc15b5bb79e268e00

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

LOG: [clang][ASTImporter] Not using consumeError at failed import of in-class 
initializer.

The error can be returned from the function, the problem written in comment 
before
does not exist. The same is done already in ASTImporter at various import 
failures.

After a declaration is created in an `ASTNodeImporter` import function
with `GetImportedOrCreateDecl`, that function registers it with
`MapImported`. At many places import errors can happen after this
and the error is returned. The same can be done in the place where
the in-class initializer is imported.

Reviewed By: martong

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

Added: 


Modified: 
clang/lib/AST/ASTImporter.cpp

Removed: 




diff  --git a/clang/lib/AST/ASTImporter.cpp b/clang/lib/AST/ASTImporter.cpp
index 5661e55b5505d..e3b3deff7c5c9 100644
--- a/clang/lib/AST/ASTImporter.cpp
+++ b/clang/lib/AST/ASTImporter.cpp
@@ -3658,11 +3658,7 @@ ExpectedDecl ASTNodeImporter::VisitFieldDecl(FieldDecl 
*D) {
 if (!FoundField->getInClassInitializer())
   FoundField->setInClassInitializer(*ToInitializerOrErr);
   } else {
-// We can't return error here,
-// since we already mapped D as imported.
-// FIXME: warning message?
-consumeError(ToInitializerOrErr.takeError());
-return FoundField;
+  return ToInitializerOrErr.takeError();
   }
 }
 return FoundField;



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


[PATCH] D122528: [clang][ASTImporter] Not using consumeError at failed import of in-class initializer.

2022-04-07 Thread Balázs Kéri via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG5479174071ec: [clang][ASTImporter] Not using consumeError at 
failed import of in-class… (authored by balazske).

Changed prior to commit:
  https://reviews.llvm.org/D122528?vs=418395&id=421132#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122528

Files:
  clang/lib/AST/ASTImporter.cpp


Index: clang/lib/AST/ASTImporter.cpp
===
--- clang/lib/AST/ASTImporter.cpp
+++ clang/lib/AST/ASTImporter.cpp
@@ -3658,11 +3658,7 @@
 if (!FoundField->getInClassInitializer())
   FoundField->setInClassInitializer(*ToInitializerOrErr);
   } else {
-// We can't return error here,
-// since we already mapped D as imported.
-// FIXME: warning message?
-consumeError(ToInitializerOrErr.takeError());
-return FoundField;
+  return ToInitializerOrErr.takeError();
   }
 }
 return FoundField;


Index: clang/lib/AST/ASTImporter.cpp
===
--- clang/lib/AST/ASTImporter.cpp
+++ clang/lib/AST/ASTImporter.cpp
@@ -3658,11 +3658,7 @@
 if (!FoundField->getInClassInitializer())
   FoundField->setInClassInitializer(*ToInitializerOrErr);
   } else {
-// We can't return error here,
-// since we already mapped D as imported.
-// FIXME: warning message?
-consumeError(ToInitializerOrErr.takeError());
-return FoundField;
+  return ToInitializerOrErr.takeError();
   }
 }
 return FoundField;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D123259: [clang][ExtractAPI] Fix appendSpace in DeclarationFragments

2022-04-07 Thread Daniel Grumberg via Phabricator via cfe-commits
dang accepted this revision.
dang added a comment.

LGTM thanks for spotting this!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123259

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


[PATCH] D112621: [analyzer][solver] Introduce reasoning for not equal to operator

2022-04-07 Thread Manas Gupta via Phabricator via cfe-commits
manas updated this revision to Diff 421134.
manas added a comment.

Format constant-folding.c


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112621

Files:
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  clang/test/Analysis/constant-folding.c

Index: clang/test/Analysis/constant-folding.c
===
--- clang/test/Analysis/constant-folding.c
+++ clang/test/Analysis/constant-folding.c
@@ -281,3 +281,59 @@
 clang_analyzer_eval((b % a) < x + 10); // expected-warning{{TRUE}}
   }
 }
+
+void testDisequalityRules(unsigned int u1, unsigned int u2, unsigned int u3,
+  int s1, int s2, int s3) {
+
+  // Checks when ranges are not overlapping
+  if (u1 <= 10 && u2 >= 20) {
+// u1: [0,10], u2: [20,UINT_MAX]
+clang_analyzer_eval(u1 != u2); // expected-warning{{TRUE}}
+  }
+
+  if (s1 <= INT_MIN + 10 && s2 >= INT_MAX - 10) {
+// s1: [INT_MIN,INT_MIN + 10], s2: [INT_MAX - 10,INT_MAX]
+clang_analyzer_eval(s1 != s2); // expected-warning{{TRUE}}
+  }
+
+  // Checks when ranges are completely overlapping and have more than one point
+  if (u1 >= 20 && u1 <= 50 && u2 >= 20 && u2 <= 50) {
+// u1: [20,50], u2: [20,50]
+clang_analyzer_eval(u1 != u2); // expected-warning{{UNKNOWN}}
+  }
+
+  if (s1 >= -20 && s1 <= 20 && s2 >= -20 && s2 <= 20) {
+// s1: [-20,20], s2: [-20,20]
+clang_analyzer_eval(s1 != s2); // expected-warning{{UNKNOWN}}
+  }
+
+  // Checks when ranges are partially overlapping
+  if (u1 >= 100 && u1 <= 200 && u2 >= 150 && u2 <= 300) {
+// u1: [100,200], u2: [150,300]
+clang_analyzer_eval(u1 != u2); // expected-warning{{UNKNOWN}}
+  }
+
+  if (s1 >= -80 && s1 <= -50 && s2 >= -100 && s2 <= -75) {
+// s1: [-80,-50], s2: [-100,-75]
+clang_analyzer_eval(s1 != s2); // expected-warning{{UNKNOWN}}
+  }
+
+  // Checks for ranges which are subset of one-another
+  if (u1 >= 500 && u1 <= 1000 && u2 >= 750 && u2 <= 1000) {
+// u1: [500,1000], u2: [750,1000]
+clang_analyzer_eval(u1 != u2); // expected-warning{{UNKNOWN}}
+  }
+
+  if (s1 >= -1000 && s1 <= -500 && s2 <= -500 && s2 >= -750) {
+// s1: [-1000,-500], s2: [-500,-750]
+clang_analyzer_eval(s1 != s2); // expected-warning{{UNKNOWN}}
+  }
+
+  // Checks for comparison between different types
+  // Using different variables as previous constraints may interfere in the
+  // reasoning.
+  if (u3 <= 255 && s3 < 0) {
+// u3: [0, 255], s3: [INT_MIN, -1]
+clang_analyzer_eval(u3 != s3); // expected-warning{{TRUE}}
+  }
+}
Index: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -20,8 +20,8 @@
 #include "llvm/ADT/FoldingSet.h"
 #include "llvm/ADT/ImmutableSet.h"
 #include "llvm/ADT/STLExtras.h"
-#include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/SmallSet.h"
+#include "llvm/ADT/StringExtras.h"
 #include "llvm/Support/Compiler.h"
 #include "llvm/Support/raw_ostream.h"
 #include 
@@ -1136,18 +1136,7 @@
   }
 
   RangeSet VisitBinaryOperator(RangeSet LHS, BinaryOperator::Opcode Op,
-   RangeSet RHS, QualType T) {
-switch (Op) {
-case BO_Or:
-  return VisitBinaryOperator(LHS, RHS, T);
-case BO_And:
-  return VisitBinaryOperator(LHS, RHS, T);
-case BO_Rem:
-  return VisitBinaryOperator(LHS, RHS, T);
-default:
-  return infer(T);
-}
-  }
+   RangeSet RHS, QualType T);
 
   //===--===//
   // Ranges and operators
@@ -1412,6 +1401,49 @@
 //   Range-based reasoning about symbolic operations
 //===--===//
 
+template <>
+RangeSet SymbolicRangeInferrer::VisitBinaryOperator(RangeSet LHS,
+   RangeSet RHS,
+   QualType T) {
+
+  // We must check for empty RangeSets. This gets done via VisitBinaryOperator
+  // for other operators, but BO_NE is handled specifically.
+  if (LHS.isEmpty() || RHS.isEmpty()) {
+return RangeFactory.getEmptySet();
+  }
+
+  Range CoarseLHS = fillGaps(LHS);
+  Range CoarseRHS = fillGaps(RHS);
+
+  APSIntType ResultType = ValueFactory.getAPSIntType(T);
+
+  auto ConvertedCoarseLHS = convert(CoarseLHS, ResultType);
+  auto ConvertedCoarseRHS = convert(CoarseRHS, ResultType);
+
+  if (!ConvertedCoarseLHS || !ConvertedCoarseRHS) {
+return infer(T);
+  }
+
+  // When both the Ranges are non-overlapping then all possible pairs of (x, y)
+  // in ConvertedLHS, ConvertedRHS respectively, will satisfy expression
+  // (x != y).
+  if ((Convert

[PATCH] D120305: [Driver] Default CLANG_DEFAULT_PIE_ON_LINUX to ON

2022-04-07 Thread Nikita Popov via Phabricator via cfe-commits
nikic added a comment.

Looks like this causes a relocation failure on this buildbot: 
https://lab.llvm.org/buildbot/#/builders/169/builds/7311

  ld.lld: error: relocation R_MIPS_64 cannot be used against local symbol; 
recompile with -fPIC
  >>> defined in ScudoUnitTestsObjects.wrappers_cpp_test.cpp.mips64.o
  >>> referenced by wrappers_cpp_test.cpp
  >>>   
ScudoUnitTestsObjects.wrappers_cpp_test.cpp.mips64.o:(.eh_frame+0x15A39)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120305

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


[PATCH] D123148: [clang][extract-api] Process only APIs declared in inputs

2022-04-07 Thread Daniel Grumberg via Phabricator via cfe-commits
dang updated this revision to Diff 421143.
dang added a comment.

Rebase on top of latest changes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123148

Files:
  clang/include/clang/ExtractAPI/FrontendActions.h
  clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
  clang/test/ExtractAPI/known_files_only.c
  clang/test/ExtractAPI/known_files_only_hmap.c

Index: clang/test/ExtractAPI/known_files_only_hmap.c
===
--- /dev/null
+++ clang/test/ExtractAPI/known_files_only_hmap.c
@@ -0,0 +1,164 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: sed -e "s@INPUT_DIR@%/t@g" %t/reference.output.json.in >> \
+// RUN: %t/reference.output.json
+// RUN: sed -e "s@INPUT_DIR@%/t@g" %t/known_files_only.hmap.json.in >> \
+// RUN: %t/known_files_only.hmap.json
+// RUN: %hmaptool write %t/known_files_only.hmap.json %t/known_files_only.hmap
+// RUN: %clang -extract-api --product-name=KnownFilesOnlyHmap -target arm64-apple-macosx \
+// RUN: -I%t/known_files_only.hmap -I%t/subdir %t/subdir/subdir1/input.h \
+// RUN: %t/subdir/subdir2/known_file.h -o %t/output.json | FileCheck -allow-empty %s
+
+// Generator version is not consistent across test runs, normalize it.
+// RUN: sed -e "s@\"generator\": \".*\"@\"generator\": \"?\"@g" \
+// RUN: %t/output.json >> %t/output-normalized.json
+// RUN: diff %t/reference.output.json %t/output-normalized.json
+
+// CHECK-NOT: error:
+// CHECK-NOT: warning:
+//--- known_files_only.hmap.json.in
+{
+  "mappings" :
+{
+ "subdir2/known_file.h" : "INPUT_DIR/subdir/subdir3/unknown.h"
+}
+}
+
+//--- subdir/subdir1/input.h
+int num;
+#include "subdir2/known_file.h"
+
+//--- subdir/subdir2/known_file.h
+int known_num;
+
+//--- subdir/subdir3/unknown.h
+// Ensure that these symbols are not emitted in the Symbol Graph.
+#ifndef INPUT4_H
+#define INPUT4_H
+
+#define HELLO 1
+char not_emitted;
+void foo(int);
+struct Foo { int a; };
+
+#endif
+
+//--- reference.output.json.in
+{
+  "metadata": {
+"formatVersion": {
+  "major": 0,
+  "minor": 5,
+  "patch": 3
+},
+"generator": "?"
+  },
+  "module": {
+"name": "KnownFilesOnlyHmap",
+"platform": {
+  "architecture": "arm64",
+  "operatingSystem": {
+"minimumVersion": {
+  "major": 11,
+  "minor": 0,
+  "patch": 0
+},
+"name": "macosx"
+  },
+  "vendor": "apple"
+}
+  },
+  "relationships": [],
+  "symbols": [
+{
+  "accessLevel": "public",
+  "declarationFragments": [
+{
+  "kind": "typeIdentifier",
+  "preciseIdentifier": "c:I",
+  "spelling": "int"
+},
+{
+  "kind": "text",
+  "spelling": " "
+},
+{
+  "kind": "identifier",
+  "spelling": "num"
+}
+  ],
+  "identifier": {
+"interfaceLanguage": "c",
+"precise": "c:@num"
+  },
+  "kind": {
+"displayName": "Global Variable",
+"identifier": "c.var"
+  },
+  "location": {
+"position": {
+  "character": 5,
+  "line": 1
+},
+"uri": "file://INPUT_DIR/subdir/subdir1/input.h"
+  },
+  "names": {
+"subHeading": [
+  {
+"kind": "identifier",
+"spelling": "num"
+  }
+],
+"title": "num"
+  },
+  "pathComponents": [
+"num"
+  ]
+},
+{
+  "accessLevel": "public",
+  "declarationFragments": [
+{
+  "kind": "typeIdentifier",
+  "preciseIdentifier": "c:I",
+  "spelling": "int"
+},
+{
+  "kind": "text",
+  "spelling": " "
+},
+{
+  "kind": "identifier",
+  "spelling": "known_num"
+}
+  ],
+  "identifier": {
+"interfaceLanguage": "c",
+"precise": "c:@known_num"
+  },
+  "kind": {
+"displayName": "Global Variable",
+"identifier": "c.var"
+  },
+  "location": {
+"position": {
+  "character": 5,
+  "line": 1
+},
+"uri": "file://INPUT_DIR/subdir/subdir2/known_file.h"
+  },
+  "names": {
+"subHeading": [
+  {
+"kind": "identifier",
+"spelling": "known_num"
+  }
+],
+"title": "known_num"
+  },
+  "pathComponents": [
+"known_num"
+  ]
+}
+  ]
+}
Index: clang/test/ExtractAPI/known_files_only.c
===
--- /dev/null
+++ clang/test/ExtractAPI/known_files_only.c
@@ -0,0 +1,100 @@
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: sed -e "s@INPUT_DIR@%/t@g" %t/reference.output.json.in >> \
+// RUN: %t/reference.output.json
+// RUN: %clang -extract-api --product-name=GlobalRecord -target arm64-apple-macosx \
+// RUN: 

[PATCH] D122248: [clang][CodeGen]Fix clang crash and add bitfield support in __builtin_dump_struct

2022-04-07 Thread Wang Yihan via Phabricator via cfe-commits
yihanaa added inline comments.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:2113-2117
 if (CanonicalType->isRecordType()) {
-  TmpRes = dumpRecord(CGF, CanonicalType, FieldPtr, Align, Func, Lvl + 1);
+  TmpRes = dumpRecord(CGF, CanonicalType, FieldLV, Align, Func, Lvl + 1);
   Res = CGF.Builder.CreateAdd(TmpRes, Res);
   continue;
 }

yihanaa wrote:
> yihanaa wrote:
> > yihanaa wrote:
> > > rsmith wrote:
> > > > After this patch, this case no longer prints the field name. Eg: 
> > > > https://godbolt.org/z/o7vcbWaEf
> > > > 
> > > > ```
> > > > #include 
> > > > 
> > > > struct A {};
> > > > 
> > > > struct B {
> > > > A a;
> > > > };
> > > > 
> > > > 
> > > > int main() {
> > > > B x;
> > > > __builtin_dump_struct(&x, &printf);
> > > > }
> > > > ```
> > > > 
> > > > now prints:
> > > > 
> > > > ```
> > > > B {
> > > > A {
> > > > }
> > > > }
> > > > ```
> > > > 
> > > > This seems like an important regression; please can you take a look? 
> > > > This also suggests to me that there's a hole in our test coverage.
> > > Thanks for taking the time to review my patch and writing the Compiler 
> > > Explorer examples, I'll take a look at this  problem
> > > After this patch, this case no longer prints the field name. Eg: 
> > > https://godbolt.org/z/o7vcbWaEf
> > > 
> > > ```
> > > #include 
> > > 
> > > struct A {};
> > > 
> > > struct B {
> > > A a;
> > > };
> > > 
> > > 
> > > int main() {
> > > B x;
> > > __builtin_dump_struct(&x, &printf);
> > > }
> > > ```
> > > 
> > > now prints:
> > > 
> > > ```
> > > B {
> > > A {
> > > }
> > > }
> > > ```
> > > 
> > > This seems like an important regression; please can you take a look? This 
> > > also suggests to me that there's a hole in our test coverage.
> > 
> > I'm sorry for introducing this bug. 😔 Do you think the following is correct 
> > behavior? If yes I will try to fix it.
> > ```
> > struct B {
> > struct A a = {
> > }
> > }
> > ```
> I have submitted a patch to fix this. https://reviews.llvm.org/D122920
> I have submitted a patch to fix this. https://reviews.llvm.org/D122920

Please can you take a review?@rsmith


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122248

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


[PATCH] D123115: [OpaquePtrs][Clang] Add -no-opaque-pointers to tests

2022-04-07 Thread Nikita Popov 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 rG532dc62b9075: [OpaquePtrs][Clang] Add -no-opaque-pointers to 
tests (NFC) (authored by nikic).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D123115?vs=420439&id=421146#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123115

Files:
  clang/test/CXX/drs/dr158.cpp
  clang/test/CXX/except/except.spec/p14-ir.cpp
  clang/test/CXX/except/except.spec/p9-dynamic.cpp
  clang/test/CXX/except/except.spec/p9-noexcept.cpp
  clang/test/CXX/expr/expr.prim/expr.prim.lambda/blocks-irgen.mm
  clang/test/CXX/expr/p10-0x.cpp
  clang/test/CXX/special/class.copy/p15-inclass.cpp
  clang/test/CodeGen/2004-02-13-BuiltinFrameReturnAddress.c
  clang/test/CodeGen/2005-01-02-ConstantInits.c
  clang/test/CodeGen/2005-12-04-AttributeUsed.c
  clang/test/CodeGen/2006-01-13-StackSave.c
  clang/test/CodeGen/2006-05-19-SingleEltReturn.c
  clang/test/CodeGen/2007-03-27-VarLengthArray.c
  clang/test/CodeGen/2007-05-16-EmptyStruct.c
  clang/test/CodeGen/2007-11-07-CopyAggregateAlign.c
  clang/test/CodeGen/2007-11-07-ZeroAggregateAlign.c
  clang/test/CodeGen/2008-03-05-syncPtr.c
  clang/test/CodeGen/2008-08-07-AlignPadding1.c
  clang/test/CodeGen/2009-02-13-zerosize-union-field.c
  clang/test/CodeGen/2010-01-13-MemBarrier.c
  clang/test/CodeGen/2010-05-26-AsmSideEffect.c
  clang/test/CodeGen/2010-07-14-overconservative-align.c
  clang/test/CodeGen/2010-07-14-ref-off-end.c
  clang/test/CodeGen/2011-03-31-ArrayRefFolding.c
  clang/test/CodeGen/24-bit.c
  clang/test/CodeGen/64bit-swiftcall.c
  clang/test/CodeGen/Atomics.c
  clang/test/CodeGen/Nontemporal.cpp
  clang/test/CodeGen/PowerPC/aix-alignment.c
  clang/test/CodeGen/PowerPC/aix-altivec-vaargs.c
  clang/test/CodeGen/PowerPC/aix-altivec.c
  clang/test/CodeGen/PowerPC/aix-constructor-attribute.c
  clang/test/CodeGen/PowerPC/aix-destructor-attribute.c
  clang/test/CodeGen/PowerPC/aix-ignore-xcoff-visibility.cpp
  clang/test/CodeGen/PowerPC/aix-init-priority-attribute.cpp
  clang/test/CodeGen/PowerPC/aix-struct-arg.c
  clang/test/CodeGen/PowerPC/aix-vaargs.c
  clang/test/CodeGen/PowerPC/aix32-complex-varargs.c
  clang/test/CodeGen/PowerPC/bool_test.c
  clang/test/CodeGen/PowerPC/builtins-ppc-32bit-vec-ll.c
  clang/test/CodeGen/PowerPC/builtins-ppc-altivec.c
  clang/test/CodeGen/PowerPC/builtins-ppc-build-pair-mma.c
  clang/test/CodeGen/PowerPC/builtins-ppc-cache.c
  clang/test/CodeGen/PowerPC/builtins-ppc-fastmath.c
  clang/test/CodeGen/PowerPC/builtins-ppc-ld-st-rmb.c
  clang/test/CodeGen/PowerPC/builtins-ppc-p10vector.c
  clang/test/CodeGen/PowerPC/builtins-ppc-p9vector.c
  clang/test/CodeGen/PowerPC/builtins-ppc-pair-mma.c
  clang/test/CodeGen/PowerPC/builtins-ppc-quadword.c
  clang/test/CodeGen/PowerPC/builtins-ppc-vsx.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xl-xst.c
  
clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-LoadReseve-StoreCond-64bit-only.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-LoadReseve-StoreCond.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-cas.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-cmplx.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-compare.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-fetch.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-fp.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-load-store-reversed.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-macros.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-math.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-prefetch.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-pwr8.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-rotate.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-stfiw.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-swdiv.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-swdiv_nochk.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat-sync.c
  clang/test/CodeGen/PowerPC/builtins-ppc-xlcompat.c
  clang/test/CodeGen/PowerPC/ignore-exceptions.cpp
  clang/test/CodeGen/PowerPC/powerpc-c99complex.c
  clang/test/CodeGen/PowerPC/ppc-aggregate-abi.cpp
  clang/test/CodeGen/PowerPC/ppc-mma-types.c
  clang/test/CodeGen/PowerPC/ppc-varargs-struct.c
  clang/test/CodeGen/PowerPC/ppc32-and-aix-struct-return.c
  clang/test/CodeGen/PowerPC/ppc32-dwarf.c
  clang/test/CodeGen/PowerPC/ppc64-align-struct.c
  clang/test/CodeGen/PowerPC/ppc64-complex-parms.c
  clang/test/CodeGen/PowerPC/ppc64-dwarf.c
  clang/test/CodeGen/PowerPC/ppc64-elf-abi.c
  clang/test/CodeGen/PowerPC/ppc64-f128-builtins.c
  clang/test/CodeGen/PowerPC/ppc64-inline-asm.c
  clang/test/CodeGen/PowerPC/ppc64-soft-float.c
  clang/test/CodeGen/PowerPC/ppc64-struct-onefloat.c
  clang/test/CodeGen/PowerPC/ppc64-varargs-complex.c
  clang/test/CodeGen/PowerPC/ppc64-vector

[PATCH] D123295: [clang][extract-api] Use dedicated API to check for macro equality

2022-04-07 Thread Daniel Grumberg via Phabricator via cfe-commits
dang created this revision.
dang added reviewers: zixuw, ributzka.
Herald added a project: All.
dang requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D123295

Files:
  clang/lib/ExtractAPI/ExtractAPIConsumer.cpp


Index: clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
===
--- clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
+++ clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
@@ -587,7 +587,8 @@
 
 class MacroCallback : public PPCallbacks {
 public:
-  MacroCallback(const SourceManager &SM, APISet &API) : SM(SM), API(API) {}
+  MacroCallback(const SourceManager &SM, APISet &API, Preprocessor &PP)
+  : SM(SM), API(API), PP(PP) {}
 
   void MacroDefined(const Token &MacroNameToken,
 const MacroDirective *MD) override {
@@ -614,9 +615,9 @@
 if (!Undef)
   return;
 
-llvm::erase_if(PendingMacros, [&MD](const PendingMacro &PM) {
-  return MD.getMacroInfo()->getDefinitionLoc() ==
- PM.MD->getMacroInfo()->getDefinitionLoc();
+llvm::erase_if(PendingMacros, [&MD, this](const PendingMacro &PM) {
+  return MD.getMacroInfo()->isIdenticalTo(*PM.MD->getMacroInfo(), PP,
+  /*Syntactically*/ false);
 });
   }
 
@@ -652,6 +653,7 @@
 
   const SourceManager &SM;
   APISet &API;
+  Preprocessor &PP;
   llvm::SmallVector PendingMacros;
 };
 
@@ -672,8 +674,8 @@
   CI.getFrontendOpts().Inputs.back().getKind().getLanguage());
 
   // Register preprocessor callbacks that will add macro definitions to API.
-  CI.getPreprocessor().addPPCallbacks(
-  std::make_unique(CI.getSourceManager(), *API));
+  CI.getPreprocessor().addPPCallbacks(std::make_unique(
+  CI.getSourceManager(), *API, CI.getPreprocessor()));
 
   return std::make_unique(CI.getASTContext(), *API);
 }


Index: clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
===
--- clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
+++ clang/lib/ExtractAPI/ExtractAPIConsumer.cpp
@@ -587,7 +587,8 @@
 
 class MacroCallback : public PPCallbacks {
 public:
-  MacroCallback(const SourceManager &SM, APISet &API) : SM(SM), API(API) {}
+  MacroCallback(const SourceManager &SM, APISet &API, Preprocessor &PP)
+  : SM(SM), API(API), PP(PP) {}
 
   void MacroDefined(const Token &MacroNameToken,
 const MacroDirective *MD) override {
@@ -614,9 +615,9 @@
 if (!Undef)
   return;
 
-llvm::erase_if(PendingMacros, [&MD](const PendingMacro &PM) {
-  return MD.getMacroInfo()->getDefinitionLoc() ==
- PM.MD->getMacroInfo()->getDefinitionLoc();
+llvm::erase_if(PendingMacros, [&MD, this](const PendingMacro &PM) {
+  return MD.getMacroInfo()->isIdenticalTo(*PM.MD->getMacroInfo(), PP,
+  /*Syntactically*/ false);
 });
   }
 
@@ -652,6 +653,7 @@
 
   const SourceManager &SM;
   APISet &API;
+  Preprocessor &PP;
   llvm::SmallVector PendingMacros;
 };
 
@@ -672,8 +674,8 @@
   CI.getFrontendOpts().Inputs.back().getKind().getLanguage());
 
   // Register preprocessor callbacks that will add macro definitions to API.
-  CI.getPreprocessor().addPPCallbacks(
-  std::make_unique(CI.getSourceManager(), *API));
+  CI.getPreprocessor().addPPCallbacks(std::make_unique(
+  CI.getSourceManager(), *API, CI.getPreprocessor()));
 
   return std::make_unique(CI.getASTContext(), *API);
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D123296: [llvm][AArch64] Generate getExtensionFeatures from the list of extensions

2022-04-07 Thread David Spickett via Phabricator via cfe-commits
DavidSpickett created this revision.
Herald added subscribers: hiraditya, kristof.beyls.
Herald added a project: All.
DavidSpickett requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

This takes the AARCH64_ARCH_EXT_NAME in AArch64TargetParser.def and uses
it to generate all the "if bit is set add this feature name" code.

Which gives us a bunch that we were missing. I've updated testing
to include those and reordered them to match the order in the .def.

The final part of the test will catch any missing extensions if
we somehow manage to not generate an if block for them.

This has changed the order of cc1's "-target-feature" output so I've
updated some tests in clang to reflect that.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D123296

Files:
  clang/test/Preprocessor/aarch64-target-features.c
  llvm/lib/Support/AArch64TargetParser.cpp
  llvm/unittests/Support/TargetParserTest.cpp

Index: llvm/unittests/Support/TargetParserTest.cpp
===
--- llvm/unittests/Support/TargetParserTest.cpp
+++ llvm/unittests/Support/TargetParserTest.cpp
@@ -12,6 +12,7 @@
 #include "llvm/Support/ARMBuildAttributes.h"
 #include "llvm/Support/FormatVariadic.h"
 #include "llvm/Support/TargetParser.h"
+#include "gmock/gmock.h"
 #include "gtest/gtest.h"
 #include 
 
@@ -1448,14 +1449,20 @@
 
 TEST(TargetParserTest, AArch64ExtensionFeatures) {
   std::vector Extensions = {
-  AArch64::AEK_CRC, AArch64::AEK_CRYPTO,  AArch64::AEK_FP,
-  AArch64::AEK_SIMD,AArch64::AEK_FP16,AArch64::AEK_PROFILE,
-  AArch64::AEK_RAS, AArch64::AEK_LSE, AArch64::AEK_RDM,
-  AArch64::AEK_DOTPROD, AArch64::AEK_SVE, AArch64::AEK_SVE2,
-  AArch64::AEK_SVE2AES, AArch64::AEK_SVE2SM4, AArch64::AEK_SVE2SHA3,
-  AArch64::AEK_SVE2BITPERM, AArch64::AEK_RCPC,AArch64::AEK_FP16FML,
-  AArch64::AEK_SME, AArch64::AEK_SMEF64,  AArch64::AEK_SMEI64,
-  AArch64::AEK_PERFMON};
+  AArch64::AEK_CRC, AArch64::AEK_LSE,  AArch64::AEK_RDM,
+  AArch64::AEK_CRYPTO,  AArch64::AEK_SM4,  AArch64::AEK_SHA3,
+  AArch64::AEK_SHA2,AArch64::AEK_AES,  AArch64::AEK_DOTPROD,
+  AArch64::AEK_FP,  AArch64::AEK_SIMD, AArch64::AEK_FP16,
+  AArch64::AEK_FP16FML, AArch64::AEK_PROFILE,  AArch64::AEK_RAS,
+  AArch64::AEK_SVE, AArch64::AEK_SVE2, AArch64::AEK_SVE2AES,
+  AArch64::AEK_SVE2SM4, AArch64::AEK_SVE2SHA3, AArch64::AEK_SVE2BITPERM,
+  AArch64::AEK_RCPC,AArch64::AEK_RAND, AArch64::AEK_MTE,
+  AArch64::AEK_SSBS,AArch64::AEK_SB,   AArch64::AEK_PREDRES,
+  AArch64::AEK_BF16,AArch64::AEK_I8MM, AArch64::AEK_F32MM,
+  AArch64::AEK_F64MM,   AArch64::AEK_TME,  AArch64::AEK_LS64,
+  AArch64::AEK_BRBE,AArch64::AEK_PAUTH,AArch64::AEK_FLAGM,
+  AArch64::AEK_SME, AArch64::AEK_SMEF64,   AArch64::AEK_SMEI64,
+  AArch64::AEK_HBC, AArch64::AEK_MOPS, AArch64::AEK_PERFMON};
 
   std::vector Features;
 
@@ -1470,27 +1477,54 @@
   EXPECT_EQ(Extensions.size(), Features.size());
 
   EXPECT_TRUE(llvm::is_contained(Features, "+crc"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+lse"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+rdm"));
   EXPECT_TRUE(llvm::is_contained(Features, "+crypto"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+sm4"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+sha3"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+sha2"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+aes"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+dotprod"));
   EXPECT_TRUE(llvm::is_contained(Features, "+fp-armv8"));
   EXPECT_TRUE(llvm::is_contained(Features, "+neon"));
   EXPECT_TRUE(llvm::is_contained(Features, "+fullfp16"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+fp16fml"));
   EXPECT_TRUE(llvm::is_contained(Features, "+spe"));
   EXPECT_TRUE(llvm::is_contained(Features, "+ras"));
-  EXPECT_TRUE(llvm::is_contained(Features, "+lse"));
-  EXPECT_TRUE(llvm::is_contained(Features, "+rdm"));
-  EXPECT_TRUE(llvm::is_contained(Features, "+dotprod"));
-  EXPECT_TRUE(llvm::is_contained(Features, "+rcpc"));
-  EXPECT_TRUE(llvm::is_contained(Features, "+fp16fml"));
   EXPECT_TRUE(llvm::is_contained(Features, "+sve"));
   EXPECT_TRUE(llvm::is_contained(Features, "+sve2"));
   EXPECT_TRUE(llvm::is_contained(Features, "+sve2-aes"));
   EXPECT_TRUE(llvm::is_contained(Features, "+sve2-sm4"));
   EXPECT_TRUE(llvm::is_contained(Features, "+sve2-sha3"));
   EXPECT_TRUE(llvm::is_contained(Features, "+sve2-bitperm"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+rcpc"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+rand"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+mte"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+ssbs"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+sb"));
+  EXPECT_TRUE(llvm::is_contained(Features, "+predres"));
+  

[PATCH] D123297: [flang][driver] Add support for -mmlir

2022-04-07 Thread Andrzej Warzynski via Phabricator via cfe-commits
awarzynski created this revision.
awarzynski added a reviewer: rovka.
Herald added subscribers: sdasgup3, wenzhicui, wrengr, Chia-hungDuan, dcaballe, 
cota, teijeong, rdzhabarov, tatianashp, msifontes, jurahul, Kayjukh, grosul1, 
Joonsoo, liufengdb, aartbik, mgester, arpith-jacob, antiagainst, shauheen, 
rriddle, mehdi_amini, mgorny.
Herald added a reviewer: sscalpone.
Herald added projects: Flang, All.
awarzynski requested review of this revision.
Herald added subscribers: cfe-commits, stephenneuendorffer, nicolasvasilache, 
jdoerfert, MaskRay.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D123297

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Flang.cpp
  flang/include/flang/Frontend/FrontendOptions.h
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/FrontendTool/CMakeLists.txt
  flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
  flang/test/Driver/driver-help-hidden.f90
  flang/test/Driver/driver-help.f90
  flang/test/Driver/mllvm_vs_mmlir.f90

Index: flang/test/Driver/mllvm_vs_mmlir.f90
===
--- /dev/null
+++ flang/test/Driver/mllvm_vs_mmlir.f90
@@ -0,0 +1,18 @@
+! Verify that `-mllvm` options are forwarded to LLVM and `-mmlir` to MLIR
+
+!
+! RUN COMMAND
+!
+! RUN: %flang_fc1  -mmlir --help | FileCheck %s --check-prefix=MLIR
+! RUN: %flang_fc1  -mllvm --help | FileCheck %s --check-prefix=MLLVM
+
+!
+! EXPECTED OUTPUT
+!
+! MLIR: flang (MLIR option parsing) [options]
+! MLIR: --mlir-{{.*}}
+! MLIR-NOT: --print-ir-after-all
+
+! MLLVM: flang (LLVM option parsing) [options]
+! MLLVM: --print-ir-after-all
+! MLLVM-NOT: --mlir-{{.*}}
Index: flang/test/Driver/driver-help.f90
===
--- flang/test/Driver/driver-help.f90
+++ flang/test/Driver/driver-help.f90
@@ -48,6 +48,7 @@
 ! HELP-NEXT: -help  Display available options
 ! HELP-NEXT: -IAdd directory to the end of the list of include search paths
 ! HELP-NEXT: -mllvm  Additional arguments to forward to LLVM's option processing
+! HELP-NEXT: -mmlir  Additional arguments to forward to MLIR's option processing
 ! HELP-NEXT: -module-dir   Put MODULE files in 
 ! HELP-NEXT: -nocpp Disable predefined and command line preprocessor macros
 ! HELP-NEXT: -o   Write output to 
@@ -123,6 +124,7 @@
 ! HELP-FC1-NEXT: -IAdd directory to the end of the list of include search paths
 ! HELP-FC1-NEXT: -load Load the named plugin (dynamic shared object)
 ! HELP-FC1-NEXT: -mllvm  Additional arguments to forward to LLVM's option processing
+! HELP-FC1-NEXT: -mmlir  Additional arguments to forward to MLIR's option processing
 ! HELP-FC1-NEXT: -module-dir   Put MODULE files in 
 ! HELP-FC1-NEXT: -module-suffix  Use  as the suffix for module files (the default value is `.mod`)
 ! HELP-FC1-NEXT: -nocpp Disable predefined and command line preprocessor macros
Index: flang/test/Driver/driver-help-hidden.f90
===
--- flang/test/Driver/driver-help-hidden.f90
+++ flang/test/Driver/driver-help-hidden.f90
@@ -48,6 +48,7 @@
 ! CHECK-NEXT: -help Display available options
 ! CHECK-NEXT: -IAdd directory to the end of the list of include search paths
 ! CHECK-NEXT: -mllvm  Additional arguments to forward to LLVM's option processing
+! CHECK-NEXT: -mmlir  Additional arguments to forward to MLIR's option processing
 ! CHECK-NEXT: -module-dir   Put MODULE files in 
 ! CHECK-NEXT: -nocpp Disable predefined and command line preprocessor macros
 ! CHECK-NEXT: -o  Write output to 
Index: flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
===
--- flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
+++ flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
@@ -11,6 +11,8 @@
 //
 //===--===//
 
+#include "mlir/IR/MLIRContext.h"
+#include "mlir/Pass/PassManager.h"
 #include "flang/Frontend/CompilerInstance.h"
 #include "flang/Frontend/FrontendActions.h"
 #include "flang/Frontend/FrontendPluginRegistry.h"
@@ -148,6 +150,21 @@
 llvm::cl::ParseCommandLineOptions(numArgs + 1, args.get());
   }
 
+  // Honor -mmlir. This should happen AFTER plugins have been loaded!
+  if (!flang->frontendOpts().mlirArgs.empty()) {
+mlir::registerMLIRContextCLOptions();
+mlir::registerPassManagerCLOptions();
+unsigned numArgs = flang->frontendOpts().mlirArgs.size();
+auto args = std::make_unique(numArgs + 2);
+args[0] = "flang (MLIR option parsing)";
+
+for (unsigned i = 0; i != numArgs; ++i)
+  args[i + 1] = flang->frontendOpts().mlirArgs[i].c_str(

[PATCH] D123296: [llvm][AArch64] Generate getExtensionFeatures from the list of extensions

2022-04-07 Thread David Spickett via Phabricator via cfe-commits
DavidSpickett added reviewers: amilendra, tmatheson.
DavidSpickett added a comment.

The background here is that I want to automate what I did in 
https://reviews.llvm.org/D121999 and thought I could do that by passing 0xf...f 
to getExtensionFeatures.

I thought there might be some reason to not list them all but considering that 
things like mte were missing I don't think there is. More likely that any time 
we were adding something like +mte we went through a different function in the 
target parser.




Comment at: clang/test/Preprocessor/aarch64-target-features.c:288
+// CHECK-MCPU-CORTEX-A73: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" 
"-target-feature" "+v8a" "-target-feature" "+crc" "-target-feature" "+crypto" 
"-target-feature" "+fp-armv8" "-target-feature" "+neon"
+// CHECK-MCPU-CORTEX-R82: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" 
"-target-feature" "+v8r" "-target-feature" "+crc" "-target-feature" "+lse" 
"-target-feature" "+rdm" "-target-feature" "+dotprod" "-target-feature" 
"+fp-armv8" "-target-feature" "+neon" "-target-feature" "+fp16fml" 
"-target-feature" "+ras" "-target-feature" "+rcpc" "-target-feature" "+ssbs" 
"-target-feature" "+sb" "-target-feature" "+fullfp16"
+// CHECK-MCPU-M3: "-cc1"{{.*}} "-triple" "aarch64{{.*}}" "-target-feature" 
"+v8a" "-target-feature" "+crc" "-target-feature" "+crypto" "-target-feature" 
"+fp-armv8" "-target-feature" "+neon"

Some of the ordering has changed and that means some tests look for new 
features. The CPU already had these features, the test just didn't check for 
them before and now they've been inserted into what it's looking for.

We could change all these to look for the exact feature set but to be 
conservative I stuck to re-ordering them and adding just enough to get them 
passing again.



Comment at: llvm/lib/Support/AArch64TargetParser.cpp:69
+  if (Extensions & ID) {   
\
+const char *feature = FEATURE; 
\
+/* INVALID and NONE have no feature name. */   
\

This looks a bit strange but you can't do:
```
Features.push_back(FEATURE);
```
Because you get:
```
Features.push_back(nullptr);
```
Which calls a deleted constructor, and we don't want empty feature strings in 
any case.

So that's why I assign it to something so that the `push_back` line can still 
be compiled.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123296

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


[PATCH] D119544: Deferred Concept Instantiation Implementation

2022-04-07 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu added a comment.

I've read the whole patch. It looks good to me roughly except some style issues 
and the 2 places you marked as ` Attn Reviewers`. Let's try to fix them one by 
one.




Comment at: clang/lib/Sema/SemaTemplate.cpp:4705
   CheckConstraintSatisfaction(
-  NamedConcept, {NamedConcept->getConstraintExpr()}, Converted,
+  NamedConcept, {NamedConcept->getConstraintExpr()}, MLTAL,
   SourceRange(SS.isSet() ? SS.getBeginLoc() : ConceptNameInfo.getLoc(),

I would feel better if we could write:
```
CheckConstraintSatisfaction(
  NamedConcept, {NamedConcept->getConstraintExpr()}, {MLTAL},
  SourceRange(SS.isSet() ? SS.getBeginLoc() : ConceptNameInfo.getLoc(),
  TemplateArgs->getRAngleLoc()),
  Satisfaction)
```

But it looks unimplementable.



Comment at: clang/lib/Sema/SemaTemplate.cpp:5564
   return true;
 
 TemplateArgumentList TemplateArgs(TemplateArgumentList::OnStack, 
Converted);





Comment at: clang/lib/Sema/SemaTemplate.cpp:7468-7483
+  // Attn Reviewers: This works and fixes the constraint comparison issues,
+  // but I don't have a good idea why this is, nor if it is the 'right'
+  // thing.  I THINK it is pulling off the 'template template' level of the
+  // constraint, but I have no idea if that is the correct thing to do.
+  SmallVector ConvertedParamsAC;
+  TemplateArgumentList Empty(TemplateArgumentList::OnStack, {});
+  MultiLevelTemplateArgumentList MLTAL{Empty};

I've spent some time to playing it myself to figure it out. And I found that we 
could fix this cleaner we adopt above suggestions. The problem here is that the 
instantiation is started half way. But the conversion for the constraint have 
been deferred. So here is the problem. I guess there are other similar 
problems. But let's fix them after we met them actually.




Comment at: clang/lib/Sema/SemaTemplateInstantiate.cpp:60-61
 const NamedDecl *D, const TemplateArgumentList *Innermost,
-bool RelativeToPrimary, const FunctionDecl *Pattern) {
+bool RelativeToPrimary, const FunctionDecl *Pattern, bool LookBeyondLambda,
+bool IncludeContainingStructArgs) {
   // Accumulate the set of template argument lists in this structure.

erichkeane wrote:
> ChuanqiXu wrote:
> > Would you elaborate more for `LookBeyondLambda` and 
> > `IncludeContainingStructArgs`? It confuses me since I couldn't find 
> > `Lambda` or `Struct` from the context of use point.
> Sure!  
> 
> So this function is typically used for 'getting the template instantiation 
> args' of the current Declaration (D) for a variety of reasons.  In all of 
> those cases previously, it would 'stop' looking when it hit a lambda generic 
> call operator (see line 157).  This would block our ability to get the full 
> instantiation tree.
> 
> Similarly, it would stop at a containing class-template (as most 
> instantiations are done against the parent class template).  Unfortunately 
> this is sufficient, so the IncludeContainingStructArgs (see line 185) ALSO 
> includes those arguments, as they are necessary  (since they haven't been 
> instantiated in the constraint yet).
I got it. It might be necessary to edit the comment too.


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

https://reviews.llvm.org/D119544

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


[PATCH] D122808: [clang] Fix warnings when `-Wdeprecated-enum-enum-conversion` is enabled

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

LGTM, thank you for the new interface and fixes! (Current Precommit CI failures 
look unrelated to me.)


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

https://reviews.llvm.org/D122808

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


[clang] b16a3b4 - [Clang] Add -no-opaque-pointers to more tests (NFC)

2022-04-07 Thread Nikita Popov via cfe-commits

Author: Nikita Popov
Date: 2022-04-07T12:53:29+02:00
New Revision: b16a3b4f3bbd6f9f1f8d3a1525804dd5754c0adf

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

LOG: [Clang] Add -no-opaque-pointers to more tests (NFC)

This adds the flag to more tests that were not caught by the
mass-migration in 532dc62b907554b3f07f17205674aa71e76fc863.

Added: 


Modified: 
clang/test/CodeGen/PowerPC/ppc-emmintrin.c
clang/test/CodeGen/PowerPC/ppc-mmintrin.c
clang/test/CodeGen/PowerPC/ppc-pmmintrin.c
clang/test/CodeGen/PowerPC/ppc-smmintrin.c
clang/test/CodeGen/PowerPC/ppc-tmmintrin.c
clang/test/CodeGen/PowerPC/ppc-x86gprintrin.c
clang/test/CodeGen/PowerPC/ppc-xmmintrin.c
clang/test/CodeGen/PowerPC/vector-compat-pixel-bool-ternary.c
clang/test/CodeGen/PowerPC/vector-compat-pixel-bool.c
clang/test/CodeGen/PowerPC/vector-compat-ternary.c
clang/test/CodeGen/PowerPC/vector-compat.c
clang/test/CodeGen/extern-inline.c
clang/test/CodeGen/ffp-contract-option.c
clang/test/CodeGen/ffp-model.c
clang/test/CodeGen/lifetime-sanitizer.c
clang/test/CodeGen/sancov-new-pm.c
clang/test/CodeGenCUDA/amdgpu-alias-undef-symbols.cu
clang/test/CodeGenCUDASPIRV/kernel-argument.cu
clang/test/CodeGenCXX/cxx-apple-kext.cpp
clang/test/CodeGenCXX/debug-info-nrvo.cpp
clang/test/CodeGenCXX/debug-info-template.cpp
clang/test/CodeGenCXX/float16-declarations.cpp
clang/test/CodeGenCXX/lifetime-sanitizer.cpp
clang/test/CodeGenCXX/virtual-function-elimination.cpp
clang/test/CodeGenObjC/objc_copyStruct.m
clang/test/CodeGenOpenCL/amdgpu-debug-info-variable-expression.cl
clang/test/Frontend/fixed_point_same_fbits.c
clang/test/Headers/wasm.c
clang/test/utils/update_cc_test_checks/Inputs/basic-cplusplus.cpp
clang/test/utils/update_cc_test_checks/Inputs/basic-cplusplus.cpp.expected
clang/test/utils/update_cc_test_checks/Inputs/check-attributes.cpp

clang/test/utils/update_cc_test_checks/Inputs/check-attributes.cpp.funcattrs.expected

clang/test/utils/update_cc_test_checks/Inputs/check-attributes.cpp.plain.expected
clang/test/utils/update_cc_test_checks/Inputs/def-and-decl.c
clang/test/utils/update_cc_test_checks/Inputs/def-and-decl.c.expected
clang/test/utils/update_cc_test_checks/Inputs/exec-all-runlines.c
clang/test/utils/update_cc_test_checks/Inputs/exec-all-runlines.c.expected

clang/test/utils/update_cc_test_checks/Inputs/explicit-template-instantiation.cpp

clang/test/utils/update_cc_test_checks/Inputs/explicit-template-instantiation.cpp.expected
clang/test/utils/update_cc_test_checks/Inputs/generated-funcs-regex.c

clang/test/utils/update_cc_test_checks/Inputs/generated-funcs-regex.c.expected
clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c

clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c.generated.expected

clang/test/utils/update_cc_test_checks/Inputs/generated-funcs.c.no-generated.expected
clang/test/utils/update_cc_test_checks/Inputs/mangled_names.c
clang/test/utils/update_cc_test_checks/Inputs/mangled_names.c.expected

clang/test/utils/update_cc_test_checks/Inputs/mangled_names.c.funcsig.expected
clang/test/utils/update_cc_test_checks/Inputs/resolve-tmp-conflict.cpp

clang/test/utils/update_cc_test_checks/Inputs/resolve-tmp-conflict.cpp.expected

Removed: 




diff  --git a/clang/test/CodeGen/PowerPC/ppc-emmintrin.c 
b/clang/test/CodeGen/PowerPC/ppc-emmintrin.c
index 1163ba3ad5753..00da13fcf69ce 100644
--- a/clang/test/CodeGen/PowerPC/ppc-emmintrin.c
+++ b/clang/test/CodeGen/PowerPC/ppc-emmintrin.c
@@ -1,11 +1,11 @@
 // REQUIRES: powerpc-registered-target
 
-// RUN: %clang -S -emit-llvm -target powerpc64-unknown-linux-gnu -mcpu=pwr8 
-ffreestanding -DNO_WARN_X86_INTRINSICS %s \
+// RUN: %clang -Xclang -no-opaque-pointers -S -emit-llvm -target 
powerpc64-unknown-linux-gnu -mcpu=pwr8 -ffreestanding -DNO_WARN_X86_INTRINSICS 
%s \
 // RUN:  -ffp-contract=off -fno-discard-value-names -mllvm 
-disable-llvm-optzns -o - | llvm-cxxfilt -n | FileCheck %s 
--check-prefixes=CHECK,CHECK-BE
-// RUN: %clang -S -emit-llvm -target powerpc64le-unknown-linux-gnu -mcpu=pwr8 
-ffreestanding -DNO_WARN_X86_INTRINSICS %s \
+// RUN: %clang -Xclang -no-opaque-pointers -S -emit-llvm -target 
powerpc64le-unknown-linux-gnu -mcpu=pwr8 -ffreestanding 
-DNO_WARN_X86_INTRINSICS %s \
 // RUN:   -ffp-contract=off -fno-discard-value-names -mllvm 
-disable-llvm-optzns -o - | llvm-cxxfilt -n | FileCheck %s 
--check-prefixes=CHECK,CHECK-LE
 
-// RUN: %clang -S -emit-llvm -target powerpc64le-unknown-linux-gnu -mcpu=pwr10 
-ffreestanding -DNO_WARN_X86_INTRINSICS %s \
+// RUN: %clang -Xclang -no-opaque-pointers -S -emit-llvm -target 
powerpc64le-unkno

[clang-tools-extra] be572e1 - [clangd] NFC: Fix doc typos

2022-04-07 Thread Kirill Bobyrev via cfe-commits

Author: Kirill Bobyrev
Date: 2022-04-07T12:56:56+02:00
New Revision: be572e1e1d297039129b0c4ff2deffd817e42f30

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

LOG: [clangd] NFC: Fix doc typos

Added: 


Modified: 
clang-tools-extra/clangd/Config.h
clang-tools-extra/clangd/ConfigFragment.h

Removed: 




diff  --git a/clang-tools-extra/clangd/Config.h 
b/clang-tools-extra/clangd/Config.h
index f84b5ef1ffb58..c693aee56ce57 100644
--- a/clang-tools-extra/clangd/Config.h
+++ b/clang-tools-extra/clangd/Config.h
@@ -17,7 +17,7 @@
 //
 // Because this structure is shared throughout clangd, it's a potential source
 // of layering problems. Config should be expressed in terms of simple
-// vocubulary types where possible.
+// vocabulary types where possible.
 //
 
//===--===//
 

diff  --git a/clang-tools-extra/clangd/ConfigFragment.h 
b/clang-tools-extra/clangd/ConfigFragment.h
index cbaf6deb69de5..3c574bace2221 100644
--- a/clang-tools-extra/clangd/ConfigFragment.h
+++ b/clang-tools-extra/clangd/ConfigFragment.h
@@ -235,14 +235,14 @@ struct Fragment {
 /// Controls how clang-tidy will run over the code base.
 ///
 /// The settings are merged with any settings found in .clang-tidy
-/// configiration files with these ones taking precedence.
+/// configuration files with these ones taking precedence.
 struct ClangTidyBlock {
   std::vector> Add;
   /// List of checks to disable.
   /// Takes precedence over Add. To enable all llvm checks except include
   /// order:
   ///   Add: llvm-*
-  ///   Remove: llvm-include-onder
+  ///   Remove: llvm-include-order
   std::vector> Remove;
 
   /// A Key-Value pair list of options to pass to clang-tidy checks



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


[PATCH] D123298: [NFC] [AST] Reduce the size of TemplateParmPosition

2022-04-07 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu created this revision.
ChuanqiXu added reviewers: erichkeane, aaron.ballman, cor3ntin.
ChuanqiXu added a project: clang.
Herald added a subscriber: kristof.beyls.
Herald added a project: All.
ChuanqiXu requested review of this revision.
Herald added a subscriber: cfe-commits.

I found this when reading the codes. I think it makes sense to reduce the space 
for TemplateParmPosition. It is hard to image the depth of template parameter 
is larger than 2^20 and the index is larger than 2^12. So I think the patch 
might be reasonable.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D123298

Files:
  clang/include/clang/AST/DeclTemplate.h


Index: clang/include/clang/AST/DeclTemplate.h
===
--- clang/include/clang/AST/DeclTemplate.h
+++ clang/include/clang/AST/DeclTemplate.h
@@ -1148,10 +1148,8 @@
 /// parameters and is not part of the Decl hierarchy. Just a facility.
 class TemplateParmPosition {
 protected:
-  // FIXME: These probably don't need to be ints. int:5 for depth, int:8 for
-  // position? Maybe?
-  unsigned Depth;
-  unsigned Position;
+  unsigned Depth : 20;
+  unsigned Position : 12;
 
   TemplateParmPosition(unsigned D, unsigned P) : Depth(D), Position(P) {}
 


Index: clang/include/clang/AST/DeclTemplate.h
===
--- clang/include/clang/AST/DeclTemplate.h
+++ clang/include/clang/AST/DeclTemplate.h
@@ -1148,10 +1148,8 @@
 /// parameters and is not part of the Decl hierarchy. Just a facility.
 class TemplateParmPosition {
 protected:
-  // FIXME: These probably don't need to be ints. int:5 for depth, int:8 for
-  // position? Maybe?
-  unsigned Depth;
-  unsigned Position;
+  unsigned Depth : 20;
+  unsigned Position : 12;
 
   TemplateParmPosition(unsigned D, unsigned P) : Depth(D), Position(P) {}
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D116203: [clang] adds unary type transformations as compiler built-ins

2022-04-07 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D116203#3434761 , @rjmccall wrote:

> In D116203#3434515 , @cjdb wrote:
>
>> In D116203#3431612 , @rjmccall 
>> wrote:
>>
>>> In D116203#3430332 , 
>>> @aaron.ballman wrote:
>>>
 In D116203#3425512 , @cjdb wrote:

> I've noticed that libstdc++ has `using __remove_cv = typename 
> remove_cv::type`, which causes Clang to chuck a wobbly. Changing from 
> `KEYWORD` to `TYPE_TRAIT_1` didn't seem to fix anything.
> Is there a way we can work around this, or should we just rename 
> `__remove_cv` and friends to something else?

 You could work around it by taking note that you're in a libstdc++ system 
 header and do a special dance, but because these are in the 
 implementation's namespace, I think it's probably kinder for everyone to 
 just pick a different name.
>>
>> I was hoping we could do something similar to `struct __remove_cv` which 
>> would issue a warning?
>>
 If you wanted to be especially mean, you could go with `__remove_cvr`, but 
 I'd suggest `__remove_cv_qualifiers` instead. However, what about 
 `restrict` qualifiers? We support them in C++: 
 https://godbolt.org/z/11EPefhjf
>>>
>>> Along with a fair number of other vendor qualifiers, yeah.  I think you 
>>> have to make a policy decision about whether the intent of `std::remove_cv` 
>>> is really to just remove CV qualifiers or to produce an unqualified type 
>>> (at the outermost level).  The former is probably more defensible, even if 
>>> it makes the transform less useful in the presence of extended qualifiers.
>>
>> I'm partial to `std::remove_cv` being faithful to its name, unless existing 
>> implementations do something else already. I don't mind adding support for 
>> the other stuff, but if there's more than just add/remove `restrict`, we're 
>> going to have a combinatorial explosion for removes. Is there an alternate 
>> way we can approach this?
>> Possibly:
>>
>>   template
>>   using remove_const_t = __remove_qualifiers(T, const);
>>   
>>   
>>   template
>>   using remove_reference_t = __remove_qualifiers(T, &, &&);
>>   
>>   template
>>   using remove_rcvref_t = __remove_qualifiers(T, const, volatile, restrict, 
>> &, &&); // rcv instead of cvr to prevent a typo with remove_cvref_t
>
> I don't think it's worth adding that parsing complexity for a builtin that we 
> expect to only be used in system headers.  Let's just remove `const` and 
> `volatile` and leave other qualifiers in place.

I come down on the opposite side of the fence and think it should remove all 
qualifiers (or that should be an interface we support in addition to removing 
just cv qualifiers). WG14 adopted 
https://www9.open-std.org/jtc1/sc22/wg14/www/docs/n2927.htm into C23 with a 
`remove_quals` function which removes *all* qualifiers (including `_Atomic`), 
as an example. But even in C++ mode, I fail to see why we wouldn't want  
interface for stripping `__restrict` the same as `const` or `volatile` along 
with some interface for stripping all qualifiers period (I don't see a huge 
need for a `__remove_cvr` if we have the ability to remove all qualifiers, so I 
don't think we need the combinatorial explosion or a complex interface). 
Basically -- if we have extensions like `__restrict` or _Atomic, we should 
fully support them rather than halfway do it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116203

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


[PATCH] D123299: [clang-format][docs] Fix incorrect 'clang-format 9' option marker

2022-04-07 Thread Krystian Kuzniarek via Phabricator via cfe-commits
kuzkry created this revision.
kuzkry added reviewers: MyDeveloperDay, HazardyKnusperkeks.
kuzkry added a project: clang-format.
Herald added a project: All.
kuzkry requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Introduced by 23a5090c6 
, this 
style option marker indicated
'clang-format 9', though its respective option was available in
an earlier release.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D123299

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/include/clang/Format/Format.h


Index: clang/include/clang/Format/Format.h
===
--- clang/include/clang/Format/Format.h
+++ clang/include/clang/Format/Format.h
@@ -600,7 +600,7 @@
   };
 
   /// Dependent on the value, ``if (a) return;`` can be put on a single line.
-  /// \version 9
+  /// \version 3.3
   ShortIfStyle AllowShortIfStatementsOnASingleLine;
 
   /// Different styles for merging short lambdas containing at most one
Index: clang/docs/ClangFormatStyleOptions.rst
===
--- clang/docs/ClangFormatStyleOptions.rst
+++ clang/docs/ClangFormatStyleOptions.rst
@@ -1019,7 +1019,7 @@
 
 
 
-**AllowShortIfStatementsOnASingleLine** (``ShortIfStyle``) 
:versionbadge:`clang-format 9`
+**AllowShortIfStatementsOnASingleLine** (``ShortIfStyle``) 
:versionbadge:`clang-format 3.3`
   Dependent on the value, ``if (a) return;`` can be put on a single line.
 
   Possible values:


Index: clang/include/clang/Format/Format.h
===
--- clang/include/clang/Format/Format.h
+++ clang/include/clang/Format/Format.h
@@ -600,7 +600,7 @@
   };
 
   /// Dependent on the value, ``if (a) return;`` can be put on a single line.
-  /// \version 9
+  /// \version 3.3
   ShortIfStyle AllowShortIfStatementsOnASingleLine;
 
   /// Different styles for merging short lambdas containing at most one
Index: clang/docs/ClangFormatStyleOptions.rst
===
--- clang/docs/ClangFormatStyleOptions.rst
+++ clang/docs/ClangFormatStyleOptions.rst
@@ -1019,7 +1019,7 @@
 
 
 
-**AllowShortIfStatementsOnASingleLine** (``ShortIfStyle``) :versionbadge:`clang-format 9`
+**AllowShortIfStatementsOnASingleLine** (``ShortIfStyle``) :versionbadge:`clang-format 3.3`
   Dependent on the value, ``if (a) return;`` can be put on a single line.
 
   Possible values:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D123299: [clang-format][docs] Fix incorrect 'clang-format 9' option marker

2022-04-07 Thread Krystian Kuzniarek via Phabricator via cfe-commits
kuzkry added a comment.

Hi, I've got yet another one. Luckily, nothing wrong with clang-format 10, all 
were fine. This one was the only option incorrectly marked as clang-format 9.

Note, AllowShortIfStatementsOnASingleLine was introduced by 
1b750edda14879a16ce782b3ade3af599bfbb717


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123299

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


[PATCH] D123298: [NFC] [AST] Reduce the size of TemplateParmPosition

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

Changes LGTM, I also don't think we should hit these limits. Perhaps we should 
add some assertions to the ctor and the setter functions just to be sure though?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123298

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


[PATCH] D111548: [Clang] Add the `annotate_type` attribute

2022-04-07 Thread Martin Böhme via Phabricator via cfe-commits
mboehme updated this revision to Diff 421159.
mboehme added a comment.

Add documentation and a unit test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111548

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Sema/SemaAttr.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CodeGenCXX/annotate-type.cpp
  clang/test/Sema/annotate-type.c
  clang/test/SemaCXX/annotate-type.cpp
  clang/unittests/AST/AttrTest.cpp

Index: clang/unittests/AST/AttrTest.cpp
===
--- clang/unittests/AST/AttrTest.cpp
+++ clang/unittests/AST/AttrTest.cpp
@@ -7,7 +7,10 @@
 //===--===//
 
 #include "clang/AST/Attr.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
 #include "clang/Basic/AttrKinds.h"
+#include "clang/Tooling/Tooling.h"
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
 
@@ -15,10 +18,81 @@
 
 namespace {
 
+using clang::ast_matchers::constantExpr;
+using clang::ast_matchers::equals;
+using clang::ast_matchers::functionDecl;
+using clang::ast_matchers::has;
+using clang::ast_matchers::hasDescendant;
+using clang::ast_matchers::hasName;
+using clang::ast_matchers::integerLiteral;
+using clang::ast_matchers::match;
+using clang::ast_matchers::selectFirst;
+using clang::ast_matchers::stringLiteral;
+using clang::tooling::buildASTFromCode;
+
 TEST(Attr, Doc) {
   EXPECT_THAT(Attr::getDocumentation(attr::Used).str(),
   testing::HasSubstr("The compiler must emit the definition even "
  "if it appears to be unused"));
 }
 
+const FunctionDecl *getFunctionNode(clang::ASTUnit *AST,
+const std::string &Name) {
+  auto Result =
+  match(functionDecl(hasName(Name)).bind("fn"), AST->getASTContext());
+  EXPECT_EQ(Result.size(), 1u);
+  return Result[0].getNodeAs("fn");
+}
+
+TEST(Attr, AnnotateType) {
+
+  // Test that the AnnotateType attribute shows up in the right places and that
+  // it stores its arguments correctly.
+
+  auto AST = buildASTFromCode(R"cpp(
+void f(int* [[clang::annotate_type("foo", "arg1", 2)]] *,
+   int [[clang::annotate_type("bar")]]);
+)cpp");
+
+  const FunctionDecl *Func = getFunctionNode(AST.get(), "f");
+
+  {
+TypeLoc Parm0TL = Func->getParamDecl(0)->getTypeSourceInfo()->getTypeLoc();
+const auto PointerTL = Parm0TL.getAs();
+ASSERT_FALSE(PointerTL.isNull());
+const auto AttributedTL =
+PointerTL.getPointeeLoc().getAs();
+ASSERT_FALSE(AttributedTL.isNull());
+ASSERT_NE(AttributedTL.getAttr(), nullptr);
+ASSERT_TRUE(AttributedTL.getModifiedLoc().getAs());
+
+const auto *Annotate = dyn_cast(AttributedTL.getAttr());
+ASSERT_NE(Annotate, nullptr);
+EXPECT_EQ(Annotate->getAnnotation(), "foo");
+
+EXPECT_EQ(Annotate->args_size(), 2);
+const auto *StringLit = selectFirst(
+"str", match(constantExpr(hasDescendant(stringLiteral().bind("str"))),
+ *Annotate->args_begin()[0], Func->getASTContext()));
+ASSERT_NE(StringLit, nullptr);
+EXPECT_EQ(StringLit->getString(), "arg1");
+EXPECT_EQ(match(constantExpr(has(integerLiteral(equals(2)).bind("int"))),
+*Annotate->args_begin()[1], Func->getASTContext())
+  .size(),
+  1);
+  }
+
+  {
+TypeLoc Parm1TL = Func->getParamDecl(1)->getTypeSourceInfo()->getTypeLoc();
+const auto AttributedTL = Parm1TL.getAs();
+ASSERT_FALSE(AttributedTL.isNull());
+ASSERT_TRUE(AttributedTL.getModifiedLoc().getType() ==
+Func->getASTContext().IntTy);
+
+const auto *Annotate = dyn_cast(AttributedTL.getAttr());
+ASSERT_NE(Annotate, nullptr);
+EXPECT_EQ(Annotate->getAnnotation(), "bar");
+  }
+}
+
 } // namespace
Index: clang/test/SemaCXX/annotate-type.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/annotate-type.cpp
@@ -0,0 +1,30 @@
+// RUN: %clang_cc1 %s -std=c++17 -fsyntax-only -verify
+
+struct S1 {
+  void f() [[clang::annotate_type("foo")]];
+};
+
+template  struct is_same {
+  static constexpr bool value = false;
+};
+
+template  struct is_same {
+  static constexpr bool value = true;
+};
+
+static_assert(is_same::value);
+static_assert(is_same::value);
+static_assert(is_same::value);
+
+// Cannot overload on types that only differ by `annotate_type` attribute.
+void f(int) {} // expected-note {{previous definition is here}}
+void f(int [[clang::annotate_type("foo")]]) {} // expected-error {{redefinition of 'f'}}
+
+// Cannot specialize on types that only differ by `annotate_type` attribute.
+template  struct S2 {};
+
+template 

[PATCH] D120989: Support debug info for alias variable

2022-04-07 Thread Kavitha Natarajan via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGb1ea0191a420: [clang][DebugInfo] Support debug info for 
alias variable (authored by kavitha-natarajan).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120989

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CGDebugInfo.h
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenModule.h
  clang/test/CodeGen/debug-info-alias.c

Index: clang/test/CodeGen/debug-info-alias.c
===
--- /dev/null
+++ clang/test/CodeGen/debug-info-alias.c
@@ -0,0 +1,15 @@
+// RUN: %clang_cc1 -emit-llvm -debug-info-kind=limited %s -o - | FileCheck %s
+
+// CHECK-DAG: [[ENTITY1:![0-9]+]] = distinct !DIGlobalVariable(name: "aliased_global"
+// CHECK-DAG: [[ENTITY2:![0-9]+]] = distinct !DIGlobalVariable(name: "aliased_global_2"
+// CHECK-DAG: !DIImportedEntity(tag: DW_TAG_imported_declaration, name: "__global_alias", scope: !2, entity: [[ENTITY1]]
+// CHECK-DAG: [[ENTITY3:![0-9]+]] = !DIImportedEntity(tag: DW_TAG_imported_declaration, name: "global_alias_2", scope: !2, entity: [[ENTITY2]]
+// CHECK-DAG: !DIImportedEntity(tag: DW_TAG_imported_declaration, name: "__global_alias_2_alias", scope: !2, entity: [[ENTITY3]]
+
+int aliased_global = 1;
+extern int __attribute__((alias("aliased_global"))) __global_alias;
+
+// Recursive alias:
+int aliased_global_2 = 2;
+extern int __attribute__((alias("aliased_global_2"))) global_alias_2;
+extern int __attribute__((alias("global_alias_2"))) __global_alias_2_alias;
Index: clang/lib/CodeGen/CodeGenModule.h
===
--- clang/lib/CodeGen/CodeGenModule.h
+++ clang/lib/CodeGen/CodeGenModule.h
@@ -1222,6 +1222,7 @@
 
   StringRef getMangledName(GlobalDecl GD);
   StringRef getBlockMangledName(GlobalDecl GD, const BlockDecl *BD);
+  const GlobalDecl getMangledNameDecl(StringRef);
 
   void EmitTentativeDefinition(const VarDecl *D);
 
Index: clang/lib/CodeGen/CodeGenModule.cpp
===
--- clang/lib/CodeGen/CodeGenModule.cpp
+++ clang/lib/CodeGen/CodeGenModule.cpp
@@ -1502,6 +1502,16 @@
   return Result.first->first();
 }
 
+const GlobalDecl CodeGenModule::getMangledNameDecl(StringRef Name) {
+  auto it = MangledDeclNames.begin();
+  while (it != MangledDeclNames.end()) {
+if (it->second == Name)
+  return it->first;
+it++;
+  }
+  return GlobalDecl();
+}
+
 llvm::GlobalValue *CodeGenModule::GetGlobalValue(StringRef Name) {
   return getModule().getNamedValue(Name);
 }
@@ -5171,6 +5181,13 @@
   setTLSMode(GA, *VD);
 
   SetCommonAttributes(GD, GA);
+
+  // Emit global alias debug information.
+  if (const auto *VD = dyn_cast(D)) {
+if (CGDebugInfo *DI = getModuleDebugInfo()) {
+  DI->EmitGlobalAlias(cast(GA->getAliasee()), GD);
+}
+  }
 }
 
 void CodeGenModule::emitIFuncDefinition(GlobalDecl GD) {
Index: clang/lib/CodeGen/CGDebugInfo.h
===
--- clang/lib/CodeGen/CGDebugInfo.h
+++ clang/lib/CodeGen/CGDebugInfo.h
@@ -152,8 +152,10 @@
   llvm::DenseMap DIFileCache;
   llvm::DenseMap SPCache;
   /// Cache declarations relevant to DW_TAG_imported_declarations (C++
-  /// using declarations) that aren't covered by other more specific caches.
+  /// using declarations and global alias variables) that aren't covered
+  /// by other more specific caches.
   llvm::DenseMap DeclCache;
+  llvm::DenseMap ImportedDeclCache;
   llvm::DenseMap NamespaceCache;
   llvm::DenseMap
   NamespaceAliasCache;
@@ -507,6 +509,9 @@
   /// Emit information about an external variable.
   void EmitExternalVariable(llvm::GlobalVariable *GV, const VarDecl *Decl);
 
+  /// Emit information about global variable alias.
+  void EmitGlobalAlias(const llvm::GlobalValue *GV, const GlobalDecl Decl);
+
   /// Emit C++ using directive.
   void EmitUsingDirective(const UsingDirectiveDecl &UD);
 
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -3845,6 +3845,17 @@
 auto N = I->second;
 if (auto *GVE = dyn_cast_or_null(N))
   return GVE->getVariable();
+return cast(N);
+  }
+
+  // Search imported declaration cache if it is already defined
+  // as imported declaration.
+  auto IE = ImportedDeclCache.find(D->getCanonicalDecl());
+
+  if (IE != ImportedDeclCache.end()) {
+auto N = IE->second;
+if (auto *GVE = dyn_cast_or_null(N))
+  return cast(GVE);
 return dyn_cast_or_null(N);
   }
 
@@ -5392,6 +5403,47 @@
   Var->addDebugInfo(GVE);
 }
 
+void CGDebugInfo::EmitGlobalAlias(const llvm::GlobalValue *GV,
+  const GlobalDecl GD) {
+
+  assert(GV);
+
+  if (!CGM.getCodeGenOpts().hasR

[clang] b1ea019 - [clang][DebugInfo] Support debug info for alias variable

2022-04-07 Thread Kavitha Natarajan via cfe-commits

Author: Kavitha Natarajan
Date: 2022-04-07T17:15:40+05:30
New Revision: b1ea0191a42074341847d767609f66a26b6d5a41

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

LOG: [clang][DebugInfo] Support debug info for alias variable

clang to emit DWARF information for global alias variable as
DW_TAG_imported_declaration. This change also handles nested
(recursive) imported declarations.

Reviewed by: dblaikie, aprantl

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

Added: 
clang/test/CodeGen/debug-info-alias.c

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

Removed: 




diff  --git a/clang/lib/CodeGen/CGDebugInfo.cpp 
b/clang/lib/CodeGen/CGDebugInfo.cpp
index eeabae09c2cab..63b89f258a8ac 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -3845,6 +3845,17 @@ llvm::DINode 
*CGDebugInfo::getDeclarationOrDefinition(const Decl *D) {
 auto N = I->second;
 if (auto *GVE = dyn_cast_or_null(N))
   return GVE->getVariable();
+return cast(N);
+  }
+
+  // Search imported declaration cache if it is already defined
+  // as imported declaration.
+  auto IE = ImportedDeclCache.find(D->getCanonicalDecl());
+
+  if (IE != ImportedDeclCache.end()) {
+auto N = IE->second;
+if (auto *GVE = dyn_cast_or_null(N))
+  return cast(GVE);
 return dyn_cast_or_null(N);
   }
 
@@ -5392,6 +5403,47 @@ void 
CGDebugInfo::EmitExternalVariable(llvm::GlobalVariable *Var,
   Var->addDebugInfo(GVE);
 }
 
+void CGDebugInfo::EmitGlobalAlias(const llvm::GlobalValue *GV,
+  const GlobalDecl GD) {
+
+  assert(GV);
+
+  if (!CGM.getCodeGenOpts().hasReducedDebugInfo())
+return;
+
+  const auto *D = cast(GD.getDecl());
+  if (D->hasAttr())
+return;
+
+  auto AliaseeDecl = CGM.getMangledNameDecl(GV->getName());
+  llvm::DINode *DI;
+
+  if (!AliaseeDecl)
+// FIXME: Aliasee not declared yet - possibly declared later
+// For example,
+//
+//   1 extern int newname __attribute__((alias("oldname")));
+//   2 int oldname = 1;
+//
+// No debug info would be generated for 'newname' in this case.
+//
+// Fix compiler to generate "newname" as imported_declaration
+// pointing to the DIE of "oldname".
+return;
+  if (!(DI = getDeclarationOrDefinition(
+AliaseeDecl.getCanonicalDecl().getDecl(
+return;
+
+  llvm::DIScope *DContext = getDeclContextDescriptor(D);
+  auto Loc = D->getLocation();
+
+  llvm::DIImportedEntity *ImportDI = DBuilder.createImportedDeclaration(
+  DContext, DI, getOrCreateFile(Loc), getLineNumber(Loc), D->getName());
+
+  // Record this DIE in the cache for nested declaration reference.
+  ImportedDeclCache[GD.getCanonicalDecl().getDecl()].reset(ImportDI);
+}
+
 llvm::DIScope *CGDebugInfo::getCurrentContextDescriptor(const Decl *D) {
   if (!LexicalBlockStack.empty())
 return LexicalBlockStack.back();

diff  --git a/clang/lib/CodeGen/CGDebugInfo.h b/clang/lib/CodeGen/CGDebugInfo.h
index 74990adc1e246..8984f3eb1d7a0 100644
--- a/clang/lib/CodeGen/CGDebugInfo.h
+++ b/clang/lib/CodeGen/CGDebugInfo.h
@@ -152,8 +152,10 @@ class CGDebugInfo {
   llvm::DenseMap DIFileCache;
   llvm::DenseMap SPCache;
   /// Cache declarations relevant to DW_TAG_imported_declarations (C++
-  /// using declarations) that aren't covered by other more specific caches.
+  /// using declarations and global alias variables) that aren't covered
+  /// by other more specific caches.
   llvm::DenseMap DeclCache;
+  llvm::DenseMap ImportedDeclCache;
   llvm::DenseMap NamespaceCache;
   llvm::DenseMap
   NamespaceAliasCache;
@@ -507,6 +509,9 @@ class CGDebugInfo {
   /// Emit information about an external variable.
   void EmitExternalVariable(llvm::GlobalVariable *GV, const VarDecl *Decl);
 
+  /// Emit information about global variable alias.
+  void EmitGlobalAlias(const llvm::GlobalValue *GV, const GlobalDecl Decl);
+
   /// Emit C++ using directive.
   void EmitUsingDirective(const UsingDirectiveDecl &UD);
 

diff  --git a/clang/lib/CodeGen/CodeGenModule.cpp 
b/clang/lib/CodeGen/CodeGenModule.cpp
index 26957ea0768e7..ec34d91e65372 100644
--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -1502,6 +1502,16 @@ StringRef CodeGenModule::getBlockMangledName(GlobalDecl 
GD,
   return Result.first->first();
 }
 
+const GlobalDecl CodeGenModule::getMangledNameDecl(StringRef Name) {
+  auto it = MangledDeclNames.begin();
+  while (it != MangledDeclNames.end()) {
+if (it->second == Name)
+  return it->first;
+it++;
+  }
+  return GlobalDecl();
+}
+
 llvm::GlobalValue *CodeGenModule::GetGlobalValue(StringRef N

[clang] 82d0f7b - [Clang] Remove redundant -no-opaque-pointers flag in test (NFC)

2022-04-07 Thread Nikita Popov via cfe-commits

Author: Nikita Popov
Date: 2022-04-07T13:53:37+02:00
New Revision: 82d0f7bdb5b542118f54aa03fac52e7a8f776123

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

LOG: [Clang] Remove redundant -no-opaque-pointers flag in test (NFC)

This was accidentally caught in an automated replacement. This
test is testing the -opaque-pointers flag itself, so we shouldn't
add -no-opaque-pointers here (though it doesn't hurt either).

Also drop the line testing the default, as the default is now
determined by a cmake option.

Added: 


Modified: 
clang/test/CodeGen/opaque-pointers-flag.c

Removed: 




diff  --git a/clang/test/CodeGen/opaque-pointers-flag.c 
b/clang/test/CodeGen/opaque-pointers-flag.c
index 9199d9493fea4..2c6e4b02a8eaa 100644
--- a/clang/test/CodeGen/opaque-pointers-flag.c
+++ b/clang/test/CodeGen/opaque-pointers-flag.c
@@ -1,8 +1,6 @@
 // NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py
-// RUN: %clang_cc1 -no-opaque-pointers -no-opaque-pointers -triple 
x86_64-unknown-unknown -emit-llvm %s -o - | FileCheck %s -check-prefix=TYPED
-// RUN: %clang_cc1 -no-opaque-pointers -opaque-pointers -triple 
x86_64-unknown-unknown -emit-llvm %s -o - | FileCheck %s -check-prefix=OPAQUE
-// The current default is typed pointers:
 // RUN: %clang_cc1 -no-opaque-pointers -triple x86_64-unknown-unknown 
-emit-llvm %s -o - | FileCheck %s -check-prefix=TYPED
+// RUN: %clang_cc1 -opaque-pointers -triple x86_64-unknown-unknown -emit-llvm 
%s -o - | FileCheck %s -check-prefix=OPAQUE
 
 // TYPED-LABEL: @test(
 // TYPED-NEXT:  entry:



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


[PATCH] D123298: [NFC] [AST] Reduce the size of TemplateParmPosition

2022-04-07 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin added a comment.

In D123298#3435770 , @aaron.ballman 
wrote:

> Changes LGTM, I also don't think we should hit these limits. Perhaps we 
> should add some assertions to the ctor and the setter functions just to be 
> sure though?

If we are going to do anything, it ought to be a diagnostic? 
I can't imagine a scenario in which someone would hit these limits and have 
assertions enabled. But i agree with you that the limit themselves should not 
be hit. 
On the other hand, why not use 16 for both?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123298

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


[PATCH] D123297: [flang][driver] Add support for -mmlir

2022-04-07 Thread Diana Picus via Phabricator via cfe-commits
rovka added a comment.

I don't know the command line library that well, so I have this curiosity: what 
happens if LLVM and MLIR have 2 different options with the same name? Do we get 
a compile time error? Or is there a risk that someone might -mllvm -XYZ and it 
would end up in MLIR's XYZ option instead, because we're processing the MLIR 
options after the LLVM ones?




Comment at: flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:15
+#include "mlir/IR/MLIRContext.h"
+#include "mlir/Pass/PassManager.h"
 #include "flang/Frontend/CompilerInstance.h"

Nit: Should these come after the llvm/ headers? (So it's alphabetical except 
for flang, which may go first)



Comment at: flang/test/Driver/mllvm_vs_mmlir.f90:17
+! MLLVM: flang (LLVM option parsing) [options]
+! MLLVM: --print-ir-after-all
+! MLLVM-NOT: --mlir-{{.*}}

Is this the most llvm-ish option we have? I'm concerned that MLIR might also 
decide to add an option that sounds like this (and for sure 
-print-ir-before-all is mentioned in the [[ 
https://mlir.llvm.org/getting_started/Debugging/ |  MLIR docs ]]).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123297

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


[PATCH] D122808: [clang] Fix warnings when `-Wdeprecated-enum-enum-conversion` is enabled

2022-04-07 Thread Antonio Frighetto via Phabricator via cfe-commits
antoniofrighetto added a comment.

Awesome, thank you for reviewing this! PS: I do not have commit access, feel 
free to close it, if you say.


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

https://reviews.llvm.org/D122808

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


[PATCH] D123297: [flang][driver] Add support for -mmlir

2022-04-07 Thread Diana Picus via Phabricator via cfe-commits
rovka added inline comments.



Comment at: flang/test/Driver/mllvm_vs_mmlir.f90:17
+! MLLVM: flang (LLVM option parsing) [options]
+! MLLVM: --print-ir-after-all
+! MLLVM-NOT: --mlir-{{.*}}

rovka wrote:
> Is this the most llvm-ish option we have? I'm concerned that MLIR might also 
> decide to add an option that sounds like this (and for sure 
> -print-ir-before-all is mentioned in the [[ 
> https://mlir.llvm.org/getting_started/Debugging/ |  MLIR docs ]]).
> Is this the most llvm-ish option we have? I'm concerned that MLIR might also 
> decide to add an option that sounds like this (and for sure 
> -print-ir-before-all is mentioned in the [[ 
> https://mlir.llvm.org/getting_started/Debugging/ |  MLIR docs ]]).

Right, I think that might be why the premerge tests are failing...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123297

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


[PATCH] D121838: Generalize "check-all" umbrella targets, use for check-clang-tools

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

I'm not an expert in CMake, but the changes look reasonable from what I do 
know. The current bot failures all look to be unrelated to the changes in this 
patch as best I can tell. Accepting, but you should probably wait for a second 
confirmation before landing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121838

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


[PATCH] D122808: [clang] Fix warnings when `-Wdeprecated-enum-enum-conversion` is enabled

2022-04-07 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D122808#3435821 , 
@antoniofrighetto wrote:

> Awesome, thank you for reviewing this! PS: I do not have commit access, feel 
> free to close it, if you say.

Ah, thank you for letting me know you don't have commit access. I'm happy to 
land this on your behalf. What name and email address would you like me to use 
for patch attribution?


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

https://reviews.llvm.org/D122808

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


[PATCH] D123298: [NFC] [AST] Reduce the size of TemplateParmPosition

2022-04-07 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D123298#3435796 , @cor3ntin wrote:

> In D123298#3435770 , @aaron.ballman 
> wrote:
>
>> Changes LGTM, I also don't think we should hit these limits. Perhaps we 
>> should add some assertions to the ctor and the setter functions just to be 
>> sure though?
>
> If we are going to do anything, it ought to be a diagnostic?

Doing a diagnostic would mean finding all the places where we form a 
`TemplateParmPosition` and ensure we have enough source location information to 
issue the diagnostic. Given that we don't expect users to ever hit it, having 
the assertion gives a wee bit of coverage (godbolt exposes an assertions build, 
for example) but without as much implementation burden. That said, if it's easy 
enough to give diagnostics, that's a more user-friendly approach if we think 
anyone would hit that limit. (I suspect template instantiation depth would be 
hit before bumping up against these limits, though.)

> I can't imagine a scenario in which someone would hit these limits and have 
> assertions enabled. But i agree with you that the limit themselves should not 
> be hit. 
> On the other hand, why not use 16 for both?

I think people instantiate to deeper template depths than they typically have 
for template parameters, so having a deeper depth made sense to me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123298

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


[clang] 7c3d8c8 - Fix warnings when `-Wdeprecated-enum-enum-conversion` is enabled

2022-04-07 Thread Aaron Ballman via cfe-commits

Author: Antonio Frighetto
Date: 2022-04-07T08:20:54-04:00
New Revision: 7c3d8c8977cfc013254783b85b9fc6026566b35f

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

LOG: Fix warnings when `-Wdeprecated-enum-enum-conversion` is enabled

clang may throw the following warning:
include/clang/AST/DeclarationName.h:210:52: error: arithmetic between
different enumeration types ('clang::DeclarationName::StoredNameKind'
and 'clang::detail::DeclarationNameExtra::ExtraKind') is deprecated
when flags -Werror,-Wdeprecated-enum-enum-conversion are on.

This adds the `addEnumValues()` helper function to STLExtras.h to hide
the details of adding enumeration values together from two different
enumerations.

Added: 


Modified: 
clang/include/clang/AST/DeclarationName.h
llvm/include/llvm/ADT/STLExtras.h
llvm/unittests/ADT/STLExtrasTest.cpp

Removed: 




diff  --git a/clang/include/clang/AST/DeclarationName.h 
b/clang/include/clang/AST/DeclarationName.h
index 0762e0a478eac..1a1cbbf9f6eb5 100644
--- a/clang/include/clang/AST/DeclarationName.h
+++ b/clang/include/clang/AST/DeclarationName.h
@@ -21,6 +21,7 @@
 #include "clang/Basic/SourceLocation.h"
 #include "llvm/ADT/DenseMapInfo.h"
 #include "llvm/ADT/FoldingSet.h"
+#include "llvm/ADT/STLExtras.h"
 #include "llvm/Support/Compiler.h"
 #include "llvm/Support/type_traits.h"
 #include 
@@ -192,6 +193,13 @@ class DeclarationName {
 "The various classes that DeclarationName::Ptr can point to"
 " must be at least aligned to 8 bytes!");
 
+  static_assert(
+  std::is_same,
+   std::underlying_type_t<
+   detail::DeclarationNameExtra::ExtraKind>>::value,
+  "The various enums used to compute values for NameKind should "
+  "all have the same underlying type");
+
 public:
   /// The kind of the name stored in this DeclarationName.
   /// The first 7 enumeration values are stored inline and correspond
@@ -205,15 +213,18 @@ class DeclarationName {
 CXXDestructorName = StoredCXXDestructorName,
 CXXConversionFunctionName = StoredCXXConversionFunctionName,
 CXXOperatorName = StoredCXXOperatorName,
-CXXDeductionGuideName = UncommonNameKindOffset +
-
detail::DeclarationNameExtra::CXXDeductionGuideName,
-CXXLiteralOperatorName =
-UncommonNameKindOffset +
-detail::DeclarationNameExtra::CXXLiteralOperatorName,
-CXXUsingDirective = UncommonNameKindOffset +
-detail::DeclarationNameExtra::CXXUsingDirective,
-ObjCMultiArgSelector = UncommonNameKindOffset +
-   detail::DeclarationNameExtra::ObjCMultiArgSelector
+CXXDeductionGuideName = llvm::addEnumValues(
+UncommonNameKindOffset,
+detail::DeclarationNameExtra::CXXDeductionGuideName),
+CXXLiteralOperatorName = llvm::addEnumValues(
+UncommonNameKindOffset,
+detail::DeclarationNameExtra::CXXLiteralOperatorName),
+CXXUsingDirective =
+llvm::addEnumValues(UncommonNameKindOffset,
+detail::DeclarationNameExtra::CXXUsingDirective),
+ObjCMultiArgSelector =
+llvm::addEnumValues(UncommonNameKindOffset,
+
detail::DeclarationNameExtra::ObjCMultiArgSelector),
   };
 
 private:

diff  --git a/llvm/include/llvm/ADT/STLExtras.h 
b/llvm/include/llvm/ADT/STLExtras.h
index fc461f8fe7e50..b186489295b41 100644
--- a/llvm/include/llvm/ADT/STLExtras.h
+++ b/llvm/include/llvm/ADT/STLExtras.h
@@ -206,6 +206,17 @@ struct FirstIndexOfType : 
std::integral_constant {};
 template 
 using TypeAtIndex = std::tuple_element_t>;
 
+/// Helper which adds two underlying types of enumeration type.
+/// Implicit conversion to a common type is accepted.
+template ::value,
+  std::underlying_type_t>,
+  typename UT2 = std::enable_if_t::value,
+  std::underlying_type_t>>
+constexpr auto addEnumValues(EnumTy1 LHS, EnumTy2 RHS) {
+  return static_cast(LHS) + static_cast(RHS);
+}
+
 
//===--===//
 // Extra additions to 
 
//===--===//

diff  --git a/llvm/unittests/ADT/STLExtrasTest.cpp 
b/llvm/unittests/ADT/STLExtrasTest.cpp
index 09ff556f3ea15..a32c823e73b66 100644
--- a/llvm/unittests/ADT/STLExtrasTest.cpp
+++ b/llvm/unittests/ADT/STLExtrasTest.cpp
@@ -9,6 +9,7 @@
 #include "llvm/ADT/STLExtras.h"
 #include "gtest/gtest.h"
 
+#include 
 #include 
 #include 
 
@@ -989,4 +990,32 @@ TEST(STLExtrasTest, IsContainedInitializerList) {
   static_assert(!is_contained({1, 2, 3, 4}, 5), "It's not there :(");
 }
 
+TEST(STLExtras

[PATCH] D122808: [clang] Fix warnings when `-Wdeprecated-enum-enum-conversion` is enabled

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

Thank you for the fix! I've landed on your behalf in 
7c3d8c8977cfc013254783b85b9fc6026566b35f 
.


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

https://reviews.llvm.org/D122808

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


[PATCH] D123297: [flang][driver] Add support for -mmlir

2022-04-07 Thread Andrzej Warzynski via Phabricator via cfe-commits
awarzynski updated this revision to Diff 421168.
awarzynski edited the summary of this revision.
awarzynski added a comment.

Fix pre-commit CI


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123297

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Flang.cpp
  flang/include/flang/Frontend/FrontendOptions.h
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/FrontendTool/CMakeLists.txt
  flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
  flang/test/Driver/driver-help-hidden.f90
  flang/test/Driver/driver-help.f90
  flang/test/Driver/mllvm_vs_mmlir.f90

Index: flang/test/Driver/mllvm_vs_mmlir.f90
===
--- /dev/null
+++ flang/test/Driver/mllvm_vs_mmlir.f90
@@ -0,0 +1,18 @@
+! Verify that `-mllvm` options are forwarded to LLVM and `-mmlir` to MLIR
+
+!
+! RUN COMMAND
+!
+! RUN: %flang_fc1  -mmlir --help | FileCheck %s --check-prefix=MLIR
+! RUN: %flang_fc1  -mllvm --help | FileCheck %s --check-prefix=MLLVM
+
+!
+! EXPECTED OUTPUT
+!
+! MLIR: flang (MLIR option parsing) [options]
+! MLIR: --mlir-{{.*}}
+! MLIR-NOT: --mir-strip-debugify-only
+
+! MLLVM: flang (LLVM option parsing) [options]
+! MLLVM: --mir-strip-debugify-only
+! MLLVM-NOT: --mlir-{{.*}}
Index: flang/test/Driver/driver-help.f90
===
--- flang/test/Driver/driver-help.f90
+++ flang/test/Driver/driver-help.f90
@@ -48,6 +48,7 @@
 ! HELP-NEXT: -help  Display available options
 ! HELP-NEXT: -IAdd directory to the end of the list of include search paths
 ! HELP-NEXT: -mllvm  Additional arguments to forward to LLVM's option processing
+! HELP-NEXT: -mmlir  Additional arguments to forward to MLIR's option processing
 ! HELP-NEXT: -module-dir   Put MODULE files in 
 ! HELP-NEXT: -nocpp Disable predefined and command line preprocessor macros
 ! HELP-NEXT: -o   Write output to 
@@ -123,6 +124,7 @@
 ! HELP-FC1-NEXT: -IAdd directory to the end of the list of include search paths
 ! HELP-FC1-NEXT: -load Load the named plugin (dynamic shared object)
 ! HELP-FC1-NEXT: -mllvm  Additional arguments to forward to LLVM's option processing
+! HELP-FC1-NEXT: -mmlir  Additional arguments to forward to MLIR's option processing
 ! HELP-FC1-NEXT: -module-dir   Put MODULE files in 
 ! HELP-FC1-NEXT: -module-suffix  Use  as the suffix for module files (the default value is `.mod`)
 ! HELP-FC1-NEXT: -nocpp Disable predefined and command line preprocessor macros
Index: flang/test/Driver/driver-help-hidden.f90
===
--- flang/test/Driver/driver-help-hidden.f90
+++ flang/test/Driver/driver-help-hidden.f90
@@ -48,6 +48,7 @@
 ! CHECK-NEXT: -help Display available options
 ! CHECK-NEXT: -IAdd directory to the end of the list of include search paths
 ! CHECK-NEXT: -mllvm  Additional arguments to forward to LLVM's option processing
+! CHECK-NEXT: -mmlir  Additional arguments to forward to MLIR's option processing
 ! CHECK-NEXT: -module-dir   Put MODULE files in 
 ! CHECK-NEXT: -nocpp Disable predefined and command line preprocessor macros
 ! CHECK-NEXT: -o  Write output to 
Index: flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
===
--- flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
+++ flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
@@ -11,6 +11,8 @@
 //
 //===--===//
 
+#include "mlir/IR/MLIRContext.h"
+#include "mlir/Pass/PassManager.h"
 #include "flang/Frontend/CompilerInstance.h"
 #include "flang/Frontend/FrontendActions.h"
 #include "flang/Frontend/FrontendPluginRegistry.h"
@@ -148,6 +150,21 @@
 llvm::cl::ParseCommandLineOptions(numArgs + 1, args.get());
   }
 
+  // Honor -mmlir. This should happen AFTER plugins have been loaded!
+  if (!flang->frontendOpts().mlirArgs.empty()) {
+mlir::registerMLIRContextCLOptions();
+mlir::registerPassManagerCLOptions();
+unsigned numArgs = flang->frontendOpts().mlirArgs.size();
+auto args = std::make_unique(numArgs + 2);
+args[0] = "flang (MLIR option parsing)";
+
+for (unsigned i = 0; i != numArgs; ++i)
+  args[i + 1] = flang->frontendOpts().mlirArgs[i].c_str();
+
+args[numArgs + 1] = nullptr;
+llvm::cl::ParseCommandLineOptions(numArgs + 1, args.get());
+  }
+
   // If there were errors in processing arguments, don't do anything else.
   if (flang->diagnostics().hasErrorOccurred()) {
 return false;
Index: flang/lib/FrontendTool/CMakeLists.txt

Re: [PATCH] D123298: [NFC] [AST] Reduce the size of TemplateParmPosition

2022-04-07 Thread Corentin via cfe-commits
On Thu, Apr 7, 2022 at 2:11 PM Aaron Ballman via Phabricator <
revi...@reviews.llvm.org> wrote:

> aaron.ballman added a comment.
>
> In D123298#3435796 , @cor3ntin
> wrote:
>
> > In D123298#3435770 ,
> @aaron.ballman wrote:
> >
> >> Changes LGTM, I also don't think we should hit these limits. Perhaps we
> should add some assertions to the ctor and the setter functions just to be
> sure though?
> >
> > If we are going to do anything, it ought to be a diagnostic?
>
> Doing a diagnostic would mean finding all the places where we form a
> `TemplateParmPosition` and ensure we have enough source location
> information to issue the diagnostic. Given that we don't expect users to
> ever hit it, having the assertion gives a wee bit of coverage (godbolt
> exposes an assertions build, for example) but without as much
> implementation burden. That said, if it's easy enough to give diagnostics,
> that's a more user-friendly approach if we think anyone would hit that
> limit. (I suspect template instantiation depth would be hit before bumping
> up against these limits, though.)
>

Fair enough - I suspect godbolt would die in that scenario though.
Note that i was not asking for a diagnostic, just saying that the assertion
may not protect anyone


>
> > I can't imagine a scenario in which someone would hit these limits and
> have assertions enabled. But i agree with you that the limit themselves
> should not be hit.
> > On the other hand, why not use 16 for both?
>
> I think people instantiate to deeper template depths than they typically
> have for template parameters, so having a deeper depth made sense to me.
>

Sure, but there is a huge imbalance there. 1048576 vs 4096 - I think it's
still better than msvc and it's conforming - the standard sets the minimum
at 1024 for both afaik


>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D123298/new/
>
> https://reviews.llvm.org/D123298
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D123297: [flang][driver] Add support for -mmlir

2022-04-07 Thread Andrzej Warzynski via Phabricator via cfe-commits
awarzynski added a comment.

In D123297#3435816 , @rovka wrote:

> I don't know the command line library that well, so I have this curiosity: 
> what happens if LLVM and MLIR have 2 different options with the same name? Do 
> we get a compile time error?

The llvm::cl API uses global variables. So, if a variable is defined twice, you 
will get a compilation error. I will advertise this before merging so that 
folks from LLVM and MLIR are aware of this change. I'm hoping that they won't 
mind having to use distinct variable names for CL options in MLIR and LLVM.

> Or is there a risk that someone might -mllvm -XYZ and it would end up in 
> MLIR's XYZ option instead, because we're processing the MLIR options after 
> the LLVM ones?

Note that `-mllvm` options are saved in `llvmArgs` and `-mmlir` options are 
saved in `mlirArgs` (this is taken care of in "CompilerInvocation.cpp"). This 
should guarantee that the right option set is used.




Comment at: flang/test/Driver/mllvm_vs_mmlir.f90:17
+! MLLVM: flang (LLVM option parsing) [options]
+! MLLVM: --print-ir-after-all
+! MLLVM-NOT: --mlir-{{.*}}

rovka wrote:
> rovka wrote:
> > Is this the most llvm-ish option we have? I'm concerned that MLIR might 
> > also decide to add an option that sounds like this (and for sure 
> > -print-ir-before-all is mentioned in the [[ 
> > https://mlir.llvm.org/getting_started/Debugging/ |  MLIR docs ]]).
> > Is this the most llvm-ish option we have? I'm concerned that MLIR might 
> > also decide to add an option that sounds like this (and for sure 
> > -print-ir-before-all is mentioned in the [[ 
> > https://mlir.llvm.org/getting_started/Debugging/ |  MLIR docs ]]).
> 
> Right, I think that might be why the premerge tests are failing...
> Is this the most llvm-ish option we have? 

Sadly, most LLVM options have rather generic names that could at some point be 
added in MLIR. Perhaps you'll spot something more suitable:

```lang=bash
USAGE: flang (LLVM option parsing) [options]

OPTIONS:

Color Options:

  --color   - Use colors in output 
(default=autodetect)

General options:

  --aarch64-neon-syntax= - Choose style of NEON code 
to emit from AArch64 backend:
=generic-   Emit generic NEON 
assembly
=apple  -   Emit Apple-style NEON 
assembly
  --aarch64-use-aa  - Enable the use of AA 
during codegen.
  --abort-on-max-devirt-iterations-reached  - Abort when the max 
iterations for devirtualization CGSCC repeat pass is reached
  --allow-ginsert-as-artifact   - Allow G_INSERT to be 
considered an artifact. Hack around AMDGPU test infinite loops.
  --always-execute-loop-body- force the body of a loop 
to execute at least once
  --array-constructor-initial-buffer-size=- set the incremental array 
construction buffer size (default=32)
  --cfg-hide-cold-paths=- Hide blocks with relative 
frequency below the given value
  --cfg-hide-deoptimize-paths   -
  --cfg-hide-unreachable-paths  -
  --cost-kind=   - Target cost kind
=throughput -   Reciprocal throughput
=latency-   Instruction latency
=code-size  -   Code size
=size-latency   -   Code size and latency
  --debugify-level=  - Kind of debug info to add
=locations  -   Locations only
=location+variables -   Locations and Variables
  --debugify-quiet  - Suppress verbose debugify 
output
  --default-kinds= - string to set default 
kind values
  --disable-i2p-p2i-opt - Disables 
inttoptr/ptrtoint roundtrip optimization
  --dot-cfg-mssa= - file name for generated 
dot file
  --enable-cse-in-irtranslator  - Should enable CSE in 
irtranslator
  --enable-cse-in-legalizer - Should enable CSE in 
Legalizer
  --enable-gvn-memdep   -
  --enable-load-in-loop-pre -
  --enable-load-pre -
  --enable-loop-simplifycfg-term-folding-
  --enable-name-compression - Enable name/filename 
string compression
  --enable-split-backedge-in-load-pre   -
  --experimental-debug-variable-locations   - Use experimental new 
value-tracking variable locations
  --fdebug-dump-pre-fir - dump the Pre-FIR tree 
prior to FIR generation
  --fs-profile-debug-bw-threshold=- Only show debug 

Re: [PATCH] D123298: [NFC] [AST] Reduce the size of TemplateParmPosition

2022-04-07 Thread Aaron Ballman via cfe-commits
On Thu, Apr 7, 2022 at 8:35 AM Corentin via cfe-commits
 wrote:
>
>
>
> On Thu, Apr 7, 2022 at 2:11 PM Aaron Ballman via Phabricator 
>  wrote:
>>
>> aaron.ballman added a comment.
>>
>> In D123298#3435796 , @cor3ntin 
>> wrote:
>>
>> > In D123298#3435770 , 
>> > @aaron.ballman wrote:
>> >
>> >> Changes LGTM, I also don't think we should hit these limits. Perhaps we 
>> >> should add some assertions to the ctor and the setter functions just to 
>> >> be sure though?
>> >
>> > If we are going to do anything, it ought to be a diagnostic?
>>
>> Doing a diagnostic would mean finding all the places where we form a 
>> `TemplateParmPosition` and ensure we have enough source location information 
>> to issue the diagnostic. Given that we don't expect users to ever hit it, 
>> having the assertion gives a wee bit of coverage (godbolt exposes an 
>> assertions build, for example) but without as much implementation burden. 
>> That said, if it's easy enough to give diagnostics, that's a more 
>> user-friendly approach if we think anyone would hit that limit. (I suspect 
>> template instantiation depth would be hit before bumping up against these 
>> limits, though.)
>
>
> Fair enough - I suspect godbolt would die in that scenario though.
> Note that i was not asking for a diagnostic, just saying that the assertion 
> may not protect anyone

Agreed, it's a pretty paltry protection. :-) My thinking is: we likely
have torture test suite cases that may tell us if we've guessed wrong
(either in tree, or in some downstream).

>> > I can't imagine a scenario in which someone would hit these limits and 
>> > have assertions enabled. But i agree with you that the limit themselves 
>> > should not be hit.
>> > On the other hand, why not use 16 for both?
>>
>> I think people instantiate to deeper template depths than they typically 
>> have for template parameters, so having a deeper depth made sense to me.
>
> Sure, but there is a huge imbalance there. 1048576 vs 4096 - I think it's 
> still better than msvc and it's conforming - the standard sets the minimum at 
> 1024 for both afaik

That's a fair point. I don't have a strong opinion on what bit widths
we use so long as they are "sensible" (for some definition of the
term).
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 9eda5fc - [clang] Verify internal entity module mangling

2022-04-07 Thread Nathan Sidwell via cfe-commits

Author: Nathan Sidwell
Date: 2022-04-07T05:40:57-07:00
New Revision: 9eda5fc0c6eafd772d0e6ff015352136c5e505a4

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

LOG: [clang] Verify internal entity module mangling

Internal symbol mangling is implementation-defined.  We do not mangle
any module attachment, and this adds a test to verify that.

Reviewed By: dblaikie

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

Added: 
clang/test/CodeGenCXX/cxx20-module-internal.cppm

Modified: 


Removed: 




diff  --git a/clang/test/CodeGenCXX/cxx20-module-internal.cppm 
b/clang/test/CodeGenCXX/cxx20-module-internal.cppm
new file mode 100644
index 0..b45358325c423
--- /dev/null
+++ b/clang/test/CodeGenCXX/cxx20-module-internal.cppm
@@ -0,0 +1,46 @@
+// RUN: %clang_cc1 -std=c++20 %s -triple %itanium_abi_triple -emit-llvm -o - | 
FileCheck %s
+
+// internal-linkage symbol mangling is implementation defined.  Let's
+// not mangle in the module attachment -- that unnecessarily bloats
+// the symbols.
+
+export module A;
+
+// CHECK-DAG: void @_ZL6addonev(
+static void addone() {}
+// CHECK-DAG: @_ZL1x =
+static int x = 5;
+
+namespace {
+// CHECK-DAG: void @_ZN12_GLOBAL__N_14frobEv(
+void frob() {}
+// CHECK-DAG: @_ZN12_GLOBAL__N_11yE =
+int y = 2;
+struct Bill {
+  void F();
+};
+// CHECK-DAG: void @_ZN12_GLOBAL__N_14Bill1FEv(
+void Bill::F() {}
+} // namespace
+
+// CHECK-DAG: void @_ZL4FrobPN12_GLOBAL__N_14BillE(
+static void Frob(Bill *b) {
+  if (b)
+b->F();
+}
+
+namespace N {
+// CHECK-DAG: void @_ZN1NL5innerEv(
+static void inner() {}
+// CHECK-DAG: @_ZN1NL1zE
+static int z = 3;
+} // namespace N
+
+// CHECK-DAG: void @_ZW1A6addsixv(
+void addsix() {
+  Frob(nullptr);
+  frob();
+  addone();
+  void(x + y + N::z);
+  N::inner();
+}



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


[PATCH] D123220: [clang] Verify internal entity module mangling

2022-04-07 Thread Nathan Sidwell via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG9eda5fc0c6ea: [clang] Verify internal entity module mangling 
(authored by urnathan).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D123220?vs=420841&id=421170#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123220

Files:
  clang/test/CodeGenCXX/cxx20-module-internal.cppm


Index: clang/test/CodeGenCXX/cxx20-module-internal.cppm
===
--- /dev/null
+++ clang/test/CodeGenCXX/cxx20-module-internal.cppm
@@ -0,0 +1,46 @@
+// RUN: %clang_cc1 -std=c++20 %s -triple %itanium_abi_triple -emit-llvm -o - | 
FileCheck %s
+
+// internal-linkage symbol mangling is implementation defined.  Let's
+// not mangle in the module attachment -- that unnecessarily bloats
+// the symbols.
+
+export module A;
+
+// CHECK-DAG: void @_ZL6addonev(
+static void addone() {}
+// CHECK-DAG: @_ZL1x =
+static int x = 5;
+
+namespace {
+// CHECK-DAG: void @_ZN12_GLOBAL__N_14frobEv(
+void frob() {}
+// CHECK-DAG: @_ZN12_GLOBAL__N_11yE =
+int y = 2;
+struct Bill {
+  void F();
+};
+// CHECK-DAG: void @_ZN12_GLOBAL__N_14Bill1FEv(
+void Bill::F() {}
+} // namespace
+
+// CHECK-DAG: void @_ZL4FrobPN12_GLOBAL__N_14BillE(
+static void Frob(Bill *b) {
+  if (b)
+b->F();
+}
+
+namespace N {
+// CHECK-DAG: void @_ZN1NL5innerEv(
+static void inner() {}
+// CHECK-DAG: @_ZN1NL1zE
+static int z = 3;
+} // namespace N
+
+// CHECK-DAG: void @_ZW1A6addsixv(
+void addsix() {
+  Frob(nullptr);
+  frob();
+  addone();
+  void(x + y + N::z);
+  N::inner();
+}


Index: clang/test/CodeGenCXX/cxx20-module-internal.cppm
===
--- /dev/null
+++ clang/test/CodeGenCXX/cxx20-module-internal.cppm
@@ -0,0 +1,46 @@
+// RUN: %clang_cc1 -std=c++20 %s -triple %itanium_abi_triple -emit-llvm -o - | FileCheck %s
+
+// internal-linkage symbol mangling is implementation defined.  Let's
+// not mangle in the module attachment -- that unnecessarily bloats
+// the symbols.
+
+export module A;
+
+// CHECK-DAG: void @_ZL6addonev(
+static void addone() {}
+// CHECK-DAG: @_ZL1x =
+static int x = 5;
+
+namespace {
+// CHECK-DAG: void @_ZN12_GLOBAL__N_14frobEv(
+void frob() {}
+// CHECK-DAG: @_ZN12_GLOBAL__N_11yE =
+int y = 2;
+struct Bill {
+  void F();
+};
+// CHECK-DAG: void @_ZN12_GLOBAL__N_14Bill1FEv(
+void Bill::F() {}
+} // namespace
+
+// CHECK-DAG: void @_ZL4FrobPN12_GLOBAL__N_14BillE(
+static void Frob(Bill *b) {
+  if (b)
+b->F();
+}
+
+namespace N {
+// CHECK-DAG: void @_ZN1NL5innerEv(
+static void inner() {}
+// CHECK-DAG: @_ZN1NL1zE
+static int z = 3;
+} // namespace N
+
+// CHECK-DAG: void @_ZW1A6addsixv(
+void addsix() {
+  Frob(nullptr);
+  frob();
+  addone();
+  void(x + y + N::z);
+  N::inner();
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D121556: [randstruct] Add randomize structure layout support

2022-04-07 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

Recap: aside from the function merging behavior and the possible question about 
assertions in tests, I think this is ready to go.




Comment at: clang/lib/Sema/SemaDecl.cpp:27
 #include "clang/AST/NonTrivialTypeVisitor.h"
+#include "clang/AST/Randstruct.h"
 #include "clang/AST/StmtCXX.h"

void wrote:
> aaron.ballman wrote:
> > Is this include necessary?
> Yes. There's a call to `randstruct::randomizeStructureLayout` below.
Oh derp, I missed that. :-)



Comment at: clang/unittests/AST/RandstructTest.cpp:154-158
+#ifdef _WIN32
+  const field_names Expected = {"lettuce", "bacon", "mayonnaise", "tomato"};
+#else
+  const field_names Expected = {"mayonnaise", "bacon", "tomato", "lettuce"};
+#endif

void wrote:
> aaron.ballman wrote:
> > Any idea what's gone wrong here? (Do we have a bug to file because these 
> > come out reversed? If so, can you add a FIXME comment here that we expect 
> > this test to change someday?)
> I think it's just a case where Windows' algorithm for `std::mt19937` is 
> subtly different than the one for Linux. I'm not sure we should worry about 
> it too much, to be honest. As long as it produces a deterministic output on 
> the same platform we should be fine. I think it's expected that the same 
> compiler/environment is used during all compilation steps. (I.e., one's not 
> going to compile a module on Windows for a kernel build on Linux.)
Okay, that's a great reason for this to be left alone.



Comment at: clang/unittests/AST/RandstructTest.cpp:208-213
+// FIXME: Clang trips an assertion in the DiagnosticsEngine when the warning is
+// emitted while running under the test suite:
+// clang/lib/Frontend/TextDiagnosticPrinter.cpp:150: virtual void
+// 
clang::TextDiagnosticPrinter::HandleDiagnostic(clang::DiagnosticsEngine::Level,
+// const clang::Diagnostic&): Assertion `TextDiag && "UnExpected diagnostic
+// outside source file processing"' failed.

void wrote:
> aaron.ballman wrote:
> > Is the assertion unrelated to the changes in your patch and you just happen 
> > to hit it with this test? (I get worried when tests trigger assertions.)
> To be honest, I haven't looked at these tests. I inherited them from the 
> previous code base. I'll revisit these and probably delete them if they're 
> not useful.
Okay, that sounds good to me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121556

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


[PATCH] D122699: [HLSL] Add Semantic syntax, and SV_GroupIndex

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

LGTM! There's an open question about the circumstances under which we emit the 
`err_hlsl_attr_unsupported_in_stage` diagnostic, but if there's code to be 
changed there, it can be done in a follow up.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122699

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


[PATCH] D122983: [C11/C2x] Change the behavior of the implicit function declaration warning

2022-04-07 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D122983#3433919 , @erichkeane 
wrote:

> Up for review: https://reviews.llvm.org/D123241

Thank you @erichkeane! That landed in a87f4e4f9808a397dc4c575013142c9eac0b7eba 
, so it 
should no longer be blocking this patch.


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

https://reviews.llvm.org/D122983

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


[PATCH] D123303: [Clang][AArch64][SVE] Add shift operators for SVE vector types

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

This patch enables shift operators on SVE vector types, as well as
supporting vector-scalar shift operations.
Shifts by a scalar that is wider than the contained type in the
vector are permitted but as in the C standard if the value is larger
than the width of the type the behavior is undefined.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D123303

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

Index: clang/test/SemaCXX/sizeless-1.cpp
===
--- clang/test/SemaCXX/sizeless-1.cpp
+++ clang/test/SemaCXX/sizeless-1.cpp
@@ -210,14 +210,9 @@
   __real init_int8; // expected-error {{invalid type 'svint8_t'}}
   __imag init_int8; // expected-error {{invalid type 'svint8_t'}}
 
-  local_int8 << init_int8; // expected-error {{invalid operands to binary expression}}
-  local_int8 >> init_int8; // expected-error {{invalid operands to binary expression}}
   local_int8 &&init_int8;  // expected-error {{invalid operands to binary expression}} expected-error {{not contextually convertible}}
   local_int8 || init_int8; // expected-error {{invalid operands to binary expression}} expected-error {{not contextually convertible}}
 
-  local_int8 <<= init_int8; // expected-error {{invalid operands to binary expression}}
-  local_int8 >>= init_int8; // expected-error {{invalid operands to binary expression}}
-
   local_int8 + 0;  // expected-error {{invalid operands to binary expression}}
   local_int8 - 0;  // expected-error {{invalid operands to binary expression}}
   local_int8 * 0;  // expected-error {{invalid operands to binary expression}}
@@ -226,8 +221,6 @@
   local_int8 & 0;  // expected-error {{invalid operands to binary expression}}
   local_int8 | 0;  // expected-error {{invalid operands to binary expression}}
   local_int8 ^ 0;  // expected-error {{invalid operands to binary expression}}
-  local_int8 << 0; // expected-error {{invalid operands to binary expression}}
-  local_int8 >> 0; // expected-error {{invalid operands to binary expression}}
   local_int8 < 0;  // expected-error {{invalid operands to binary expression}}
   local_int8 <= 0; // expected-error {{invalid operands to binary expression}}
   local_int8 == 0; // expected-error {{invalid operands to binary expression}}
Index: clang/test/Sema/sizeless-1.c
===
--- clang/test/Sema/sizeless-1.c
+++ clang/test/Sema/sizeless-1.c
@@ -198,14 +198,9 @@
   __real init_int8; // expected-error {{invalid type 'svint8_t'}}
   __imag init_int8; // expected-error {{invalid type 'svint8_t'}}
 
-  local_int8 << init_int8; // expected-error {{invalid operands to binary expression}}
-  local_int8 >> init_int8; // expected-error {{invalid operands to binary expression}}
   local_int8 &&init_int8;  // expected-error {{invalid operands to binary expression}}
   local_int8 || init_int8; // expected-error {{invalid operands to binary expression}}
 
-  local_int8 <<= init_int8; // expected-error {{invalid operands to binary expression}}
-  local_int8 >>= init_int8; // expected-error {{invalid operands to binary expression}}
-
   local_int8 + 0;  // expected-error {{invalid operands to binary expression}}
   local_int8 - 0;  // expected-error {{invalid operands to binary expression}}
   local_int8 * 0;  // expected-error {{invalid operands to binary expression}}
@@ -214,8 +209,6 @@
   local_int8 & 0;  // expected-error {{invalid operands to binary expression}}
   local_int8 | 0;  // expected-error {{invalid operands to binary expression}}
   local_int8 ^ 0;  // expected-error {{invalid operands to binary expression}}
-  local_int8 << 0; // expected-error {{invalid operands to binary expression}}
-  local_int8 >> 0; // expected-error {{invalid operands to binary expression}}
   local_int8 < 0;  // expected-error {{invalid operands to binary expression}}
   local_int8 <= 0; // expected-error {{invalid operands to binary expression}}
   local_int8 == 0; // expected-error {{invalid operands to binary expression}}
Index: clang/test/Sema/aarch64-sve-vector-shift-ops.c
===
--- /dev/null
+++ clang/test/Sema/aarch64-sve-vector-shift-ops.c
@@ -0,0 +1,583 @@
+// RUN: %clang_cc1 -verify -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -fsyntax-only %s
+
+// REQUIRES: aarch64-registered-target
+
+#include 
+
+void lshift(svint8_t i8, svint16_t i16, svint32_t i32, svint64_t i64,
+svuint8_t u8, svuint16_t 

[PATCH] D123304: [clang][extract-api] Emit "functionSignature" in SGF for ObjC methods.

2022-04-07 Thread Daniel Grumberg via Phabricator via cfe-commits
dang created this revision.
dang added reviewers: zixuw, QuietMisdreavus.
Herald added a project: All.
dang requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D123304

Files:
  clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
  clang/test/ExtractAPI/objc_category.m
  clang/test/ExtractAPI/objc_interface.m

Index: clang/test/ExtractAPI/objc_interface.m
===
--- clang/test/ExtractAPI/objc_interface.m
+++ clang/test/ExtractAPI/objc_interface.m
@@ -170,6 +170,38 @@
   "spelling": "Property"
 }
   ],
+  "functionSignature": {
+"parameters": [
+  {
+"declarationFragments": [
+  {
+"kind": "text",
+"spelling": "("
+  },
+  {
+"kind": "typeIdentifier",
+"preciseIdentifier": "c:i",
+"spelling": "unsigned int"
+  },
+  {
+"kind": "text",
+"spelling": ")"
+  },
+  {
+"kind": "internalParam",
+"spelling": "Property"
+  }
+],
+"name": "Property"
+  }
+],
+"returns": [
+  {
+"kind": "keyword",
+"spelling": "id"
+  }
+]
+  },
   "identifier": {
 "interfaceLanguage": "objective-c",
 "precise": "c:objc(cs)Super(cm)getWithProperty:"
@@ -405,6 +437,15 @@
   "spelling": "getIvar"
 }
   ],
+  "functionSignature": {
+"returns": [
+  {
+"kind": "typeIdentifier",
+"preciseIdentifier": "c:C",
+"spelling": "char"
+  }
+]
+  },
   "identifier": {
 "interfaceLanguage": "objective-c",
 "precise": "c:objc(cs)Derived(im)getIvar"
Index: clang/test/ExtractAPI/objc_category.m
===
--- clang/test/ExtractAPI/objc_category.m
+++ clang/test/ExtractAPI/objc_category.m
@@ -138,6 +138,15 @@
   "spelling": "InstanceMethod"
 }
   ],
+  "functionSignature": {
+"returns": [
+  {
+"kind": "typeIdentifier",
+"preciseIdentifier": "c:v",
+"spelling": "void"
+  }
+]
+  },
   "identifier": {
 "interfaceLanguage": "objective-c",
 "precise": "c:objc(cs)Interface(im)InstanceMethod"
@@ -192,6 +201,15 @@
   "spelling": "ClassMethod"
 }
   ],
+  "functionSignature": {
+"returns": [
+  {
+"kind": "typeIdentifier",
+"preciseIdentifier": "c:v",
+"spelling": "void"
+  }
+]
+  },
   "identifier": {
 "interfaceLanguage": "objective-c",
 "precise": "c:objc(cs)Interface(cm)ClassMethod"
Index: clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
===
--- clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
+++ clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
@@ -14,6 +14,7 @@
 #include "clang/ExtractAPI/Serialization/SymbolGraphSerializer.h"
 #include "clang/Basic/Version.h"
 #include "clang/ExtractAPI/API.h"
+#include "llvm/Support/Casting.h"
 #include "llvm/Support/JSON.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/VersionTuple.h"
@@ -491,6 +492,10 @@
 if (!MemberRecord)
   continue;
 
+if (const auto *Method = dyn_cast(Member.get()))
+  serializeObject(*MemberRecord, "functionSignature",
+  serializeFunctionSignature(Method->Signature));
+
 Symbols.emplace_back(std::move(*MemberRecord));
 serializeRelationship(RelationshipKind::MemberOf, *Member, Record);
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] dc15bed - Fix MSVC "not all control paths return a value" warning

2022-04-07 Thread Simon Pilgrim via cfe-commits

Author: Simon Pilgrim
Date: 2022-04-07T14:01:15+01:00
New Revision: dc15bedfb9de8ec574c1b480a15cd584b82eaa0d

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

LOG: Fix MSVC "not all control paths return a value" warning

Added: 


Modified: 
clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp 
b/clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp
index 355c3183edf60..b9809a2808faa 100644
--- a/clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp
+++ b/clang-tools-extra/clangd/refactor/tweaks/ExtractFunction.cpp
@@ -479,6 +479,7 @@ std::string NewFunction::renderDeclaration(FunctionDeclKind 
K,
 llvm::formatv("{0} {\n{1}\n}\n", Declaration, getFuncBody(SM)));
 break;
   }
+  llvm_unreachable("Unsupported FunctionDeclKind enum");
 }
 
 std::string NewFunction::getFuncBody(const SourceManager &SM) const {



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


[PATCH] D123298: [NFC] [AST] Reduce the size of TemplateParmPosition

2022-04-07 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

> I think people instantiate to deeper template depths than they typically have 
> for template parameters, so having a deeper depth made sense to me.

Hmm... the cases I can think of make me think this isn't necessarily true... It 
is very common to template-recurse on an integer-sequence of some sort, which 
would result in depth and position being roughly the same.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123298

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


[PATCH] D123261: [clang][ExtractAPI] Fix declaration fragments for ObjC methods

2022-04-07 Thread Daniel Grumberg via Phabricator via cfe-commits
dang accepted this revision.
dang added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123261

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


[PATCH] D122874: [clang] Add GNU spelling for no_unqiue_address attribute

2022-04-07 Thread Nikolas Klauser via Phabricator via cfe-commits
philnik added a comment.

> Hmmm, I'd be more comfortable if this wasn't an ABI break for people using 
> the `__attribute__(())` spelling. If we wanted to surprise users with ABI 
> breaks, we'd just implement `[[no_unique_address]]` on Windows and break 
> users when Microsoft eventually supports the attribute, which is an approach 
> I'm rather strongly opposed to. In this case, it's a bit different because 
> it's a GNU-style spelling and Microsoft doesn't support that spelling at all, 
> so my thinking was that we could define the ABI for it and make it stable 
> because it's our extension. But I can see why you'd want something different 
> in libc++.

I'm also OK with `__attribute__((no_unique_address))` being stable. We have all 
these fun things behind a macro anyways currently, so nothing would prevent us 
from having `__attribute__((no_unique_address))` in the stable ABI and use 
`[[no_unique_address]]` (whenever it will be implemented) in the unstable ABI. 
Or just remove the macro stuff if it will be the same ABI.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122874

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


[PATCH] D119544: Deferred Concept Instantiation Implementation

2022-04-07 Thread Erich Keane via Phabricator via cfe-commits
erichkeane marked 8 inline comments as done.
erichkeane added inline comments.



Comment at: clang/lib/Sema/SemaTemplate.cpp:4705
   CheckConstraintSatisfaction(
-  NamedConcept, {NamedConcept->getConstraintExpr()}, Converted,
+  NamedConcept, {NamedConcept->getConstraintExpr()}, MLTAL,
   SourceRange(SS.isSet() ? SS.getBeginLoc() : ConceptNameInfo.getLoc(),

ChuanqiXu wrote:
> I would feel better if we could write:
> ```
> CheckConstraintSatisfaction(
>   NamedConcept, {NamedConcept->getConstraintExpr()}, {MLTAL},
>   SourceRange(SS.isSet() ? SS.getBeginLoc() : 
> ConceptNameInfo.getLoc(),
>   TemplateArgs->getRAngleLoc()),
>   Satisfaction)
> ```
> 
> But it looks unimplementable.
I'm not sure I get the suggestion?  Why would you want to put the 
`MultiLevelTemplateArgumentList` in curleys?  



Comment at: clang/lib/Sema/SemaTemplate.cpp:7468-7483
+  // Attn Reviewers: This works and fixes the constraint comparison issues,
+  // but I don't have a good idea why this is, nor if it is the 'right'
+  // thing.  I THINK it is pulling off the 'template template' level of the
+  // constraint, but I have no idea if that is the correct thing to do.
+  SmallVector ConvertedParamsAC;
+  TemplateArgumentList Empty(TemplateArgumentList::OnStack, {});
+  MultiLevelTemplateArgumentList MLTAL{Empty};

ChuanqiXu wrote:
> I've spent some time to playing it myself to figure it out. And I found that 
> we could fix this cleaner we adopt above suggestions. The problem here is 
> that the instantiation is started half way. But the conversion for the 
> constraint have been deferred. So here is the problem. I guess there are 
> other similar problems. But let's fix them after we met them actually.
> 
Ah, neat!  Thanks for this.  Done.


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

https://reviews.llvm.org/D119544

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


[PATCH] D123298: [NFC] [AST] Reduce the size of TemplateParmPosition

2022-04-07 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

I note that 'recursive' depth is limited to 1024: 
https://godbolt.org/z/h9bEfsToT

Though I think there are other ways to get 'deeper' than that.  So perhaps in 
any case we're just arranging deck chairs on a -post-error titanic :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123298

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


[PATCH] D119544: Deferred Concept Instantiation Implementation

2022-04-07 Thread Erich Keane via Phabricator via cfe-commits
erichkeane updated this revision to Diff 421186.
erichkeane marked 2 inline comments as done.
erichkeane added a comment.

Make suggestions from @ChuanqiXu


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

https://reviews.llvm.org/D119544

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Sema/Template.h
  clang/lib/Sema/SemaConcept.cpp
  clang/lib/Sema/SemaTemplate.cpp
  clang/lib/Sema/SemaTemplateDeduction.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/lib/Sema/SemaTemplateInstantiateDecl.cpp
  clang/lib/Sema/TreeTransform.h
  clang/test/CXX/temp/temp.constr/temp.constr.constr/non-function-templates.cpp
  clang/test/SemaTemplate/deferred-concept-inst.cpp
  clang/test/SemaTemplate/instantiate-requires-clause.cpp
  clang/test/SemaTemplate/trailing-return-short-circuit.cpp

Index: clang/test/SemaTemplate/trailing-return-short-circuit.cpp
===
--- /dev/null
+++ clang/test/SemaTemplate/trailing-return-short-circuit.cpp
@@ -0,0 +1,61 @@
+// RUN: %clang_cc1 -std=c++20 -verify %s
+
+template 
+requires(sizeof(T) > 2) || T::value // #FOO_REQ
+void Foo(T){};  // #FOO
+
+template 
+void TrailingReturn(T) // #TRAILING
+requires(sizeof(T) > 2) || // #TRAILING_REQ
+T::value{};// #TRAILING_REQ_VAL
+template 
+struct HasValue {
+  static constexpr bool value = B;
+};
+static_assert(sizeof(HasValue) <= 2);
+
+template 
+struct HasValueLarge {
+  static constexpr bool value = B;
+  int I;
+};
+static_assert(sizeof(HasValueLarge) > 2);
+
+void usage() {
+  // Passes the 1st check, short-circuit so the 2nd ::value is not evaluated.
+  Foo(1.0);
+  TrailingReturn(1.0);
+
+  // Fails the 1st check, but has a ::value, so the check happens correctly.
+  Foo(HasValue{});
+  TrailingReturn(HasValue{});
+
+  // Passes the 1st check, but would have passed the 2nd one.
+  Foo(HasValueLarge{});
+  TrailingReturn(HasValueLarge{});
+
+  // Fails the 1st check, fails 2nd because there is no ::value.
+  Foo(true);
+  // expected-error@-1{{no matching function for call to 'Foo'}}
+  // expected-note@#FOO{{candidate template ignored: constraints not satisfied [with T = bool]}}
+  // expected-note@#FOO_REQ{{because 'sizeof(_Bool) > 2' (1 > 2) evaluated to false}}
+  // expected-note@#FOO_REQ{{because substituted constraint expression is ill-formed: type 'bool' cannot be used prior to '::' because it has no members}}
+
+  TrailingReturn(true);
+  // expected-error@-1{{no matching function for call to 'TrailingReturn'}}
+  // expected-note@#TRAILING{{candidate template ignored: constraints not satisfied [with T = bool]}}
+  // expected-note@#TRAILING_REQ{{because 'sizeof(_Bool) > 2' (1 > 2) evaluated to false}}
+  // expected-note@#TRAILING_REQ_VAL{{because substituted constraint expression is ill-formed: type 'bool' cannot be used prior to '::' because it has no members}}
+
+  // Fails the 1st check, fails 2nd because ::value is false.
+  Foo(HasValue{});
+  // expected-error@-1 {{no matching function for call to 'Foo'}}
+  // expected-note@#FOO{{candidate template ignored: constraints not satisfied [with T = HasValue]}}
+  // expected-note@#FOO_REQ{{because 'sizeof(HasValue) > 2' (1 > 2) evaluated to false}}
+  // expected-note@#FOO_REQ{{and 'HasValue::value' evaluated to false}}
+  TrailingReturn(HasValue{});
+  // expected-error@-1 {{no matching function for call to 'TrailingReturn'}}
+  // expected-note@#TRAILING{{candidate template ignored: constraints not satisfied [with T = HasValue]}}
+  // expected-note@#TRAILING_REQ{{because 'sizeof(HasValue) > 2' (1 > 2) evaluated to false}}
+  // expected-note@#TRAILING_REQ_VAL{{and 'HasValue::value' evaluated to false}}
+}
Index: clang/test/SemaTemplate/instantiate-requires-clause.cpp
===
--- clang/test/SemaTemplate/instantiate-requires-clause.cpp
+++ clang/test/SemaTemplate/instantiate-requires-clause.cpp
@@ -40,6 +40,18 @@
 
 static_assert(S::f(1));
 
+// Similar to the 'S' test, but tries to use 'U' in the requires clause.
+template 
+struct S1 {
+  // expected-note@+3 {{candidate template ignored: constraints not satisfied [with U = int]}}
+  // expected-note@+2 {{because substituted constraint expression is ill-formed: type 'int' cannot be used prior to '::' because it has no members}}
+  template 
+  static constexpr auto f(U const index) requires(U::foo) { return true; }
+};
+
+// expected-error@+1 {{no matching function for call to 'f'}}
+static_assert(S1::f(1));
+
 constexpr auto value = 0;
 
 template
Index: clang/test/SemaTemplate/deferred-concept-inst.cpp
===
--- /dev/null
+++ clang/test/SemaTemplate/deferred-concept-inst.cpp
@@ -0,0 +1,23 @@
+// RUN: %clang_cc1 -std=c++2a -x c++ %s -verify -Wno-unused-value
+// expected-no-diagnostics
+
+namespace GithubBug44178 {
+template

[PATCH] D123200: [compiler-rt][CMake] Add initial support of target AVR

2022-04-07 Thread Ayke via Phabricator via cfe-commits
aykevl added a comment.

What about chip families other than avr2? Some have a different PC pointer size 
(1-3 bytes, therefore affecting the ABI), some have different instructions, etc.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123200

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


[PATCH] D123308: Handle a subtle hole in inline builtin handling

2022-04-07 Thread serge via Phabricator via cfe-commits
serge-sans-paille created this revision.
serge-sans-paille added reviewers: nickdesaulniers, aaron.ballman, tstellar.
Herald added a project: All.
serge-sans-paille requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

When an inline builtin declaration is shadowed by an actual declaration, we must
reference the actual declaration, even if it's not the last, following GCC
behavior.

This fixes #54715


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D123308

Files:
  clang/lib/CodeGen/CGExpr.cpp
  clang/test/CodeGen/fread-inline-builtin-late-redecl.c


Index: clang/test/CodeGen/fread-inline-builtin-late-redecl.c
===
--- /dev/null
+++ clang/test/CodeGen/fread-inline-builtin-late-redecl.c
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -triple x86_64 -S -emit-llvm -disable-llvm-passes -o - %s | 
FileCheck %s
+//
+// Verifies that clang-generated *.inline are removed when shadowed by an
+// external definition, even when that definition appears at the end of the
+// file.
+
+// CHECK-NOT: strlen.inline
+
+extern unsigned long strlen(char const *s);
+
+extern __inline __attribute__((__always_inline__)) 
__attribute__((__gnu_inline__)) unsigned long strlen(char const *s) {
+  return 1;
+}
+
+static unsigned long chesterfield(char const *s) {
+  return strlen(s);
+}
+static unsigned long (*_strlen)(char const *ptr);
+
+unsigned long blutch(char const *s) {
+  return chesterfield(s);
+}
+
+unsigned long strlen(char const *s) {
+  return _strlen(s);
+}
Index: clang/lib/CodeGen/CGExpr.cpp
===
--- clang/lib/CodeGen/CGExpr.cpp
+++ clang/lib/CodeGen/CGExpr.cpp
@@ -4948,6 +4948,16 @@
   return EmitCall(E->getCallee()->getType(), Callee, E, ReturnValue);
 }
 
+// Detect the unusual situation where an inline version is shadowed by a
+// non-inline version. In that case we should pick the external one
+// everywhere. That's GCC behavior too.
+static bool OnlyHasInlineBuiltinDeclaration(const FunctionDecl *FD) {
+  for (const FunctionDecl *PD = FD; PD; PD = PD->getPreviousDecl())
+if (!PD->isInlineBuiltinDeclaration())
+  return false;
+  return true;
+}
+
 static CGCallee EmitDirectCallee(CodeGenFunction &CGF, GlobalDecl GD) {
   const FunctionDecl *FD = cast(GD.getDecl());
 
@@ -4955,7 +4965,7 @@
 std::string FDInlineName = (FD->getName() + ".inline").str();
 // When directing calling an inline builtin, call it through it's mangled
 // name to make it clear it's not the actual builtin.
-if (FD->isInlineBuiltinDeclaration() &&
+if (OnlyHasInlineBuiltinDeclaration(FD) &&
 CGF.CurFn->getName() != FDInlineName) {
   llvm::Constant *CalleePtr = EmitFunctionDeclPointer(CGF.CGM, GD);
   llvm::Function *Fn = llvm::cast(CalleePtr);


Index: clang/test/CodeGen/fread-inline-builtin-late-redecl.c
===
--- /dev/null
+++ clang/test/CodeGen/fread-inline-builtin-late-redecl.c
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 -triple x86_64 -S -emit-llvm -disable-llvm-passes -o - %s | FileCheck %s
+//
+// Verifies that clang-generated *.inline are removed when shadowed by an
+// external definition, even when that definition appears at the end of the
+// file.
+
+// CHECK-NOT: strlen.inline
+
+extern unsigned long strlen(char const *s);
+
+extern __inline __attribute__((__always_inline__)) __attribute__((__gnu_inline__)) unsigned long strlen(char const *s) {
+  return 1;
+}
+
+static unsigned long chesterfield(char const *s) {
+  return strlen(s);
+}
+static unsigned long (*_strlen)(char const *ptr);
+
+unsigned long blutch(char const *s) {
+  return chesterfield(s);
+}
+
+unsigned long strlen(char const *s) {
+  return _strlen(s);
+}
Index: clang/lib/CodeGen/CGExpr.cpp
===
--- clang/lib/CodeGen/CGExpr.cpp
+++ clang/lib/CodeGen/CGExpr.cpp
@@ -4948,6 +4948,16 @@
   return EmitCall(E->getCallee()->getType(), Callee, E, ReturnValue);
 }
 
+// Detect the unusual situation where an inline version is shadowed by a
+// non-inline version. In that case we should pick the external one
+// everywhere. That's GCC behavior too.
+static bool OnlyHasInlineBuiltinDeclaration(const FunctionDecl *FD) {
+  for (const FunctionDecl *PD = FD; PD; PD = PD->getPreviousDecl())
+if (!PD->isInlineBuiltinDeclaration())
+  return false;
+  return true;
+}
+
 static CGCallee EmitDirectCallee(CodeGenFunction &CGF, GlobalDecl GD) {
   const FunctionDecl *FD = cast(GD.getDecl());
 
@@ -4955,7 +4965,7 @@
 std::string FDInlineName = (FD->getName() + ".inline").str();
 // When directing calling an inline builtin, call it through it's mangled
 // name to make it clear it's not the actual builtin.
-if (FD->isInlineBuiltinDeclaration() &&
+if (OnlyHasInlineBuiltinDeclaration(FD) &&
 CGF.CurFn->getName(

[PATCH] D123278: [Clang] [Docs] Add HLSLSupport page

2022-04-07 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

Thanks for getting a start on this documentation, I appreciate it!




Comment at: clang/docs/HLSLSupport.rst:11
+
+HLSL Support is a new initiative underway in the Clang codebase. This document
+describes the high level goals of the project, the guiding principals, as well

I can't wait to read "is a new initiative underway" four years from now. :-D 
(We may want to prevent that by making it a less temporal statement.)



Comment at: clang/docs/HLSLSupport.rst:12
+HLSL Support is a new initiative underway in the Clang codebase. This document
+describes the high level goals of the project, the guiding principals, as well
+as some of the idiosyncrasies of the HLSL language and how we intend to support





Comment at: clang/docs/HLSLSupport.rst:19-23
+The long term goal of this project is to enable clang to function as a
+replacement for the `DirectXShaderCompiler (DXC)
+`_. in all its supported
+use cases. Accomplishing that goal will require a high level of source
+compatibility.





Comment at: clang/docs/HLSLSupport.rst:33
+
+Guiding Principals
+==





Comment at: clang/docs/HLSLSupport.rst:46-48
+HLSL support in clang is expressed as C++ minus unsupported C and C++ features.
+This is different from how other clang languages are implemented. Most 
languages
+in Clang are additive on top of C.





Comment at: clang/docs/HLSLSupport.rst:59
+checks on language options where the code is simple and isolated, and prefer
+HLSL-specific implementation files for any code of reasonable complexity.
+

I think it would be good to also mention what happens when HLSL is in conflict 
with either C or C++, at a high level.



Comment at: clang/docs/HLSLSupport.rst:73
+Following the examples of other parser extensions HLSL will add a ParseHLSL.cpp
+file to contain the implementations of HLSL-specific extensions to the clang
+parser.

Probably also worth pointing out that most HLSL parsing is expected to be the 
usual C and C++ code paths, or is that not your expectation?



Comment at: clang/docs/HLSLSupport.rst:121-122
+operators (unary ``*``, and ``->``), as well as the address of operator (unary
+&). While HLSL disallows pointers and references in the syntax, HLSL does use
+reference types in the AST.
+

Presumably it also uses pointer types in the AST for things like array and 
function decay?



Comment at: clang/docs/HLSLSupport.rst:143-145
+In HLSL 2018 and earlier, HLSL supported logical operators (and the ternary
+operator) on vector types. This behavior required that operators not short
+circuit.

It's not clear whether the behavior will vary for all types or just vector 
types. Also, does this apply in preprocessor conditionals the same as runtime 
expressions?



Comment at: clang/docs/HLSLSupport.rst:150-152
+HLSL has a ``precise`` qualifier that behaves unlike anything else in the C
+language. The support for this qualifier in DXC is buggy, so our bar for
+compatibility is low.

Is it worth supporting at all (I know you want source compatibility...)? Type 
system changes are generally expensive and invasive, largely because changing 
the type system in C++ is complicated. For example, does this qualifier impact 
overload sets or template specializations? Does it get name mangled? That sort 
of thing.



Comment at: clang/docs/HLSLSupport.rst:166
+HLSL uses templates to define builtin types and methods, but disallowed
+user-defined templates until HLSL 2021. HLSL also allows omiting empty template
+parameter lists when all template parameters are defaulted. This is an 
ambiguous





Comment at: clang/docs/HLSLSupport.rst:168
+parameter lists when all template parameters are defaulted. This is an 
ambiguous
+syntax in C++, however clang detects the case and issues a diagnostic, so
+supporting it is minimally invasive.





Comment at: clang/docs/HLSLSupport.rst:175
+HLSL uses the OpenCL vector extensions, and also provides C++-style 
constructors
+for vectors that are not supported by clang.
+





Comment at: clang/docs/HLSLSupport.rst:185
+* ``union`` types `(in progress for HLSL 202x) 
`_
+* Most features C11 and later
+

From C99:
VLAs?
_Complex/_Imaginary?

From C11:
Threads/Atomics?
Language features like `_Generic` (or `[[]]` attributes in C2x)?

Also, it's not clear whether you expect these unsupported features to be 
diagnosed or supported as extensions in HLSL, etc.



Comment at

[PATCH] D121637: [PowerPC] Fix EmitPPCBuiltinExpr to emit arguments once

2022-04-07 Thread Nemanja Ivanovic via Phabricator via cfe-commits
nemanjai accepted this revision.
nemanjai added a comment.

Please add a test case that would cause a failure prior to this patch due to 
the argument being emitted more than once (i.e. the test case that prompted 
this patch). If that is already added and I just missed it, please add a note 
to the test case along the lines of:

  // The argument expression must not be emitted multiple times.

Other than the minor nits, LGTM.




Comment at: clang/lib/CodeGen/CGBuiltin.cpp:15627
+Value *Y =
+Builder.CreateAnd(EmitScalarExpr(E->getArg(1)), 
Builder.CreateNot(Op3));
 return Builder.CreateOr(X, Y);

Nit: I understand that we only have one use of `E->getArg(1)`, but might as 
well initialize `Op1` as above just for consistency.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121637

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


[PATCH] D119720: [ARM] Pass for Cortex-A57 and Cortex-A72 Fused AES Erratum

2022-04-07 Thread Sam Elliott via Phabricator via cfe-commits
lenary updated this revision to Diff 421193.
lenary marked 2 inline comments as done.
lenary added a comment.

- Updated set of safe instructions
- Address reviewer feedback, including reordering passes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119720

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Arch/ARM.cpp
  clang/test/Driver/arm-fix-cortex-a57-aes-1742098.c
  llvm/lib/Target/ARM/ARM.h
  llvm/lib/Target/ARM/ARM.td
  llvm/lib/Target/ARM/ARMFixCortexA57AES1742098Pass.cpp
  llvm/lib/Target/ARM/ARMTargetMachine.cpp
  llvm/lib/Target/ARM/CMakeLists.txt
  llvm/test/CodeGen/ARM/O3-pipeline.ll
  llvm/test/CodeGen/ARM/aes-erratum-fix.ll

Index: llvm/test/CodeGen/ARM/aes-erratum-fix.ll
===
--- llvm/test/CodeGen/ARM/aes-erratum-fix.ll
+++ llvm/test/CodeGen/ARM/aes-erratum-fix.ll
@@ -47,6 +47,7 @@
 ; CHECK-FIX-NEXT:push {r4, lr}
 ; CHECK-FIX-NEXT:mov r4, r0
 ; CHECK-FIX-NEXT:bl get_input
+; CHECK-FIX-NEXT:vorr q0, q0, q0
 ; CHECK-FIX-NEXT:vld1.64 {d16, d17}, [r4]
 ; CHECK-FIX-NEXT:aese.8 q0, q8
 ; CHECK-FIX-NEXT:aesmc.8 q8, q0
@@ -67,6 +68,7 @@
 ; CHECK-FIX-NEXT:push {r4, lr}
 ; CHECK-FIX-NEXT:mov r4, r0
 ; CHECK-FIX-NEXT:bl get_inputf16
+; CHECK-FIX-NEXT:vorr q0, q0, q0
 ; CHECK-FIX-NEXT:vld1.64 {d16, d17}, [r4]
 ; CHECK-FIX-NEXT:aese.8 q0, q8
 ; CHECK-FIX-NEXT:aesmc.8 q8, q0
@@ -87,6 +89,7 @@
 ; CHECK-FIX-NEXT:push {r4, lr}
 ; CHECK-FIX-NEXT:mov r4, r0
 ; CHECK-FIX-NEXT:bl get_inputf32
+; CHECK-FIX-NEXT:vorr q0, q0, q0
 ; CHECK-FIX-NEXT:vld1.64 {d16, d17}, [r4]
 ; CHECK-FIX-NEXT:aese.8 q0, q8
 ; CHECK-FIX-NEXT:aesmc.8 q8, q0
@@ -120,6 +123,8 @@
 define arm_aapcs_vfpcc <16 x i8> @aese_once_via_val(<16 x i8> %0, <16 x i8> %1) nounwind {
 ; CHECK-FIX-LABEL: aese_once_via_val:
 ; CHECK-FIX:   @ %bb.0:
+; CHECK-FIX-NEXT:vorr q1, q1, q1
+; CHECK-FIX-NEXT:vorr q0, q0, q0
 ; CHECK-FIX-NEXT:aese.8 q1, q0
 ; CHECK-FIX-NEXT:aesmc.8 q0, q1
 ; CHECK-FIX-NEXT:bx lr
@@ -156,6 +161,9 @@
 define arm_aapcs_vfpcc <16 x i8> @aese_twice_via_val(<16 x i8> %0, <16 x i8> %1) nounwind {
 ; CHECK-FIX-LABEL: aese_twice_via_val:
 ; CHECK-FIX:   @ %bb.0:
+; CHECK-FIX-NEXT:vorr q1, q1, q1
+; CHECK-FIX-NEXT:vorr q0, q0, q0
+; CHECK-FIX-NEXT:vorr q0, q0, q0
 ; CHECK-FIX-NEXT:aese.8 q1, q0
 ; CHECK-FIX-NEXT:aesmc.8 q8, q1
 ; CHECK-FIX-NEXT:aese.8 q8, q0
@@ -219,6 +227,8 @@
 define arm_aapcs_vfpcc <16 x i8> @aese_loop_via_val(i32 %0, <16 x i8> %1, <16 x i8> %2) nounwind {
 ; CHECK-FIX-LABEL: aese_loop_via_val:
 ; CHECK-FIX:   @ %bb.0:
+; CHECK-FIX-NEXT:vorr q1, q1, q1
+; CHECK-FIX-NEXT:vorr q0, q0, q0
 ; CHECK-FIX-NEXT:cmp r0, #0
 ; CHECK-FIX-NEXT:beq .LBB9_2
 ; CHECK-FIX-NEXT:  .LBB9_1: @ =>This Inner Loop Header: Depth=1
@@ -249,6 +259,7 @@
 define arm_aapcs_vfpcc void @aese_set8_via_ptr(i8* %0, <16 x i8> %1, <16 x i8>* %2) nounwind {
 ; CHECK-FIX-NOSCHED-LABEL: aese_set8_via_ptr:
 ; CHECK-FIX-NOSCHED:   @ %bb.0:
+; CHECK-FIX-NOSCHED-NEXT:vorr q0, q0, q0
 ; CHECK-FIX-NOSCHED-NEXT:ldrb r0, [r0]
 ; CHECK-FIX-NOSCHED-NEXT:vld1.64 {d16, d17}, [r1]
 ; CHECK-FIX-NOSCHED-NEXT:vmov.8 d0[0], r0
@@ -260,6 +271,7 @@
 ;
 ; CHECK-CORTEX-FIX-LABEL: aese_set8_via_ptr:
 ; CHECK-CORTEX-FIX:   @ %bb.0:
+; CHECK-CORTEX-FIX-NEXT:vorr q0, q0, q0
 ; CHECK-CORTEX-FIX-NEXT:vld1.64 {d16, d17}, [r1]
 ; CHECK-CORTEX-FIX-NEXT:ldrb r0, [r0]
 ; CHECK-CORTEX-FIX-NEXT:vmov.8 d0[0], r0
@@ -281,6 +293,7 @@
 define arm_aapcs_vfpcc void @aese_set8_via_val(i8 zeroext %0, <16 x i8> %1, <16 x i8>* %2) nounwind {
 ; CHECK-FIX-LABEL: aese_set8_via_val:
 ; CHECK-FIX:   @ %bb.0:
+; CHECK-FIX-NEXT:vorr q0, q0, q0
 ; CHECK-FIX-NEXT:vld1.64 {d16, d17}, [r1]
 ; CHECK-FIX-NEXT:vmov.8 d0[0], r0
 ; CHECK-FIX-NEXT:vmov.8 d16[0], r0
@@ -300,6 +313,7 @@
 define arm_aapcs_vfpcc void @aese_set8_cond_via_ptr(i1 zeroext %0, i8* %1, <16 x i8> %2, <16 x i8>* %3) nounwind {
 ; CHECK-FIX-LABEL: aese_set8_cond_via_ptr:
 ; CHECK-FIX:   @ %bb.0:
+; CHECK-FIX-NEXT:vorr q0, q0, q0
 ; CHECK-FIX-NEXT:cmp r0, #0
 ; CHECK-FIX-NEXT:beq .LBB12_2
 ; CHECK-FIX-NEXT:  @ %bb.1:
@@ -351,6 +365,7 @@
 define arm_aapcs_vfpcc void @aese_set8_cond_via_val(i1 zeroext %0, i8 zeroext %1, <16 x i8> %2, <16 x i8>* %3) nounwind {
 ; CHECK-FIX-LABEL: aese_set8_cond_via_val:
 ; CHECK-FIX:   @ %bb.0:
+; CHECK-FIX-NEXT:vorr q0, q0, q0
 ; CHECK-FIX-NEXT:vld1.64 {d16, d17}, [r2]
 ; CHECK-FIX-NEXT:cmp r0, #0
 ; CHECK-FIX-NEXT:beq .LBB13_2
@@ -380,6 +395,7 @@
 define arm_aapcs_vfpcc void @aese_set8_loop_via_ptr(i32 %0, i8* %1, <16 x i8> %2, <16 x i8>* %3) nounwind {
 ; CHECK-FIX-LABEL: aese_set8_loop_via_ptr:
 ; CHECK-FIX:   @ %bb.0:
+; CHECK-FIX-NEXT:vorr q0, q0, q0
 ; CHECK-FIX-NEXT:ldrb r1, 

[PATCH] D123278: [Clang] [Docs] Add HLSLSupport page

2022-04-07 Thread Thorsten via Phabricator via cfe-commits
tschuett added a comment.

Thanks. I let Aaron go over the details.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123278

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


[PATCH] D123200: [compiler-rt][CMake] Add initial support of target AVR

2022-04-07 Thread Ben Shi via Phabricator via cfe-commits
benshi001 added a comment.

In D123200#3436043 , @aykevl wrote:

> What about chip families other than avr2 (the default)? Some have a different 
> PC pointer size (1-3 bytes, therefore affecting the ABI), some have different 
> instructions, etc.

There are two options `CMAKE_CXX_FLAGS` and `CMAKE_C_FLAGS" can be specified 
when doing cmake compiler-rt, we can specify the instruction set via them.

Since libgcc-avr has unique source code but built into several different 
libgcc.a files with different instruction set, I expect compiler-rt would be 
done in the way.

And of cource this patch just is an initial support, we still need much more 
patches to make it fully functional.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123200

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


[clang] e22a60b - Revert "Reland "[Driver] Default CLANG_DEFAULT_PIE_ON_LINUX to ON"""

2022-04-07 Thread Nico Weber via cfe-commits

Author: Nico Weber
Date: 2022-04-07T10:07:07-04:00
New Revision: e22a60b1c898a760a73417fa225c2fbe0609a69f

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

LOG: Revert "Reland "[Driver] Default CLANG_DEFAULT_PIE_ON_LINUX to ON"""

This reverts commit 2aca33baf15926afe2520a06b1427a9894226fd2.
Broke tests on several bots, see comments on https://reviews.llvm.org/D120305

Added: 


Modified: 
clang/CMakeLists.txt
clang/docs/ReleaseNotes.rst
clang/test/Driver/hip-fpie-option.hip

lldb/test/API/functionalities/tail_call_frames/unambiguous_sequence/TestUnambiguousTailCalls.py
lldb/test/Shell/ObjectFile/ELF/minidebuginfo-set-and-hit-breakpoint.test
llvm/utils/gn/secondary/clang/include/clang/Config/BUILD.gn
utils/bazel/llvm-project-overlay/clang/include/clang/Config/config.h

Removed: 




diff  --git a/clang/CMakeLists.txt b/clang/CMakeLists.txt
index 3a77e7b0c8d60..c0b1a20e8e8a0 100644
--- a/clang/CMakeLists.txt
+++ b/clang/CMakeLists.txt
@@ -245,7 +245,7 @@ set(PPC_LINUX_DEFAULT_IEEELONGDOUBLE OFF CACHE BOOL
 set(CLANG_SPAWN_CC1 OFF CACHE BOOL
 "Whether clang should use a new process for the CC1 invocation")
 
-option(CLANG_DEFAULT_PIE_ON_LINUX "Default to -fPIE and -pie on linux-gnu" ON)
+option(CLANG_DEFAULT_PIE_ON_LINUX "Default to -fPIE and -pie on Linux" OFF)
 
 # Manually handle default so we can change the meaning of a cached default.
 set(CLANG_ENABLE_OPAQUE_POINTERS "DEFAULT" CACHE STRING

diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index a64d9d383d957..df6a7d7539ee6 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -279,12 +279,6 @@ Internal API Changes
 Build System Changes
 
 
-* CMake ``-DCLANG_DEFAULT_PIE_ON_LINUX=ON`` is now the default. This is used by
-  linux-gnu systems to decide whether ``-fPIE -pie`` is the default (instead of
-  ``-fno-pic -no-pie``). This matches GCC installations on many Linux distros.
-  Note: linux-android and linux-musl always default to ``-fPIE -pie``, ignoring
-  this variable. ``-DCLANG_DEFAULT_PIE_ON_LINUX`` may be removed in the future.
-
 AST Matchers
 
 

diff  --git a/clang/test/Driver/hip-fpie-option.hip 
b/clang/test/Driver/hip-fpie-option.hip
index ffd639dd5a6de..2e296a099dea5 100644
--- a/clang/test/Driver/hip-fpie-option.hip
+++ b/clang/test/Driver/hip-fpie-option.hip
@@ -1,15 +1,15 @@
-// REQUIRES: clang-driver, amdgpu-registered-target, default-pie-on-linux
+// REQUIRES: clang-driver, amdgpu-registered-target
 
 // -fPIC and -fPIE only affects host relocation model.
 // device compilation always uses PIC. 
 
 // RUN: %clang -### -target x86_64-unknown-linux-gnu \
 // RUN:   --offload-arch=gfx906 %s -nogpulib -nogpuinc \
-// RUN:   2>&1 | FileCheck -check-prefixes=DEV,HOST-PIE %s
+// RUN:   2>&1 | FileCheck -check-prefixes=DEV,HOST-STATIC %s
 
 // RUN: %clang -### -target x86_64-unknown-linux-gnu \
 // RUN:   -fgpu-rdc --offload-arch=gfx906 %s -nogpulib -nogpuinc \
-// RUN:   2>&1 | FileCheck -check-prefixes=DEV,HOST-PIE %s
+// RUN:   2>&1 | FileCheck -check-prefixes=DEV,HOST-STATIC %s
 
 // RUN: %clang -### -target x86_64-unknown-linux-gnu \
 // RUN:   --offload-arch=gfx906 %s -nogpulib -nogpuinc \
@@ -32,6 +32,7 @@
 // RUN:   2>&1 | FileCheck -check-prefixes=DEV,HOST-PIE %s
 
 // DEV-DAG: {{".*clang.*".* "-triple" "amdgcn-amd-amdhsa".* 
"-mrelocation-model" "pic" "-pic-level" "[1|2]".* "-mframe-pointer=all"}}
+// HOST-STATIC-DAG: {{".*clang.*".* "-triple" "x86_64-unknown-linux-gnu".* 
"-mrelocation-model" "static"}}
 // HOST-PIC-DAG: {{".*clang.*".* "-triple" "x86_64-unknown-linux-gnu".* 
"-mrelocation-model" "pic" "-pic-level" "2"}}
 // HOST-PIC-NOT: "-pic-is-pie"
 // HOST-PIE-DAG: {{".*clang.*".* "-triple" "x86_64-unknown-linux-gnu".* 
"-mrelocation-model" "pic" "-pic-level" "2" "-pic-is-pie"}}

diff  --git 
a/lldb/test/API/functionalities/tail_call_frames/unambiguous_sequence/TestUnambiguousTailCalls.py
 
b/lldb/test/API/functionalities/tail_call_frames/unambiguous_sequence/TestUnambiguousTailCalls.py
index cef500f0e7754..19aad2ab1ec32 100644
--- 
a/lldb/test/API/functionalities/tail_call_frames/unambiguous_sequence/TestUnambiguousTailCalls.py
+++ 
b/lldb/test/API/functionalities/tail_call_frames/unambiguous_sequence/TestUnambiguousTailCalls.py
@@ -2,7 +2,6 @@
 from lldbsuite.test import decorators
 
 decor = [decorators.skipUnlessHasCallSiteInfo,
- decorators.skipIf(archs=['arm'],oslist=["linux"]),
  decorators.skipIf(dwarf_version=['<', '4']),
  decorators.skipIf(compiler="clang", compiler_version=['<', '11.0'])]
 lldbinline.MakeInlineTest(__file__, globals(), name="UnambiguousTailCalls_V5",

diff  --git 
a/lldb/test/Shell/ObjectFile/ELF/minidebuginfo-set-and-hit-breakpoint.test 

[PATCH] D120305: [Driver] Default CLANG_DEFAULT_PIE_ON_LINUX to ON

2022-04-07 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

We're seeing the same problem here 
https://bugs.chromium.org/p/chromium/issues/detail?id=1314297&q=linux_upload_clang&can=2

Reverted in e22a60b1c898a760a73417fa225c2fbe0609a69f 
 for now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120305

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


[clang] b2a7f1c - Remove a few effectively-unused FileEntry APIs. NFC

2022-04-07 Thread Sam McCall via cfe-commits

Author: Sam McCall
Date: 2022-04-07T16:45:47+02:00
New Revision: b2a7f1c3904ede781565c6ed772f155167aa8325

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

LOG: Remove a few effectively-unused FileEntry APIs. NFC

- isValid: FileManager only ever returns valid FileEntries (see next point)

- construction from outside FileManager (both FileEntry and DirectoryEntry).
  It's not possible to create a useful FileEntry this way, there are no setters.
  This was only used in FileEntryTest, added a friend to enable this.
  A real constructor is cleaner but requires larger changes to FileManager.

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

Added: 


Modified: 
clang/include/clang/Basic/DirectoryEntry.h
clang/include/clang/Basic/FileEntry.h
clang/lib/Basic/FileManager.cpp
clang/lib/Frontend/LogDiagnosticPrinter.cpp
clang/lib/Frontend/TextDiagnostic.cpp
clang/unittests/Basic/FileEntryTest.cpp
clang/unittests/Basic/FileManagerTest.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/DirectoryEntry.h 
b/clang/include/clang/Basic/DirectoryEntry.h
index 21565621b80fc..fe18b12769546 100644
--- a/clang/include/clang/Basic/DirectoryEntry.h
+++ b/clang/include/clang/Basic/DirectoryEntry.h
@@ -32,7 +32,11 @@ template  class MapEntryOptionalStorage;
 /// Cached information about one directory (either on disk or in
 /// the virtual file system).
 class DirectoryEntry {
+  DirectoryEntry() = default;
+  DirectoryEntry(const DirectoryEntry &) = delete;
+  DirectoryEntry &operator=(const DirectoryEntry &) = delete;
   friend class FileManager;
+  friend class FileEntryTestHelper;
 
   // FIXME: We should not be storing a directory entry name here.
   StringRef Name; // Name of the directory.

diff  --git a/clang/include/clang/Basic/FileEntry.h 
b/clang/include/clang/Basic/FileEntry.h
index a0a041c7ab3b9..92a67150ba453 100644
--- a/clang/include/clang/Basic/FileEntry.h
+++ b/clang/include/clang/Basic/FileEntry.h
@@ -65,7 +65,6 @@ class FileEntryRef {
   }
   DirectoryEntryRef getDir() const { return *ME->second->Dir; }
 
-  inline bool isValid() const;
   inline off_t getSize() const;
   inline unsigned getUID() const;
   inline const llvm::sys::fs::UniqueID &getUniqueID() const;
@@ -330,6 +329,10 @@ static_assert(
 /// descriptor for the file.
 class FileEntry {
   friend class FileManager;
+  friend class FileEntryTestHelper;
+  FileEntry();
+  FileEntry(const FileEntry &) = delete;
+  FileEntry &operator=(const FileEntry &) = delete;
 
   std::string RealPathName;   // Real path to the file; could be empty.
   off_t Size = 0; // File size in bytes.
@@ -338,7 +341,6 @@ class FileEntry {
   llvm::sys::fs::UniqueID UniqueID;
   unsigned UID = 0; // A unique (small) ID for the file.
   bool IsNamedPipe = false;
-  bool IsValid = false; // Is this \c FileEntry initialized and valid?
 
   /// The open file, if it is owned by the \p FileEntry.
   mutable std::unique_ptr File;
@@ -355,17 +357,11 @@ class FileEntry {
   Optional LastRef;
 
 public:
-  FileEntry();
   ~FileEntry();
-
-  FileEntry(const FileEntry &) = delete;
-  FileEntry &operator=(const FileEntry &) = delete;
-
   StringRef getName() const { return LastRef->getName(); }
   FileEntryRef getLastRef() const { return *LastRef; }
 
   StringRef tryGetRealPathName() const { return RealPathName; }
-  bool isValid() const { return IsValid; }
   off_t getSize() const { return Size; }
   unsigned getUID() const { return UID; }
   const llvm::sys::fs::UniqueID &getUniqueID() const { return UniqueID; }
@@ -381,8 +377,6 @@ class FileEntry {
   void closeFile() const;
 };
 
-bool FileEntryRef::isValid() const { return getFileEntry().isValid(); }
-
 off_t FileEntryRef::getSize() const { return getFileEntry().getSize(); }
 
 unsigned FileEntryRef::getUID() const { return getFileEntry().getUID(); }

diff  --git a/clang/lib/Basic/FileManager.cpp b/clang/lib/Basic/FileManager.cpp
index b955e02f1711e..baabb322482c3 100644
--- a/clang/lib/Basic/FileManager.cpp
+++ b/clang/lib/Basic/FileManager.cpp
@@ -342,7 +342,6 @@ FileManager::getFileRef(StringRef Filename, bool openFile, 
bool CacheFailure) {
   UFE->UniqueID = Status.getUniqueID();
   UFE->IsNamedPipe = Status.getType() == llvm::sys::fs::file_type::fifo_file;
   UFE->File = std::move(F);
-  UFE->IsValid = true;
 
   if (UFE->File) {
 if (auto PathName = UFE->File->getName())
@@ -453,7 +452,6 @@ FileEntryRef FileManager::getVirtualFileRef(StringRef 
Filename, off_t Size,
   UFE->ModTime = ModificationTime;
   UFE->Dir = &DirInfo->getDirEntry();
   UFE->UID = NextFileUID++;
-  UFE->IsValid = true;
   UFE->File.reset();
   return FileEntryRef(NamedFileEnt);
 }
@@ -483,7 +481,6 @@ llvm::Optional 
FileManager::getBypassFile(FileEntryRef VF) {
   

[PATCH] D123197: Remove a few effectively-unused FileEntry APIs. NFC

2022-04-07 Thread Sam McCall 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 rGb2a7f1c3904e: Remove a few effectively-unused FileEntry 
APIs. NFC (authored by sammccall).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123197

Files:
  clang/include/clang/Basic/DirectoryEntry.h
  clang/include/clang/Basic/FileEntry.h
  clang/lib/Basic/FileManager.cpp
  clang/lib/Frontend/LogDiagnosticPrinter.cpp
  clang/lib/Frontend/TextDiagnostic.cpp
  clang/unittests/Basic/FileEntryTest.cpp
  clang/unittests/Basic/FileManagerTest.cpp

Index: clang/unittests/Basic/FileManagerTest.cpp
===
--- clang/unittests/Basic/FileManagerTest.cpp
+++ clang/unittests/Basic/FileManagerTest.cpp
@@ -165,7 +165,6 @@
 
   auto file = manager.getFile("/tmp/test");
   ASSERT_TRUE(file);
-  ASSERT_TRUE((*file)->isValid());
   EXPECT_EQ("/tmp/test", (*file)->getName());
 
   const DirectoryEntry *dir = (*file)->getDir();
@@ -190,7 +189,6 @@
   manager.getVirtualFile("virtual/dir/bar.h", 100, 0);
   auto file = manager.getFile("virtual/dir/bar.h");
   ASSERT_TRUE(file);
-  ASSERT_TRUE((*file)->isValid());
   EXPECT_EQ("virtual/dir/bar.h", (*file)->getName());
 
   const DirectoryEntry *dir = (*file)->getDir();
@@ -212,9 +210,7 @@
   auto fileFoo = manager.getFile("foo.cpp");
   auto fileBar = manager.getFile("bar.cpp");
   ASSERT_TRUE(fileFoo);
-  ASSERT_TRUE((*fileFoo)->isValid());
   ASSERT_TRUE(fileBar);
-  ASSERT_TRUE((*fileBar)->isValid());
   EXPECT_NE(*fileFoo, *fileBar);
 }
 
@@ -341,9 +337,6 @@
   statCache->InjectFile("abc/bar.cpp", 42);
   manager.setStatCache(std::move(statCache));
 
-  ASSERT_TRUE(manager.getVirtualFile("abc/foo.cpp", 100, 0)->isValid());
-  ASSERT_TRUE(manager.getVirtualFile("abc/bar.cpp", 200, 0)->isValid());
-
   auto f1 = manager.getFile("abc/foo.cpp");
   auto f2 = manager.getFile("abc/bar.cpp");
 
@@ -418,14 +411,12 @@
   // Inject the virtual file:
   const FileEntry *file1 = manager.getVirtualFile("c:\\tmp\\test", 123, 1);
   ASSERT_TRUE(file1 != nullptr);
-  ASSERT_TRUE(file1->isValid());
   EXPECT_EQ(43U, file1->getUniqueID().getFile());
   EXPECT_EQ(123, file1->getSize());
 
   // Lookup the virtual file with a different name:
   auto file2 = manager.getFile("c:/tmp/test", 100, 1);
   ASSERT_TRUE(file2);
-  ASSERT_TRUE((*file2)->isValid());
   // Check that it's the same UFE:
   EXPECT_EQ(file1, *file2);
   EXPECT_EQ(43U, (*file2)->getUniqueID().getFile());
@@ -487,7 +478,6 @@
   // Check for real path.
   const FileEntry *file = Manager.getVirtualFile("/tmp/test", 123, 1);
   ASSERT_TRUE(file != nullptr);
-  ASSERT_TRUE(file->isValid());
   SmallString<64> ExpectedResult = CustomWorkingDir;
 
   llvm::sys::path::append(ExpectedResult, "tmp", "test");
@@ -515,7 +505,6 @@
   // Check for real path.
   auto file = Manager.getFile("/tmp/test", /*OpenFile=*/false);
   ASSERT_TRUE(file);
-  ASSERT_TRUE((*file)->isValid());
   SmallString<64> ExpectedResult = CustomWorkingDir;
 
   llvm::sys::path::append(ExpectedResult, "tmp", "test");
@@ -548,7 +537,6 @@
   const FileEntry *File = Manager.getVirtualFile("/tmp/test", /*Size=*/10, 0);
   ASSERT_TRUE(File);
   const FileEntry &FE = *File;
-  EXPECT_TRUE(FE.isValid());
   EXPECT_EQ(FE.getSize(), 10);
 
   // Calling a second time should not affect the UID or size.
@@ -564,7 +552,6 @@
   llvm::Optional BypassRef =
   Manager.getBypassFile(File->getLastRef());
   ASSERT_TRUE(BypassRef);
-  EXPECT_TRUE(BypassRef->isValid());
   EXPECT_EQ("/tmp/test", BypassRef->getName());
 
   // Check that it's different in the right ways.
Index: clang/unittests/Basic/FileEntryTest.cpp
===
--- clang/unittests/Basic/FileEntryTest.cpp
+++ clang/unittests/Basic/FileEntryTest.cpp
@@ -12,25 +12,22 @@
 #include "gtest/gtest.h"
 
 using namespace llvm;
-using namespace clang;
 
-namespace {
-
-using FileMap = StringMap>;
-using DirMap = StringMap>;
+namespace clang {
 
-struct RefMaps {
-  FileMap Files;
-  DirMap Dirs;
+class FileEntryTestHelper {
+  StringMap> Files;
+  StringMap> Dirs;
 
   SmallVector, 5> FEs;
   SmallVector, 5> DEs;
   DirectoryEntryRef DR;
 
-  RefMaps() : DR(addDirectory("dir")) {}
+public:
+  FileEntryTestHelper() : DR(addDirectory("dir")) {}
 
   DirectoryEntryRef addDirectory(StringRef Name) {
-DEs.push_back(std::make_unique());
+DEs.emplace_back(new DirectoryEntry());
 return DirectoryEntryRef(*Dirs.insert({Name, *DEs.back()}).first);
   }
   DirectoryEntryRef addDirectoryAlias(StringRef Name, DirectoryEntryRef Base) {
@@ -40,7 +37,7 @@
   }
 
   FileEntryRef addFile(StringRef Name) {
-FEs.push_back(std::make_unique());
+FEs.emplace_back(new FileEntry());
 return FileEntryRef(
 *Files.insert({Name, FileEntryRef::MapValue(*FEs.back().get(), DR)})
  

[PATCH] D115924: [ConstantFolding] Unify handling of load from uniform value

2022-04-07 Thread Cameron McInally via Phabricator via cfe-commits
cameron.mcinally added inline comments.



Comment at: llvm/lib/Analysis/ConstantFolding.cpp:722
+  (Ty->isIntOrIntVectorTy() || Ty->isFPOrFPVectorTy()))
+return Constant::getAllOnesValue(Ty);
+  return nullptr;

nikic wrote:
> cameron.mcinally wrote:
> > Sorry for the late comment, but is this legal to do if the src and dest 
> > types are different sizes? E.g.:
> > 
> > ```
> > %xxx_cast = bitcast i8* %xxx to i1*
> > store i1 true, i1* %xxx_cast
> > %yyy = load i8, i8* %xxx
> > ```
> > 
> > In this case, we'll be turning an i1 -1 into an i8 -1, which changes bits.
> This code assumes that the loaded type is either smaller or that loading a 
> larger type fills in the remaining bits with poison, so we can use any value 
> for them. The caller is responsible for doing a type size check if necessary.
> 
> However, I don't believe that non-byte-sized types were really considered 
> either here or in other parts of the constant load folding code. In that case 
> the type store sizes are the same, but the type sizes differ.
> 
> Now, as to whether this behavior is actually incorrect, LangRef has the 
> following to say on non-byte-sized memory accesses:
> 
> > When writing a value of a type like i20 with a size that is not an integral 
> > number of bytes, it is unspecified what happens to the extra bits that do 
> > not belong to the type, but they will typically be overwritten.
> 
> > When loading a value of a type like i20 with a size that is not an integral 
> > number of bytes, the result is undefined if the value was not originally 
> > written using a store of the same type.
> 
> Based on a strict reading, I believe the store of i1 and load of i8 would 
> result in the remaining bits having an unspecified, but generally non-poison 
> value. The reverse would be UB (which really doesn't make sense to me -- it 
> would be great if we could rework this to be more well-defined.)
> 
> So, yeah, I'd say this is a bug. I'll take a look.
Thanks, Nikita.

Looking at the LangRef language, I suspect that you're correct here:

```
Based on a strict reading, I believe the store of i1 and load of i8 would 
result in the remaining bits having an unspecified, but generally non-poison 
value. 
```

Requiring the IR producer to maintain those unspecified bits is an acceptable 
answer. ;)

I wish LangRef took the responsibility of maintaining the unspecified i1/i4 
bits off of the IR producer, since they're so common in predication, but I also 
understand the access instruction limitations as well. It's an unfortunate 
situation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115924

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


[PATCH] D123313: [OpenMP] Make clang argument handling for the new driver more generic

2022-04-07 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 created this revision.
jhuber6 added reviewers: jdoerfert, JonChesterfield.
Herald added subscribers: guansong, yaxunl.
Herald added a project: All.
jhuber6 requested review of this revision.
Herald added subscribers: cfe-commits, sstefan1, MaskRay.
Herald added a project: clang.

In preparation for accepting other offloading kinds with the new driver,
this patch makes the way we handle offloading actions more generic. A
new field to get the associated device action's toolchain is used rather
than manually iterating a list. This makes building the arguments easier
and makes sure that we doin't rely on any implicit ordering.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D123313

Files:
  clang/include/clang/Driver/Action.h
  clang/lib/Driver/Action.cpp
  clang/lib/Driver/ToolChains/Clang.cpp

Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4389,11 +4389,13 @@
   bool IsHIP = JA.isOffloading(Action::OFK_HIP);
   bool IsHIPDevice = JA.isDeviceOffloading(Action::OFK_HIP);
   bool IsOpenMPDevice = JA.isDeviceOffloading(Action::OFK_OpenMP);
-  bool IsOpenMPHost = JA.isHostOffloading(Action::OFK_OpenMP);
   bool IsHeaderModulePrecompile = isa(JA);
   bool IsExtractAPI = isa(JA);
   bool IsDeviceOffloadAction = !(JA.isDeviceOffloading(Action::OFK_None) ||
  JA.isDeviceOffloading(Action::OFK_Host));
+  bool IsHostOffloadingAction =
+  JA.isHostOffloading(C.getActiveOffloadKinds()) &&
+  Args.hasArg(options::OPT_fopenmp_new_driver);
   bool IsUsingLTO = D.isUsingLTO(IsDeviceOffloadAction);
   auto LTOMode = D.getLTOMode(IsDeviceOffloadAction);
 
@@ -4420,7 +4422,7 @@
 
   InputInfoList ModuleHeaderInputs;
   InputInfoList ExtractAPIInputs;
-  InputInfoList OpenMPHostInputs;
+  InputInfoList HostOffloadingInputs;
   const InputInfo *CudaDeviceInput = nullptr;
   const InputInfo *OpenMPDeviceInput = nullptr;
   for (const InputInfo &I : Inputs) {
@@ -4443,12 +4445,12 @@
 << types::getTypeName(ExpectedInputType);
   }
   ExtractAPIInputs.push_back(I);
+} else if (IsHostOffloadingAction) {
+  HostOffloadingInputs.push_back(I);
 } else if ((IsCuda || IsHIP) && !CudaDeviceInput) {
   CudaDeviceInput = &I;
 } else if (IsOpenMPDevice && !OpenMPDeviceInput) {
   OpenMPDeviceInput = &I;
-} else if (IsOpenMPHost) {
-  OpenMPHostInputs.push_back(I);
 } else {
   llvm_unreachable("unexpectedly given multiple inputs");
 }
@@ -6974,25 +6976,24 @@
 }
   }
 
-  // Host-side OpenMP offloading recieves the device object files and embeds it
-  // in a named section including the associated target triple and architecture.
-  if (IsOpenMPHost && !OpenMPHostInputs.empty()) {
-auto InputFile = OpenMPHostInputs.begin();
-auto OpenMPTCs = C.getOffloadToolChains();
-for (auto TI = OpenMPTCs.first, TE = OpenMPTCs.second; TI != TE;
- ++TI, ++InputFile) {
-  const ToolChain *TC = TI->second;
-  const ArgList &TCArgs = C.getArgsForToolChain(TC, "", Action::OFK_OpenMP);
-  StringRef File =
-  C.getArgs().MakeArgString(TC->getInputFilename(*InputFile));
-  StringRef InputName = Clang::getBaseInputStem(Args, Inputs);
+  // Host-side offloading recieves the device object files and embeds it in a
+  // named section including the associated target triple and architecture.
+  for (const InputInfo Input : HostOffloadingInputs) {
+const Action *OffloadAction = Input.getAction();
+const ToolChain *TC = OffloadAction->getOffloadingToolChain();
+const ArgList &TCArgs =
+C.getArgsForToolChain(TC, OffloadAction->getOffloadingArch(),
+  OffloadAction->getOffloadingDeviceKind());
+StringRef File = C.getArgs().MakeArgString(TC->getInputFilename(Input));
+StringRef InputName = Clang::getBaseInputStem(Args, Inputs);
+StringRef Arch = (OffloadAction->getOffloadingArch())
+ ? OffloadAction->getOffloadingArch()
+ : TCArgs.getLastArgValue(options::OPT_march_EQ);
 
-  CmdArgs.push_back(Args.MakeArgString(
-  "-fembed-offload-object=" + File + "," +
-  Action::GetOffloadKindName(Action::OFK_OpenMP) + "." +
-  TC->getTripleString() + "." +
-  TCArgs.getLastArgValue(options::OPT_march_EQ) + "." + InputName));
-}
+CmdArgs.push_back(Args.MakeArgString(
+"-fembed-offload-object=" + File + "," +
+Action::GetOffloadKindName(OffloadAction->getOffloadingDeviceKind()) +
+"." + TC->getTripleString() + "." + Arch + "." + InputName));
   }
 
   if (Triple.isAMDGPU()) {
Index: clang/lib/Driver/Action.cpp
===
--- clang/lib/Driver/Action.cpp
+++ clang/lib/Driver/Action.cpp
@@ -54,7 +54,8 @@
   llvm_unreachable("invalid clas

[PATCH] D123026: [clang][NFC] Extract EmitAssemblyHelper::shouldEmitRegularLTOSummary

2022-04-07 Thread Pavel Samolysov via Phabricator via cfe-commits
psamolysov-intel marked an inline comment as done.
psamolysov-intel added a comment.

Colleagues, could you help me with landing? @tejohnson has approved the patch 
(if I applied the suggestion as it was expected, thank you @tejohnson!)


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

https://reviews.llvm.org/D123026

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


[PATCH] D123229: [clang][deps] Ensure deterministic file names on case-insensitive filesystems

2022-04-07 Thread Jan Svoboda via Phabricator via cfe-commits
jansvoboda11 updated this revision to Diff 421221.
jansvoboda11 added a comment.

Windows path separators...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123229

Files:
  clang/include/clang/Lex/DirectoryLookup.h
  clang/lib/Lex/HeaderSearch.cpp
  clang/test/ClangScanDeps/header-search-case-sensitivity.c


Index: clang/test/ClangScanDeps/header-search-case-sensitivity.c
===
--- /dev/null
+++ clang/test/ClangScanDeps/header-search-case-sensitivity.c
@@ -0,0 +1,50 @@
+// This test checks that reusing FileManager produces deterministic results on 
case-insensitive filesystems.
+
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+
+//--- dir1/arm/lower.h
+//--- dir2/ARM/upper.h
+//--- t1.c
+#include "upper.h"
+//--- t2.c
+#include "arm/lower.h"
+
+//--- cdb.json.template
+[{
+  "directory": "DIR",
+  "command": "clang -fsyntax-only DIR/t1.c -I DIR/dir2/ARM -I DIR/dir1",
+  "file": "DIR/t1.c"
+},{
+  "directory": "DIR",
+  "command": "clang -fsyntax-only DIR/t2.c -I DIR/dir2 -I DIR/dir1",
+  "file": "DIR/t2.c"
+}]
+
+//--- cdb-rev.json.template
+[{
+  "directory": "DIR",
+  "command": "clang -fsyntax-only DIR/t2.c -I DIR/dir2 -I DIR/dir1",
+  "file": "DIR/t2.c"
+},{
+  "directory": "DIR",
+  "command": "clang -fsyntax-only DIR/t1.c -I DIR/dir2/ARM -I DIR/dir1",
+  "file": "DIR/t1.c"
+}]
+
+// RUN: sed -e "s|DIR|%/t|g" %t/cdb.json.template > %t/cdb.json
+// RUN: sed -e "s|DIR|%/t|g" %t/cdb-rev.json.template > %t/cdb-rev.json
+
+// RUN: clang-scan-deps -compilation-database=%t/cdb.json -format make -j 
1 | sed 's:\?:/:g' | FileCheck %s
+
+// In the reversed case, Clang starts by scanning "t2.c". When looking up the 
"arm/lower.h" header,
+// the string is appended to "DIR/dir2". That file ("DIR/dir2/arm/lower.h") 
doesn't exist, but when
+// learning so, the FileManager stats and caches the parent directory 
("DIR/dir2/arm"), using the
+// UID as the key.
+// When scanning "t1.c" later on, the "DIR/dir2/ARM" search directory is 
assigned the **same**
+// directory entry (with lowercase "arm"), since they share the UID on 
case-insensitive filesystems.
+// To preserve the correct case throughout the compiler for any file within 
that directory, it's
+// important to use the spelling actually used, not just the cached one.
+// RUN: clang-scan-deps -compilation-database=%t/cdb-rev.json -format make -j 
1 | sed 's:\?:/:g' | FileCheck %s
+
+// CHECK: ARM/upper.h
Index: clang/lib/Lex/HeaderSearch.cpp
===
--- clang/lib/Lex/HeaderSearch.cpp
+++ clang/lib/Lex/HeaderSearch.cpp
@@ -436,10 +436,10 @@
   SmallString<1024> TmpDir;
   if (isNormalDir()) {
 // Concatenate the requested file onto the directory.
-TmpDir = getDir()->getName();
+TmpDir = getDirRef()->getName();
 llvm::sys::path::append(TmpDir, Filename);
 if (SearchPath) {
-  StringRef SearchPathRef(getDir()->getName());
+  StringRef SearchPathRef(getDirRef()->getName());
   SearchPath->clear();
   SearchPath->append(SearchPathRef.begin(), SearchPathRef.end());
 }
Index: clang/include/clang/Lex/DirectoryLookup.h
===
--- clang/include/clang/Lex/DirectoryLookup.h
+++ clang/include/clang/Lex/DirectoryLookup.h
@@ -91,6 +91,10 @@
 return isNormalDir() ? &u.Dir.getDirEntry() : nullptr;
   }
 
+  Optional getDirRef() const {
+return isNormalDir() ? Optional(u.Dir) : None;
+  }
+
   /// getFrameworkDir - Return the directory that this framework refers to.
   ///
   const DirectoryEntry *getFrameworkDir() const {


Index: clang/test/ClangScanDeps/header-search-case-sensitivity.c
===
--- /dev/null
+++ clang/test/ClangScanDeps/header-search-case-sensitivity.c
@@ -0,0 +1,50 @@
+// This test checks that reusing FileManager produces deterministic results on case-insensitive filesystems.
+
+// RUN: rm -rf %t
+// RUN: split-file %s %t
+
+//--- dir1/arm/lower.h
+//--- dir2/ARM/upper.h
+//--- t1.c
+#include "upper.h"
+//--- t2.c
+#include "arm/lower.h"
+
+//--- cdb.json.template
+[{
+  "directory": "DIR",
+  "command": "clang -fsyntax-only DIR/t1.c -I DIR/dir2/ARM -I DIR/dir1",
+  "file": "DIR/t1.c"
+},{
+  "directory": "DIR",
+  "command": "clang -fsyntax-only DIR/t2.c -I DIR/dir2 -I DIR/dir1",
+  "file": "DIR/t2.c"
+}]
+
+//--- cdb-rev.json.template
+[{
+  "directory": "DIR",
+  "command": "clang -fsyntax-only DIR/t2.c -I DIR/dir2 -I DIR/dir1",
+  "file": "DIR/t2.c"
+},{
+  "directory": "DIR",
+  "command": "clang -fsyntax-only DIR/t1.c -I DIR/dir2/ARM -I DIR/dir1",
+  "file": "DIR/t1.c"
+}]
+
+// RUN: sed -e "s|DIR|%/t|g" %t/cdb.json.template > %t/cdb.json
+// RUN: sed -e "s|DIR|%/t|g" %t/cdb-rev.json.template > %t/cdb-rev.json
+
+// RUN: clang-scan-deps -compilati

[PATCH] D123297: [flang][driver] Add support for -mmlir

2022-04-07 Thread Andrzej Warzynski via Phabricator via cfe-commits
awarzynski updated this revision to Diff 421223.
awarzynski added a comment.

Make sure the MLIR CL options are "applied"


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123297

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Flang.cpp
  flang/include/flang/Frontend/FrontendOptions.h
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/Frontend/FrontendActions.cpp
  flang/lib/FrontendTool/CMakeLists.txt
  flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
  flang/test/Driver/driver-help-hidden.f90
  flang/test/Driver/driver-help.f90
  flang/test/Driver/mllvm_vs_mmlir.f90

Index: flang/test/Driver/mllvm_vs_mmlir.f90
===
--- /dev/null
+++ flang/test/Driver/mllvm_vs_mmlir.f90
@@ -0,0 +1,18 @@
+! Verify that `-mllvm` options are forwarded to LLVM and `-mmlir` to MLIR
+
+!
+! RUN COMMAND
+!
+! RUN: %flang_fc1  -mmlir --help | FileCheck %s --check-prefix=MLIR
+! RUN: %flang_fc1  -mllvm --help | FileCheck %s --check-prefix=MLLVM
+
+!
+! EXPECTED OUTPUT
+!
+! MLIR: flang (MLIR option parsing) [options]
+! MLIR: --mlir-{{.*}}
+! MLIR-NOT: --mir-strip-debugify-only
+
+! MLLVM: flang (LLVM option parsing) [options]
+! MLLVM: --mir-strip-debugify-only
+! MLLVM-NOT: --mlir-{{.*}}
Index: flang/test/Driver/driver-help.f90
===
--- flang/test/Driver/driver-help.f90
+++ flang/test/Driver/driver-help.f90
@@ -48,6 +48,7 @@
 ! HELP-NEXT: -help  Display available options
 ! HELP-NEXT: -IAdd directory to the end of the list of include search paths
 ! HELP-NEXT: -mllvm  Additional arguments to forward to LLVM's option processing
+! HELP-NEXT: -mmlir  Additional arguments to forward to MLIR's option processing
 ! HELP-NEXT: -module-dir   Put MODULE files in 
 ! HELP-NEXT: -nocpp Disable predefined and command line preprocessor macros
 ! HELP-NEXT: -o   Write output to 
@@ -123,6 +124,7 @@
 ! HELP-FC1-NEXT: -IAdd directory to the end of the list of include search paths
 ! HELP-FC1-NEXT: -load Load the named plugin (dynamic shared object)
 ! HELP-FC1-NEXT: -mllvm  Additional arguments to forward to LLVM's option processing
+! HELP-FC1-NEXT: -mmlir  Additional arguments to forward to MLIR's option processing
 ! HELP-FC1-NEXT: -module-dir   Put MODULE files in 
 ! HELP-FC1-NEXT: -module-suffix  Use  as the suffix for module files (the default value is `.mod`)
 ! HELP-FC1-NEXT: -nocpp Disable predefined and command line preprocessor macros
Index: flang/test/Driver/driver-help-hidden.f90
===
--- flang/test/Driver/driver-help-hidden.f90
+++ flang/test/Driver/driver-help-hidden.f90
@@ -48,6 +48,7 @@
 ! CHECK-NEXT: -help Display available options
 ! CHECK-NEXT: -IAdd directory to the end of the list of include search paths
 ! CHECK-NEXT: -mllvm  Additional arguments to forward to LLVM's option processing
+! CHECK-NEXT: -mmlir  Additional arguments to forward to MLIR's option processing
 ! CHECK-NEXT: -module-dir   Put MODULE files in 
 ! CHECK-NEXT: -nocpp Disable predefined and command line preprocessor macros
 ! CHECK-NEXT: -o  Write output to 
Index: flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
===
--- flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
+++ flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
@@ -11,6 +11,8 @@
 //
 //===--===//
 
+#include "mlir/IR/MLIRContext.h"
+#include "mlir/Pass/PassManager.h"
 #include "flang/Frontend/CompilerInstance.h"
 #include "flang/Frontend/FrontendActions.h"
 #include "flang/Frontend/FrontendPluginRegistry.h"
@@ -148,6 +150,21 @@
 llvm::cl::ParseCommandLineOptions(numArgs + 1, args.get());
   }
 
+  // Honor -mmlir. This should happen AFTER plugins have been loaded!
+  if (!flang->frontendOpts().mlirArgs.empty()) {
+mlir::registerMLIRContextCLOptions();
+mlir::registerPassManagerCLOptions();
+unsigned numArgs = flang->frontendOpts().mlirArgs.size();
+auto args = std::make_unique(numArgs + 2);
+args[0] = "flang (MLIR option parsing)";
+
+for (unsigned i = 0; i != numArgs; ++i)
+  args[i + 1] = flang->frontendOpts().mlirArgs[i].c_str();
+
+args[numArgs + 1] = nullptr;
+llvm::cl::ParseCommandLineOptions(numArgs + 1, args.get());
+  }
+
   // If there were errors in processing arguments, don't do anything else.
   if (flang->diagnostics().hasErrorOccurred()) {
 return false;
Index: flang/lib/FrontendTool/CMakeLists.txt
=

[PATCH] D105142: RFC: Implementing new mechanism for hard register operands to inline asm as a constraint.

2022-04-07 Thread James Y Knight via Phabricator via cfe-commits
jyknight added a comment.
Herald added a subscriber: StephenFan.
Herald added a project: All.

What's the status of this? Did the GCC proposal go anywhere? I'd be happy to 
see this move forward if you're also pushing it on the GCC side.




Comment at: clang/lib/CodeGen/CGStmt.cpp:2077
+  // which one to emit.
+  // FIXME: Should we add one additional level of granulariy, where the 
compiler
+  // can forgive the user, if they mention the same register to be used through

I don't think the FIXME seems useful. I don't see any reason why anyone should 
validly use both at the same time.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105142

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


[PATCH] D123026: [clang][NFC] Extract EmitAssemblyHelper::shouldEmitRegularLTOSummary

2022-04-07 Thread Teresa Johnson via Phabricator via cfe-commits
tejohnson added a comment.

In D123026#3436323 , 
@psamolysov-intel wrote:

> Colleagues, could you help me with landing? @tejohnson has approved the patch 
> (if I applied the suggestion as it was expected, thank you @tejohnson!)

lgtm. I can commit for you today.


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

https://reviews.llvm.org/D123026

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


[PATCH] D123297: [flang][driver] Add support for -mmlir

2022-04-07 Thread River Riddle via Phabricator via cfe-commits
rriddle added inline comments.



Comment at: flang/test/Driver/mllvm_vs_mmlir.f90:17
+! MLLVM: flang (LLVM option parsing) [options]
+! MLLVM: --print-ir-after-all
+! MLLVM-NOT: --mlir-{{.*}}

awarzynski wrote:
> awarzynski wrote:
> > rovka wrote:
> > > rovka wrote:
> > > > Is this the most llvm-ish option we have? I'm concerned that MLIR might 
> > > > also decide to add an option that sounds like this (and for sure 
> > > > -print-ir-before-all is mentioned in the [[ 
> > > > https://mlir.llvm.org/getting_started/Debugging/ |  MLIR docs ]]).
> > > > Is this the most llvm-ish option we have? I'm concerned that MLIR might 
> > > > also decide to add an option that sounds like this (and for sure 
> > > > -print-ir-before-all is mentioned in the [[ 
> > > > https://mlir.llvm.org/getting_started/Debugging/ |  MLIR docs ]]).
> > > 
> > > Right, I think that might be why the premerge tests are failing...
> > > Is this the most llvm-ish option we have? 
> > 
> > Sadly, most LLVM options have rather generic names that could at some point 
> > be added in MLIR. Perhaps you'll spot something more suitable:
> > 
> > ```lang=bash
> > USAGE: flang (LLVM option parsing) [options]
> > 
> > OPTIONS:
> > 
> > Color Options:
> > 
> >   --color   - Use colors in output 
> > (default=autodetect)
> > 
> > General options:
> > 
> >   --aarch64-neon-syntax= - Choose style of NEON 
> > code to emit from AArch64 backend:
> > =generic-   Emit generic NEON 
> > assembly
> > =apple  -   Emit Apple-style 
> > NEON assembly
> >   --aarch64-use-aa  - Enable the use of AA 
> > during codegen.
> >   --abort-on-max-devirt-iterations-reached  - Abort when the max 
> > iterations for devirtualization CGSCC repeat pass is reached
> >   --allow-ginsert-as-artifact   - Allow G_INSERT to be 
> > considered an artifact. Hack around AMDGPU test infinite loops.
> >   --always-execute-loop-body- force the body of a 
> > loop to execute at least once
> >   --array-constructor-initial-buffer-size=- set the incremental 
> > array construction buffer size (default=32)
> >   --cfg-hide-cold-paths=- Hide blocks with 
> > relative frequency below the given value
> >   --cfg-hide-deoptimize-paths   -
> >   --cfg-hide-unreachable-paths  -
> >   --cost-kind=   - Target cost kind
> > =throughput -   Reciprocal 
> > throughput
> > =latency-   Instruction latency
> > =code-size  -   Code size
> > =size-latency   -   Code size and 
> > latency
> >   --debugify-level=  - Kind of debug info to 
> > add
> > =locations  -   Locations only
> > =location+variables -   Locations and 
> > Variables
> >   --debugify-quiet  - Suppress verbose 
> > debugify output
> >   --default-kinds= - string to set default 
> > kind values
> >   --disable-i2p-p2i-opt - Disables 
> > inttoptr/ptrtoint roundtrip optimization
> >   --dot-cfg-mssa= - file name for 
> > generated dot file
> >   --enable-cse-in-irtranslator  - Should enable CSE in 
> > irtranslator
> >   --enable-cse-in-legalizer - Should enable CSE in 
> > Legalizer
> >   --enable-gvn-memdep   -
> >   --enable-load-in-loop-pre -
> >   --enable-load-pre -
> >   --enable-loop-simplifycfg-term-folding-
> >   --enable-name-compression - Enable name/filename 
> > string compression
> >   --enable-split-backedge-in-load-pre   -
> >   --experimental-debug-variable-locations   - Use experimental new 
> > value-tracking variable locations
> >   --fdebug-dump-pre-fir - dump the Pre-FIR tree 
> > prior to FIR generation
> >   --fs-profile-debug-bw-threshold=- Only show debug 
> > message if the source branch weight is greater  than this value.
> >   --fs-profile-debug-prob-diff-threshold= - Only show debug 
> > message if the branch probility is greater than this value (in percentage).
> >   --gen-array-coor  - in lowering create 
> > ArrayCoorOp instead of CoordinateOp
> >   --generate-merged-base-profiles   - When generating 
> > nested context-sensitive profiles, always generate extra base profile for 
> > function with all its context profiles merged into it.
> >   --inline-all   

[PATCH] D119136: [clang] Implement Change scope of lambda trailing-return-type

2022-04-07 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin updated this revision to Diff 421227.
cor3ntin marked 4 inline comments as done.
cor3ntin added a comment.

Address ChuanqiXu's feedback


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119136

Files:
  clang/include/clang/AST/DeclCXX.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Scope.h
  clang/include/clang/Sema/ScopeInfo.h
  clang/include/clang/Sema/Sema.h
  clang/lib/Parse/ParseExprCXX.cpp
  clang/lib/Sema/Scope.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaCXXScopeSpec.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaLambda.cpp
  clang/lib/Sema/TreeTransform.h
  clang/test/CXX/expr/expr.prim/expr.prim.lambda/p11-1y.cpp
  clang/test/SemaCXX/lambda-capture-type-deduction.cpp
  clang/test/SemaCXX/warn-shadow-in-lambdas.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -1356,7 +1356,7 @@
 
   Change scope of lambda trailing-return-type
   https://wg21.link/P2036R3";>P2036R3
-  No
+  Clang 15
 
 
   Multidimensional subscript operator
Index: clang/test/SemaCXX/warn-shadow-in-lambdas.cpp
===
--- clang/test/SemaCXX/warn-shadow-in-lambdas.cpp
+++ clang/test/SemaCXX/warn-shadow-in-lambdas.cpp
@@ -95,7 +95,7 @@
 #ifdef AVOID
   auto l4 = [var = param] (int param) { ; }; // no warning
 #else
-  auto l4 = [var = param] (int param) { ; }; // expected-warning {{declaration shadows a local variable}}
+  auto l4 = [var = param](int param) { ; }; // expected-warning 2{{declaration shadows a local variable}}
 #endif
 
   // Make sure that inner lambdas work as well.
Index: clang/test/SemaCXX/lambda-capture-type-deduction.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/lambda-capture-type-deduction.cpp
@@ -0,0 +1,132 @@
+// RUN: %clang_cc1 -std=c++2b -verify -fsyntax-only %s
+
+template 
+constexpr bool is_same = false;
+
+template 
+constexpr bool is_same = true;
+
+void f() {
+
+  int y;
+
+  static_assert(is_same decltype((x)) { return x; }())>);
+
+  static_assert(is_same decltype((x)) { return x; }())>);
+
+  static_assert(is_same decltype((y)) { return y; }())>);
+
+  static_assert(is_same decltype((y)) { return y; }())>);
+
+  static_assert(is_same decltype((y)) { return y; }())>);
+
+  static_assert(is_same decltype((y)) { return y; }())>);
+
+  auto ref = [&x = y](
+ decltype([&](decltype(x)) { return 0; }) y) {
+return x;
+  };
+}
+
+void test_noexcept() {
+
+  int y;
+
+  static_assert(noexcept([x = 1] noexcept(is_same) {}()));
+  static_assert(noexcept([x = 1] mutable noexcept(is_same) {}()));
+  static_assert(noexcept([y] noexcept(is_same) {}()));
+  static_assert(noexcept([y] mutable noexcept(is_same) {}()));
+  static_assert(noexcept([=] noexcept(is_same) {}()));
+  static_assert(noexcept([=] mutable noexcept(is_same) {}()));
+  static_assert(noexcept([&] noexcept(is_same) {}()));
+  static_assert(noexcept([&] mutable noexcept(is_same) {}()));
+
+  static_assert(noexcept([&] mutable noexcept(!is_same) {}())); //expected-error {{static_assert failed due}}
+}
+
+void test_requires() {
+
+  int x;
+
+  [x = 1]() requires is_same {}
+  ();
+  [x = 1]() mutable requires is_same {}
+  ();
+  [x]() requires is_same {}
+  ();
+  [x]() mutable requires is_same {}
+  ();
+  [=]() requires is_same {}
+  ();
+  [=]() mutable requires is_same {}
+  ();
+  [&]() requires is_same {}
+  ();
+  [&]() mutable requires is_same {}
+  ();
+  [&x]() requires is_same {}
+  ();
+  [&x]() mutable requires is_same {}
+  ();
+
+  [x = 1]() requires is_same {} (); //expected-error {{no matching function for call to object of type}} \
+   // expected-note {{candidate function not viable}} \
+   // expected-note {{'is_same' evaluated to false}}
+  [x = 1]() mutable requires is_same {} (); // expected-error {{no matching function for call to object of type}} \
+ // expected-note {{candidate function not viable}} \
+ // expected-note {{'is_same' evaluated to false}}
+}
+
+void err() {
+  int y, z;// expected-note 2{{declared here}}
+  auto implicit_tpl = [=]( // expected-note {{variable 'y' is captured here}}
+  decltype(
+  [&] { return 0; }) y) { //expected-error{{captured variable 'y' cannot appear}}
+return y;
+  };
+
+  auto init_tpl = [x = 1](  // expected-note{

[PATCH] D119136: [clang] Implement Change scope of lambda trailing-return-type

2022-04-07 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin updated this revision to Diff 421228.
cor3ntin added a comment.

Formatting.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119136

Files:
  clang/include/clang/AST/DeclCXX.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Scope.h
  clang/include/clang/Sema/ScopeInfo.h
  clang/include/clang/Sema/Sema.h
  clang/lib/Parse/ParseExprCXX.cpp
  clang/lib/Sema/Scope.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaCXXScopeSpec.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaLambda.cpp
  clang/lib/Sema/TreeTransform.h
  clang/test/CXX/expr/expr.prim/expr.prim.lambda/p11-1y.cpp
  clang/test/SemaCXX/lambda-capture-type-deduction.cpp
  clang/test/SemaCXX/warn-shadow-in-lambdas.cpp
  clang/www/cxx_status.html

Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -1356,7 +1356,7 @@
 
   Change scope of lambda trailing-return-type
   https://wg21.link/P2036R3";>P2036R3
-  No
+  Clang 15
 
 
   Multidimensional subscript operator
Index: clang/test/SemaCXX/warn-shadow-in-lambdas.cpp
===
--- clang/test/SemaCXX/warn-shadow-in-lambdas.cpp
+++ clang/test/SemaCXX/warn-shadow-in-lambdas.cpp
@@ -95,7 +95,7 @@
 #ifdef AVOID
   auto l4 = [var = param] (int param) { ; }; // no warning
 #else
-  auto l4 = [var = param] (int param) { ; }; // expected-warning {{declaration shadows a local variable}}
+  auto l4 = [var = param](int param) { ; }; // expected-warning 2{{declaration shadows a local variable}}
 #endif
 
   // Make sure that inner lambdas work as well.
Index: clang/test/SemaCXX/lambda-capture-type-deduction.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/lambda-capture-type-deduction.cpp
@@ -0,0 +1,132 @@
+// RUN: %clang_cc1 -std=c++2b -verify -fsyntax-only %s
+
+template 
+constexpr bool is_same = false;
+
+template 
+constexpr bool is_same = true;
+
+void f() {
+
+  int y;
+
+  static_assert(is_same decltype((x)) { return x; }())>);
+
+  static_assert(is_same decltype((x)) { return x; }())>);
+
+  static_assert(is_same decltype((y)) { return y; }())>);
+
+  static_assert(is_same decltype((y)) { return y; }())>);
+
+  static_assert(is_same decltype((y)) { return y; }())>);
+
+  static_assert(is_same decltype((y)) { return y; }())>);
+
+  auto ref = [&x = y](
+ decltype([&](decltype(x)) { return 0; }) y) {
+return x;
+  };
+}
+
+void test_noexcept() {
+
+  int y;
+
+  static_assert(noexcept([x = 1] noexcept(is_same) {}()));
+  static_assert(noexcept([x = 1] mutable noexcept(is_same) {}()));
+  static_assert(noexcept([y] noexcept(is_same) {}()));
+  static_assert(noexcept([y] mutable noexcept(is_same) {}()));
+  static_assert(noexcept([=] noexcept(is_same) {}()));
+  static_assert(noexcept([=] mutable noexcept(is_same) {}()));
+  static_assert(noexcept([&] noexcept(is_same) {}()));
+  static_assert(noexcept([&] mutable noexcept(is_same) {}()));
+
+  static_assert(noexcept([&] mutable noexcept(!is_same) {}())); //expected-error {{static_assert failed due}}
+}
+
+void test_requires() {
+
+  int x;
+
+  [x = 1]() requires is_same {}
+  ();
+  [x = 1]() mutable requires is_same {}
+  ();
+  [x]() requires is_same {}
+  ();
+  [x]() mutable requires is_same {}
+  ();
+  [=]() requires is_same {}
+  ();
+  [=]() mutable requires is_same {}
+  ();
+  [&]() requires is_same {}
+  ();
+  [&]() mutable requires is_same {}
+  ();
+  [&x]() requires is_same {}
+  ();
+  [&x]() mutable requires is_same {}
+  ();
+
+  [x = 1]() requires is_same {} (); //expected-error {{no matching function for call to object of type}} \
+   // expected-note {{candidate function not viable}} \
+   // expected-note {{'is_same' evaluated to false}}
+  [x = 1]() mutable requires is_same {} (); // expected-error {{no matching function for call to object of type}} \
+ // expected-note {{candidate function not viable}} \
+ // expected-note {{'is_same' evaluated to false}}
+}
+
+void err() {
+  int y, z;// expected-note 2{{declared here}}
+  auto implicit_tpl = [=]( // expected-note {{variable 'y' is captured here}}
+  decltype(
+  [&] { return 0; }) y) { //expected-error{{captured variable 'y' cannot appear}}
+return y;
+  };
+
+  auto init_tpl = [x = 1](  // expected-note{{explicitly captured here}}
+  decltype(

[PATCH] D119136: [clang] Implement Change scope of lambda trailing-return-type

2022-04-07 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin added inline comments.



Comment at: clang/include/clang/AST/DeclCXX.h:1816-1821
+  void setLambdaIsDependent(bool IsDependent) {
+auto *DD = DefinitionData;
+assert(DD && DD->IsLambda && "setting lambda property of non-lambda 
class");
+auto &DL = static_cast(*DD);
+DL.DependencyKind = IsDependent ? LDK_AlwaysDependent : LDK_Unknown;
+  }

ChuanqiXu wrote:
> It looks like this one is not used, is it?
Thanks., you are right, i wrote that before realizing i did not need it.



Comment at: clang/include/clang/Sema/ScopeInfo.h:842
+
+  bool BeforeLambdaQualifiersScope = false;
+

ChuanqiXu wrote:
> I think the name `Before*` is a little bit confusing. From the context, it 
> would be set to true in `ActOnLambdaIntroducer`and be set to false in 
> `ActOnLambdaClosureQualifiers`. So it looks like something `IsInRangeOf...`. 
> The name before implies that it should be true by default and be false after 
> some point...
> 
> I am not sure if my point is clear...
I struggle to find a better name, but I added a comment. Does that help? 



Comment at: clang/include/clang/Sema/Sema.h:6848
+
+  // 1: Create the class
+  void ActOnLambdaIntroducer(LambdaIntroducer &Intro, Scope *CurContext);

ChuanqiXu wrote:
> The comment looks like a draft.
Thanks for noticing that, I added a longer comment



Comment at: clang/lib/Parse/ParseExprCXX.cpp:1439
+DeclEndLoc = RParenLoc = T.getCloseLocation();
+HasParameters = true;
+  }

ChuanqiXu wrote:
> It looks a little bit. It looks like if the code is `()` and `HasParameters` 
> would still be true. 
Which is what we want to track. But it was not clear, I renamed the variable to 
`HasParentheses`



Comment at: clang/lib/Sema/Scope.cpp:72
+  // Lambdas have an extra prototype scope that doesn't add any depth
+  if (flags & FunctionPrototypeScope && !(flags & LambdaScope))
+PrototypeDepth++;

ChuanqiXu wrote:
> ChuanqiXu wrote:
> > This looks like:
> This isn't addressed. I mean the flags would always be true if the last 
> clause get evaluated.
I'm not sure I understand your point. We are checking that it's a function 
scope that is not a lambda scope.
They are probably other ways to write that but they aren't clearer



Comment at: clang/lib/Sema/SemaLambda.cpp:358-360
+/// Start the definition of a lambda expression.
+/// In this overload, we do not know the type yet
+static QualType finishLambdaMethodType(Sema &S, clang::CXXRecordDecl *Class,

ChuanqiXu wrote:
> The comment says `Start` while the function name starts with `finish`. It 
> looks odd...
The comment appertain to the `startLambdaDefinition` below, i fixed it. 
I also renamed `finishLambdaMethodType` to buildTypeForLambdaCallOperator` 
which is clearer`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119136

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


[PATCH] D120272: [CUDA] Add driver support for compiling CUDA with the new driver

2022-04-07 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 updated this revision to Diff 421232.
jhuber6 added a comment.

Update with the more generic clang argument handling.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120272

Files:
  clang/include/clang/Basic/Cuda.h
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/cuda-openmp-driver.cu

Index: clang/test/Driver/cuda-openmp-driver.cu
===
--- /dev/null
+++ clang/test/Driver/cuda-openmp-driver.cu
@@ -0,0 +1,16 @@
+// REQUIRES: clang-driver
+// REQUIRES: x86-registered-target
+// REQUIRES: nvptx-registered-target
+
+// RUN: %clang -### -target x86_64-linux-gnu -nocudalib -ccc-print-bindings -fgpu-rdc \
+// RUN:-foffload-new-driver --offload-arch=sm_35 --offload-arch=sm_70 %s 2>&1 \
+// RUN: | FileCheck -check-prefix CHECK %s
+
+// CHECK: "nvptx64-nvidia-cuda" - "clang", inputs: ["[[INPUT:.+]]"], output: "[[PTX_SM_35:.+]]"
+// CHECK: "nvptx64-nvidia-cuda" - "NVPTX::Assembler", inputs: ["[[PTX_SM_35]]"], output: "[[CUBIN_SM_35:.+]]"
+// CHECK: "nvptx64-nvidia-cuda" - "NVPTX::Linker", inputs: ["[[CUBIN_SM_35]]", "[[PTX_SM_35]]"], output: "[[FATBIN_SM_35:.+]]"
+// CHECK: "nvptx64-nvidia-cuda" - "clang", inputs: ["[[INPUT]]"], output: "[[PTX_SM_70:.+]]"
+// CHECK: "nvptx64-nvidia-cuda" - "NVPTX::Assembler", inputs: ["[[PTX_SM_70:.+]]"], output: "[[CUBIN_SM_70:.+]]"
+// CHECK: "nvptx64-nvidia-cuda" - "NVPTX::Linker", inputs: ["[[CUBIN_SM_70]]", "[[PTX_SM_70:.+]]"], output: "[[FATBIN_SM_70:.+]]"
+// CHECK: "x86_64-unknown-linux-gnu" - "clang", inputs: ["[[INPUT]]", "[[FATBIN_SM_35]]", "[[FATBIN_SM_70]]"], output: "[[HOST_OBJ:.+]]"
+// CHECK: "x86_64-unknown-linux-gnu" - "Offload::Linker", inputs: ["[[HOST_OBJ]]"], output: "a.out"
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -8248,14 +8248,17 @@
   ArgStringList CmdArgs;
 
   // Pass the CUDA path to the linker wrapper tool.
-  for (auto &I : llvm::make_range(OpenMPTCRange.first, OpenMPTCRange.second)) {
-const ToolChain *TC = I.second;
-if (TC->getTriple().isNVPTX()) {
-  CudaInstallationDetector CudaInstallation(D, TheTriple, Args);
-  if (CudaInstallation.isValid())
-CmdArgs.push_back(Args.MakeArgString(
-"--cuda-path=" + CudaInstallation.getInstallPath()));
-  break;
+  for (Action::OffloadKind Kind : {Action::OFK_Cuda, Action::OFK_OpenMP}) {
+auto TCRange = C.getOffloadToolChains(Kind);
+for (auto &I : llvm::make_range(TCRange.first, TCRange.second)) {
+  const ToolChain *TC = I.second;
+  if (TC->getTriple().isNVPTX()) {
+CudaInstallationDetector CudaInstallation(D, TheTriple, Args);
+if (CudaInstallation.isValid())
+  CmdArgs.push_back(Args.MakeArgString(
+  "--cuda-path=" + CudaInstallation.getInstallPath()));
+break;
+  }
 }
   }
 
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -4105,6 +4105,101 @@
   Args.ClaimAllArgs(options::OPT_cuda_compile_host_device);
 }
 
+/// Returns the canonical name for the offloading architecture when using HIP or
+/// CUDA.
+static StringRef getCanonicalArchString(Compilation &C,
+llvm::opt::DerivedArgList &Args,
+StringRef ArchStr,
+Action::OffloadKind Kind) {
+  if (Kind == Action::OFK_Cuda) {
+CudaArch Arch = StringToCudaArch(ArchStr);
+if (Arch == CudaArch::UNKNOWN || !IsNVIDIAGpuArch(Arch)) {
+  C.getDriver().Diag(clang::diag::err_drv_cuda_bad_gpu_arch) << ArchStr;
+  return StringRef();
+}
+return Args.MakeArgStringRef(CudaArchToString(Arch));
+  } else if (Kind == Action::OFK_HIP) {
+llvm::StringMap Features;
+// getHIPOffloadTargetTriple() is known to return valid value as it has
+// been called successfully in the CreateOffloadingDeviceToolChains().
+auto Arch = parseTargetID(
+*getHIPOffloadTargetTriple(C.getDriver(), C.getInputArgs()), ArchStr,
+&Features);
+if (!Arch) {
+  C.getDriver().Diag(clang::diag::err_drv_bad_target_id) << ArchStr;
+  C.setContainsError();
+  return StringRef();
+}
+return Args.MakeArgStringRef(
+getCanonicalTargetID(Arch.getValue(), Features));
+  }
+  return StringRef();
+}
+
+/// Checks if the set offloading architectures does not conflict. Returns the
+/// incompatible pair if a conflict occurs.
+static llvm::Optional>
+getConflictOffloadArchCombination(const llvm::DenseSet &Archs,
+  Action::OffloadKind Kind) {
+  if (Kind != Action

[PATCH] D111548: [Clang] Add the `annotate_type` attribute

2022-04-07 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun added inline comments.



Comment at: clang/include/clang/Basic/AttrDocs.td:6387
+additional information specific to the annotation category. The optional
+arguments must be constant expressions of arbitrary type.
+

Do we want to mention that it is not actually part of the type system (i.e., 
annotated and unannotated types are considered the same)?



Comment at: clang/include/clang/Basic/AttrDocs.td:6393
+
+  int* [[clang::annotate("category1", "foo", 1)]] 
f(int[[clang::annotate("category2"]] *);
+

Missing closing paren for the second annotate. 



Comment at: clang/lib/AST/TypePrinter.cpp:1686
+  // would require retrieving the attribute arguments, which we don't have 
here.
+  if (T->getAttrKind() == attr::AnnotateType)
+return;

Would it make sense to print something without the arguments? I wonder which 
behavior would be less confusing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D111548

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


[PATCH] D122895: [C89/C2x] Improve diagnostics around strict prototypes in C

2022-04-07 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

Thanks @erichkeane!

@jyknight, @hubert.reinterpretcast, @eli.friedman -- I'll likely land this 
sometime tomorrow unless I hear from you. But if I land it and you still have 
comments, I'll be happy to address them post commit.


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

https://reviews.llvm.org/D122895

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


[clang] fe2c77a - [clang][ExtractAPI] Fix appendSpace in DeclarationFragments

2022-04-07 Thread Zixu Wang via cfe-commits

Author: Zixu Wang
Date: 2022-04-07T09:17:30-07:00
New Revision: fe2c77a0065cda43418d625f0162a974ce8ec1e5

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

LOG: [clang][ExtractAPI] Fix appendSpace in DeclarationFragments

There is a bug in `DeclarationFragments::appendSpace` where the space
character is added to a local copy of the last fragment.

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

Added: 


Modified: 
clang/lib/ExtractAPI/DeclarationFragments.cpp
clang/test/ExtractAPI/global_record.c
clang/test/ExtractAPI/global_record_multifile.c
clang/test/ExtractAPI/macro_undefined.c
clang/test/ExtractAPI/objc_category.m
clang/test/ExtractAPI/objc_interface.m

Removed: 




diff  --git a/clang/lib/ExtractAPI/DeclarationFragments.cpp 
b/clang/lib/ExtractAPI/DeclarationFragments.cpp
index fa28fad358db9..a569ff9168bc3 100644
--- a/clang/lib/ExtractAPI/DeclarationFragments.cpp
+++ b/clang/lib/ExtractAPI/DeclarationFragments.cpp
@@ -21,7 +21,7 @@ using namespace llvm;
 
 DeclarationFragments &DeclarationFragments::appendSpace() {
   if (!Fragments.empty()) {
-Fragment Last = Fragments.back();
+Fragment &Last = Fragments.back();
 if (Last.Kind == FragmentKind::Text) {
   // Merge the extra space into the last fragment if the last fragment is
   // also text.
@@ -390,7 +390,7 @@ DeclarationFragmentsBuilder::getFragmentsForParam(const 
ParmVarDecl *Param) {
   if (Param->isObjCMethodParameter())
 Fragments.append("(", DeclarationFragments::FragmentKind::Text)
 .append(std::move(TypeFragments))
-.append(")", DeclarationFragments::FragmentKind::Text);
+.append(") ", DeclarationFragments::FragmentKind::Text);
   else
 Fragments.append(std::move(TypeFragments)).appendSpace();
 

diff  --git a/clang/test/ExtractAPI/global_record.c 
b/clang/test/ExtractAPI/global_record.c
index 4c14cae2de877..dfe99c2f55f67 100644
--- a/clang/test/ExtractAPI/global_record.c
+++ b/clang/test/ExtractAPI/global_record.c
@@ -175,7 +175,7 @@ char unavailable __attribute__((unavailable));
 },
 {
   "kind": "text",
-  "spelling": " *"
+  "spelling": " * "
 },
 {
   "kind": "internalParam",
@@ -331,7 +331,7 @@ char unavailable __attribute__((unavailable));
   },
   {
 "kind": "text",
-"spelling": " *"
+"spelling": " * "
   },
   {
 "kind": "internalParam",

diff  --git a/clang/test/ExtractAPI/global_record_multifile.c 
b/clang/test/ExtractAPI/global_record_multifile.c
index 76e18811a53b4..577eb121cf922 100644
--- a/clang/test/ExtractAPI/global_record_multifile.c
+++ b/clang/test/ExtractAPI/global_record_multifile.c
@@ -177,7 +177,7 @@ char unavailable __attribute__((unavailable));
 },
 {
   "kind": "text",
-  "spelling": " *"
+  "spelling": " * "
 },
 {
   "kind": "internalParam",
@@ -333,7 +333,7 @@ char unavailable __attribute__((unavailable));
   },
   {
 "kind": "text",
-"spelling": " *"
+"spelling": " * "
   },
   {
 "kind": "internalParam",

diff  --git a/clang/test/ExtractAPI/macro_undefined.c 
b/clang/test/ExtractAPI/macro_undefined.c
index feb4b3f43637e..0ae04d02e1543 100644
--- a/clang/test/ExtractAPI/macro_undefined.c
+++ b/clang/test/ExtractAPI/macro_undefined.c
@@ -142,7 +142,7 @@ FUNC_GEN(bar, const int *, unsigned);
 },
 {
   "kind": "text",
-  "spelling": " *"
+  "spelling": " * "
 },
 {
   "kind": "internalParam",
@@ -189,7 +189,7 @@ FUNC_GEN(bar, const int *, unsigned);
   },
   {
 "kind": "text",
-"spelling": " *"
+"spelling": " * "
   },
   {
 "kind": "internalParam",

diff  --git a/clang/test/ExtractAPI/objc_category.m 
b/clang/test/ExtractAPI/objc_category.m
index bc572adfcd161..2416e3049bd55 100644
--- a/clang/test/ExtractAPI/objc_category.m
+++ b/clang/test/ExtractAPI/objc_category.m
@@ -131,7 +131,7 @@ + (void)ClassMethod;
 },
 {
   "kind": "text",
-  "spelling": ")"
+  "spelling": ") "
 },
 {
   "kind": "identifier",
@@ -185,7 +185,7 @@ + (void)ClassMethod;
 },
 {
   "kind": "text",
-  "spelling": ")"
+  "spelling": ") "
 },
 {
   "kind": "identifier",
@@ -266,7 +266,7 @@ + (void)ClassMethod;
 },
 {
   "kind": "text",
-  "spelling": ")"
+

[PATCH] D123259: [clang][ExtractAPI] Fix appendSpace in DeclarationFragments

2022-04-07 Thread Zixu Wang 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 rGfe2c77a0065c: [clang][ExtractAPI] Fix appendSpace in 
DeclarationFragments (authored by zixuw).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123259

Files:
  clang/lib/ExtractAPI/DeclarationFragments.cpp
  clang/test/ExtractAPI/global_record.c
  clang/test/ExtractAPI/global_record_multifile.c
  clang/test/ExtractAPI/macro_undefined.c
  clang/test/ExtractAPI/objc_category.m
  clang/test/ExtractAPI/objc_interface.m

Index: clang/test/ExtractAPI/objc_interface.m
===
--- clang/test/ExtractAPI/objc_interface.m
+++ clang/test/ExtractAPI/objc_interface.m
@@ -142,7 +142,7 @@
 },
 {
   "kind": "text",
-  "spelling": ")"
+  "spelling": ") "
 },
 {
   "kind": "identifier",
@@ -163,7 +163,7 @@
 },
 {
   "kind": "text",
-  "spelling": ")"
+  "spelling": ") "
 },
 {
   "kind": "internalParam",
@@ -244,7 +244,7 @@
 },
 {
   "kind": "text",
-  "spelling": ")"
+  "spelling": ") "
 },
 {
   "kind": "typeIdentifier",
@@ -398,7 +398,7 @@
 },
 {
   "kind": "text",
-  "spelling": ")"
+  "spelling": ") "
 },
 {
   "kind": "identifier",
Index: clang/test/ExtractAPI/objc_category.m
===
--- clang/test/ExtractAPI/objc_category.m
+++ clang/test/ExtractAPI/objc_category.m
@@ -131,7 +131,7 @@
 },
 {
   "kind": "text",
-  "spelling": ")"
+  "spelling": ") "
 },
 {
   "kind": "identifier",
@@ -185,7 +185,7 @@
 },
 {
   "kind": "text",
-  "spelling": ")"
+  "spelling": ") "
 },
 {
   "kind": "identifier",
@@ -266,7 +266,7 @@
 },
 {
   "kind": "text",
-  "spelling": ")"
+  "spelling": ") "
 },
 {
   "kind": "typeIdentifier",
Index: clang/test/ExtractAPI/macro_undefined.c
===
--- clang/test/ExtractAPI/macro_undefined.c
+++ clang/test/ExtractAPI/macro_undefined.c
@@ -142,7 +142,7 @@
 },
 {
   "kind": "text",
-  "spelling": " *"
+  "spelling": " * "
 },
 {
   "kind": "internalParam",
@@ -189,7 +189,7 @@
   },
   {
 "kind": "text",
-"spelling": " *"
+"spelling": " * "
   },
   {
 "kind": "internalParam",
Index: clang/test/ExtractAPI/global_record_multifile.c
===
--- clang/test/ExtractAPI/global_record_multifile.c
+++ clang/test/ExtractAPI/global_record_multifile.c
@@ -177,7 +177,7 @@
 },
 {
   "kind": "text",
-  "spelling": " *"
+  "spelling": " * "
 },
 {
   "kind": "internalParam",
@@ -333,7 +333,7 @@
   },
   {
 "kind": "text",
-"spelling": " *"
+"spelling": " * "
   },
   {
 "kind": "internalParam",
Index: clang/test/ExtractAPI/global_record.c
===
--- clang/test/ExtractAPI/global_record.c
+++ clang/test/ExtractAPI/global_record.c
@@ -175,7 +175,7 @@
 },
 {
   "kind": "text",
-  "spelling": " *"
+  "spelling": " * "
 },
 {
   "kind": "internalParam",
@@ -331,7 +331,7 @@
   },
   {
 "kind": "text",
-"spelling": " *"
+"spelling": " * "
   },
   {
 "kind": "internalParam",
Index: clang/lib/ExtractAPI/DeclarationFragments.cpp
===
--- clang/lib/ExtractAPI/DeclarationFragments.cpp
+++ clang/lib/ExtractAPI/DeclarationFragments.cpp
@@ -21,7 +21,7 @@
 
 DeclarationFragments &DeclarationFragments::appendSpace() {
   if (!Fragments.empty()) {
-Fragment Last = Fragments.back();
+Fragment &Last = Fragments.back();
 if (Last.Kind == FragmentKind::Text) {
   // Merge the extra space into the last fragment if the last fragment is
   // also text.
@@ -390,7 +390,7 @@
   if (Param->isObjCMethodParameter())
 Fragments.append("(", DeclarationFragments::FragmentKind::Text)
 .append(std::move(TypeFragments))
-.append(")", DeclarationFragments::FragmentKind:

[PATCH] D92956: Fix range-loop-analysis checks for trivial copyability

2022-04-07 Thread Anshil Gandhi via Phabricator via cfe-commits
gandhi21299 added a comment.
Herald added a project: All.

@Quuxplusone I can commit this patch on behalf of @fanfuqiang.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92956

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


[PATCH] D123297: [flang][driver] Add support for -mmlir

2022-04-07 Thread Andrzej Warzynski via Phabricator via cfe-commits
awarzynski added inline comments.



Comment at: flang/test/Driver/mllvm_vs_mmlir.f90:17
+! MLLVM: flang (LLVM option parsing) [options]
+! MLLVM: --print-ir-after-all
+! MLLVM-NOT: --mlir-{{.*}}

rriddle wrote:
> awarzynski wrote:
> > awarzynski wrote:
> > > rovka wrote:
> > > > rovka wrote:
> > > > > Is this the most llvm-ish option we have? I'm concerned that MLIR 
> > > > > might also decide to add an option that sounds like this (and for 
> > > > > sure -print-ir-before-all is mentioned in the [[ 
> > > > > https://mlir.llvm.org/getting_started/Debugging/ |  MLIR docs ]]).
> > > > > Is this the most llvm-ish option we have? I'm concerned that MLIR 
> > > > > might also decide to add an option that sounds like this (and for 
> > > > > sure -print-ir-before-all is mentioned in the [[ 
> > > > > https://mlir.llvm.org/getting_started/Debugging/ |  MLIR docs ]]).
> > > > 
> > > > Right, I think that might be why the premerge tests are failing...
> > > > Is this the most llvm-ish option we have? 
> > > 
> > > Sadly, most LLVM options have rather generic names that could at some 
> > > point be added in MLIR. Perhaps you'll spot something more suitable:
> > > 
> > > ```lang=bash
> > > USAGE: flang (LLVM option parsing) [options]
> > > 
> > > OPTIONS:
> > > 
> > > Color Options:
> > > 
> > >   --color   - Use colors in 
> > > output (default=autodetect)
> > > 
> > > General options:
> > > 
> > >   --aarch64-neon-syntax= - Choose style of 
> > > NEON code to emit from AArch64 backend:
> > > =generic-   Emit generic NEON 
> > > assembly
> > > =apple  -   Emit Apple-style 
> > > NEON assembly
> > >   --aarch64-use-aa  - Enable the use of 
> > > AA during codegen.
> > >   --abort-on-max-devirt-iterations-reached  - Abort when the max 
> > > iterations for devirtualization CGSCC repeat pass is reached
> > >   --allow-ginsert-as-artifact   - Allow G_INSERT to 
> > > be considered an artifact. Hack around AMDGPU test infinite loops.
> > >   --always-execute-loop-body- force the body of a 
> > > loop to execute at least once
> > >   --array-constructor-initial-buffer-size=- set the incremental 
> > > array construction buffer size (default=32)
> > >   --cfg-hide-cold-paths=- Hide blocks with 
> > > relative frequency below the given value
> > >   --cfg-hide-deoptimize-paths   -
> > >   --cfg-hide-unreachable-paths  -
> > >   --cost-kind=   - Target cost kind
> > > =throughput -   Reciprocal 
> > > throughput
> > > =latency-   Instruction 
> > > latency
> > > =code-size  -   Code size
> > > =size-latency   -   Code size and 
> > > latency
> > >   --debugify-level=  - Kind of debug info 
> > > to add
> > > =locations  -   Locations only
> > > =location+variables -   Locations and 
> > > Variables
> > >   --debugify-quiet  - Suppress verbose 
> > > debugify output
> > >   --default-kinds= - string to set 
> > > default kind values
> > >   --disable-i2p-p2i-opt - Disables 
> > > inttoptr/ptrtoint roundtrip optimization
> > >   --dot-cfg-mssa= - file name for 
> > > generated dot file
> > >   --enable-cse-in-irtranslator  - Should enable CSE 
> > > in irtranslator
> > >   --enable-cse-in-legalizer - Should enable CSE 
> > > in Legalizer
> > >   --enable-gvn-memdep   -
> > >   --enable-load-in-loop-pre -
> > >   --enable-load-pre -
> > >   --enable-loop-simplifycfg-term-folding-
> > >   --enable-name-compression - Enable 
> > > name/filename string compression
> > >   --enable-split-backedge-in-load-pre   -
> > >   --experimental-debug-variable-locations   - Use experimental 
> > > new value-tracking variable locations
> > >   --fdebug-dump-pre-fir - dump the Pre-FIR 
> > > tree prior to FIR generation
> > >   --fs-profile-debug-bw-threshold=- Only show debug 
> > > message if the source branch weight is greater  than this value.
> > >   --fs-profile-debug-prob-diff-threshold= - Only show debug 
> > > message if the branch probility is greater than this value (in 
> > > percentage).
> > >   --gen-array-coor  - in lowering create 
> > > ArrayCoorOp instead of CoordinateOp
> > >   --generate-merged-

[PATCH] D123295: [clang][extract-api] Use dedicated API to check for macro equality

2022-04-07 Thread Zixu Wang via Phabricator via cfe-commits
zixuw accepted this revision.
zixuw 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/D123295/new/

https://reviews.llvm.org/D123295

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


[PATCH] D92956: Fix range-loop-analysis checks for trivial copyability

2022-04-07 Thread Anshil Gandhi via Phabricator via cfe-commits
gandhi21299 added a comment.

Perhaps, a description could be added to this patch before committing.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D92956

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


[PATCH] D116203: [clang] adds unary type transformations as compiler built-ins

2022-04-07 Thread Christopher Di Bella via Phabricator via cfe-commits
cjdb added a comment.

In D116203#3435729 , @aaron.ballman 
wrote:

> In D116203#3434761 , @rjmccall 
> wrote:
>
>> In D116203#3434515 , @cjdb wrote:
>>
>>> In D116203#3431612 , @rjmccall 
>>> wrote:
>>>
 In D116203#3430332 , 
 @aaron.ballman wrote:

> In D116203#3425512 , @cjdb 
> wrote:
>
>> I've noticed that libstdc++ has `using __remove_cv = typename 
>> remove_cv::type`, which causes Clang to chuck a wobbly. Changing from 
>> `KEYWORD` to `TYPE_TRAIT_1` didn't seem to fix anything.
>> Is there a way we can work around this, or should we just rename 
>> `__remove_cv` and friends to something else?
>
> You could work around it by taking note that you're in a libstdc++ system 
> header and do a special dance, but because these are in the 
> implementation's namespace, I think it's probably kinder for everyone to 
> just pick a different name.
>>>
>>> I was hoping we could do something similar to `struct __remove_cv` which 
>>> would issue a warning?
>>>
> If you wanted to be especially mean, you could go with `__remove_cvr`, 
> but I'd suggest `__remove_cv_qualifiers` instead. However, what about 
> `restrict` qualifiers? We support them in C++: 
> https://godbolt.org/z/11EPefhjf

 Along with a fair number of other vendor qualifiers, yeah.  I think you 
 have to make a policy decision about whether the intent of 
 `std::remove_cv` is really to just remove CV qualifiers or to produce an 
 unqualified type (at the outermost level).  The former is probably more 
 defensible, even if it makes the transform less useful in the presence of 
 extended qualifiers.
>>>
>>> I'm partial to `std::remove_cv` being faithful to its name, unless existing 
>>> implementations do something else already. I don't mind adding support for 
>>> the other stuff, but if there's more than just add/remove `restrict`, we're 
>>> going to have a combinatorial explosion for removes. Is there an alternate 
>>> way we can approach this?
>>> Possibly:
>>>
>>>   template
>>>   using remove_const_t = __remove_qualifiers(T, const);
>>>   
>>>   
>>>   template
>>>   using remove_reference_t = __remove_qualifiers(T, &, &&);
>>>   
>>>   template
>>>   using remove_rcvref_t = __remove_qualifiers(T, const, volatile, restrict, 
>>> &, &&); // rcv instead of cvr to prevent a typo with remove_cvref_t
>>
>> I don't think it's worth adding that parsing complexity for a builtin that 
>> we expect to only be used in system headers.  Let's just remove `const` and 
>> `volatile` and leave other qualifiers in place.
>
> I come down on the opposite side of the fence and think it should remove all 
> qualifiers (or that should be an interface we support in addition to removing 
> just cv qualifiers). WG14 adopted 
> https://www9.open-std.org/jtc1/sc22/wg14/www/docs/n2927.htm into C23 with a 
> `remove_quals` function which removes *all* qualifiers (including `_Atomic`), 
> as an example. But even in C++ mode, I fail to see why we wouldn't want 
>  interface for stripping `__restrict` the same as `const` or `volatile` 
> along with some interface for stripping all qualifiers period (I don't see a 
> huge need for a `__remove_cvr` if we have the ability to remove all 
> qualifiers, so I don't think we need the combinatorial explosion or a complex 
> interface). Basically -- if we have extensions like `__restrict` or _Atomic, 
> we should fully support them rather than halfway do it.

Having `__remove_cv` do more than it's advertised to do doesn't sound like a 
great idea to me. Both libc++ 

 and libstdc++ 

 define `std::remove_cv` without extensions, and I think it would be surprising 
for `__remove_cv` to remove anything else.

I'm not against adding `__remove_restrict`, `__remove_qualifiers` (although 
"qualifier" could imply ref-qualifiers too?), etc.. I suppose that in the rare 
case someone wants to remove `volatile restrict` and keep `const&`, it's 
possible to do `__add_const(__remove_qualifiers(T)&)`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D116203

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


[PATCH] D123319: Change how we handle auto return types for lambda operator() to be consistent with gcc

2022-04-07 Thread Shafik Yaghmour via Phabricator via cfe-commits
shafik created this revision.
shafik added reviewers: aprantl, dblaikie, probinson.
Herald added a project: All.
shafik requested review of this revision.

D70524  added support for auto return types 
for C++ member functions. I was implementing support on the LLDB side for 
looking up the deduced type.

I ran into trouble with some cases with respect to lambdas. I looked into how 
gcc was handling these cases and it appears gcc emits the deduced return type 
for lambdas.

So I am changing out behavior to match that.


https://reviews.llvm.org/D123319

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp


Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -1678,8 +1678,14 @@
   SmallVector Elts;
   // First element is always return type. For 'void' functions it is NULL.
   QualType temp = Func->getReturnType();
-  if (temp->getTypeClass() == Type::Auto && decl)
-Elts.push_back(CreateType(cast(temp)));
+  if (temp->getTypeClass() == Type::Auto && decl) {
+const AutoType *AT = cast(temp);
+
+if (AT->isDeduced() && ThisPtr->getPointeeCXXRecordDecl()->isLambda())
+  Elts.push_back(getOrCreateType(AT->getDeducedType(),Unit));
+else
+  Elts.push_back(CreateType(AT));
+  }
   else
 Elts.push_back(Args[0]);
 


Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -1678,8 +1678,14 @@
   SmallVector Elts;
   // First element is always return type. For 'void' functions it is NULL.
   QualType temp = Func->getReturnType();
-  if (temp->getTypeClass() == Type::Auto && decl)
-Elts.push_back(CreateType(cast(temp)));
+  if (temp->getTypeClass() == Type::Auto && decl) {
+const AutoType *AT = cast(temp);
+
+if (AT->isDeduced() && ThisPtr->getPointeeCXXRecordDecl()->isLambda())
+  Elts.push_back(getOrCreateType(AT->getDeducedType(),Unit));
+else
+  Elts.push_back(CreateType(AT));
+  }
   else
 Elts.push_back(Args[0]);
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D112621: [analyzer][solver] Introduce reasoning for not equal to operator

2022-04-07 Thread Denys Petrov via Phabricator via cfe-commits
ASDenysPetrov added a comment.

Here are my remarks.




Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:1415-1416
+
+  Range CoarseLHS = fillGaps(LHS);
+  Range CoarseRHS = fillGaps(RHS);
+

Avoid filling the gaps, because it's completely possible to compare all the 
ranges.
E.g. //LHS //`[1,2]U[8,9]`  and  //RHS //`[5,6]` are not equal.
And you don't need to fiil the gap in LHS, because it will lead you to a wrong 
answer, like `[1,9] != [5,6]` => **UNKNOWN** instead of **TRUE**.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:1420-1421
+
+  auto ConvertedCoarseLHS = convert(CoarseLHS, ResultType);
+  auto ConvertedCoarseRHS = convert(CoarseRHS, ResultType);
+

The `ResultType` of `BO_NE` is `bool`. You don't need to convert your **integer 
**ranges to **boolean**. Otherwise, you'll lose the information to compare. 



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:1430-1433
+  if ((ConvertedCoarseLHS->To() < ConvertedCoarseRHS->From()) ||
+  (ConvertedCoarseLHS->From() > ConvertedCoarseRHS->To())) {
+return getTrueRange(T);
+  }

You can simply check an intersection (`RangeSet::Factory::intersect`) between 
the ranges.
If the result range is //empty// then return TRUE.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:1437-1441
+  if (ConvertedCoarseLHS->getConcreteValue() &&
+  ConvertedCoarseLHS->getConcreteValue() ==
+  ConvertedCoarseRHS->getConcreteValue()) {
+return getFalseRange(T);
+  }

This is OK but check `ConvertedCoarseRHS->getConcreteValue()` for `nullptr` 
before getting the value.




Comment at: clang/test/Analysis/constant-folding.c:339
+  }
+}

I'd like to see the cases with concrete integers as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112621

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


  1   2   >