[PATCH] D121042: [clang-format] Handle goto labels for RemoveBracesLLVM

2022-03-04 Thread Owen Pan via Phabricator via cfe-commits
owenpan created this revision.
owenpan added reviewers: MyDeveloperDay, curdeius, HazardyKnusperkeks.
owenpan added a project: clang-format.
Herald added a project: All.
owenpan 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/D121042

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


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -24988,6 +24988,23 @@
"}",
Style);
 
+  verifyFormat("if (a) {\n"
+   "Label:\n"
+   "}",
+   Style);
+
+  verifyFormat("if (a) {\n"
+   "Label:\n"
+   "  f();\n"
+   "}",
+   Style);
+
+  verifyFormat("if (a) {\n"
+   "  f();\n"
+   "Label:\n"
+   "}",
+   Style);
+
   // FIXME: See https://github.com/llvm/llvm-project/issues/53543.
 #if 0
   Style.ColumnLimit = 65;
Index: clang/lib/Format/UnwrappedLineParser.h
===
--- clang/lib/Format/UnwrappedLineParser.h
+++ clang/lib/Format/UnwrappedLineParser.h
@@ -112,7 +112,8 @@
   void readTokenWithJavaScriptASI();
   void parseStructuralElement(IfStmtKind *IfKind = nullptr,
   bool IsTopLevel = false,
-  TokenType NextLBracesType = TT_Unknown);
+  TokenType NextLBracesType = TT_Unknown,
+  bool *HasLabel = nullptr);
   bool tryToParseBracedList();
   bool parseBracedList(bool ContinueOnSemicolons = false, bool IsEnum = false,
tok::TokenKind ClosingBraceKind = tok::r_brace);
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -476,6 +476,7 @@
   : TT_Unknown;
   const bool IsPrecededByCommentOrPPDirective =
   !Style.RemoveBracesLLVM || precededByCommentOrPPDirective();
+  bool HasLabel = false;
   unsigned StatementCount = 0;
   bool SwitchLabelEncountered = false;
   do {
@@ -486,9 +487,9 @@
   kind = tok::r_brace;
 
 auto ParseDefault = [this, HasOpeningBrace, IfKind, NextLevelLBracesType,
- ] {
-  parseStructuralElement(IfKind, /*IsTopLevel=*/!HasOpeningBrace,
- /*NextLBracesType=*/NextLevelLBracesType);
+ , ] {
+  parseStructuralElement(IfKind, !HasOpeningBrace, NextLevelLBracesType,
+ HasLabel ? nullptr : );
   ++StatementCount;
   assert(StatementCount > 0 && "StatementCount overflow!");
 };
@@ -523,7 +524,7 @@
   if (HasOpeningBrace) {
 if (!Style.RemoveBracesLLVM)
   return false;
-if (FormatTok->isNot(tok::r_brace) || StatementCount != 1 ||
+if (FormatTok->isNot(tok::r_brace) || StatementCount != 1 || HasLabel 
||
 IsPrecededByCommentOrPPDirective ||
 precededByCommentOrPPDirective())
   return false;
@@ -1312,7 +1313,8 @@
 
 void UnwrappedLineParser::parseStructuralElement(IfStmtKind *IfKind,
  bool IsTopLevel,
- TokenType NextLBracesType) {
+ TokenType NextLBracesType,
+ bool *HasLabel) {
   if (Style.Language == FormatStyle::LK_TableGen &&
   FormatTok->is(tok::pp_include)) {
 nextToken();
@@ -1758,6 +1760,8 @@
 if (FormatTok->is(tok::colon) && !Line->MustBeDeclaration) {
   Line->Tokens.begin()->Tok->MustBreakBefore = true;
   parseLabel(!Style.IndentGotoLabels);
+  if (HasLabel)
+*HasLabel = true;
   return;
 }
 // Recognize function-like macro usages without trailing semicolon as


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -24988,6 +24988,23 @@
"}",
Style);
 
+  verifyFormat("if (a) {\n"
+   "Label:\n"
+   "}",
+   Style);
+
+  verifyFormat("if (a) {\n"
+   "Label:\n"
+   "  f();\n"
+   "}",
+   Style);
+
+  verifyFormat("if (a) {\n"
+   "  f();\n"
+   "Label:\n"
+   "}",
+   Style);
+
   // FIXME: See 

[PATCH] D119609: [Clang][Sema] Don't act on ReturnStmt when parsing the lambda declarator.

2022-03-04 Thread Jun Zhang via Phabricator via cfe-commits
junaire updated this revision to Diff 413195.
junaire added a comment.

This update proibit any use of ({}) in the default argument.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119609

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Parse/ParseDecl.cpp
  clang/test/Sema/err-expr-stmt-in-default-arg.cpp
  clang/test/SemaTemplate/dependent-expr.cpp


Index: clang/test/SemaTemplate/dependent-expr.cpp
===
--- clang/test/SemaTemplate/dependent-expr.cpp
+++ clang/test/SemaTemplate/dependent-expr.cpp
@@ -143,13 +143,6 @@
   void h(auto a, decltype(g())*) {} // expected-note {{previous}}
   void h(auto a, void*) {} // expected-error {{redefinition}}
 
-  void i(auto a) {
-[](auto a, int = ({decltype(a) i; i * 2;})){}(a); // expected-error 
{{invalid operands to binary expression ('decltype(a)' (aka 'void *') and 
'int')}} expected-note {{in instantiation of}}
-  }
-  void use_i() {
-i(0);
-i((void*)0); // expected-note {{instantiation of}}
-  }
 }
 
 namespace BindingInStmtExpr {
Index: clang/test/Sema/err-expr-stmt-in-default-arg.cpp
===
--- /dev/null
+++ clang/test/Sema/err-expr-stmt-in-default-arg.cpp
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 %s -fsyntax-only -verify -std=c++20
+
+void foo() {
+  void fn(int i, int = ({ 1; })); // expected-error {{can't use expression 
statement in default argument}}
+
+  auto a = [](int = ({ 1; })) {}; // expected-error {{can't use expression 
statement in default argument}}
+}
+
+template 
+int bar(Callable &) {
+  return Call();
+}
+
+int baz() {
+  auto l = [](int a = ({ int x = 12; x; })) { // expected-error {{can't use 
expression statement in default argument}}
+return 1;
+  };
+  return bar(l);
+}
Index: clang/lib/Parse/ParseDecl.cpp
===
--- clang/lib/Parse/ParseDecl.cpp
+++ clang/lib/Parse/ParseDecl.cpp
@@ -7085,8 +7085,15 @@
   if (getLangOpts().CPlusPlus11 && Tok.is(tok::l_brace)) {
 Diag(Tok, diag::warn_cxx98_compat_generalized_initializer_lists);
 DefArgResult = ParseBraceInitializer();
-  } else
+  } else {
+if (Tok.is(tok::l_paren) && NextToken().is(tok::l_brace)) {
+  Diag(Tok, diag::err_expr_statement_in_default_arg);
+  Actions.ActOnParamDefaultArgumentError(Param, EqualLoc);
+  SkipUntil(tok::comma, tok::r_paren, StopAtSemi | 
StopBeforeMatch);
+  return;
+}
 DefArgResult = ParseAssignmentExpression();
+  }
   DefArgResult = Actions.CorrectDelayedTyposInExpr(DefArgResult);
   if (DefArgResult.isInvalid()) {
 Actions.ActOnParamDefaultArgumentError(Param, EqualLoc);
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -4362,6 +4362,8 @@
 def err_default_arg_makes_ctor_special : Error<
   "addition of default argument on redeclaration makes this constructor a "
   "%select{default|copy|move}0 constructor">;
+def err_expr_statement_in_default_arg : Error<
+  "can't use expression statement in default argument">;
 
 def err_use_of_default_argument_to_function_declared_later : Error<
   "use of default argument to function %0 that is declared later in class %1">;


Index: clang/test/SemaTemplate/dependent-expr.cpp
===
--- clang/test/SemaTemplate/dependent-expr.cpp
+++ clang/test/SemaTemplate/dependent-expr.cpp
@@ -143,13 +143,6 @@
   void h(auto a, decltype(g())*) {} // expected-note {{previous}}
   void h(auto a, void*) {} // expected-error {{redefinition}}
 
-  void i(auto a) {
-[](auto a, int = ({decltype(a) i; i * 2;})){}(a); // expected-error {{invalid operands to binary expression ('decltype(a)' (aka 'void *') and 'int')}} expected-note {{in instantiation of}}
-  }
-  void use_i() {
-i(0);
-i((void*)0); // expected-note {{instantiation of}}
-  }
 }
 
 namespace BindingInStmtExpr {
Index: clang/test/Sema/err-expr-stmt-in-default-arg.cpp
===
--- /dev/null
+++ clang/test/Sema/err-expr-stmt-in-default-arg.cpp
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 %s -fsyntax-only -verify -std=c++20
+
+void foo() {
+  void fn(int i, int = ({ 1; })); // expected-error {{can't use expression statement in default argument}}
+
+  auto a = [](int = ({ 1; })) {}; // expected-error {{can't use expression statement in default argument}}
+}
+
+template 
+int bar(Callable &) {
+  return Call();
+}
+
+int baz() {
+  auto l = [](int a = ({ int x = 12; x; })) { // expected-error {{can't use expression 

[clang] fa9c8ba - [RISCV] Support k-ext clang intrinsics

2022-03-04 Thread Shao-Ce SUN via cfe-commits

Author: Shao-Ce SUN
Date: 2022-03-05T13:57:18+08:00
New Revision: fa9c8bab0c7a7aed423191baa8a980533ae5602a

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

LOG: [RISCV] Support k-ext clang intrinsics

Reviewed By: craig.topper

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

Added: 
clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbkb.c
clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbkc.c
clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbkx.c
clang/test/CodeGen/RISCV/rvb-intrinsics/riscv64-zbkb.c
clang/test/CodeGen/RISCV/rvb-intrinsics/riscv64-zbkc.c
clang/test/CodeGen/RISCV/rvb-intrinsics/riscv64-zbkx.c
clang/test/CodeGen/RISCV/rvk-intrinsics/riscv32-zknd.c
clang/test/CodeGen/RISCV/rvk-intrinsics/riscv32-zkne.c
clang/test/CodeGen/RISCV/rvk-intrinsics/riscv32-zknh.c
clang/test/CodeGen/RISCV/rvk-intrinsics/riscv32-zksed.c
clang/test/CodeGen/RISCV/rvk-intrinsics/riscv32-zksh.c
clang/test/CodeGen/RISCV/rvk-intrinsics/riscv64-zknd-zkne.c
clang/test/CodeGen/RISCV/rvk-intrinsics/riscv64-zknd.c
clang/test/CodeGen/RISCV/rvk-intrinsics/riscv64-zkne.c
clang/test/CodeGen/RISCV/rvk-intrinsics/riscv64-zknh.c
clang/test/CodeGen/RISCV/rvk-intrinsics/riscv64-zksed.c
clang/test/CodeGen/RISCV/rvk-intrinsics/riscv64-zksh.c

Modified: 
clang/include/clang/Basic/BuiltinsRISCV.def
clang/lib/CodeGen/CGBuiltin.cpp
clang/lib/Sema/SemaChecking.cpp
clang/test/Driver/riscv-arch.c
clang/test/Preprocessor/riscv-target-features.c

Removed: 




diff  --git a/clang/include/clang/Basic/BuiltinsRISCV.def 
b/clang/include/clang/Basic/BuiltinsRISCV.def
index 495a036e576f8..73ec6eae7e955 100644
--- a/clang/include/clang/Basic/BuiltinsRISCV.def
+++ b/clang/include/clang/Basic/BuiltinsRISCV.def
@@ -19,11 +19,15 @@
 TARGET_BUILTIN(__builtin_riscv_orc_b_32, "ZiZi", "nc", "zbb")
 TARGET_BUILTIN(__builtin_riscv_orc_b_64, "WiWi", "nc", "zbb,64bit")
 
-// Zbc extension
-TARGET_BUILTIN(__builtin_riscv_clmul, "LiLiLi", "nc", "zbc")
-TARGET_BUILTIN(__builtin_riscv_clmulh, "LiLiLi", "nc", "zbc")
+// Zbc or Zbkc extension
+TARGET_BUILTIN(__builtin_riscv_clmul, "LiLiLi", "nc", "zbc|zbkc")
+TARGET_BUILTIN(__builtin_riscv_clmulh, "LiLiLi", "nc", "zbc|zbkc")
 TARGET_BUILTIN(__builtin_riscv_clmulr, "LiLiLi", "nc", "zbc")
 
+// Zbkx
+TARGET_BUILTIN(__builtin_riscv_xperm4, "LiLiLi", "nc", "zbkx")
+TARGET_BUILTIN(__builtin_riscv_xperm8, "LiLiLi", "nc", "zbkx")
+
 // Zbe extension
 TARGET_BUILTIN(__builtin_riscv_bcompress_32, "ZiZiZi", "nc", 
"experimental-zbe")
 TARGET_BUILTIN(__builtin_riscv_bcompress_64, "WiWiWi", "nc",
@@ -67,5 +71,52 @@ TARGET_BUILTIN(__builtin_riscv_fsr_32, "LiLiLiLi", "nc", 
"experimental-zbt")
 TARGET_BUILTIN(__builtin_riscv_fsl_64, "WiWiWiWi", "nc", 
"experimental-zbt,64bit")
 TARGET_BUILTIN(__builtin_riscv_fsr_64, "WiWiWiWi", "nc", 
"experimental-zbt,64bit")
 
+// Zbkb extension
+TARGET_BUILTIN(__builtin_riscv_brev8, "LiLi", "nc", "zbkb")
+TARGET_BUILTIN(__builtin_riscv_zip_32, "ZiZi", "nc", "zbkb")
+TARGET_BUILTIN(__builtin_riscv_unzip_32, "ZiZi", "nc", "zbkb")
+
+// Zknd extension
+TARGET_BUILTIN(__builtin_riscv_aes32dsi_32, "ZiZiZiIUc", "nc", "zknd")
+TARGET_BUILTIN(__builtin_riscv_aes32dsmi_32, "ZiZiZiIUc", "nc", "zknd")
+TARGET_BUILTIN(__builtin_riscv_aes64ds_64, "WiWiWi", "nc", "zknd,64bit")
+TARGET_BUILTIN(__builtin_riscv_aes64dsm_64, "WiWiWi", "nc", "zknd,64bit")
+TARGET_BUILTIN(__builtin_riscv_aes64im_64, "WiWi", "nc", "zknd,64bit")
+
+// Zknd & zkne
+TARGET_BUILTIN(__builtin_riscv_aes64ks1i_64, "WiWiIUi", "nc", 
"zknd|zkne,64bit")
+TARGET_BUILTIN(__builtin_riscv_aes64ks2_64, "WiWiWi", "nc", "zknd|zkne,64bit")
+
+// Zkne extension
+TARGET_BUILTIN(__builtin_riscv_aes32esi_32, "ZiZiZiIUc", "nc", "zkne")
+TARGET_BUILTIN(__builtin_riscv_aes32esmi_32, "ZiZiZiIUc", "nc", "zkne")
+TARGET_BUILTIN(__builtin_riscv_aes64es_64, "WiWiWi", "nc", "zkne,64bit")
+TARGET_BUILTIN(__builtin_riscv_aes64esm_64, "WiWiWi", "nc", "zkne,64bit")
+
+// Zknh extension
+TARGET_BUILTIN(__builtin_riscv_sha256sig0, "LiLi", "nc", "zknh")
+TARGET_BUILTIN(__builtin_riscv_sha256sig1, "LiLi", "nc", "zknh")
+TARGET_BUILTIN(__builtin_riscv_sha256sum0, "LiLi", "nc", "zknh")
+TARGET_BUILTIN(__builtin_riscv_sha256sum1, "LiLi", "nc", "zknh")
+
+TARGET_BUILTIN(__builtin_riscv_sha512sig0h_32, "ZiZiZi", "nc", "zknh")
+TARGET_BUILTIN(__builtin_riscv_sha512sig0l_32, "ZiZiZi", "nc", "zknh")
+TARGET_BUILTIN(__builtin_riscv_sha512sig1h_32, "ZiZiZi", "nc", "zknh")
+TARGET_BUILTIN(__builtin_riscv_sha512sig1l_32, "ZiZiZi", "nc", "zknh")
+TARGET_BUILTIN(__builtin_riscv_sha512sum0r_32, "ZiZiZi", "nc", "zknh")
+TARGET_BUILTIN(__builtin_riscv_sha512sum1r_32, "ZiZiZi", "nc", "zknh")
+TARGET_BUILTIN(__builtin_riscv_sha512sig0_64, "WiWi", "nc", "zknh,64bit")

[PATCH] D112774: [RISCV] Support k-ext clang intrinsics

2022-03-04 Thread Shao-Ce SUN 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 rGfa9c8bab0c7a: [RISCV] Support k-ext clang intrinsics 
(authored by achieveartificialintelligence).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112774

Files:
  clang/include/clang/Basic/BuiltinsRISCV.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbkb.c
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbkc.c
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbkx.c
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv64-zbkb.c
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv64-zbkc.c
  clang/test/CodeGen/RISCV/rvb-intrinsics/riscv64-zbkx.c
  clang/test/CodeGen/RISCV/rvk-intrinsics/riscv32-zknd.c
  clang/test/CodeGen/RISCV/rvk-intrinsics/riscv32-zkne.c
  clang/test/CodeGen/RISCV/rvk-intrinsics/riscv32-zknh.c
  clang/test/CodeGen/RISCV/rvk-intrinsics/riscv32-zksed.c
  clang/test/CodeGen/RISCV/rvk-intrinsics/riscv32-zksh.c
  clang/test/CodeGen/RISCV/rvk-intrinsics/riscv64-zknd-zkne.c
  clang/test/CodeGen/RISCV/rvk-intrinsics/riscv64-zknd.c
  clang/test/CodeGen/RISCV/rvk-intrinsics/riscv64-zkne.c
  clang/test/CodeGen/RISCV/rvk-intrinsics/riscv64-zknh.c
  clang/test/CodeGen/RISCV/rvk-intrinsics/riscv64-zksed.c
  clang/test/CodeGen/RISCV/rvk-intrinsics/riscv64-zksh.c
  clang/test/Driver/riscv-arch.c
  clang/test/Preprocessor/riscv-target-features.c

Index: clang/test/Preprocessor/riscv-target-features.c
===
--- clang/test/Preprocessor/riscv-target-features.c
+++ clang/test/Preprocessor/riscv-target-features.c
@@ -31,6 +31,17 @@
 // CHECK-NOT: __riscv_zfh
 // CHECK-NOT: __riscv_v
 // CHECK-NOT: __riscv_vector
+// CHECK-NOT: __riscv_zbkc
+// CHECK-NOT: __riscv_zbkx
+// CHECK-NOT: __riscv_zbkb
+// CHECK-NOT: __riscv_zkne
+// CHECK-NOT: __riscv_zknd
+// CHECK-NOT: __riscv_zknh
+// CHECK-NOT: __riscv_zksh
+// CHECK-NOT: __riscv_zksed
+// CHECK-NOT: __riscv_zkr
+// CHECK-NOT: __riscv_zkt
+// CHECK-NOT: __riscv_zk
 
 // RUN: %clang -target riscv32-unknown-linux-gnu -march=rv32im -x c -E -dM %s \
 // RUN: -o - | FileCheck --check-prefix=CHECK-M-EXT %s
@@ -343,3 +354,58 @@
 // CHECK-ZVE32X-EXT: __riscv_v_min_vlen 32
 // CHECK-ZVE32X-EXT: __riscv_vector 1
 // CHECK-ZVE32X-EXT: __riscv_zve32x 100{{$}}
+
+// RUN: %clang -target riscv64-unknown-linux-gnu \
+// RUN: -march=rv64izbkc1p0 -x c -E -dM %s -o - \
+// RUN: | FileCheck --check-prefix=CHECK-ZBKC-EXT %s
+// CHECK-ZBKC-EXT: __riscv_zbkc
+
+// RUN: %clang -target riscv64-unknown-linux-gnu \
+// RUN: -march=rv64izbkx1p0 -x c -E -dM %s -o - \
+// RUN: | FileCheck --check-prefix=CHECK-ZBKX-EXT %s
+// CHECK-ZBKX-EXT: __riscv_zbkx
+
+// RUN: %clang -target riscv64-unknown-linux-gnu \
+// RUN: -march=rv64izbkb1p0 -x c -E -dM %s -o - \
+// RUN: | FileCheck --check-prefix=CHECK-ZBKB-EXT %s
+// CHECK-ZBKB-EXT: __riscv_zbkb
+
+// RUN: %clang -target riscv64-unknown-linux-gnu \
+// RUN: -march=rv64izknd1p0 -x c -E -dM %s -o - \
+// RUN: | FileCheck --check-prefix=CHECK-ZKND-EXT %s
+// CHECK-ZKND-EXT: __riscv_zknd
+
+// RUN: %clang -target riscv64-unknown-linux-gnu \
+// RUN: -march=rv64izkne1p0 -x c -E -dM %s -o - \
+// RUN: | FileCheck --check-prefix=CHECK-ZKNE-EXT %s
+// CHECK-ZKNE-EXT: __riscv_zkne
+
+// RUN: %clang -target riscv64-unknown-linux-gnu \
+// RUN: -march=rv64izknh1p0 -x c -E -dM %s -o - \
+// RUN: | FileCheck --check-prefix=CHECK-ZKNH-EXT %s
+// CHECK-ZKNH-EXT: __riscv_zknh
+
+// RUN: %clang -target riscv64-unknown-linux-gnu \
+// RUN: -march=rv64izksh1p0 -x c -E -dM %s -o - \
+// RUN: | FileCheck --check-prefix=CHECK-ZKSH-EXT %s
+// CHECK-ZKSH-EXT: __riscv_zksh
+
+// RUN: %clang -target riscv64-unknown-linux-gnu \
+// RUN: -march=rv64izksed1p0 -x c -E -dM %s -o - \
+// RUN: | FileCheck --check-prefix=CHECK-ZKSED-EXT %s
+// CHECK-ZKSED-EXT: __riscv_zksed
+
+// RUN: %clang -target riscv64-unknown-linux-gnu \
+// RUN: -march=rv64izkr1p0 -x c -E -dM %s -o - \
+// RUN: | FileCheck --check-prefix=CHECK-ZKR-EXT %s
+// CHECK-ZKR-EXT: __riscv_zkr
+
+// RUN: %clang -target riscv64-unknown-linux-gnu \
+// RUN: -march=rv64izkt1p0 -x c -E -dM %s -o - \
+// RUN: | FileCheck --check-prefix=CHECK-ZKT-EXT %s
+// CHECK-ZKT-EXT: __riscv_zkt
+
+// RUN: %clang -target riscv64-unknown-linux-gnu \
+// RUN: -march=rv64izk1p0 -x c -E -dM %s -o - \
+// RUN: | FileCheck --check-prefix=CHECK-ZK-EXT %s
+// CHECK-ZK-EXT: __riscv_zk
Index: clang/test/Driver/riscv-arch.c
===
--- clang/test/Driver/riscv-arch.c
+++ clang/test/Driver/riscv-arch.c
@@ -414,3 +414,47 @@
 // RUN: %clang -target riscv32-unknown-elf -march=rv32iv1p0_zvl32b1p0 -### %s -c 2>&1 | \
 // RUN:   FileCheck -check-prefix=RV32-ZVL-GOODVERS %s
 // RV32-ZVL-GOODVERS: "-target-feature" "+zvl32b"
+
+// 

[PATCH] D23934: Add a -ffixed-date-time= flag that sets the initial value of __DATE__, __TIME__, __TIMESTAMP__

2022-03-04 Thread Anmol P. Paralkar via Phabricator via cfe-commits
appcs added a comment.

In D23934#3355355 , @emaste wrote:

> The original author appears to have given up on it. Someone will need to 
> rebase and work on pushing it forward

Please see: https://reviews.llvm.org/D121040


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

https://reviews.llvm.org/D23934

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


[PATCH] D119996: [safestack] Support safestack in stack size diagnostics

2022-03-04 Thread Paul Kirth via Phabricator via cfe-commits
paulkirth added inline comments.



Comment at: llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp:1211
   const MachineFrameInfo  = MF.getFrameInfo();
-  uint64_t StackSize = FrameInfo.getStackSize();
+  uint64_t StackSize =
+  FrameInfo.getStackSize() + FrameInfo.getUnsafeStackSize();

mcgrathr wrote:
> Should we also update emitStackSizeSection to match?
> I'm not sure whether that's meant to be used for diagnostic-like cases or for 
> more concrete backend uses where the distinction between the two stacks still 
> matters.
> 
I am not exactly sure, but https://reviews.llvm.org/D39788, which I believe 
adds the feature seems like it is only used for diagnostic information 
according to the RFC they mention:  
http://lists.llvm.org/pipermail/llvm-dev/2017-August/117028.html. 

Changing the behavior to be aware of the safe-stack, however, does seem 
consistent with the original goal of the feature, so I'm happy to update the 
patch to reflect that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119996

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


[PATCH] D121014: [WebAssembly] Check bulk-memory when adjusting lang opts

2022-03-04 Thread Thomas Lively via Phabricator via cfe-commits
tlively added a comment.

@dyung, this should be fixed by 
https://reviews.llvm.org/rGc01ec3083026f7e24e6c06f48a05d413e2c697d4


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121014

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


[PATCH] D119996: [safestack] Support safestack in stack size diagnostics

2022-03-04 Thread Roland McGrath via Phabricator via cfe-commits
mcgrathr added inline comments.



Comment at: llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp:1211
   const MachineFrameInfo  = MF.getFrameInfo();
-  uint64_t StackSize = FrameInfo.getStackSize();
+  uint64_t StackSize =
+  FrameInfo.getStackSize() + FrameInfo.getUnsafeStackSize();

Should we also update emitStackSizeSection to match?
I'm not sure whether that's meant to be used for diagnostic-like cases or for 
more concrete backend uses where the distinction between the two stacks still 
matters.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119996

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


[clang] c01ec30 - [WebAssembly] Update Preprocessor/init.c test after 3be9e0ba972c

2022-03-04 Thread Thomas Lively via cfe-commits

Author: Thomas Lively
Date: 2022-03-04T18:40:10-08:00
New Revision: c01ec3083026f7e24e6c06f48a05d413e2c697d4

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

LOG: [WebAssembly] Update Preprocessor/init.c test after 3be9e0ba972c

Added: 


Modified: 
clang/test/Preprocessor/init.c

Removed: 




diff  --git a/clang/test/Preprocessor/init.c b/clang/test/Preprocessor/init.c
index a08e503570723..33354e8975fd2 100644
--- a/clang/test/Preprocessor/init.c
+++ b/clang/test/Preprocessor/init.c
@@ -1483,7 +1483,7 @@
 // RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 
-triple=wasm32-emscripten \
 // RUN:   < /dev/null \
 // RUN:   | FileCheck -match-full-lines 
-check-prefixes=WEBASSEMBLY,WEBASSEMBLY32,EMSCRIPTEN %s
-// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 
-triple=wasm32-emscripten -pthread -target-feature +atomics \
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 
-triple=wasm32-emscripten -pthread -target-feature +atomics -target-feature 
+bulk-memory \
 // RUN:   < /dev/null \
 // RUN:   | FileCheck -match-full-lines 
-check-prefixes=WEBASSEMBLY,WEBASSEMBLY32,EMSCRIPTEN,EMSCRIPTEN-THREADS %s
 // RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 
-triple=wasm64-emscripten \
@@ -1498,7 +1498,7 @@
 // RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 
-triple=wasm32-unknown-unknown -x c++ \
 // RUN:   < /dev/null \
 // RUN:   | FileCheck -match-full-lines -check-prefixes=WEBASSEMBLY-CXX %s
-// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 
-triple=wasm32-unknown-unknown -x c++ -pthread -target-feature +atomics \
+// RUN: %clang_cc1 -E -dM -ffreestanding -fgnuc-version=4.2.1 
-triple=wasm32-unknown-unknown -x c++ -pthread -target-feature +atomics 
-target-feature +bulk-memory \
 // RUN:   < /dev/null \
 // RUN:   | FileCheck -match-full-lines 
-check-prefixes=WEBASSEMBLY-CXX-ATOMICS %s
 //



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


LLVM build master will be restarted at 9pm PST today

2022-03-04 Thread Galina Kistanova via cfe-commits
Hello,

LLVM build master will be restarted at 9pm PST today.

Thanks

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


[PATCH] D121014: [WebAssembly] Check bulk-memory when adjusting lang opts

2022-03-04 Thread Douglas Yung via Phabricator via cfe-commits
dyung added a comment.

This change seems to be causing many bots to fail when running the clang :: 
Preprocessor/init.c test, can you take a look?

https://lab.llvm.org/buildbot/#/builders/139/builds/18081
https://lab.llvm.org/buildbot/#/builders/216/builds/881
https://lab.llvm.org/buildbot/#/builders/109/builds/33853


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121014

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


[PATCH] D119996: [safestack] Support safestack in stack size diagnostics

2022-03-04 Thread Paul Kirth via Phabricator via cfe-commits
paulkirth created this revision.
Herald added a subscriber: hiraditya.
paulkirth updated this revision to Diff 409705.
paulkirth added a comment.
paulkirth updated this revision to Diff 409797.
tstellar added a subscriber: serge-sans-paille.
paulkirth edited the summary of this revision.
paulkirth added reviewers: phosek, mcgrathr, tstellar.
Herald added a project: All.
paulkirth published this revision for review.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

Fix ARM test breakage


paulkirth added a comment.

Actually fix the ARM test


Current stack size diagnostics ignore the size of the unsafe stack.
This patch attaches the size of the static portion of the unsafe stack
to the function as metadata, which can be used by the backend to emit
diagnostics regarding stack usage.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D119996

Files:
  clang/test/Frontend/stack-usage-safestack.c
  llvm/include/llvm/CodeGen/MachineFrameInfo.h
  llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
  llvm/lib/CodeGen/MachineFunction.cpp
  llvm/lib/CodeGen/PrologEpilogInserter.cpp
  llvm/lib/CodeGen/SafeStack.cpp
  llvm/test/Transforms/SafeStack/ARM/debug.ll

Index: llvm/test/Transforms/SafeStack/ARM/debug.ll
===
--- llvm/test/Transforms/SafeStack/ARM/debug.ll
+++ llvm/test/Transforms/SafeStack/ARM/debug.ll
@@ -10,8 +10,8 @@
 ; void Capture(char*x);
 ; void f() { char c[16]; Capture(c); }
 
-; CHECK: !35 = !DILocation(line: 3, column: 11, scope: !17, inlinedAt: !36)
-; CHECK: !36 = distinct !DILocation(line: 6, scope: !27)
+; CHECK: !36 = !DILocation(line: 3, column: 11, scope: !17, inlinedAt: !37)
+; CHECK: !37 = distinct !DILocation(line: 6, scope: !27)
 
 @addr = common local_unnamed_addr global i8*** null, align 4, !dbg !0
 
Index: llvm/lib/CodeGen/SafeStack.cpp
===
--- llvm/lib/CodeGen/SafeStack.cpp
+++ llvm/lib/CodeGen/SafeStack.cpp
@@ -49,6 +49,7 @@
 #include "llvm/IR/IntrinsicInst.h"
 #include "llvm/IR/Intrinsics.h"
 #include "llvm/IR/MDBuilder.h"
+#include "llvm/IR/Metadata.h"
 #include "llvm/IR/Module.h"
 #include "llvm/IR/Type.h"
 #include "llvm/IR/Use.h"
@@ -645,6 +646,13 @@
   // FIXME: no need to update BasePointer in leaf functions.
   unsigned FrameSize = alignTo(SSL.getFrameSize(), StackAlignment);
 
+  MDBuilder MDB(F.getContext());
+  SmallVector Data;
+  Data.push_back(MDB.createString("unsafe-stack-size"));
+  Data.push_back(MDB.createConstant(ConstantInt::get(Int32Ty, FrameSize)));
+  MDNode *MD = MDTuple::get(F.getContext(), Data);
+  F.setMetadata(LLVMContext::MD_annotation, MD);
+
   // Update shadow stack pointer in the function epilogue.
   IRB.SetInsertPoint(BasePointer->getNextNode());
 
Index: llvm/lib/CodeGen/PrologEpilogInserter.cpp
===
--- llvm/lib/CodeGen/PrologEpilogInserter.cpp
+++ llvm/lib/CodeGen/PrologEpilogInserter.cpp
@@ -285,6 +285,9 @@
 assert(!Failed && "Invalid warn-stack-size fn attr value");
 (void)Failed;
   }
+  if (MF.getFunction().hasFnAttribute(Attribute::SafeStack)) {
+StackSize += MFI.getUnsafeStackSize();
+  }
   if (StackSize > Threshold) {
 DiagnosticInfoStackSize DiagStackSize(F, StackSize, Threshold, DS_Warning);
 F.getContext().diagnose(DiagStackSize);
Index: llvm/lib/CodeGen/MachineFunction.cpp
===
--- llvm/lib/CodeGen/MachineFunction.cpp
+++ llvm/lib/CodeGen/MachineFunction.cpp
@@ -109,6 +109,27 @@
   llvm_unreachable("Invalid machine function property");
 }
 
+void setUnsafeStackSize(const Function , MachineFrameInfo ) {
+  if (!F.hasFnAttribute(Attribute::SafeStack))
+return;
+
+  auto *Existing =
+  dyn_cast_or_null(F.getMetadata(LLVMContext::MD_annotation));
+
+  if (!Existing || Existing->getNumOperands() != 2)
+return;
+
+  auto *MetadataName = "unsafe-stack-size";
+  if (auto  = Existing->getOperand(0)) {
+if (cast(N.get())->getString() == MetadataName) {
+  if (auto  = Existing->getOperand(1)) {
+auto Val = mdconst::extract(Op)->getZExtValue();
+FrameInfo.setUnsafeStackSize(Val);
+  }
+}
+  }
+}
+
 // Pin the vtable to this file.
 void MachineFunction::Delegate::anchor() {}
 
@@ -177,6 +198,8 @@
   /*ForcedRealign=*/CanRealignSP &&
   F.hasFnAttribute(Attribute::StackAlignment));
 
+  setUnsafeStackSize(F, *FrameInfo);
+
   if (F.hasFnAttribute(Attribute::StackAlignment))
 FrameInfo->ensureMaxAlignment(*F.getFnStackAlign());
 
Index: llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
===
--- llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
+++ llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
@@ -1208,7 +1208,8 @@
 return;
 
   const MachineFrameInfo  = MF.getFrameInfo();
-  uint64_t StackSize = FrameInfo.getStackSize();
+  

[PATCH] D121029: [CMake] Replace `TARGET_TRIPLE` with `TOOLCHAIN_TARGET_TRIPLE` for Win-to-Arm cross toolchain cache file. NFC.

2022-03-04 Thread Vlad Vereschaka 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 rGd860ac5da6d7: [CMake] Replace `TARGET_TRIPLE` with 
`TOOLCHAIN_TARGET_TRIPLE` for Win-to-Arm… (authored by vvereschaka).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121029

Files:
  clang/cmake/caches/CrossWinToARMLinux.cmake

Index: clang/cmake/caches/CrossWinToARMLinux.cmake
===
--- clang/cmake/caches/CrossWinToARMLinux.cmake
+++ clang/cmake/caches/CrossWinToARMLinux.cmake
@@ -10,7 +10,7 @@
 #
 # Configure:
 #  cmake -G Ninja ^
-#   -DTARGET_TRIPLE=armv7-unknown-linux-gnueabihf ^
+#   -DTOOLCHAIN_TARGET_TRIPLE=armv7-unknown-linux-gnueabihf ^
 #   -DCMAKE_INSTALL_PREFIX=../install ^
 #   -DDEFAULT_SYSROOT= ^
 #   -DLLVM_AR=/bin/llvm-ar[.exe] ^
@@ -25,10 +25,10 @@
 #  cmake --build . --target check-llvm
 #  cmake --build . --target check-clang
 #  cmake --build . --target check-lld
-#  cmake --build . --target check-compiler-rt-
-#  cmake --build . --target check-cxxabi-
-#  cmake --build . --target check-unwind-
-#  cmake --build . --target check-cxx-
+#  cmake --build . --target check-compiler-rt-
+#  cmake --build . --target check-cxxabi-
+#  cmake --build . --target check-unwind-
+#  cmake --build . --target check-cxx-
 
 # LLVM_PROJECT_DIR is the path to the llvm-project directory.
 # The right way to compute it would probably be to use "${CMAKE_SOURCE_DIR}/../",
@@ -55,40 +55,40 @@
   set(LLVM_ENABLE_RUNTIMES "compiler-rt;libunwind;libcxxabi;libcxx" CACHE STRING "")
 endif()
 
-if (NOT DEFINED TARGET_TRIPLE)
-  set(TARGET_TRIPLE "armv7-unknown-linux-gnueabihf")
+if (NOT DEFINED TOOLCHAIN_TARGET_TRIPLE)
+  set(TOOLCHAIN_TARGET_TRIPLE "armv7-unknown-linux-gnueabihf")
 else()
   #NOTE: we must normalize specified target triple to a fully specified triple,
   # including the vendor part. It is necessary to synchronize the runtime library
   # installation path and operable target triple by Clang to get a correct runtime
   # path through `-print-runtime-dir` Clang option.
-  string(REPLACE "-" ";" TARGET_TRIPLE "${TARGET_TRIPLE}")
-  list(LENGTH TARGET_TRIPLE TARGET_TRIPLE_LEN)
-  if (TARGET_TRIPLE_LEN LESS 3)
+  string(REPLACE "-" ";" TOOLCHAIN_TARGET_TRIPLE "${TOOLCHAIN_TARGET_TRIPLE}")
+  list(LENGTH TOOLCHAIN_TARGET_TRIPLE TOOLCHAIN_TARGET_TRIPLE_LEN)
+  if (TOOLCHAIN_TARGET_TRIPLE_LEN LESS 3)
 message(FATAL_ERROR "invalid target triple")
   endif()
   # We suppose missed vendor's part.
-  if (TARGET_TRIPLE_LEN LESS 4)
-list(INSERT TARGET_TRIPLE 1 "unknown")
+  if (TOOLCHAIN_TARGET_TRIPLE_LEN LESS 4)
+list(INSERT TOOLCHAIN_TARGET_TRIPLE 1 "unknown")
   endif()
-  string(REPLACE ";" "-" TARGET_TRIPLE "${TARGET_TRIPLE}")
+  string(REPLACE ";" "-" TOOLCHAIN_TARGET_TRIPLE "${TOOLCHAIN_TARGET_TRIPLE}")
 endif()
 
 if (NOT DEFINED CMAKE_BUILD_TYPE)
   set(CMAKE_BUILD_TYPE "Release" CACHE STRING "")
 endif()
 
-message(STATUS "Toolchain target triple: ${TARGET_TRIPLE}")
+message(STATUS "Toolchain target triple: ${TOOLCHAIN_TARGET_TRIPLE}")
 
 set(CMAKE_CROSSCOMPILINGON CACHE BOOL "")
 set(CMAKE_CL_SHOWINCLUDES_PREFIX"Note: including file: " CACHE STRING "")
 # Required if COMPILER_RT_DEFAULT_TARGET_ONLY is ON
-set(CMAKE_C_COMPILER_TARGET "${TARGET_TRIPLE}" CACHE STRING "")
-set(CMAKE_CXX_COMPILER_TARGET   "${TARGET_TRIPLE}" CACHE STRING "")
+set(CMAKE_C_COMPILER_TARGET "${TOOLCHAIN_TARGET_TRIPLE}" CACHE STRING "")
+set(CMAKE_CXX_COMPILER_TARGET   "${TOOLCHAIN_TARGET_TRIPLE}" CACHE STRING "")
 
 set(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR  ON CACHE BOOL "")
-set(LLVM_DEFAULT_TARGET_TRIPLE  "${TARGET_TRIPLE}" CACHE STRING "")
-set(LLVM_TARGET_ARCH"${TARGET_TRIPLE}" CACHE STRING "")
+set(LLVM_DEFAULT_TARGET_TRIPLE  "${TOOLCHAIN_TARGET_TRIPLE}" CACHE STRING "")
+set(LLVM_TARGET_ARCH"${TOOLCHAIN_TARGET_TRIPLE}" CACHE STRING "")
 set(LLVM_LIT_ARGS   "-vv ${LLVM_LIT_ARGS}" CACHE STRING "" FORCE)
 
 set(CLANG_DEFAULT_LINKER"lld" CACHE STRING "")
@@ -104,56 +104,56 @@
   set(RUNTIMES_INSTALL_RPATH"\$ORIGIN/../lib;${CMAKE_INSTALL_PREFIX}/lib")
 endif()
 
-set(LLVM_BUILTIN_TARGETS"${TARGET_TRIPLE}" CACHE STRING "")
+set(LLVM_BUILTIN_TARGETS"${TOOLCHAIN_TARGET_TRIPLE}" CACHE STRING "")
 
-set(BUILTINS_${TARGET_TRIPLE}_CMAKE_SYSTEM_NAME "Linux" CACHE STRING "")
-set(BUILTINS_${TARGET_TRIPLE}_CMAKE_SYSROOT "${DEFAULT_SYSROOT}"  CACHE STRING "")
-set(BUILTINS_${TARGET_TRIPLE}_CMAKE_INSTALL_RPATH   "${RUNTIMES_INSTALL_RPATH}"  CACHE STRING "")

[clang] d860ac5 - [CMake] Replace `TARGET_TRIPLE` with `TOOLCHAIN_TARGET_TRIPLE` for Win-to-Arm cross toolchain cache file. NFC.

2022-03-04 Thread Vladimir Vereschaka via cfe-commits

Author: Vladimir Vereschaka
Date: 2022-03-04T16:39:28-08:00
New Revision: d860ac5da6d71dd759d347a3c7d5e63705443694

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

LOG: [CMake] Replace `TARGET_TRIPLE` with `TOOLCHAIN_TARGET_TRIPLE` for 
Win-to-Arm cross toolchain cache file. NFC.

Avoid using TARGET_TRIPLE argument for the cross toolchain cmake cache file and 
replace it
with TOOLCHAIN_TARGET_TRIPLE.

Reference: https://reviews.llvm.org/D119918

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

Added: 


Modified: 
clang/cmake/caches/CrossWinToARMLinux.cmake

Removed: 




diff  --git a/clang/cmake/caches/CrossWinToARMLinux.cmake 
b/clang/cmake/caches/CrossWinToARMLinux.cmake
index 5e62d01b297c2..63461ea2ddbe3 100644
--- a/clang/cmake/caches/CrossWinToARMLinux.cmake
+++ b/clang/cmake/caches/CrossWinToARMLinux.cmake
@@ -10,7 +10,7 @@
 #
 # Configure:
 #  cmake -G Ninja ^
-#   -DTARGET_TRIPLE=armv7-unknown-linux-gnueabihf ^
+#   -DTOOLCHAIN_TARGET_TRIPLE=armv7-unknown-linux-gnueabihf ^
 #   -DCMAKE_INSTALL_PREFIX=../install ^
 #   -DDEFAULT_SYSROOT= ^
 #   -DLLVM_AR=/bin/llvm-ar[.exe] ^
@@ -25,10 +25,10 @@
 #  cmake --build . --target check-llvm
 #  cmake --build . --target check-clang
 #  cmake --build . --target check-lld
-#  cmake --build . --target check-compiler-rt-
-#  cmake --build . --target check-cxxabi-
-#  cmake --build . --target check-unwind-
-#  cmake --build . --target check-cxx-
+#  cmake --build . --target check-compiler-rt-
+#  cmake --build . --target check-cxxabi-
+#  cmake --build . --target check-unwind-
+#  cmake --build . --target check-cxx-
 
 # LLVM_PROJECT_DIR is the path to the llvm-project directory.
 # The right way to compute it would probably be to use 
"${CMAKE_SOURCE_DIR}/../",
@@ -55,40 +55,40 @@ if (NOT DEFINED LLVM_ENABLE_RUNTIMES)
   set(LLVM_ENABLE_RUNTIMES "compiler-rt;libunwind;libcxxabi;libcxx" CACHE 
STRING "")
 endif()
 
-if (NOT DEFINED TARGET_TRIPLE)
-  set(TARGET_TRIPLE "armv7-unknown-linux-gnueabihf")
+if (NOT DEFINED TOOLCHAIN_TARGET_TRIPLE)
+  set(TOOLCHAIN_TARGET_TRIPLE "armv7-unknown-linux-gnueabihf")
 else()
   #NOTE: we must normalize specified target triple to a fully specified triple,
   # including the vendor part. It is necessary to synchronize the runtime 
library
   # installation path and operable target triple by Clang to get a correct 
runtime
   # path through `-print-runtime-dir` Clang option.
-  string(REPLACE "-" ";" TARGET_TRIPLE "${TARGET_TRIPLE}")
-  list(LENGTH TARGET_TRIPLE TARGET_TRIPLE_LEN)
-  if (TARGET_TRIPLE_LEN LESS 3)
+  string(REPLACE "-" ";" TOOLCHAIN_TARGET_TRIPLE "${TOOLCHAIN_TARGET_TRIPLE}")
+  list(LENGTH TOOLCHAIN_TARGET_TRIPLE TOOLCHAIN_TARGET_TRIPLE_LEN)
+  if (TOOLCHAIN_TARGET_TRIPLE_LEN LESS 3)
 message(FATAL_ERROR "invalid target triple")
   endif()
   # We suppose missed vendor's part.
-  if (TARGET_TRIPLE_LEN LESS 4)
-list(INSERT TARGET_TRIPLE 1 "unknown")
+  if (TOOLCHAIN_TARGET_TRIPLE_LEN LESS 4)
+list(INSERT TOOLCHAIN_TARGET_TRIPLE 1 "unknown")
   endif()
-  string(REPLACE ";" "-" TARGET_TRIPLE "${TARGET_TRIPLE}")
+  string(REPLACE ";" "-" TOOLCHAIN_TARGET_TRIPLE "${TOOLCHAIN_TARGET_TRIPLE}")
 endif()
 
 if (NOT DEFINED CMAKE_BUILD_TYPE)
   set(CMAKE_BUILD_TYPE "Release" CACHE STRING "")
 endif()
 
-message(STATUS "Toolchain target triple: ${TARGET_TRIPLE}")
+message(STATUS "Toolchain target triple: ${TOOLCHAIN_TARGET_TRIPLE}")
 
 set(CMAKE_CROSSCOMPILINGON CACHE BOOL "")
 set(CMAKE_CL_SHOWINCLUDES_PREFIX"Note: including file: " CACHE 
STRING "")
 # Required if COMPILER_RT_DEFAULT_TARGET_ONLY is ON
-set(CMAKE_C_COMPILER_TARGET "${TARGET_TRIPLE}" CACHE STRING "")
-set(CMAKE_CXX_COMPILER_TARGET   "${TARGET_TRIPLE}" CACHE STRING "")
+set(CMAKE_C_COMPILER_TARGET "${TOOLCHAIN_TARGET_TRIPLE}" CACHE 
STRING "")
+set(CMAKE_CXX_COMPILER_TARGET   "${TOOLCHAIN_TARGET_TRIPLE}" CACHE 
STRING "")
 
 set(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR  ON CACHE BOOL "")
-set(LLVM_DEFAULT_TARGET_TRIPLE  "${TARGET_TRIPLE}" CACHE STRING "")
-set(LLVM_TARGET_ARCH"${TARGET_TRIPLE}" CACHE STRING "")
+set(LLVM_DEFAULT_TARGET_TRIPLE  "${TOOLCHAIN_TARGET_TRIPLE}" CACHE 
STRING "")
+set(LLVM_TARGET_ARCH"${TOOLCHAIN_TARGET_TRIPLE}" CACHE 
STRING "")
 set(LLVM_LIT_ARGS   "-vv ${LLVM_LIT_ARGS}" CACHE 
STRING "" FORCE)
 
 set(CLANG_DEFAULT_LINKER"lld" CACHE STRING "")
@@ -104,56 +104,56 @@ if (NOT DEFINED RUNTIMES_INSTALL_RPATH)
   set(RUNTIMES_INSTALL_RPATH
"\$ORIGIN/../lib;${CMAKE_INSTALL_PREFIX}/lib")
 endif()
 
-set(LLVM_BUILTIN_TARGETS

[PATCH] D120984: [clang][dataflow] Extend flow conditions from block terminators

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



Comment at: clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp:123
+  if (Constraints1.empty() || Constraints2.empty()) {
+// Disjunction of empty set and non-empty set is represented as empty set.
+return JoinedConstraints;

xazax.hun wrote:
> Is this actually correct? Or did you mean `Conjunction`?
Oh, sorry. Just realized the empty set is interpreted as `true`. In this case 
this is correct. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120984

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


[PATCH] D121029: [CMake] Replace `TARGET_TRIPLE` with `TOOLCHAIN_TARGET_TRIPLE` for Win-to-Arm cross toolchain cache file.

2022-03-04 Thread Vlad Vereschaka via Phabricator via cfe-commits
vvereschaka created this revision.
vvereschaka added a reviewer: vvereschaka.
Herald added subscribers: kristof.beyls, mgorny.
Herald added a project: All.
vvereschaka requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Avoid using `TARGET_TRIPLE` argument for the cross toolchain cmake cache file 
and replace it with `TOOLCHAIN_TARGET_TRIPLE` argument.

Reference: https://reviews.llvm.org/D119918


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D121029

Files:
  clang/cmake/caches/CrossWinToARMLinux.cmake

Index: clang/cmake/caches/CrossWinToARMLinux.cmake
===
--- clang/cmake/caches/CrossWinToARMLinux.cmake
+++ clang/cmake/caches/CrossWinToARMLinux.cmake
@@ -10,7 +10,7 @@
 #
 # Configure:
 #  cmake -G Ninja ^
-#   -DTARGET_TRIPLE=armv7-unknown-linux-gnueabihf ^
+#   -DTOOLCHAIN_TARGET_TRIPLE=armv7-unknown-linux-gnueabihf ^
 #   -DCMAKE_INSTALL_PREFIX=../install ^
 #   -DDEFAULT_SYSROOT= ^
 #   -DLLVM_AR=/bin/llvm-ar[.exe] ^
@@ -25,10 +25,10 @@
 #  cmake --build . --target check-llvm
 #  cmake --build . --target check-clang
 #  cmake --build . --target check-lld
-#  cmake --build . --target check-compiler-rt-
-#  cmake --build . --target check-cxxabi-
-#  cmake --build . --target check-unwind-
-#  cmake --build . --target check-cxx-
+#  cmake --build . --target check-compiler-rt-
+#  cmake --build . --target check-cxxabi-
+#  cmake --build . --target check-unwind-
+#  cmake --build . --target check-cxx-
 
 # LLVM_PROJECT_DIR is the path to the llvm-project directory.
 # The right way to compute it would probably be to use "${CMAKE_SOURCE_DIR}/../",
@@ -55,40 +55,40 @@
   set(LLVM_ENABLE_RUNTIMES "compiler-rt;libunwind;libcxxabi;libcxx" CACHE STRING "")
 endif()
 
-if (NOT DEFINED TARGET_TRIPLE)
-  set(TARGET_TRIPLE "armv7-unknown-linux-gnueabihf")
+if (NOT DEFINED TOOLCHAIN_TARGET_TRIPLE)
+  set(TOOLCHAIN_TARGET_TRIPLE "armv7-unknown-linux-gnueabihf")
 else()
   #NOTE: we must normalize specified target triple to a fully specified triple,
   # including the vendor part. It is necessary to synchronize the runtime library
   # installation path and operable target triple by Clang to get a correct runtime
   # path through `-print-runtime-dir` Clang option.
-  string(REPLACE "-" ";" TARGET_TRIPLE "${TARGET_TRIPLE}")
-  list(LENGTH TARGET_TRIPLE TARGET_TRIPLE_LEN)
-  if (TARGET_TRIPLE_LEN LESS 3)
+  string(REPLACE "-" ";" TOOLCHAIN_TARGET_TRIPLE "${TOOLCHAIN_TARGET_TRIPLE}")
+  list(LENGTH TOOLCHAIN_TARGET_TRIPLE TOOLCHAIN_TARGET_TRIPLE_LEN)
+  if (TOOLCHAIN_TARGET_TRIPLE_LEN LESS 3)
 message(FATAL_ERROR "invalid target triple")
   endif()
   # We suppose missed vendor's part.
-  if (TARGET_TRIPLE_LEN LESS 4)
-list(INSERT TARGET_TRIPLE 1 "unknown")
+  if (TOOLCHAIN_TARGET_TRIPLE_LEN LESS 4)
+list(INSERT TOOLCHAIN_TARGET_TRIPLE 1 "unknown")
   endif()
-  string(REPLACE ";" "-" TARGET_TRIPLE "${TARGET_TRIPLE}")
+  string(REPLACE ";" "-" TOOLCHAIN_TARGET_TRIPLE "${TOOLCHAIN_TARGET_TRIPLE}")
 endif()
 
 if (NOT DEFINED CMAKE_BUILD_TYPE)
   set(CMAKE_BUILD_TYPE "Release" CACHE STRING "")
 endif()
 
-message(STATUS "Toolchain target triple: ${TARGET_TRIPLE}")
+message(STATUS "Toolchain target triple: ${TOOLCHAIN_TARGET_TRIPLE}")
 
 set(CMAKE_CROSSCOMPILINGON CACHE BOOL "")
 set(CMAKE_CL_SHOWINCLUDES_PREFIX"Note: including file: " CACHE STRING "")
 # Required if COMPILER_RT_DEFAULT_TARGET_ONLY is ON
-set(CMAKE_C_COMPILER_TARGET "${TARGET_TRIPLE}" CACHE STRING "")
-set(CMAKE_CXX_COMPILER_TARGET   "${TARGET_TRIPLE}" CACHE STRING "")
+set(CMAKE_C_COMPILER_TARGET "${TOOLCHAIN_TARGET_TRIPLE}" CACHE STRING "")
+set(CMAKE_CXX_COMPILER_TARGET   "${TOOLCHAIN_TARGET_TRIPLE}" CACHE STRING "")
 
 set(LLVM_ENABLE_PER_TARGET_RUNTIME_DIR  ON CACHE BOOL "")
-set(LLVM_DEFAULT_TARGET_TRIPLE  "${TARGET_TRIPLE}" CACHE STRING "")
-set(LLVM_TARGET_ARCH"${TARGET_TRIPLE}" CACHE STRING "")
+set(LLVM_DEFAULT_TARGET_TRIPLE  "${TOOLCHAIN_TARGET_TRIPLE}" CACHE STRING "")
+set(LLVM_TARGET_ARCH"${TOOLCHAIN_TARGET_TRIPLE}" CACHE STRING "")
 set(LLVM_LIT_ARGS   "-vv ${LLVM_LIT_ARGS}" CACHE STRING "" FORCE)
 
 set(CLANG_DEFAULT_LINKER"lld" CACHE STRING "")
@@ -104,56 +104,56 @@
   set(RUNTIMES_INSTALL_RPATH"\$ORIGIN/../lib;${CMAKE_INSTALL_PREFIX}/lib")
 endif()
 
-set(LLVM_BUILTIN_TARGETS"${TARGET_TRIPLE}" CACHE STRING "")
+set(LLVM_BUILTIN_TARGETS"${TOOLCHAIN_TARGET_TRIPLE}" CACHE STRING "")
 
-set(BUILTINS_${TARGET_TRIPLE}_CMAKE_SYSTEM_NAME "Linux" CACHE STRING "")
-set(BUILTINS_${TARGET_TRIPLE}_CMAKE_SYSROOT "${DEFAULT_SYSROOT}"  CACHE STRING "")

[PATCH] D121014: [WebAssembly] Check bulk-memory when adjusting lang opts

2022-03-04 Thread Thomas Lively 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 rG3be9e0ba972c: [WebAssembly] Check bulk-memory when adjusting 
lang opts (authored by tlively).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D121014

Files:
  clang/lib/Basic/Targets/WebAssembly.cpp
  clang/test/CodeGenCXX/static-init-wasm.cpp


Index: clang/test/CodeGenCXX/static-init-wasm.cpp
===
--- clang/test/CodeGenCXX/static-init-wasm.cpp
+++ clang/test/CodeGenCXX/static-init-wasm.cpp
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -emit-llvm -triple=wasm32-unknown-unknown -target-feature 
+atomics -o - %s \
+// RUN: %clang_cc1 -emit-llvm -triple=wasm32-unknown-unknown -target-feature 
+atomics -target-feature +bulk-memory -o - %s \
 // RUN:   | FileCheck %s -check-prefix=WEBASSEMBLY32
-// RUN: %clang_cc1 -emit-llvm -triple=wasm64-unknown-unknown -target-feature 
+atomics -o - %s \
+// RUN: %clang_cc1 -emit-llvm -triple=wasm64-unknown-unknown -target-feature 
+atomics -target-feature +bulk-memory -o - %s \
 // RUN:   | FileCheck %s -check-prefix=WEBASSEMBLY64
 
 // Test that we don't create common blocks.
@@ -53,9 +53,9 @@
 // WEBASSEMBLY64: define internal void @_GLOBAL__sub_I_static_init_wasm.cpp() 
#3 {
 // WEBASSEMBLY64: call void @__cxx_global_var_init()
 
-// RUN: %clang_cc1 -emit-llvm -triple=wasm32-unknown-unknown -o - %s \
+// RUN: %clang_cc1 -emit-llvm -triple=wasm32-unknown-unknown -target-feature 
+bulk-memory -o - %s \
 // RUN:   | FileCheck %s -check-prefix=NOATOMICS
-// RUN: %clang_cc1 -emit-llvm -triple=wasm64-unknown-unknown -o - %s \
+// RUN: %clang_cc1 -emit-llvm -triple=wasm64-unknown-unknown -target-feature 
+bulk-memory -o - %s \
 // RUN:   | FileCheck %s -check-prefix=NOATOMICS
 
 // NOATOMICS-LABEL: @_Z1gv()
@@ -66,3 +66,17 @@
 // NOATOMICS-NOT:   __cxa_guard_acquire
 // NOATOMICS:   [[END]]:
 // NOATOMICS-NEXT:  ret void
+
+// RUN: %clang_cc1 -emit-llvm -triple=wasm32-unknown-unknown -target-feature 
+atomics -o - %s \
+// RUN:   | FileCheck %s -check-prefix=NOBULKMEM
+// RUN: %clang_cc1 -emit-llvm -triple=wasm64-unknown-unknown -target-feature 
+atomics -o - %s \
+// RUN:   | FileCheck %s -check-prefix=NOBULKMEM
+
+// NOBULKMEM-LABEL: @_Z1gv()
+// NOBULKMEM:   %[[R0:.+]] = load i8, i8* @_ZGVZ1gvE1a, align 1
+// NOBULKMEM-NEXT:  %guard.uninitialized = icmp eq i8 %[[R0]], 0
+// NOBULKMEM-NEXT:  br i1 %guard.uninitialized, label %[[CHECK:.+]], label 
%[[END:.+]],
+// NOBULKMEM:   [[CHECK]]:
+// NOBULKMEM-NOT:   __cxa_guard_acquire
+// NOBULKMEM:   [[END]]:
+// NOBULKMEM-NEXT:  ret void
Index: clang/lib/Basic/Targets/WebAssembly.cpp
===
--- clang/lib/Basic/Targets/WebAssembly.cpp
+++ clang/lib/Basic/Targets/WebAssembly.cpp
@@ -256,9 +256,10 @@
 void WebAssemblyTargetInfo::adjust(DiagnosticsEngine ,
LangOptions ) {
   TargetInfo::adjust(Diags, Opts);
-  // If the Atomics feature isn't available, turn off POSIXThreads and
-  // ThreadModel, so that we don't predefine _REENTRANT or __STDCPP_THREADS__.
-  if (!HasAtomics) {
+  // Turn off POSIXThreads and ThreadModel so that we don't predefine 
_REENTRANT
+  // or __STDCPP_THREADS__ if we will eventually end up stripping atomics
+  // because they are unsupported.
+  if (!HasAtomics || !HasBulkMemory) {
 Opts.POSIXThreads = false;
 Opts.setThreadModel(LangOptions::ThreadModelKind::Single);
 Opts.ThreadsafeStatics = false;


Index: clang/test/CodeGenCXX/static-init-wasm.cpp
===
--- clang/test/CodeGenCXX/static-init-wasm.cpp
+++ clang/test/CodeGenCXX/static-init-wasm.cpp
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -emit-llvm -triple=wasm32-unknown-unknown -target-feature +atomics -o - %s \
+// RUN: %clang_cc1 -emit-llvm -triple=wasm32-unknown-unknown -target-feature +atomics -target-feature +bulk-memory -o - %s \
 // RUN:   | FileCheck %s -check-prefix=WEBASSEMBLY32
-// RUN: %clang_cc1 -emit-llvm -triple=wasm64-unknown-unknown -target-feature +atomics -o - %s \
+// RUN: %clang_cc1 -emit-llvm -triple=wasm64-unknown-unknown -target-feature +atomics -target-feature +bulk-memory -o - %s \
 // RUN:   | FileCheck %s -check-prefix=WEBASSEMBLY64
 
 // Test that we don't create common blocks.
@@ -53,9 +53,9 @@
 // WEBASSEMBLY64: define internal void @_GLOBAL__sub_I_static_init_wasm.cpp() #3 {
 // WEBASSEMBLY64: call void @__cxx_global_var_init()
 
-// RUN: %clang_cc1 -emit-llvm -triple=wasm32-unknown-unknown -o - %s \
+// RUN: %clang_cc1 -emit-llvm -triple=wasm32-unknown-unknown -target-feature +bulk-memory -o - %s \
 // RUN:   | FileCheck %s -check-prefix=NOATOMICS
-// RUN: %clang_cc1 -emit-llvm -triple=wasm64-unknown-unknown -o - %s \
+// RUN: %clang_cc1 -emit-llvm 

[clang] 3be9e0b - [WebAssembly] Check bulk-memory when adjusting lang opts

2022-03-04 Thread Thomas Lively via cfe-commits

Author: Thomas Lively
Date: 2022-03-04T16:07:16-08:00
New Revision: 3be9e0ba972cc3486971f745a606e2c44472b655

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

LOG: [WebAssembly] Check bulk-memory when adjusting lang opts

We previously had logic to disable pthreads, set the ThreadModel to Single, and
disable thread-safe statics when the atomics target features is disabled, since
that means that the resulting program will not be used in a threaded context.
Similarly check for the presence of the bulk-memory feature, since that is also
necessary to produce multithreaded programs.

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

Added: 


Modified: 
clang/lib/Basic/Targets/WebAssembly.cpp
clang/test/CodeGenCXX/static-init-wasm.cpp

Removed: 




diff  --git a/clang/lib/Basic/Targets/WebAssembly.cpp 
b/clang/lib/Basic/Targets/WebAssembly.cpp
index 023c03c7cf5c0..18ff109bf2d39 100644
--- a/clang/lib/Basic/Targets/WebAssembly.cpp
+++ b/clang/lib/Basic/Targets/WebAssembly.cpp
@@ -256,9 +256,10 @@ ArrayRef 
WebAssemblyTargetInfo::getTargetBuiltins() const {
 void WebAssemblyTargetInfo::adjust(DiagnosticsEngine ,
LangOptions ) {
   TargetInfo::adjust(Diags, Opts);
-  // If the Atomics feature isn't available, turn off POSIXThreads and
-  // ThreadModel, so that we don't predefine _REENTRANT or __STDCPP_THREADS__.
-  if (!HasAtomics) {
+  // Turn off POSIXThreads and ThreadModel so that we don't predefine 
_REENTRANT
+  // or __STDCPP_THREADS__ if we will eventually end up stripping atomics
+  // because they are unsupported.
+  if (!HasAtomics || !HasBulkMemory) {
 Opts.POSIXThreads = false;
 Opts.setThreadModel(LangOptions::ThreadModelKind::Single);
 Opts.ThreadsafeStatics = false;

diff  --git a/clang/test/CodeGenCXX/static-init-wasm.cpp 
b/clang/test/CodeGenCXX/static-init-wasm.cpp
index 0a066de616fa9..3742976ca4947 100644
--- a/clang/test/CodeGenCXX/static-init-wasm.cpp
+++ b/clang/test/CodeGenCXX/static-init-wasm.cpp
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -emit-llvm -triple=wasm32-unknown-unknown -target-feature 
+atomics -o - %s \
+// RUN: %clang_cc1 -emit-llvm -triple=wasm32-unknown-unknown -target-feature 
+atomics -target-feature +bulk-memory -o - %s \
 // RUN:   | FileCheck %s -check-prefix=WEBASSEMBLY32
-// RUN: %clang_cc1 -emit-llvm -triple=wasm64-unknown-unknown -target-feature 
+atomics -o - %s \
+// RUN: %clang_cc1 -emit-llvm -triple=wasm64-unknown-unknown -target-feature 
+atomics -target-feature +bulk-memory -o - %s \
 // RUN:   | FileCheck %s -check-prefix=WEBASSEMBLY64
 
 // Test that we don't create common blocks.
@@ -53,9 +53,9 @@ A theA;
 // WEBASSEMBLY64: define internal void @_GLOBAL__sub_I_static_init_wasm.cpp() 
#3 {
 // WEBASSEMBLY64: call void @__cxx_global_var_init()
 
-// RUN: %clang_cc1 -emit-llvm -triple=wasm32-unknown-unknown -o - %s \
+// RUN: %clang_cc1 -emit-llvm -triple=wasm32-unknown-unknown -target-feature 
+bulk-memory -o - %s \
 // RUN:   | FileCheck %s -check-prefix=NOATOMICS
-// RUN: %clang_cc1 -emit-llvm -triple=wasm64-unknown-unknown -o - %s \
+// RUN: %clang_cc1 -emit-llvm -triple=wasm64-unknown-unknown -target-feature 
+bulk-memory -o - %s \
 // RUN:   | FileCheck %s -check-prefix=NOATOMICS
 
 // NOATOMICS-LABEL: @_Z1gv()
@@ -66,3 +66,17 @@ A theA;
 // NOATOMICS-NOT:   __cxa_guard_acquire
 // NOATOMICS:   [[END]]:
 // NOATOMICS-NEXT:  ret void
+
+// RUN: %clang_cc1 -emit-llvm -triple=wasm32-unknown-unknown -target-feature 
+atomics -o - %s \
+// RUN:   | FileCheck %s -check-prefix=NOBULKMEM
+// RUN: %clang_cc1 -emit-llvm -triple=wasm64-unknown-unknown -target-feature 
+atomics -o - %s \
+// RUN:   | FileCheck %s -check-prefix=NOBULKMEM
+
+// NOBULKMEM-LABEL: @_Z1gv()
+// NOBULKMEM:   %[[R0:.+]] = load i8, i8* @_ZGVZ1gvE1a, align 1
+// NOBULKMEM-NEXT:  %guard.uninitialized = icmp eq i8 %[[R0]], 0
+// NOBULKMEM-NEXT:  br i1 %guard.uninitialized, label %[[CHECK:.+]], label 
%[[END:.+]],
+// NOBULKMEM:   [[CHECK]]:
+// NOBULKMEM-NOT:   __cxa_guard_acquire
+// NOBULKMEM:   [[END]]:
+// NOBULKMEM-NEXT:  ret void



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


[PATCH] D119601: [analyzer] Refactor makeNull to makeNullWithWidth (NFC)

2022-03-04 Thread Vince Bridgers via Phabricator via cfe-commits
vabridgers added a comment.

Is it ok to land this change? Or shall we continue to wait on @NoQ ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119601

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


[PATCH] D120134: [analyzer] refactor makeIntValWithPtrWidth, remove getZeroWithPtrWidth (NFC)

2022-03-04 Thread Vince Bridgers via Phabricator via cfe-commits
vabridgers added a comment.

Is it ok to land this change? Or shall we continue to wait on @NoQ ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120134

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


[PATCH] D119910: [clang][debug] port clang-cl /JMC flag to ELF

2022-03-04 Thread Yuanfang Chen via Phabricator via cfe-commits
ychen added inline comments.



Comment at: llvm/test/Instrumentation/JustMyCode/jmc-instrument-elf.ll:1
-; REQUIRES: system-windows
-; RUN: opt -jmc-instrument -mtriple=x86_64-pc-windows-msvc  -S < %s | 
FileCheck %s
-; RUN: opt -jmc-instrument -mtriple=aarch64-pc-windows-msvc -S < %s | 
FileCheck %s
-; RUN: opt -jmc-instrument -mtriple=arm-pc-windows-msvc -S < %s | 
FileCheck %s
+; REQUIRES: system-linux
+; RUN: opt -jmc-instrument -mtriple=x86_64-unknown-linux-gnu  -S < %s | 
FileCheck %s

ychen wrote:
> rnk wrote:
> > ychen wrote:
> > > rnk wrote:
> > > > ychen wrote:
> > > > > rnk wrote:
> > > > > > Please remove the REQUIRES line, this test should pass on Windows, 
> > > > > > and the other test should pass on Linux as well. Neither of these 
> > > > > > tests depend on anything from the system.
> > > > > Yeah, this is a little tricky. It is about the host rather than the 
> > > > > target. The flag symbol name is computed using `sys::path` functions. 
> > > > > It is different between Windows and Linux. For testing purposes, I 
> > > > > need to anchor them to a specific system to check the result. I 
> > > > > could've made this `; REQUIRES: system-windows` and check the result, 
> > > > > I thought it is more intuitive to test the ELF on Linux.
> > > > That seems like a bug. LLVM optimization and code generation should not 
> > > > depend on the host. This is a requirement for distributed build 
> > > > systems, which may migrate inputs to other machines, cross compile, and 
> > > > expect the results to match local compilation.
> > > The symbol names are host-dependent. It does not depend on the host to 
> > > work correctly though. It works on both Windows and Linux.
> > Yes, you say they are host dependent, I see that, but I don't think that's 
> > a requirement. `opt` should be a pure function of its inputs. The paths are 
> > in the debug info, it shouldn't let the environment leak into the 
> > compilation.
> Great point. This is not ideal in principle. For the distributed build, this 
> may break if the remote and host compilation uses different environments like 
> Windows/Linux. I'll create a follow-up patch. 
Filed https://github.com/llvm/llvm-project/issues/54219 to follow up on the bug.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119910

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


[PATCH] D120931: [clang-format] Fix namespace format when the name is a macro expansion

2022-03-04 Thread Zequan Wu via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGbe5705767aad: [clang-format] fix namepsace format when the 
name is macro expansion (authored by zequanwu).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120931

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

Index: clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp
===
--- clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp
+++ clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp
@@ -68,6 +68,127 @@
 "int i;\n"
 "int j;\n"
 "}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace M(x)",
+fixNamespaceEndComments("#define M(x) x##x\n"
+"namespace M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace A::M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A::M(x)",
+fixNamespaceEndComments("#define M(x) x##x\n"
+"namespace A::M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace M(x)::A {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace M(x)::A",
+fixNamespaceEndComments("#define M(x) x##x\n"
+"namespace M(x)::A {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace A::inline M(x)::B {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A::inline M(x)::B",
+fixNamespaceEndComments("#define M(x) x##x\n"
+"namespace A::inline M(x)::B {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace [[deprecated(\"foo\")]] A::inline M(x)::A {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A::inline M(x)::A",
+fixNamespaceEndComments(
+"#define M(x) x##x\n"
+"namespace [[deprecated(\"foo\")]] A::inline M(x)::A {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ(
+  "namespace /* comment */ [[deprecated(\"foo\")]] /* comment */ A {\n"
+  "int i;\n"
+  "int j;\n"
+  "}// namespace A",
+  fixNamespaceEndComments(
+  "namespace /* comment */ [[deprecated(\"foo\")]] /* comment */ A {\n"
+  "int i;\n"
+  "int j;\n"
+  "}"));
+  EXPECT_EQ("namespace /* comment */ [[deprecated(\"foo\")]] A {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A",
+fixNamespaceEndComments(
+"namespace /* comment */ [[deprecated(\"foo\")]] A {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ(
+  "#define M(x) x##x\n"
+  "namespace /* comment */ [[deprecated(\"foo\")]] /* comment */ M(x) {\n"
+  "int i;\n"
+  "int j;\n"
+  "}// namespace M(x)",
+  fixNamespaceEndComments("#define M(x) x##x\n"
+  "namespace /* comment */ "
+  "[[deprecated(\"foo\")]] /* comment */ M(x) {\n"
+  "int i;\n"
+  "int j;\n"
+  "}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace /* comment */ [[deprecated(\"foo\")]] /* comment */ "
+"A::M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A::M(x)",
+fixNamespaceEndComments(
+"#define M(x) x##x\n"
+"namespace /* comment */ "
+"[[deprecated(\"foo\")]] /* comment */ A::M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace /* comment */ [[deprecated(\"foo\")]] /* comment */ "
+"M(x) /* comment */ {\n"
+"int i;\n"
+"int 

[clang] be57057 - [clang-format] fix namepsace format when the name is macro expansion

2022-03-04 Thread Zequan Wu via cfe-commits

Author: Zequan Wu
Date: 2022-03-04T16:01:17-08:00
New Revision: be5705767aad8d8eafd40225f7dba8e7e661c6b5

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

LOG: [clang-format] fix namepsace format when the name is macro expansion

Originally filed at crbug.com/1184570.
When the name of a namespace is a macro that takes arguments,
- It fixed the indentation.
- It fixed the namepsace end comments.

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

Added: 


Modified: 
clang/lib/Format/NamespaceEndCommentsFixer.cpp
clang/lib/Format/UnwrappedLineParser.cpp
clang/unittests/Format/FormatTest.cpp
clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp

Removed: 




diff  --git a/clang/lib/Format/NamespaceEndCommentsFixer.cpp 
b/clang/lib/Format/NamespaceEndCommentsFixer.cpp
index 65f965548da37..e527402e33074 100644
--- a/clang/lib/Format/NamespaceEndCommentsFixer.cpp
+++ b/clang/lib/Format/NamespaceEndCommentsFixer.cpp
@@ -40,12 +40,32 @@ std::string computeName(const FormatToken *NamespaceTok) {
   Tok = Tok->getNextNonComment();
 }
   } else {
+// Skip attributes.
+if (Tok && Tok->is(tok::l_square)) {
+  for (int NestLevel = 1; NestLevel > 0;) {
+Tok = Tok->getNextNonComment();
+if (!Tok)
+  break;
+if (Tok->is(tok::l_square))
+  ++NestLevel;
+else if (Tok->is(tok::r_square))
+  --NestLevel;
+  }
+  if (Tok)
+Tok = Tok->getNextNonComment();
+}
+
+// Use the string after `namespace` as a name candidate until `{` or `::` 
or
+// `(`. If the name is empty, use the candicate.
+std::string FirstNSName;
 // For `namespace [[foo]] A::B::inline C {` or
 // `namespace MACRO1 MACRO2 A::B::inline C {`, returns "A::B::inline C".
-// Peek for the first '::' (or '{') and then return all tokens from one
-// token before that up until the '{'.
+// Peek for the first '::' (or '{' or '(')) and then return all tokens from
+// one token before that up until the '{'. A '(' might be a macro with
+// arguments.
 const FormatToken *FirstNSTok = Tok;
-while (Tok && !Tok->is(tok::l_brace) && !Tok->is(tok::coloncolon)) {
+while (Tok && !Tok->isOneOf(tok::l_brace, tok::coloncolon, tok::l_paren)) {
+  FirstNSName += FirstNSTok->TokenText;
   FirstNSTok = Tok;
   Tok = Tok->getNextNonComment();
 }
@@ -57,6 +77,8 @@ std::string computeName(const FormatToken *NamespaceTok) {
 name += " ";
   Tok = Tok->getNextNonComment();
 }
+if (name.empty())
+  name = FirstNSName;
   }
   return name;
 }

diff  --git a/clang/lib/Format/UnwrappedLineParser.cpp 
b/clang/lib/Format/UnwrappedLineParser.cpp
index 46562f7ae8b84..68b0e2a630bcd 100644
--- a/clang/lib/Format/UnwrappedLineParser.cpp
+++ b/clang/lib/Format/UnwrappedLineParser.cpp
@@ -2597,10 +2597,12 @@ void UnwrappedLineParser::parseNamespace() {
 parseParens();
   } else {
 while (FormatTok->isOneOf(tok::identifier, tok::coloncolon, tok::kw_inline,
-  tok::l_square, tok::period) ||
+  tok::l_square, tok::period, tok::l_paren) ||
(Style.isCSharp() && FormatTok->is(tok::kw_union)))
   if (FormatTok->is(tok::l_square))
 parseSquare();
+  else if (FormatTok->is(tok::l_paren))
+parseParens();
   else
 nextToken();
   }

diff  --git a/clang/unittests/Format/FormatTest.cpp 
b/clang/unittests/Format/FormatTest.cpp
index 6c2b00b97ed3c..f453a4f77f8b3 100644
--- a/clang/unittests/Format/FormatTest.cpp
+++ b/clang/unittests/Format/FormatTest.cpp
@@ -3738,6 +3738,36 @@ TEST_F(FormatTest, FormatsNamespaces) {
"void f() { f(); }\n"
"}",
LLVMWithNoNamespaceFix);
+  verifyFormat("#define M(x) x##x\n"
+   "namespace M(x) {\n"
+   "class A {};\n"
+   "void f() { f(); }\n"
+   "}",
+   LLVMWithNoNamespaceFix);
+  verifyFormat("#define M(x) x##x\n"
+   "namespace N::inline M(x) {\n"
+   "class A {};\n"
+   "void f() { f(); }\n"
+   "}",
+   LLVMWithNoNamespaceFix);
+  verifyFormat("#define M(x) x##x\n"
+   "namespace M(x)::inline N {\n"
+   "class A {};\n"
+   "void f() { f(); }\n"
+   "}",
+   LLVMWithNoNamespaceFix);
+  verifyFormat("#define M(x) x##x\n"
+   "namespace N::M(x) {\n"
+   "class A {};\n"
+   "void f() { f(); }\n"
+   "}",
+   LLVMWithNoNamespaceFix);
+  verifyFormat("#define M(x) x##x\n"
+   "namespace M::N(x) {\n"
+   "class A {};\n"
+   

[clang] 9129743 - [Docs] List __has_feature(dataflow_sanitizer) in LanguageExtensions docs.

2022-03-04 Thread Andrew Browne via cfe-commits

Author: Andrew Browne
Date: 2022-03-04T15:48:07-08:00
New Revision: 9129743dde267f7ff678441c64bdfb9e24f7b448

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

LOG: [Docs] List __has_feature(dataflow_sanitizer) in LanguageExtensions docs.

Added: 


Modified: 
clang/docs/LanguageExtensions.rst

Removed: 




diff  --git a/clang/docs/LanguageExtensions.rst 
b/clang/docs/LanguageExtensions.rst
index aefb09afc82bb..68b294d0b8640 100644
--- a/clang/docs/LanguageExtensions.rst
+++ b/clang/docs/LanguageExtensions.rst
@@ -3592,6 +3592,9 @@ with :doc:`ThreadSanitizer`.
 Use ``__has_feature(memory_sanitizer)`` to check if the code is being built
 with :doc:`MemorySanitizer`.
 
+Use ``__has_feature(dataflow_sanitizer)`` to check if the code is being built
+with :doc:`DataFlowSanitizer`.
+
 Use ``__has_feature(safe_stack)`` to check if the code is being built
 with :doc:`SafeStack`.
 



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


[PATCH] D119910: [clang][debug] port clang-cl /JMC flag to ELF

2022-03-04 Thread Yuanfang Chen via Phabricator via cfe-commits
ychen added inline comments.



Comment at: llvm/test/Instrumentation/JustMyCode/jmc-instrument-elf.ll:1
-; REQUIRES: system-windows
-; RUN: opt -jmc-instrument -mtriple=x86_64-pc-windows-msvc  -S < %s | 
FileCheck %s
-; RUN: opt -jmc-instrument -mtriple=aarch64-pc-windows-msvc -S < %s | 
FileCheck %s
-; RUN: opt -jmc-instrument -mtriple=arm-pc-windows-msvc -S < %s | 
FileCheck %s
+; REQUIRES: system-linux
+; RUN: opt -jmc-instrument -mtriple=x86_64-unknown-linux-gnu  -S < %s | 
FileCheck %s

rnk wrote:
> ychen wrote:
> > rnk wrote:
> > > ychen wrote:
> > > > rnk wrote:
> > > > > Please remove the REQUIRES line, this test should pass on Windows, 
> > > > > and the other test should pass on Linux as well. Neither of these 
> > > > > tests depend on anything from the system.
> > > > Yeah, this is a little tricky. It is about the host rather than the 
> > > > target. The flag symbol name is computed using `sys::path` functions. 
> > > > It is different between Windows and Linux. For testing purposes, I need 
> > > > to anchor them to a specific system to check the result. I could've 
> > > > made this `; REQUIRES: system-windows` and check the result, I thought 
> > > > it is more intuitive to test the ELF on Linux.
> > > That seems like a bug. LLVM optimization and code generation should not 
> > > depend on the host. This is a requirement for distributed build systems, 
> > > which may migrate inputs to other machines, cross compile, and expect the 
> > > results to match local compilation.
> > The symbol names are host-dependent. It does not depend on the host to work 
> > correctly though. It works on both Windows and Linux.
> Yes, you say they are host dependent, I see that, but I don't think that's a 
> requirement. `opt` should be a pure function of its inputs. The paths are in 
> the debug info, it shouldn't let the environment leak into the compilation.
Great point. This is not ideal in principle. For the distributed build, this 
may break if the remote and host compilation uses different environments like 
Windows/Linux. I'll create a follow-up patch. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119910

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


[PATCH] D119599: [clang-format] Add option to align compound assignments like `+=`

2022-03-04 Thread sstwcw via Phabricator via cfe-commits
sstwcw marked 7 inline comments as done.
sstwcw added inline comments.



Comment at: clang/docs/tools/dump_format_style.py:293
   state = State.InNestedStruct
-  field_type, field_name = re.match(r'([<>:\w(,\s)]+)\s+(\w+);', 
line).groups()
+  field_type, field_name = re.match(r'([<>:\w(,\s)]+)\s+(\w+)', 
line).groups()
   if field_type in enums:

This change is needed to parse the entry `bool PadOperators = true;`.



Comment at: clang/lib/Format/WhitespaceManager.cpp:273
+// RightJustify - Whether it is the token's right end or left end that
+// gets moved to that column.
 template 

MyDeveloperDay wrote:
> something odd here why not, the following its fits 80 columns
> 
> ```
> // Column - The token for which Matches returns true is moved to this column.
> // RightJustify - Whether it is the token's right end or left end that gets
> // moved to that column.
> ```
My text editor automatically limited comments to 72 columns.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119599

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


[PATCH] D119599: [clang-format] Add option to align compound assignments like `+=`

2022-03-04 Thread sstwcw via Phabricator via cfe-commits
sstwcw updated this revision to Diff 413152.
sstwcw marked an inline comment as done.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119599

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/docs/tools/dump_format_style.py
  clang/include/clang/Format/Format.h
  clang/lib/Format/Format.cpp
  clang/lib/Format/WhitespaceManager.cpp
  clang/unittests/Format/FormatTest.cpp
  clang/unittests/Format/FormatTestJS.cpp

Index: clang/unittests/Format/FormatTestJS.cpp
===
--- clang/unittests/Format/FormatTestJS.cpp
+++ clang/unittests/Format/FormatTestJS.cpp
@@ -2699,7 +2699,7 @@
 
 TEST_F(FormatTestJS, AlignConsecutiveDeclarations) {
   FormatStyle Style = getGoogleStyle(FormatStyle::LK_JavaScript);
-  Style.AlignConsecutiveDeclarations = FormatStyle::ACS_Consecutive;
+  Style.AlignConsecutiveDeclarations.Enabled = true;
   verifyFormat("letletVariable = 5;\n"
"double constVariable = 10;",
Style);
@@ -2736,7 +2736,7 @@
 TEST_F(FormatTestJS, AlignConsecutiveAssignments) {
   FormatStyle Style = getGoogleStyle(FormatStyle::LK_JavaScript);
 
-  Style.AlignConsecutiveAssignments = FormatStyle::ACS_Consecutive;
+  Style.AlignConsecutiveAssignments.Enabled = true;
   verifyFormat("let letVariable  = 5;\n"
"double constVariable = 10;",
Style);
@@ -2772,8 +2772,8 @@
 
 TEST_F(FormatTestJS, AlignConsecutiveAssignmentsAndDeclarations) {
   FormatStyle Style = getGoogleStyle(FormatStyle::LK_JavaScript);
-  Style.AlignConsecutiveDeclarations = FormatStyle::ACS_Consecutive;
-  Style.AlignConsecutiveAssignments = FormatStyle::ACS_Consecutive;
+  Style.AlignConsecutiveDeclarations.Enabled = true;
+  Style.AlignConsecutiveAssignments.Enabled = true;
   verifyFormat("letletVariable   = 5;\n"
"double constVariable = 10;",
Style);
Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -2076,7 +2076,7 @@
   " res2 = [](int ) { return 0; };",
   Style);
 
-  Style.AlignConsecutiveDeclarations = FormatStyle::ACS_Consecutive;
+  Style.AlignConsecutiveDeclarations.Enabled = true;
   verifyFormat("Const unsigned int *c;\n"
"const unsigned int *d;\n"
"Const unsigned int \n"
@@ -2117,7 +2117,7 @@
   "res2 = [](int& a) { return 0; };",
   Style);
 
-  Style.AlignConsecutiveDeclarations = FormatStyle::ACS_Consecutive;
+  Style.AlignConsecutiveDeclarations.Enabled = true;
   verifyFormat("Const unsigned int* c;\n"
"const unsigned int* d;\n"
"Const unsigned int& e;\n"
@@ -2138,7 +2138,7 @@
   verifyFormat("for (int a = 0, b = 0; const Foo *c : {1, 2, 3})", Style);
   verifyFormat("for (int a = 0, b++; const Foo *c : {1, 2, 3})", Style);
 
-  Style.AlignConsecutiveDeclarations = FormatStyle::ACS_Consecutive;
+  Style.AlignConsecutiveDeclarations.Enabled = true;
   verifyFormat("Const unsigned int *c;\n"
"const unsigned int *d;\n"
"Const unsigned int& e;\n"
@@ -2174,7 +2174,7 @@
   " res2 = [](int & a) { return 0; };",
   Style);
 
-  Style.AlignConsecutiveDeclarations = FormatStyle::ACS_Consecutive;
+  Style.AlignConsecutiveDeclarations.Enabled = true;
   verifyFormat("Const unsigned int*  c;\n"
"const unsigned int*  d;\n"
"Const unsigned int & e;\n"
@@ -14425,8 +14425,8 @@
"*/\n"
"}",
Tab));
-  Tab.AlignConsecutiveAssignments = FormatStyle::ACS_Consecutive;
-  Tab.AlignConsecutiveDeclarations = FormatStyle::ACS_Consecutive;
+  Tab.AlignConsecutiveAssignments.Enabled = true;
+  Tab.AlignConsecutiveDeclarations.Enabled = true;
   Tab.TabWidth = 4;
   Tab.IndentWidth = 4;
   verifyFormat("class Assign {\n"
@@ -14664,8 +14664,8 @@
"*/\n"
"}",
Tab));
-  Tab.AlignConsecutiveAssignments = FormatStyle::ACS_Consecutive;
-  Tab.AlignConsecutiveDeclarations = FormatStyle::ACS_Consecutive;
+  Tab.AlignConsecutiveAssignments.Enabled = true;
+  Tab.AlignConsecutiveDeclarations.Enabled = true;
   Tab.TabWidth = 4;
   Tab.IndentWidth = 4;
   verifyFormat("class Assign {\n"
@@ -15835,9 +15835,8 @@
 
 TEST_F(FormatTest, AlignConsecutiveMacros) {
   FormatStyle Style = getLLVMStyle();
-  Style.AlignConsecutiveAssignments = FormatStyle::ACS_Consecutive;
-  Style.AlignConsecutiveDeclarations = FormatStyle::ACS_Consecutive;
-  Style.AlignConsecutiveMacros = FormatStyle::ACS_None;
+  Style.AlignConsecutiveAssignments.Enabled = true;
+  Style.AlignConsecutiveDeclarations.Enabled = true;
 
   

[PATCH] D120271: [Clang] Add offload kind to embedded offload object

2022-03-04 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added a comment.
Herald added a project: All.

@saiislam Ok to postpone the bundle entry usage to a follow up?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120271

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


[PATCH] D120288: [OpenMP] Implement dense map info for device file

2022-03-04 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert accepted this revision.
jdoerfert added a comment.
This revision is now accepted and ready to land.
Herald added a project: All.

LG


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120288

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


[PATCH] D120931: [clang-format] Fix namespace format when the name is a macro expansion

2022-03-04 Thread Owen Pan via Phabricator via cfe-commits
owenpan accepted this revision.
owenpan added a comment.
This revision is now accepted and ready to land.

LGTM, but please wait for other reviewers in case they have more comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120931

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


[PATCH] D119599: [clang-format] Add option to align compound assignments like `+=`

2022-03-04 Thread sstwcw via Phabricator via cfe-commits
sstwcw updated this revision to Diff 413149.
sstwcw marked 2 inline comments as done.
sstwcw added a comment.
Herald added a project: All.

Take out things in other revisions


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119599

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/Format.cpp
  clang/lib/Format/WhitespaceManager.cpp
  clang/unittests/Format/FormatTest.cpp
  clang/unittests/Format/FormatTestJS.cpp

Index: clang/unittests/Format/FormatTestJS.cpp
===
--- clang/unittests/Format/FormatTestJS.cpp
+++ clang/unittests/Format/FormatTestJS.cpp
@@ -2699,7 +2699,7 @@
 
 TEST_F(FormatTestJS, AlignConsecutiveDeclarations) {
   FormatStyle Style = getGoogleStyle(FormatStyle::LK_JavaScript);
-  Style.AlignConsecutiveDeclarations = FormatStyle::ACS_Consecutive;
+  Style.AlignConsecutiveDeclarations.Enabled = true;
   verifyFormat("letletVariable = 5;\n"
"double constVariable = 10;",
Style);
@@ -2736,7 +2736,7 @@
 TEST_F(FormatTestJS, AlignConsecutiveAssignments) {
   FormatStyle Style = getGoogleStyle(FormatStyle::LK_JavaScript);
 
-  Style.AlignConsecutiveAssignments = FormatStyle::ACS_Consecutive;
+  Style.AlignConsecutiveAssignments.Enabled = true;
   verifyFormat("let letVariable  = 5;\n"
"double constVariable = 10;",
Style);
@@ -2772,8 +2772,8 @@
 
 TEST_F(FormatTestJS, AlignConsecutiveAssignmentsAndDeclarations) {
   FormatStyle Style = getGoogleStyle(FormatStyle::LK_JavaScript);
-  Style.AlignConsecutiveDeclarations = FormatStyle::ACS_Consecutive;
-  Style.AlignConsecutiveAssignments = FormatStyle::ACS_Consecutive;
+  Style.AlignConsecutiveDeclarations.Enabled = true;
+  Style.AlignConsecutiveAssignments.Enabled = true;
   verifyFormat("letletVariable   = 5;\n"
"double constVariable = 10;",
Style);
Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -2076,7 +2076,7 @@
   " res2 = [](int ) { return 0; };",
   Style);
 
-  Style.AlignConsecutiveDeclarations = FormatStyle::ACS_Consecutive;
+  Style.AlignConsecutiveDeclarations.Enabled = true;
   verifyFormat("Const unsigned int *c;\n"
"const unsigned int *d;\n"
"Const unsigned int \n"
@@ -2117,7 +2117,7 @@
   "res2 = [](int& a) { return 0; };",
   Style);
 
-  Style.AlignConsecutiveDeclarations = FormatStyle::ACS_Consecutive;
+  Style.AlignConsecutiveDeclarations.Enabled = true;
   verifyFormat("Const unsigned int* c;\n"
"const unsigned int* d;\n"
"Const unsigned int& e;\n"
@@ -2138,7 +2138,7 @@
   verifyFormat("for (int a = 0, b = 0; const Foo *c : {1, 2, 3})", Style);
   verifyFormat("for (int a = 0, b++; const Foo *c : {1, 2, 3})", Style);
 
-  Style.AlignConsecutiveDeclarations = FormatStyle::ACS_Consecutive;
+  Style.AlignConsecutiveDeclarations.Enabled = true;
   verifyFormat("Const unsigned int *c;\n"
"const unsigned int *d;\n"
"Const unsigned int& e;\n"
@@ -2174,7 +2174,7 @@
   " res2 = [](int & a) { return 0; };",
   Style);
 
-  Style.AlignConsecutiveDeclarations = FormatStyle::ACS_Consecutive;
+  Style.AlignConsecutiveDeclarations.Enabled = true;
   verifyFormat("Const unsigned int*  c;\n"
"const unsigned int*  d;\n"
"Const unsigned int & e;\n"
@@ -14425,8 +14425,8 @@
"*/\n"
"}",
Tab));
-  Tab.AlignConsecutiveAssignments = FormatStyle::ACS_Consecutive;
-  Tab.AlignConsecutiveDeclarations = FormatStyle::ACS_Consecutive;
+  Tab.AlignConsecutiveAssignments.Enabled = true;
+  Tab.AlignConsecutiveDeclarations.Enabled = true;
   Tab.TabWidth = 4;
   Tab.IndentWidth = 4;
   verifyFormat("class Assign {\n"
@@ -14664,8 +14664,8 @@
"*/\n"
"}",
Tab));
-  Tab.AlignConsecutiveAssignments = FormatStyle::ACS_Consecutive;
-  Tab.AlignConsecutiveDeclarations = FormatStyle::ACS_Consecutive;
+  Tab.AlignConsecutiveAssignments.Enabled = true;
+  Tab.AlignConsecutiveDeclarations.Enabled = true;
   Tab.TabWidth = 4;
   Tab.IndentWidth = 4;
   verifyFormat("class Assign {\n"
@@ -15835,9 +15835,8 @@
 
 TEST_F(FormatTest, AlignConsecutiveMacros) {
   FormatStyle Style = getLLVMStyle();
-  Style.AlignConsecutiveAssignments = FormatStyle::ACS_Consecutive;
-  Style.AlignConsecutiveDeclarations = FormatStyle::ACS_Consecutive;
-  Style.AlignConsecutiveMacros = FormatStyle::ACS_None;
+  Style.AlignConsecutiveAssignments.Enabled = true;
+  

[PATCH] D119910: [clang][debug] port clang-cl /JMC flag to ELF

2022-03-04 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added inline comments.



Comment at: llvm/test/Instrumentation/JustMyCode/jmc-instrument-elf.ll:1
-; REQUIRES: system-windows
-; RUN: opt -jmc-instrument -mtriple=x86_64-pc-windows-msvc  -S < %s | 
FileCheck %s
-; RUN: opt -jmc-instrument -mtriple=aarch64-pc-windows-msvc -S < %s | 
FileCheck %s
-; RUN: opt -jmc-instrument -mtriple=arm-pc-windows-msvc -S < %s | 
FileCheck %s
+; REQUIRES: system-linux
+; RUN: opt -jmc-instrument -mtriple=x86_64-unknown-linux-gnu  -S < %s | 
FileCheck %s

ychen wrote:
> rnk wrote:
> > ychen wrote:
> > > rnk wrote:
> > > > Please remove the REQUIRES line, this test should pass on Windows, and 
> > > > the other test should pass on Linux as well. Neither of these tests 
> > > > depend on anything from the system.
> > > Yeah, this is a little tricky. It is about the host rather than the 
> > > target. The flag symbol name is computed using `sys::path` functions. It 
> > > is different between Windows and Linux. For testing purposes, I need to 
> > > anchor them to a specific system to check the result. I could've made 
> > > this `; REQUIRES: system-windows` and check the result, I thought it is 
> > > more intuitive to test the ELF on Linux.
> > That seems like a bug. LLVM optimization and code generation should not 
> > depend on the host. This is a requirement for distributed build systems, 
> > which may migrate inputs to other machines, cross compile, and expect the 
> > results to match local compilation.
> The symbol names are host-dependent. It does not depend on the host to work 
> correctly though. It works on both Windows and Linux.
Yes, you say they are host dependent, I see that, but I don't think that's a 
requirement. `opt` should be a pure function of its inputs. The paths are in 
the debug info, it shouldn't let the environment leak into the compilation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119910

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


[PATCH] D119918: [CMake] Rename TARGET_TRIPLE to LLVM_TARGET_TRIPLE

2022-03-04 Thread Vlad Vereschaka via Phabricator via cfe-commits
vvereschaka added a comment.

@phosek @rovka

no need those changes for `CrossWinToARMLinux.cmake`. `TARGET_TRIPLE` is using 
to parametrize the cache file only.
But if there is a goal to completely remove `TARGET_TRIPLE` from the source 
tree I will update the cache file and the buildbot configuration accordingly


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

https://reviews.llvm.org/D119918

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


[PATCH] D119910: [clang][debug] port clang-cl /JMC flag to ELF

2022-03-04 Thread Yuanfang Chen via Phabricator via cfe-commits
ychen added inline comments.



Comment at: llvm/test/Instrumentation/JustMyCode/jmc-instrument-elf.ll:1
-; REQUIRES: system-windows
-; RUN: opt -jmc-instrument -mtriple=x86_64-pc-windows-msvc  -S < %s | 
FileCheck %s
-; RUN: opt -jmc-instrument -mtriple=aarch64-pc-windows-msvc -S < %s | 
FileCheck %s
-; RUN: opt -jmc-instrument -mtriple=arm-pc-windows-msvc -S < %s | 
FileCheck %s
+; REQUIRES: system-linux
+; RUN: opt -jmc-instrument -mtriple=x86_64-unknown-linux-gnu  -S < %s | 
FileCheck %s

rnk wrote:
> ychen wrote:
> > rnk wrote:
> > > Please remove the REQUIRES line, this test should pass on Windows, and 
> > > the other test should pass on Linux as well. Neither of these tests 
> > > depend on anything from the system.
> > Yeah, this is a little tricky. It is about the host rather than the target. 
> > The flag symbol name is computed using `sys::path` functions. It is 
> > different between Windows and Linux. For testing purposes, I need to anchor 
> > them to a specific system to check the result. I could've made this `; 
> > REQUIRES: system-windows` and check the result, I thought it is more 
> > intuitive to test the ELF on Linux.
> That seems like a bug. LLVM optimization and code generation should not 
> depend on the host. This is a requirement for distributed build systems, 
> which may migrate inputs to other machines, cross compile, and expect the 
> results to match local compilation.
The symbol names are host-dependent. It does not depend on the host to work 
correctly though. It works on both Windows and Linux.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119910

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


[PATCH] D119910: [clang][debug] port clang-cl /JMC flag to ELF

2022-03-04 Thread Reid Kleckner via Phabricator via cfe-commits
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.

Looks like I hit submit too early...

I wanted to say the path thing is a pre-existing issue, and it seems reasonable 
to address that as a separate patch. If you don't have plans to do a follow up 
patch, please file a bug about it, and maybe I can hand it off to someone.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119910

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


[PATCH] D119910: [clang][debug] port clang-cl /JMC flag to ELF

2022-03-04 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added inline comments.



Comment at: llvm/lib/CodeGen/JMCInstrumenter.cpp:72
   SmallString<256> FilePath(SP.getDirectory());
   sys::path::append(FilePath, SP.getFilename());
   sys::path::native(FilePath);

These sys::path calls introduce host-dependence, and that should be eliminated



Comment at: llvm/test/Instrumentation/JustMyCode/jmc-instrument-elf.ll:1
-; REQUIRES: system-windows
-; RUN: opt -jmc-instrument -mtriple=x86_64-pc-windows-msvc  -S < %s | 
FileCheck %s
-; RUN: opt -jmc-instrument -mtriple=aarch64-pc-windows-msvc -S < %s | 
FileCheck %s
-; RUN: opt -jmc-instrument -mtriple=arm-pc-windows-msvc -S < %s | 
FileCheck %s
+; REQUIRES: system-linux
+; RUN: opt -jmc-instrument -mtriple=x86_64-unknown-linux-gnu  -S < %s | 
FileCheck %s

ychen wrote:
> rnk wrote:
> > Please remove the REQUIRES line, this test should pass on Windows, and the 
> > other test should pass on Linux as well. Neither of these tests depend on 
> > anything from the system.
> Yeah, this is a little tricky. It is about the host rather than the target. 
> The flag symbol name is computed using `sys::path` functions. It is different 
> between Windows and Linux. For testing purposes, I need to anchor them to a 
> specific system to check the result. I could've made this `; REQUIRES: 
> system-windows` and check the result, I thought it is more intuitive to test 
> the ELF on Linux.
That seems like a bug. LLVM optimization and code generation should not depend 
on the host. This is a requirement for distributed build systems, which may 
migrate inputs to other machines, cross compile, and expect the results to 
match local compilation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119910

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


[PATCH] D119910: [clang][debug] port clang-cl /JMC flag to ELF

2022-03-04 Thread Yuanfang Chen via Phabricator via cfe-commits
ychen marked 2 inline comments as done.
ychen added a comment.

@rnk, thanks for taking a look. Patch updated.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119910

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


[PATCH] D119910: [clang][debug] port clang-cl /JMC flag to ELF

2022-03-04 Thread Yuanfang Chen via Phabricator via cfe-commits
ychen updated this revision to Diff 413146.
ychen added a comment.
Herald added a subscriber: dang.

- Address Reid's comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119910

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/cl-options.c
  clang/test/Driver/clang_f_opts.c
  llvm/lib/CodeGen/JMCInstrumenter.cpp
  llvm/test/Instrumentation/JustMyCode/jmc-instrument-elf.ll
  llvm/test/Instrumentation/JustMyCode/jmc-instrument-x86.ll
  llvm/test/Instrumentation/JustMyCode/jmc-instrument.ll

Index: llvm/test/Instrumentation/JustMyCode/jmc-instrument-x86.ll
===
--- llvm/test/Instrumentation/JustMyCode/jmc-instrument-x86.ll
+++ llvm/test/Instrumentation/JustMyCode/jmc-instrument-x86.ll
@@ -11,12 +11,12 @@
 ; CHECK:   ret void
 ; CHECK: }
 
-; CHECK: declare x86_fastcallcc void @__CheckForDebuggerJustMyCode(i8* inreg noundef) unnamed_addr
-
 ; CHECK: define void @_JustMyCode_Default(i8* inreg noundef %0) unnamed_addr comdat {
 ; CHECK:   ret void
 ; CHECK: }
 
+; CHECK: declare x86_fastcallcc void @__CheckForDebuggerJustMyCode(i8* inreg noundef) unnamed_addr
+
 ; CHECK: !0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
 ; CHECK: !1 = distinct !DIGlobalVariable(name: "_A8764FDD_x@c", scope: !2, file: !3, type: !5, isLocal: true, isDefinition: true)
 ; CHECK: !2 = distinct !DICompileUnit(language: DW_LANG_C99, file: !3, producer: "clang", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, globals: !4, splitDebugInlining: false, nameTableKind: None)
Index: llvm/test/Instrumentation/JustMyCode/jmc-instrument.ll
===
--- llvm/test/Instrumentation/JustMyCode/jmc-instrument.ll
+++ llvm/test/Instrumentation/JustMyCode/jmc-instrument.ll
@@ -6,8 +6,8 @@
 ; CHECK: $__JustMyCode_Default = comdat any
 
 ; CHECK: @"__E6EA670F_x@c" = internal unnamed_addr global i8 1, section ".msvcjmc", align 1, !dbg !0
-; CHECK: @"__A8764FDD_x@c" = internal unnamed_addr global i8 1, section ".msvcjmc", align 1, !dbg !5
 ; CHECK: @llvm.used = appending global [1 x i8*] [i8* bitcast (void (i8*)* @__JustMyCode_Default to i8*)], section "llvm.metadata"
+; CHECK: @"__A8764FDD_x@c" = internal unnamed_addr global i8 1, section ".msvcjmc", align 1, !dbg !5
 
 ; CHECK: define void @l1() !dbg !13 {
 ; CHECK:   call void @__CheckForDebuggerJustMyCode(i8* noundef @"__E6EA670F_x@c")
@@ -39,12 +39,12 @@
 ; CHECK:   ret void
 ; CHECK: }
 
-; CHECK: declare void @__CheckForDebuggerJustMyCode(i8* noundef) unnamed_addr
-
 ; CHECK: define void @__JustMyCode_Default(i8* noundef %0) unnamed_addr comdat {
 ; CHECK:   ret void
 ; CHECK: }
 
+; CHECK: declare void @__CheckForDebuggerJustMyCode(i8* noundef) unnamed_addr
+
 ; CHECK: !llvm.linker.options = !{!12}
 
 ; CHECK: !0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
Index: llvm/test/Instrumentation/JustMyCode/jmc-instrument-elf.ll
===
--- llvm/test/Instrumentation/JustMyCode/jmc-instrument-elf.ll
+++ llvm/test/Instrumentation/JustMyCode/jmc-instrument-elf.ll
@@ -1,78 +1,72 @@
-; REQUIRES: system-windows
-; RUN: opt -jmc-instrument -mtriple=x86_64-pc-windows-msvc  -S < %s | FileCheck %s
-; RUN: opt -jmc-instrument -mtriple=aarch64-pc-windows-msvc -S < %s | FileCheck %s
-; RUN: opt -jmc-instrument -mtriple=arm-pc-windows-msvc -S < %s | FileCheck %s
+; REQUIRES: system-linux
+; RUN: opt -jmc-instrument -mtriple=x86_64-unknown-linux-gnu  -S < %s | FileCheck %s
 
-; CHECK: $__JustMyCode_Default = comdat any
+; CHECK: @"__7DF23CF5_x@c" = internal unnamed_addr global i8 1, section ".just.my.code", align 1, !dbg !0
+; CHECK: @"__A85D9D03_x@c" = internal unnamed_addr global i8 1, section ".just.my.code", align 1, !dbg !5
 
-; CHECK: @"__E6EA670F_x@c" = internal unnamed_addr global i8 1, section ".msvcjmc", align 1, !dbg !0
-; CHECK: @"__A8764FDD_x@c" = internal unnamed_addr global i8 1, section ".msvcjmc", align 1, !dbg !5
-; CHECK: @llvm.used = appending global [1 x i8*] [i8* bitcast (void (i8*)* @__JustMyCode_Default to i8*)], section "llvm.metadata"
-
-; CHECK: define void @l1() !dbg !13 {
-; CHECK:   call void @__CheckForDebuggerJustMyCode(i8* noundef @"__E6EA670F_x@c")
+; CHECK: define void @l1() !dbg !12 {
+; CHECK:   call void @__CheckForDebuggerJustMyCode(i8* noundef @"__7DF23CF5_x@c")
 ; CHECK:   ret void
 ; CHECK: }
 
-; CHECK: define void @l2() !dbg !17 {
-; CHECK:   call void @__CheckForDebuggerJustMyCode(i8* noundef @"__E6EA670F_x@c")
+; CHECK: define void @l2() !dbg !16 {
+; CHECK:   call void @__CheckForDebuggerJustMyCode(i8* noundef @"__7DF23CF5_x@c")
 ; CHECK:   ret void
 ; CHECK: }
 
-; CHECK: define void @w1() !dbg !19 {
-; CHECK:   call void 

[PATCH] D119918: [CMake] Rename TARGET_TRIPLE to LLVM_TARGET_TRIPLE

2022-03-04 Thread Petr Hosek via Phabricator via cfe-commits
phosek updated this revision to Diff 413141.
phosek added a comment.

Rebase


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

https://reviews.llvm.org/D119918

Files:
  bolt/test/Unit/lit.site.cfg.py.in
  bolt/test/lit.site.cfg.py.in
  clang-tools-extra/clangd/test/lit.site.cfg.py.in
  clang-tools-extra/test/Unit/lit.site.cfg.py.in
  clang-tools-extra/test/lit.site.cfg.py.in
  clang/test/Unit/lit.site.cfg.py.in
  clang/test/lit.site.cfg.py.in
  clang/utils/perf-training/lit.site.cfg.in
  clang/utils/perf-training/order-files.lit.site.cfg.in
  compiler-rt/cmake/Modules/AddCompilerRT.cmake
  compiler-rt/cmake/Modules/CompilerRTMockLLVMCMakeConfig.cmake
  compiler-rt/cmake/Modules/CompilerRTUtils.cmake
  compiler-rt/test/fuzzer/lit.site.cfg.py.in
  compiler-rt/unittests/lit.common.unit.configured.in
  cross-project-tests/lit.site.cfg.py.in
  flang/test/NonGtestUnit/lit.site.cfg.py.in
  flang/test/Unit/lit.site.cfg.py.in
  lld/test/Unit/lit.site.cfg.py.in
  lld/test/lit.site.cfg.py.in
  lldb/test/API/lit.site.cfg.py.in
  lldb/test/CMakeLists.txt
  lldb/test/Shell/lit.site.cfg.py.in
  lldb/test/Unit/lit.site.cfg.py.in
  lldb/test/lit.site.cfg.py.in
  llvm/CMakeLists.txt
  llvm/cmake/modules/AddLLVM.cmake
  llvm/cmake/modules/CrossCompile.cmake
  llvm/cmake/modules/LLVMConfig.cmake.in
  llvm/runtimes/CMakeLists.txt
  llvm/test/lit.site.cfg.py.in
  llvm/utils/gn/secondary/clang-tools-extra/clangd/test/BUILD.gn
  llvm/utils/gn/secondary/clang-tools-extra/test/BUILD.gn
  llvm/utils/gn/secondary/clang/test/BUILD.gn
  llvm/utils/gn/secondary/lld/test/BUILD.gn
  llvm/utils/gn/secondary/lldb/test/BUILD.gn
  llvm/utils/gn/secondary/llvm/test/BUILD.gn
  mlir/examples/standalone/test/lit.site.cfg.py.in
  mlir/test/lit.site.cfg.py.in
  polly/test/Unit/lit.site.cfg.in
  polly/test/lit.site.cfg.in

Index: polly/test/lit.site.cfg.in
===
--- polly/test/lit.site.cfg.in
+++ polly/test/lit.site.cfg.in
@@ -6,7 +6,7 @@
 config.llvm_libs_dir = "@LLVM_LIBS_DIR@"
 config.polly_obj_root = "@POLLY_BINARY_DIR@"
 config.polly_lib_dir = "@POLLY_LIB_DIR@"
-config.target_triple = "@TARGET_TRIPLE@"
+config.target_triple = "@LLVM_TARGET_TRIPLE@"
 config.enable_gpgpu_codegen = "@GPU_CODEGEN@"
 config.llvm_polly_link_into_tools = "@LLVM_POLLY_LINK_INTO_TOOLS@"
 config.targets_to_build = "@TARGETS_TO_BUILD@"
@@ -15,7 +15,7 @@
 ## Check the current platform with regex
 import re
 EAT_ERR_ON_X86 = ' '
-if (re.match(r'^x86_64*', '@TARGET_TRIPLE@') == None) :
+if (re.match(r'^x86_64*', '@LLVM_TARGET_TRIPLE@') == None) :
   EAT_ERR_ON_X86 = '|| echo \"error is eaten\"'
 
 for arch in config.targets_to_build.split():
Index: polly/test/Unit/lit.site.cfg.in
===
--- polly/test/Unit/lit.site.cfg.in
+++ polly/test/Unit/lit.site.cfg.in
@@ -11,7 +11,7 @@
 config.polly_lib_dir = "@POLLY_LIB_DIR@"
 config.enable_shared = @ENABLE_SHARED@
 config.shlibdir = "@SHLIBDIR@"
-config.target_triple = "@TARGET_TRIPLE@"
+config.target_triple = "@LLVM_TARGET_TRIPLE@"
 config.enable_gpgpu_codegen = "@GPU_CODEGEN@"
 config.llvm_polly_link_into_tools = "@LLVM_POLLY_LINK_INTO_TOOLS@"
 config.has_unittests = @POLLY_GTEST_AVAIL@
Index: mlir/test/lit.site.cfg.py.in
===
--- mlir/test/lit.site.cfg.py.in
+++ mlir/test/lit.site.cfg.py.in
@@ -3,7 +3,7 @@
 import sys
 
 config.host_triple = "@LLVM_HOST_TRIPLE@"
-config.target_triple = "@TARGET_TRIPLE@"
+config.target_triple = "@LLVM_TARGET_TRIPLE@"
 config.llvm_src_root = "@LLVM_SOURCE_DIR@"
 config.llvm_obj_root = "@LLVM_BINARY_DIR@"
 config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"
Index: mlir/examples/standalone/test/lit.site.cfg.py.in
===
--- mlir/examples/standalone/test/lit.site.cfg.py.in
+++ mlir/examples/standalone/test/lit.site.cfg.py.in
@@ -3,7 +3,7 @@
 import sys
 
 config.host_triple = "@LLVM_HOST_TRIPLE@"
-config.target_triple = "@TARGET_TRIPLE@"
+config.target_triple = "@LLVM_TARGET_TRIPLE@"
 config.llvm_src_root = "@LLVM_SOURCE_DIR@"
 config.llvm_obj_root = "@LLVM_BINARY_DIR@"
 config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"
Index: llvm/utils/gn/secondary/llvm/test/BUILD.gn
===
--- llvm/utils/gn/secondary/llvm/test/BUILD.gn
+++ llvm/utils/gn/secondary/llvm/test/BUILD.gn
@@ -72,7 +72,7 @@
 "LLVM_VERSION_SUFFIX=git",
 "Python3_EXECUTABLE=$python_path",
 "TARGETS_TO_BUILD=$llvm_targets_to_build_string",
-"TARGET_TRIPLE=$llvm_target_triple",
+"LLVM_TARGET_TRIPLE=$llvm_target_triple",
 
 "LLVM_LIBCXX_USED=0",
 
Index: llvm/utils/gn/secondary/lldb/test/BUILD.gn
===
--- llvm/utils/gn/secondary/lldb/test/BUILD.gn
+++ llvm/utils/gn/secondary/lldb/test/BUILD.gn
@@ -24,7 +24,7 @@
   "LLVM_SOURCE_DIR=" + 

[PATCH] D120931: [clang-format] Fix namespace format when the name is a macro expansion

2022-03-04 Thread Zequan Wu via Phabricator via cfe-commits
zequanwu updated this revision to Diff 413139.
zequanwu marked 2 inline comments as done.
zequanwu added a comment.

update.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120931

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

Index: clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp
===
--- clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp
+++ clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp
@@ -68,6 +68,127 @@
 "int i;\n"
 "int j;\n"
 "}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace M(x)",
+fixNamespaceEndComments("#define M(x) x##x\n"
+"namespace M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace A::M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A::M(x)",
+fixNamespaceEndComments("#define M(x) x##x\n"
+"namespace A::M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace M(x)::A {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace M(x)::A",
+fixNamespaceEndComments("#define M(x) x##x\n"
+"namespace M(x)::A {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace A::inline M(x)::B {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A::inline M(x)::B",
+fixNamespaceEndComments("#define M(x) x##x\n"
+"namespace A::inline M(x)::B {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace [[deprecated(\"foo\")]] A::inline M(x)::A {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A::inline M(x)::A",
+fixNamespaceEndComments(
+"#define M(x) x##x\n"
+"namespace [[deprecated(\"foo\")]] A::inline M(x)::A {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ(
+  "namespace /* comment */ [[deprecated(\"foo\")]] /* comment */ A {\n"
+  "int i;\n"
+  "int j;\n"
+  "}// namespace A",
+  fixNamespaceEndComments(
+  "namespace /* comment */ [[deprecated(\"foo\")]] /* comment */ A {\n"
+  "int i;\n"
+  "int j;\n"
+  "}"));
+  EXPECT_EQ("namespace /* comment */ [[deprecated(\"foo\")]] A {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A",
+fixNamespaceEndComments(
+"namespace /* comment */ [[deprecated(\"foo\")]] A {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ(
+  "#define M(x) x##x\n"
+  "namespace /* comment */ [[deprecated(\"foo\")]] /* comment */ M(x) {\n"
+  "int i;\n"
+  "int j;\n"
+  "}// namespace M(x)",
+  fixNamespaceEndComments("#define M(x) x##x\n"
+  "namespace /* comment */ "
+  "[[deprecated(\"foo\")]] /* comment */ M(x) {\n"
+  "int i;\n"
+  "int j;\n"
+  "}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace /* comment */ [[deprecated(\"foo\")]] /* comment */ "
+"A::M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A::M(x)",
+fixNamespaceEndComments(
+"#define M(x) x##x\n"
+"namespace /* comment */ "
+"[[deprecated(\"foo\")]] /* comment */ A::M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace /* comment */ [[deprecated(\"foo\")]] /* comment */ "
+"M(x) /* comment */ {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace M(x)",
+fixNamespaceEndComments(
+"#define M(x) x##x\n"
+   

[PATCH] D120931: [clang-format] Fix namespace format when the name is a macro expansion

2022-03-04 Thread Owen Pan via Phabricator via cfe-commits
owenpan added inline comments.



Comment at: clang/lib/Format/NamespaceEndCommentsFixer.cpp:59-60
+
+// Use the string after `namespace` until `{` or `::` or `(` as a name
+// candidate. If the name is empty, use the candicate.
+std::string FirstNSName;

owenpan wrote:
> Move "as a name candidate" to between "`namespace`" and "until".
> Move "as a name candidate" to between "`namespace`" and "until".

Or move it to after "Use", i.e. "Use as a name candidate the string after ...".


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120931

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


[PATCH] D120931: [clang-format] Fix namespace format when the name is a macro expansion

2022-03-04 Thread Owen Pan via Phabricator via cfe-commits
owenpan added inline comments.



Comment at: clang/lib/Format/NamespaceEndCommentsFixer.cpp:45-54
+  int NestLevel = 1;
+  while (Tok && NestLevel > 0) {
+Tok = Tok->getNextNonComment();
+if (Tok) {
+  if (Tok->is(tok::l_square))
+++NestLevel;
+  if (Tok->is(tok::r_square))

To make the loop simpler and more efficient.



Comment at: clang/lib/Format/NamespaceEndCommentsFixer.cpp:59-60
+
+// Use the string after `namespace` until `{` or `::` or `(` as a name
+// candidate. If the name is empty, use the candicate.
+std::string FirstNSName;

Move "as a name candidate" to between "`namespace`" and "until".


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120931

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


[clang] 22b6e81 - Fix test failure in openmp-offload.c

2022-03-04 Thread Yaxun Liu via cfe-commits

Author: Yaxun (Sam) Liu
Date: 2022-03-04T16:32:30-05:00
New Revision: 22b6e8173cb258fae5a7d332b6f9eb19e9ddf86f

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

LOG: Fix test failure in openmp-offload.c

Update active offload kind of actions for OpenMP programs.

The change is expected as of e5eb365069cce7bb642421d53a1d3964f8d5bdb7.

Added: 


Modified: 
clang/test/Driver/openmp-offload.c

Removed: 




diff  --git a/clang/test/Driver/openmp-offload.c 
b/clang/test/Driver/openmp-offload.c
index 424b484df99bd..0bfe5a1195fe1 100644
--- a/clang/test/Driver/openmp-offload.c
+++ b/clang/test/Driver/openmp-offload.c
@@ -234,9 +234,9 @@
 // CHK-PHASES-WITH-CUDA: 19: assembler, {18}, object, (device-openmp)
 // CHK-PHASES-WITH-CUDA: 20: linker, {19}, image, (device-openmp)
 // CHK-PHASES-WITH-CUDA: 21: offload, "device-openmp (nvptx64-nvidia-cuda)" 
{20}, image
-// CHK-PHASES-WITH-CUDA: 22: clang-offload-wrapper, {21}, ir, 
(host-cuda-openmp)
-// CHK-PHASES-WITH-CUDA: 23: backend, {22}, assembler, (host-cuda-openmp)
-// CHK-PHASES-WITH-CUDA: 24: assembler, {23}, object, (host-cuda-openmp)
+// CHK-PHASES-WITH-CUDA: 22: clang-offload-wrapper, {21}, ir, (host-openmp)
+// CHK-PHASES-WITH-CUDA: 23: backend, {22}, assembler, (host-openmp)
+// CHK-PHASES-WITH-CUDA: 24: assembler, {23}, object, (host-openmp)
 // CHK-PHASES-WITH-CUDA: 25: linker, {13, 24}, image, (host-cuda-openmp)
 
 /// ###



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


[PATCH] D120931: [clang-format] Fix namespace format when the name is a macro expansion

2022-03-04 Thread Zequan Wu via Phabricator via cfe-commits
zequanwu added inline comments.



Comment at: clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp:112
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace [[deprecated(\"foo\")]] A::inline M(x)::A {\n"
+"int i;\n"

MyDeveloperDay wrote:
> zequanwu wrote:
> > MyDeveloperDay wrote:
> > > Is this 2 bugs in one? I notice  you also handling attributes? is this a 
> > > different bug? (if so it should really be separate  (but we can let it 
> > > slide as long as the tests are thorough)
> > > 
> > > can you test:
> > > 
> > > ```
> > > namespace /* comment  */ [[ xxx ]]  /* comment */  A {
> > > int i;
> > > int j;
> > > }  // namespace  A
> > > 
> > > namespace /* comment  */ [[ xxx ]]   A {
> > > int i;
> > > int j;
> > > }  //  namespace A
> > > 
> > > namespace /* comment  */ [[ xxx ]]   /* comment */ M(x) {
> > > int i;
> > > int j;
> > > }  // namespace  M(x)
> > > 
> > > namespace /* comment  */ [[ xxx ]]   /* comment */  A::M(x) {
> > > int i;
> > > int j;
> > > }  // namespace  A::M(x)
> > > 
> > > namespace /* comment  */ [[ xxx ]]   /* comment */ M(x)  /* comment */ {
> > > int i;
> > > int j;
> > > }  // namespace  M(x)  
> > > 
> > > namespace /* comment  */ [[ xxx ]]   /* comment */  A::M(x) /* comment */ 
> > >  {
> > > int i;
> > > int j;
> > > }  // namespace  A::M(x)
> > > ```
> > > Is this 2 bugs in one? I notice you also handling attributes? 
> > No. This tests with attribute is here to test that candidate name doesn't 
> > include attributes, but that is unnecessary. Added the 6 tests above for 
> > testing that.
> Where are you checking the addition of this
> 
> ```
> if (Tok && Tok->is(tok::l_square)) {
>   int NestLevel = 1;
>   while (Tok && NestLevel > 0) {
> Tok = Tok->getNextNonComment();
> if (Tok) {
>   if (Tok->is(tok::l_square))
> ++NestLevel;
>   if (Tok->is(tok::r_square))
> --NestLevel;
> }
>   }
>   if (Tok)
> Tok = Tok->getNextNonComment();
> }
> ```
That part of code skips attribute so that `FirstNSName` doesn't add attribute 
string into its name.
In the following test case. it's tested. 
```
namespace /* comment  */ [[ xxx ]]   /* comment */  A::M(x) {
int i;
int j;
}  // namespace  A::M(x)
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120931

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


[clang] e5eb365 - [CUDA][HIP] Fix offloading kind for linking C++ programs

2022-03-04 Thread Yaxun Liu via cfe-commits

Author: Yaxun (Sam) Liu
Date: 2022-03-04T15:56:54-05:00
New Revision: e5eb365069cce7bb642421d53a1d3964f8d5bdb7

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

LOG: [CUDA][HIP] Fix offloading kind for linking C++ programs

When both CUDA or HIP programs and C++ programs are passed
to clang driver without -c, C++ programs are treated as CUDA
or HIP program, which is incorrect.

This is because action builder sets the offloading kind of input
job actions to the linking action to be the union of offloading
kind of the input job actions, i.e. if there is one HIP or CUDA
input to the linker, then all the input to the linker is marked
as HIP or CUDA.

To fix this issue, the offload action builder tracks the originating
input argument of each host action, which allows it to determine
the active offload kind of each host action. Then the offload
kind of each input action to the linker can be determined
individually.

Reviewed by: Artem Belevich

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

Added: 


Modified: 
clang/include/clang/Driver/Action.h
clang/lib/Driver/Driver.cpp
clang/test/Driver/hip-phases.hip

Removed: 




diff  --git a/clang/include/clang/Driver/Action.h 
b/clang/include/clang/Driver/Action.h
index 3b6c9e31faa3e..458a10ee11274 100644
--- a/clang/include/clang/Driver/Action.h
+++ b/clang/include/clang/Driver/Action.h
@@ -189,6 +189,11 @@ class Action {
   /// dependences.
   void propagateHostOffloadInfo(unsigned OKinds, const char *OArch);
 
+  void setHostOffloadInfo(unsigned OKinds, const char *OArch) {
+ActiveOffloadKindMask |= OKinds;
+OffloadingArch = OArch;
+  }
+
   /// Set the offload info of this action to be the same as the provided 
action,
   /// and propagate it to its dependences.
   void propagateOffloadInfo(const Action *A);

diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 00d8f1b3b374e..488f0164c7336 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -2465,6 +2465,9 @@ class OffloadingActionBuilder final {
   /// Map between an input argument and the offload kinds used to process it.
   std::map InputArgToOffloadKindMap;
 
+  /// Map between a host action and its originating input argument.
+  std::map HostActionToInputArgMap;
+
   /// Builder interface. It doesn't build anything or keep any state.
   class DeviceActionBuilder {
   public:
@@ -3449,6 +3452,17 @@ class OffloadingActionBuilder final {
   delete SB;
   }
 
+  /// Record a host action and its originating input argument.
+  void recordHostAction(Action *HostAction, const Arg *InputArg) {
+assert(HostAction && "Invalid host action");
+assert(InputArg && "Invalid input argument");
+auto Loc = HostActionToInputArgMap.find(HostAction);
+if (Loc == HostActionToInputArgMap.end())
+  HostActionToInputArgMap[HostAction] = InputArg;
+assert(HostActionToInputArgMap[HostAction] == InputArg &&
+   "host action mapped to multiple input arguments");
+  }
+
   /// Generate an action that adds device dependences (if any) to a host 
action.
   /// If no device dependence actions exist, just return the host action \a
   /// HostAction. If an error is found or if no builder requires the host 
action
@@ -3464,6 +3478,7 @@ class OffloadingActionBuilder final {
   return HostAction;
 
 assert(HostAction && "Invalid host action!");
+recordHostAction(HostAction, InputArg);
 
 OffloadAction::DeviceDependences DDeps;
 // Check if all the programming models agree we should not emit the host
@@ -3517,6 +3532,8 @@ class OffloadingActionBuilder final {
 if (!IsValid)
   return true;
 
+recordHostAction(HostAction, InputArg);
+
 // If we are supporting bundling/unbundling and the current action is an
 // input action of non-source file, we replace the host action by the
 // unbundling action. The bundler tool has the logic to detect if an input
@@ -3533,6 +3550,7 @@ class OffloadingActionBuilder final {
   C.getSingleOffloadToolChain(),
   /*BoundArch=*/StringRef(), Action::OFK_Host);
   HostAction = UnbundlingHostAction;
+  recordHostAction(HostAction, InputArg);
 }
 
 assert(HostAction && "Invalid host action!");
@@ -3569,6 +3587,9 @@ class OffloadingActionBuilder final {
   /// programming models allow it.
   bool appendTopLevelActions(ActionList , Action *HostAction,
  const Arg *InputArg) {
+if (HostAction)
+  recordHostAction(HostAction, InputArg);
+
 // Get the device actions to be appended.
 ActionList OffloadAL;
 for (auto *SB : SpecializedBuilders) {
@@ -3590,6 +3611,7 @@ class OffloadingActionBuilder final {
   // before this method was called.
   

[PATCH] D120911: [CUDA][HIP] Fix offloading kind for linking C++ programs

2022-03-04 Thread Yaxun Liu 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 rGe5eb365069cc: [CUDA][HIP] Fix offloading kind for linking 
C++ programs (authored by yaxunl).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120911

Files:
  clang/include/clang/Driver/Action.h
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/hip-phases.hip

Index: clang/test/Driver/hip-phases.hip
===
--- clang/test/Driver/hip-phases.hip
+++ clang/test/Driver/hip-phases.hip
@@ -459,17 +459,65 @@
 // Test mixed HIP and C++ compilation. HIP program should have HIP offload kind.
 // C++ program should have no offload kind.
 
+// Test compile empty.hip and empty.cpp.
 // RUN: %clang -target x86_64-unknown-linux-gnu \
 // RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
 // RUN: -c %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED %s
-
 // RUN: %clang -target x86_64-unknown-linux-gnu \
 // RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
 // RUN: -c %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED-NEG %s
 
+// Test compile and link empty.hip and empty.cpp.
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED %s
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED-NEG %s
+
+// Test compile and link empty.hip and empty.cpp with --hip-link -fgpu-rdc.
+// RUN: %clang -target x86_64-unknown-linux-gnu --hip-link -fgpu-rdc \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED %s
+// RUN: %clang -target x86_64-unknown-linux-gnu --hip-link -fgpu-rdc \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED-NEG %s
+
+// Test compile and link -x hip empty.hip and -x c++ empty.cpp.
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: -x hip %S/Inputs/empty.hip -x c++ %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED %s
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: -x hip %S/Inputs/empty.hip -x c++ %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED-NEG %s
+
+// Test compile and link -x hip empty.hip and empty.cpp.
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: -x hip %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED2 %s
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: -x hip %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED2-NEG %s
+
+// Test compile and link empty.hip and -x hip empty.cpp.
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: %S/Inputs/empty.hip -x hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED2 %s
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: -x hip %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED2-NEG %s
+
 // MIXED-DAG: input, "{{.*}}empty.hip", hip, (host-hip)
 // MIXED-DAG: input, "{{.*}}empty.hip", hip, (device-hip, gfx803)
 // MIXED-DAG: input, "{{.*}}empty.hip", hip, (device-hip, gfx900)
 // MIXED-DAG: input, "{{.*}}empty.cpp", c++
 // MIXED-NEG-NOT: input, "{{.*}}empty.cpp", c++, (host-hip)
 // MIXED-NEG-NOT: input, "{{.*}}empty.cpp", c++, (device-hip
+
+// MIXED2-DAG: input, "{{.*}}empty.hip", hip, (host-hip)
+// MIXED2-DAG: input, "{{.*}}empty.hip", hip, (device-hip, gfx803)
+// MIXED2-DAG: input, "{{.*}}empty.hip", hip, (device-hip, gfx900)
+// MIXED2-DAG: input, "{{.*}}empty.cpp", hip, (host-hip)
+// MIXED2-DAG: input, "{{.*}}empty.cpp", hip, (device-hip, gfx803)
+// MIXED2-DAG: input, "{{.*}}empty.cpp", hip, (device-hip, gfx900)
+// MIXED2-NEG-NOT: input, "{{.*}}empty.cpp", c++
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -2465,6 +2465,9 @@
   /// Map between an input argument and the 

[PATCH] D119040: Fix LookupTest where it was missing an assertion

2022-03-04 Thread Paul Robinson via Phabricator via cfe-commits
probinson added a reviewer: hokein.
probinson added a subscriber: hokein.
probinson added a comment.
Herald added a project: All.

+ @hokein  who has done work in the one place where `replaceNestedName` is used.


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

https://reviews.llvm.org/D119040

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


[PATCH] D120931: [clang-format] Fix namespace format when the name is a macro expansion

2022-03-04 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added inline comments.



Comment at: clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp:112
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace [[deprecated(\"foo\")]] A::inline M(x)::A {\n"
+"int i;\n"

zequanwu wrote:
> MyDeveloperDay wrote:
> > Is this 2 bugs in one? I notice  you also handling attributes? is this a 
> > different bug? (if so it should really be separate  (but we can let it 
> > slide as long as the tests are thorough)
> > 
> > can you test:
> > 
> > ```
> > namespace /* comment  */ [[ xxx ]]  /* comment */  A {
> > int i;
> > int j;
> > }  // namespace  A
> > 
> > namespace /* comment  */ [[ xxx ]]   A {
> > int i;
> > int j;
> > }  //  namespace A
> > 
> > namespace /* comment  */ [[ xxx ]]   /* comment */ M(x) {
> > int i;
> > int j;
> > }  // namespace  M(x)
> > 
> > namespace /* comment  */ [[ xxx ]]   /* comment */  A::M(x) {
> > int i;
> > int j;
> > }  // namespace  A::M(x)
> > 
> > namespace /* comment  */ [[ xxx ]]   /* comment */ M(x)  /* comment */ {
> > int i;
> > int j;
> > }  // namespace  M(x)  
> > 
> > namespace /* comment  */ [[ xxx ]]   /* comment */  A::M(x) /* comment */  {
> > int i;
> > int j;
> > }  // namespace  A::M(x)
> > ```
> > Is this 2 bugs in one? I notice you also handling attributes? 
> No. This tests with attribute is here to test that candidate name doesn't 
> include attributes, but that is unnecessary. Added the 6 tests above for 
> testing that.
Where are you checking the addition of this

```
if (Tok && Tok->is(tok::l_square)) {
  int NestLevel = 1;
  while (Tok && NestLevel > 0) {
Tok = Tok->getNextNonComment();
if (Tok) {
  if (Tok->is(tok::l_square))
++NestLevel;
  if (Tok->is(tok::r_square))
--NestLevel;
}
  }
  if (Tok)
Tok = Tok->getNextNonComment();
}
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120931

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


[PATCH] D119910: [clang][debug] port clang-cl /JMC flag to ELF

2022-03-04 Thread Yuanfang Chen via Phabricator via cfe-commits
ychen added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:5372
+  // This controls whether or not we perform JustMyCode instrumentation.
+  if (TC.getTriple().isOSBinFormatELF() && Args.hasArg(options::OPT_fjmc)) {
+if (DebugInfoKind >= codegenoptions::DebugInfoConstructor)

rnk wrote:
> Generally all flags have an fno- variant. Normally, this would be 
> `hasFlag(OPT_fjmc, OPT_fno_jmc, false)`, which handles the behavior of making 
> the last flag win. Any reason not to set that up?
I missed that. Before this port, `fjmc` is supposed to be used as cc1 option 
only. With this port, it is also a driver option now. I'll add the no-variant.



Comment at: llvm/lib/CodeGen/JMCInstrumenter.cpp:177
+DefaultCheckFunc->setName(CheckFunctionName);
+DefaultCheckFunc->setLinkage(GlobalValue::WeakODRLinkage);
+CheckFunction = DefaultCheckFunc;

rnk wrote:
> This is a bit pedantic, but the idea is that this weak function will be 
> overridden with a strong function, right? Technically, for that use case, 
> `weak` linkage is the correct linkage. Because the JMC pass runs late after 
> inlining, it is unlikely that this will ever cause issues in practice, but I 
> think it expresses the intention better to use the linkage that matches the 
> use case.
> 
> ODR linkage is supposed to indicate that all definitions must be functionally 
> equivalent. It just turns out that the only real power that grants the 
> optimizer is the ability to inline.
Agreed. I'll change it to `weak` linkage.



Comment at: llvm/test/Instrumentation/JustMyCode/jmc-instrument-elf.ll:1
-; REQUIRES: system-windows
-; RUN: opt -jmc-instrument -mtriple=x86_64-pc-windows-msvc  -S < %s | 
FileCheck %s
-; RUN: opt -jmc-instrument -mtriple=aarch64-pc-windows-msvc -S < %s | 
FileCheck %s
-; RUN: opt -jmc-instrument -mtriple=arm-pc-windows-msvc -S < %s | 
FileCheck %s
+; REQUIRES: system-linux
+; RUN: opt -jmc-instrument -mtriple=x86_64-unknown-linux-gnu  -S < %s | 
FileCheck %s

rnk wrote:
> Please remove the REQUIRES line, this test should pass on Windows, and the 
> other test should pass on Linux as well. Neither of these tests depend on 
> anything from the system.
Yeah, this is a little tricky. It is about the host rather than the target. The 
flag symbol name is computed using `sys::path` functions. It is different 
between Windows and Linux. For testing purposes, I need to anchor them to a 
specific system to check the result. I could've made this `; REQUIRES: 
system-windows` and check the result, I thought it is more intuitive to test 
the ELF on Linux.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119910

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


[PATCH] D120931: [clang-format] Fix namespace format when the name is a macro expansion

2022-03-04 Thread Zequan Wu via Phabricator via cfe-commits
zequanwu added inline comments.



Comment at: clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp:112
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace [[deprecated(\"foo\")]] A::inline M(x)::A {\n"
+"int i;\n"

MyDeveloperDay wrote:
> Is this 2 bugs in one? I notice  you also handling attributes? is this a 
> different bug? (if so it should really be separate  (but we can let it slide 
> as long as the tests are thorough)
> 
> can you test:
> 
> ```
> namespace /* comment  */ [[ xxx ]]  /* comment */  A {
> int i;
> int j;
> }  // namespace  A
> 
> namespace /* comment  */ [[ xxx ]]   A {
> int i;
> int j;
> }  //  namespace A
> 
> namespace /* comment  */ [[ xxx ]]   /* comment */ M(x) {
> int i;
> int j;
> }  // namespace  M(x)
> 
> namespace /* comment  */ [[ xxx ]]   /* comment */  A::M(x) {
> int i;
> int j;
> }  // namespace  A::M(x)
> 
> namespace /* comment  */ [[ xxx ]]   /* comment */ M(x)  /* comment */ {
> int i;
> int j;
> }  // namespace  M(x)  
> 
> namespace /* comment  */ [[ xxx ]]   /* comment */  A::M(x) /* comment */  {
> int i;
> int j;
> }  // namespace  A::M(x)
> ```
> Is this 2 bugs in one? I notice you also handling attributes? 
No. This tests with attribute is here to test that candidate name doesn't 
include attributes, but that is unnecessary. Added the 6 tests above for 
testing that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120931

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


[PATCH] D120931: [clang-format] Fix namespace format when the name is a macro expansion

2022-03-04 Thread Zequan Wu via Phabricator via cfe-commits
zequanwu updated this revision to Diff 413109.
zequanwu marked 4 inline comments as done.
zequanwu added a comment.

Address comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120931

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

Index: clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp
===
--- clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp
+++ clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp
@@ -68,6 +68,127 @@
 "int i;\n"
 "int j;\n"
 "}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace M(x)",
+fixNamespaceEndComments("#define M(x) x##x\n"
+"namespace M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace A::M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A::M(x)",
+fixNamespaceEndComments("#define M(x) x##x\n"
+"namespace A::M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace M(x)::A {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace M(x)::A",
+fixNamespaceEndComments("#define M(x) x##x\n"
+"namespace M(x)::A {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace A::inline M(x)::B {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A::inline M(x)::B",
+fixNamespaceEndComments("#define M(x) x##x\n"
+"namespace A::inline M(x)::B {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace [[deprecated(\"foo\")]] A::inline M(x)::A {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A::inline M(x)::A",
+fixNamespaceEndComments(
+"#define M(x) x##x\n"
+"namespace [[deprecated(\"foo\")]] A::inline M(x)::A {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ(
+  "namespace /* comment */ [[deprecated(\"foo\")]] /* comment */ A {\n"
+  "int i;\n"
+  "int j;\n"
+  "}// namespace A",
+  fixNamespaceEndComments(
+  "namespace /* comment */ [[deprecated(\"foo\")]] /* comment */ A {\n"
+  "int i;\n"
+  "int j;\n"
+  "}"));
+  EXPECT_EQ("namespace /* comment */ [[deprecated(\"foo\")]] A {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A",
+fixNamespaceEndComments(
+"namespace /* comment */ [[deprecated(\"foo\")]] A {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ(
+  "#define M(x) x##x\n"
+  "namespace /* comment */ [[deprecated(\"foo\")]] /* comment */ M(x) {\n"
+  "int i;\n"
+  "int j;\n"
+  "}// namespace M(x)",
+  fixNamespaceEndComments("#define M(x) x##x\n"
+  "namespace /* comment */ "
+  "[[deprecated(\"foo\")]] /* comment */ M(x) {\n"
+  "int i;\n"
+  "int j;\n"
+  "}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace /* comment */ [[deprecated(\"foo\")]] /* comment */ "
+"A::M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace A::M(x)",
+fixNamespaceEndComments(
+"#define M(x) x##x\n"
+"namespace /* comment */ "
+"[[deprecated(\"foo\")]] /* comment */ A::M(x) {\n"
+"int i;\n"
+"int j;\n"
+"}"));
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace /* comment */ [[deprecated(\"foo\")]] /* comment */ "
+"M(x) /* comment */ {\n"
+"int i;\n"
+"int j;\n"
+"}// namespace M(x)",
+fixNamespaceEndComments(
+"#define M(x) x##x\n"
+ 

[PATCH] D120910: [HIP] Fix job action offloading kind for mixed HIP/C++ compilation

2022-03-04 Thread Yaxun Liu 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 rGbde13a8102ba: [HIP] Fix job action offloading kind for mixed 
HIP/C++ compilation (authored by yaxunl).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120910

Files:
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/Inputs/empty.cpp
  clang/test/Driver/Inputs/empty.hip
  clang/test/Driver/hip-phases.hip


Index: clang/test/Driver/hip-phases.hip
===
--- clang/test/Driver/hip-phases.hip
+++ clang/test/Driver/hip-phases.hip
@@ -338,7 +338,7 @@
 // RL2-NB-NOT: linker
 // RL2-NB-NOT: offload
 
-// NL2-DAG: [[P4:[0-9]+]]: linker, {[[P0]], [[P2]]}, image, (host-[[T:hip]])
+// NL2-DAG: [[P4:[0-9]+]]: linker, {[[P0]], [[P2]]}, image
 // RL2-EM-DAG: [[P4:[0-9]+]]: linker, {[[P1]], [[P3]], [[P9]]}, image, 
(host-[[T]])
 // RL2-DEV-NOT: linker
 
@@ -455,3 +455,21 @@
 // PPELLVM2-DAG: [[P9:[0-9]+]]: offload, "device-[[T]] 
(amdgcn-amd-amdhsa:[[ARCH2]])" {[[P8]]}, ir
 // PPELLVM2-DAG: [[P10:[0-9]+]]: clang-offload-bundler, {[[P4]], [[P9]]}, ir, 
(device-hip, )
 // PPELLVM2-NOT: host
+
+// Test mixed HIP and C++ compilation. HIP program should have HIP offload 
kind.
+// C++ program should have no offload kind.
+
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: -c %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck 
-check-prefixes=MIXED %s
+
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: -c %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck 
-check-prefixes=MIXED-NEG %s
+
+// MIXED-DAG: input, "{{.*}}empty.hip", hip, (host-hip)
+// MIXED-DAG: input, "{{.*}}empty.hip", hip, (device-hip, gfx803)
+// MIXED-DAG: input, "{{.*}}empty.hip", hip, (device-hip, gfx900)
+// MIXED-DAG: input, "{{.*}}empty.cpp", c++
+// MIXED-NEG-NOT: input, "{{.*}}empty.cpp", c++, (host-hip)
+// MIXED-NEG-NOT: input, "{{.*}}empty.cpp", c++, (device-hip
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -2692,6 +2692,7 @@
   UA->registerDependentActionInfo(ToolChains[0], Arch,
   AssociatedOffloadKind);
 }
+IsActive = true;
 return ABRT_Success;
   }
 
@@ -3038,6 +3039,9 @@
 getDeviceDependences(OffloadAction::DeviceDependences ,
  phases::ID CurPhase, phases::ID FinalPhase,
  PhasesTy ) override {
+  if (!IsActive)
+return ABRT_Inactive;
+
   // amdgcn does not support linking of object files, therefore we skip
   // backend and assemble phases to output LLVM IR. Except for generating
   // non-relocatable device coee, where we generate fat binary for device


Index: clang/test/Driver/hip-phases.hip
===
--- clang/test/Driver/hip-phases.hip
+++ clang/test/Driver/hip-phases.hip
@@ -338,7 +338,7 @@
 // RL2-NB-NOT: linker
 // RL2-NB-NOT: offload
 
-// NL2-DAG: [[P4:[0-9]+]]: linker, {[[P0]], [[P2]]}, image, (host-[[T:hip]])
+// NL2-DAG: [[P4:[0-9]+]]: linker, {[[P0]], [[P2]]}, image
 // RL2-EM-DAG: [[P4:[0-9]+]]: linker, {[[P1]], [[P3]], [[P9]]}, image, (host-[[T]])
 // RL2-DEV-NOT: linker
 
@@ -455,3 +455,21 @@
 // PPELLVM2-DAG: [[P9:[0-9]+]]: offload, "device-[[T]] (amdgcn-amd-amdhsa:[[ARCH2]])" {[[P8]]}, ir
 // PPELLVM2-DAG: [[P10:[0-9]+]]: clang-offload-bundler, {[[P4]], [[P9]]}, ir, (device-hip, )
 // PPELLVM2-NOT: host
+
+// Test mixed HIP and C++ compilation. HIP program should have HIP offload kind.
+// C++ program should have no offload kind.
+
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: -c %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED %s
+
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: -c %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck -check-prefixes=MIXED-NEG %s
+
+// MIXED-DAG: input, "{{.*}}empty.hip", hip, (host-hip)
+// MIXED-DAG: input, "{{.*}}empty.hip", hip, (device-hip, gfx803)
+// MIXED-DAG: input, "{{.*}}empty.hip", hip, (device-hip, gfx900)
+// MIXED-DAG: input, "{{.*}}empty.cpp", c++
+// MIXED-NEG-NOT: input, "{{.*}}empty.cpp", c++, (host-hip)
+// MIXED-NEG-NOT: input, "{{.*}}empty.cpp", c++, (device-hip
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ 

[clang] bde13a8 - [HIP] Fix job action offloading kind for mixed HIP/C++ compilation

2022-03-04 Thread Yaxun Liu via cfe-commits

Author: Yaxun (Sam) Liu
Date: 2022-03-04T15:34:02-05:00
New Revision: bde13a8102baef4d79723064e6bd27cd39124d91

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

LOG: [HIP] Fix job action offloading kind for mixed HIP/C++ compilation

When both HIP and C++ programs are input files to clang
with -c, clang treats C++ programs as HIP programs,
which is incorrect.

This is due to action builder does not set correct
offloading kind for job actions for C++ programs.

Reviewed by: Artem Belevich

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

Added: 
clang/test/Driver/Inputs/empty.cpp
clang/test/Driver/Inputs/empty.hip

Modified: 
clang/lib/Driver/Driver.cpp
clang/test/Driver/hip-phases.hip

Removed: 




diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 3bfddeefc7b2b..00d8f1b3b374e 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -2692,6 +2692,7 @@ class OffloadingActionBuilder final {
   UA->registerDependentActionInfo(ToolChains[0], Arch,
   AssociatedOffloadKind);
 }
+IsActive = true;
 return ABRT_Success;
   }
 
@@ -3038,6 +3039,9 @@ class OffloadingActionBuilder final {
 getDeviceDependences(OffloadAction::DeviceDependences ,
  phases::ID CurPhase, phases::ID FinalPhase,
  PhasesTy ) override {
+  if (!IsActive)
+return ABRT_Inactive;
+
   // amdgcn does not support linking of object files, therefore we skip
   // backend and assemble phases to output LLVM IR. Except for generating
   // non-relocatable device coee, where we generate fat binary for device

diff  --git a/clang/test/Driver/Inputs/empty.cpp 
b/clang/test/Driver/Inputs/empty.cpp
new file mode 100644
index 0..e69de29bb2d1d

diff  --git a/clang/test/Driver/Inputs/empty.hip 
b/clang/test/Driver/Inputs/empty.hip
new file mode 100644
index 0..e69de29bb2d1d

diff  --git a/clang/test/Driver/hip-phases.hip 
b/clang/test/Driver/hip-phases.hip
index 93bf635dab63f..5e4f6fc9373a4 100644
--- a/clang/test/Driver/hip-phases.hip
+++ b/clang/test/Driver/hip-phases.hip
@@ -338,7 +338,7 @@
 // RL2-NB-NOT: linker
 // RL2-NB-NOT: offload
 
-// NL2-DAG: [[P4:[0-9]+]]: linker, {[[P0]], [[P2]]}, image, (host-[[T:hip]])
+// NL2-DAG: [[P4:[0-9]+]]: linker, {[[P0]], [[P2]]}, image
 // RL2-EM-DAG: [[P4:[0-9]+]]: linker, {[[P1]], [[P3]], [[P9]]}, image, 
(host-[[T]])
 // RL2-DEV-NOT: linker
 
@@ -455,3 +455,21 @@
 // PPELLVM2-DAG: [[P9:[0-9]+]]: offload, "device-[[T]] 
(amdgcn-amd-amdhsa:[[ARCH2]])" {[[P8]]}, ir
 // PPELLVM2-DAG: [[P10:[0-9]+]]: clang-offload-bundler, {[[P4]], [[P9]]}, ir, 
(device-hip, )
 // PPELLVM2-NOT: host
+
+// Test mixed HIP and C++ compilation. HIP program should have HIP offload 
kind.
+// C++ program should have no offload kind.
+
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: -c %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck 
-check-prefixes=MIXED %s
+
+// RUN: %clang -target x86_64-unknown-linux-gnu \
+// RUN: -ccc-print-phases --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 \
+// RUN: -c %S/Inputs/empty.hip %S/Inputs/empty.cpp 2>&1 | FileCheck 
-check-prefixes=MIXED-NEG %s
+
+// MIXED-DAG: input, "{{.*}}empty.hip", hip, (host-hip)
+// MIXED-DAG: input, "{{.*}}empty.hip", hip, (device-hip, gfx803)
+// MIXED-DAG: input, "{{.*}}empty.hip", hip, (device-hip, gfx900)
+// MIXED-DAG: input, "{{.*}}empty.cpp", c++
+// MIXED-NEG-NOT: input, "{{.*}}empty.cpp", c++, (host-hip)
+// MIXED-NEG-NOT: input, "{{.*}}empty.cpp", c++, (device-hip



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


[clang] e22e277 - [RGT] DistroTest: Separate environment-specific test functions

2022-03-04 Thread Paul Robinson via cfe-commits

Author: Paul Robinson
Date: 2022-03-04T12:28:38-08:00
New Revision: e22e2774d93379d6bad41ae20194b076fdb44915

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

LOG: [RGT] DistroTest: Separate environment-specific test functions

This allows using GTEST_SKIP() to identify un-executed tests.

Found by the Rotten Green Tests project.

Added: 


Modified: 
clang/unittests/Driver/DistroTest.cpp

Removed: 




diff  --git a/clang/unittests/Driver/DistroTest.cpp 
b/clang/unittests/Driver/DistroTest.cpp
index b6e4ca9be8579..ebf75dc7ce3a6 100644
--- a/clang/unittests/Driver/DistroTest.cpp
+++ b/clang/unittests/Driver/DistroTest.cpp
@@ -360,16 +360,17 @@ TEST(DistroTest, DetectWindowsAndCrossCompile) {
 unsigned Count{};
   };
 
+  llvm::Triple Host(llvm::sys::getProcessTriple());
+  if (!Host.isOSWindows())
+GTEST_SKIP();
+
   llvm::IntrusiveRefCntPtr RFS =
   llvm::vfs::getRealFileSystem();
-  llvm::Triple Host(llvm::sys::getProcessTriple());
 
   CountingFileSystem CFileSystem;
   Distro LinuxDistro{CFileSystem, llvm::Triple("unknown-pc-linux")};
-  if (Host.isOSWindows()) {
-ASSERT_EQ(Distro(Distro::UnknownDistro), LinuxDistro);
-ASSERT_GT(CFileSystem.Count, 0U);
-  }
+  ASSERT_EQ(Distro(Distro::UnknownDistro), LinuxDistro);
+  ASSERT_GT(CFileSystem.Count, 0U);
 
   Distro WinDistro{CFileSystem, llvm::Triple("unknown-pc-windows")};
   ASSERT_EQ(Distro(Distro::UnknownDistro), WinDistro);
@@ -377,20 +378,25 @@ TEST(DistroTest, DetectWindowsAndCrossCompile) {
 
   // When running on Windows along with a real file system, ensure that no
   // distro is returned if targeting Linux
-  if (Host.isOSWindows()) {
-Distro LinuxRealDistro{*RFS, llvm::Triple("unknown-pc-linux")};
-ASSERT_EQ(Distro(Distro::UnknownDistro), LinuxRealDistro);
-  }
-  // When running on Linux, check if the distro is the same as the host when
-  // targeting Linux
-  if (Host.isOSLinux()) {
-Distro HostDistro{*RFS, Host};
-Distro LinuxRealDistro{*RFS, llvm::Triple("unknown-pc-linux")};
-ASSERT_EQ(HostDistro, LinuxRealDistro);
-  }
+  Distro LinuxRealDistro{*RFS, llvm::Triple("unknown-pc-linux")};
+  ASSERT_EQ(Distro(Distro::UnknownDistro), LinuxRealDistro);
 
   Distro WinRealDistro{*RFS, llvm::Triple("unknown-pc-windows")};
   ASSERT_EQ(Distro(Distro::UnknownDistro), WinRealDistro);
 }
 
+TEST(DistroTest, DetectLinux) {
+  llvm::Triple Host(llvm::sys::getProcessTriple());
+  if (!Host.isOSLinux())
+GTEST_SKIP();
+
+  // When running on Linux, check if the distro is the same as the host when
+  // targeting Linux
+  llvm::IntrusiveRefCntPtr RFS =
+  llvm::vfs::getRealFileSystem();
+  Distro HostDistro{*RFS, Host};
+  Distro LinuxRealDistro{*RFS, llvm::Triple("unknown-pc-linux")};
+  ASSERT_EQ(HostDistro, LinuxRealDistro);
+}
+
 } // end anonymous namespace



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


[PATCH] D121019: [clang-tools-extra] Document clang tidy unit tests target

2022-03-04 Thread Richard via Phabricator via cfe-commits
LegalizeAdulthood created this revision.
LegalizeAdulthood added reviewers: aaron.ballman, njames93, ymandel.
LegalizeAdulthood added a project: clang-tools-extra.
Herald added a project: All.
LegalizeAdulthood requested review of this revision.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D121019

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


Index: clang-tools-extra/docs/clang-tidy/Contributing.rst
===
--- clang-tools-extra/docs/clang-tidy/Contributing.rst
+++ clang-tools-extra/docs/clang-tidy/Contributing.rst
@@ -364,6 +364,11 @@
 test.  The ``ASTMatchersTests`` target contains unit tests for the public AST 
matcher
 classes and is a good source of testing idioms for matchers.
 
+You can build the Clang Tidy unit tests by building the ``ClangTidyTests`` 
target.
+Test targets in LLVM and Clang are excluded from the "build all" style action 
of
+IDE based CMake generators, so you need to explicitly build the target for the 
unit
+tests to be built.
+
 Making your check robust
 
 


Index: clang-tools-extra/docs/clang-tidy/Contributing.rst
===
--- clang-tools-extra/docs/clang-tidy/Contributing.rst
+++ clang-tools-extra/docs/clang-tidy/Contributing.rst
@@ -364,6 +364,11 @@
 test.  The ``ASTMatchersTests`` target contains unit tests for the public AST matcher
 classes and is a good source of testing idioms for matchers.
 
+You can build the Clang Tidy unit tests by building the ``ClangTidyTests`` target.
+Test targets in LLVM and Clang are excluded from the "build all" style action of
+IDE based CMake generators, so you need to explicitly build the target for the unit
+tests to be built.
+
 Making your check robust
 
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D120947: [tooling] Explain how to create a compilation database on Windows [NFC]

2022-03-04 Thread Richard 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 rGd5d03135a716: [tooling] Explain how to create a compilation 
database on Windows [NFC] (authored by LegalizeAdulthood).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120947

Files:
  clang/docs/HowToSetupToolingForLLVM.rst


Index: clang/docs/HowToSetupToolingForLLVM.rst
===
--- clang/docs/HowToSetupToolingForLLVM.rst
+++ clang/docs/HowToSetupToolingForLLVM.rst
@@ -53,6 +53,54 @@
 
   $ make check-all
 
+Setup Clang Tooling Using CMake on Windows
+==
+
+For Windows developers, the Visual Studio project generators in CMake do
+not support `CMAKE_EXPORT_COMPILE_COMMANDS
+`_.
+However, the Ninja generator does support this variable and can be used
+on Windows to generate a suitable ``compile_commands.json`` that invokes
+the MSVC compiler.
+
+First, you will need to install `Ninja`_.  Once installed, the Ninja
+executable will need to be in your search path for CMake to locate it.
+
+Next, assuming you already have Visual Studio installed on your machine, you
+need to have the appropriate environment variables configured so that CMake
+will locate the MSVC compiler for the Ninja generator.  The `documentation
+`_
+describes the necessary environment variable settings, but the simplest thing
+is to use a `developer command-prompt window
+`_
+or call a `developer command file
+`_
+to set the environment variables appropriately.
+
+Now you can run CMake with the Ninja generator to export a compilation
+database:
+
+.. code-block:: console
+
+  C:\> mkdir build-ninja
+  C:\> cd build-ninja
+  C:\build-ninja> cmake -G Ninja -DCMAKE_EXPORT_COMPILE_COMMANDS=ON 
path/to/llvm/sources
+
+It is best to keep your Visual Studio IDE build folder separate from the
+Ninja build folder.  This prevents the two build systems from negatively
+interacting with each other.
+
+Once the ``compile_commands.json`` file has been created by Ninja, you can
+use that compilation database with Clang Tooling.  One caveat is that because
+there are indirect settings obtained through the environment variables,
+you may need to run any Clang Tooling executables through a command prompt
+window created for use with Visual Studio as described above.  An
+alternative, e.g. for using the Visual Studio debugger on a Clang Tooling
+executable, is to ensure that the environment variables are also visible
+to the debugger settings.  This can be done locally in Visual Studio's
+debugger configuration locally or globally by launching the Visual Studio
+IDE from a suitable command-prompt window.
+
 Using Clang Tools
 =
 
@@ -143,9 +191,9 @@
 Using Ninja Build System
 ===
 
-Optionally you can use the `Ninja `_
-build system instead of make. It is aimed at making your builds faster.
-Currently this step will require building Ninja from sources.
+Optionally you can use the `Ninja`_ build system instead of make. It is
+aimed at making your builds faster.  Currently this step will require
+building Ninja from sources.
 
 To take advantage of using Clang Tools along with Ninja build you need
 at least CMake 2.8.9.
@@ -197,3 +245,5 @@
   $ ninja check-all
 
 Other target names can be used in the same way as with make.
+
+.. _Ninja: https://ninja-build.org/


Index: clang/docs/HowToSetupToolingForLLVM.rst
===
--- clang/docs/HowToSetupToolingForLLVM.rst
+++ clang/docs/HowToSetupToolingForLLVM.rst
@@ -53,6 +53,54 @@
 
   $ make check-all
 
+Setup Clang Tooling Using CMake on Windows
+==
+
+For Windows developers, the Visual Studio project generators in CMake do
+not support `CMAKE_EXPORT_COMPILE_COMMANDS
+`_.
+However, the Ninja generator does support this variable and can be used
+on Windows to generate a suitable ``compile_commands.json`` that invokes
+the MSVC compiler.
+
+First, you will need to install `Ninja`_.  Once installed, the Ninja
+executable will need to be in your search path for CMake to locate it.
+
+Next, assuming you already have Visual Studio installed on your machine, you
+need to have the appropriate environment 

[clang] d5d0313 - [tooling] Explain how to create a compilation database on Windows [NFC]

2022-03-04 Thread via cfe-commits

Author: Richard
Date: 2022-03-04T13:06:08-07:00
New Revision: d5d03135a7160586e2b09dc47c7021379252fbbd

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

LOG: [tooling] Explain how to create a compilation database on Windows [NFC]

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

Added: 


Modified: 
clang/docs/HowToSetupToolingForLLVM.rst

Removed: 




diff  --git a/clang/docs/HowToSetupToolingForLLVM.rst 
b/clang/docs/HowToSetupToolingForLLVM.rst
index cbe15abaab3b4..62189511aeb2a 100644
--- a/clang/docs/HowToSetupToolingForLLVM.rst
+++ b/clang/docs/HowToSetupToolingForLLVM.rst
@@ -53,6 +53,54 @@ Now you are ready to build and test LLVM using make:
 
   $ make check-all
 
+Setup Clang Tooling Using CMake on Windows
+==
+
+For Windows developers, the Visual Studio project generators in CMake do
+not support `CMAKE_EXPORT_COMPILE_COMMANDS
+`_.
+However, the Ninja generator does support this variable and can be used
+on Windows to generate a suitable ``compile_commands.json`` that invokes
+the MSVC compiler.
+
+First, you will need to install `Ninja`_.  Once installed, the Ninja
+executable will need to be in your search path for CMake to locate it.
+
+Next, assuming you already have Visual Studio installed on your machine, you
+need to have the appropriate environment variables configured so that CMake
+will locate the MSVC compiler for the Ninja generator.  The `documentation
+`_
+describes the necessary environment variable settings, but the simplest thing
+is to use a `developer command-prompt window
+`_
+or call a `developer command file
+`_
+to set the environment variables appropriately.
+
+Now you can run CMake with the Ninja generator to export a compilation
+database:
+
+.. code-block:: console
+
+  C:\> mkdir build-ninja
+  C:\> cd build-ninja
+  C:\build-ninja> cmake -G Ninja -DCMAKE_EXPORT_COMPILE_COMMANDS=ON 
path/to/llvm/sources
+
+It is best to keep your Visual Studio IDE build folder separate from the
+Ninja build folder.  This prevents the two build systems from negatively
+interacting with each other.
+
+Once the ``compile_commands.json`` file has been created by Ninja, you can
+use that compilation database with Clang Tooling.  One caveat is that because
+there are indirect settings obtained through the environment variables,
+you may need to run any Clang Tooling executables through a command prompt
+window created for use with Visual Studio as described above.  An
+alternative, e.g. for using the Visual Studio debugger on a Clang Tooling
+executable, is to ensure that the environment variables are also visible
+to the debugger settings.  This can be done locally in Visual Studio's
+debugger configuration locally or globally by launching the Visual Studio
+IDE from a suitable command-prompt window.
+
 Using Clang Tools
 =
 
@@ -143,9 +191,9 @@ Examples:
 Using Ninja Build System
 ===
 
-Optionally you can use the `Ninja `_
-build system instead of make. It is aimed at making your builds faster.
-Currently this step will require building Ninja from sources.
+Optionally you can use the `Ninja`_ build system instead of make. It is
+aimed at making your builds faster.  Currently this step will require
+building Ninja from sources.
 
 To take advantage of using Clang Tools along with Ninja build you need
 at least CMake 2.8.9.
@@ -197,3 +245,5 @@ Now you are ready to build and test LLVM using Ninja:
   $ ninja check-all
 
 Other target names can be used in the same way as with make.
+
+.. _Ninja: https://ninja-build.org/



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


[PATCH] D120947: [tooling] Explain how to create a compilation database on Windows [NFC]

2022-03-04 Thread Richard via Phabricator via cfe-commits
LegalizeAdulthood updated this revision to Diff 413093.
LegalizeAdulthood marked an inline comment as done.
LegalizeAdulthood added a comment.

Update from review comments


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

https://reviews.llvm.org/D120947

Files:
  clang/docs/HowToSetupToolingForLLVM.rst


Index: clang/docs/HowToSetupToolingForLLVM.rst
===
--- clang/docs/HowToSetupToolingForLLVM.rst
+++ clang/docs/HowToSetupToolingForLLVM.rst
@@ -53,6 +53,54 @@
 
   $ make check-all
 
+Setup Clang Tooling Using CMake on Windows
+==
+
+For Windows developers, the Visual Studio project generators in CMake do
+not support `CMAKE_EXPORT_COMPILE_COMMANDS
+`_.
+However, the Ninja generator does support this variable and can be used
+on Windows to generate a suitable ``compile_commands.json`` that invokes
+the MSVC compiler.
+
+First, you will need to install `Ninja`_.  Once installed, the Ninja
+executable will need to be in your search path for CMake to locate it.
+
+Next, assuming you already have Visual Studio installed on your machine, you
+need to have the appropriate environment variables configured so that CMake
+will locate the MSVC compiler for the Ninja generator.  The `documentation
+`_
+describes the necessary environment variable settings, but the simplest thing
+is to use a `developer command-prompt window
+`_
+or call a `developer command file
+`_
+to set the environment variables appropriately.
+
+Now you can run CMake with the Ninja generator to export a compilation
+database:
+
+.. code-block:: console
+
+  C:\> mkdir build-ninja
+  C:\> cd build-ninja
+  C:\build-ninja> cmake -G Ninja -DCMAKE_EXPORT_COMPILE_COMMANDS=ON 
path/to/llvm/sources
+
+It is best to keep your Visual Studio IDE build folder separate from the
+Ninja build folder.  This prevents the two build systems from negatively
+interacting with each other.
+
+Once the ``compile_commands.json`` file has been created by Ninja, you can
+use that compilation database with Clang Tooling.  One caveat is that because
+there are indirect settings obtained through the environment variables,
+you may need to run any Clang Tooling executables through a command prompt
+window created for use with Visual Studio as described above.  An
+alternative, e.g. for using the Visual Studio debugger on a Clang Tooling
+executable, is to ensure that the environment variables are also visible
+to the debugger settings.  This can be done locally in Visual Studio's
+debugger configuration locally or globally by launching the Visual Studio
+IDE from a suitable command-prompt window.
+
 Using Clang Tools
 =
 
@@ -143,9 +191,9 @@
 Using Ninja Build System
 ===
 
-Optionally you can use the `Ninja `_
-build system instead of make. It is aimed at making your builds faster.
-Currently this step will require building Ninja from sources.
+Optionally you can use the `Ninja`_ build system instead of make. It is
+aimed at making your builds faster.  Currently this step will require
+building Ninja from sources.
 
 To take advantage of using Clang Tools along with Ninja build you need
 at least CMake 2.8.9.
@@ -197,3 +245,5 @@
   $ ninja check-all
 
 Other target names can be used in the same way as with make.
+
+.. _Ninja: https://ninja-build.org/


Index: clang/docs/HowToSetupToolingForLLVM.rst
===
--- clang/docs/HowToSetupToolingForLLVM.rst
+++ clang/docs/HowToSetupToolingForLLVM.rst
@@ -53,6 +53,54 @@
 
   $ make check-all
 
+Setup Clang Tooling Using CMake on Windows
+==
+
+For Windows developers, the Visual Studio project generators in CMake do
+not support `CMAKE_EXPORT_COMPILE_COMMANDS
+`_.
+However, the Ninja generator does support this variable and can be used
+on Windows to generate a suitable ``compile_commands.json`` that invokes
+the MSVC compiler.
+
+First, you will need to install `Ninja`_.  Once installed, the Ninja
+executable will need to be in your search path for CMake to locate it.
+
+Next, assuming you already have Visual Studio installed on your machine, you
+need to have the appropriate environment variables configured so that CMake
+will locate the MSVC compiler for the Ninja generator.  The `documentation

[PATCH] D119778: [clang] Add a note "deducing return type for 'foo'"

2022-03-04 Thread Arthur O'Dwyer via Phabricator via cfe-commits
Quuxplusone updated this revision to Diff 413089.
Quuxplusone added a comment.
Herald added a project: All.

Rebased after landing D119184 . I'm no longer 
necessarily trying to land this note (it's not directly relevant to my 
interests anymore), but I'd like to show its CI as green before I abandon it. 
@rsmith would you like me to do something other than abandon this?


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

https://reviews.llvm.org/D119778

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/Frontend/FrontendActions.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaTemplateInstantiate.cpp
  clang/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p2-1z.cpp
  clang/test/CXX/dcl.dcl/dcl.spec/dcl.type/dcl.spec.auto/p7-cxx14.cpp
  clang/test/CXX/dcl/dcl.spec/dcl.type/dcl.spec.auto/p6.cpp
  clang/test/SemaCUDA/autoret-global.cu
  clang/test/SemaCXX/cxx2b-consteval-if.cpp
  clang/test/SemaCXX/deduced-return-type-cxx14.cpp
  clang/test/SemaCXX/deduced-return-void.cpp
  clang/test/SemaCXX/typo-correction-crash.cpp
  clang/test/SemaTemplate/concepts.cpp

Index: clang/test/SemaTemplate/concepts.cpp
===
--- clang/test/SemaTemplate/concepts.cpp
+++ clang/test/SemaTemplate/concepts.cpp
@@ -114,6 +114,7 @@
   }
   template void g5() {
 ([]() -> C auto{ // expected-error-re {{deduced type {{.*}} does not satisfy}}
+// expected-note@-1 {{deducing return type for 'operator()'}}
  return T();
  }(), ...);
   }
@@ -174,26 +175,34 @@
   template concept C = false; // expected-note 6 {{because 'false' evaluated to false}}
 
   C auto f1() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+// expected-note@-1 {{deducing return type for 'f1'}}
 return void();
   }
   C auto f2() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+// expected-note@-1 {{deducing return type for 'f2'}}
 return;
   }
   C auto f3() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+// expected-note@-1 {{deducing return type for 'f3'}}
   }
   C decltype(auto) f4() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+  // expected-note@-1 {{deducing return type for 'f4'}}
 return void();
   }
   C decltype(auto) f5() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+  // expected-note@-1 {{deducing return type for 'f5'}}
 return;
   }
   C decltype(auto) f6() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+  // expected-note@-1 {{deducing return type for 'f6'}}
   }
   C auto& f7() { // expected-error {{cannot form a reference to 'void'}}
+ // expected-note@-1 {{deducing return type for 'f7'}}
 return void();
   }
   C auto& f8() {
 return; // expected-error {{cannot deduce return type 'C auto &' from omitted return expression}}
+// expected-note@-2 {{deducing return type for 'f8'}}
   }
   C auto& f9() { // expected-error {{cannot deduce return type 'C auto &' for function with no return statements}}
   }
Index: clang/test/SemaCXX/typo-correction-crash.cpp
===
--- clang/test/SemaCXX/typo-correction-crash.cpp
+++ clang/test/SemaCXX/typo-correction-crash.cpp
@@ -9,6 +9,7 @@
   return "s";
   return tes; // expected-error {{use of undeclared identifier 'tes'; did you mean 'test'?}}
   // expected-error@-1 {{deduced as 'int' here but deduced as 'const char *' in earlier}}
+  // expected-note@-4 {{deducing return type for 'check2'}}
 }
 
 template  struct is_same { static constexpr bool value = false; };
Index: clang/test/SemaCXX/deduced-return-void.cpp
===
--- clang/test/SemaCXX/deduced-return-void.cpp
+++ clang/test/SemaCXX/deduced-return-void.cpp
@@ -16,10 +16,12 @@
 auto f4() {
   return i;
   return; // expected-error {{'auto' in return type deduced as 'void' here but deduced as 'int' in earlier return statement}}
+  // expected-note@-3 {{deducing return type for 'f4'}}
 }
 auto f5() {
   return i;
   return void(); // expected-error {{'auto' in return type deduced as 'void' here but deduced as 'int' in earlier return statement}}
+ // expected-note@-3 {{deducing return type for 'f5'}}
 }
 
 auto l1 = []() { };
@@ -44,10 +46,12 @@
 decltype(auto) f4() {
   return i;
   return; // expected-error {{'decltype(auto)' in return type deduced as 'void' here but deduced as 'int' in earlier return statement}}
+  // expected-note@-3 {{deducing return type for 'f4'}}
 }
 decltype(auto) f5() {
   return i;
   return void(); // expected-error {{'decltype(auto)' in return type deduced as 'void' here but 

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

2022-03-04 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 added inline comments.



Comment at: clang/lib/Driver/Driver.cpp:4132-4134
+  Archs.insert(CudaArchToString(CudaArch::SM_35));
+else if (Kind == Action::OFK_HIP)
+  Archs.insert(CudaArchToString(CudaArch::GFX803));

tra wrote:
> JonChesterfield wrote:
> > tra wrote:
> > > If we do not have constants for the default CUDA/HIP arch yet, we should 
> > > probably add them and use them here.
> > Defaulting hip to gfx803 is unlikely to be helpful. It won't run on other 
> > architectures, i.e. there's no conservative default that will run on most 
> > things. I guess that's an existing quirk of the hip toolchain?
> I agree that there's no "safe" choice of GPU target. It applies to CUDA, as 
> well, at least for GPU binaries.
> That said, we still want `clang -c foo.cu` to work.
> 
> For CUDA we use the oldest variant still supported by the vendor. It produces 
> PTX assembly which we embed along with the GPU binary. 
> That PTX is valid for newer GPU archtectures and CUDA runtime will be able to 
> compile it for the GPU the app happens to run on. It's not ideal, but it 
> works.
> 
> While for AMDGPU we do not have such forward compatibility mode as we have 
> with CUDA, being able to compile for *something* by default is still useful, 
> IMO.
> 
> 
I just copied GFX803 because that's what the previous driver used. I agree we 
should just default to something, maybe in the AMD case we can issue a warning 
telling them to use the flag to properly specify it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120272

___
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-03-04 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 updated this revision to Diff 413087.
jhuber6 added a comment.
Herald added a subscriber: dexonsmith.

Addressing nits.


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/Basic/DiagnosticDriverKinds.td
  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
@@ -4391,6 +4391,7 @@
   // one input.
   bool IsCuda = JA.isOffloading(Action::OFK_Cuda);
   bool IsCudaDevice = JA.isDeviceOffloading(Action::OFK_Cuda);
+  bool IsCudaHost = JA.isHostOffloading(Action::OFK_Cuda);
   bool IsHIP = JA.isOffloading(Action::OFK_HIP);
   bool IsHIPDevice = JA.isDeviceOffloading(Action::OFK_HIP);
   bool IsOpenMPDevice = JA.isDeviceOffloading(Action::OFK_OpenMP);
@@ -4414,6 +4415,7 @@
 
   InputInfoList ModuleHeaderInputs;
   InputInfoList OpenMPHostInputs;
+  InputInfoList CudaHostInputs;
   const InputInfo *CudaDeviceInput = nullptr;
   const InputInfo *OpenMPDeviceInput = nullptr;
   for (const InputInfo  : Inputs) {
@@ -4428,6 +4430,8 @@
 << types::getTypeName(Expected);
   }
   ModuleHeaderInputs.push_back(I);
+} else if (IsCudaHost && Args.hasArg(options::OPT_fopenmp_new_driver)) {
+  CudaHostInputs.push_back(I);
 } else if ((IsCuda || IsHIP) && !CudaDeviceInput) {
   CudaDeviceInput = 
 } else if (IsOpenMPDevice && !OpenMPDeviceInput) {
@@ -6957,6 +6961,7 @@
 auto OpenMPTCs = C.getOffloadToolChains();
 for (auto TI = OpenMPTCs.first, TE = OpenMPTCs.second; TI != TE;
  ++TI, ++InputFile) {
+  assert(InputFile->isFilename() && "Offloading requires a filename");
   const ToolChain *TC = TI->second;
   const ArgList  = C.getArgsForToolChain(TC, "", Action::OFK_OpenMP);
   StringRef File =
@@ -6969,6 +6974,20 @@
   TC->getTripleString() + "." +
   TCArgs.getLastArgValue(options::OPT_march_EQ) + "." + InputName));
 }
+  } else if (IsCudaHost && !CudaHostInputs.empty()) {
+const ToolChain *TC = C.getSingleOffloadToolChain();
+for (const auto  : CudaHostInputs) {
+  assert(InputFile.isFilename() && "Offloading requires a filename");
+  StringRef File =
+  C.getArgs().MakeArgString(TC->getInputFilename(InputFile));
+  StringRef InputName = Clang::getBaseInputStem(Args, Inputs);
+  // The CUDA toolchain should have a bound arch appended to the filename.
+  StringRef Arch = File.split(".").first.rsplit('-').second;
+  CmdArgs.push_back(Args.MakeArgString(
+  "-fembed-offload-object=" + File + "," +
+  Action::GetOffloadKindName(Action::OFK_Cuda) + "." +
+  TC->getTripleString() + "." + Arch + "." + InputName));
+}
   }
 
   if (Triple.isAMDGPU()) {
@@ -8220,14 +8239,17 @@
   ArgStringList CmdArgs;
 
   // Pass the CUDA path to the linker wrapper tool.
-  for (auto  : 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=" + 

[PATCH] D120244: [clang][sema] Enable first-class bool support for C2x

2022-03-04 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.
Herald added a project: All.

Thanks for working on this! It's worth noting that 
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2935.pdf was what was adopted 
by WG14 a few weeks ago, so you should be checking against that one, not the 
initial version of the paper.
 It's also worth noting that your changes are partially covering 
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2934.pdf which was adopted at 
the same meeting (setting `Opts.Bool` to true means you get `bool` and `true` 
and `false`); I would note that in the commit message, because I don't think 
it's worth trying to separate out `bool`, `true`, and `false` from one another 
in the implementation. But it is worth adding the deprecation warning to use of 
`_Bool` from that paper and removing the macro for `bool` in C2x mode from 
`` as part of these changes in this patch.

I think you're missing some test coverage for the preprocessor in the patch. 
e.g.,

  #if true != 1
  #error "oops"
  #endif
  
  #if false != 0
  #error "oops"
  #endif

And I don't see the changes to the  header which is now obsolete in 
C2x.

Oh, and the change should be added to the release notes.




Comment at: clang/lib/Frontend/CompilerInvocation.cpp:3247
 
   // OpenCL and C++ both have bool, true, false keywords.
+  Opts.Bool = Opts.OpenCL || Opts.CPlusPlus || Opts.C2x;

Comment is now stale.



Comment at: clang/test/Sema/c2x-bool.c:1
+// RUN: %clang_cc1 -triple x86_64-apple-darwin -std=c2x -x c -fsyntax-only 
-verify %s
+

Is the triple necessary?



Comment at: clang/test/Sema/c2x-bool.c:14
+_Static_assert(false == (bool)+0);
+
+

You should also add a test to verify that the predefined constants are usable 
as an integer constant expression:
```
char c1[true]; // good
_Static_assert(sizeof(c1) == sizeof(char[1]));
char c2[false]; // zero-sized array declaration
```
(This covers the changes in 6.6.)





Comment at: clang/test/Sema/c2x-bool.c:15
+
+
+static void *f = false; // expected-warning {{to null from a constant boolean 
expression}}

Another test case that's needed is for the integer promotion rules:
```
_Static_assert(_Generic(+true, bool : 0, unsigned int : 0, signed int : 1, 
default : 0));

struct S {
  bool b : 1;
} s;
_Static_assert(_Generic(+s.b, bool : 0, unsigned int : 0, signed int : 1, 
default : 0));
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120244

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


[PATCH] D119918: [CMake] Rename TARGET_TRIPLE to LLVM_TARGET_TRIPLE

2022-03-04 Thread Amir Ayupov via Phabricator via cfe-commits
Amir accepted this revision.
Amir added a comment.

LGTM from BOLT side


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119918

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


[PATCH] D120934: [OpenMP][NFC] Refactor new driver to be more general

2022-03-04 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert accepted this revision.
jdoerfert added a comment.
This revision is now accepted and ready to land.

LG


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120934

___
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-03-04 Thread Artem Belevich via Phabricator via cfe-commits
tra added inline comments.



Comment at: clang/lib/Driver/Driver.cpp:4132-4134
+  Archs.insert(CudaArchToString(CudaArch::SM_35));
+else if (Kind == Action::OFK_HIP)
+  Archs.insert(CudaArchToString(CudaArch::GFX803));

JonChesterfield wrote:
> tra wrote:
> > If we do not have constants for the default CUDA/HIP arch yet, we should 
> > probably add them and use them here.
> Defaulting hip to gfx803 is unlikely to be helpful. It won't run on other 
> architectures, i.e. there's no conservative default that will run on most 
> things. I guess that's an existing quirk of the hip toolchain?
I agree that there's no "safe" choice of GPU target. It applies to CUDA, as 
well, at least for GPU binaries.
That said, we still want `clang -c foo.cu` to work.

For CUDA we use the oldest variant still supported by the vendor. It produces 
PTX assembly which we embed along with the GPU binary. 
That PTX is valid for newer GPU archtectures and CUDA runtime will be able to 
compile it for the GPU the app happens to run on. It's not ideal, but it works.

While for AMDGPU we do not have such forward compatibility mode as we have with 
CUDA, being able to compile for *something* by default is still useful, IMO.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120272

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


[PATCH] D119918: [CMake] Rename TARGET_TRIPLE to LLVM_TARGET_TRIPLE

2022-03-04 Thread Louis Dionne via Phabricator via cfe-commits
ldionne added a comment.
Herald added a project: All.

Shall we land this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119918

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


[PATCH] D121014: [WebAssembly] Check bulk-memory when adjusting lang opts

2022-03-04 Thread Thomas Lively via Phabricator via cfe-commits
tlively created this revision.
tlively added a reviewer: sbc100.
Herald added subscribers: wingo, ecnelises, sunfish, jgravelle-google, dschuff.
Herald added a project: All.
tlively requested review of this revision.
Herald added subscribers: cfe-commits, aheejin.
Herald added a project: clang.

We previously had logic to disable pthreads, set the ThreadModel to Single, and
disable thread-safe statics when the atomics target features is disabled, since
that means that the resulting program will not be used in a threaded context.
Similarly check for the presence of the bulk-memory feature, since that is also
necessary to produce multithreaded programs.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D121014

Files:
  clang/lib/Basic/Targets/WebAssembly.cpp
  clang/test/CodeGenCXX/static-init-wasm.cpp


Index: clang/test/CodeGenCXX/static-init-wasm.cpp
===
--- clang/test/CodeGenCXX/static-init-wasm.cpp
+++ clang/test/CodeGenCXX/static-init-wasm.cpp
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -emit-llvm -triple=wasm32-unknown-unknown -target-feature 
+atomics -o - %s \
+// RUN: %clang_cc1 -emit-llvm -triple=wasm32-unknown-unknown -target-feature 
+atomics -target-feature +bulk-memory -o - %s \
 // RUN:   | FileCheck %s -check-prefix=WEBASSEMBLY32
-// RUN: %clang_cc1 -emit-llvm -triple=wasm64-unknown-unknown -target-feature 
+atomics -o - %s \
+// RUN: %clang_cc1 -emit-llvm -triple=wasm64-unknown-unknown -target-feature 
+atomics -target-feature +bulk-memory -o - %s \
 // RUN:   | FileCheck %s -check-prefix=WEBASSEMBLY64
 
 // Test that we don't create common blocks.
@@ -53,9 +53,9 @@
 // WEBASSEMBLY64: define internal void @_GLOBAL__sub_I_static_init_wasm.cpp() 
#3 {
 // WEBASSEMBLY64: call void @__cxx_global_var_init()
 
-// RUN: %clang_cc1 -emit-llvm -triple=wasm32-unknown-unknown -o - %s \
+// RUN: %clang_cc1 -emit-llvm -triple=wasm32-unknown-unknown -target-feature 
+bulk-memory -o - %s \
 // RUN:   | FileCheck %s -check-prefix=NOATOMICS
-// RUN: %clang_cc1 -emit-llvm -triple=wasm64-unknown-unknown -o - %s \
+// RUN: %clang_cc1 -emit-llvm -triple=wasm64-unknown-unknown -target-feature 
+bulk-memory -o - %s \
 // RUN:   | FileCheck %s -check-prefix=NOATOMICS
 
 // NOATOMICS-LABEL: @_Z1gv()
@@ -66,3 +66,17 @@
 // NOATOMICS-NOT:   __cxa_guard_acquire
 // NOATOMICS:   [[END]]:
 // NOATOMICS-NEXT:  ret void
+
+// RUN: %clang_cc1 -emit-llvm -triple=wasm32-unknown-unknown -target-feature 
+atomics -o - %s \
+// RUN:   | FileCheck %s -check-prefix=NOBULKMEM
+// RUN: %clang_cc1 -emit-llvm -triple=wasm64-unknown-unknown -target-feature 
+atomics -o - %s \
+// RUN:   | FileCheck %s -check-prefix=NOBULKMEM
+
+// NOBULKMEM-LABEL: @_Z1gv()
+// NOBULKMEM:   %[[R0:.+]] = load i8, i8* @_ZGVZ1gvE1a, align 1
+// NOBULKMEM-NEXT:  %guard.uninitialized = icmp eq i8 %[[R0]], 0
+// NOBULKMEM-NEXT:  br i1 %guard.uninitialized, label %[[CHECK:.+]], label 
%[[END:.+]],
+// NOBULKMEM:   [[CHECK]]:
+// NOBULKMEM-NOT:   __cxa_guard_acquire
+// NOBULKMEM:   [[END]]:
+// NOBULKMEM-NEXT:  ret void
Index: clang/lib/Basic/Targets/WebAssembly.cpp
===
--- clang/lib/Basic/Targets/WebAssembly.cpp
+++ clang/lib/Basic/Targets/WebAssembly.cpp
@@ -256,9 +256,10 @@
 void WebAssemblyTargetInfo::adjust(DiagnosticsEngine ,
LangOptions ) {
   TargetInfo::adjust(Diags, Opts);
-  // If the Atomics feature isn't available, turn off POSIXThreads and
-  // ThreadModel, so that we don't predefine _REENTRANT or __STDCPP_THREADS__.
-  if (!HasAtomics) {
+  // Turn off POSIXThreads and ThreadModel so that we don't predefine 
_REENTRANT
+  // or __STDCPP_THREADS__ if we will eventually end up stripping atomics
+  // because they are unsupported.
+  if (!HasAtomics || !HasBulkMemory) {
 Opts.POSIXThreads = false;
 Opts.setThreadModel(LangOptions::ThreadModelKind::Single);
 Opts.ThreadsafeStatics = false;


Index: clang/test/CodeGenCXX/static-init-wasm.cpp
===
--- clang/test/CodeGenCXX/static-init-wasm.cpp
+++ clang/test/CodeGenCXX/static-init-wasm.cpp
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -emit-llvm -triple=wasm32-unknown-unknown -target-feature +atomics -o - %s \
+// RUN: %clang_cc1 -emit-llvm -triple=wasm32-unknown-unknown -target-feature +atomics -target-feature +bulk-memory -o - %s \
 // RUN:   | FileCheck %s -check-prefix=WEBASSEMBLY32
-// RUN: %clang_cc1 -emit-llvm -triple=wasm64-unknown-unknown -target-feature +atomics -o - %s \
+// RUN: %clang_cc1 -emit-llvm -triple=wasm64-unknown-unknown -target-feature +atomics -target-feature +bulk-memory -o - %s \
 // RUN:   | FileCheck %s -check-prefix=WEBASSEMBLY64
 
 // Test that we don't create common blocks.
@@ -53,9 +53,9 @@
 // WEBASSEMBLY64: define internal void @_GLOBAL__sub_I_static_init_wasm.cpp() #3 {
 // WEBASSEMBLY64: call void 

[PATCH] D120984: [clang][dataflow] Extend flow conditions from block terminators

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



Comment at: clang/include/clang/Analysis/FlowSensitive/DataflowEnvironment.h:99
+   const Environment , Value ,
+   Environment ) {
   return false;

`MergedEnv`? Also, the documentation above gives a short description of the 
relationship between `Val1`, `Val2`, and `MergedVal`. But it gives little 
pointers what are we supposed to do with the `Environment`. 



Comment at: clang/lib/Analysis/FlowSensitive/DataflowEnvironment.cpp:123
+  if (Constraints1.empty() || Constraints2.empty()) {
+// Disjunction of empty set and non-empty set is represented as empty set.
+return JoinedConstraints;

Is this actually correct? Or did you mean `Conjunction`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120984

___
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-03-04 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield added inline comments.



Comment at: clang/lib/Driver/Driver.cpp:4132-4134
+  Archs.insert(CudaArchToString(CudaArch::SM_35));
+else if (Kind == Action::OFK_HIP)
+  Archs.insert(CudaArchToString(CudaArch::GFX803));

tra wrote:
> If we do not have constants for the default CUDA/HIP arch yet, we should 
> probably add them and use them here.
Defaulting hip to gfx803 is unlikely to be helpful. It won't run on other 
architectures, i.e. there's no conservative default that will run on most 
things. I guess that's an existing quirk of the hip toolchain?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120272

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


[PATCH] D120888: [clang] Stop dragging a EndLoc around when parsing attributes

2022-03-04 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 aside from two formatting nits, thank you for the cleanup!




Comment at: clang/lib/Parse/ParsePragma.cpp:1373
 
-  PragmaAttributeInfo(ParsedAttributes ) : Attributes(Attributes) {}
+  PragmaAttributeInfo(ParsedAttributesWithRange ) : 
Attributes(Attributes) {}
 };

Probably worth reformatting this before you land.


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

https://reviews.llvm.org/D120888

___
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-03-04 Thread Artem Belevich via Phabricator via cfe-commits
tra added inline comments.



Comment at: clang/lib/Driver/Driver.cpp:4107
+ options::OPT_no_offload_arch_EQ)) {
+C.getDriver().Diag(diag::err_opt_not_valid_with_opt) << "--offload-arch"
+ << "--offload";

Nit: It would be nice to report specific option which triggered the diag. 
Reporting `--offload-arch` when it's triggered by `--no-offload-arch` would be 
somewhat confusing.

`Args.hasArgNoClaim(options::OPT_offload_arch_EQ) ? "--offload-arch" : 
--no-offload-arch` ?



Comment at: clang/lib/Driver/Driver.cpp:4132-4134
+  Archs.insert(CudaArchToString(CudaArch::SM_35));
+else if (Kind == Action::OFK_HIP)
+  Archs.insert(CudaArchToString(CudaArch::GFX803));

If we do not have constants for the default CUDA/HIP arch yet, we should 
probably add them and use them here.



Comment at: clang/lib/Driver/Driver.cpp:4171
 
-for (unsigned I = 0; I < ToolChains.size(); ++I)
+if (!Relocatable)
+  Diags.Report(diag::err_drv_non_relocatable);

If we do not allow non-relocatable compilation with the new driver, perhaps we 
should make `-fgpu-rdc` enabled by default with the new driver and error out if 
someone attempts to use `-fno-gpu-rdc`. Otherwise we're virtually guaranteed 
that everyone attempting to use `-foffload-new-driver` will hit this error.




Comment at: clang/lib/Driver/Driver.cpp:4172
+if (!Relocatable)
+  Diags.Report(diag::err_drv_non_relocatable);
+

Do we want to return early here?



Comment at: clang/lib/Driver/Driver.cpp:4221
+auto TCAndArch = TCAndArchs.begin();
 for (Action *A : DeviceActions) {
+  DDeps.add(*A, *TCAndArch->first, TCAndArch->second.data(), Kind);

Nit: We do have `llvm::zip` for iterating over multiple containers. However, 
unpacking loop variable results maybe more trouble than it's worth it in such a 
small loop, Up to you.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120272

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


[PATCH] D119910: [clang][debug] port clang-cl /JMC flag to ELF

2022-03-04 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added inline comments.
Herald added a project: All.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:5372
+  // This controls whether or not we perform JustMyCode instrumentation.
+  if (TC.getTriple().isOSBinFormatELF() && Args.hasArg(options::OPT_fjmc)) {
+if (DebugInfoKind >= codegenoptions::DebugInfoConstructor)

Generally all flags have an fno- variant. Normally, this would be 
`hasFlag(OPT_fjmc, OPT_fno_jmc, false)`, which handles the behavior of making 
the last flag win. Any reason not to set that up?



Comment at: llvm/lib/CodeGen/JMCInstrumenter.cpp:177
+DefaultCheckFunc->setName(CheckFunctionName);
+DefaultCheckFunc->setLinkage(GlobalValue::WeakODRLinkage);
+CheckFunction = DefaultCheckFunc;

This is a bit pedantic, but the idea is that this weak function will be 
overridden with a strong function, right? Technically, for that use case, 
`weak` linkage is the correct linkage. Because the JMC pass runs late after 
inlining, it is unlikely that this will ever cause issues in practice, but I 
think it expresses the intention better to use the linkage that matches the use 
case.

ODR linkage is supposed to indicate that all definitions must be functionally 
equivalent. It just turns out that the only real power that grants the 
optimizer is the ability to inline.



Comment at: llvm/test/Instrumentation/JustMyCode/jmc-instrument-elf.ll:1
-; REQUIRES: system-windows
-; RUN: opt -jmc-instrument -mtriple=x86_64-pc-windows-msvc  -S < %s | 
FileCheck %s
-; RUN: opt -jmc-instrument -mtriple=aarch64-pc-windows-msvc -S < %s | 
FileCheck %s
-; RUN: opt -jmc-instrument -mtriple=arm-pc-windows-msvc -S < %s | 
FileCheck %s
+; REQUIRES: system-linux
+; RUN: opt -jmc-instrument -mtriple=x86_64-unknown-linux-gnu  -S < %s | 
FileCheck %s

Please remove the REQUIRES line, this test should pass on Windows, and the 
other test should pass on Linux as well. Neither of these tests depend on 
anything from the system.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119910

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


[PATCH] D120989: Support debug info for alias variable

2022-03-04 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a comment.

I think it'd potentially go somewhere in 
`DWARFDebugLine::LineTable::getFileLineInfoForAddress` for instance - which 
could inspect the candidate row in the line table, and if it's line zero, it 
could go back one row in the table. This would avoid probing addresses that are 
defined by the same row and will have the same result. (& could keep going back 
rows until it finds a non-zero row) & document that it's a fuzzy match. Or 
always produce the precise result and a separate non-zero fuzzy result if the 
main result is zero. "Nearest preceeding non-zero" or something.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120989

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


[PATCH] D120992: [analyzer] ReverseNull: New checker to warn for pointer value conditions, if the pointer value is unconditionally non-null

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



Comment at: clang/lib/StaticAnalyzer/Checkers/NullPtrInterferenceChecker.cpp:166
+/// child is a sink node.
+static bool unconditionallyLeadsHere(const ExplodedNode *N) {
+  size_t NonSinkNodeCount = llvm::count_if(

xazax.hun wrote:
> Consider the following code snippet:
> ```
> void f(int *p, bool b)
> {
>   if (b) {
> *p = 4;
>   }
>   if (p) {
>...
>   }
> }
> ```
> 
> I suspect that we would get a warning for the code above. I think warning on 
> the code above might be reasonable (the values of `b` and `p` might be 
> correlated but in some cases the analyzer has no way to know this, probably 
> some assertions could make the code clearer in that case).
> 
> My problem is with the wording of the error message.
> The warning `Pointer is unconditionally non-null here` on the null check is 
> not true for the code above.
Also, if the check would warn for the code snippet above, the note "suggest 
moving the condition here" would also be incorrect.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120992

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


[PATCH] D120931: [clang-format] Fix namespace format when the name is a macro expansion

2022-03-04 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added a comment.

> Its assignment only happens in MacroExpander which is never used

This is something that @klimek was working on.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120931

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


[PATCH] D120931: [clang-format] Fix namespace format when the name is a macro expansion

2022-03-04 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added inline comments.



Comment at: clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp:112
+  EXPECT_EQ("#define M(x) x##x\n"
+"namespace [[deprecated(\"foo\")]] A::inline M(x)::A {\n"
+"int i;\n"

Is this 2 bugs in one? I notice  you also handling attributes? is this a 
different bug? (if so it should really be separate  (but we can let it slide as 
long as the tests are thorough)

can you test:

```
namespace /* comment  */ [[ xxx ]]  /* comment */  A {
int i;
int j;
}  // namespace  A

namespace /* comment  */ [[ xxx ]]   A {
int i;
int j;
}  //  namespace A

namespace /* comment  */ [[ xxx ]]   /* comment */ M(x) {
int i;
int j;
}  // namespace  M(x)

namespace /* comment  */ [[ xxx ]]   /* comment */  A::M(x) {
int i;
int j;
}  // namespace  A::M(x)

namespace /* comment  */ [[ xxx ]]   /* comment */ M(x)  /* comment */ {
int i;
int j;
}  // namespace  M(x)  

namespace /* comment  */ [[ xxx ]]   /* comment */  A::M(x) /* comment */  {
int i;
int j;
}  // namespace  A::M(x)
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120931

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


[PATCH] D120992: [analyzer] ReverseNull: New checker to warn for pointer value conditions, if the pointer value is unconditionally non-null

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



Comment at: clang/lib/StaticAnalyzer/Checkers/NullPtrInterferenceChecker.cpp:166
+/// child is a sink node.
+static bool unconditionallyLeadsHere(const ExplodedNode *N) {
+  size_t NonSinkNodeCount = llvm::count_if(

Consider the following code snippet:
```
void f(int *p, bool b)
{
  if (b) {
*p = 4;
  }
  if (p) {
   ...
  }
}
```

I suspect that we would get a warning for the code above. I think warning on 
the code above might be reasonable (the values of `b` and `p` might be 
correlated but in some cases the analyzer has no way to know this, probably 
some assertions could make the code clearer in that case).

My problem is with the wording of the error message.
The warning `Pointer is unconditionally non-null here` on the null check is not 
true for the code above.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120992

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


[PATCH] D120931: [clang-format] fix namepsace format when the name is macro expansion

2022-03-04 Thread Marek Kurdej via Phabricator via cfe-commits
curdeius added a comment.

Please update the summary, the name is no longer empty. Also, if you can add 
some info in the summary about how it looked before (copying a part of the 
Chromium bug report seems enough), it would be awesome.
Otherwise, some small comments only.




Comment at: clang/lib/Format/NamespaceEndCommentsFixer.cpp:59
+
+// Use the string after `namespace` until `{` or `::` or `(` as an name
+// candicate. If the name is empty, use the candicate.





Comment at: clang/lib/Format/NamespaceEndCommentsFixer.cpp:60
+// Use the string after `namespace` until `{` or `::` or `(` as an name
+// candicate. If the name is empty, use the candicate.
+std::string FirstNSName;





Comment at: clang/lib/Format/NamespaceEndCommentsFixer.cpp:69
+while (Tok && !Tok->is(tok::l_brace) && !Tok->is(tok::coloncolon) &&
+   !Tok->is(tok::l_paren)) {
+  FirstNSName += FirstNSTok->TokenText;

It should be simpler when written as `!Tok->isOneOf(...)`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120931

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


[PATCH] D112774: [RISCV] Support k-ext clang intrinsics

2022-03-04 Thread Craig Topper via Phabricator via cfe-commits
craig.topper accepted this revision.
craig.topper added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112774

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


[PATCH] D120449: [RISCV][RVV] Add strict vfcvt intrinsics that have side effects for dynamically-set rounding mode

2022-03-04 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added inline comments.



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoVVLPatterns.td:624
+  (mask_type true_mask),
+  VLOpFrag, (XLenVT undef))),
+(!cast(inst#"_"#kind#"_"#vlmul.MX)

I don't like using Undef for a field that should be a constant. Can we use 0?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120449

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


[PATCH] D119184: [clang] [concepts] Check constrained-auto return types for void-returning functions

2022-03-04 Thread Arthur O'Dwyer via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGf0891cd61b2f: [clang] [concepts] Check constrained-auto 
return types for void-returning… (authored by arthur.j.odwyer).

Changed prior to commit:
  https://reviews.llvm.org/D119184?vs=413006=413046#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119184

Files:
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/test/SemaTemplate/concepts.cpp

Index: clang/test/SemaTemplate/concepts.cpp
===
--- clang/test/SemaTemplate/concepts.cpp
+++ clang/test/SemaTemplate/concepts.cpp
@@ -169,3 +169,42 @@
   template void f(T, U) = delete;
   void g() { f(0, 0); }
 }
+
+namespace PR49188 {
+  template concept C = false; // expected-note 6 {{because 'false' evaluated to false}}
+
+  C auto f1() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+return void();
+  }
+  C auto f2() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+return;
+  }
+  C auto f3() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+  }
+  C decltype(auto) f4() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+return void();
+  }
+  C decltype(auto) f5() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+return;
+  }
+  C decltype(auto) f6() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+  }
+  C auto& f7() { // expected-error {{cannot form a reference to 'void'}}
+return void();
+  }
+  C auto& f8() {
+return; // expected-error {{cannot deduce return type 'C auto &' from omitted return expression}}
+  }
+  C auto& f9() { // expected-error {{cannot deduce return type 'C auto &' for function with no return statements}}
+  }
+}
+namespace PR53911 {
+  template concept C = false;
+
+  C auto *f1() {
+return (void*)nullptr; // FIXME: should error
+  }
+  C auto *f2() {
+return (int*)nullptr; // FIXME: should error
+  }
+}
Index: clang/lib/Sema/SemaStmt.cpp
===
--- clang/lib/Sema/SemaStmt.cpp
+++ clang/lib/Sema/SemaStmt.cpp
@@ -3808,19 +3808,26 @@
 LocalTypedefNameReferencer Referencer(*this);
 Referencer.TraverseType(RetExpr->getType());
   } else {
-//  In the case of a return with no operand, the initializer is considered
-//  to be void().
-//
-// Deduction here can only succeed if the return type is exactly 'cv auto'
-// or 'decltype(auto)', so just check for that case directly.
+// For a function with a deduced result type to return void,
+// the result type as written must be 'auto' or 'decltype(auto)',
+// possibly cv-qualified or constrained, but not ref-qualified.
 if (!OrigResultType.getType()->getAs()) {
   Diag(ReturnLoc, diag::err_auto_fn_return_void_but_not_auto)
 << OrigResultType.getType();
   return true;
 }
-// We always deduce U = void in this case.
-Deduced = SubstAutoType(OrigResultType.getType(), Context.VoidTy);
-if (Deduced.isNull())
+// In the case of a return with no operand, the initializer is considered
+// to be 'void()'.
+Expr *Dummy = new (Context) CXXScalarValueInitExpr(
+Context.VoidTy,
+Context.getTrivialTypeSourceInfo(Context.VoidTy, ReturnLoc), ReturnLoc);
+DeduceAutoResult DAR = DeduceAutoType(OrigResultType, Dummy, Deduced);
+
+if (DAR == DAR_Failed && !FD->isInvalidDecl())
+  Diag(ReturnLoc, diag::err_auto_fn_deduction_failure)
+  << OrigResultType.getType() << Dummy->getType();
+
+if (DAR != DAR_Succeeded)
   return true;
   }
 
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -14674,18 +14674,20 @@
   if (getLangOpts().CPlusPlus14) {
 if (!FD->isInvalidDecl() && Body && !FD->isDependentContext() &&
 FD->getReturnType()->isUndeducedType()) {
-  // If the function has a deduced result type but contains no 'return'
-  // statements, the result type as written must be exactly 'auto', and
-  // the deduced result type is 'void'.
+  // For a function with a deduced result type to return void,
+  // the result type as written must be 'auto' or 'decltype(auto)',
+  // possibly cv-qualified or constrained, but not ref-qualified.
   if (!FD->getReturnType()->getAs()) {
 Diag(dcl->getLocation(), diag::err_auto_fn_no_return_but_not_auto)
 << FD->getReturnType();
 FD->setInvalidDecl();
   } else {
-// Substitute 'void' for the 'auto' in the type.
-TypeLoc ResultType = getReturnTypeLoc(FD);
-Context.adjustDeducedFunctionResultType(
-FD, 

[clang] f0891cd - [clang] [concepts] Check constrained-auto return types for void-returning functions

2022-03-04 Thread Arthur O'Dwyer via cfe-commits

Author: Arthur O'Dwyer
Date: 2022-03-04T12:43:06-05:00
New Revision: f0891cd61b2f7cd57d906406ae785722bfd87603

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

LOG: [clang] [concepts] Check constrained-auto return types for void-returning 
functions

Fixes #49188.

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

Added: 


Modified: 
clang/lib/Sema/SemaDecl.cpp
clang/lib/Sema/SemaStmt.cpp
clang/test/SemaTemplate/concepts.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index 7d9d5ec87948e..b88d9f2f847fd 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -14674,18 +14674,20 @@ Decl *Sema::ActOnFinishFunctionBody(Decl *dcl, Stmt 
*Body,
   if (getLangOpts().CPlusPlus14) {
 if (!FD->isInvalidDecl() && Body && !FD->isDependentContext() &&
 FD->getReturnType()->isUndeducedType()) {
-  // If the function has a deduced result type but contains no 'return'
-  // statements, the result type as written must be exactly 'auto', and
-  // the deduced result type is 'void'.
+  // For a function with a deduced result type to return void,
+  // the result type as written must be 'auto' or 'decltype(auto)',
+  // possibly cv-qualified or constrained, but not ref-qualified.
   if (!FD->getReturnType()->getAs()) {
 Diag(dcl->getLocation(), diag::err_auto_fn_no_return_but_not_auto)
 << FD->getReturnType();
 FD->setInvalidDecl();
   } else {
-// Substitute 'void' for the 'auto' in the type.
-TypeLoc ResultType = getReturnTypeLoc(FD);
-Context.adjustDeducedFunctionResultType(
-FD, SubstAutoType(ResultType.getType(), Context.VoidTy));
+// Falling off the end of the function is the same as 'return;'.
+Expr *Dummy = nullptr;
+if (DeduceFunctionTypeFromReturnExpr(
+FD, dcl->getLocation(), Dummy,
+FD->getReturnType()->getAs()))
+  FD->setInvalidDecl();
   }
 }
   } else if (getLangOpts().CPlusPlus11 && isLambdaCallOperator(FD)) {

diff  --git a/clang/lib/Sema/SemaStmt.cpp b/clang/lib/Sema/SemaStmt.cpp
index d51a71ffc7f41..e23fd23019998 100644
--- a/clang/lib/Sema/SemaStmt.cpp
+++ b/clang/lib/Sema/SemaStmt.cpp
@@ -3808,19 +3808,26 @@ bool 
Sema::DeduceFunctionTypeFromReturnExpr(FunctionDecl *FD,
 LocalTypedefNameReferencer Referencer(*this);
 Referencer.TraverseType(RetExpr->getType());
   } else {
-//  In the case of a return with no operand, the initializer is considered
-//  to be void().
-//
-// Deduction here can only succeed if the return type is exactly 'cv auto'
-// or 'decltype(auto)', so just check for that case directly.
+// For a function with a deduced result type to return void,
+// the result type as written must be 'auto' or 'decltype(auto)',
+// possibly cv-qualified or constrained, but not ref-qualified.
 if (!OrigResultType.getType()->getAs()) {
   Diag(ReturnLoc, diag::err_auto_fn_return_void_but_not_auto)
 << OrigResultType.getType();
   return true;
 }
-// We always deduce U = void in this case.
-Deduced = SubstAutoType(OrigResultType.getType(), Context.VoidTy);
-if (Deduced.isNull())
+// In the case of a return with no operand, the initializer is considered
+// to be 'void()'.
+Expr *Dummy = new (Context) CXXScalarValueInitExpr(
+Context.VoidTy,
+Context.getTrivialTypeSourceInfo(Context.VoidTy, ReturnLoc), 
ReturnLoc);
+DeduceAutoResult DAR = DeduceAutoType(OrigResultType, Dummy, Deduced);
+
+if (DAR == DAR_Failed && !FD->isInvalidDecl())
+  Diag(ReturnLoc, diag::err_auto_fn_deduction_failure)
+  << OrigResultType.getType() << Dummy->getType();
+
+if (DAR != DAR_Succeeded)
   return true;
   }
 

diff  --git a/clang/test/SemaTemplate/concepts.cpp 
b/clang/test/SemaTemplate/concepts.cpp
index c297a75dd82e6..20af504883566 100644
--- a/clang/test/SemaTemplate/concepts.cpp
+++ b/clang/test/SemaTemplate/concepts.cpp
@@ -169,3 +169,42 @@ namespace PR50561 {
   template void f(T, U) = delete;
   void g() { f(0, 0); }
 }
+
+namespace PR49188 {
+  template concept C = false; // expected-note 6 {{because 
'false' evaluated to false}}
+
+  C auto f1() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+return void();
+  }
+  C auto f2() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+return;
+  }
+  C auto f3() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+  }
+  C decltype(auto) f4() { // expected-error {{deduced type 'void' does not 

[clang] adf6703 - [clang] [NFC] Add `const` to a parameter that's not modified.

2022-03-04 Thread Arthur O'Dwyer via cfe-commits

Author: Arthur O'Dwyer
Date: 2022-03-04T12:43:05-05:00
New Revision: adf6703f75b09564ca887b0eea0c3b37e65237d7

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

LOG: [clang] [NFC] Add `const` to a parameter that's not modified.

Reviewed as part of D119184.

Added: 


Modified: 
clang/include/clang/Sema/Sema.h
clang/lib/Sema/SemaStmt.cpp

Removed: 




diff  --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 9496d72cadcab..d072cf9223f7d 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -8701,7 +8701,7 @@ class Sema final {
 
   bool DeduceFunctionTypeFromReturnExpr(FunctionDecl *FD,
 SourceLocation ReturnLoc,
-Expr *, AutoType *AT);
+Expr *, const AutoType *AT);
 
   FunctionTemplateDecl *getMoreSpecializedTemplate(
   FunctionTemplateDecl *FT1, FunctionTemplateDecl *FT2, SourceLocation Loc,

diff  --git a/clang/lib/Sema/SemaStmt.cpp b/clang/lib/Sema/SemaStmt.cpp
index 6ccef38c2f61d..d51a71ffc7f41 100644
--- a/clang/lib/Sema/SemaStmt.cpp
+++ b/clang/lib/Sema/SemaStmt.cpp
@@ -3762,8 +3762,8 @@ TypeLoc Sema::getReturnTypeLoc(FunctionDecl *FD) const {
 bool Sema::DeduceFunctionTypeFromReturnExpr(FunctionDecl *FD,
 SourceLocation ReturnLoc,
 Expr *,
-AutoType *AT) {
-  // If this is the conversion function for a lambda, we choose to deduce it
+const AutoType *AT) {
+  // If this is the conversion function for a lambda, we choose to deduce its
   // type from the corresponding call operator, not from the synthesized return
   // statement within it. See Sema::DeduceReturnType.
   if (isLambdaConversionOperator(FD))



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


[PATCH] D103313: [RISCV][Clang] Implement support for zmmul-experimental

2022-03-04 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added a comment.

In D103313#3359628 , @ksyx wrote:

> In D103313#3359310 , 
> @JiahaoChenConor wrote:
>
>> Hi, do you still continue working on this patch?
>
> In fact, not pretty sure what else I need to improve on this.

At minimum it probably needs to rebased because RISCVISAInfo.cpp has been added 
to cut down on some duplication.


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

https://reviews.llvm.org/D103313

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


[PATCH] D114231: [clang][docs][dataflow] Added an introduction to dataflow analysis

2022-03-04 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added a comment.
Herald added a project: All.

Did you add somewhere what dependency we need in order to build the 
documentation now as mine is having problems with "recommonmark"

  /usr/bin/sphinx-build -n ./docs ./html
  Running Sphinx v3.4.3
  
  Configuration error:
  There is a programmable error in your configuration file:
  
  Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/sphinx/config.py", line 326, in 
eval_config_file
  execfile_(filename, namespace)
File "/usr/lib/python3.6/site-packages/sphinx/util/pycompat.py", line 88, 
in execfile_
  exec(code, _globals)
File "/buildareas/llvm3/llvm-project/clang/docs/conf.py", line 41, in 

  import recommonmark
  ModuleNotFoundError: No module named 'recommonmark'


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114231

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


[PATCH] D112181: [docs] Remove hard-coded version numbers from sphinx configs

2022-03-04 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added a comment.
Herald added a project: All.

Can we drop the git from everywhere?

F22325692: image.png 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112181

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


[PATCH] D120900: [clang][dataflow] Add `MatchSwitch` utility library.

2022-03-04 Thread Yitzhak Mandelbaum 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 rGc88deef0a721: [clang][dataflow] Add `MatchSwitch` utility 
library. (authored by ymandel).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120900

Files:
  clang/include/clang/Analysis/FlowSensitive/MatchSwitch.h
  clang/unittests/Analysis/FlowSensitive/CMakeLists.txt
  clang/unittests/Analysis/FlowSensitive/MatchSwitchTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/MatchSwitchTest.cpp
===
--- /dev/null
+++ clang/unittests/Analysis/FlowSensitive/MatchSwitchTest.cpp
@@ -0,0 +1,204 @@
+//===- unittests/Analysis/FlowSensitive/MatchSwitchTest.cpp ---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+//  This file defines a simplistic version of Constant Propagation as an example
+//  of a forward, monotonic dataflow analysis. The analysis tracks all
+//  variables in the scope, but lacks escape analysis.
+//
+//===--===//
+
+#include "clang/Analysis/FlowSensitive/MatchSwitch.h"
+#include "TestingSupport.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/Decl.h"
+#include "clang/AST/Expr.h"
+#include "clang/AST/Stmt.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/Analysis/FlowSensitive/DataflowAnalysis.h"
+#include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
+#include "clang/Analysis/FlowSensitive/DataflowLattice.h"
+#include "clang/Analysis/FlowSensitive/MapLattice.h"
+#include "clang/Tooling/Tooling.h"
+#include "llvm/ADT/None.h"
+#include "llvm/ADT/Optional.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/ADT/Twine.h"
+#include "llvm/Support/Error.h"
+#include "llvm/Testing/Support/Annotations.h"
+#include "llvm/Testing/Support/Error.h"
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+
+using namespace clang;
+using namespace dataflow;
+
+namespace {
+using ::testing::Pair;
+using ::testing::UnorderedElementsAre;
+
+class BooleanLattice {
+public:
+  BooleanLattice() : Value(false) {}
+  explicit BooleanLattice(bool B) : Value(B) {}
+
+  static BooleanLattice bottom() { return BooleanLattice(false); }
+
+  static BooleanLattice top() { return BooleanLattice(true); }
+
+  LatticeJoinEffect join(BooleanLattice Other) {
+auto Prev = Value;
+Value = Value || Other.Value;
+return Prev == Value ? LatticeJoinEffect::Unchanged
+ : LatticeJoinEffect::Changed;
+  }
+
+  friend bool operator==(BooleanLattice LHS, BooleanLattice RHS) {
+return LHS.Value == RHS.Value;
+  }
+
+  friend std::ostream <<(std::ostream , const BooleanLattice ) {
+Os << B.Value;
+return Os;
+  }
+
+  bool value() const { return Value; }
+
+private:
+  bool Value;
+};
+} // namespace
+
+MATCHER_P(Holds, m,
+  ((negation ? "doesn't hold" : "holds") +
+   llvm::StringRef(" a lattice element that ") +
+   ::testing::DescribeMatcher(m, negation))
+  .str()) {
+  return ExplainMatchResult(m, arg.Lattice, result_listener);
+}
+
+void TransferSetTrue(const DeclRefExpr *,
+ TransferState ) {
+  State.Lattice = BooleanLattice(true);
+}
+
+void TransferSetFalse(const Stmt *,
+  const ast_matchers::MatchFinder::MatchResult &,
+  TransferState ) {
+  State.Lattice = BooleanLattice(false);
+}
+
+class TestAnalysis : public DataflowAnalysis {
+  MatchSwitch> TransferSwitch;
+
+public:
+  explicit TestAnalysis(ASTContext )
+  : DataflowAnalysis(Context) {
+using namespace ast_matchers;
+TransferSwitch =
+MatchSwitchBuilder>()
+.CaseOf(declRefExpr(to(varDecl(hasName("X", TransferSetTrue)
+.CaseOf(callExpr(callee(functionDecl(hasName("Foo",
+TransferSetFalse)
+.Build();
+  }
+
+  static BooleanLattice initialElement() { return BooleanLattice::bottom(); }
+
+  void transfer(const Stmt *S, BooleanLattice , Environment ) {
+TransferState State(L, Env);
+TransferSwitch(*S, getASTContext(), State);
+  }
+};
+
+class MatchSwitchTest : public ::testing::Test {
+protected:
+  template 
+  void RunDataflow(llvm::StringRef Code, Matcher Expectations) {
+ASSERT_THAT_ERROR(
+test::checkDataflow(
+Code, "fun",
+[](ASTContext , Environment &) { return TestAnalysis(C); },
+[](
+llvm::ArrayRef>>
+

[clang] c88deef - [clang][dataflow] Add `MatchSwitch` utility library.

2022-03-04 Thread Yitzhak Mandelbaum via cfe-commits

Author: Yitzhak Mandelbaum
Date: 2022-03-04T17:19:51Z
New Revision: c88deef0a7218dd5c30500e7d3f58fc23283d3e5

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

LOG: [clang][dataflow] Add `MatchSwitch` utility library.

Adds `MatchSwitch`, a library for simplifying implementation of transfer
functions. `MatchSwitch` supports constructing a "switch" statement, where each
case of the switch is defined by an AST matcher. The cases are considered in
order, like pattern matching in functional languages.

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

Added: 
clang/include/clang/Analysis/FlowSensitive/MatchSwitch.h
clang/unittests/Analysis/FlowSensitive/MatchSwitchTest.cpp

Modified: 
clang/unittests/Analysis/FlowSensitive/CMakeLists.txt

Removed: 




diff  --git a/clang/include/clang/Analysis/FlowSensitive/MatchSwitch.h 
b/clang/include/clang/Analysis/FlowSensitive/MatchSwitch.h
new file mode 100644
index 0..b319360627911
--- /dev/null
+++ b/clang/include/clang/Analysis/FlowSensitive/MatchSwitch.h
@@ -0,0 +1,153 @@
+//=== MatchSwitch.h -*- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+//  This file defines the `MatchSwitch` abstraction for building a "switch"
+//  statement, where each case of the switch is defined by an AST matcher. The
+//  cases are considered in order, like pattern matching in functional
+//  languages.
+//
+//  Currently, the design is catered towards simplifying the implementation of
+//  `DataflowAnalysis` transfer functions. Based on experience here, this
+//  library may be generalized and moved to ASTMatchers.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_MATCHSWITCH_H_
+#define LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_MATCHSWITCH_H_
+
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/Stmt.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/Analysis/FlowSensitive/DataflowEnvironment.h"
+#include "llvm/ADT/StringRef.h"
+#include 
+#include 
+#include 
+#include 
+
+namespace clang {
+namespace dataflow {
+
+/// A common form of state shared between the cases of a transfer function.
+template  struct TransferState {
+  TransferState(LatticeT , Environment )
+  : Lattice(Lattice), Env(Env) {}
+
+  /// Current lattice element.
+  LatticeT 
+  Environment 
+};
+
+/// Matches against `Stmt` and, based on its structure, dispatches to an
+/// appropriate handler.
+template 
+using MatchSwitch = std::function;
+
+/// Collects cases of a "match switch": a collection of matchers paired with
+/// callbacks, which together define a switch that can be applied to a
+/// `Stmt`. This structure can simplify the definition of `transfer` functions
+/// that rely on pattern-matching.
+///
+/// For example, consider an analysis that handles particular function calls. 
It
+/// can define the `MatchSwitch` once, in the constructor of the analysis, and
+/// then reuse it each time that `transfer` is called, with a fresh state 
value.
+///
+/// \code
+/// MatchSwitch BuildSwitch() {
+///   return MatchSwitchBuilder>()
+/// .CaseOf(callExpr(callee(functionDecl(hasName("foo", 
TransferFooCall)
+/// .CaseOf(callExpr(argumentCountIs(2),
+///  callee(functionDecl(hasName("bar",
+/// TransferBarCall)
+/// .Build();
+/// }
+/// \endcode
+template  class MatchSwitchBuilder {
+public:
+  // An action is triggered by the match of a pattern against the input
+  // statement. For generality, actions take both the matched statement and the
+  // set of bindings produced by the match.
+  using Action = std::function;
+
+  MatchSwitchBuilder &(ast_matchers::internal::Matcher M,
+  Action A) && {
+Matchers.push_back(std::move(M));
+Actions.push_back(std::move(A));
+return std::move(*this);
+  }
+
+  // Convenience function for the common case, where bound nodes are not
+  // needed. `Node` should be a subclass of `Stmt`.
+  template 
+  MatchSwitchBuilder &(ast_matchers::internal::Matcher M,
+  void (*Action)(const Node *, State &)) && {
+Matchers.push_back(std::move(M));
+Actions.push_back([Action](const Stmt *Stmt,
+   const ast_matchers::MatchFinder::MatchResult &,
+   State ) { Action(cast(Stmt), S); });
+return std::move(*this);
+  

[PATCH] D120967: [NFC] Divide tests into smaller files

2022-03-04 Thread Jessica Clarke via Phabricator via cfe-commits
jrtc27 added a comment.

With one exception, every RISC-V Clang CodeGen test (and with 9 exceptions, 
every RISC-V LLVM CodeGen test) is kebab-case not snake_case


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120967

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


[PATCH] D120890: [clang][dataflow] Add a lattice to track source locations.

2022-03-04 Thread Yitzhak Mandelbaum 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 rG7ee97c24efab: [clang][dataflow] Add a lattice to track 
source locations. (authored by ymandel).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120890

Files:
  clang/include/clang/Analysis/FlowSensitive/SourceLocationsLattice.h
  clang/lib/Analysis/FlowSensitive/CMakeLists.txt
  clang/lib/Analysis/FlowSensitive/SourceLocationsLattice.cpp
  clang/unittests/Analysis/FlowSensitive/CMakeLists.txt
  clang/unittests/Analysis/FlowSensitive/SourceLocationsLatticeTest.cpp

Index: clang/unittests/Analysis/FlowSensitive/SourceLocationsLatticeTest.cpp
===
--- /dev/null
+++ clang/unittests/Analysis/FlowSensitive/SourceLocationsLatticeTest.cpp
@@ -0,0 +1,68 @@
+//===- unittests/Analysis/FlowSensitive/SourceLocationsLatticeTest.cpp ===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang/Analysis/FlowSensitive/SourceLocationsLattice.h"
+
+#include "clang/Analysis/FlowSensitive/DataflowLattice.h"
+#include "clang/Basic/SourceLocation.h"
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+
+namespace clang {
+namespace dataflow {
+namespace {
+
+TEST(SourceLocationsLatticeTest, Comparison) {
+  const SourceLocationsLattice Bottom;
+  const SourceLocationsLattice NonBottom(
+  {SourceLocation::getFromRawEncoding(0)});
+
+  EXPECT_TRUE(Bottom == Bottom);
+  EXPECT_FALSE(Bottom == NonBottom);
+  EXPECT_FALSE(NonBottom == Bottom);
+  EXPECT_TRUE(NonBottom == NonBottom);
+
+  EXPECT_FALSE(Bottom != Bottom);
+  EXPECT_TRUE(Bottom != NonBottom);
+  EXPECT_TRUE(NonBottom != Bottom);
+  EXPECT_FALSE(NonBottom != NonBottom);
+}
+
+TEST(SourceLocationsLatticeTest, Join) {
+  const SourceLocationsLattice Bottom;
+  const SourceLocationsLattice NonBottom(
+  {SourceLocation::getFromRawEncoding(0)});
+  {
+SourceLocationsLattice LHS = Bottom;
+const SourceLocationsLattice RHS = Bottom;
+EXPECT_EQ(LHS.join(RHS), LatticeJoinEffect::Unchanged);
+EXPECT_EQ(LHS, Bottom);
+  }
+  {
+SourceLocationsLattice LHS = NonBottom;
+const SourceLocationsLattice RHS = Bottom;
+EXPECT_EQ(LHS.join(RHS), LatticeJoinEffect::Unchanged);
+EXPECT_EQ(LHS, NonBottom);
+  }
+  {
+SourceLocationsLattice LHS = Bottom;
+const SourceLocationsLattice RHS = NonBottom;
+EXPECT_EQ(LHS.join(RHS), LatticeJoinEffect::Changed);
+EXPECT_EQ(LHS, NonBottom);
+  }
+  {
+SourceLocationsLattice LHS = NonBottom;
+const SourceLocationsLattice RHS = NonBottom;
+EXPECT_EQ(LHS.join(RHS), LatticeJoinEffect::Unchanged);
+EXPECT_EQ(LHS, NonBottom);
+  }
+}
+
+} // namespace
+} // namespace dataflow
+} // namespace clang
Index: clang/unittests/Analysis/FlowSensitive/CMakeLists.txt
===
--- clang/unittests/Analysis/FlowSensitive/CMakeLists.txt
+++ clang/unittests/Analysis/FlowSensitive/CMakeLists.txt
@@ -9,6 +9,7 @@
   MapLatticeTest.cpp
   MultiVarConstantPropagationTest.cpp
   SingleVarConstantPropagationTest.cpp
+  SourceLocationsLatticeTest.cpp
   TestingSupport.cpp
   TestingSupportTest.cpp
   TransferTest.cpp
Index: clang/lib/Analysis/FlowSensitive/SourceLocationsLattice.cpp
===
--- /dev/null
+++ clang/lib/Analysis/FlowSensitive/SourceLocationsLattice.cpp
@@ -0,0 +1,51 @@
+//===- SourceLocationsLattice.cpp -===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+//  This file implements a lattice that collects source locations of interest.
+//
+//===--===//
+
+#include "clang/Analysis/FlowSensitive/SourceLocationsLattice.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/Analysis/FlowSensitive/DataflowLattice.h"
+#include "llvm/ADT/STLExtras.h"
+#include "llvm/Support/raw_ostream.h"
+#include 
+#include 
+#include 
+
+namespace clang {
+namespace dataflow {
+
+LatticeJoinEffect
+SourceLocationsLattice::join(const SourceLocationsLattice ) {
+  auto SizeBefore = Locs.size();
+  Locs.insert(Other.Locs.begin(), Other.Locs.end());
+  return SizeBefore == Locs.size() ? LatticeJoinEffect::Unchanged
+   : LatticeJoinEffect::Changed;
+}
+
+std::string 

[clang] 7ee97c2 - [clang][dataflow] Add a lattice to track source locations.

2022-03-04 Thread Yitzhak Mandelbaum via cfe-commits

Author: Yitzhak Mandelbaum
Date: 2022-03-04T17:13:24Z
New Revision: 7ee97c24efab4b2617da7f188760b0ad2dcc2125

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

LOG: [clang][dataflow] Add a lattice to track source locations.

This patch adds a simpe lattice used to collect source loctions. An intended 
application is to track errors found in code during an analysis.

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

Added: 
clang/include/clang/Analysis/FlowSensitive/SourceLocationsLattice.h
clang/lib/Analysis/FlowSensitive/SourceLocationsLattice.cpp
clang/unittests/Analysis/FlowSensitive/SourceLocationsLatticeTest.cpp

Modified: 
clang/lib/Analysis/FlowSensitive/CMakeLists.txt
clang/unittests/Analysis/FlowSensitive/CMakeLists.txt

Removed: 




diff  --git 
a/clang/include/clang/Analysis/FlowSensitive/SourceLocationsLattice.h 
b/clang/include/clang/Analysis/FlowSensitive/SourceLocationsLattice.h
new file mode 100644
index 0..d294f9768cdc5
--- /dev/null
+++ b/clang/include/clang/Analysis/FlowSensitive/SourceLocationsLattice.h
@@ -0,0 +1,65 @@
+//===-- SourceLocationsLattice.h *- C++ 
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+//  This file defines a lattice that collects source locations of interest.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_SOURCELOCATIONS_LATTICE_H
+#define LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_SOURCELOCATIONS_LATTICE_H
+
+#include "clang/AST/ASTContext.h"
+#include "clang/Analysis/FlowSensitive/DataflowLattice.h"
+#include "clang/Basic/SourceLocation.h"
+#include "llvm/ADT/DenseSet.h"
+#include 
+#include 
+
+namespace clang {
+namespace dataflow {
+
+/// Lattice for dataflow analysis that keeps track of a set of source 
locations.
+///
+/// Bottom is the empty set, join is set union, and equality is set equality.
+///
+/// FIXME: Generalize into a (templated) PowerSetLattice.
+class SourceLocationsLattice {
+public:
+  SourceLocationsLattice() = default;
+
+  explicit SourceLocationsLattice(llvm::DenseSet Locs)
+  : Locs(std::move(Locs)) {}
+
+  bool operator==(const SourceLocationsLattice ) const {
+return Locs == Other.Locs;
+  }
+
+  bool operator!=(const SourceLocationsLattice ) const {
+return !(*this == Other);
+  }
+
+  LatticeJoinEffect join(const SourceLocationsLattice );
+
+  llvm::DenseSet () { return Locs; }
+
+  const llvm::DenseSet () const {
+return Locs;
+  }
+
+private:
+  llvm::DenseSet Locs;
+};
+
+/// Returns a string that represents the source locations of the lattice.
+std::string DebugString(const SourceLocationsLattice ,
+const ASTContext );
+
+} // namespace dataflow
+} // namespace clang
+
+#endif // LLVM_CLANG_ANALYSIS_FLOWSENSITIVE_SOURCELOCATIONS_LATTICE_H

diff  --git a/clang/lib/Analysis/FlowSensitive/CMakeLists.txt 
b/clang/lib/Analysis/FlowSensitive/CMakeLists.txt
index 933792d569799..cfe3c8e77b4fd 100644
--- a/clang/lib/Analysis/FlowSensitive/CMakeLists.txt
+++ b/clang/lib/Analysis/FlowSensitive/CMakeLists.txt
@@ -2,6 +2,7 @@ add_clang_library(clangAnalysisFlowSensitive
   ControlFlowContext.cpp
   DataflowAnalysisContext.cpp
   DataflowEnvironment.cpp
+  SourceLocationsLattice.cpp
   Transfer.cpp
   TypeErasedDataflowAnalysis.cpp
   WatchedLiteralsSolver.cpp
@@ -9,4 +10,5 @@ add_clang_library(clangAnalysisFlowSensitive
   LINK_LIBS
   clangAnalysis
   clangAST
+  clangBasic
   )

diff  --git a/clang/lib/Analysis/FlowSensitive/SourceLocationsLattice.cpp 
b/clang/lib/Analysis/FlowSensitive/SourceLocationsLattice.cpp
new file mode 100644
index 0..9e280f4e634a1
--- /dev/null
+++ b/clang/lib/Analysis/FlowSensitive/SourceLocationsLattice.cpp
@@ -0,0 +1,51 @@
+//===- SourceLocationsLattice.cpp 
-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+//  This file implements a lattice that collects source locations of interest.
+//
+//===--===//
+
+#include "clang/Analysis/FlowSensitive/SourceLocationsLattice.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/Analysis/FlowSensitive/DataflowLattice.h"
+#include 

[PATCH] D120449: [RISCV][RVV] Add strict vfcvt intrinsics that have side effects for dynamically-set rounding mode

2022-03-04 Thread Zakk Chen via Phabricator via cfe-commits
khchen added a comment.

Makes sense to me, but I'd appreciate someone else for a final LGTM.




Comment at: llvm/lib/Target/RISCV/RISCVISelLowering.cpp:4683
+Ops.push_back(VL);
+Ops.push_back(DAG.getUNDEF(XLenVT)); // Policy
+  }

arcbbb wrote:
> kito-cheng wrote:
> > Is this operand for tail policy? if so why this is `UNDEF`? I guess this 
> > should be `TAIL_AGNOSTIC` rather than `UNDEF`?
> Because unmasked pseudos doesn't have a policy operand,
> TA/TU is distinguished by checking if passthru is undef. I think it is proper 
> to leave undef here.
nit: maybe we could add a comment for that, because it must be `UNDEF` to match 
unmaksed pattern successfully.



Comment at: llvm/lib/Target/RISCV/RISCVISelLowering.cpp:4678
+MVT MaskVT = MVT::getVectorVT(MVT::i1, VT.getVectorElementCount());
+SDValue Mask = DAG.getNode(RISCVISD::VMSET_VL, DL, MaskVT, VL);
+Ops.push_back(Mask);

I think `TrueMask` maybe better.



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoVVLPatterns.td:619
+  VReg result_reg_class,
+  VReg op2_reg_class
+  > {

--> `VReg op2_reg_class> {`



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoVVLPatterns.td:649
+defvar ivti = GetIntVTypeInfo.Vti;
+
+defm : VPatConvertStrictSDNode_VLhttps://reviews.llvm.org/D120449/new/

https://reviews.llvm.org/D120449

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


[clang-tools-extra] e86324f - [clang-tidy][NFC] Document bugprone-narrowing-conversions check alias

2022-03-04 Thread Balazs Benics via cfe-commits

Author: Balazs Benics
Date: 2022-03-04T16:47:11+01:00
New Revision: e86324f80031fb5596f9f7437cb8c0b24fcf3143

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

LOG: [clang-tidy][NFC] Document bugprone-narrowing-conversions check alias

Added: 
clang-tools-extra/docs/clang-tidy/checks/bugprone-narrowing-conversions.rst

Modified: 
clang-tools-extra/docs/clang-tidy/checks/list.rst

Removed: 




diff  --git 
a/clang-tools-extra/docs/clang-tidy/checks/bugprone-narrowing-conversions.rst 
b/clang-tools-extra/docs/clang-tidy/checks/bugprone-narrowing-conversions.rst
new file mode 100644
index 0..85867273aaa6a
--- /dev/null
+++ 
b/clang-tools-extra/docs/clang-tidy/checks/bugprone-narrowing-conversions.rst
@@ -0,0 +1,10 @@
+.. title:: clang-tidy - bugprone-narrowing-conversions
+.. meta::
+   :http-equiv=refresh: 5;URL=cppcoreguidelines-narrowing-conversions.html
+
+bugprone-narrowing-conversions
+==
+
+The bugprone-narrowing-conversions check is an alias, please see
+`cppcoreguidelines-narrowing-conversions 
`_
+for more information.

diff  --git a/clang-tools-extra/docs/clang-tidy/checks/list.rst 
b/clang-tools-extra/docs/clang-tidy/checks/list.rst
index a67de1c4788f9..f2b361e2aecbc 100644
--- a/clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ b/clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -336,6 +336,7 @@ Clang-Tidy Checks
 .. csv-table:: Aliases..
:header: "Name", "Redirect", "Offers fixes"
 
+   `bugprone-narrowing-conversions `_, 
`cppcoreguidelines-narrowing-conversions 
`_,
`cert-con36-c `_, `bugprone-spuriously-wake-up-functions 
`_,
`cert-con54-cpp `_, 
`bugprone-spuriously-wake-up-functions 
`_,
`cert-dcl03-c `_, `misc-static-assert 
`_, "Yes"



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


[PATCH] D119184: [clang] [concepts] Check constrained-auto return types for void-returning functions

2022-03-04 Thread Arthur O'Dwyer via Phabricator via cfe-commits
Quuxplusone updated this revision to Diff 413006.
Quuxplusone added a comment.
Herald added a project: All.

Rebased, poke CI one last time.
If this is green, imma land it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119184

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/test/SemaTemplate/concepts.cpp

Index: clang/test/SemaTemplate/concepts.cpp
===
--- clang/test/SemaTemplate/concepts.cpp
+++ clang/test/SemaTemplate/concepts.cpp
@@ -169,3 +169,42 @@
   template void f(T, U) = delete;
   void g() { f(0, 0); }
 }
+
+namespace PR49188 {
+  template concept C = false; // expected-note 6 {{because 'false' evaluated to false}}
+
+  C auto f1() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+return void();
+  }
+  C auto f2() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+return;
+  }
+  C auto f3() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+  }
+  C decltype(auto) f4() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+return void();
+  }
+  C decltype(auto) f5() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+return;
+  }
+  C decltype(auto) f6() { // expected-error {{deduced type 'void' does not satisfy 'C'}}
+  }
+  C auto& f7() { // expected-error {{cannot form a reference to 'void'}}
+return void();
+  }
+  C auto& f8() {
+return; // expected-error {{cannot deduce return type 'C auto &' from omitted return expression}}
+  }
+  C auto& f9() { // expected-error {{cannot deduce return type 'C auto &' for function with no return statements}}
+  }
+}
+namespace PR53911 {
+  template concept C = false;
+
+  C auto *f1() {
+return (void*)nullptr; // FIXME: should error
+  }
+  C auto *f2() {
+return (int*)nullptr; // FIXME: should error
+  }
+}
Index: clang/lib/Sema/SemaStmt.cpp
===
--- clang/lib/Sema/SemaStmt.cpp
+++ clang/lib/Sema/SemaStmt.cpp
@@ -3762,8 +3762,8 @@
 bool Sema::DeduceFunctionTypeFromReturnExpr(FunctionDecl *FD,
 SourceLocation ReturnLoc,
 Expr *,
-AutoType *AT) {
-  // If this is the conversion function for a lambda, we choose to deduce it
+const AutoType *AT) {
+  // If this is the conversion function for a lambda, we choose to deduce its
   // type from the corresponding call operator, not from the synthesized return
   // statement within it. See Sema::DeduceReturnType.
   if (isLambdaConversionOperator(FD))
@@ -3808,19 +3808,26 @@
 LocalTypedefNameReferencer Referencer(*this);
 Referencer.TraverseType(RetExpr->getType());
   } else {
-//  In the case of a return with no operand, the initializer is considered
-//  to be void().
-//
-// Deduction here can only succeed if the return type is exactly 'cv auto'
-// or 'decltype(auto)', so just check for that case directly.
+// For a function with a deduced result type to return void,
+// the result type as written must be 'auto' or 'decltype(auto)',
+// possibly cv-qualified or constrained, but not ref-qualified.
 if (!OrigResultType.getType()->getAs()) {
   Diag(ReturnLoc, diag::err_auto_fn_return_void_but_not_auto)
 << OrigResultType.getType();
   return true;
 }
-// We always deduce U = void in this case.
-Deduced = SubstAutoType(OrigResultType.getType(), Context.VoidTy);
-if (Deduced.isNull())
+// In the case of a return with no operand, the initializer is considered
+// to be 'void()'.
+Expr *Dummy = new (Context) CXXScalarValueInitExpr(
+Context.VoidTy,
+Context.getTrivialTypeSourceInfo(Context.VoidTy, ReturnLoc), ReturnLoc);
+DeduceAutoResult DAR = DeduceAutoType(OrigResultType, Dummy, Deduced);
+
+if (DAR == DAR_Failed && !FD->isInvalidDecl())
+  Diag(ReturnLoc, diag::err_auto_fn_deduction_failure)
+  << OrigResultType.getType() << Dummy->getType();
+
+if (DAR != DAR_Succeeded)
   return true;
   }
 
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -14674,18 +14674,20 @@
   if (getLangOpts().CPlusPlus14) {
 if (!FD->isInvalidDecl() && Body && !FD->isDependentContext() &&
 FD->getReturnType()->isUndeducedType()) {
-  // If the function has a deduced result type but contains no 'return'
-  // statements, the result type as written must be exactly 'auto', and
-  // the deduced result type is 'void'.
+  // For a function with a deduced result type to return void,
+  

[PATCH] D120323: [clang][SVE] Add support for arithmetic operators on SVE types

2022-03-04 Thread Bradley Smith via Phabricator via cfe-commits
bsmith added a comment.
Herald added a project: All.

This all looks reasonable to me, but I'll let @peterwaller-arm have the final 
say.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120323

___
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-03-04 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 updated this revision to Diff 412996.
jhuber6 added a comment.

Fix


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/DiagnosticDriverKinds.td
  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
@@ -4391,6 +4391,7 @@
   // one input.
   bool IsCuda = JA.isOffloading(Action::OFK_Cuda);
   bool IsCudaDevice = JA.isDeviceOffloading(Action::OFK_Cuda);
+  bool IsCudaHost = JA.isHostOffloading(Action::OFK_Cuda);
   bool IsHIP = JA.isOffloading(Action::OFK_HIP);
   bool IsHIPDevice = JA.isDeviceOffloading(Action::OFK_HIP);
   bool IsOpenMPDevice = JA.isDeviceOffloading(Action::OFK_OpenMP);
@@ -4414,6 +4415,7 @@
 
   InputInfoList ModuleHeaderInputs;
   InputInfoList OpenMPHostInputs;
+  InputInfoList CudaHostInputs;
   const InputInfo *CudaDeviceInput = nullptr;
   const InputInfo *OpenMPDeviceInput = nullptr;
   for (const InputInfo  : Inputs) {
@@ -4428,6 +4430,8 @@
 << types::getTypeName(Expected);
   }
   ModuleHeaderInputs.push_back(I);
+} else if (IsCudaHost && Args.hasArg(options::OPT_fopenmp_new_driver)) {
+  CudaHostInputs.push_back(I);
 } else if ((IsCuda || IsHIP) && !CudaDeviceInput) {
   CudaDeviceInput = 
 } else if (IsOpenMPDevice && !OpenMPDeviceInput) {
@@ -6957,6 +6961,7 @@
 auto OpenMPTCs = C.getOffloadToolChains();
 for (auto TI = OpenMPTCs.first, TE = OpenMPTCs.second; TI != TE;
  ++TI, ++InputFile) {
+  assert(InputFile->isFilename() && "Offloading requires a filename");
   const ToolChain *TC = TI->second;
   const ArgList  = C.getArgsForToolChain(TC, "", Action::OFK_OpenMP);
   StringRef File =
@@ -6969,6 +6974,21 @@
   TC->getTripleString() + "." +
   TCArgs.getLastArgValue(options::OPT_march_EQ) + "." + InputName));
 }
+  } else if (IsCudaHost && !CudaHostInputs.empty()) {
+const ToolChain *TC = C.getSingleOffloadToolChain();
+for (const auto  : CudaHostInputs) {
+  assert(InputFile.isFilename() && "Offloading requires a filename");
+  StringRef File =
+  C.getArgs().MakeArgString(TC->getInputFilename(InputFile));
+  StringRef InputName = Clang::getBaseInputStem(Args, Inputs);
+  // The CUDA toolchain should have a bound arch appended to the filename.
+  StringRef Arch = File.split(".").first.rsplit('-').second;
+  CmdArgs.push_back(Args.MakeArgString(
+  "-fembed-offload-object=" + File + "," +
+  Action::GetOffloadKindName(Action::OFK_Cuda) + "." +
+  TC->getTripleString() + "." +
+  Arch + "." + InputName));
+}
   }
 
   if (Triple.isAMDGPU()) {
@@ -8220,14 +8240,17 @@
   ArgStringList CmdArgs;
 
   // Pass the CUDA path to the linker wrapper tool.
-  for (auto  : 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, 

[PATCH] D120992: [analyzer] ReverseNull: New checker to warn for pointer value conditions, if the pointer value is unconditionally non-null

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

Looks great. I'm loving it!
BTW what is the semantics of `[p retain]` in ObjC? Can `p` be null in that 
context? Or does it count as a dereferences, hence it constraints the pointer?

Why did you touch the `AnalysisOrderChecker`, should we separate those changes?

Additionally, why do you think it needs to be in the `alpha.core` package 
instead of the `core`?
What sort of false-positives have you seen in the wild justifying that 
classification?




Comment at: clang/docs/analyzer/checkers.rst:1703
+alpha.core.ReverseNull (C)
+"
+Checks whether a dereferenced (and as such, assumed to be non-null) pointer is





Comment at: 
clang/lib/StaticAnalyzer/Checkers/NullPtrInterferenceChecker.cpp:196-198
+const MemRegion *MR = Cond->getAsRegion();
+if (!MR)
+  return;

I think additionally to this, you should also check for the type of the 
`Condition` expression. It's gotta be a pointer.



Comment at: 
clang/lib/StaticAnalyzer/Checkers/NullPtrInterferenceChecker.cpp:211-216
+  // We want to be sure that the constraint and the condition are in the
+  // same stackframe. Caller and callee functions' pre/post conditions may
+  // not apply to the caller stackframe. A similar issue is discussed here:
+  // 
https://discourse.llvm.org/t/static-analyzer-query-why-is-suppress-null-return-paths-enabled-by-default/
+  if (NBeforeConstraint->getLocationContext() != Ctx.getLocationContext())
+return;

IMO we should catch these as well:
```lang=C++
void store(int *q, int value) {
  *q = value;
}

void top(int *p) {
  store(p, 5);
  if (!p)
return;
}
```

In this case, the stack-frame in which the pointer gets constrained is not the 
same as where the redundant check resides - rather a child frame of that.



Comment at: clang/test/Analysis/null-pointer-interference.c:18
+  // expected-note@-1{{Pointer assumed non-null here}}
+  // expected-note@-2{{Consider moving the condition here}}
+  if (p)

"before this expression"?
The term `here` is not well defined IMO.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120992

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


[PATCH] D120888: [clang] Stop dragging a EndLoc around when parsing attributes

2022-03-04 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder updated this revision to Diff 412994.
tbaeder marked an inline comment as done.

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

https://reviews.llvm.org/D120888

Files:
  clang/include/clang/Parse/Parser.h
  clang/include/clang/Sema/DeclSpec.h
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Parse/ParseExprCXX.cpp
  clang/lib/Parse/ParsePragma.cpp
  clang/lib/Parse/ParseStmt.cpp
  clang/lib/Parse/ParseTentative.cpp

Index: clang/lib/Parse/ParseTentative.cpp
===
--- clang/lib/Parse/ParseTentative.cpp
+++ clang/lib/Parse/ParseTentative.cpp
@@ -1913,7 +1913,7 @@
   /*OuterMightBeMessageSend*/true))
   return TPResult::True;
 
-ParsedAttributes attrs(AttrFactory);
+ParsedAttributesWithRange attrs(AttrFactory);
 MaybeParseMicrosoftAttributes(attrs);
 
 // decl-specifier-seq
Index: clang/lib/Parse/ParseStmt.cpp
===
--- clang/lib/Parse/ParseStmt.cpp
+++ clang/lib/Parse/ParseStmt.cpp
@@ -106,7 +106,7 @@
   // at the start of the statement. Thus, we're not using MaybeParseAttributes
   // here because we don't want to allow arbitrary orderings.
   ParsedAttributesWithRange Attrs(AttrFactory);
-  MaybeParseCXX11Attributes(Attrs, nullptr, /*MightBeObjCMessageSend*/ true);
+  MaybeParseCXX11Attributes(Attrs, /*MightBeObjCMessageSend*/ true);
   if (getLangOpts().OpenCL)
 MaybeParseGNUAttributes(Attrs);
 
@@ -1119,7 +1119,7 @@
 ConsumeToken();
 
   ParsedAttributesWithRange attrs(AttrFactory);
-  MaybeParseCXX11Attributes(attrs, nullptr,
+  MaybeParseCXX11Attributes(attrs,
 /*MightBeObjCMessageSend*/ true);
 
   // If this is the start of a declaration, parse it as such.
Index: clang/lib/Parse/ParsePragma.cpp
===
--- clang/lib/Parse/ParsePragma.cpp
+++ clang/lib/Parse/ParsePragma.cpp
@@ -341,7 +341,7 @@
 Token ) override;
 
   /// A pool of attributes that were parsed in \#pragma clang attribute.
-  ParsedAttributes AttributesForPragmaAttribute;
+  ParsedAttributesWithRange AttributesForPragmaAttribute;
 };
 
 struct PragmaMaxTokensHereHandler : public PragmaHandler {
@@ -1365,12 +1365,12 @@
 namespace {
 struct PragmaAttributeInfo {
   enum ActionType { Push, Pop, Attribute };
-  ParsedAttributes 
+  ParsedAttributesWithRange 
   ActionType Action;
   const IdentifierInfo *Namespace = nullptr;
   ArrayRef Tokens;
 
-  PragmaAttributeInfo(ParsedAttributes ) : Attributes(Attributes) {}
+  PragmaAttributeInfo(ParsedAttributesWithRange ) : Attributes(Attributes) {}
 };
 
 #include "clang/Parse/AttrSubMatchRulesParserStringSwitches.inc"
@@ -1640,7 +1640,7 @@
   /*IsReinject=*/false);
   ConsumeAnnotationToken();
 
-  ParsedAttributes  = Info->Attributes;
+  ParsedAttributesWithRange  = Info->Attributes;
   Attrs.clearListOnly();
 
   auto SkipToEnd = [this]() {
Index: clang/lib/Parse/ParseExprCXX.cpp
===
--- clang/lib/Parse/ParseExprCXX.cpp
+++ clang/lib/Parse/ParseExprCXX.cpp
@@ -1252,7 +1252,7 @@
   TemplateParameterDepthRAII CurTemplateDepthTracker(TemplateParameterDepth);
   Actions.PushLambdaScope();
 
-  ParsedAttributes Attr(AttrFactory);
+  ParsedAttributesWithRange Attr(AttrFactory);
   if (getLangOpts().CUDA) {
 // In CUDA code, GNU attributes are allowed to appear immediately after the
 // "[...]", even if there is no "(...)" before the lambda body.
@@ -1355,7 +1355,8 @@
   DeclEndLoc = ESpecRange.getEnd();
 
 // Parse attribute-specifier[opt].
-MaybeParseCXX11Attributes(Attr, );
+if (MaybeParseCXX11Attributes(Attr))
+  DeclEndLoc = Attr.Range.getEnd();
 
 // Parse OpenCL addr space attribute.
 if (Tok.isOneOf(tok::kw___private, tok::kw___global, tok::kw___local,
Index: clang/lib/Parse/ParseDeclCXX.cpp
===
--- clang/lib/Parse/ParseDeclCXX.cpp
+++ clang/lib/Parse/ParseDeclCXX.cpp
@@ -4513,19 +4513,17 @@
 ///
 /// attribute-specifier-seq:
 ///   attribute-specifier-seq[opt] attribute-specifier
-void Parser::ParseCXX11Attributes(ParsedAttributesWithRange ,
-  SourceLocation *endLoc) {
+void Parser::ParseCXX11Attributes(ParsedAttributesWithRange ) {
   assert(standardAttributesAllowed());
 
-  SourceLocation StartLoc = Tok.getLocation(), Loc;
-  if (!endLoc)
-endLoc = 
+  SourceLocation StartLoc = Tok.getLocation();
+  SourceLocation EndLoc = StartLoc;
 
   do {
-ParseCXX11AttributeSpecifier(attrs, endLoc);
+ParseCXX11AttributeSpecifier(attrs, );
   } while (isCXX11AttributeSpecifier());
 
-  attrs.Range = SourceRange(StartLoc, *endLoc);
+  attrs.Range = SourceRange(StartLoc, EndLoc);
 

[PATCH] D120888: [clang] Stop dragging a EndLoc around when parsing attributes

2022-03-04 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder marked an inline comment as done.
tbaeder added a comment.

In D120888#3359798 , @aaron.ballman 
wrote:

> Thank you for working on this! We've (very) slowly been working towards all 
> of the attribute parsing functions taking a `ParsedAttributesWithRange` so 
> that we don't lose this information in the AST, and this is a good step in 
> the right direction towards that.

Yes, that's what I'm working on. There is a very peculiar test failure in 
`clang/test/SemaOpenCL/address-spaces.cl` however, so I can't switch everything 
over to `ParsedAttributesWithRange` (and do a rename) at once.




Comment at: clang/lib/Parse/ParseDecl.cpp:820-821
 T.consumeClose();
-if (End)
-  *End = T.getCloseLocation();
   }

aaron.ballman wrote:
> This is a case where we're regressing functionality -- we used to track the 
> actual end location here, but because this doesn't take a 
> `ParsedAttributesWithRange`, the end location is lost. Can we rework this to 
> take a `ParsedAttributesWithRange` instead?
Pretty sure yes. I already have that change locally anyway, I'll add it to this 
patch and run the tests.



Comment at: clang/lib/Parse/ParseDeclCXX.cpp:4661-4662
   assert(Tok.is(tok::l_square) && "Not a Microsoft attribute list");
+  // FIXME: ParseMicrosoftAttributes() does not support
+  // ParsedAttributesWithRange.
 

aaron.ballman wrote:
> Heh, same concern here as above.
Also same as above :)


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

https://reviews.llvm.org/D120888

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


[PATCH] D120992: [analyzer] ReverseNull: New checker to warn for pointer value conditions, if the pointer value is unconditionally non-null

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

In addition to the excellent summary, I'd like to highlight that this is 
intended to catch only the cases where the use of the constrained pointer is in 
the very same stack frame where it was constrained. This leads to a really nice 
property: local reasoning, which greatly reduces the number of false-positives.

This should be emphasized in the doc segment of the checker as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D120992

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


  1   2   >