[PATCH] D80603: add isAtPosition narrowing matcher for parmVarDecl

[Dmitri Gribenko via Phabricator via cfe-commits]

gribozavr2 added inline comments.



Comment at: clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp:2672
+TEST(IsAtPosition, BlockDecl) {
+  // FIXME: Needs to enable block-support (ie., -fblocks)
+  if (true)

Please use `matchesObjC` / `notMatchesObjC`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80603



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

[PATCH] D80603: add isAtPosition narrowing matcher for parmVarDecl

[Dmitri Gribenko via Phabricator via cfe-commits]

gribozavr2 added a comment.

In D80603#2058019 , @aaron.ballman 
wrote:

> I'm sorry if I'm being dense, but `hasParameter`  traverses to the 
> `ParmVarDecl`, so I'm not certain I understand why this new matcher is needed 
> as a public matcher. It seems like you can already accomplish this without 
> adding a second API to do effectively the same thing: 
> `functionDecl(hasParameter(0, parmVarDecl().bind("param")))`, can't you?


It is syntax sugar, true. Note that the proposed matcher is a narrowing matcher 
for `parmVarDecl()`, while your suggestion is a narrowing matcher for 
`functionDecl()`, so it is not an entirely apples-to-apples comparison. Think 
about use cases like: `declRefExpr(to(parmVarDecl(at(...`. To rewrite that 
with `hasParameter()`, we have to use `hasAncestor` to find the `functionDecl` 
first, and then compare the AST node pointers. So while it is possible to 
express this proposed operation today, it requires a complex matcher for such a 
conceptually simple operation.




Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:4621
+template 
+static bool __isParamAt(const clang::DeclContext *Context,
+const clang::ParmVarDecl , unsigned N) {

Identifiers with double underscores are reserved. Also, this file typically 
does not define helpers.

My best suggestion is to define a local lambda in the AST_MATCHER_P, or just 
copy the code three times -- there is not that much duplication.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80603



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

[PATCH] D80289: [Driver][X86] Support branch align options with LTO

[Kan Shengchen via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
skan marked an inline comment as done.
Closed by commit rG495444999549: [Driver][X86] Support branch align options 
with LTO (authored by skan).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80289

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/CommonArgs.h
  clang/test/Driver/x86-malign-branch.c

Index: clang/test/Driver/x86-malign-branch.c
===
--- clang/test/Driver/x86-malign-branch.c
+++ clang/test/Driver/x86-malign-branch.c
@@ -1,8 +1,10 @@
-/// Test that -malign-branch* and -mbranches-within-32B-boundaries are parsed and converted to -mllvm options.
+/// Test that -malign-branch* and -mbranches-within-32B-boundaries are parsed and converted to MC options.
 
 /// Test -malign-branch-boundary=
 // RUN: %clang -target x86_64 -malign-branch-boundary=16 %s -c -### 2>&1 | FileCheck %s --check-prefix=BOUNDARY
 // BOUNDARY: "-mllvm" "-x86-align-branch-boundary=16"
+// RUN: %clang -target x86_64-unknown-linux -malign-branch-boundary=16 -flto %s -### 2>&1 | FileCheck %s --check-prefix=BOUNDARY-LTO
+// BOUNDARY-LTO: "-plugin-opt=-x86-align-branch-boundary=16"
 
 // RUN: %clang -target x86_64 -malign-branch-boundary=8 %s -c -### 2>&1 | FileCheck %s --check-prefix=BOUNDARY-ERR
 // RUN: %clang -target x86_64 -malign-branch-boundary=15 %s -c -### 2>&1 | FileCheck %s --check-prefix=BOUNDARY-ERR
@@ -13,6 +15,8 @@
 // TYPE0: "-mllvm" "-x86-align-branch=fused+jcc+jmp"
 // RUN: %clang -target x86_64 -malign-branch=fused,jcc,jmp,ret,call,indirect %s -c -### %s 2>&1 | FileCheck %s --check-prefix=TYPE1
 // TYPE1: "-mllvm" "-x86-align-branch=fused+jcc+jmp+ret+call+indirect"
+// RUN: %clang -target x86_64-unknown-linux -malign-branch=fused,jcc,jmp -flto %s -### %s 2>&1 | FileCheck %s --check-prefix=TYPE0-LTO
+// TYPE0-LTO: "-plugin-opt=-x86-align-branch=fused+jcc+jmp"
 
 // RUN: %clang -target x86_64 -malign-branch=fused,foo,bar %s -c -### %s 2>&1 | FileCheck %s --check-prefix=TYPE-ERR
 // TYPE-ERR: invalid argument 'foo' to -malign-branch=; each element must be one of: fused, jcc, jmp, call, ret, indirect
@@ -23,10 +27,14 @@
 // PREFIX-0: "-mllvm" "-x86-pad-max-prefix-size=0"
 // RUN: %clang -target x86_64 -mpad-max-prefix-size=15 %s -c -### 2>&1 | FileCheck %s --check-prefix=PREFIX-15
 // PREFIX-15: "-mllvm" "-x86-pad-max-prefix-size=15"
+// RUN: %clang -target x86_64-unknown-linux -mpad-max-prefix-size=0 -flto %s -### 2>&1 | FileCheck %s --check-prefix=PREFIX-0-LTO
+// PREFIX-0-LTO: "-plugin-opt=-x86-pad-max-prefix-size=0"
 
 /// Test -mbranches-within-32B-boundaries
 // RUN: %clang -target x86_64 -mbranches-within-32B-boundaries %s -c -### 2>&1 | FileCheck %s --check-prefix=32B
 // 32B: "-mllvm" "-x86-branches-within-32B-boundaries"
+// RUN: %clang -target x86_64-unknown-linux -mbranches-within-32B-boundaries -flto %s -### 2>&1 | FileCheck %s --check-prefix=32B-LTO
+// 32B-LTO: "-plugin-opt=-x86-branches-within-32B-boundaries"
 
 /// Unsupported on other targets.
 // RUN: %clang -target aarch64 -malign-branch=jmp %s -c -### 2>&1 | FileCheck --check-prefix=UNUSED %s
Index: clang/lib/Driver/ToolChains/CommonArgs.h
===
--- clang/lib/Driver/ToolChains/CommonArgs.h
+++ clang/lib/Driver/ToolChains/CommonArgs.h
@@ -127,6 +127,8 @@
 void addMultilibFlag(bool Enabled, const char *const Flag,
  Multilib::flags_list );
 
+void addX86AlignBranchArgs(const Driver , const llvm::opt::ArgList ,
+   llvm::opt::ArgStringList , bool IsLTO);
 } // end namespace tools
 } // end namespace driver
 } // end namespace clang
Index: clang/lib/Driver/ToolChains/CommonArgs.cpp
===
--- clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -358,6 +358,7 @@
   ArgStringList , const InputInfo ,
   const InputInfo , bool IsThinLTO) {
   const char *Linker = Args.MakeArgString(ToolChain.GetLinkerPath());
+  const Driver  = ToolChain.getDriver();
   if (llvm::sys::path::filename(Linker) != "ld.lld" &&
   llvm::sys::path::stem(Linker) != "ld.lld") {
 // Tell the linker to load the plugin. This has to come before
@@ -374,10 +375,9 @@
 #endif
 
 SmallString<1024> Plugin;
-llvm::sys::path::native(Twine(ToolChain.getDriver().Dir) +
-"/../lib" CLANG_LIBDIR_SUFFIX "/LLVMgold" +
-Suffix,
-Plugin);
+llvm::sys::path::native(
+Twine(D.Dir) + "/../lib" CLANG_LIBDIR_SUFFIX "/LLVMgold" + Suffix,
+Plugin);
 CmdArgs.push_back(Args.MakeArgString(Plugin));
   }
 
@@ -417,7 +417,7 @@
   if 

[clang] 4954449 - [Driver][X86] Support branch align options with LTO

[Shengchen Kan via cfe-commits]

Author: Shengchen Kan
Date: 2020-05-28T13:17:14+08:00
New Revision: 49544499954912c5a0f02014de53e0bc0234c7af

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

LOG: [Driver][X86] Support branch align options with LTO

Summary: Before this patch, we use two different ways to pass options to align 
branch
depending on whether LTO is enabled. For example, 
`-mbranches-within-32B-boundaries`
w/o LTO and `-Wl,-plugin-opt=-x86-branches-within-32B-boundaries` w/ LTO.  It's
inconvenient, so this patch unifies the way: we only need to pass options like
`-mbranches-within-32B-boundaries` to align branches, no matter LTO is enabled 
or not.

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Driver/ToolChains/CommonArgs.cpp
clang/lib/Driver/ToolChains/CommonArgs.h
clang/test/Driver/x86-malign-branch.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index f33983db3e1e..dd83cafb2748 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -2045,57 +2045,10 @@ void Clang::AddSystemZTargetArgs(const ArgList ,
   }
 }
 
-static void addX86AlignBranchArgs(const Driver , const ArgList ,
-  ArgStringList ) {
-  if (Args.hasArg(options::OPT_mbranches_within_32B_boundaries)) {
-CmdArgs.push_back("-mllvm");
-CmdArgs.push_back("-x86-branches-within-32B-boundaries");
-  }
-  if (const Arg *A = Args.getLastArg(options::OPT_malign_branch_boundary_EQ)) {
-StringRef Value = A->getValue();
-unsigned Boundary;
-if (Value.getAsInteger(10, Boundary) || Boundary < 16 ||
-!llvm::isPowerOf2_64(Boundary)) {
-  D.Diag(diag::err_drv_invalid_argument_to_option)
-  << Value << A->getOption().getName();
-} else {
-  CmdArgs.push_back("-mllvm");
-  CmdArgs.push_back(
-  Args.MakeArgString("-x86-align-branch-boundary=" + Twine(Boundary)));
-}
-  }
-  if (const Arg *A = Args.getLastArg(options::OPT_malign_branch_EQ)) {
-std::string AlignBranch;
-for (StringRef T : A->getValues()) {
-  if (T != "fused" && T != "jcc" && T != "jmp" && T != "call" &&
-  T != "ret" && T != "indirect")
-D.Diag(diag::err_drv_invalid_malign_branch_EQ)
-<< T << "fused, jcc, jmp, call, ret, indirect";
-  if (!AlignBranch.empty())
-AlignBranch += '+';
-  AlignBranch += T;
-}
-CmdArgs.push_back("-mllvm");
-CmdArgs.push_back(Args.MakeArgString("-x86-align-branch=" + AlignBranch));
-  }
-  if (const Arg *A = Args.getLastArg(options::OPT_mpad_max_prefix_size_EQ)) {
-StringRef Value = A->getValue();
-unsigned PrefixSize;
-if (Value.getAsInteger(10, PrefixSize)) {
-  D.Diag(diag::err_drv_invalid_argument_to_option)
-  << Value << A->getOption().getName();
-} else {
-  CmdArgs.push_back("-mllvm");
-  CmdArgs.push_back(
-  Args.MakeArgString("-x86-pad-max-prefix-size=" + Twine(PrefixSize)));
-}
-  }
-}
-
 void Clang::AddX86TargetArgs(const ArgList ,
  ArgStringList ) const {
   const Driver  = getToolChain().getDriver();
-  addX86AlignBranchArgs(D, Args, CmdArgs);
+  addX86AlignBranchArgs(D, Args, CmdArgs, /*IsLTO=*/false);
 
   if (!Args.hasFlag(options::OPT_mred_zone, options::OPT_mno_red_zone, true) ||
   Args.hasArg(options::OPT_mkernel) ||
@@ -6745,7 +6698,8 @@ void ClangAs::AddMIPSTargetArgs(const ArgList ,
 
 void ClangAs::AddX86TargetArgs(const ArgList ,
ArgStringList ) const {
-  addX86AlignBranchArgs(getToolChain().getDriver(), Args, CmdArgs);
+  addX86AlignBranchArgs(getToolChain().getDriver(), Args, CmdArgs,
+/*IsLTO=*/false);
 
   if (Arg *A = Args.getLastArg(options::OPT_masm_EQ)) {
 StringRef Value = A->getValue();

diff  --git a/clang/lib/Driver/ToolChains/CommonArgs.cpp 
b/clang/lib/Driver/ToolChains/CommonArgs.cpp
index 85a1a4e1ac07..33c43222b5f9 100644
--- a/clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ b/clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -358,6 +358,7 @@ void tools::addLTOOptions(const ToolChain , const 
ArgList ,
   ArgStringList , const InputInfo ,
   const InputInfo , bool IsThinLTO) {
   const char *Linker = Args.MakeArgString(ToolChain.GetLinkerPath());
+  const Driver  = ToolChain.getDriver();
   if (llvm::sys::path::filename(Linker) != "ld.lld" &&
   llvm::sys::path::stem(Linker) != "ld.lld") {
 // Tell the linker to load the plugin. This has to come before
@@ -374,10 +375,9 @@ void tools::addLTOOptions(const ToolChain , 
const ArgList ,
 #endif
 
 SmallString<1024> Plugin;
-  

[PATCH] D80603: add isAtPosition narrowing matcher for parmVarDecl

[Vy Nguyen via Phabricator via cfe-commits]

oontvoo updated this revision to Diff 266735.
oontvoo added a comment.

More tests for Block


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80603

Files:
  clang/docs/LibASTMatchersReference.html
  clang/include/clang/ASTMatchers/ASTMatchers.h
  clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp

Index: clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
@@ -2643,6 +2643,43 @@
   parmVarDecl(hasDefaultArgument(;
 }
 
+TEST(IsAtPosition, Basic) {
+  EXPECT_TRUE(matches("void x(int a, int b) {}", parmVarDecl(isAtPosition(1;
+  EXPECT_TRUE(matches("void x(int a, int b) {}", parmVarDecl(isAtPosition(0;
+  EXPECT_TRUE(matches("void x(int a, int b) {}", parmVarDecl(isAtPosition(1;
+  EXPECT_TRUE(notMatches("void x(int val) {}", parmVarDecl(isAtPosition(1;
+}
+
+TEST(IsAtPosition, FunctionDecl) {
+  EXPECT_TRUE(matches("void x(int a);", parmVarDecl(isAtPosition(0;
+  EXPECT_TRUE(matches("void x(int a, int b);", parmVarDecl(isAtPosition(0;
+  EXPECT_TRUE(matches("void x(int a, int b);", parmVarDecl(isAtPosition(1;
+  EXPECT_TRUE(notMatches("void x(int val);", parmVarDecl(isAtPosition(1;
+}
+
+TEST(IsAtPosition, Lambda) {
+  EXPECT_TRUE(
+  matches("void x() { [](int a) {};  }", parmVarDecl(isAtPosition(0;
+  EXPECT_TRUE(matches("void x() { [](int a, int b) {}; }",
+  parmVarDecl(isAtPosition(0;
+  EXPECT_TRUE(matches("void x() { [](int a, int b) {}; }",
+  parmVarDecl(isAtPosition(1;
+  EXPECT_TRUE(
+  notMatches("void x() { [](int val) {}; }", parmVarDecl(isAtPosition(1;
+}
+
+TEST(IsAtPosition, BlockDecl) {
+  // FIXME: Needs to enable block-support (ie., -fblocks)
+  if (true)
+return;
+  EXPECT_TRUE(matches("void x()  { auto b = ^(int y) { }; } ",
+  parmVarDecl(isAtPosition(0;
+  EXPECT_TRUE(matches("void x()  { auto b = ^(int y,int z) { }; } ",
+  parmVarDecl(isAtPosition(1;
+  EXPECT_TRUE(notMatches("void x()  { auto b = ^(int y) { }; } ",
+ parmVarDecl(isAtPosition(1;
+}
+
 TEST(IsArray, Basic) {
   EXPECT_TRUE(matches("struct MyClass {}; MyClass *p1 = new MyClass[10];",
   cxxNewExpr(isArray(;
Index: clang/include/clang/ASTMatchers/ASTMatchers.h
===
--- clang/include/clang/ASTMatchers/ASTMatchers.h
+++ clang/include/clang/ASTMatchers/ASTMatchers.h
@@ -4615,6 +4615,39 @@
  InnerMatcher.matches(*DeclarationStatement, Finder, Builder);
 }
 
+// Returns true if Node is a parameter at N in the given Context
+// of type DeclT.
+template 
+static bool __isParamAt(const clang::DeclContext *Context,
+const clang::ParmVarDecl , unsigned N) {
+  if (const auto *Decl = dyn_cast_or_null(Context))
+return N < Decl->param_size() && Decl->getParamDecl(N) == 
+
+  return false;
+}
+
+/// Matches the ParmVarDecl nodes that are at the N'th position in the parameter
+/// list. The parameter list could be that of either a block, function, or
+/// objc-method.
+///
+///
+/// Given
+///
+/// \code
+/// void f(int a, int b, int c) {
+/// }
+/// \endcode
+///
+/// ``parmVarDecl(isAtPosition(0))`` matches ``int a``.
+///
+/// ``parmVarDecl(isAtPosition(1))`` matches ``int b``.
+AST_MATCHER_P(clang::ParmVarDecl, isAtPosition, unsigned, N) {
+  const clang::DeclContext *ParentContext = Node.getParentFunctionOrMethod();
+  return __isParamAt(ParentContext, Node, N) ||
+ __isParamAt(ParentContext, Node, N) ||
+ __isParamAt(ParentContext, Node, N);
+}
+
 /// Matches the index expression of an array subscript expression.
 ///
 /// Given
Index: clang/docs/LibASTMatchersReference.html
===
--- clang/docs/LibASTMatchersReference.html
+++ clang/docs/LibASTMatchersReference.html
@@ -4671,6 +4671,23 @@
 Usable as: Matcherhttps://clang.llvm.org/doxygen/classclang_1_1FunctionDecl.html;>FunctionDecl, Matcherhttps://clang.llvm.org/doxygen/classclang_1_1VarDecl.html;>VarDecl, Matcherhttps://clang.llvm.org/doxygen/classclang_1_1CXXRecordDecl.html;>CXXRecordDecl
 
 
+
+Matcherclang::ParmVarDeclisAtPositionunsigned N
+Matches the ParmVarDecl nodes that are at the N'th position in the parameter
+list. The parameter list could be that of either a block, function, or
+objc-method.
+
+
+Given
+
+void f(int a, int b, int c) {
+}
+
+``parmVarDecl(isAtPosition(0))`` matches ``int a``.
+
+``parmVarDecl(isAtPosition(1))`` matches ``int b``.
+
+
 
 
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org

[PATCH] D80606: [libTooling] Fix Transformer to work with ambient traversal kinds

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel updated this revision to Diff 266729.
ymandel added a comment.

adds a fix to transformer


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80606

Files:
  clang/include/clang/Tooling/Transformer/RewriteRule.h
  clang/lib/Tooling/Transformer/RewriteRule.cpp
  clang/unittests/Tooling/TransformerTest.cpp

Index: clang/unittests/Tooling/TransformerTest.cpp
===
--- clang/unittests/Tooling/TransformerTest.cpp
+++ clang/unittests/Tooling/TransformerTest.cpp
@@ -571,6 +571,59 @@
   testRule(Rule, Input, Expected);
 }
 
+// Verifies that a rule with a matcher for an implicit node (like
+// `implicitCastExpr`) does not change the code, when the traversal kind is not
+// explicitly set ti TK_AsIs). In this test, only the rule with the
+// explicit-node matcher will fire.
+TEST_F(TransformerTest, OrderedRuleImplicitIgnored) {
+  std::string Input = R"cc(
+void f1();
+int f2();
+void call_f1() { f1(); }
+float call_f2() { return f2(); }
+  )cc";
+  std::string Expected = R"cc(
+void f1();
+int f2();
+void call_f1() { REPLACE_F1; }
+float call_f2() { return f2(); }
+  )cc";
+
+  RewriteRule ReplaceF1 =
+  makeRule(callExpr(callee(functionDecl(hasName("f1",
+   changeTo(cat("REPLACE_F1")));
+  RewriteRule ReplaceF2 =
+  makeRule(implicitCastExpr(hasSourceExpression(callExpr())),
+   changeTo(cat("REPLACE_F2")));
+  testRule(applyFirst({ReplaceF1, ReplaceF2}), Input, Expected);
+}
+
+// Verifies that explicitly setting the traversal kind fixes the problem in the
+// previous test.
+TEST_F(TransformerTest, OrderedRuleImplicitMatched) {
+  std::string Input = R"cc(
+void f1();
+int f2();
+void call_f1() { f1(); }
+float call_f2() { return f2(); }
+  )cc";
+  std::string Expected = R"cc(
+void f1();
+int f2();
+void call_f1() { REPLACE_F1; }
+float call_f2() { return REPLACE_F2; }
+  )cc";
+
+  RewriteRule ReplaceF1 = makeRule(
+  traverse(clang::TK_AsIs, callExpr(callee(functionDecl(hasName("f1"),
+  changeTo(cat("REPLACE_F1")));
+  RewriteRule ReplaceF2 =
+  makeRule(traverse(clang::TK_AsIs,
+implicitCastExpr(hasSourceExpression(callExpr(,
+   changeTo(cat("REPLACE_F2")));
+  testRule(applyFirst({ReplaceF1, ReplaceF2}), Input, Expected);
+}
+
 //
 // Negative tests (where we expect no transformation to occur).
 //
Index: clang/lib/Tooling/Transformer/RewriteRule.cpp
===
--- clang/lib/Tooling/Transformer/RewriteRule.cpp
+++ clang/lib/Tooling/Transformer/RewriteRule.cpp
@@ -116,10 +116,13 @@
 #endif
 
 // Binds each rule's matcher to a unique (and deterministic) tag based on
-// `TagBase` and the id paired with the case.
+// `TagBase` and the id paired with the case. All of the returned matchers have
+// their traversal kind explicitly set, either based on a pre-set kind or taken
+// from `DefaultTraversalKind`.
 static std::vector taggedMatchers(
 StringRef TagBase,
-const SmallVectorImpl> ) {
+const SmallVectorImpl> ,
+ast_type_traits::TraversalKind DefaultTraversalKind) {
   std::vector Matchers;
   Matchers.reserve(Cases.size());
   for (const auto  : Cases) {
@@ -127,8 +130,11 @@
 // HACK: Many matchers are not bindable, so ensure that tryBind will work.
 DynTypedMatcher BoundMatcher(Case.second.Matcher);
 BoundMatcher.setAllowBind(true);
-auto M = BoundMatcher.tryBind(Tag);
-Matchers.push_back(*std::move(M));
+auto M = *BoundMatcher.tryBind(Tag);
+Matchers.push_back(!M.getTraversalKind()
+   ? DynTypedMatcher::constructWithTraversalKind(
+ std::move(M), DefaultTraversalKind)
+   : std::move(M));
   }
   return Matchers;
 }
@@ -143,8 +149,9 @@
   return R;
 }
 
-std::vector
-transformer::detail::buildMatchers(const RewriteRule ) {
+std::vector transformer::detail::buildMatchers(
+const RewriteRule ,
+ast_type_traits::TraversalKind DefaultTraversalKind) {
   // Map the cases into buckets of matchers -- one for each "root" AST kind,
   // which guarantees that they can be combined in a single anyOf matcher. Each
   // case is paired with an identifying number that is converted to a string id
@@ -162,10 +169,11 @@
   for (const auto  : Buckets) {
 DynTypedMatcher M = DynTypedMatcher::constructVariadic(
 DynTypedMatcher::VO_AnyOf, Bucket.first,
-taggedMatchers("Tag", Bucket.second));
+taggedMatchers("Tag", Bucket.second, DefaultTraversalKind));
 M.setAllowBind(true);
 // `tryBind` is guaranteed to succeed, because `AllowBind` was set to true.
-Matchers.push_back(*M.tryBind(RewriteRule::RootID));
+Matchers.push_back(DynTypedMatcher::constructWithTraversalKind(
+

[PATCH] D80222: Replace Clang's createRuntimeFunction with the definitions in OMPKinds.def

[Joseph Huber via Phabricator via cfe-commits]

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



Comment at: openmp/runtime/test/tasking/kmp_taskloop.c:100
 th_counter[i] = 0;
-#pragma omp parallel num_threads(N)
+#pragma omp parallel // num_threads(N)
 {

jdoerfert wrote:
> jhuber6 wrote:
> > jdoerfert wrote:
> > > jhuber6 wrote:
> > > > jdoerfert wrote:
> > > > > jhuber6 wrote:
> > > > > > AndreyChurbanov wrote:
> > > > > > > jhuber6 wrote:
> > > > > > > > jhuber6 wrote:
> > > > > > > > > jdoerfert wrote:
> > > > > > > > > > jhuber6 wrote:
> > > > > > > > > > > I am not entirely sure why, but commenting this out 
> > > > > > > > > > > causes the problem to go away. I tried adding proper 
> > > > > > > > > > > names to the forward-declared functions but since clang 
> > > > > > > > > > > already knew I had something called ident_t, I couldn't 
> > > > > > > > > > > declare a new struct with the same name.
> > > > > > > > > > This is not good. The difference should only be that the 
> > > > > > > > > > `kmpc_fork_call` has a different argument, right? Does the 
> > > > > > > > > > segfault happen at compile or runtime?
> > > > > > > > > > 
> > > > > > > > > > You can just use the ident_t clang created, right? Did you 
> > > > > > > > > > print the function names requested by clang as we discussed?
> > > > > > > > > I added an assertion and debug statements. If I try to 
> > > > > > > > > declare a struct named "Ident_t" I get the following error 
> > > > > > > > > message in the seg-fault. I think the seg-fault is 
> > > > > > > > > compile-time.
> > > > > > > > > 
> > > > > > > > > Found OpenMP runtime function __kmpc_global_thread_num with 
> > > > > > > > > type i32 (%struct.ident_t.0*). Expected type is i32 
> > > > > > > > > (%struct.ident_t*)
> > > > > > > > > clang: 
> > > > > > > > > /home/jhuber/Documents/llvm-project/llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:124:
> > > > > > > > >  static llvm::Function* 
> > > > > > > > > llvm::OpenMPIRBuilder::getOrCreateRuntimeFunction(llvm::Module&,
> > > > > > > > >  llvm::omp::RuntimeFunction): Assertion `FnTy == 
> > > > > > > > > Fn->getFunctionType() && "Found OpenMP runtime function has 
> > > > > > > > > mismatched types"' failed.
> > > > > > > > I'm not sure if there's a way around this without changing the 
> > > > > > > > getOrCreateRuntimeFunction method to return a FunctionCallee 
> > > > > > > > and removing the assertion. Clang doesn't know about the 
> > > > > > > > ident_t struct when it's compiling the file, but when its doing 
> > > > > > > > the codegen it sees two structs with the same name and creates 
> > > > > > > > a new name. So when it gets the types it says that ident_t and 
> > > > > > > > ident_t.0 don't match. As you said the old version got around 
> > > > > > > > this by adding a bitcasting instruction so it knew how to turn 
> > > > > > > > it into an ident_t pointer.
> > > > > > > Note that this change breaks the test on any system with more 
> > > > > > > that 4 procs.  Because array th_counter[4] is indexed by thread 
> > > > > > > number which can easily be greater than 3 if number of threads is 
> > > > > > > not limited.
> > > > > > The problem was that the num_threads clause required an implicit 
> > > > > > call to kmpc_global_thread_num so it could be passed to 
> > > > > > kmpc_push_num_threads. The types of the implicit function and the 
> > > > > > forward declaration then wouldn't match up. I added another forward 
> > > > > > declaration to explicitly call kmpc_push_num_threads. Is this a 
> > > > > > sufficient solution?
> > > > > We need this to work with num_threads(8). 
> > > > > 
> > > > > > Clang doesn't know about the ident_t struct when it's compiling the 
> > > > > > file, but when its doing the codegen it sees two structs with the 
> > > > > > same name and creates a new name.
> > > > > 
> > > > > Where are the two structs coming from? We should have one. If clang 
> > > > > introduces one it needs to use the one from OMPKindes.def instead. Is 
> > > > > that a fix?
> > > > The first struct is the one that I'm assuming comes from the OpenMP 
> > > > CodeGen that places the Ident_t struct in the IR file. if I declare a 
> > > > struct also named ident_t in the C source file it most likely will see 
> > > > that there's two structs with the same name and call the second one 
> > > > "ident_t.0" internally. The other ident_t struct is only known once 
> > > > clang generates the LLVM IR so I can't just use "ident_t" nor can I 
> > > > declare a struct with the same name.
> > > 1) Either Clang needs to use the `llvm::omp::types::Ident` *or* Clang 
> > > needs to define `llvm::omp::types::Ident` and we do not do it via  
> > > `__OMP_STRUCT_TYPE(Ident, ident_t, Int32, Int32, Int32, Int32, Int8Ptr)`. 
> > > I would prefer the first solution. 
> > > 
> > > 2) `OMPConstants.cpp` does pick up an existing struct type with the same 
> > > name if present. That is, probably not what 

[PATCH] D80289: [Driver][X86] Support branch align options with LTO

[Fangrui Song via Phabricator via cfe-commits]

MaskRay accepted this revision.
MaskRay added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/test/Driver/x86-malign-branch.c:6
 // BOUNDARY: "-mllvm" "-x86-align-branch-boundary=16"
+// RUN: %clang -target x86_64-unknown-linux -malign-branch-boundary=16 -flto 
%s -### 2>&1 | FileCheck %s --check-prefix=BOUNDARY-LTO
+// BOUNDARY-LTO: "-plugin-opt=-x86-align-branch-boundary=16"

skan wrote:
> MaskRay wrote:
> > Drop `-unknown-linux`
> > 
> > ditto below
> Sorry it seems I didn't submit my comment...
> 
> Dropping `-unknown-linux`  here would get an error
> 
> ```
>  error: 'x86_64': unable to pass LLVM bit-code files to linker
> ```
Ah, you are right. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80289



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

[PATCH] D77178: [Analyzer][WebKit] NoUncountedMembersChecker

[Jan Korous via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG660cda572d6e: [Analyzer][WebKit] NoUncountedMembersChecker 
(authored by jkorous).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77178

Files:
  clang/docs/analyzer/checkers.rst
  clang/include/clang/StaticAnalyzer/Checkers/Checkers.td
  clang/lib/StaticAnalyzer/Checkers/CMakeLists.txt
  clang/lib/StaticAnalyzer/Checkers/WebKit/DiagOutputUtils.h
  clang/lib/StaticAnalyzer/Checkers/WebKit/NoUncountedMembersChecker.cpp
  clang/test/Analysis/Checkers/WebKit/uncounted-members.cpp

Index: clang/test/Analysis/Checkers/WebKit/uncounted-members.cpp
===
--- /dev/null
+++ clang/test/Analysis/Checkers/WebKit/uncounted-members.cpp
@@ -0,0 +1,43 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=webkit.WebKitNoUncountedMemberChecker -verify %s
+
+#include "mock-types.h"
+
+namespace members {
+  struct Foo {
+  private:
+RefCountable* a = nullptr;
+// expected-warning@-1{{Member variable 'a' in 'members::Foo' is a raw pointer to ref-countable type 'RefCountable'}}
+
+  protected:
+RefPtr b;
+
+  public:
+RefCountable silenceWarningAboutInit;
+RefCountable& c = silenceWarningAboutInit;
+// expected-warning@-1{{Member variable 'c' in 'members::Foo' is a reference to ref-countable type 'RefCountable'}}
+Ref d;
+  };
+
+  template
+  struct FooTmpl {
+T* a;
+// expected-warning@-1{{Member variable 'a' in 'members::FooTmpl' is a raw pointer to ref-countable type 'RefCountable'}}
+  };
+
+  void forceTmplToInstantiate(FooTmpl) {}
+}
+
+namespace ignore_unions {
+  union Foo {
+RefCountable* a;
+RefPtr b;
+Ref c;
+  };
+
+  template
+  union RefPtr {
+T* a;
+  };
+
+  void forceTmplToInstantiate(RefPtr) {}
+}
Index: clang/lib/StaticAnalyzer/Checkers/WebKit/NoUncountedMembersChecker.cpp
===
--- /dev/null
+++ clang/lib/StaticAnalyzer/Checkers/WebKit/NoUncountedMembersChecker.cpp
@@ -0,0 +1,150 @@
+//===- NoUncountedMembersChecker.cpp -*- C++ -*-==//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "ASTUtils.h"
+#include "DiagOutputUtils.h"
+#include "PtrTypesSemantics.h"
+#include "clang/AST/CXXInheritance.h"
+#include "clang/AST/Decl.h"
+#include "clang/AST/DeclCXX.h"
+#include "clang/AST/RecursiveASTVisitor.h"
+#include "clang/StaticAnalyzer/Checkers/BuiltinCheckerRegistration.h"
+#include "clang/StaticAnalyzer/Core/BugReporter/BugReporter.h"
+#include "clang/StaticAnalyzer/Core/BugReporter/BugType.h"
+#include "clang/StaticAnalyzer/Core/Checker.h"
+#include "llvm/ADT/DenseSet.h"
+#include "llvm/Support/Casting.h"
+
+using namespace clang;
+using namespace ento;
+
+namespace {
+
+class NoUncountedMemberChecker
+: public Checker> {
+private:
+  BugType Bug;
+  mutable BugReporter *BR;
+
+public:
+  NoUncountedMemberChecker()
+  : Bug(this,
+"Member variable is a raw-poiner/reference to reference-countable "
+"type",
+"WebKit coding guidelines") {}
+
+  void checkASTDecl(const TranslationUnitDecl *TUD, AnalysisManager ,
+BugReporter ) const {
+BR = 
+
+// The calls to checkAST* from AnalysisConsumer don't
+// visit template instantiations or lambda classes. We
+// want to visit those, so we make our own RecursiveASTVisitor.
+struct LocalVisitor : public RecursiveASTVisitor {
+  const NoUncountedMemberChecker *Checker;
+  explicit LocalVisitor(const NoUncountedMemberChecker *Checker)
+  : Checker(Checker) {
+assert(Checker);
+  }
+
+  bool shouldVisitTemplateInstantiations() const { return true; }
+  bool shouldVisitImplicitCode() const { return false; }
+
+  bool VisitRecordDecl(const RecordDecl *RD) {
+Checker->visitRecordDecl(RD);
+return true;
+  }
+};
+
+LocalVisitor visitor(this);
+visitor.TraverseDecl(const_cast(TUD));
+  }
+
+  void visitRecordDecl(const RecordDecl *RD) const {
+if (shouldSkipDecl(RD))
+  return;
+
+for (auto Member : RD->fields()) {
+  const Type *MemberType = Member->getType().getTypePtrOrNull();
+  if (!MemberType)
+continue;
+
+  if (auto *MemberCXXRD = MemberType->getPointeeCXXRecordDecl()) {
+if (isRefCountable(MemberCXXRD))
+  reportBug(Member, MemberType, MemberCXXRD, RD);
+  }
+}
+  }
+
+  bool shouldSkipDecl(const RecordDecl *RD) const {
+if (!RD->isThisDeclarationADefinition())
+  return 

[clang] 660cda5 - [Analyzer][WebKit] NoUncountedMembersChecker

[Jan Korous via cfe-commits]

Author: Jan Korous
Date: 2020-05-27T19:46:32-07:00
New Revision: 660cda572d6e05e55a9d959e61aba51790c0abbd

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

LOG: [Analyzer][WebKit] NoUncountedMembersChecker

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

Added: 
clang/lib/StaticAnalyzer/Checkers/WebKit/NoUncountedMembersChecker.cpp
clang/test/Analysis/Checkers/WebKit/uncounted-members.cpp

Modified: 
clang/docs/analyzer/checkers.rst
clang/include/clang/StaticAnalyzer/Checkers/Checkers.td
clang/lib/StaticAnalyzer/Checkers/CMakeLists.txt
clang/lib/StaticAnalyzer/Checkers/WebKit/DiagOutputUtils.h

Removed: 




diff  --git a/clang/docs/analyzer/checkers.rst 
b/clang/docs/analyzer/checkers.rst
index dcf1f28994de..c977dde8c52f 100644
--- a/clang/docs/analyzer/checkers.rst
+++ b/clang/docs/analyzer/checkers.rst
@@ -1403,6 +1403,24 @@ Ref-counted types hold their ref-countable data by a raw 
pointer and allow impli
 
  struct Derived : RefCntblBase { }; // warn
 
+.. _webkit-WebKitNoUncountedMemberChecker:
+
+webkit.WebKitNoUncountedMemberChecker
+
+Raw pointers and references to uncounted types can't be used as class members. 
Only ref-counted types are allowed.
+
+.. code-block:: cpp
+ struct RefCntbl {
+   void ref() {}
+   void deref() {}
+ };
+
+ struct Foo {
+   RefCntbl * ptr; // warn
+   RefCntbl & ptr; // warn
+   // ...
+ };
+
 .. _alpha-checkers:
 
 Experimental Checkers

diff  --git a/clang/include/clang/StaticAnalyzer/Checkers/Checkers.td 
b/clang/include/clang/StaticAnalyzer/Checkers/Checkers.td
index 2ba3881c6135..2d69d8f34420 100644
--- a/clang/include/clang/StaticAnalyzer/Checkers/Checkers.td
+++ b/clang/include/clang/StaticAnalyzer/Checkers/Checkers.td
@@ -1623,4 +1623,8 @@ let ParentPackage = WebKit in {
 def RefCntblBaseVirtualDtorChecker : Checker<"RefCntblBaseVirtualDtor">,
   HelpText<"Check for any ref-countable base class having virtual 
destructor.">,
   Documentation;
+
+def WebKitNoUncountedMemberChecker : Checker<"WebKitNoUncountedMemberChecker">,
+  HelpText<"Check for no uncounted member variables.">,
+  Documentation;
 } // end webkit

diff  --git a/clang/lib/StaticAnalyzer/Checkers/CMakeLists.txt 
b/clang/lib/StaticAnalyzer/Checkers/CMakeLists.txt
index 4f885fadf415..b3dc7a9f6321 100644
--- a/clang/lib/StaticAnalyzer/Checkers/CMakeLists.txt
+++ b/clang/lib/StaticAnalyzer/Checkers/CMakeLists.txt
@@ -121,6 +121,7 @@ add_clang_library(clangStaticAnalyzerCheckers
   VLASizeChecker.cpp
   ValistChecker.cpp
   VirtualCallChecker.cpp
+  WebKit/NoUncountedMembersChecker.cpp
   WebKit/PtrTypesSemantics.cpp
   WebKit/RefCntblBaseVirtualDtorChecker.cpp
 

diff  --git a/clang/lib/StaticAnalyzer/Checkers/WebKit/DiagOutputUtils.h 
b/clang/lib/StaticAnalyzer/Checkers/WebKit/DiagOutputUtils.h
index 4979b8ffc2b2..781a8d746001 100644
--- a/clang/lib/StaticAnalyzer/Checkers/WebKit/DiagOutputUtils.h
+++ b/clang/lib/StaticAnalyzer/Checkers/WebKit/DiagOutputUtils.h
@@ -23,6 +23,14 @@ void printQuotedQualifiedName(llvm::raw_ostream ,
   Os << "'";
 }
 
+template 
+void printQuotedName(llvm::raw_ostream , const NamedDeclDerivedT ) {
+  Os << "'";
+  D->getNameForDiagnostic(Os, D->getASTContext().getPrintingPolicy(),
+  /*Qualified=*/false);
+  Os << "'";
+}
+
 } // namespace clang
 
 #endif

diff  --git 
a/clang/lib/StaticAnalyzer/Checkers/WebKit/NoUncountedMembersChecker.cpp 
b/clang/lib/StaticAnalyzer/Checkers/WebKit/NoUncountedMembersChecker.cpp
new file mode 100644
index ..89caf602a17e
--- /dev/null
+++ b/clang/lib/StaticAnalyzer/Checkers/WebKit/NoUncountedMembersChecker.cpp
@@ -0,0 +1,150 @@
+//===- NoUncountedMembersChecker.cpp -*- C++ 
-*-==//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "ASTUtils.h"
+#include "DiagOutputUtils.h"
+#include "PtrTypesSemantics.h"
+#include "clang/AST/CXXInheritance.h"
+#include "clang/AST/Decl.h"
+#include "clang/AST/DeclCXX.h"
+#include "clang/AST/RecursiveASTVisitor.h"
+#include "clang/StaticAnalyzer/Checkers/BuiltinCheckerRegistration.h"
+#include "clang/StaticAnalyzer/Core/BugReporter/BugReporter.h"
+#include "clang/StaticAnalyzer/Core/BugReporter/BugType.h"
+#include "clang/StaticAnalyzer/Core/Checker.h"
+#include "llvm/ADT/DenseSet.h"
+#include "llvm/Support/Casting.h"
+
+using namespace clang;
+using namespace ento;
+
+namespace {
+
+class NoUncountedMemberChecker
+: public Checker> {
+private:
+  BugType Bug;
+  mutable BugReporter *BR;
+

[PATCH] D80685: [ASTMatchers] Add traversal-kind support to `DynTypedMatcher`

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel created this revision.
ymandel added reviewers: gribozavr, steveire.
Herald added a project: clang.

This patch exposes `TraversalKind` support in the `DynTypedMatcher` API. While
previously, the `match` method supported traversal logic, it was not possible to
set or get the traversal kind.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D80685

Files:
  clang/include/clang/ASTMatchers/ASTMatchersInternal.h
  clang/lib/ASTMatchers/ASTMatchersInternal.cpp
  clang/unittests/ASTMatchers/ASTMatchersInternalTest.cpp

Index: clang/unittests/ASTMatchers/ASTMatchersInternalTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersInternalTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersInternalTest.cpp
@@ -17,6 +17,7 @@
 
 namespace clang {
 namespace ast_matchers {
+using internal::DynTypedMatcher;
 
 #if GTEST_HAS_DEATH_TEST
 TEST(HasNameDeathTest, DiesOnEmptyName) {
@@ -171,6 +172,34 @@
   EXPECT_NE(nullptr, PT);
 }
 
+TEST(DynTypedMatcherTest, TraversalKindForwardsToImpl) {
+  auto M = DynTypedMatcher(decl());
+  EXPECT_FALSE(M.getTraversalKind().hasValue());
+
+  M = DynTypedMatcher(traverse(TK_AsIs, decl()));
+  llvm::Optional TK = M.getTraversalKind();
+  EXPECT_TRUE(TK.hasValue());
+  EXPECT_EQ(*TK, TK_AsIs);
+}
+
+TEST(DynTypedMatcherTest, ConstructWithTraversalKindSetsTK) {
+  auto M = DynTypedMatcher::constructWithTraversalKind(DynTypedMatcher(decl()),
+   TK_AsIs);
+  llvm::Optional TK = M.getTraversalKind();
+  EXPECT_TRUE(TK.hasValue());
+  EXPECT_EQ(*TK, TK_AsIs);
+}
+
+TEST(DynTypedMatcherTest, ConstructWithTraversalKindOverridesNestedTK) {
+  auto M = DynTypedMatcher::constructWithTraversalKind(DynTypedMatcher(decl()),
+   TK_AsIs);
+  auto M2 = DynTypedMatcher::constructWithTraversalKind(
+  M, TK_IgnoreUnlessSpelledInSource);
+  llvm::Optional TK = M2.getTraversalKind();
+  EXPECT_TRUE(TK.hasValue());
+  EXPECT_EQ(*TK, TK_IgnoreUnlessSpelledInSource);
+}
+
 TEST(IsInlineMatcher, IsInline) {
   EXPECT_TRUE(matches("void g(); inline void f();",
   functionDecl(isInline(), hasName("f";
Index: clang/lib/ASTMatchers/ASTMatchersInternal.cpp
===
--- clang/lib/ASTMatchers/ASTMatchersInternal.cpp
+++ clang/lib/ASTMatchers/ASTMatchersInternal.cpp
@@ -136,6 +136,31 @@
   }
 };
 
+/// A matcher that specifies a particular \c TraversalKind.
+///
+/// The kind provided to the constructor overrides any kind that may be
+/// specified by the `InnerMatcher`.
+class DynTraversalMatcherImpl : public DynMatcherInterface {
+public:
+  explicit DynTraversalMatcherImpl(
+  clang::TraversalKind TK,
+  IntrusiveRefCntPtr InnerMatcher)
+  : TK(TK), InnerMatcher(std::move(InnerMatcher)) {}
+
+  bool dynMatches(const DynTypedNode , ASTMatchFinder *Finder,
+  BoundNodesTreeBuilder *Builder) const override {
+return this->InnerMatcher->dynMatches(DynNode, Finder, Builder);
+  }
+
+  llvm::Optional TraversalKind() const override {
+return TK;
+  }
+
+private:
+  clang::TraversalKind TK;
+  IntrusiveRefCntPtr InnerMatcher;
+};
+
 } // namespace
 
 static llvm::ManagedStatic TrueMatcherInstance;
@@ -204,6 +229,14 @@
   return Copy;
 }
 
+DynTypedMatcher
+DynTypedMatcher::constructWithTraversalKind(DynTypedMatcher InnerMatcher,
+ast_type_traits::TraversalKind TK) {
+  InnerMatcher.Implementation =
+  new DynTraversalMatcherImpl(TK, std::move(InnerMatcher.Implementation));
+  return InnerMatcher;
+}
+
 DynTypedMatcher DynTypedMatcher::trueMatcher(ASTNodeKind NodeKind) {
   return DynTypedMatcher(NodeKind, NodeKind, &*TrueMatcherInstance);
 }
Index: clang/include/clang/ASTMatchers/ASTMatchersInternal.h
===
--- clang/include/clang/ASTMatchers/ASTMatchersInternal.h
+++ clang/include/clang/ASTMatchers/ASTMatchersInternal.h
@@ -379,6 +379,12 @@
   constructRestrictedWrapper(const DynTypedMatcher ,
  ASTNodeKind RestrictKind);
 
+  /// Creates a new matcher that is identical to the old one, but sets the
+  /// traversal kind. If `InnerMatcher` had already set a traversal kind, then
+  /// the new one overrides it.
+  static DynTypedMatcher
+  constructWithTraversalKind(DynTypedMatcher InnerMatcher, TraversalKind TK);
+
   /// Get a "true" matcher for \p NodeKind.
   ///
   /// It only checks that the node is of the right kind.
@@ -458,6 +464,14 @@
   /// If it is not compatible, then this matcher will never match anything.
   template  Matcher unconditionalConvertTo() const;
 
+  /// Returns the \c TraversalKind respected by calls to `match()`, if any.
+  ///
+  /// Most matchers will not have a traversal kind set, instead relying on the
+  /// surrounding context. For those, \c 

[PATCH] D80289: [Driver][X86] Support branch align options with LTO

[Kan Shengchen via Phabricator via cfe-commits]

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



Comment at: clang/test/Driver/x86-malign-branch.c:6
 // BOUNDARY: "-mllvm" "-x86-align-branch-boundary=16"
+// RUN: %clang -target x86_64-unknown-linux -malign-branch-boundary=16 -flto 
%s -### 2>&1 | FileCheck %s --check-prefix=BOUNDARY-LTO
+// BOUNDARY-LTO: "-plugin-opt=-x86-align-branch-boundary=16"

MaskRay wrote:
> Drop `-unknown-linux`
> 
> ditto below
Sorry it seems I didn't submit my comment...

Dropping `-unknown-linux`  here would get an error

```
 error: 'x86_64': unable to pass LLVM bit-code files to linker
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80289



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

[PATCH] D79800: [Sema] Implement DR2233

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

rsmith added a comment.

Unfortunately, I think this approach basically can't work, because we need to 
consider inheriting default arguments from a previous (or subsequent!) 
declaration before dropping default arguments preceding a pack. I think we will 
instead need to detect this situation when issuing the diagnostic for a 
parameter with a default argument followed by a parameter without one, and will 
need to make sure that all the parts of Clang that look at default arguments 
can cope with them being discontiguous.




Comment at: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp:1978
+
+// DR777, DR2233.
+// Parameter packs are allowed after and inbetween parameters with default

This code is only reached when substituting into non-member functions, so this 
change would not address the corresponding problem for member function 
templates or for member functions of class templates. It would be better to 
handle this in `InitFunctionInstantiation`, which is called for all function 
instantiations. (But as noted below, doing this during instantiation doesn't 
seem to be correct.)

In any case, we should have some testcases for member functions.



Comment at: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp:2090
 // as described in ActOnFriendFunctionDecl.
 SemaRef.LookupQualifiedName(Previous, DC->getRedeclContext());
 

We need to do this lookup and the merging below in `CheckFunctionDeclaration` 
before we drop any default arguments. Consider this pathological-but-valid 
testcase (that Clang currently accepts and the other compilers incorrectly 
reject):

```
template void f() {
void g(int, int = 0);
void g(int = 0, T...);
g();
}
void h() { f(); }
```

Here, we only find out that the second `g` redeclares the first one during 
instantiation, and only after that do we inherit the `=0` for the second 
parameter of the first `g` onto the second parameter of the second `g`.

And that's not even the worst testcase of this kind. Consider:

```
template void f() {
void g(int = 0, T...);
void g(int, int = 0);
g();
}
void h() { f(); }
```

This is valid under DR2233. The first declaration of `g` provides a default 
argument for the first parameter, the second provides a default argument for 
the second parameter, and the call to `g()` is valid because both parameters 
have default arguments. So it is not correct to discard the default arguments 
when instantiating the first declaration of `g`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79800



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

[PATCH] D80603: add isAtPosition narrowing matcher for parmVarDecl

[Vy Nguyen via Phabricator via cfe-commits]

oontvoo updated this revision to Diff 266714.
oontvoo added a comment.

use helper for examining the node instead of nested matchers


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80603

Files:
  clang/docs/LibASTMatchersReference.html
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/ASTMatchers/ASTMatchers.h
  clang/lib/AST/ASTContext.cpp
  clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp

Index: clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
@@ -2643,6 +2643,29 @@
   parmVarDecl(hasDefaultArgument(;
 }
 
+TEST(IsAtPosition, Basic) {
+  EXPECT_TRUE(matches("void x(int a) {}", parmVarDecl(isAtPosition(0;
+  EXPECT_TRUE(matches("void x(int a, int b) {}", parmVarDecl(isAtPosition(0;
+  EXPECT_TRUE(matches("void x(int a, int b) {}", parmVarDecl(isAtPosition(1;
+  EXPECT_TRUE(notMatches("void x(int val) {}", parmVarDecl(isAtPosition(1;
+
+  // Tests with function-decls
+  EXPECT_TRUE(matches("void x(int a);", parmVarDecl(isAtPosition(0;
+  EXPECT_TRUE(matches("void x(int a, int b);", parmVarDecl(isAtPosition(0;
+  EXPECT_TRUE(matches("void x(int a, int b);", parmVarDecl(isAtPosition(1;
+  EXPECT_TRUE(notMatches("void x(int val);", parmVarDecl(isAtPosition(1;
+
+  // Tests with lamdas
+  EXPECT_TRUE(
+  matches("void x() { [](int a) {};  }", parmVarDecl(isAtPosition(0;
+  EXPECT_TRUE(matches("void x() { [](int a, int b) {}; }",
+  parmVarDecl(isAtPosition(0;
+  EXPECT_TRUE(matches("void x() { [](int a, int b) {}; }",
+  parmVarDecl(isAtPosition(1;
+  EXPECT_TRUE(
+  notMatches("void x() { [](int val) {}; }", parmVarDecl(isAtPosition(1;
+}
+
 TEST(IsArray, Basic) {
   EXPECT_TRUE(matches("struct MyClass {}; MyClass *p1 = new MyClass[10];",
   cxxNewExpr(isArray(;
Index: clang/lib/AST/ASTContext.cpp
===
--- clang/lib/AST/ASTContext.cpp
+++ clang/lib/AST/ASTContext.cpp
@@ -10749,6 +10749,13 @@
   return I->second;
 }
 
+bool ASTContext::parameterHasIndex(const ParmVarDecl *D, unsigned index) const {
+  ParameterIndexTable::const_iterator I = ParamIndices.find(D);
+  if (I == ParamIndices.end())
+return false;
+  return I->second == index;
+}
+
 QualType ASTContext::getStringLiteralArrayType(QualType EltTy,
unsigned Length) const {
   // A C++ string literal has a const-qualified element type (C++ 2.13.4p1).
Index: clang/include/clang/ASTMatchers/ASTMatchers.h
===
--- clang/include/clang/ASTMatchers/ASTMatchers.h
+++ clang/include/clang/ASTMatchers/ASTMatchers.h
@@ -4615,6 +4615,27 @@
  InnerMatcher.matches(*DeclarationStatement, Finder, Builder);
 }
 
+/// Matches the ParmVarDecl nodes that are at the N'th position in the parameter
+/// list. The parameter list could be that of either a block, function, or
+/// objc-method.
+///
+///
+/// Given
+///
+/// \code
+/// void f(int a, int b, int c) {
+/// }
+/// \endcode
+///
+/// ``parmVarDecl(isAtPosition(0))`` matches ``int a``.
+///
+/// ``parmVarDecl(isAtPosition(1))`` matches ``int b``.
+AST_MATCHER_P(clang::ParmVarDecl, isAtPosition, unsigned, N) {
+  const clang::DeclContext *ParentContext = Node.getParentFunctionOrMethod();
+  return ParentContext != nullptr &&
+ ParentContext->getParentASTContext().parameterHasIndex(, N);
+}
+
 /// Matches the index expression of an array subscript expression.
 ///
 /// Given
Index: clang/include/clang/AST/ASTContext.h
===
--- clang/include/clang/AST/ASTContext.h
+++ clang/include/clang/AST/ASTContext.h
@@ -2795,6 +2795,10 @@
   /// index of the parameter when it exceeds the size of the normal bitfield.
   unsigned getParameterIndex(const ParmVarDecl *D) const;
 
+  // Returns "true" iff the given ParmVarDecl exists in this context at the
+  // given position.
+  bool parameterHasIndex(const ParmVarDecl *D, unsigned index) const;
+
   /// Return a string representing the human readable name for the specified
   /// function declaration or file name. Used by SourceLocExpr and
   /// PredefinedExpr to cache evaluated results.
Index: clang/docs/LibASTMatchersReference.html
===
--- clang/docs/LibASTMatchersReference.html
+++ clang/docs/LibASTMatchersReference.html
@@ -4671,6 +4671,23 @@
 Usable as: Matcherhttps://clang.llvm.org/doxygen/classclang_1_1FunctionDecl.html;>FunctionDecl, Matcherhttps://clang.llvm.org/doxygen/classclang_1_1VarDecl.html;>VarDecl, 

[PATCH] D79800: [Sema] Implement DR2233

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

A couple of minor requests.  Otherwise this looks good to me, although I really 
would like @rsmith to sign off on this approach, especially given his 
involvement with the DRs.




Comment at: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp:1985
+// pack is expanded the user must've provided arguments for all parameters
+// before it.
+FunctionDecl *TemplatedDecl = FunctionTemplate->getTemplatedDecl();

There should be a space in "in between", or just use "between".

I don't think the line about "if a parameter pack is expanded..." is true as 
written.  What you're trying to say is something like "It's okay to remove 
earlier default arguments because the expanded parameters are required to have 
matching arguments, which they only can if all the earlier parameters have 
arguments as well."


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79800



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

[PATCH] D80315: Fix CC1 command line options mapping into fast-math flags.

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In D80315#2058735 , @michele.scandale 
wrote:

> In D80315#2058549 , @rjmccall wrote:
>
> > The code cleanups all seems reasonable.  The actual changes in 
> > code-generation changes are because we were failing to set these reliably?
>
>
> Most of them yes.
>
> In the CUDA test we there is now `contract` because we honor the default 
> contraction mode that for CUDA is set to fast.


Right, and we weren't honoring that mode before?

> In `clang/test/CodeGen/complex-math.c` I've added `-ffp-contract=fast` to the 
> command line option because `-ffast-math` at the CC1 level does not change 
> the default contraction mode.

Oh, I see, makes sense.  So there was inconsistent treatment of the options, 
where one thing observed it but others didn't, and that's been fixed now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80315



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

[PATCH] D80681: [clang][SourceManager] cache Macro Expansions

[Nick Desaulniers via Phabricator via cfe-commits]

nickdesaulniers created this revision.
nickdesaulniers added reviewers: rsmith, bkramer.
Herald added subscribers: cfe-commits, jfb, kristof.beyls.
Herald added a project: clang.

A seemingly innocuous Linux kernel change [0] seemingly blew up our
compile times by over 3x, as reported by @nathanchance in [1].

The code in question uses a doubly nested macro containing GNU C
statement expressions that are then passed to typeof(), which is then
used in a very important macro for atomic variable access throughout
most of the kernel. The inner most macro, is passed a GNU C statement
expression.  In this case, we have macro arguments that are GNU C
statement expressions, which can contain a significant number of tokens.
The upstream kernel patch caused significant build time regressions for
both Clang and GCC. Since then, some of the nesting has been removed via
@melver, which helps gain back most of the lost compilation time. [2]

Profiles collected [3] from compilations of the slowest TU for us in the
kernel show:

- 51.4% time spent in clang::TokenLexer::updateLocForMacroArgTokens
- 48.7% time spent in clang::SourceManager::getFileIDLocal
- 35.5% time spent in clang::SourceManager::isOffsetInFileID

(mostly calls from the former through to the latter).

So it seems we have a pathological case for which properly tracking the
SourceLocation of macro arguments is significantly harming build
performance. This stands out in referenced flame graph.

In fact, this case was identified previously as being problematic in
commit 3339c568c4 ("[Lex] Speed up updateConsecutiveMacroArgTokens (NFC)")

Looking at the above call chain, there's 3 things we can do to speed up
this case.

1. TokenLexer::updateConsecutiveMacroArgTokens() calls 
SourceManager::isWrittenInSameFile() which calls SourceManager::getFileID(), 
which is both very hot and very expensive to call. SourceManger has a one entry 
cache, member LastFileIDLookup. If that isn't the FileID for a give source 
location offset, we fall back to a linear probe, and then to a binary search 
for the FileID. These fallbacks update the one entry cache, but noticeably they 
do not for the case of macro expansions!

  For the slowest TU to compile in the Linux kernel, it seems that we miss 
about 78.67% of the 68 million queries we make to getFileIDLocal that we could 
have had cache hits for, had we saved the macro expansion source location's 
FileID in the one entry cache. [4]

  I tried adding a separate cache item for macro expansions, and to check that 
before the linear then binary search fallbacks, but did not find it faster than 
simply allowing macro expansions into the one item cache.  This alone nets us 
back a lot of the performance loss.

  That said, this is a modification of caching logic, which is playing with a 
double edged sword.  While it significantly improves the pathological case, its 
hard to say that there's not an equal but opposite pathological case that isn't 
regressed by this change. Though non-pathological cases of builds of the Linux 
kernel before [0] are only slightly improved (<1%) and builds of LLVM itself 
don't change due to this patch.

  Should future travelers find this change to significantly harm their build 
times, I encourage them to feel empowered to revert this change.

2. SourceManager::getFileIDLocal has a FIXME hinting that the call to 
SourceManager::isOffsetInFileID could be made much faster since 
isOffsetInFileID is generic in the sense that it tries to handle the more 
generic case of "local" (as opposed to "loaded") files, though the caller has 
already determined the file to be local. This patch implements a new method 
that specialized for use when the caller already knows the file is local, then 
use that in TokenLexer::updateLocForMacroArgTokens.  This should be less 
controversial than 1, and is likely an across the board win. It's much less 
significant for the pathological case, but still a measurable win once we have 
fallen to the final case of binary search.

3. A bunch of methods in SourceManager take a default argument. 
SourceManager::getLocalSLocEntry doesn't do anything with this argument, yet 
many callers of getLocalSLocEntry setup, pass, then check this argument. This 
is wasted work. We can't remove the parameter outright, as it's part of an 
interface expected by getInclusions() in libclang.

With this patch applied, the above profile [5] for the same pathological
input looks like:

- 25.1% time spent in clang::TokenLexer::updateLocForMacroArgTokens
- 17.2% time spent in clang::SourceManager::getFileIDLocal

and clang::SourceManager::isOffsetInFileID is no longer called, and thus
falls out of the profile.

There may be further improvements to the general problem of "what
interval contains one number out of millions" than the current use of a
one item cache, followed by linear probing, followed by binary
searching. We might even be able to do something smarter in

Buildbot numbers for the week of 05/17/2020 - 05/23/2020

[Galina Kistanova via cfe-commits]

Hello everyone,

Below are some buildbot numbers for the last week of 05/17/2020 -
05/23/2020.

Please see the same data in attached csv files:

The longest time each builder was red during the week;
"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green);
Count of commits by project;
Number of completed builds, failed builds and average build time for
successful builds per active builder;
Average waiting time for a revision to get build result per active builder
(response time).

Thanks

Galina


The longest time each builder was red during the week:
  buildername  |  was_red
---+--
 llvm-sphinx-docs  | 135:14:21
 sanitizer-x86_64-linux| 109:51:18
 sanitizer-windows | 58:52:18
 libcxx-libcxxabi-libunwind-armv8-linux| 42:43:01
 libcxx-libcxxabi-libunwind-armv7-linux| 41:16:16
 libcxx-libcxxabi-libunwind-armv7-linux-noexceptions   | 41:08:38
 libcxx-libcxxabi-libunwind-armv8-linux-noexceptions   | 39:28:10
 libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions | 33:14:48
 libcxx-libcxxabi-libunwind-aarch64-linux  | 33:07:18
 clang-cmake-armv7-selfhost-neon   | 24:18:39
 clang-cmake-armv7-selfhost| 23:51:36
 clang-cmake-armv8-lld | 23:32:13
 sanitizer-x86_64-linux-android| 22:48:06
 clang-ppc64le-linux   | 22:06:29
 clang-ppc64le-linux-lnt   | 21:04:38
 clang-ppc64le-linux-multistage| 20:36:42
 sanitizer-ppc64le-linux   | 20:36:37
 sanitizer-x86_64-linux-autoconf   | 20:02:40
 clang-cmake-armv7-full| 19:57:11
 clang-with-thin-lto-ubuntu| 19:56:15
 clang-s390x-linux-lnt | 18:10:27
 clang-ppc64be-linux-multistage| 18:10:26
 clang-ppc64be-linux-lnt   | 18:03:35
 clang-s390x-linux | 17:57:12
 clang-ppc64be-linux   | 17:50:34
 clang-cmake-thumbv7-full-sh   | 17:10:59
 llvm-clang-win-x-armv7l   | 16:02:35
 clang-x64-windows-msvc| 12:51:37
 sanitizer-x86_64-linux-bootstrap-msan | 12:39:59
 clang-with-lto-ubuntu | 12:32:36
 sanitizer-x86_64-linux-fast   | 12:31:20
 llvm-clang-x86_64-expensive-checks-win| 12:30:41
 sanitizer-x86_64-linux-bootstrap-ubsan| 12:28:31
 fuchsia-x86_64-linux  | 12:26:09
 sanitizer-ppc64be-linux   | 12:11:55
 sanitizer-x86_64-linux-bootstrap  | 11:52:36
 ppc64le-lld-multistage-test   | 11:33:27
 clang-s390x-linux-multistage  | 11:20:51
 lldb-x64-windows-ninja| 10:34:12
 lldb-x86_64-debian| 09:49:02
 mlir-windows  | 08:39:13
 flang-aarch64-ubuntu  | 07:45:24
 mlir-nvidia   | 07:09:43
 lldb-arm-ubuntu   | 06:50:32
 clang-cmake-aarch64-lld   | 06:49:27
 clang-cmake-aarch64-global-isel   | 04:49:52
 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast  | 03:49:33
 aosp-O3-polly-before-vectorizer-unprofitable  | 03:44:05
 clang-cmake-armv7-global-isel | 03:29:37
 clang-cmake-aarch64-full  | 03:28:38
 clang-cmake-aarch64-quick | 03:27:21
 llvm-avr-linux| 03:22:21
 lldb-aarch64-ubuntu   | 03:05:14
 clang-cmake-x86_64-avx2-linux | 02:38:23
 llvm-clang-win-x-aarch64  | 02:26:50
 clang-cmake-armv7-quick   | 02:15:36
 sanitizer-x86_64-linux-fuzzer | 02:15:10
 polly-arm-linux   | 01:49:06
 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast| 01:44:35
 libc-x86_64-debian-dbg| 01:41:25
 clang-x86_64-debian-fast  | 01:35:30
 lld-x86_64-win| 01:24:16
 clang-x86_64-debian-new-pass-manager-fast | 01:22:13
 clang-ppc64le-rhel| 01:11:20
 

Buildbot numbers for the week of 05/10/2020 - 05/16/2020

[Galina Kistanova via cfe-commits]

Hello everyone,

Below are some buildbot numbers for the week of 05/10/2020 - 05/16/2020.

Please see the same data in attached csv files:

The longest time each builder was red during the week;
"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green);
Count of commits by project;
Number of completed builds, failed builds and average build time for
successful builds per active builder;
Average waiting time for a revision to get build result per active builder
(response time).

Thanks

Galina


The longest time each builder was red during the week:
  buildername  |  was_red
---+--
 clang-native-arm-lnt-perf | 115:00:42
 clang-cmake-armv7-full| 52:54:20
 libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions | 45:19:28
 libcxx-libcxxabi-libunwind-aarch64-linux  | 45:17:38
 libcxx-libcxxabi-libunwind-armv8-linux| 45:13:14
 libcxx-libcxxabi-libunwind-armv8-linux-noexceptions   | 45:12:35
 libcxx-libcxxabi-libunwind-armv7-linux-noexceptions   | 44:45:08
 libcxx-libcxxabi-x86_64-linux-ubuntu-ubsan| 44:36:40
 libcxx-libcxxabi-singlethreaded-x86_64-linux-debian   | 44:01:32
 libcxx-libcxxabi-libunwind-armv7-linux| 42:45:49
 clang-cmake-thumbv7-full-sh   | 39:22:01
 fuchsia-x86_64-linux  | 27:20:00
 llvm-clang-win-x-armv7l   | 20:50:33
 clang-cmake-armv8-lld | 15:02:48
 clang-cmake-armv7-global-isel | 14:32:55
 clang-cmake-aarch64-full  | 14:16:55
 clang-cmake-armv7-selfhost| 14:00:07
 clang-cmake-aarch64-global-isel   | 13:14:41
 clang-cmake-aarch64-lld   | 12:49:53
 clang-cmake-aarch64-quick | 12:21:30
 clang-cmake-armv7-quick   | 12:17:46
 flang-aarch64-ubuntu  | 12:10:52
 llvm-clang-win-x-aarch64  | 12:10:50
 clang-cmake-armv7-selfhost-neon   | 10:36:01
 clang-ppc64le-linux-multistage| 10:30:46
 sanitizer-x86_64-linux-bootstrap  | 09:08:16
 llvm-avr-linux| 08:57:20
 sanitizer-x86_64-linux-fast   | 08:42:02
 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast  | 08:07:55
 clang-x64-windows-msvc| 08:07:54
 clang-s390x-linux-multistage  | 07:49:46
 clang-s390x-linux-lnt | 06:47:03
 clang-with-thin-lto-ubuntu| 06:43:07
 clang-ppc64be-linux-multistage| 06:38:30
 lld-x86_64-win| 06:36:57
 llvm-clang-x86_64-expensive-checks-win| 06:36:28
 clang-cmake-x86_64-avx2-linux | 06:31:03
 clang-ppc64be-linux-lnt   | 06:30:51
 clang-s390x-linux | 06:26:17
 clang-ppc64le-linux-lnt   | 06:13:29
 mlir-windows  | 06:11:52
 clang-ppc64be-linux   | 06:06:29
 clang-ppc64le-linux   | 06:05:02
 clang-cmake-armv7-lnt | 05:58:16
 llvm-clang-x86_64-expensive-checks-ubuntu | 05:54:54
 lld-x86_64-ubuntu-fast| 05:53:26
 clang-cmake-x86_64-sde-avx512-linux   | 05:49:18
 clang-with-lto-ubuntu | 05:31:14
 polly-x86_64-linux| 05:01:16
 sanitizer-ppc64le-linux   | 04:19:13
 sanitizer-x86_64-linux| 04:04:34
 libcxx-libcxxabi-x86_64-linux-ubuntu-asan | 03:55:35
 polly-arm-linux   | 03:35:43
 clang-x86_64-linux-abi-test   | 03:17:51
 aosp-O3-polly-before-vectorizer-unprofitable  | 03:13:19
 sanitizer-ppc64be-linux   | 03:00:55
 lldb-x64-windows-ninja| 02:58:27
 lldb-x86_64-debian| 02:55:59
 lldb-aarch64-ubuntu   | 02:49:34
 lld-x86_64-darwin | 02:15:12
 sanitizer-x86_64-linux-bootstrap-ubsan| 01:54:43
 clang-x86_64-debian-new-pass-manager-fast | 01:53:47
 clang-x86_64-debian-fast  | 01:50:40
 sanitizer-x86_64-linux-bootstrap-msan | 01:49:38
 

Buildbot numbers for the week of 05/3/2020 - 05/9/2020

[Galina Kistanova via cfe-commits]

Hello everyone,

Below are some buildbot numbers for the week of 05/3/2020 - 05/9/2020.

Please see the same data in attached csv files:

The longest time each builder was red during the week;
"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green);
Count of commits by project;
Number of completed builds, failed builds and average build time for
successful builds per active builder;
Average waiting time for a revision to get build result per active builder
(response time).

Thanks

Galina


The longest time each builder was red during the week:
  buildername  | was_red
---+-
 clang-cmake-aarch64-lld   | 78:19:10
 clang-cmake-aarch64-full  | 76:57:25
 clang-cmake-aarch64-quick | 75:12:58
 clang-cmake-aarch64-global-isel   | 74:24:22
 llvm-clang-x86_64-expensive-checks-win| 62:04:51
 clang-ppc64le-linux-lnt   | 61:19:44
 lld-x86_64-win| 60:34:02
 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast  | 59:50:54
 libcxx-libcxxabi-libunwind-armv7-linux-noexceptions   | 53:58:49
 libcxx-libcxxabi-libunwind-armv8-linux| 48:44:52
 libcxx-libcxxabi-libunwind-armv8-linux-noexceptions   | 48:44:27
 libcxx-libcxxabi-libunwind-aarch64-linux  | 48:40:43
 libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions | 48:39:42
 libcxx-libcxxabi-libunwind-armv7-linux| 47:35:41
 sanitizer-x86_64-linux-bootstrap-ubsan| 44:58:31
 sanitizer-x86_64-linux-fast   | 44:40:25
 libcxx-libcxxabi-x86_64-linux-ubuntu-asan | 27:24:18
 libcxx-libcxxabi-singlethreaded-x86_64-linux-debian   | 24:27:43
 sanitizer-x86_64-linux-bootstrap  | 22:29:54
 llvm-clang-win-x-armv7l   | 21:07:28
 sanitizer-x86_64-linux-bootstrap-msan | 20:39:56
 fuchsia-x86_64-linux  | 20:15:54
 lldb-x64-windows-ninja| 20:05:22
 clang-cmake-armv7-full| 18:55:44
 clang-cmake-thumbv7-full-sh   | 16:41:34
 sanitizer-x86_64-linux| 06:54:53
 mlir-nvidia   | 06:08:57
 clang-ppc64le-linux-multistage| 06:02:00
 clang-x64-windows-msvc| 05:30:03
 lld-x86_64-ubuntu-fast| 04:57:29
 clang-cmake-armv8-lld | 04:52:43
 llvm-clang-x86_64-expensive-checks-ubuntu | 04:50:56
 llvm-clang-win-x-aarch64  | 04:44:41
 clang-with-lto-ubuntu | 04:38:27
 ppc64le-lld-multistage-test   | 04:35:32
 mlir-windows  | 04:28:22
 aosp-O3-polly-before-vectorizer-unprofitable  | 04:17:13
 sanitizer-ppc64le-linux   | 04:09:43
 clang-with-thin-lto-ubuntu| 03:52:09
 clang-cmake-x86_64-avx2-linux | 03:38:21
 clang-cmake-armv7-selfhost| 03:32:17
 lld-x86_64-freebsd| 03:31:19
 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast| 03:30:02
 clang-cmake-x86_64-sde-avx512-linux   | 03:30:01
 lld-x86_64-darwin | 03:29:54
 clang-x86_64-debian-new-pass-manager-fast | 03:29:49
 clang-x86_64-debian-fast  | 03:29:48
 llvm-clang-x86_64-expensive-checks-debian | 03:29:39
 clang-cmake-armv7-selfhost-neon   | 03:22:26
 llvm-avr-linux| 03:21:25
 clang-s390x-linux | 03:16:56
 clang-ppc64be-linux-multistage| 03:15:51
 clang-cmake-armv7-quick   | 03:09:15
 clang-ppc64le-linux   | 03:05:14
 clang-s390x-linux-lnt | 03:00:23
 libc-x86_64-debian-asan   | 02:45:01
 clang-cmake-armv7-global-isel | 02:33:28
 sanitizer-windows | 02:19:14
 openmp-gcc-x86_64-linux-debian| 02:19:01
 lldb-aarch64-ubuntu   | 02:14:16
 lldb-x86_64-debian| 02:14:00
 clang-ppc64be-linux-lnt   | 02:01:54
 polly-arm-linux   | 01:55:19
 clang-cmake-armv7-lnt | 01:51:34
 

Buildbot numbers for the week of 04/26/2020 - 05/2/2020

[Galina Kistanova via cfe-commits]

Hello everyone,

Below are some buildbot numbers for the week of 04/26/2020 - 05/2/2020.

Please see the same data in attached csv files:

The longest time each builder was red during the week;
"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green);
Count of commits by project;
Number of completed builds, failed builds and average build time for
successful builds per active builder;
Average waiting time for a revision to get build result per active builder
(response time).

Thanks

Galina


The longest time each builder was red during the week:
   buildername   | was_red
-+-
 clang-x64-windows-msvc  | 84:56:43
 llvm-avr-linux  | 83:24:47
 clang-s390x-linux-multistage| 57:50:34
 clang-s390x-linux-lnt   | 57:19:52
 clang-s390x-linux   | 57:10:56
 clang-cmake-armv8-lld   | 49:09:33
 llvm-clang-x86_64-expensive-checks-win  | 46:44:00
 clang-cmake-aarch64-lld | 29:01:06
 libcxx-libcxxabi-libunwind-armv8-linux-noexceptions | 24:59:31
 sanitizer-x86_64-linux-bootstrap-ubsan  | 24:50:37
 libcxx-libcxxabi-libunwind-armv8-linux  | 24:43:57
 libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions   | 24:21:35
 libcxx-libcxxabi-libunwind-aarch64-linux| 24:04:50
 sanitizer-x86_64-linux-fast | 23:09:35
 ppc64le-lld-multistage-test | 21:12:02
 llvm-clang-win-x-armv7l | 20:51:58
 clang-cmake-thumbv7-full-sh | 20:38:44
 clang-cmake-x86_64-sde-avx512-linux | 20:00:58
 clang-cmake-x86_64-avx2-linux   | 18:50:44
 libcxx-libcxxabi-x86_64-linux-ubuntu-asan   | 17:30:16
 llvm-clang-x86_64-expensive-checks-debian   | 16:10:08
 llvm-clang-x86_64-expensive-checks-ubuntu   | 16:09:50
 mlir-windows| 14:45:52
 clang-cmake-armv7-selfhost-neon | 13:37:35
 clang-cmake-aarch64-global-isel | 11:56:24
 clang-ppc64le-linux-multistage  | 11:42:43
 clang-ppc64le-linux | 10:44:20
 sanitizer-ppc64le-linux | 10:20:09
 sanitizer-x86_64-linux  | 09:34:43
 libcxx-libcxxabi-x86_64-linux-ubuntu-ubsan  | 08:31:23
 libcxx-libcxxabi-x86_64-linux-ubuntu-msan   | 08:22:55
 sanitizer-x86_64-linux-autoconf | 08:16:31
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx17  | 07:58:36
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx2a  | 07:52:13
 clang-ppc64le-rhel  | 07:34:23
 clang-ppc64le-linux-lnt | 07:22:11
 sanitizer-ppc64be-linux | 07:21:53
 clang-hexagon-elf   | 07:01:43
 clang-ppc64be-linux-lnt | 06:41:21
 clang-x86_64-debian-fast| 06:39:39
 clang-x86_64-debian-new-pass-manager-fast   | 06:37:49
 clang-cmake-aarch64-quick   | 06:35:29
 clang-cmake-aarch64-full| 06:04:13
 clang-ppc64be-linux-multistage  | 06:02:05
 libcxx-libcxxabi-libunwind-armv7-linux  | 05:53:31
 libcxx-libcxxabi-libunwind-armv7-linux-noexceptions | 05:52:37
 clang-cmake-armv7-full  | 05:49:48
 sanitizer-x86_64-linux-bootstrap| 05:33:48
 clang-cmake-armv7-selfhost  | 05:16:33
 clang-cmake-armv7-global-isel   | 05:13:11
 clang-with-lto-ubuntu   | 05:09:38
 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast  | 04:59:03
 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast| 04:54:25
 clang-cmake-armv7-quick | 04:47:27
 clang-ppc64be-linux | 04:42:09
 clang-with-thin-lto-ubuntu  | 04:41:37
 fuchsia-x86_64-linux| 03:53:09
 aosp-O3-polly-before-vectorizer-unprofitable| 03:47:55
 llvm-clang-win-x-aarch64| 03:37:52
 sanitizer-x86_64-linux-bootstrap-msan   | 03:28:52
 publish-sphinx-docs | 03:09:14
 polly-arm-linux | 02:37:19
 lld-x86_64-freebsd  

[clang] 00e5d38 - Do not warn that an expression of the form (void)arr; is unused when

[Richard Smith via cfe-commits]

Author: Richard Smith
Date: 2020-05-27T17:26:29-07:00
New Revision: 00e5d38d40162d049f67b436ad42c9d05092e65c

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

LOG: Do not warn that an expression of the form (void)arr; is unused when
arr is a volatile non-local array.

This fixes a recent regression exposed by removing lvalue-to-rvalue
conversion of discarded volatile arrays. In passing, regularize the
rules we use to determine whether '(void)expr;' warns when expr is a
volatile glvalue.

Added: 


Modified: 
clang/include/clang/AST/Expr.h
clang/lib/AST/Expr.cpp
clang/lib/Sema/SemaExprCXX.cpp
clang/test/SemaCXX/warn-unused-value.cpp

Removed: 




diff  --git a/clang/include/clang/AST/Expr.h b/clang/include/clang/AST/Expr.h
index 0ca4941789e7..deca0b82c4e3 100644
--- a/clang/include/clang/AST/Expr.h
+++ b/clang/include/clang/AST/Expr.h
@@ -232,6 +232,11 @@ class Expr : public ValueStmt {
   /// a problem with a generic expression.
   SourceLocation getExprLoc() const LLVM_READONLY;
 
+  /// Determine whether an lvalue-to-rvalue conversion should implicitly be
+  /// applied to this expression if it appears as a discarded-value expression
+  /// in C++11 onwards. This applies to certain forms of volatile glvalues.
+  bool isReadIfDiscardedInCPlusPlus11() const;
+
   /// isUnusedResultAWarning - Return true if this immediate expression should
   /// be warned about if the result is unused.  If so, fill in expr, location,
   /// and ranges with expr to warn on and source locations/ranges appropriate

diff  --git a/clang/lib/AST/Expr.cpp b/clang/lib/AST/Expr.cpp
index 4c175fff6421..feb0517204c4 100644
--- a/clang/lib/AST/Expr.cpp
+++ b/clang/lib/AST/Expr.cpp
@@ -2267,6 +2267,64 @@ Stmt *BlockExpr::getBody() {
 // Generic Expression Routines
 
//===--===//
 
+bool Expr::isReadIfDiscardedInCPlusPlus11() const {
+  // In C++11, discarded-value expressions of a certain form are special,
+  // according to [expr]p10:
+  //   The lvalue-to-rvalue conversion (4.1) is applied only if the
+  //   expression is an lvalue of volatile-qualified type and it has
+  //   one of the following forms:
+  if (!isGLValue() || !getType().isVolatileQualified())
+return false;
+
+  const Expr *E = IgnoreParens();
+
+  //   - id-expression (5.1.1),
+  if (isa(E))
+return true;
+
+  //   - subscripting (5.2.1),
+  if (isa(E))
+return true;
+
+  //   - class member access (5.2.5),
+  if (isa(E))
+return true;
+
+  //   - indirection (5.3.1),
+  if (auto *UO = dyn_cast(E))
+if (UO->getOpcode() == UO_Deref)
+  return true;
+
+  if (auto *BO = dyn_cast(E)) {
+//   - pointer-to-member operation (5.5),
+if (BO->isPtrMemOp())
+  return true;
+
+//   - comma expression (5.18) where the right operand is one of the above.
+if (BO->getOpcode() == BO_Comma)
+  return BO->getRHS()->isReadIfDiscardedInCPlusPlus11();
+  }
+
+  //   - conditional expression (5.16) where both the second and the third
+  // operands are one of the above, or
+  if (auto *CO = dyn_cast(E))
+return CO->getTrueExpr()->isReadIfDiscardedInCPlusPlus11() &&
+   CO->getFalseExpr()->isReadIfDiscardedInCPlusPlus11();
+  // The related edge case of "*x ?: *x".
+  if (auto *BCO =
+  dyn_cast(E)) {
+if (auto *OVE = dyn_cast(BCO->getTrueExpr()))
+  return OVE->getSourceExpr()->isReadIfDiscardedInCPlusPlus11() &&
+ BCO->getFalseExpr()->isReadIfDiscardedInCPlusPlus11();
+  }
+
+  // Objective-C++ extensions to the rule.
+  if (isa(E) || isa(E))
+return true;
+
+  return false;
+}
+
 /// isUnusedResultAWarning - Return true if this immediate expression should
 /// be warned about if the result is unused.  If so, fill in Loc and Ranges
 /// with location to warn on and the source range[s] to report with the
@@ -2555,20 +2613,31 @@ bool Expr::isUnusedResultAWarning(const Expr *, 
SourceLocation ,
   }
   case CXXFunctionalCastExprClass:
   case CStyleCastExprClass: {
-// Ignore an explicit cast to void unless the operand is a non-trivial
-// volatile lvalue.
+// Ignore an explicit cast to void, except in C++98 if the operand is a
+// volatile glvalue for which we would trigger an implicit read in any
+// other language mode. (Such an implicit read always happens as part of
+// the lvalue conversion in C, and happens in C++ for expressions of all
+// forms where it seems likely the user intended to trigger a volatile
+// load.)
 const CastExpr *CE = cast(this);
+const Expr *SubE = CE->getSubExpr()->IgnoreParens();
 if (CE->getCastKind() == CK_ToVoid) {
-  if (CE->getSubExpr()->isGLValue() &&
-  

[PATCH] D80660: clang: Add support for relative linker paths with -fuse-ld

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added inline comments.



Comment at: clang/test/Driver/fuse-ld.c:7
 
+// RUN: cd "%S" && %clang %s -### \
+// RUN: -fuse-ld=Inputs/fuse_ld_windows/ld.foo.exe 2>&1 \

This changes the working directory. It may be better moving cd tests to the 
bottom.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80660



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

[PATCH] D80669: [analyzer] LoopWidening: fix crash by avoiding aliased references invalidation

[Artem Dergachev via Phabricator via cfe-commits]

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

Fair!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80669



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

[PATCH] D69764: [clang-format] Add East/West Const fixer capability

[Marek Kurdej via Phabricator via cfe-commits]

curdeius added a comment.

One last thought, how about making the config a bit more future-proof and 
instead of `ConstPlacement` accept what was discussed some time ago:

  QualifierStyle:
 -   const: Right

and restrict it to `const` for the moment?
Maybe renaming to `QualifierPlacement` or something more appropriate.


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

https://reviews.llvm.org/D69764



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

[PATCH] D79378: PR34581: Don't remove an 'if (p)' guarding a call to 'operator delete(p)' under -Oz.

[Diogo N. Sampaio via Phabricator via cfe-commits]

dnsampaio added a comment.

Hi @rsmith,
are you still looking into this?
cheers


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79378



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

[PATCH] D69764: [clang-format] Add East/West Const fixer capability

[Marek Kurdej via Phabricator via cfe-commits]

curdeius added inline comments.



Comment at: clang/docs/ReleaseNotes.rst:359
 
+- Option ``ConstPlacement`` has been added auto-arrange the positioning of 
const
+  in variable and parameter declarations to be ``Right/East`` const or 
``Left/West`` 

It sounds strange as if you wanted to write "[in order] to auto-arrange".



Comment at: clang/lib/Format/EastWestConstFixer.cpp:83
+  // Change `const int` to be `int const`.
+  std::string NewType;
+  NewType += Second->TokenText;

Nit: `NewType` may be misleading when reading. Why not `NewText` as above?



Comment at: clang/lib/Format/EastWestConstFixer.cpp:130
+
+static void swapFourTokens(const SourceManager ,
+ tooling::Replacements ,

These functions seem a bit ugly... and very specific. And they both look like 
rotate left/right. Couldn't it be a single function taking a 
range/span/collection of FormatTokens?



Comment at: clang/lib/Format/EastWestConstFixer.cpp:136
+ const FormatToken *Fourth, 
+ bool West) {
+  // e.g. Change `const unsigned long long` to be `unsigned long long const`.

Nit: West doesn't seem appropriate as a name at the level of this function as 
you rather don't move elements west/east but left/right. Of course, that 
applies only if you share my view that it's sort of rotate algorithm.



Comment at: clang/lib/Format/EastWestConstFixer.cpp:171
+return false;
+  return (Tok->isSimpleTypeSpecifier() ||
+  Tok->isOneOf(tok::kw_volatile, tok::kw_auto));

Parentheses seem to be unnecessary.



Comment at: clang/lib/Format/EastWestConstFixer.cpp:171
+return false;
+  return (Tok->isSimpleTypeSpecifier() ||
+  Tok->isOneOf(tok::kw_volatile, tok::kw_auto));

curdeius wrote:
> Parentheses seem to be unnecessary.
Stupid question, are both const and restrict handled here?



Comment at: clang/lib/Format/EastWestConstFixer.cpp:175
+
+// If a token is an identifier and its upper case it could
+// be a macro and hence we need to be able to ignore it

Typo: its -> it's.
Missing comma before "it could".



Comment at: clang/lib/Format/EastWestConstFixer.cpp:176
+// If a token is an identifier and its upper case it could
+// be a macro and hence we need to be able to ignore it
+static bool isPossibleMacro(const FormatToken *Tok)

Missing dot at the end.



Comment at: clang/lib/Format/EastWestConstFixer.cpp:195
+FormatToken *Tok) {
+  // We only need to think about streams that begin with const.
+  if (!Tok->is(tok::kw_const)) {

Why? What about `unsigned const int`?



Comment at: clang/lib/Format/EastWestConstFixer.cpp:208
+
+  if (isCVQualifierOrType(Tok->Next) && isCVQualifierOrType(Tok->Next->Next) 
&& isCVQualifierOrType(Tok->Next->Next->Next)) {
+swapFourTokens(SourceMgr, Fixes, Tok, Tok->Next, Tok->Next->Next, 
Tok->Next->Next->Next,

I think that this code asks for a cleanup. And if we needed to look for five 
tokens...?



Comment at: clang/lib/Format/EastWestConstFixer.cpp:213
+  }
+  if (isCVQualifierOrType(Tok->Next) && Tok->Next->Next &&
+  isCVQualifierOrType(Tok->Next->Next)) {

Shouldn't it be `else if`?



Comment at: clang/lib/Format/EastWestConstFixer.cpp:223
+ Tok->Next->is(tok::kw_auto)) {
+// The basic case  `const int` -> `int const`
+swapTwoTokens(SourceMgr, Fixes, Tok, Tok->Next);

Nits: double space, missing ending dot.



Comment at: clang/lib/Format/EastWestConstFixer.cpp:225
+swapTwoTokens(SourceMgr, Fixes, Tok, Tok->Next);
+
+  } else if (Tok->startsSequence(tok::kw_const, tok::identifier,

Nit: unnecessary blank line.



Comment at: clang/lib/Format/EastWestConstFixer.cpp:228
+ TT_TemplateOpener)) {
+// Read from to the end of the TemplateOpener to
+// TemplateCloser const ArrayRef a; const ArrayRef 

"from to the end"?



Comment at: clang/lib/Format/EastWestConstFixer.cpp:244
+  removeToken(SourceMgr, Fixes, Tok);
+  //return EndTemplate->Next;
+  return Tok;

Forgotten remnants?



Comment at: clang/lib/Format/EastWestConstFixer.cpp:383
+while (Tok && Tok != Last) {
+  if (!Tok->Next) {
+break;

It's a matter of taste, but this condition could be moved into the while 
condition above.



Comment at: clang/lib/Format/EastWestConstFixer.cpp:387
+  if (Tok->is(tok::comment)) {
+Tok = Tok->Next;
+continue;

You 

[PATCH] D80315: Fix CC1 command line options mapping into fast-math flags.

[Michele Scandale via Phabricator via cfe-commits]

michele.scandale added a comment.

In D80315#2058549 , @rjmccall wrote:

> The code cleanups all seems reasonable.  The actual changes in 
> code-generation changes are because we were failing to set these reliably?


Most of them yes.

In the CUDA test we there is now `contract` because we honor the default 
contraction mode that for CUDA is set to fast.

In `clang/test/CodeGen/complex-math.c` I've added `-ffp-contract=fast` to the 
command line option because `-ffast-math` at the CC1 level does not change the 
default contraction mode. We might want to treat `-ffast-math` similarly to 
`-cl-fast-relaxed-math`, i.e. it implies by default the "fast" contraction 
mode. Before this change there behavior was accidentally the same as 
"-ffast-math changes the default contraction mode" because there was:

  if (CGM.getLangOpts().FastMath)
FMF.setFast()

and so the bit for `AllowContract` was enabled in the fast-math flags.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80315



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

[PATCH] D80440: [OpenCL] Prevent fused mul and add by default

[Matt Arsenault via Phabricator via cfe-commits]

arsenm requested changes to this revision.
arsenm added a comment.
This revision now requires changes to proceed.

I think the current handling is correct. As you said, the specified default is 
FP_CONTRACT ON. The description of the mad function in the table is unrelated, 
since that's the definition and won't change based on the pragma.


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

https://reviews.llvm.org/D80440



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

[PATCH] D80412: Summary: [Lexer] Fix invalid suffix diagnostic for fixed-point literals

[Leonard Chan via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGef3744405855: [Lexer] Fix invalid suffix diagnostic for 
fixed-point literals (authored by leonardchan).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80412

Files:
  clang/include/clang/Basic/DiagnosticLexKinds.td
  clang/include/clang/Lex/LiteralSupport.h
  clang/lib/Lex/LiteralSupport.cpp
  clang/test/Frontend/fixed_point_errors.c


Index: clang/test/Frontend/fixed_point_errors.c
===
--- clang/test/Frontend/fixed_point_errors.c
+++ clang/test/Frontend/fixed_point_errors.c
@@ -137,15 +137,15 @@
 _Sat longaccum_t td_sat_long_accum; // expected-error{{'_Sat' 
specifier is only valid on '_Fract' or '_Accum', not 'type-name'}}
 
 /* Bad suffixes  */
-_Accum fk = 1.0fk;// expected-error{{invalid suffix 'fk' on integer 
constant}}
-_Accum kk = 1.0kk;// expected-error{{invalid suffix 'kk' on integer 
constant}}
-_Accum rk = 1.0rk;// expected-error{{invalid suffix 'rk' on integer 
constant}}
-_Accum rk = 1.0rr;// expected-error{{invalid suffix 'rr' on integer 
constant}}
-_Accum qk = 1.0qr;// expected-error{{invalid suffix 'qr' on integer 
constant}}
+_Accum fk = 1.0fk; // expected-error{{invalid suffix 'fk' on fixed-point 
constant}}
+_Accum kk = 1.0kk; // expected-error{{invalid suffix 'kk' on fixed-point 
constant}}
+_Accum rk = 1.0rk; // expected-error{{invalid suffix 'rk' on fixed-point 
constant}}
+_Accum rk = 1.0rr; // expected-error{{invalid suffix 'rr' on fixed-point 
constant}}
+_Accum qk = 1.0qr; // expected-error{{invalid suffix 'qr' on fixed-point 
constant}}
 
 /* Using wrong exponent notation */
-_Accum dec_with_hex_exp1 = 0.1p10k;// expected-error{{invalid suffix 
'p10k' on integer constant}}
-_Accum dec_with_hex_exp2 = 0.1P10k;// expected-error{{invalid suffix 
'P10k' on integer constant}}
+_Accum dec_with_hex_exp1 = 0.1p10k;// expected-error{{invalid suffix 
'p10k' on fixed-point constant}}
+_Accum dec_with_hex_exp2 = 0.1P10k;// expected-error{{invalid suffix 
'P10k' on fixed-point constant}}
 _Accum hex_with_dex_exp1 = 0x0.1e10k;  // expected-error{{hexadecimal floating 
constant requires an exponent}}
 _Accum hex_with_dex_exp2 = 0x0.1E10k;  // expected-error{{hexadecimal floating 
constant requires an exponent}}
 
Index: clang/lib/Lex/LiteralSupport.cpp
===
--- clang/lib/Lex/LiteralSupport.cpp
+++ clang/lib/Lex/LiteralSupport.cpp
@@ -583,6 +583,7 @@
 
   // Parse the suffix.  At this point we can classify whether we have an FP or
   // integer constant.
+  bool isFixedPointConstant = isFixedPointLiteral();
   bool isFPConstant = isFloatingLiteral();
 
   // Loop over all of the characters of the suffix.  If we see something bad,
@@ -737,7 +738,8 @@
   // Report an error if there are any.
   PP.Diag(PP.AdvanceToTokenCharacter(TokLoc, SuffixBegin - ThisTokBegin),
   diag::err_invalid_suffix_constant)
-  << StringRef(SuffixBegin, ThisTokEnd - SuffixBegin) << isFPConstant;
+  << StringRef(SuffixBegin, ThisTokEnd - SuffixBegin)
+  << (isFixedPointConstant ? 2 : isFPConstant);
   hadError = true;
 }
   }
Index: clang/include/clang/Lex/LiteralSupport.h
===
--- clang/include/clang/Lex/LiteralSupport.h
+++ clang/include/clang/Lex/LiteralSupport.h
@@ -71,7 +71,9 @@
   bool isFract : 1; // 1.0hr/r/lr/uhr/ur/ulr
   bool isAccum : 1; // 1.0hk/k/lk/uhk/uk/ulk
 
-  bool isFixedPointLiteral() const { return saw_fixed_point_suffix; }
+  bool isFixedPointLiteral() const {
+return (saw_period || saw_exponent) && saw_fixed_point_suffix;
+  }
 
   bool isIntegerLiteral() const {
 return !saw_period && !saw_exponent && !isFixedPointLiteral();
Index: clang/include/clang/Basic/DiagnosticLexKinds.td
===
--- clang/include/clang/Basic/DiagnosticLexKinds.td
+++ clang/include/clang/Basic/DiagnosticLexKinds.td
@@ -175,7 +175,7 @@
 def err_invalid_digit : Error<
   "invalid digit '%0' in %select{decimal|octal|binary}1 constant">;
 def err_invalid_suffix_constant : Error<
-  "invalid suffix '%0' on %select{integer|floating}1 constant">;
+  "invalid suffix '%0' on %select{integer|floating|fixed-point}1 constant">;
 def warn_cxx11_compat_digit_separator : Warning<
   "digit separators are incompatible with C++ standards before C++14">,
   InGroup, DefaultIgnore;


Index: clang/test/Frontend/fixed_point_errors.c
===
--- clang/test/Frontend/fixed_point_errors.c
+++ clang/test/Frontend/fixed_point_errors.c
@@ -137,15 +137,15 @@
 _Sat longaccum_t td_sat_long_accum; // expected-error{{'_Sat' specifier is only valid 

[PATCH] D80412: Summary: [Lexer] Fix invalid suffix diagnostic for fixed-point literals

[Leonard Chan via Phabricator via cfe-commits]

leonardchan added a comment.

In D80412#2056353 , @nagart wrote:

> I don't have commit access. Could any one please help to commit this patch. 
>  Thanks in advance.


No problem. Committed in ef37444058550b0f49441b994c9e9368d8e42da8 
.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80412



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

[PATCH] D80669: [analyzer] LoopWidening: fix crash by avoiding aliased references invalidation

[Abbas Sabra via Phabricator via cfe-commits]

AbbasSabra updated this revision to Diff 266689.
AbbasSabra added a comment.

clang-format


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80669

Files:
  clang/lib/StaticAnalyzer/Core/LoopWidening.cpp
  clang/test/Analysis/loop-widening-preserve-reference-type.cpp


Index: clang/test/Analysis/loop-widening-preserve-reference-type.cpp
===
--- clang/test/Analysis/loop-widening-preserve-reference-type.cpp
+++ clang/test/Analysis/loop-widening-preserve-reference-type.cpp
@@ -12,3 +12,11 @@
   for (int i = 0; i < 10; ++i) { }
   clang_analyzer_eval( != 0); // expected-warning{{TRUE}}
 }   // expected-warning@-1{{reference cannot be 
bound to dereferenced null pointer in well-defined C++ code; comparison may be 
assumed to always evaluate to true}}
+
+using AR = const A &;
+void invalid_type_alias_region_access() {
+  AR x = B();
+  for (int i = 0; i < 10; ++i) {
+  }
+  clang_analyzer_eval( != 0); // expected-warning{{TRUE}}
+} // expected-warning@-1{{reference cannot be bound to dereferenced null 
pointer in well-defined C++ code; comparison may be assumed to always evaluate 
to true}}
Index: clang/lib/StaticAnalyzer/Core/LoopWidening.cpp
===
--- clang/lib/StaticAnalyzer/Core/LoopWidening.cpp
+++ clang/lib/StaticAnalyzer/Core/LoopWidening.cpp
@@ -67,8 +67,10 @@
   }
 
   // References should not be invalidated.
-  auto Matches = 
match(findAll(stmt(hasDescendant(varDecl(hasType(referenceType())).bind(MatchRef,
-   *LCtx->getDecl()->getBody(), ASTCtx);
+  auto Matches = match(
+  findAll(stmt(hasDescendant(
+  
varDecl(hasType(hasCanonicalType(referenceType(.bind(MatchRef,
+  *LCtx->getDecl()->getBody(), ASTCtx);
   for (BoundNodes Match : Matches) {
 const VarDecl *VD = Match.getNodeAs(MatchRef);
 assert(VD);


Index: clang/test/Analysis/loop-widening-preserve-reference-type.cpp
===
--- clang/test/Analysis/loop-widening-preserve-reference-type.cpp
+++ clang/test/Analysis/loop-widening-preserve-reference-type.cpp
@@ -12,3 +12,11 @@
   for (int i = 0; i < 10; ++i) { }
   clang_analyzer_eval( != 0); // expected-warning{{TRUE}}
 }   // expected-warning@-1{{reference cannot be bound to dereferenced null pointer in well-defined C++ code; comparison may be assumed to always evaluate to true}}
+
+using AR = const A &;
+void invalid_type_alias_region_access() {
+  AR x = B();
+  for (int i = 0; i < 10; ++i) {
+  }
+  clang_analyzer_eval( != 0); // expected-warning{{TRUE}}
+} // expected-warning@-1{{reference cannot be bound to dereferenced null pointer in well-defined C++ code; comparison may be assumed to always evaluate to true}}
Index: clang/lib/StaticAnalyzer/Core/LoopWidening.cpp
===
--- clang/lib/StaticAnalyzer/Core/LoopWidening.cpp
+++ clang/lib/StaticAnalyzer/Core/LoopWidening.cpp
@@ -67,8 +67,10 @@
   }
 
   // References should not be invalidated.
-  auto Matches = match(findAll(stmt(hasDescendant(varDecl(hasType(referenceType())).bind(MatchRef,
-   *LCtx->getDecl()->getBody(), ASTCtx);
+  auto Matches = match(
+  findAll(stmt(hasDescendant(
+  varDecl(hasType(hasCanonicalType(referenceType(.bind(MatchRef,
+  *LCtx->getDecl()->getBody(), ASTCtx);
   for (BoundNodes Match : Matches) {
 const VarDecl *VD = Match.getNodeAs(MatchRef);
 assert(VD);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D80671: [analyzer] LoopWidening: fix crash by avoiding aliased references invalidation

[Abbas Sabra via Phabricator via cfe-commits]

AbbasSabra created this revision.
Herald added subscribers: cfe-commits, ASDenysPetrov, martong, Charusso, 
dkrupp, donat.nagy, Szelethus, mikhail.ramalho, a.sidorin, szepet, 
baloghadamsoftware, xazax.hun.
Herald added a project: clang.
AbbasSabra abandoned this revision.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D80671

Files:
  clang/lib/StaticAnalyzer/Core/LoopWidening.cpp
  clang/test/Analysis/loop-widening-preserve-reference-type.cpp


Index: clang/test/Analysis/loop-widening-preserve-reference-type.cpp
===
--- clang/test/Analysis/loop-widening-preserve-reference-type.cpp
+++ clang/test/Analysis/loop-widening-preserve-reference-type.cpp
@@ -12,3 +12,11 @@
   for (int i = 0; i < 10; ++i) { }
   clang_analyzer_eval( != 0); // expected-warning{{TRUE}}
 }   // expected-warning@-1{{reference cannot be 
bound to dereferenced null pointer in well-defined C++ code; comparison may be 
assumed to always evaluate to true}}
+
+using AR = const A &;
+void invalid_type_alias_region_access() {
+  AR x = B();
+  for (int i = 0; i < 10; ++i) {
+  }
+  clang_analyzer_eval( != 0); // expected-warning{{TRUE}}
+} // expected-warning@-1{{reference cannot be bound to dereferenced null 
pointer in well-defined C++ code; comparison may be assumed to always evaluate 
to true}}
Index: clang/lib/StaticAnalyzer/Core/LoopWidening.cpp
===
--- clang/lib/StaticAnalyzer/Core/LoopWidening.cpp
+++ clang/lib/StaticAnalyzer/Core/LoopWidening.cpp
@@ -67,8 +67,10 @@
   }
 
   // References should not be invalidated.
-  auto Matches = 
match(findAll(stmt(hasDescendant(varDecl(hasType(referenceType())).bind(MatchRef,
-   *LCtx->getDecl()->getBody(), ASTCtx);
+  auto Matches = match(
+  findAll(stmt(hasDescendant(
+  
varDecl(hasType(hasCanonicalType(referenceType(.bind(MatchRef,
+  *LCtx->getDecl()->getBody(), ASTCtx);
   for (BoundNodes Match : Matches) {
 const VarDecl *VD = Match.getNodeAs(MatchRef);
 assert(VD);


Index: clang/test/Analysis/loop-widening-preserve-reference-type.cpp
===
--- clang/test/Analysis/loop-widening-preserve-reference-type.cpp
+++ clang/test/Analysis/loop-widening-preserve-reference-type.cpp
@@ -12,3 +12,11 @@
   for (int i = 0; i < 10; ++i) { }
   clang_analyzer_eval( != 0); // expected-warning{{TRUE}}
 }   // expected-warning@-1{{reference cannot be bound to dereferenced null pointer in well-defined C++ code; comparison may be assumed to always evaluate to true}}
+
+using AR = const A &;
+void invalid_type_alias_region_access() {
+  AR x = B();
+  for (int i = 0; i < 10; ++i) {
+  }
+  clang_analyzer_eval( != 0); // expected-warning{{TRUE}}
+} // expected-warning@-1{{reference cannot be bound to dereferenced null pointer in well-defined C++ code; comparison may be assumed to always evaluate to true}}
Index: clang/lib/StaticAnalyzer/Core/LoopWidening.cpp
===
--- clang/lib/StaticAnalyzer/Core/LoopWidening.cpp
+++ clang/lib/StaticAnalyzer/Core/LoopWidening.cpp
@@ -67,8 +67,10 @@
   }
 
   // References should not be invalidated.
-  auto Matches = match(findAll(stmt(hasDescendant(varDecl(hasType(referenceType())).bind(MatchRef,
-   *LCtx->getDecl()->getBody(), ASTCtx);
+  auto Matches = match(
+  findAll(stmt(hasDescendant(
+  varDecl(hasType(hasCanonicalType(referenceType(.bind(MatchRef,
+  *LCtx->getDecl()->getBody(), ASTCtx);
   for (BoundNodes Match : Matches) {
 const VarDecl *VD = Match.getNodeAs(MatchRef);
 assert(VD);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D79675: [OpenMP][OMPBuilder] Adding Privatization Requirements to OMPIRBuilder

[Fady Ghanim via Phabricator via cfe-commits]

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

I am moving on because we are not getting anywhere. However, There are few 
things I need to point out very quickly.

> I fail to see the point in committing for example your target type solution 
> if we found a more generic version in the meantime.
>  We can for sure commit them and then replace them subsequently, but is that 
> really helping anyone? It would not be a question if
>  they were in, since they are not it seems to me there is no benefit in 
> blocking the other patch on them. I mean, the time you worked
>  on that part is not "less wasted" if we commit it. TBH, I don't thin it is 
> wasted at all but that is a different conversation.

At one point, you said I was delaying D80222  
moments after it was uploaded. Now, D79675  
and D79676  , cannot be committed because of 
the artificial dependency on that patch.

> I'm sorry you **feel** I waste your time. I really would not do so on purpose.

It is not a feeling. It is a matter of record, and never said you did so on 
purpose. Freudian slip? :p

> While more reviewers would obviously help, it is known that smaller patches 
> do too.

D79739  has been merged with D80222 
. I kinda feel bad for the reviewer ;)
You are the code owner of the `OMPBuilder`, who do you suggest as reviewers 
that I can add, in the future?

> If you have ideas on other improvements of the process, I'm happy to try them 
> out.

Let people know that you changed your mind before they put in the time and 
effort. I am sure that is not a big ask.

---

Anyways, I suggested something that you didn't reply to, which you may have 
missed. To resolve this, would you be willing to go for:

1. You handle any typing problems with this patch when you commit it and D79676 
 after D80222 
2. I bring back all my runtime def.s that I need, and use macros per your 
original suggestion, and you commit this and D79676 
 today or tomorrow and that patch can merge 
based on head commit which it will do anyway?




Comment at: llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h:62
+  /// return a copy of the current insertion point information
+  InsertPointTy SaveIP() { return Builder.saveIP(); }
+

jdoerfert wrote:
> fghanim wrote:
> > jdoerfert wrote:
> > > Unused?
> > I'll happily drop them if you want. I needed them at one point, and assumed 
> > we may need them later, and left them in to see what you think. So still 
> > LGTM , or no LGTM?
> Generally we should not include code we don't need (or that is not tested).
We don't need it at the moment, however, I do not think an IRBuilder should go 
without a way to specify where you want it to point at.
This doesn't need a test. it just passes an argument to a private `IRBuilder` - 
if that works, this should just work.
Bottom line, should I remove it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79675



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

[PATCH] D80222: Replace Clang's createRuntimeFunction with the definitions in OMPKinds.def

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added inline comments.



Comment at: openmp/runtime/test/tasking/kmp_taskloop.c:100
 th_counter[i] = 0;
-#pragma omp parallel num_threads(N)
+#pragma omp parallel // num_threads(N)
 {

jhuber6 wrote:
> jdoerfert wrote:
> > jhuber6 wrote:
> > > jdoerfert wrote:
> > > > jhuber6 wrote:
> > > > > AndreyChurbanov wrote:
> > > > > > jhuber6 wrote:
> > > > > > > jhuber6 wrote:
> > > > > > > > jdoerfert wrote:
> > > > > > > > > jhuber6 wrote:
> > > > > > > > > > I am not entirely sure why, but commenting this out causes 
> > > > > > > > > > the problem to go away. I tried adding proper names to the 
> > > > > > > > > > forward-declared functions but since clang already knew I 
> > > > > > > > > > had something called ident_t, I couldn't declare a new 
> > > > > > > > > > struct with the same name.
> > > > > > > > > This is not good. The difference should only be that the 
> > > > > > > > > `kmpc_fork_call` has a different argument, right? Does the 
> > > > > > > > > segfault happen at compile or runtime?
> > > > > > > > > 
> > > > > > > > > You can just use the ident_t clang created, right? Did you 
> > > > > > > > > print the function names requested by clang as we discussed?
> > > > > > > > I added an assertion and debug statements. If I try to declare 
> > > > > > > > a struct named "Ident_t" I get the following error message in 
> > > > > > > > the seg-fault. I think the seg-fault is compile-time.
> > > > > > > > 
> > > > > > > > Found OpenMP runtime function __kmpc_global_thread_num with 
> > > > > > > > type i32 (%struct.ident_t.0*). Expected type is i32 
> > > > > > > > (%struct.ident_t*)
> > > > > > > > clang: 
> > > > > > > > /home/jhuber/Documents/llvm-project/llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:124:
> > > > > > > >  static llvm::Function* 
> > > > > > > > llvm::OpenMPIRBuilder::getOrCreateRuntimeFunction(llvm::Module&,
> > > > > > > >  llvm::omp::RuntimeFunction): Assertion `FnTy == 
> > > > > > > > Fn->getFunctionType() && "Found OpenMP runtime function has 
> > > > > > > > mismatched types"' failed.
> > > > > > > I'm not sure if there's a way around this without changing the 
> > > > > > > getOrCreateRuntimeFunction method to return a FunctionCallee and 
> > > > > > > removing the assertion. Clang doesn't know about the ident_t 
> > > > > > > struct when it's compiling the file, but when its doing the 
> > > > > > > codegen it sees two structs with the same name and creates a new 
> > > > > > > name. So when it gets the types it says that ident_t and 
> > > > > > > ident_t.0 don't match. As you said the old version got around 
> > > > > > > this by adding a bitcasting instruction so it knew how to turn it 
> > > > > > > into an ident_t pointer.
> > > > > > Note that this change breaks the test on any system with more that 
> > > > > > 4 procs.  Because array th_counter[4] is indexed by thread number 
> > > > > > which can easily be greater than 3 if number of threads is not 
> > > > > > limited.
> > > > > The problem was that the num_threads clause required an implicit call 
> > > > > to kmpc_global_thread_num so it could be passed to 
> > > > > kmpc_push_num_threads. The types of the implicit function and the 
> > > > > forward declaration then wouldn't match up. I added another forward 
> > > > > declaration to explicitly call kmpc_push_num_threads. Is this a 
> > > > > sufficient solution?
> > > > We need this to work with num_threads(8). 
> > > > 
> > > > > Clang doesn't know about the ident_t struct when it's compiling the 
> > > > > file, but when its doing the codegen it sees two structs with the 
> > > > > same name and creates a new name.
> > > > 
> > > > Where are the two structs coming from? We should have one. If clang 
> > > > introduces one it needs to use the one from OMPKindes.def instead. Is 
> > > > that a fix?
> > > The first struct is the one that I'm assuming comes from the OpenMP 
> > > CodeGen that places the Ident_t struct in the IR file. if I declare a 
> > > struct also named ident_t in the C source file it most likely will see 
> > > that there's two structs with the same name and call the second one 
> > > "ident_t.0" internally. The other ident_t struct is only known once clang 
> > > generates the LLVM IR so I can't just use "ident_t" nor can I declare a 
> > > struct with the same name.
> > 1) Either Clang needs to use the `llvm::omp::types::Ident` *or* Clang needs 
> > to define `llvm::omp::types::Ident` and we do not do it via  
> > `__OMP_STRUCT_TYPE(Ident, ident_t, Int32, Int32, Int32, Int32, Int8Ptr)`. I 
> > would prefer the first solution. 
> > 
> > 2) `OMPConstants.cpp` does pick up an existing struct type with the same 
> > name if present. That is, probably not what we want because it clashes with 
> > user types.
> > 
> > 3) We can still return a `FunctionCallee` with the Function* and the 
> > expected type (as defined by OMPKinds.def) to mimic the old behavior for 
> > now.
> > Either 

[clang] ef37444 - [Lexer] Fix invalid suffix diagnostic for fixed-point literals

[Leonard Chan via cfe-commits]

Author: Leonard Chan
Date: 2020-05-27T16:16:56-07:00
New Revision: ef37444058550b0f49441b994c9e9368d8e42da8

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

LOG: [Lexer] Fix invalid suffix diagnostic for fixed-point literals

Committing on behalf of nagart, who authored this patch.

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

Added: 


Modified: 
clang/include/clang/Basic/DiagnosticLexKinds.td
clang/include/clang/Lex/LiteralSupport.h
clang/lib/Lex/LiteralSupport.cpp
clang/test/Frontend/fixed_point_errors.c

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticLexKinds.td 
b/clang/include/clang/Basic/DiagnosticLexKinds.td
index ef90bdf84c8a..fa07e9ae76c8 100644
--- a/clang/include/clang/Basic/DiagnosticLexKinds.td
+++ b/clang/include/clang/Basic/DiagnosticLexKinds.td
@@ -175,7 +175,7 @@ def ext_unknown_escape : ExtWarn<"unknown escape sequence 
'\\%0'">,
 def err_invalid_digit : Error<
   "invalid digit '%0' in %select{decimal|octal|binary}1 constant">;
 def err_invalid_suffix_constant : Error<
-  "invalid suffix '%0' on %select{integer|floating}1 constant">;
+  "invalid suffix '%0' on %select{integer|floating|fixed-point}1 constant">;
 def warn_cxx11_compat_digit_separator : Warning<
   "digit separators are incompatible with C++ standards before C++14">,
   InGroup, DefaultIgnore;

diff  --git a/clang/include/clang/Lex/LiteralSupport.h 
b/clang/include/clang/Lex/LiteralSupport.h
index b9d64c24a00b..6829771b2830 100644
--- a/clang/include/clang/Lex/LiteralSupport.h
+++ b/clang/include/clang/Lex/LiteralSupport.h
@@ -71,7 +71,9 @@ class NumericLiteralParser {
   bool isFract : 1; // 1.0hr/r/lr/uhr/ur/ulr
   bool isAccum : 1; // 1.0hk/k/lk/uhk/uk/ulk
 
-  bool isFixedPointLiteral() const { return saw_fixed_point_suffix; }
+  bool isFixedPointLiteral() const {
+return (saw_period || saw_exponent) && saw_fixed_point_suffix;
+  }
 
   bool isIntegerLiteral() const {
 return !saw_period && !saw_exponent && !isFixedPointLiteral();

diff  --git a/clang/lib/Lex/LiteralSupport.cpp 
b/clang/lib/Lex/LiteralSupport.cpp
index 2b1add4d9b98..f44614b4bec4 100644
--- a/clang/lib/Lex/LiteralSupport.cpp
+++ b/clang/lib/Lex/LiteralSupport.cpp
@@ -583,6 +583,7 @@ NumericLiteralParser::NumericLiteralParser(StringRef 
TokSpelling,
 
   // Parse the suffix.  At this point we can classify whether we have an FP or
   // integer constant.
+  bool isFixedPointConstant = isFixedPointLiteral();
   bool isFPConstant = isFloatingLiteral();
 
   // Loop over all of the characters of the suffix.  If we see something bad,
@@ -737,7 +738,8 @@ NumericLiteralParser::NumericLiteralParser(StringRef 
TokSpelling,
   // Report an error if there are any.
   PP.Diag(PP.AdvanceToTokenCharacter(TokLoc, SuffixBegin - ThisTokBegin),
   diag::err_invalid_suffix_constant)
-  << StringRef(SuffixBegin, ThisTokEnd - SuffixBegin) << isFPConstant;
+  << StringRef(SuffixBegin, ThisTokEnd - SuffixBegin)
+  << (isFixedPointConstant ? 2 : isFPConstant);
   hadError = true;
 }
   }

diff  --git a/clang/test/Frontend/fixed_point_errors.c 
b/clang/test/Frontend/fixed_point_errors.c
index db15bd874b31..9b600fbc2642 100644
--- a/clang/test/Frontend/fixed_point_errors.c
+++ b/clang/test/Frontend/fixed_point_errors.c
@@ -137,15 +137,15 @@ _Sat longfract_t td_sat_long_fract; // 
expected-error{{'_Sat' specifier
 _Sat longaccum_t td_sat_long_accum; // expected-error{{'_Sat' 
specifier is only valid on '_Fract' or '_Accum', not 'type-name'}}
 
 /* Bad suffixes  */
-_Accum fk = 1.0fk;// expected-error{{invalid suffix 'fk' on integer 
constant}}
-_Accum kk = 1.0kk;// expected-error{{invalid suffix 'kk' on integer 
constant}}
-_Accum rk = 1.0rk;// expected-error{{invalid suffix 'rk' on integer 
constant}}
-_Accum rk = 1.0rr;// expected-error{{invalid suffix 'rr' on integer 
constant}}
-_Accum qk = 1.0qr;// expected-error{{invalid suffix 'qr' on integer 
constant}}
+_Accum fk = 1.0fk; // expected-error{{invalid suffix 'fk' on fixed-point 
constant}}
+_Accum kk = 1.0kk; // expected-error{{invalid suffix 'kk' on fixed-point 
constant}}
+_Accum rk = 1.0rk; // expected-error{{invalid suffix 'rk' on fixed-point 
constant}}
+_Accum rk = 1.0rr; // expected-error{{invalid suffix 'rr' on fixed-point 
constant}}
+_Accum qk = 1.0qr; // expected-error{{invalid suffix 'qr' on fixed-point 
constant}}
 
 /* Using wrong exponent notation */
-_Accum dec_with_hex_exp1 = 0.1p10k;// expected-error{{invalid suffix 
'p10k' on integer constant}}
-_Accum dec_with_hex_exp2 = 0.1P10k;// expected-error{{invalid suffix 
'P10k' on integer constant}}
+_Accum dec_with_hex_exp1 = 0.1p10k;// expected-error{{invalid suffix 

[PATCH] D79972: [OpenMP5.0] map item can be non-contiguous for target update

[Chi Chun Chen via Phabricator via cfe-commits]

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



Comment at: clang/lib/Sema/SemaOpenMP.cpp:16537
 AllowWholeSizeArraySection = false;
+} else if (DKind == OMPD_target_update &&
+   SemaRef.getLangOpts().OpenMP >= 50) {

@ABataev , I guess you're saying the condition should be 
`!AllowWholeSizeArraySection && DKind == OMPD_target_update && 
SemaRef.getLangOpts().OpenMP >= 50`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79972



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

[PATCH] D76793: [Matrix] Implement + and - operators for MatrixType.

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: clang/lib/Sema/SemaExpr.cpp:11989
+  else
+return false;
+

fhahn wrote:
> rjmccall wrote:
> > I would suggest checking some preconditions and then just calling 
> > `PrepareScalarCast`.
> > 
> > You should allow implicit conversions from class types, which somewhat 
> > surprisingly I'm not sure we have a convenient method for, but which you 
> > can find workable code for in `ConvertForConditional` in SemaExprCXX.cpp.  
> > Test case is `struct DoubleWrapper { operator double(); };`, and you should 
> > test using that even when the element type isn't a double.
> > 
> > In SemaOverload, you should add builtin candidates for these operators if 
> > one operand or the other is a matrix type.  Basically:
> > 
> > 1. Collect matrix types in `AddTypesConvertedFrom`
> > 2. For each matrix type `M` on the LHS, add candidates for `(M, M) -> M` 
> > and `(M, E) -> M`, and then analogously on the RHS.  Although you might 
> > need to avoid adding redundant candidates if the same type shows up on both 
> > sides.
> Thank you very much John, I hope I managed to update the patch properly 
> according to your comments!
Does it work to just do the initialization step instead of separately checking 
for an arithmetic type?  That code is definitely capable of doing arithmetic 
conversions.



Comment at: clang/lib/Sema/SemaOverload.cpp:9173
   OpBuilder.addBinaryPlusOrMinusPointerOverloads(Op);
-  OpBuilder.addGenericBinaryArithmeticOverloads();
+  OpBuilder.addGenericBinaryArithmeticOverloads(Op);
 }

Maybe you should just extract your new code into its own method and call it 
here.  That might fit in a bit cleaner to the design, since unlike the vector 
case you're not planning on uniformly having element-wise versions of all of 
the operators.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76793



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

[PATCH] D80669: [analyzer] LoopWidening: fix crash by avoiding aliased references invalidation

[Abbas Sabra via Phabricator via cfe-commits]

AbbasSabra created this revision.
Herald added subscribers: cfe-commits, ASDenysPetrov, martong, Charusso, 
dkrupp, donat.nagy, Szelethus, mikhail.ramalho, a.sidorin, szepet, 
baloghadamsoftware, xazax.hun.
Herald added a project: clang.
AbbasSabra edited the summary of this revision.
AbbasSabra added reviewers: xazax.hun, vsavchenko, NoQ.
Herald added a subscriber: rnkovacs.
AbbasSabra retitled this revision from "[analyzer] LoopWidening: fix crash by 
avoiding aliased references invalidationSummary: LoopWidening is invalidating 
references comming from type aliases which lead to a crashReviewers: xazax.hun 
vsavchenko NoQSubscribers:" to "[analyzer] LoopWidening: fix crash by avoiding 
aliased references invalidation".

LoopWidening is invalidating references coming from type aliases which lead to 
a crash.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D80669

Files:
  clang/lib/StaticAnalyzer/Core/LoopWidening.cpp
  clang/test/Analysis/loop-widening-preserve-reference-type.cpp


Index: clang/test/Analysis/loop-widening-preserve-reference-type.cpp
===
--- clang/test/Analysis/loop-widening-preserve-reference-type.cpp
+++ clang/test/Analysis/loop-widening-preserve-reference-type.cpp
@@ -12,3 +12,10 @@
   for (int i = 0; i < 10; ++i) { }
   clang_analyzer_eval( != 0); // expected-warning{{TRUE}}
 }   // expected-warning@-1{{reference cannot be 
bound to dereferenced null pointer in well-defined C++ code; comparison may be 
assumed to always evaluate to true}}
+
+using AR = const A&;
+void invalid_type_alias_region_access() {
+  AR x = B();
+  for (int i = 0; i < 10; ++i) { }
+  clang_analyzer_eval( != 0); // expected-warning{{TRUE}}
+}   // expected-warning@-1{{reference cannot be 
bound to dereferenced null pointer in well-defined C++ code; comparison may be 
assumed to always evaluate to true}}
Index: clang/lib/StaticAnalyzer/Core/LoopWidening.cpp
===
--- clang/lib/StaticAnalyzer/Core/LoopWidening.cpp
+++ clang/lib/StaticAnalyzer/Core/LoopWidening.cpp
@@ -67,8 +67,10 @@
   }
 
   // References should not be invalidated.
-  auto Matches = 
match(findAll(stmt(hasDescendant(varDecl(hasType(referenceType())).bind(MatchRef,
-   *LCtx->getDecl()->getBody(), ASTCtx);
+  auto Matches = match(
+  findAll(stmt(hasDescendant(
+  
varDecl(hasType(hasCanonicalType(referenceType(.bind(MatchRef,
+  *LCtx->getDecl()->getBody(), ASTCtx);
   for (BoundNodes Match : Matches) {
 const VarDecl *VD = Match.getNodeAs(MatchRef);
 assert(VD);


Index: clang/test/Analysis/loop-widening-preserve-reference-type.cpp
===
--- clang/test/Analysis/loop-widening-preserve-reference-type.cpp
+++ clang/test/Analysis/loop-widening-preserve-reference-type.cpp
@@ -12,3 +12,10 @@
   for (int i = 0; i < 10; ++i) { }
   clang_analyzer_eval( != 0); // expected-warning{{TRUE}}
 }   // expected-warning@-1{{reference cannot be bound to dereferenced null pointer in well-defined C++ code; comparison may be assumed to always evaluate to true}}
+
+using AR = const A&;
+void invalid_type_alias_region_access() {
+  AR x = B();
+  for (int i = 0; i < 10; ++i) { }
+  clang_analyzer_eval( != 0); // expected-warning{{TRUE}}
+}   // expected-warning@-1{{reference cannot be bound to dereferenced null pointer in well-defined C++ code; comparison may be assumed to always evaluate to true}}
Index: clang/lib/StaticAnalyzer/Core/LoopWidening.cpp
===
--- clang/lib/StaticAnalyzer/Core/LoopWidening.cpp
+++ clang/lib/StaticAnalyzer/Core/LoopWidening.cpp
@@ -67,8 +67,10 @@
   }
 
   // References should not be invalidated.
-  auto Matches = match(findAll(stmt(hasDescendant(varDecl(hasType(referenceType())).bind(MatchRef,
-   *LCtx->getDecl()->getBody(), ASTCtx);
+  auto Matches = match(
+  findAll(stmt(hasDescendant(
+  varDecl(hasType(hasCanonicalType(referenceType(.bind(MatchRef,
+  *LCtx->getDecl()->getBody(), ASTCtx);
   for (BoundNodes Match : Matches) {
 const VarDecl *VD = Match.getNodeAs(MatchRef);
 assert(VD);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D79972: [OpenMP5.0] map item can be non-contiguous for target update

[Chi Chun Chen via Phabricator via cfe-commits]

cchen added a comment.

In D79972#2058608 , @ABataev wrote:

> In D79972#2058555 , @cchen wrote:
>
> > In D79972#2058516 , @ABataev wrote:
> >
> > > Is my guess correct that for OpenMP >= 50 for target update directive we 
> > > always emit `possibly non-continuous` runtime calls?
> >
> >
> > My intent is to emit `possibly non-contiguous` runtime calls only if the 
> > analysis in Sema set the IsNonContiguous flag to true.
>
>
> But this analysis only checks for the directive and the version,nothing else.


The context of the checks for the directive and version:

  bool NotWhole =
checkArrayExpressionDoesNotReferToWholeSize(SemaRef, OASE, CurType);
  bool NotUnity =
checkArrayExpressionDoesNotReferToUnitySize(SemaRef, OASE, CurType);
  
  if (AllowWholeSizeArraySection) {
// Any array section is currently allowed. Allowing a whole size array
// section implies allowing a unity array section as well.
//
// If this array section refers to the whole dimension we can still
// accept other array sections before this one, except if the base is a
// pointer. Otherwise, only unitary sections are accepted.
if (NotWhole || IsPointer)
  AllowWholeSizeArraySection = false;
  } else if (DKind == OMPD_target_update &&
 SemaRef.getLangOpts().OpenMP >= 50) {
IsNonContiguousRef = true;
  } else if (AllowUnitySizeArraySection && NotUnity) {
// A unity or whole array section is not allowed and that is not
// compatible with the properties of the current array section.
SemaRef.Diag(
  ELoc, diag::err_array_section_does_not_specify_contiguous_storage)
  << OASE->getSourceRange();
return false;
  }

The original analysis checks for non-contiguous by finding if there is more 
than one "array-section" expression with length greater than one. Therefore, I 
added my check there to allow more than one array-section with length greater 
than one by depending on the existing analysis (and also set IsNonContiguous to 
true so that we can pass it to codegen rather than doing analysis in codegen). 
This change allows me to pass all the existing lit test but still emit the 
"non-contiguous" runtime.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79972



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

[PATCH] D79972: [OpenMP5.0] map item can be non-contiguous for target update

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added a comment.

In D79972#2058555 , @cchen wrote:

> In D79972#2058516 , @ABataev wrote:
>
> > Is my guess correct that for OpenMP >= 50 for target update directive we 
> > always emit `possibly non-continuous` runtime calls?
>
>
> My intent is to emit `possibly non-contiguous` runtime calls only if the 
> analysis in Sema set the IsNonContiguous flag to true.


But this analysis only checks for the directive and the version,nothing else.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79972



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

[PATCH] D69764: [clang-format] Add East/West Const fixer capability

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

rsmith added a comment.

In D69764#2058334 , @MyDeveloperDay 
wrote:

> @rsmith, Thank you for your comments, I don't agree, but thank you anyway.
>
> I will continue to feel there is some value here, My hope is that others will 
> feel the same.


To be clear: I do think a tool that will reorder specifiers to match a coding 
standard has value. My concern is that it seems like scope creep for 
clang-format in particular to do that, and that scope creep makes me 
uncomfortable -- we're moving further away from the set of transformations that 
clang-format can be very confident don't change the meaning of the program, and 
we have seen problems with such scope creep in the past. But I'm only 
uncomfortable, not opposed. Looking back through the review thread, I don't 
think I'm raising anything that @sammccall didn't already bring up, and it 
seems to me like you have consensus for doing this despite those concerns. So 
be it. :)

I think that if we are reordering `const`, we should be reordering all 
//decl-specifier//s -- I'd like to see `int static constexpr unsigned const 
long inline` reordered to something like `static constexpr inline const 
unsigned long int` too. Applying this only to `const` seems incomplete to me.




Comment at: clang/lib/Format/EastWestConstFixer.cpp:199
+  }
+  // Don't concern youself if nothing follows const.
+  if (!Tok->Next) {

(Typo: youself -> yourself)



Comment at: clang/lib/Format/EastWestConstFixer.cpp:291
+  if (isCVQualifierOrType(Tok) && isCVQualifierOrType(Tok->Next) && 
isCVQualifierOrType(Tok->Next->Next) &&
+// `unsigned longl long const` -> `const unsigned long long`.
+  Tok->Next->Next->Next && Tok->Next->Next->Next->is(tok::kw_const)) {

(Typo: longl -> long)



Comment at: clang/lib/Format/EastWestConstFixer.cpp:293
+  Tok->Next->Next->Next && Tok->Next->Next->Next->is(tok::kw_const)) {
+swapFourTokens(SourceMgr, Fixes, Tok, Tok->Next, Tok->Next, 
Tok->Next->Next->Next,
+ /*West=*/true);

There can be more than four type-specifiers / cv-qualifiers in a row. Eg: 
`unsigned long long int volatile const` -> `const volatile unsigned long long 
int`.



Comment at: clang/lib/Format/EastWestConstFixer.h:1
+//===--- EastWwestConstFixer.h --*- C++ 
-*-===//
+//

(Typo in file name.)


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

https://reviews.llvm.org/D69764



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

[PATCH] D80668: [Clang][Sanitizers] Expect test failure on {arm,thumb}v7

[Marco Elver via Phabricator via cfe-commits]

melver added a comment.

Example of failing test:
http://lab.llvm.org:8011/builders/clang-cmake-armv7-full/builds/10689

So this definitely can't be -target, because we set that. So it seems that some 
version of LLVM compiled for armv7 is somehow broken?

Vitaly, I wasn't able to test this since I don't have access to any such 
platform right now. If the "XFAIL" looks sane, and there isn't a better option, 
the build bots should eventually be able to tell us if this is reasonable.

Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80668



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

[PATCH] D80668: [Clang][Sanitizers] Expect test failure on {arm,thumb}v7

[Marco Elver via Phabricator via cfe-commits]

melver created this revision.
melver added a reviewer: vitalybuka.
Herald added subscribers: cfe-commits, danielkiss, kristof.beyls.
Herald added a project: clang.
melver added a comment.

Example of failing test:
http://lab.llvm.org:8011/builders/clang-cmake-armv7-full/builds/10689

So this definitely can't be -target, because we set that. So it seems that some 
version of LLVM compiled for armv7 is somehow broken?

Vitaly, I wasn't able to test this since I don't have access to any such 
platform right now. If the "XFAIL" looks sane, and there isn't a better option, 
the build bots should eventually be able to tell us if this is reasonable.

Thanks!


Versions of LLVM built on {arm,thumb}v7 appear to have differently
configured pass managers, which causes restrictions on which sanitizers
we may use.

As such, expect failure of the recently added "sanitize-coverage.c" test
on these architectures until we can investigate armv7's restrictions.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D80668

Files:
  clang/test/CodeGen/sanitize-coverage.c


Index: clang/test/CodeGen/sanitize-coverage.c
===
--- clang/test/CodeGen/sanitize-coverage.c
+++ clang/test/CodeGen/sanitize-coverage.c
@@ -4,6 +4,8 @@
 // RUN: %clang %s -target x86_64-unknown-linux-gnu -emit-llvm -S 
-fsanitize=memory -fsanitize-coverage=trace-pc,trace-cmp -o - | FileCheck 
%s --check-prefixes=CHECK,MSAN
 // RUN: %clang %s -target x86_64-unknown-linux-gnu -emit-llvm -S 
-fsanitize=thread -fsanitize-coverage=trace-pc,trace-cmp -o - | FileCheck 
%s --check-prefixes=CHECK,TSAN
 // RUN: %clang %s -target x86_64-unknown-linux-gnu -emit-llvm -S 
-fsanitize=undefined  -fsanitize-coverage=trace-pc,trace-cmp -o - | FileCheck 
%s --check-prefixes=CHECK,UBSAN
+//
+// XFAIL: armv7, thumbv7
 
 int x[10];
 


Index: clang/test/CodeGen/sanitize-coverage.c
===
--- clang/test/CodeGen/sanitize-coverage.c
+++ clang/test/CodeGen/sanitize-coverage.c
@@ -4,6 +4,8 @@
 // RUN: %clang %s -target x86_64-unknown-linux-gnu -emit-llvm -S -fsanitize=memory -fsanitize-coverage=trace-pc,trace-cmp -o - | FileCheck %s --check-prefixes=CHECK,MSAN
 // RUN: %clang %s -target x86_64-unknown-linux-gnu -emit-llvm -S -fsanitize=thread -fsanitize-coverage=trace-pc,trace-cmp -o - | FileCheck %s --check-prefixes=CHECK,TSAN
 // RUN: %clang %s -target x86_64-unknown-linux-gnu -emit-llvm -S -fsanitize=undefined  -fsanitize-coverage=trace-pc,trace-cmp -o - | FileCheck %s --check-prefixes=CHECK,UBSAN
+//
+// XFAIL: armv7, thumbv7
 
 int x[10];
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D80222: Replace Clang's createRuntimeFunction with the definitions in OMPKinds.def

[Joseph Huber via Phabricator via cfe-commits]

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



Comment at: openmp/runtime/test/tasking/kmp_taskloop.c:100
 th_counter[i] = 0;
-#pragma omp parallel num_threads(N)
+#pragma omp parallel // num_threads(N)
 {

jdoerfert wrote:
> jhuber6 wrote:
> > jdoerfert wrote:
> > > jhuber6 wrote:
> > > > AndreyChurbanov wrote:
> > > > > jhuber6 wrote:
> > > > > > jhuber6 wrote:
> > > > > > > jdoerfert wrote:
> > > > > > > > jhuber6 wrote:
> > > > > > > > > I am not entirely sure why, but commenting this out causes 
> > > > > > > > > the problem to go away. I tried adding proper names to the 
> > > > > > > > > forward-declared functions but since clang already knew I had 
> > > > > > > > > something called ident_t, I couldn't declare a new struct 
> > > > > > > > > with the same name.
> > > > > > > > This is not good. The difference should only be that the 
> > > > > > > > `kmpc_fork_call` has a different argument, right? Does the 
> > > > > > > > segfault happen at compile or runtime?
> > > > > > > > 
> > > > > > > > You can just use the ident_t clang created, right? Did you 
> > > > > > > > print the function names requested by clang as we discussed?
> > > > > > > I added an assertion and debug statements. If I try to declare a 
> > > > > > > struct named "Ident_t" I get the following error message in the 
> > > > > > > seg-fault. I think the seg-fault is compile-time.
> > > > > > > 
> > > > > > > Found OpenMP runtime function __kmpc_global_thread_num with type 
> > > > > > > i32 (%struct.ident_t.0*). Expected type is i32 (%struct.ident_t*)
> > > > > > > clang: 
> > > > > > > /home/jhuber/Documents/llvm-project/llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:124:
> > > > > > >  static llvm::Function* 
> > > > > > > llvm::OpenMPIRBuilder::getOrCreateRuntimeFunction(llvm::Module&, 
> > > > > > > llvm::omp::RuntimeFunction): Assertion `FnTy == 
> > > > > > > Fn->getFunctionType() && "Found OpenMP runtime function has 
> > > > > > > mismatched types"' failed.
> > > > > > I'm not sure if there's a way around this without changing the 
> > > > > > getOrCreateRuntimeFunction method to return a FunctionCallee and 
> > > > > > removing the assertion. Clang doesn't know about the ident_t struct 
> > > > > > when it's compiling the file, but when its doing the codegen it 
> > > > > > sees two structs with the same name and creates a new name. So when 
> > > > > > it gets the types it says that ident_t and ident_t.0 don't match. 
> > > > > > As you said the old version got around this by adding a bitcasting 
> > > > > > instruction so it knew how to turn it into an ident_t pointer.
> > > > > Note that this change breaks the test on any system with more that 4 
> > > > > procs.  Because array th_counter[4] is indexed by thread number which 
> > > > > can easily be greater than 3 if number of threads is not limited.
> > > > The problem was that the num_threads clause required an implicit call 
> > > > to kmpc_global_thread_num so it could be passed to 
> > > > kmpc_push_num_threads. The types of the implicit function and the 
> > > > forward declaration then wouldn't match up. I added another forward 
> > > > declaration to explicitly call kmpc_push_num_threads. Is this a 
> > > > sufficient solution?
> > > We need this to work with num_threads(8). 
> > > 
> > > > Clang doesn't know about the ident_t struct when it's compiling the 
> > > > file, but when its doing the codegen it sees two structs with the same 
> > > > name and creates a new name.
> > > 
> > > Where are the two structs coming from? We should have one. If clang 
> > > introduces one it needs to use the one from OMPKindes.def instead. Is 
> > > that a fix?
> > The first struct is the one that I'm assuming comes from the OpenMP CodeGen 
> > that places the Ident_t struct in the IR file. if I declare a struct also 
> > named ident_t in the C source file it most likely will see that there's two 
> > structs with the same name and call the second one "ident_t.0" internally. 
> > The other ident_t struct is only known once clang generates the LLVM IR so 
> > I can't just use "ident_t" nor can I declare a struct with the same name.
> 1) Either Clang needs to use the `llvm::omp::types::Ident` *or* Clang needs 
> to define `llvm::omp::types::Ident` and we do not do it via  
> `__OMP_STRUCT_TYPE(Ident, ident_t, Int32, Int32, Int32, Int32, Int8Ptr)`. I 
> would prefer the first solution. 
> 
> 2) `OMPConstants.cpp` does pick up an existing struct type with the same name 
> if present. That is, probably not what we want because it clashes with user 
> types.
> 
> 3) We can still return a `FunctionCallee` with the Function* and the expected 
> type (as defined by OMPKinds.def) to mimic the old behavior for now.
> Either Clang needs to use the `llvm::omp::types::Ident` *or* Clang needs to 
> define `llvm::omp::types::Ident` and we do not do it via 
> `__OMP_STRUCT_TYPE(Ident, ident_t, Int32, Int32, Int32, 

[PATCH] D79972: [OpenMP5.0] map item can be non-contiguous for target update

[Chi Chun Chen via Phabricator via cfe-commits]

cchen added a comment.

In D79972#2058516 , @ABataev wrote:

> Is my guess correct that for OpenMP >= 50 for target update directive we 
> always emit `possibly non-continuous` runtime calls?


My intent is to emit `possibly non-contiguous` runtime calls only if the 
analysis in Sema set the IsNonContiguous flag to true.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79972



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

[PATCH] D44823: [libcxx] Improving std::vector and std::deque perfomance

[Danila Kutenin via Phabricator via cfe-commits]

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



Comment at: libcxx/trunk/include/__split_buffer:201
 __alloc_rr& __a = this->__alloc();
+pointer __to_be_end = this->__end_;
 do

hiraditya wrote:
> danlark wrote:
> > lichray wrote:
> > > mclow.lists wrote:
> > > > I have been asked specifically by the optimizer folks to NOT do things 
> > > > like this in libc++, but rather to file bugs against the optimizer.
> > > > 
> > > > And I have done so for this exact case:  
> > > > https://bugs.llvm.org/show_bug.cgi?id=35637
> > > From the thread I didn't see that the compiler side asked you not to do 
> > > so.
> > > 
> > > And I disagree with the view.  libc++ shouldn't *wait* for compilers, 
> > > because we don't dictate users' compiler choices.  This change doesn't 
> > > make libc++ worse to coming compilers, and makes libc++ better on 
> > > existing compilers, so what benefit we get by not approving this?
> > So, what is the status? Are we waiting for the compiler code-gen fix?
> > 
> > At Yandex we are using patched version like half a year or more.
> > 
> > https://github.com/catboost/catboost/blob/master/contrib/libs/cxxsupp/libcxx/include/vector#L995
> It would be great to get this patch in. Waiting for compiler for this 
> optimization seems overkill.
It was separately submitted by the libcxx mainterner in July 2019 --  
https://reviews.llvm.org/rL367183


Repository:
  rCXX libc++

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

https://reviews.llvm.org/D44823



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

[PATCH] D80315: Fix CC1 command line options mapping into fast-math flags.

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

The code cleanups all seems reasonable.  The actual changes in code-generation 
changes are because we were failing to set these reliably?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80315



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

[PATCH] D80603: add isAtPosition narrowing matcher for parmVarDecl

[Vy Nguyen via Phabricator via cfe-commits]

oontvoo added a comment.

In D80603#2058019 , @aaron.ballman 
wrote:

> In D80603#2057970 , @oontvoo wrote:
>
> > In D80603#2057014 , @aaron.ballman 
> > wrote:
> >
> > > Does the `hasParameter()` matcher not already do this?
> >
> >
> > Yes, it does. But we'd like it to be able to match on the parmVarDecl().
>
>
> I'm sorry if I'm being dense, but `hasParameter`  traverses to the 
> `ParmVarDecl`, so I'm not certain I understand why this new matcher is needed 
> as a public matcher. It seems like you can already accomplish this without 
> adding a second API to do effectively the same thing: 
> `functionDecl(hasParameter(0, parmVarDecl().bind("param")))`, can't you?


Ah, I didn't mean to say it wasn't *already possible* to do any of this.

It would be *very* nice to have this (at least to some of us, that I know of). 
(make the logic a lot simpler in a few custom matchers).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80603



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

[PATCH] D44823: [libcxx] Improving std::vector and std::deque perfomance

[Aditya Kumar via Phabricator via cfe-commits]

hiraditya added inline comments.



Comment at: libcxx/trunk/include/__split_buffer:201
 __alloc_rr& __a = this->__alloc();
+pointer __to_be_end = this->__end_;
 do

danlark wrote:
> lichray wrote:
> > mclow.lists wrote:
> > > I have been asked specifically by the optimizer folks to NOT do things 
> > > like this in libc++, but rather to file bugs against the optimizer.
> > > 
> > > And I have done so for this exact case:  
> > > https://bugs.llvm.org/show_bug.cgi?id=35637
> > From the thread I didn't see that the compiler side asked you not to do so.
> > 
> > And I disagree with the view.  libc++ shouldn't *wait* for compilers, 
> > because we don't dictate users' compiler choices.  This change doesn't make 
> > libc++ worse to coming compilers, and makes libc++ better on existing 
> > compilers, so what benefit we get by not approving this?
> So, what is the status? Are we waiting for the compiler code-gen fix?
> 
> At Yandex we are using patched version like half a year or more.
> 
> https://github.com/catboost/catboost/blob/master/contrib/libs/cxxsupp/libcxx/include/vector#L995
It would be great to get this patch in. Waiting for compiler for this 
optimization seems overkill.


Repository:
  rCXX libc++

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

https://reviews.llvm.org/D44823



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

[PATCH] D79628: [Clang][Driver] Add Bounds and Thread to SupportsCoverage list

[Marco Elver via Phabricator via cfe-commits]

melver added a comment.

In D79628#2058404 , @vvereschaka wrote:

> the Clang sanitize-coverage.c test gets crashed on Windows platform for armv7 
> target:
>
> - FAIL: Clang::sanitize-coverage.c
>
>   ```
> - command stderr: Pass 'Run-time bounds checking' is not initialized.
>
>   Verify if there is a pass dependency cycle.
>
>   Required Passes:
>
>   Target Library Information ... ``` see more details here: 
> http://lab.llvm.org:8011/builders/llvm-clang-win-x-armv7l/builds/7561/steps/test-check-clang/logs/FAIL%3A%20Clang%3A%3Asanitize-coverage.c
>
>   The first failed build: 
> http://lab.llvm.org:8011/builders/llvm-clang-win-x-armv7l/builds/7561
>
>   Would you take care of it?


Thanks, I've been trying to understand this (similar failures on other armv7 
instances). What's different with LLVM on armv7? Does it use a differently 
configured pass manager? Given this only fails on armv7, to me this highlights 
an issue with the architecture.

What I can do is blacklist the test for armv7 and thumbv7 until those 
architectures get fixed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79628



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

[PATCH] D79972: [OpenMP5.0] map item can be non-contiguous for target update

[Chi Chun Chen via Phabricator via cfe-commits]

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



Comment at: clang/include/clang/AST/OpenMPClause.h:5315
+  private llvm::TrailingObjects<
+  OMPMapClause, Expr *, ValueDecl *, bool, unsigned,
+  OMPClauseMappableExprCommon::MappableComponent> {

ABataev wrote:
> Why do you need this bool flag? Seems to me, it is set to `true` always if 
> `OpenMP >= 50 && Directive == OMPD_target_update`. Could check it during the 
> codegen rather than introduce this new extra data here?
You're right, I shouldn't add bool here since we only need it in OMPToClause 
and OMPFromClause. I was adding it since I'm assuming they should have the same 
type for the inherited TrailingObject.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79972



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

[PATCH] D79972: [OpenMP5.0] map item can be non-contiguous for target update

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added a comment.

Is my guess correct that for OpenMP >= 50 for target update directive we always 
emit `possibly non-continuous` runtime calls?




Comment at: clang/include/clang/AST/OpenMPClause.h:5315
+  private llvm::TrailingObjects<
+  OMPMapClause, Expr *, ValueDecl *, bool, unsigned,
+  OMPClauseMappableExprCommon::MappableComponent> {

Why do you need this bool flag? Seems to me, it is set to `true` always if 
`OpenMP >= 50 && Directive == OMPD_target_update`. Could check it during the 
codegen rather than introduce this new extra data here?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79972



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

[PATCH] D76793: [Matrix] Implement + and - operators for MatrixType.

[Florian Hahn via Phabricator via cfe-commits]

fhahn updated this revision to Diff 266675.
fhahn added a comment.

Fixed overload candidates, use copy instead of const reference, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76793

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/test/CodeGen/matrix-type-operators.c
  clang/test/CodeGenCXX/matrix-type-operators.cpp
  clang/test/Sema/matrix-type-operators.c
  clang/test/SemaCXX/matrix-type-operators.cpp
  llvm/include/llvm/IR/MatrixBuilder.h

Index: llvm/include/llvm/IR/MatrixBuilder.h
===
--- llvm/include/llvm/IR/MatrixBuilder.h
+++ llvm/include/llvm/IR/MatrixBuilder.h
@@ -127,6 +127,16 @@
   /// Add matrixes \p LHS and \p RHS. Support both integer and floating point
   /// matrixes.
   Value *CreateAdd(Value *LHS, Value *RHS) {
+assert(LHS->getType()->isVectorTy() || RHS->getType()->isVectorTy());
+if (LHS->getType()->isVectorTy() && !RHS->getType()->isVectorTy())
+  RHS = B.CreateVectorSplat(
+  cast(LHS->getType())->getNumElements(), RHS,
+  "scalar.splat");
+else if (!LHS->getType()->isVectorTy() && RHS->getType()->isVectorTy())
+  LHS = B.CreateVectorSplat(
+  cast(RHS->getType())->getNumElements(), LHS,
+  "scalar.splat");
+
 return cast(LHS->getType())
->getElementType()
->isFloatingPointTy()
@@ -137,6 +147,16 @@
   /// Subtract matrixes \p LHS and \p RHS. Support both integer and floating
   /// point matrixes.
   Value *CreateSub(Value *LHS, Value *RHS) {
+assert(LHS->getType()->isVectorTy() || RHS->getType()->isVectorTy());
+if (LHS->getType()->isVectorTy() && !RHS->getType()->isVectorTy())
+  RHS = B.CreateVectorSplat(
+  cast(LHS->getType())->getNumElements(), RHS,
+  "scalar.splat");
+else if (!LHS->getType()->isVectorTy() && RHS->getType()->isVectorTy())
+  LHS = B.CreateVectorSplat(
+  cast(RHS->getType())->getNumElements(), LHS,
+  "scalar.splat");
+
 return cast(LHS->getType())
->getElementType()
->isFloatingPointTy()
Index: clang/test/SemaCXX/matrix-type-operators.cpp
===
--- clang/test/SemaCXX/matrix-type-operators.cpp
+++ clang/test/SemaCXX/matrix-type-operators.cpp
@@ -114,3 +114,96 @@
   a[2] = f;
   // expected-error@-1 {{single subscript expressions are not allowed for matrix values}}
 }
+
+template 
+struct MyMatrix {
+  using matrix_t = EltTy __attribute__((matrix_type(Rows, Columns)));
+
+  matrix_t value;
+};
+
+template 
+typename MyMatrix::matrix_t add(MyMatrix , MyMatrix ) {
+  char *v1 = A.value + B.value;
+  // expected-error@-1 {{cannot initialize a variable of type 'char *' with an rvalue of type 'MyMatrix::matrix_t' (aka 'unsigned int __attribute__((matrix_type(2, 2)))')}}
+  // expected-error@-2 {{invalid operands to binary expression ('MyMatrix::matrix_t' (aka 'unsigned int __attribute__((matrix_type(3, 3)))') and 'MyMatrix::matrix_t' (aka 'float __attribute__((matrix_type(2, 2)))'))}}
+  // expected-error@-3 {{invalid operands to binary expression ('MyMatrix::matrix_t' (aka 'unsigned int __attribute__((matrix_type(2, 2)))') and 'MyMatrix::matrix_t' (aka 'unsigned int __attribute__((matrix_type(3, 3)))'))}}
+
+  return A.value + B.value;
+  // expected-error@-1 {{invalid operands to binary expression ('MyMatrix::matrix_t' (aka 'unsigned int __attribute__((matrix_type(3, 3)))') and 'MyMatrix::matrix_t' (aka 'float __attribute__((matrix_type(2, 2)))'))}}
+  // expected-error@-2 {{invalid operands to binary expression ('MyMatrix::matrix_t' (aka 'unsigned int __attribute__((matrix_type(2, 2)))') and 'MyMatrix::matrix_t' (aka 'unsigned int __attribute__((matrix_type(3, 3)))'))}}
+}
+
+void test_add_template(unsigned *Ptr1, float *Ptr2) {
+  MyMatrix Mat1;
+  MyMatrix Mat2;
+  MyMatrix Mat3;
+  Mat1.value = *((decltype(Mat1)::matrix_t *)Ptr1);
+  unsigned v1 = add(Mat1, Mat1);
+  // expected-error@-1 {{cannot initialize a variable of type 'unsigned int' with an rvalue of type 'typename MyMatrix::matrix_t' (aka 'unsigned int __attribute__((matrix_type(2, 2)))')}}
+  // expected-note@-2 {{in instantiation of function template specialization 'add' requested here}}
+
+  Mat1.value = add(Mat1, Mat2);
+  // expected-note@-1 {{in instantiation of function template specialization 'add' requested here}}
+
+  Mat1.value = add(Mat2, Mat3);
+  // expected-note@-1 {{in instantiation of function template specialization 'add' requested here}}
+}
+
+template 
+typename MyMatrix::matrix_t subtract(MyMatrix , MyMatrix ) {
+  char *v1 = A.value - B.value;
+  // expected-error@-1 {{cannot initialize a variable of type 'char *' with an rvalue of type 'MyMatrix::matrix_t' (aka 

[PATCH] D80654: WIP: Make it possible to use the traverse() matcher in clang-query

[Stephen Kelly via Phabricator via cfe-commits]

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



Comment at: clang/include/clang/ASTMatchers/ASTMatchersInternal.h:383
+  static DynTypedMatcher
+  constructTraversalWrapper(const DynTypedMatcher ,
+ast_type_traits::TraversalKind TK);

ymandel wrote:
> I need this for my fix to Transformer. In fact, this is the only thing I 
> need, rather than an overload of `traverse` for `DynTypedMatcher`.  Do you 
> want me to split this into its own patch and send to you? Or, vice versa?
> 
> Also, whay `const DynTypedMatcher `? Given that it is 
> immediately copied, why not just `DynTypedMatcher InnerMatcher`, which at 
> least allows the caller to move-construct the argument and avoid the copy?
Yes, if you could split what ever you need out and incorporate it into your 
work I think that would be useful. 

I can rebase the rest of this once your fix is in.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80654



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

[PATCH] D76793: [Matrix] Implement + and - operators for MatrixType.

[Florian Hahn via Phabricator via cfe-commits]

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



Comment at: clang/lib/Sema/SemaOverload.cpp:8587
+if (S.Context.hasSameType(M1, M2))
+  AddCandidate(M1, M2);
+

rjmccall wrote:
> I don't think this works if one side or the other has e.g. a templated 
> conversion to a matrix type.  You need to add:
> 
> ```
>(M1, M1) -> M1
>(M1, M1.ElementType) -> M1
>(M2, M2) -> M2// but don't introduce the same candidate twice if the 
> same type is also in the LHS set)
>(M2.ElementType, M2) -> M2
> ```
> 
> Test case is something like:
> 
> ```
> struct identmatrix_t {
>   template 
>   operator matrix_type() const {
> matrix_type result = {};
> for (unsigned i = 0; i != N; ++i) result[i][i] = 1;
> return result;
>   }
> };
> constexpr identmatrix_t identmatrix = identmatrix();
> 
> ...
> m + identmatrix
> ```
> 
> Also, these operator candidates are only for specific operators, right?  I 
> think you can check what the operator is.
Oh I see, I've updated the code to add the versions as suggested.

> Also, these operator candidates are only for specific operators, right? I 
> think you can check what the operator is.

Yes they are. I had to update addGenericBinaryArithmeticOverloads to pass the 
Op kind.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76793



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

[PATCH] D76791: [Matrix] Implement matrix index expressions ([][]).

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: clang/lib/CodeGen/CGExpr.cpp:1900
+  assert(!LV.isMatrixElt() &&
+ "loads of matrix element LValues should be handled elsewhere");
   assert(LV.isBitField() && "Unknown LValue type!");

This should be handled here or else a whole lot of unusual cases are going to 
blow up on you — compound operators and so on.



Comment at: clang/lib/CodeGen/CGExpr.cpp:3787
+   ColIdx->getType()->getScalarSizeInBits());
+  llvm::Type *IntTy = llvm::IntegerType::get(getLLVMContext(), MaxWidth);
+  RowIdx = Builder.CreateZExt(RowIdx, IntTy);

You should be able to assert that these have been coerced to the right type by 
Sema (probably size_t or ptrdiff_t or something).



Comment at: clang/lib/Sema/SemaExpr.cpp:4655
+  // type, in which case the overload resolution for the operator overload
+  // should get the first crack at the overload.
+

fhahn wrote:
> rjmccall wrote:
> > Overload placeholder types are used for things like `` where `foo` is 
> > the name of an overloaded function.  The places that resolve only 
> > non-overload placeholder types are doing so in order to leave room for 
> > overload resolution to resolve the overload later, e.g. as part of 
> > non-builtin operator handling.  `operator[]` is like `operator()`: 
> > non-builtin operators are only considered when the base has class type.  
> > Since you already know that the base type is a matrix type, you know that 
> > you're using your standard rules, and your standard rules have no way to 
> > resolve overloads in the index types — correctly, since indexes can't be 
> > functions or member pointers.
> > 
> > tl;dr: You can (and should) resolve all placeholders here, not just 
> > non-overload placeholders.
> Thanks for the clarification. I moved the code to deal with placeholders to 
> CreateBuiltinMatrixSubscriptExpr and removed the non-overload restriction 
> there.
> 
> I think we still need to keep dealing with placeholders in `Base` below, to 
> ensure we do not miss that the base is actually a matrix type, e.g. to 
> support. It seems it is enough to skip` isMSPropertySubscriptExpr` there 
> (without that restriction, some non-matrix-type codegen tests start to fail. 
> Does that make sense?
> 
> ```
> __attribute__((objc_root_class))
> @interface MatrixValue
> @property double4x4 value;
> @end
> ```
Yeah, you have to resolve some placeholders before you can check whether the 
base is a matrix type, and you can't resolve MS properties because the property 
access actually merges with the subscript in some cases.

I think you may need to resolve placeholders in base even in 
CreateBuiltinMatrixSubscriptExpr to handle template instantiation right.  The 
test case would be something where the matrix expression is 
non-dependently-typed but loaded from an ObjC property — we might need to 
redundantly resolve placeholders when rebuilding expressions in the 
instantiation.



Comment at: clang/lib/Sema/SemaExpr.cpp:4553
+  if (!MaybeMatrixSubscript.isUnset())
+return MaybeMatrixSubscript;
+

I would prefer that the checks are inlined here, since they're very likely to 
not trigger.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76791



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

[PATCH] D76791: [Matrix] Implement matrix index expressions ([][]).

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

I also want to confirm explicitly that you've decided that the right language 
design is for matrix components to not be addressable.  You're convinced that 
that's an important restriction to get the code generation you want?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76791



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

[PATCH] D79628: [Clang][Driver] Add Bounds and Thread to SupportsCoverage list

[Vlad Vereschaka via Phabricator via cfe-commits]

vvereschaka added a comment.

Hi Marco,

the Clang sanitize-coverage.c test gets crashed on Windows platform for armv7 
target:

- FAIL: Clang::sanitize-coverage.c

  # command stderr:
  Pass 'Run-time bounds checking' is not initialized.
  
  Verify if there is a pass dependency cycle.
  
  Required Passes:
  
Target Library Information
  ...

see more details here: 
http://lab.llvm.org:8011/builders/llvm-clang-win-x-armv7l/builds/7561/steps/test-check-clang/logs/FAIL%3A%20Clang%3A%3Asanitize-coverage.c

The first failed build: 
http://lab.llvm.org:8011/builders/llvm-clang-win-x-armv7l/builds/7561

Would you take care of it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79628



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

[PATCH] D79972: [OpenMP5.0] map item can be non-contiguous for target update

[Chi Chun Chen via Phabricator via cfe-commits]

cchen added a comment.

In D79972#2049838 , @ABataev wrote:

> How are you going to pass this non-contiguous data in the runtime? Are you 
> going to map it in a loop or convert this non-contiguous data into the 
> contiguous and map it as a contiguous chunk of data? Your presentation 
> provides interface only interface changes but has nothing about 
> implementation in the runtime.


Hi Alexey, thanks for asking. The runtime implementation I'm thinking of is to 
convert the non-contiguous data into several chunks of contiguous.

For example:

int arr[3][3][3];

#pragma omp target update to (arr[1:2][1:2][0:2])

We can visualize the noncontiguous data as below (X is the data we want to 
transfer, O is the data want don't bother with):

Dim 0 = {Offset: 0, Count: 1, Stride: 4bytes (int)}
XXO

Dim 1 = {Offset: 1, Count: 2, Stride: 12bytes (4 * 3 - since Dim 0 has 3 
elements)
OOO
XXO
XXO

Dim 2 = {Offset: 1, Count: 2, Stride: 36 bytes (12 * 3 since Dim 1 has 3 
elements)
OOO
OOO
OOO
\
OOO
XXO
XXO
\
OOO
XXO
XXO

For the visualization, we know that we want to transfer 4 contiguous chunks and 
the runtime code could be something similar to:

  // we expect this loop to transfer 4 contiguous chunks:
  // arr[1][1][0:2]
  // arr[1][2][0:2]
  // arr[2][1][0:2]
  // arr[2][2][0:2]
  for (int i = Dim[2].offset; i < Dim[2].count; i++) {
for (int j = Dim[1].offset; j < Dim[1].count; j++) {
  ptr = bast_ptr + Dim[2].stride * i + Dim[1].stride * j + Dim[2].stride * 
Dim[0].offset;
  size = Dim[0].count * Dim[0].stride;  // we can hoist it I think
  transfer(ptr, size, /*flag or some other stuff...*/);
}
  }


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79972



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

[PATCH] D80222: Replace Clang's createRuntimeFunction with the definitions in OMPKinds.def

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added inline comments.



Comment at: openmp/runtime/test/tasking/kmp_taskloop.c:100
 th_counter[i] = 0;
-#pragma omp parallel num_threads(N)
+#pragma omp parallel // num_threads(N)
 {

jhuber6 wrote:
> jdoerfert wrote:
> > jhuber6 wrote:
> > > AndreyChurbanov wrote:
> > > > jhuber6 wrote:
> > > > > jhuber6 wrote:
> > > > > > jdoerfert wrote:
> > > > > > > jhuber6 wrote:
> > > > > > > > I am not entirely sure why, but commenting this out causes the 
> > > > > > > > problem to go away. I tried adding proper names to the 
> > > > > > > > forward-declared functions but since clang already knew I had 
> > > > > > > > something called ident_t, I couldn't declare a new struct with 
> > > > > > > > the same name.
> > > > > > > This is not good. The difference should only be that the 
> > > > > > > `kmpc_fork_call` has a different argument, right? Does the 
> > > > > > > segfault happen at compile or runtime?
> > > > > > > 
> > > > > > > You can just use the ident_t clang created, right? Did you print 
> > > > > > > the function names requested by clang as we discussed?
> > > > > > I added an assertion and debug statements. If I try to declare a 
> > > > > > struct named "Ident_t" I get the following error message in the 
> > > > > > seg-fault. I think the seg-fault is compile-time.
> > > > > > 
> > > > > > Found OpenMP runtime function __kmpc_global_thread_num with type 
> > > > > > i32 (%struct.ident_t.0*). Expected type is i32 (%struct.ident_t*)
> > > > > > clang: 
> > > > > > /home/jhuber/Documents/llvm-project/llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:124:
> > > > > >  static llvm::Function* 
> > > > > > llvm::OpenMPIRBuilder::getOrCreateRuntimeFunction(llvm::Module&, 
> > > > > > llvm::omp::RuntimeFunction): Assertion `FnTy == 
> > > > > > Fn->getFunctionType() && "Found OpenMP runtime function has 
> > > > > > mismatched types"' failed.
> > > > > I'm not sure if there's a way around this without changing the 
> > > > > getOrCreateRuntimeFunction method to return a FunctionCallee and 
> > > > > removing the assertion. Clang doesn't know about the ident_t struct 
> > > > > when it's compiling the file, but when its doing the codegen it sees 
> > > > > two structs with the same name and creates a new name. So when it 
> > > > > gets the types it says that ident_t and ident_t.0 don't match. As you 
> > > > > said the old version got around this by adding a bitcasting 
> > > > > instruction so it knew how to turn it into an ident_t pointer.
> > > > Note that this change breaks the test on any system with more that 4 
> > > > procs.  Because array th_counter[4] is indexed by thread number which 
> > > > can easily be greater than 3 if number of threads is not limited.
> > > The problem was that the num_threads clause required an implicit call to 
> > > kmpc_global_thread_num so it could be passed to kmpc_push_num_threads. 
> > > The types of the implicit function and the forward declaration then 
> > > wouldn't match up. I added another forward declaration to explicitly call 
> > > kmpc_push_num_threads. Is this a sufficient solution?
> > We need this to work with num_threads(8). 
> > 
> > > Clang doesn't know about the ident_t struct when it's compiling the file, 
> > > but when its doing the codegen it sees two structs with the same name and 
> > > creates a new name.
> > 
> > Where are the two structs coming from? We should have one. If clang 
> > introduces one it needs to use the one from OMPKindes.def instead. Is that 
> > a fix?
> The first struct is the one that I'm assuming comes from the OpenMP CodeGen 
> that places the Ident_t struct in the IR file. if I declare a struct also 
> named ident_t in the C source file it most likely will see that there's two 
> structs with the same name and call the second one "ident_t.0" internally. 
> The other ident_t struct is only known once clang generates the LLVM IR so I 
> can't just use "ident_t" nor can I declare a struct with the same name.
1) Either Clang needs to use the `llvm::omp::types::Ident` *or* Clang needs to 
define `llvm::omp::types::Ident` and we do not do it via  
`__OMP_STRUCT_TYPE(Ident, ident_t, Int32, Int32, Int32, Int32, Int8Ptr)`. I 
would prefer the first solution. 

2) `OMPConstants.cpp` does pick up an existing struct type with the same name 
if present. That is, probably not what we want because it clashes with user 
types.

3) We can still return a `FunctionCallee` with the Function* and the expected 
type (as defined by OMPKinds.def) to mimic the old behavior for now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80222



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

[PATCH] D80660: clang: Add support for relative linker paths with -fuse-ld

[Keith Smiley via Phabricator via cfe-commits]

keith created this revision.
keith added reviewers: kastiglione, MaskRay, theraven, rnk.
Herald added a project: clang.

This adds support for resolving linker executable paths relatively
instead of requiring them to be names, or absolute paths. This is useful
if you're vendoring an in-tree linker, and do not want to potentially
invalidate shared remote caches by using local absolute paths in command
lines.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D80660

Files:
  clang/lib/Driver/ToolChain.cpp
  clang/test/Driver/fuse-ld.c


Index: clang/test/Driver/fuse-ld.c
===
--- clang/test/Driver/fuse-ld.c
+++ clang/test/Driver/fuse-ld.c
@@ -4,6 +4,20 @@
 // RUN:   | FileCheck %s --check-prefix=CHECK-ABSOLUTE-LD
 // CHECK-ABSOLUTE-LD: /usr/local/bin/or1k-linux-ld
 
+// RUN: cd "%S" && %clang %s -### \
+// RUN: -fuse-ld=Inputs/fuse_ld_windows/ld.foo.exe 2>&1 \
+// RUN: -target x86_64-unknown-linux \
+// RUN:   | FileCheck %s --check-prefix=CHECK-RELATIVE-LD
+// CHECK-RELATIVE-LD-NOT: error: invalid linker name
+// CHECK-RELATIVE-LD: test/Driver/Inputs/fuse_ld_windows/ld.foo.exe
+
+// RUN: %clang %s -### \
+// RUN: -fuse-ld=fuse_ld_windows/ld.foo.exe 2>&1 \
+// RUN: -target x86_64-unknown-linux \
+// RUN: -working-directory "%S/Inputs" \
+// RUN:   | FileCheck %s --check-prefix=CHECK-RELATIVE-WORKDIR-LD
+// CHECK-RELATIVE-WORKDIR-LD-NOT: error: invalid linker name
+// CHECK-RELATIVE-WORKDIR-LD: test/Driver/Inputs/fuse_ld_windows/ld.foo.exe
 
 // RUN: %clang %s -### \
 // RUN: -target x86_64-unknown-freebsd 2>&1 \
Index: clang/lib/Driver/ToolChain.cpp
===
--- clang/lib/Driver/ToolChain.cpp
+++ clang/lib/Driver/ToolChain.cpp
@@ -554,6 +554,18 @@
 std::string LinkerPath(GetProgramPath(LinkerName.c_str()));
 if (llvm::sys::fs::can_execute(LinkerPath))
   return LinkerPath;
+
+const Arg *WorkingDir = Args.getLastArg(options::OPT_working_directory);
+SmallString<128> ResolvedPath(UseLinker);
+if (WorkingDir) {
+  sys::fs::make_absolute(WorkingDir->getValue(), ResolvedPath);
+  if (llvm::sys::fs::can_execute(ResolvedPath))
+return std::string(ResolvedPath);
+}
+
+if (!sys::fs::make_absolute(ResolvedPath) &&
+llvm::sys::fs::can_execute(ResolvedPath))
+  return std::string(ResolvedPath);
   }
 
   if (A)


Index: clang/test/Driver/fuse-ld.c
===
--- clang/test/Driver/fuse-ld.c
+++ clang/test/Driver/fuse-ld.c
@@ -4,6 +4,20 @@
 // RUN:   | FileCheck %s --check-prefix=CHECK-ABSOLUTE-LD
 // CHECK-ABSOLUTE-LD: /usr/local/bin/or1k-linux-ld
 
+// RUN: cd "%S" && %clang %s -### \
+// RUN: -fuse-ld=Inputs/fuse_ld_windows/ld.foo.exe 2>&1 \
+// RUN: -target x86_64-unknown-linux \
+// RUN:   | FileCheck %s --check-prefix=CHECK-RELATIVE-LD
+// CHECK-RELATIVE-LD-NOT: error: invalid linker name
+// CHECK-RELATIVE-LD: test/Driver/Inputs/fuse_ld_windows/ld.foo.exe
+
+// RUN: %clang %s -### \
+// RUN: -fuse-ld=fuse_ld_windows/ld.foo.exe 2>&1 \
+// RUN: -target x86_64-unknown-linux \
+// RUN: -working-directory "%S/Inputs" \
+// RUN:   | FileCheck %s --check-prefix=CHECK-RELATIVE-WORKDIR-LD
+// CHECK-RELATIVE-WORKDIR-LD-NOT: error: invalid linker name
+// CHECK-RELATIVE-WORKDIR-LD: test/Driver/Inputs/fuse_ld_windows/ld.foo.exe
 
 // RUN: %clang %s -### \
 // RUN: -target x86_64-unknown-freebsd 2>&1 \
Index: clang/lib/Driver/ToolChain.cpp
===
--- clang/lib/Driver/ToolChain.cpp
+++ clang/lib/Driver/ToolChain.cpp
@@ -554,6 +554,18 @@
 std::string LinkerPath(GetProgramPath(LinkerName.c_str()));
 if (llvm::sys::fs::can_execute(LinkerPath))
   return LinkerPath;
+
+const Arg *WorkingDir = Args.getLastArg(options::OPT_working_directory);
+SmallString<128> ResolvedPath(UseLinker);
+if (WorkingDir) {
+  sys::fs::make_absolute(WorkingDir->getValue(), ResolvedPath);
+  if (llvm::sys::fs::can_execute(ResolvedPath))
+return std::string(ResolvedPath);
+}
+
+if (!sys::fs::make_absolute(ResolvedPath) &&
+llvm::sys::fs::can_execute(ResolvedPath))
+  return std::string(ResolvedPath);
   }
 
   if (A)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D80225: [Driver] Recognize -fuse-ld={bfd, gold, lld} but don't prepend "ld." or "ld64." for other values

[Keith Smiley via Phabricator via cfe-commits]

keith added a comment.

I've submitted a related change to accept relative paths for `-fuse-ld` 
https://reviews.llvm.org/D80660


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80225



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

[PATCH] D80654: WIP: Make it possible to use the traverse() matcher in clang-query

[Yitzhak Mandelbaum via Phabricator via cfe-commits]

ymandel added a comment.

Thanks, this looks quite useful. I should be able to look it over in full 
tomorrow.




Comment at: clang/include/clang/ASTMatchers/ASTMatchersInternal.h:383
+  static DynTypedMatcher
+  constructTraversalWrapper(const DynTypedMatcher ,
+ast_type_traits::TraversalKind TK);

I need this for my fix to Transformer. In fact, this is the only thing I need, 
rather than an overload of `traverse` for `DynTypedMatcher`.  Do you want me to 
split this into its own patch and send to you? Or, vice versa?

Also, whay `const DynTypedMatcher `? Given that it is immediately 
copied, why not just `DynTypedMatcher InnerMatcher`, which at least allows the 
caller to move-construct the argument and avoid the copy?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80654



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

[PATCH] D69764: [clang-format] Add East/West Const fixer capability

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

@rsmith, Thank you for your comments, I don't agree, but thank you anyway.

I will continue to feel there is some value here, My hope is that others will 
feel the same.


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

https://reviews.llvm.org/D69764



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

[PATCH] D80222: Replace Clang's createRuntimeFunction with the definitions in OMPKinds.def

[Joseph Huber via Phabricator via cfe-commits]

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



Comment at: openmp/runtime/test/tasking/kmp_taskloop.c:100
 th_counter[i] = 0;
-#pragma omp parallel num_threads(N)
+#pragma omp parallel // num_threads(N)
 {

jdoerfert wrote:
> jhuber6 wrote:
> > AndreyChurbanov wrote:
> > > jhuber6 wrote:
> > > > jhuber6 wrote:
> > > > > jdoerfert wrote:
> > > > > > jhuber6 wrote:
> > > > > > > I am not entirely sure why, but commenting this out causes the 
> > > > > > > problem to go away. I tried adding proper names to the 
> > > > > > > forward-declared functions but since clang already knew I had 
> > > > > > > something called ident_t, I couldn't declare a new struct with 
> > > > > > > the same name.
> > > > > > This is not good. The difference should only be that the 
> > > > > > `kmpc_fork_call` has a different argument, right? Does the segfault 
> > > > > > happen at compile or runtime?
> > > > > > 
> > > > > > You can just use the ident_t clang created, right? Did you print 
> > > > > > the function names requested by clang as we discussed?
> > > > > I added an assertion and debug statements. If I try to declare a 
> > > > > struct named "Ident_t" I get the following error message in the 
> > > > > seg-fault. I think the seg-fault is compile-time.
> > > > > 
> > > > > Found OpenMP runtime function __kmpc_global_thread_num with type i32 
> > > > > (%struct.ident_t.0*). Expected type is i32 (%struct.ident_t*)
> > > > > clang: 
> > > > > /home/jhuber/Documents/llvm-project/llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:124:
> > > > >  static llvm::Function* 
> > > > > llvm::OpenMPIRBuilder::getOrCreateRuntimeFunction(llvm::Module&, 
> > > > > llvm::omp::RuntimeFunction): Assertion `FnTy == Fn->getFunctionType() 
> > > > > && "Found OpenMP runtime function has mismatched types"' failed.
> > > > I'm not sure if there's a way around this without changing the 
> > > > getOrCreateRuntimeFunction method to return a FunctionCallee and 
> > > > removing the assertion. Clang doesn't know about the ident_t struct 
> > > > when it's compiling the file, but when its doing the codegen it sees 
> > > > two structs with the same name and creates a new name. So when it gets 
> > > > the types it says that ident_t and ident_t.0 don't match. As you said 
> > > > the old version got around this by adding a bitcasting instruction so 
> > > > it knew how to turn it into an ident_t pointer.
> > > Note that this change breaks the test on any system with more that 4 
> > > procs.  Because array th_counter[4] is indexed by thread number which can 
> > > easily be greater than 3 if number of threads is not limited.
> > The problem was that the num_threads clause required an implicit call to 
> > kmpc_global_thread_num so it could be passed to kmpc_push_num_threads. The 
> > types of the implicit function and the forward declaration then wouldn't 
> > match up. I added another forward declaration to explicitly call 
> > kmpc_push_num_threads. Is this a sufficient solution?
> We need this to work with num_threads(8). 
> 
> > Clang doesn't know about the ident_t struct when it's compiling the file, 
> > but when its doing the codegen it sees two structs with the same name and 
> > creates a new name.
> 
> Where are the two structs coming from? We should have one. If clang 
> introduces one it needs to use the one from OMPKindes.def instead. Is that a 
> fix?
The first struct is the one that I'm assuming comes from the OpenMP CodeGen 
that places the Ident_t struct in the IR file. if I declare a struct also named 
ident_t in the C source file it most likely will see that there's two structs 
with the same name and call the second one "ident_t.0" internally. The other 
ident_t struct is only known once clang generates the LLVM IR so I can't just 
use "ident_t" nor can I declare a struct with the same name.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80222



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

[PATCH] D76793: [Matrix] Implement + and - operators for MatrixType.

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: clang/lib/Sema/SemaOverload.cpp:8587
+if (S.Context.hasSameType(M1, M2))
+  AddCandidate(M1, M2);
+

I don't think this works if one side or the other has e.g. a templated 
conversion to a matrix type.  You need to add:

```
   (M1, M1) -> M1
   (M1, M1.ElementType) -> M1
   (M2, M2) -> M2// but don't introduce the same candidate twice if the 
same type is also in the LHS set)
   (M2.ElementType, M2) -> M2
```

Test case is something like:

```
struct identmatrix_t {
  template 
  operator matrix_type() const {
matrix_type result = {};
for (unsigned i = 0; i != N; ++i) result[i][i] = 1;
return result;
  }
};
constexpr identmatrix_t identmatrix = identmatrix();

...
m + identmatrix
```

Also, these operator candidates are only for specific operators, right?  I 
think you can check what the operator is.



Comment at: clang/lib/Sema/SemaOverload.cpp:8593
+  AddCandidate(cast(M2)->getElementType(), M2);
   }
 

Idiomatically, we just copy `QualType` instead of binding references to it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76793



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

[PATCH] D69764: [clang-format] Add East/West Const fixer capability

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay updated this revision to Diff 266647.
MyDeveloperDay added a comment.

Begin to cover the cases raised as potential code-breaking changes by ignoring 
potential MACRO usage
add support for more complex `const unsigned long long` cases   (I believe I 
can simplify this to a more general pattern)


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

https://reviews.llvm.org/D69764

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/CMakeLists.txt
  clang/lib/Format/EastWestConstFixer.cpp
  clang/lib/Format/EastWestConstFixer.h
  clang/lib/Format/Format.cpp
  clang/tools/clang-format/ClangFormat.cpp
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -13628,6 +13628,13 @@
   CHECK_PARSE("ContinuationIndentWidth: 11", ContinuationIndentWidth, 11u);
   CHECK_PARSE("CommentPragmas: '// abc$'", CommentPragmas, "// abc$");
 
+  Style.ConstPlacement = FormatStyle::CS_West;
+  CHECK_PARSE("ConstPlacement: Leave", ConstPlacement, FormatStyle::CS_Leave);
+  CHECK_PARSE("ConstPlacement: East", ConstPlacement, FormatStyle::CS_East);
+  CHECK_PARSE("ConstPlacement: West", ConstPlacement, FormatStyle::CS_West);
+  CHECK_PARSE("ConstPlacement: Right", ConstPlacement, FormatStyle::CS_East);
+  CHECK_PARSE("ConstPlacement: Left", ConstPlacement, FormatStyle::CS_West);
+
   Style.PointerAlignment = FormatStyle::PAS_Middle;
   CHECK_PARSE("PointerAlignment: Left", PointerAlignment,
   FormatStyle::PAS_Left);
@@ -16572,6 +16579,326 @@
"}",
Style);
 }
+
+TEST_F(FormatTest, EastWestConst) {
+  FormatStyle Style = getLLVMStyle();
+
+  // keep the const style unaltered
+  verifyFormat("const int a;", Style);
+  verifyFormat("const int *a;", Style);
+  verifyFormat("const int ", Style);
+  verifyFormat("const int &", Style);
+  verifyFormat("int const b;", Style);
+  verifyFormat("int const *b;", Style);
+  verifyFormat("int const ", Style);
+  verifyFormat("int const &", Style);
+  verifyFormat("int const *b const;", Style);
+  verifyFormat("int *const c;", Style);
+
+  verifyFormat("const Foo a;", Style);
+  verifyFormat("const Foo *a;", Style);
+  verifyFormat("const Foo ", Style);
+  verifyFormat("const Foo &", Style);
+  verifyFormat("Foo const b;", Style);
+  verifyFormat("Foo const *b;", Style);
+  verifyFormat("Foo const ", Style);
+  verifyFormat("Foo const &", Style);
+  verifyFormat("Foo const *b const;", Style);
+
+  verifyFormat("LLVM_NODISCARD const int ();", Style);
+  verifyFormat("LLVM_NODISCARD int const ();", Style);
+
+  verifyFormat("volatile const int *restrict;", Style);
+  verifyFormat("const volatile int *restrict;", Style);
+  verifyFormat("const int volatile *restrict;", Style);
+}
+
+TEST_F(FormatTest, EastConst) {
+  FormatStyle Style = getLLVMStyle();
+  Style.ConstPlacement = FormatStyle::CS_East;
+
+  
+  verifyFormat("int const a;", Style);
+  verifyFormat("int const *a;", Style);
+  verifyFormat("int const ", Style);
+  verifyFormat("int const &", Style);
+  verifyFormat("int const b;", Style);
+  verifyFormat("int const *b;", Style);
+  verifyFormat("int const ", Style);
+  verifyFormat("int const &", Style);
+  verifyFormat("int const *b const;", Style);
+  verifyFormat("int *const c;", Style);
+
+  verifyFormat("Foo const a;", Style);
+  verifyFormat("Foo const *a;", Style);
+  verifyFormat("Foo const ", Style);
+  verifyFormat("Foo const &", Style);
+  verifyFormat("Foo const b;", Style);
+  verifyFormat("Foo const *b;", Style);
+  verifyFormat("Foo const ", Style);
+  verifyFormat("Foo const &", Style);
+  verifyFormat("Foo const *b const;", Style);
+  verifyFormat("Foo *const b;", Style);
+  verifyFormat("Foo const *const b;", Style);
+  verifyFormat("auto const v = get_value();", Style);
+  verifyFormat("long long const ", Style);
+  verifyFormat("unsigned char const *a;", Style);
+  verifyFormat("int main(int const argc, char const *const *const argv)",
+   Style);
+
+  verifyFormat("LLVM_NODISCARD int const ();", Style);
+  verifyFormat("SourceRange getSourceRange() const override LLVM_READONLY",
+   Style);
+  verifyFormat("void foo() const override;", Style);
+  verifyFormat("void foo() const override LLVM_READONLY;", Style);
+  verifyFormat("void foo() const final;", Style);
+  verifyFormat("void foo() const final LLVM_READONLY;", Style);
+  verifyFormat("void foo() const LLVM_READONLY;", Style);
+
+  verifyFormat(
+  "template  explicit Action(Action const );",
+  Style);
+  verifyFormat(
+  "template  explicit Action(Action const );",
+  "template  explicit Action(const Action& action);",
+  Style);
+  verifyFormat(
+  "template  explicit Action(Action const );",
+  "template \nexplicit 

[PATCH] D79945: [Sema] Comparison of pointers to complete and incomplete types

[Benson Chu via Phabricator via cfe-commits]

pestctrl updated this revision to Diff 266645.
pestctrl marked an inline comment as done.
pestctrl added a comment.

ext_typecheck_compare_complete_incomplete_pointers:

- Moved to group C11.

ext_typecheck_compare_complete_incomplete_pointers:

- Changed to Warning from ExtWarn
- Moved to group C99Compat
- Added DefaultIgnore


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79945

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaExpr.cpp
  clang/test/Sema/complete-incomplete-pointer-relational-c99.c


Index: clang/test/Sema/complete-incomplete-pointer-relational-c99.c
===
--- /dev/null
+++ clang/test/Sema/complete-incomplete-pointer-relational-c99.c
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c99 -Wc99-compat %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c89 -Wc99-compat %s
+// RUN: %clang_cc1 -fsyntax-only -verify -Wc11-extensions %s
+
+int incomplete[]; // expected-warning {{tentative array definition assumed to 
have one element}}
+int complete[6];
+
+int test_comparison_between_incomplete_and_complete_pointer() {
+  return
+ <   && // expected-warning {{ordered comparison of 
complete and incomplete pointers}}
+ <=  && // expected-warning {{ordered comparison of 
complete and incomplete pointers}}
+ >   && // expected-warning {{ordered comparison of 
complete and incomplete pointers}}
+ >=  && // expected-warning {{ordered comparison of 
complete and incomplete pointers}}
+ ==  &&
+ != 
+}
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -11422,11 +11422,23 @@
 // C99 6.5.9p2 and C99 6.5.8p2
 if (Context.typesAreCompatible(LCanPointeeTy.getUnqualifiedType(),
RCanPointeeTy.getUnqualifiedType())) {
-  // Valid unless a relational comparison of function pointers
-  if (IsRelational && LCanPointeeTy->isFunctionType()) {
-Diag(Loc, diag::ext_typecheck_ordered_comparison_of_function_pointers)
-  << LHSType << RHSType << LHS.get()->getSourceRange()
-  << RHS.get()->getSourceRange();
+  if (IsRelational) {
+// Pointers both need to point to complete or incomplete types
+if (LCanPointeeTy->isIncompleteType() !=
+RCanPointeeTy->isIncompleteType()) {
+  Diag(Loc,
+   getLangOpts().C11
+   ? diag::ext_typecheck_compare_complete_incomplete_pointers
+   : diag::warn_typecheck_compare_complete_incomplete_pointers)
+  << LHSType << RHSType << LHS.get()->getSourceRange()
+  << RHS.get()->getSourceRange();
+}
+if (LCanPointeeTy->isFunctionType()) {
+  // Valid unless a relational comparison of function pointers
+  Diag(Loc, 
diag::ext_typecheck_ordered_comparison_of_function_pointers)
+  << LHSType << RHSType << LHS.get()->getSourceRange()
+  << RHS.get()->getSourceRange();
+}
   }
 } else if (!IsRelational &&
(LCanPointeeTy->isVoidType() || RCanPointeeTy->isVoidType())) {
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -6441,6 +6441,12 @@
   "ordered comparison between pointer and zero (%0 and %1)">;
 def err_typecheck_three_way_comparison_of_pointer_and_zero : Error<
   "three-way comparison between pointer and zero">;
+def ext_typecheck_compare_complete_incomplete_pointers : Extension<
+  "ordered comparison of complete and incomplete pointers (%0 and %1)">,
+  InGroup;
+def warn_typecheck_compare_complete_incomplete_pointers : Warning<
+  "ordered comparison of complete and incomplete pointers (%0 and %1)">,
+  InGroup, DefaultIgnore;
 def ext_typecheck_ordered_comparison_of_function_pointers : ExtWarn<
   "ordered comparison of function pointers (%0 and %1)">,
   InGroup>;


Index: clang/test/Sema/complete-incomplete-pointer-relational-c99.c
===
--- /dev/null
+++ clang/test/Sema/complete-incomplete-pointer-relational-c99.c
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c99 -Wc99-compat %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c89 -Wc99-compat %s
+// RUN: %clang_cc1 -fsyntax-only -verify -Wc11-extensions %s
+
+int incomplete[]; // expected-warning {{tentative array definition assumed to have one element}}
+int complete[6];
+
+int test_comparison_between_incomplete_and_complete_pointer() {
+  return
+ <   && // expected-warning {{ordered comparison of complete and incomplete pointers}}
+ <=  && // expected-warning {{ordered 

[PATCH] D80369: [DebugInfo][CallSites] Remove decl subprograms from 'retainedTypes:'

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

In D80369#2057874 , @aprantl wrote:

> > The declaration subprograms are in the retained types list - but when 
> > retained types are emitted, only types in the retained types list are used, 
> > the subprograms (and the types they only indirectly reference) are ignored.
>
> So adding the subprogram nodes to retained types has no effect?


So far as I can tell. The only use (other than serializing and deserializing) 
of retained types seems to be here: 
https://github.com/llvm-mirror/llvm/blob/master/lib/CodeGen/AsmPrinter/DwarfDebug.cpp#L882
 which filter only the types in the retained types list. I'd say, even, that 
the retained types list should probably be only types (verifier check?) 
unless/until we have a use case otherwise. (& if anyone wants to merge the 
enums list with the retained types list, that'd be a nice cleanup too).

> That's good to know. I think we can remove the code then, as long as the 
> existing tests aren't affected.




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

https://reviews.llvm.org/D80369



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

[PATCH] D79945: [Sema] Comparison of pointers to complete and incomplete types

[Benson Chu via Phabricator via cfe-commits]

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



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:6447
+  InGroup;
+def warn_typecheck_compare_complete_incomplete_pointers : ExtWarn<
+  "ordered comparison of complete and incomplete pointers (%0 and %1)">,

efriedma wrote:
> warn_typecheck_compare_complete_incomplete_pointers should be a Warning, not 
> an ExtWarn.  And should be DefaultIgnore.  And should indicate why we're 
> warning.  And should be in the group C99Compat.
I'm confused by what you mean for "indicate why we're warning". Should I change 
the warning text?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79945



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

[PATCH] D80222: Replace Clang's createRuntimeFunction with the definitions in OMPKinds.def

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added inline comments.



Comment at: openmp/runtime/test/tasking/kmp_taskloop.c:100
 th_counter[i] = 0;
-#pragma omp parallel num_threads(N)
+#pragma omp parallel // num_threads(N)
 {

jhuber6 wrote:
> AndreyChurbanov wrote:
> > jhuber6 wrote:
> > > jhuber6 wrote:
> > > > jdoerfert wrote:
> > > > > jhuber6 wrote:
> > > > > > I am not entirely sure why, but commenting this out causes the 
> > > > > > problem to go away. I tried adding proper names to the 
> > > > > > forward-declared functions but since clang already knew I had 
> > > > > > something called ident_t, I couldn't declare a new struct with the 
> > > > > > same name.
> > > > > This is not good. The difference should only be that the 
> > > > > `kmpc_fork_call` has a different argument, right? Does the segfault 
> > > > > happen at compile or runtime?
> > > > > 
> > > > > You can just use the ident_t clang created, right? Did you print the 
> > > > > function names requested by clang as we discussed?
> > > > I added an assertion and debug statements. If I try to declare a struct 
> > > > named "Ident_t" I get the following error message in the seg-fault. I 
> > > > think the seg-fault is compile-time.
> > > > 
> > > > Found OpenMP runtime function __kmpc_global_thread_num with type i32 
> > > > (%struct.ident_t.0*). Expected type is i32 (%struct.ident_t*)
> > > > clang: 
> > > > /home/jhuber/Documents/llvm-project/llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:124:
> > > >  static llvm::Function* 
> > > > llvm::OpenMPIRBuilder::getOrCreateRuntimeFunction(llvm::Module&, 
> > > > llvm::omp::RuntimeFunction): Assertion `FnTy == Fn->getFunctionType() 
> > > > && "Found OpenMP runtime function has mismatched types"' failed.
> > > I'm not sure if there's a way around this without changing the 
> > > getOrCreateRuntimeFunction method to return a FunctionCallee and removing 
> > > the assertion. Clang doesn't know about the ident_t struct when it's 
> > > compiling the file, but when its doing the codegen it sees two structs 
> > > with the same name and creates a new name. So when it gets the types it 
> > > says that ident_t and ident_t.0 don't match. As you said the old version 
> > > got around this by adding a bitcasting instruction so it knew how to turn 
> > > it into an ident_t pointer.
> > Note that this change breaks the test on any system with more that 4 procs. 
> >  Because array th_counter[4] is indexed by thread number which can easily 
> > be greater than 3 if number of threads is not limited.
> The problem was that the num_threads clause required an implicit call to 
> kmpc_global_thread_num so it could be passed to kmpc_push_num_threads. The 
> types of the implicit function and the forward declaration then wouldn't 
> match up. I added another forward declaration to explicitly call 
> kmpc_push_num_threads. Is this a sufficient solution?
We need this to work with num_threads(8). 

> Clang doesn't know about the ident_t struct when it's compiling the file, but 
> when its doing the codegen it sees two structs with the same name and creates 
> a new name.

Where are the two structs coming from? We should have one. If clang introduces 
one it needs to use the one from OMPKindes.def instead. Is that a fix?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80222



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

[PATCH] D76791: [Matrix] Implement matrix index expressions ([][]).

[Florian Hahn via Phabricator via cfe-commits]

fhahn updated this revision to Diff 266643.
fhahn marked 4 inline comments as done.
fhahn added a comment.

Addressed latest comments:

- Handle placeholder types in CreateBuiltinMatrixSubscriptExpr and do not limit 
to non-overload types there.
- Check !MatrixSubscriptExpr instead of ParenExpr.
- Only handle placeholder types for Base in ActOnMatrixSubscriptExpr. Only skip 
isMSPropertySubscriptExpr.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76791

Files:
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/BuiltinTypes.def
  clang/include/clang/AST/ComputeDependence.h
  clang/include/clang/AST/Expr.h
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/AST/Stmt.h
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/Specifiers.h
  clang/include/clang/Basic/StmtNodes.td
  clang/include/clang/Sema/Initialization.h
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ComputeDependence.cpp
  clang/lib/AST/Expr.cpp
  clang/lib/AST/ExprClassification.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/NSAPI.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/AST/StmtProfile.cpp
  clang/lib/AST/TextNodeDumper.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypeLoc.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/CodeGen/CGValue.h
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaExceptionSpec.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaInit.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTCommon.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriterStmt.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
  clang/test/CodeGen/matrix-type-operators.c
  clang/test/CodeGenCXX/matrix-type-operators.cpp
  clang/test/CodeGenObjC/matrix-type-operators.m
  clang/test/Sema/matrix-type-operators.c
  clang/test/SemaCXX/matrix-type-operators.cpp
  clang/test/SemaObjC/matrix-type-operators.m
  clang/tools/libclang/CXCursor.cpp
  llvm/include/llvm/IR/MatrixBuilder.h

Index: llvm/include/llvm/IR/MatrixBuilder.h
===
--- llvm/include/llvm/IR/MatrixBuilder.h
+++ llvm/include/llvm/IR/MatrixBuilder.h
@@ -155,15 +155,19 @@
 return B.CreateMul(LHS, ScalarVector);
   }
 
-  /// Extracts the element at (\p Row, \p Column) from \p Matrix.
-  Value *CreateExtractMatrix(Value *Matrix, Value *Row, Value *Column,
- unsigned NumRows, Twine const  = "") {
-
+  /// Extracts the element at (\p RowIdx, \p ColumnIdx) from \p Matrix.
+  Value *CreateExtractElement(Value *Matrix, Value *RowIdx, Value *ColumnIdx,
+  unsigned NumRows, Twine const  = "") {
+
+unsigned MaxWidth = std::max(RowIdx->getType()->getScalarSizeInBits(),
+ ColumnIdx->getType()->getScalarSizeInBits());
+Type *IntTy = IntegerType::get(RowIdx->getType()->getContext(), MaxWidth);
+RowIdx = B.CreateZExt(RowIdx, IntTy);
+ColumnIdx = B.CreateZExt(ColumnIdx, IntTy);
+Value *NumRowsV = B.getIntN(MaxWidth, NumRows);
 return B.CreateExtractElement(
-Matrix,
-B.CreateAdd(
-B.CreateMul(Column, ConstantInt::get(Column->getType(), NumRows)),
-Row));
+Matrix, B.CreateAdd(B.CreateMul(ColumnIdx, NumRowsV), RowIdx),
+"matext");
   }
 };
 
Index: clang/tools/libclang/CXCursor.cpp
===
--- clang/tools/libclang/CXCursor.cpp
+++ clang/tools/libclang/CXCursor.cpp
@@ -419,6 +419,11 @@
 K = CXCursor_ArraySubscriptExpr;
 break;
 
+  case Stmt::MatrixSubscriptExprClass:
+// TODO: add support for MatrixSubscriptExpr.
+K = CXCursor_UnexposedExpr;
+break;
+
   case Stmt::OMPArraySectionExprClass:
 K = CXCursor_OMPArraySectionExpr;
 break;
Index: clang/test/SemaObjC/matrix-type-operators.m
===
--- /dev/null
+++ clang/test/SemaObjC/matrix-type-operators.m
@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -fenable-matrix %s
+
+struct Foo {};
+__attribute__((objc_root_class))
+@interface FooValue
+@property struct Foo value;
+@end
+
+typedef double double4x4 __attribute__((matrix_type(4, 4)));
+
+// Check that we generate proper error messages for invalid placeholder types.
+//
+double test_index_placeholders(double4x4 m, FooValue *iv) {
+  return m[iv.value][iv.value];
+  // expected-error@-1 {{matrix row index is not an integer}}
+  // expected-error@-2 {{matrix column index is not an integer}}
+}
+
+double test_base_and_index_placeholders(FooValue *m, FooValue *iv) {
+  

[PATCH] D76791: [Matrix] Implement matrix index expressions ([][]).

[Florian Hahn via Phabricator via cfe-commits]

fhahn added inline comments.



Comment at: clang/lib/Sema/SemaExpr.cpp:4650
+  (Base->isTypeDependent() || RowIdx->isTypeDependent() ||
+   (ColumnIdx && ColumnIdx->isTypeDependent(
+return new (Context) MatrixSubscriptExpr(Base, RowIdx, ColumnIdx,

rjmccall wrote:
> fhahn wrote:
> > rjmccall wrote:
> > > Checking dependence is actually just as cheap as checking for C++, 
> > > there's no real need to gate.  But you need to check for placeholder 
> > > types in the index operands before doing these type checks.  The best 
> > > test case here is an Objective-C property reference, something like:
> > > 
> > > ```
> > > __attribute__((objc_root_class))
> > > @interface IntValue
> > > @property int value;
> > > @end
> > > 
> > > double test(double4x4 m, IntValue *iv) {
> > >   return m[iv.value][iv.value];
> > > }
> > > ```
> > > 
> > > Also, I would suggest not doing any checking on incomplete matrix 
> > > expressions; just notice that it's still incomplete, build the 
> > > expression, and return.  You can do the checking once when you have all 
> > > the operands together.
> > > Checking dependence is actually just as cheap as checking for C++, 
> > > there's no real need to gate. But you need to check for placeholder types 
> > > in the index operands before doing these type checks. The best test case 
> > > here is an Objective-C property reference, something like:
> > 
> > Done, I've added a ActOnMatrixSubscriptExpr and added code to deal with 
> > placeholder types there.
> > 
> > > Also, I would suggest not doing any checking on incomplete matrix 
> > > expressions; just notice that it's still incomplete, build the 
> > > expression, and return. You can do the checking once when you have all 
> > > the operands together.
> > 
> > Done, I initially thought it might be good to still raise an error if the 
> > row index was invalid, but given that it's not a valid expression anyways 
> > that probably is not too helpful anyways. Doing the checks on the complete 
> > expression simplifies things a bit :)
> Placeholders actually need to be handled in the `Build` function — they can 
> come up in template instantiation, too.
Move, thanks! I think we have to retain checking placeholder expressions for 
base below, as noted in the response below.



Comment at: clang/lib/Sema/SemaExpr.cpp:4645
+  // Separating the index expressions by parenthesis is not allowed.
+  if (isa(Base) && Base->getType()->isSpecificPlaceholderType(
+  BuiltinType::IncompleteMatrixIdx)) {

rjmccall wrote:
> Don't check for `ParenExpr` specifically; there are other expressions that 
> are handled the same way, like `_Generic`.  You need to check for 
> `!isa`.
Done, thanks!



Comment at: clang/lib/Sema/SemaExpr.cpp:4655
+  // type, in which case the overload resolution for the operator overload
+  // should get the first crack at the overload.
+

rjmccall wrote:
> Overload placeholder types are used for things like `` where `foo` is the 
> name of an overloaded function.  The places that resolve only non-overload 
> placeholder types are doing so in order to leave room for overload resolution 
> to resolve the overload later, e.g. as part of non-builtin operator handling. 
>  `operator[]` is like `operator()`: non-builtin operators are only considered 
> when the base has class type.  Since you already know that the base type is a 
> matrix type, you know that you're using your standard rules, and your 
> standard rules have no way to resolve overloads in the index types — 
> correctly, since indexes can't be functions or member pointers.
> 
> tl;dr: You can (and should) resolve all placeholders here, not just 
> non-overload placeholders.
Thanks for the clarification. I moved the code to deal with placeholders to 
CreateBuiltinMatrixSubscriptExpr and removed the non-overload restriction there.

I think we still need to keep dealing with placeholders in `Base` below, to 
ensure we do not miss that the base is actually a matrix type, e.g. to support. 
It seems it is enough to skip` isMSPropertySubscriptExpr` there (without that 
restriction, some non-matrix-type codegen tests start to fail. Does that make 
sense?

```
__attribute__((objc_root_class))
@interface MatrixValue
@property double4x4 value;
@end
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76791



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

[PATCH] D80603: add isAtPosition narrowing matcher for parmVarDecl

[Vy Nguyen via Phabricator via cfe-commits]

oontvoo updated this revision to Diff 266642.
oontvoo added a comment.

Remove unrelated doc generated by the script


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80603

Files:
  clang/docs/LibASTMatchersReference.html
  clang/include/clang/ASTMatchers/ASTMatchers.h
  clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp

Index: clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
@@ -2643,6 +2643,29 @@
   parmVarDecl(hasDefaultArgument(;
 }
 
+TEST(IsAtPosition, Basic) {
+  EXPECT_TRUE(matches("void x(int a) {}", parmVarDecl(isAtPosition(0;
+  EXPECT_TRUE(matches("void x(int a, int b) {}", parmVarDecl(isAtPosition(0;
+  EXPECT_TRUE(matches("void x(int a, int b) {}", parmVarDecl(isAtPosition(1;
+  EXPECT_TRUE(notMatches("void x(int val) {}", parmVarDecl(isAtPosition(1;
+
+  // Tests with function-decls
+  EXPECT_TRUE(matches("void x(int a);", parmVarDecl(isAtPosition(0;
+  EXPECT_TRUE(matches("void x(int a, int b);", parmVarDecl(isAtPosition(0;
+  EXPECT_TRUE(matches("void x(int a, int b);", parmVarDecl(isAtPosition(1;
+  EXPECT_TRUE(notMatches("void x(int val);", parmVarDecl(isAtPosition(1;
+
+  // Tests with lamdas
+  EXPECT_TRUE(
+  matches("void x() { [](int a) {};  }", parmVarDecl(isAtPosition(0;
+  EXPECT_TRUE(matches("void x() { [](int a, int b) {}; }",
+  parmVarDecl(isAtPosition(0;
+  EXPECT_TRUE(matches("void x() { [](int a, int b) {}; }",
+  parmVarDecl(isAtPosition(1;
+  EXPECT_TRUE(
+  notMatches("void x() { [](int val) {}; }", parmVarDecl(isAtPosition(1;
+}
+
 TEST(IsArray, Basic) {
   EXPECT_TRUE(matches("struct MyClass {}; MyClass *p1 = new MyClass[10];",
   cxxNewExpr(isArray(;
Index: clang/include/clang/ASTMatchers/ASTMatchers.h
===
--- clang/include/clang/ASTMatchers/ASTMatchers.h
+++ clang/include/clang/ASTMatchers/ASTMatchers.h
@@ -4615,6 +4615,37 @@
  InnerMatcher.matches(*DeclarationStatement, Finder, Builder);
 }
 
+/// Matches the ParmVarDecl nodes that are at the N'th position in the parameter
+/// list. The parameter list could be that of either a block, function, or
+/// objc-method.
+///
+///
+/// Given
+///
+/// \code
+/// void f(int a, int b, int c) {
+/// }
+/// \endcode
+///
+/// ``parmVarDecl(isAtPosition(0))`` matches ``int a``.
+///
+/// ``parmVarDecl(isAtPosition(1))`` matches ``int b``.
+AST_MATCHER_P(clang::ParmVarDecl, isAtPosition, unsigned, N) {
+  constexpr char Name[] = "##isAtPosition_parmVar_";
+
+  // The direct parent of any parmVarDecl is a TypeLoc, and not a Decl,
+  // so we have to go up one more level.
+  return parmVarDecl(
+ hasParent(typeLoc(anyOf(hasParent(blockDecl(hasParameter(
+ N, parmVarDecl().bind(Name,
+ hasParent(objcMethodDecl(hasParameter(
+ N, parmVarDecl().bind(Name,
+ hasParent(functionDecl(hasParameter(
+ N, parmVarDecl().bind(Name))),
+ equalsBoundNode(Name))
+  .matches(Node, Finder, Builder);
+}
+
 /// Matches the index expression of an array subscript expression.
 ///
 /// Given
Index: clang/docs/LibASTMatchersReference.html
===
--- clang/docs/LibASTMatchersReference.html
+++ clang/docs/LibASTMatchersReference.html
@@ -4671,6 +4671,23 @@
 Usable as: Matcherhttps://clang.llvm.org/doxygen/classclang_1_1FunctionDecl.html;>FunctionDecl, Matcherhttps://clang.llvm.org/doxygen/classclang_1_1VarDecl.html;>VarDecl, Matcherhttps://clang.llvm.org/doxygen/classclang_1_1CXXRecordDecl.html;>CXXRecordDecl
 
 
+
+Matcherclang::ParmVarDeclisAtPositionunsigned N
+Matches the ParmVarDecl nodes that are at the N'th position in the parameter
+list. The parameter list could be that of either a block, function, or
+objc-method.
+
+
+Given
+
+void f(int a, int b, int c) {
+}
+
+``parmVarDecl(isAtPosition(0))`` matches ``int a``.
+
+``parmVarDecl(isAtPosition(1))`` matches ``int b``.
+
+
 
 
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [clang] c90e198 - Fix parsing of enum-base to follow C++11 rules.

[Richard Smith via cfe-commits]

On Tue, 26 May 2020 at 20:12, Akira Hatanaka via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On May 20, 2020, at 5:53 PM, Richard Smith  wrote:
>
> On Wed, 20 May 2020 at 16:30, Akira Hatanaka via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Hi Richard,
>>
>> It looks like this patch will reject the following code, which used to
>> compile fine:
>>
>> $ cat test.cpp
>> #include 
>>
>> typedef CF_ENUM(unsigned, TestEnum) {
>>   A = 2,
>>   B = 3,
>> };
>>
>> $ clang++ -std=c++11 -c test.cpp
>>
>> *test.cpp:3:9: **error: **non-defining declaration of enumeration with a
>> fixed underlying type is only permitted as a standalone declaration;
>> missing list of enumerators? [-Welaborated-enum-base]*
>> typedef CF_ENUM(unsigned, TestEnum) {
>>
>> The macro is defined in CFAvailability.h:
>>
>>
>> https://opensource.apple.com/source/CF/CF-855.17/CFAvailability.h.auto.html
>>
>> What’s the best way to fix this?
>>
>
> Assuming this macro is always preceded by 'typedef', how about this:
>
> -#define CF_ENUM(_type, _name) enum _name : _type _name; enum _name : _type
> +#define CF_ENUM(_type, _name) int _dummy_##_name; enum _name : _type
> _name; typedef enum _name _name; enum _name : _type
>
> Or this:
>
> +#ifdef __cplusplus
>  #define CF_ENUM(_type, _name) int _dummy_##_name; enum _name : _type
> +#else
>  #define CF_ENUM(_type, _name) enum _name : _type _name; enum _name : _type
> +#endif
>
> (One wonders why the 'typedef' is not part of the macro definition.)
>
>
> Thanks! Is there a way to avoid the dummy typedef so that it doesn’t show
> up in completions and stuff or some way in C++ to undef the typedef?
>

A typedef keyword always introduces a typedef, there's no way to remove the
typedef again afterwards, and there's no way for the typedef to be for the
enum type in valid C++ code. So I think the only option is for it to be a
typedef for some other type. You could redeclare some typedef you already
know to be in scope:

#define CF_ENUM(_type, _name) size_t size_t; enum _name : _type

... but that would do surprising things if it appeared anywhere other than
at global namespace scope.

Perhaps you could add an availability / deprecated attribute to hide the
typedef from completion (plus the 'unused' attribute to avoid warnings
about it not being used).

Alternatively you could use a _Pragma to temporarily turn off the clang
error for the invalid enum forward declaration, but presumably it would be
preferable to make the code valid rather than merely get clang to continue
accepting it?

> On May 11, 2020, at 1:37 PM, Richard Smith via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>> On Mon, 11 May 2020 at 06:37, Hans Wennborg via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> On Sat, May 9, 2020 at 4:32 AM Richard Smith via cfe-commits
>>>  wrote:
>>> >
>>> >
>>> > Author: Richard Smith
>>> > Date: 2020-05-08T19:32:00-07:00
>>> > New Revision: c90e198107431f64b73686bdce31c293e3380ac7
>>> >
>>> > URL:
>>> https://github.com/llvm/llvm-project/commit/c90e198107431f64b73686bdce31c293e3380ac7
>>> > DIFF:
>>> https://github.com/llvm/llvm-project/commit/c90e198107431f64b73686bdce31c293e3380ac7.diff
>>> >
>>> > LOG: Fix parsing of enum-base to follow C++11 rules.
>>> >
>>> > Previously we implemented non-standard disambiguation rules to
>>> > distinguish an enum-base from a bit-field but otherwise treated a :
>>> > after an elaborated-enum-specifier as introducing an enum-base. That
>>> > misparses various examples (anywhere an elaborated-type-specifier can
>>> > appear followed by a colon, such as within a ternary operator or
>>> > _Generic).
>>> >
>>> > We now implement the C++11 rules, with the old cases accepted as
>>> > extensions where that seemed reasonable. These amount to:
>>> >  * an enum-base must always be accompanied by an enum definition
>>> (except
>>> >in a standalone declaration of the form 'enum E : T;')
>>> >  * in a member-declaration, 'enum E :' always introduces an enum-base,
>>> >never a bit-field
>>> >  * in a type-specifier (or similar context), 'enum E :' is not
>>> >permitted; the colon means whatever else it would mean in that
>>> >context.
>>> >
>>> > Fixed underlying types for enums are also permitted in Objective-C and
>>> > under MS extensions, plus as a language extension in all other modes.
>>> > The behavior in ObjC and MS extensions modes is unchanged (but the
>>> > bit-field disambiguation is a bit better); remaining language modes
>>> > follow the C++11 rules.
>>> >
>>> > Fixes PR45726, PR39979, PR19810, PR44941, and most of PR24297, plus C++
>>> > core issues 1514 and 1966.
>>>
>>> Hello from Chromium :-)
>>>
>>> We saw new errors from some code in a header that looked like this:
>>>
>>>   // Adapted from NSPathUtilities.h and NSObjCRuntime.h.
>>>   typedef enum NSSearchPathDirectory : unsigned long
>>> NSSearchPathDirectory;
>>>
>>> For us we think the enum itself is enough, so we'll fix it by dropping
>>> the typedef, 

[PATCH] D80198: [clangd] locateMacroAt handles patched macros

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet updated this revision to Diff 266639.
kadircet added a comment.

- Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80198

Files:
  clang-tools-extra/clangd/Headers.cpp
  clang-tools-extra/clangd/Hover.cpp
  clang-tools-extra/clangd/Preamble.cpp
  clang-tools-extra/clangd/Preamble.h
  clang-tools-extra/clangd/SourceCode.cpp
  clang-tools-extra/clangd/SourceCode.h
  clang-tools-extra/clangd/XRefs.cpp
  clang-tools-extra/clangd/unittests/HeadersTests.cpp
  clang-tools-extra/clangd/unittests/PreambleTests.cpp

Index: clang-tools-extra/clangd/unittests/PreambleTests.cpp
===
--- clang-tools-extra/clangd/unittests/PreambleTests.cpp
+++ clang-tools-extra/clangd/unittests/PreambleTests.cpp
@@ -9,14 +9,19 @@
 #include "Annotations.h"
 #include "Compiler.h"
 #include "Headers.h"
+#include "Hover.h"
 #include "Preamble.h"
+#include "SourceCode.h"
 #include "TestFS.h"
 #include "TestTU.h"
+#include "XRefs.h"
+#include "clang/Format/Format.h"
 #include "clang/Frontend/PrecompiledPreamble.h"
 #include "clang/Lex/PreprocessorOptions.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringRef.h"
+#include "llvm/Support/Error.h"
 #include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/VirtualFileSystem.h"
 #include "gmock/gmock.h"
@@ -28,6 +33,7 @@
 
 using testing::Contains;
 using testing::Field;
+using testing::Matcher;
 using testing::MatchesRegex;
 
 namespace clang {
@@ -199,7 +205,7 @@
 ADD_FAILURE() << "Failed to build compiler invocation";
 return llvm::None;
   }
-  return ParsedAST::build(testPath("main.cpp"), TU.inputs(), std::move(CI), {},
+  return ParsedAST::build(testPath(TU.Filename), TU.inputs(), std::move(CI), {},
   BaselinePreamble);
 }
 
@@ -228,7 +234,8 @@
 #define BAR
 [[BAR]])cpp",
   R"cpp(#line 0 ".*main.cpp"
-#define BAR
+#line 2
+#define BAR
 )cpp",
   },
   // multiline macro
@@ -238,7 +245,8 @@
 
 [[BAR]])cpp",
   R"cpp(#line 0 ".*main.cpp"
-#define BAR
+#line 2
+#define BAR
 )cpp",
   },
   // multiline macro
@@ -248,7 +256,8 @@
 BAR
 [[BAR]])cpp",
   R"cpp(#line 0 ".*main.cpp"
-#define BAR
+#line 3
+#define BAR
 )cpp",
   },
   };
@@ -275,8 +284,10 @@
   )cpp");
 
   llvm::StringLiteral ExpectedPatch(R"cpp(#line 0 ".*main.cpp"
-#define BAR\(X, Y\) X Y
-#define BAR\(X\) X
+#line 2
+#define BAR\(X, Y\) X Y
+#line 3
+#define BAR\(X\) X
 )cpp");
   EXPECT_THAT(getPreamblePatch(Baseline, Modified.code()),
   MatchesRegex(ExpectedPatch.str()));
@@ -286,6 +297,193 @@
   EXPECT_THAT(AST->getDiagnostics(),
   Not(Contains(Field(::Range, Modified.range();
 }
+
+TEST(PreamblePatchTest, LocateMacroAtWorks) {
+  struct {
+llvm::StringLiteral Baseline;
+llvm::StringLiteral Modified;
+  } Cases[] = {
+  // Addition of new directive
+  {
+  "",
+  R"cpp(
+#define $def^FOO
+$use^FOO)cpp",
+  },
+  // Available inside preamble section
+  {
+  "",
+  R"cpp(
+#define $def^FOO
+#undef $use^FOO)cpp",
+  },
+  // Available after undef, as we don't patch those
+  {
+  "",
+  R"cpp(
+#define $def^FOO
+#undef FOO
+$use^FOO)cpp",
+  },
+  // Identifier on a different line
+  {
+  "",
+  R"cpp(
+#define \
+  $def^FOO
+$use^FOO)cpp",
+  },
+  // In presence of comment tokens
+  {
+  "",
+  R"cpp(
+#\
+  define /* FOO */\
+  /* FOO */ $def^FOO
+$use^FOO)cpp",
+  },
+  // Moved around
+  {
+  "#define FOO",
+  R"cpp(
+#define BAR
+#define $def^FOO
+$use^FOO)cpp",
+  },
+  };
+  for (const auto  : Cases) {
+SCOPED_TRACE(Case.Modified);
+llvm::Annotations Modified(Case.Modified);
+auto AST = createPatchedAST(Case.Baseline, Modified.code());
+ASSERT_TRUE(AST);
+
+const auto  = AST->getSourceManager();
+auto *MacroTok = AST->getTokens().spelledTokenAt(
+SM.getComposedLoc(SM.getMainFileID(), Modified.point("use")));
+ASSERT_TRUE(MacroTok);
+
+auto FoundMacro = locateMacroAt(*MacroTok, AST->getPreprocessor());
+ASSERT_TRUE(FoundMacro);
+EXPECT_THAT(FoundMacro->Name, "FOO");
+
+auto MacroLoc = FoundMacro->NameLoc;
+EXPECT_EQ(SM.getFileID(MacroLoc), SM.getMainFileID());
+EXPECT_EQ(SM.getFileOffset(MacroLoc), Modified.point("def"));
+  }
+}
+
+TEST(PreamblePatchTest, LocateMacroAtDeletion) {
+  {
+// We don't patch deleted define directives, make sure we don't crash.
+llvm::StringLiteral Baseline = 

[PATCH] D79930: [clangd] Add buildPreamble to TestTU

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet updated this revision to Diff 266637.
kadircet added a comment.

- Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79930

Files:
  clang-tools-extra/clangd/unittests/PreambleTests.cpp
  clang-tools-extra/clangd/unittests/TestTU.cpp
  clang-tools-extra/clangd/unittests/TestTU.h


Index: clang-tools-extra/clangd/unittests/TestTU.h
===
--- clang-tools-extra/clangd/unittests/TestTU.h
+++ clang-tools-extra/clangd/unittests/TestTU.h
@@ -68,6 +68,7 @@
   // By default, build() will report Error diagnostics as GTest errors.
   // Suppress this behavior by adding an 'error-ok' comment to the code.
   ParsedAST build() const;
+  std::shared_ptr preamble() const;
   ParseInputs inputs() const;
   SymbolSlab headerSymbols() const;
   RefSlab headerRefs() const;
Index: clang-tools-extra/clangd/unittests/TestTU.cpp
===
--- clang-tools-extra/clangd/unittests/TestTU.cpp
+++ clang-tools-extra/clangd/unittests/TestTU.cpp
@@ -66,14 +66,24 @@
   return Inputs;
 }
 
+std::shared_ptr TestTU::preamble() const {
+  auto Inputs = inputs();
+  IgnoreDiagnostics Diags;
+  auto CI = buildCompilerInvocation(Inputs, Diags);
+  assert(CI && "Failed to build compilation invocation.");
+  return clang::clangd::buildPreamble(testPath(Filename), *CI, Inputs,
+  /*StoreInMemory=*/true,
+  /*PreambleCallback=*/nullptr);
+}
+
 ParsedAST TestTU::build() const {
   auto Inputs = inputs();
   StoreDiags Diags;
   auto CI = buildCompilerInvocation(Inputs, Diags);
   assert(CI && "Failed to build compilation invocation.");
-  auto Preamble =
-  buildPreamble(testPath(Filename), *CI, Inputs,
-/*StoreInMemory=*/true, /*PreambleCallback=*/nullptr);
+  auto Preamble = clang::clangd::buildPreamble(testPath(Filename), *CI, Inputs,
+   /*StoreInMemory=*/true,
+   /*PreambleCallback=*/nullptr);
   auto AST = ParsedAST::build(testPath(Filename), Inputs, std::move(CI),
   Diags.take(), Preamble);
   if (!AST.hasValue()) {
Index: clang-tools-extra/clangd/unittests/PreambleTests.cpp
===
--- clang-tools-extra/clangd/unittests/PreambleTests.cpp
+++ clang-tools-extra/clangd/unittests/PreambleTests.cpp
@@ -36,37 +36,19 @@
   return arg.first() == File && arg.second == D;
 }
 
-std::shared_ptr
-createPreamble(llvm::StringRef Contents = "") {
-  auto TU = TestTU::withCode(Contents);
-  // ms-compatibility changes meaning of #import, make sure it is turned off.
-  TU.ExtraArgs = {"-fno-ms-compatibility"};
-  TU.Filename = "preamble.cpp";
-  auto PI = TU.inputs();
-  IgnoreDiagnostics Diags;
-  auto CI = buildCompilerInvocation(PI, Diags);
-  if (!CI) {
-ADD_FAILURE() << "failed to build compiler invocation";
-return nullptr;
-  }
-  if (auto Preamble = buildPreamble(TU.Filename, *CI, PI, true, nullptr))
-return Preamble;
-  ADD_FAILURE() << "failed to build preamble";
-  return nullptr;
-}
-
 // Builds a preamble for BaselineContents, patches it for ModifiedContents and
 // returns the includes in the patch.
 IncludeStructure
 collectPatchedIncludes(llvm::StringRef ModifiedContents,
llvm::StringRef BaselineContents,
llvm::StringRef MainFileName = "main.cpp") {
-  auto BaselinePreamble = createPreamble(BaselineContents);
-  // Create the patch.
-  auto TU = TestTU::withCode(ModifiedContents);
+  auto TU = TestTU::withCode(BaselineContents);
   TU.Filename = MainFileName.str();
   // ms-compatibility changes meaning of #import, make sure it is turned off.
   TU.ExtraArgs = {"-fno-ms-compatibility"};
+  auto BaselinePreamble = TU.preamble();
+  // Create the patch.
+  TU = TestTU::withCode(ModifiedContents);
   auto PI = TU.inputs();
   auto PP = PreamblePatch::create(testPath(TU.Filename), PI, 
*BaselinePreamble);
   // Collect patch contents.


Index: clang-tools-extra/clangd/unittests/TestTU.h
===
--- clang-tools-extra/clangd/unittests/TestTU.h
+++ clang-tools-extra/clangd/unittests/TestTU.h
@@ -68,6 +68,7 @@
   // By default, build() will report Error diagnostics as GTest errors.
   // Suppress this behavior by adding an 'error-ok' comment to the code.
   ParsedAST build() const;
+  std::shared_ptr preamble() const;
   ParseInputs inputs() const;
   SymbolSlab headerSymbols() const;
   RefSlab headerRefs() const;
Index: clang-tools-extra/clangd/unittests/TestTU.cpp
===
--- clang-tools-extra/clangd/unittests/TestTU.cpp
+++ clang-tools-extra/clangd/unittests/TestTU.cpp
@@ -66,14 +66,24 

[PATCH] D79992: [clangd] Patch PP directives to use stale preambles while building ASTs

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet updated this revision to Diff 266638.
kadircet added a comment.

- Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79992

Files:
  clang-tools-extra/clangd/Preamble.cpp
  clang-tools-extra/clangd/Preamble.h
  clang-tools-extra/clangd/unittests/PreambleTests.cpp

Index: clang-tools-extra/clangd/unittests/PreambleTests.cpp
===
--- clang-tools-extra/clangd/unittests/PreambleTests.cpp
+++ clang-tools-extra/clangd/unittests/PreambleTests.cpp
@@ -26,7 +26,9 @@
 #include 
 #include 
 
+using testing::Contains;
 using testing::Field;
+using testing::MatchesRegex;
 
 namespace clang {
 namespace clangd {
@@ -181,6 +183,109 @@
   ElementsAre(AllOf(Field(::Written, "\"a.h\""),
 Field(::Resolved, testPath("a.h");
 }
+
+llvm::Optional createPatchedAST(llvm::StringRef Baseline,
+   llvm::StringRef Modified) {
+  auto BaselinePreamble = TestTU::withCode(Baseline).preamble();
+  if (!BaselinePreamble) {
+ADD_FAILURE() << "Failed to build baseline preamble";
+return llvm::None;
+  }
+
+  IgnoreDiagnostics Diags;
+  auto TU = TestTU::withCode(Modified);
+  auto CI = buildCompilerInvocation(TU.inputs(), Diags);
+  if (!CI) {
+ADD_FAILURE() << "Failed to build compiler invocation";
+return llvm::None;
+  }
+  return ParsedAST::build(testPath("main.cpp"), TU.inputs(), std::move(CI), {},
+  BaselinePreamble);
+}
+
+std::string getPreamblePatch(llvm::StringRef Baseline,
+ llvm::StringRef Modified) {
+  auto BaselinePreamble = TestTU::withCode(Baseline).preamble();
+  if (!BaselinePreamble) {
+ADD_FAILURE() << "Failed to build baseline preamble";
+return "";
+  }
+  auto TU = TestTU::withCode(Modified);
+  return PreamblePatch::create(testPath("main.cpp"), TU.inputs(),
+   *BaselinePreamble)
+  .text()
+  .str();
+}
+
+TEST(PreamblePatchTest, Define) {
+  // BAR should be defined while parsing the AST.
+  struct {
+llvm::StringLiteral Contents;
+llvm::StringLiteral ExpectedPatch;
+  } Cases[] = {
+  {
+  R"cpp(
+#define BAR
+[[BAR]])cpp",
+  R"cpp(#line 0 ".*main.cpp"
+#define BAR
+)cpp",
+  },
+  // multiline macro
+  {
+  R"cpp(
+#define BAR \
+
+[[BAR]])cpp",
+  R"cpp(#line 0 ".*main.cpp"
+#define BAR
+)cpp",
+  },
+  // multiline macro
+  {
+  R"cpp(
+#define \
+BAR
+[[BAR]])cpp",
+  R"cpp(#line 0 ".*main.cpp"
+#define BAR
+)cpp",
+  },
+  };
+
+  for (const auto  : Cases) {
+SCOPED_TRACE(Case.Contents);
+Annotations Modified(Case.Contents);
+EXPECT_THAT(getPreamblePatch("", Modified.code()),
+MatchesRegex(Case.ExpectedPatch.str()));
+
+auto AST = createPatchedAST("", Modified.code());
+ASSERT_TRUE(AST);
+EXPECT_THAT(AST->getDiagnostics(),
+Not(Contains(Field(::Range, Modified.range();
+  }
+}
+
+TEST(PreamblePatchTest, OrderingPreserved) {
+  llvm::StringLiteral Baseline = "#define BAR(X) X";
+  Annotations Modified(R"cpp(
+#define BAR(X, Y) X Y
+#define BAR(X) X
+[[BAR]](int y);
+  )cpp");
+
+  llvm::StringLiteral ExpectedPatch(R"cpp(#line 0 ".*main.cpp"
+#define BAR\(X, Y\) X Y
+#define BAR\(X\) X
+)cpp");
+  EXPECT_THAT(getPreamblePatch(Baseline, Modified.code()),
+  MatchesRegex(ExpectedPatch.str()));
+
+  auto AST = createPatchedAST(Baseline, Modified.code());
+  ASSERT_TRUE(AST);
+  EXPECT_THAT(AST->getDiagnostics(),
+  Not(Contains(Field(::Range, Modified.range();
+}
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/Preamble.h
===
--- clang-tools-extra/clangd/Preamble.h
+++ clang-tools-extra/clangd/Preamble.h
@@ -119,6 +119,9 @@
   /// using the presumed-location mechanism.
   std::vector preambleIncludes() const;
 
+  /// Returns textual patch contents.
+  llvm::StringRef text() const { return PatchContents; }
+
 private:
   PreamblePatch() = default;
   std::string PatchContents;
Index: clang-tools-extra/clangd/Preamble.cpp
===
--- clang-tools-extra/clangd/Preamble.cpp
+++ clang-tools-extra/clangd/Preamble.cpp
@@ -15,6 +15,7 @@
 #include "clang/Basic/Diagnostic.h"
 #include "clang/Basic/LangOptions.h"
 #include "clang/Basic/SourceLocation.h"
+#include "clang/Basic/SourceManager.h"
 #include "clang/Basic/TokenKinds.h"
 #include "clang/Frontend/CompilerInvocation.h"
 #include "clang/Frontend/FrontendActions.h"
@@ -106,14 +107,70 @@
   const SourceManager *SourceMgr = nullptr;
 };
 
-/// Gets the includes in the preamble section of the file by 

[PATCH] D80554: [DebugInfo] Use SplitTemplateClosers (foo >) in DWARF too

[Adrian McCarthy via Phabricator via cfe-commits]

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



Comment at: clang/lib/CodeGen/CGDebugInfo.cpp:242
+// SplitTemplateClosers yields better interop with GCC and GDB (PR46052).
+PP.SplitTemplateClosers = true;
   }

sammccall wrote:
> amccarth wrote:
> > So, in other words, we'll always set `PP.SplitTemplateClosers` to true, now.
> Yes. I thought it was clearest to write it separately in each branch, as it's 
> basically a coincidence and I can give a separate comment.
> 
> Happy to fold it together if you think it's confusing.
No change necessary.  I agree with how you've done it.  I was just amused that, 
after fixing the regression for CodeView, it ended up being undone for DWARF as 
well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80554



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

[PATCH] D79721: [Clang][AArch64] Capturing proper pointer alignment for Neon vld1 intrinsicts

[Eli Friedman via Phabricator via cfe-commits]

efriedma added a comment.

I'm not completely happy with using EmitPointerWithAlignment here... but I 
guess it's the same thing we do for 32-bit ARM, so it must be mostly usable in 
practice.  I'd like to see some tests in 
clang/test/CodeGen/aarch64-neon-intrinsics.c showing what happens if you pass, 
for example, a void* pointer to vld1_u32.




Comment at: clang/lib/CodeGen/CGBuiltin.cpp:10332
   case NEON::BI__builtin_neon_vld1q_v: {
+auto PtrOp0 = EmitPointerWithAlignment(E->getArg(0));
 Ops[0] = Builder.CreateBitCast(Ops[0], llvm::PointerType::getUnqual(VTy));

You can't call EmitPointerWithAlignment() here; we've already emitted the 
expression.  See CodeGenFunction::EmitARMBuiltinExpr for how we handle this on 
32-bit ARM.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:10334
 Ops[0] = Builder.CreateBitCast(Ops[0], llvm::PointerType::getUnqual(VTy));
-auto Alignment = CharUnits::fromQuantity(
-BuiltinID == NEON::BI__builtin_neon_vld1_v ? 8 : 16);
-return Builder.CreateAlignedLoad(VTy, Ops[0], Alignment);
+return Builder.CreateAlignedLoad(VTy, Ops[0], PtrOp0.getAlignment());
   }

Might as well just `return Builder.CreateLoad(VTy, PtrOp0);`



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:10363
   }
   case NEON::BI__builtin_neon_vst1_lane_v:
   case NEON::BI__builtin_neon_vst1q_lane_v:

Should we fix vst1 while we're in the area?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79721



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

[PATCH] D80237: [hip] Ensure pointer in struct argument has proper `addrspacecast`.

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In D80237#2055902 , @arsenm wrote:

> In D80237#2051933 , @rjmccall wrote:
>
> > Okay.  Can you explain why we need to coerce in the first place, though?  
> > Especially if the representation is the same, why is your target-lowering 
> > requiring parameters to be coerced to involve pointers in a different 
> > address space?
>
>
> It's not a requirement, but an optimization. The pointer representation is 
> the same, but there's a penalty to using the generic pointer. From the 
> language context here, we know the flat pointer can never alias the 
> non-global address spaces.


Is that because it's a kernel argument?  I don't understand how the coercion 
can work in general for structs that just contain pointers.

> I think the real problem here is the IR is missing a no-op cast between 
> pointers with different address spaces. With the current promotion, GVN sees 
> the bits of the addrspace(0) ptr get reinterpreted as addrspace(1), and 
> doesn't have a better option than a ptrtoint/inttoptr pair. When 
> addrspacecast was added, pointer bitcasts between different address spaces 
> were disallowed (I think mostly for reasons that no longer apply). If we 
> reallowed pointer bitcast between equivalent sized address spaces as known 
> no-op cast, we wouldn't need to change the argument promotion in the frontend.

That seems like it would be a much cleaner way of handling this, yeah.  
Ideally, GVN would be able to find the target-specific information necessary to 
know that it can introduce an `addrspacecast` between two address spaces.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80237



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

[PATCH] D80654: WIP: Make it possible to use the traverse() matcher in clang-query

[Stephen Kelly via Phabricator via cfe-commits]

steveire added a comment.

This is not ready for review, but is it a direction we want to go, given that 
we can already use

  set traversal 

in clang-query?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80654



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

[PATCH] D76791: [Matrix] Implement matrix index expressions ([][]).

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: clang/lib/Sema/SemaExpr.cpp:4650
+  (Base->isTypeDependent() || RowIdx->isTypeDependent() ||
+   (ColumnIdx && ColumnIdx->isTypeDependent(
+return new (Context) MatrixSubscriptExpr(Base, RowIdx, ColumnIdx,

fhahn wrote:
> rjmccall wrote:
> > Checking dependence is actually just as cheap as checking for C++, there's 
> > no real need to gate.  But you need to check for placeholder types in the 
> > index operands before doing these type checks.  The best test case here is 
> > an Objective-C property reference, something like:
> > 
> > ```
> > __attribute__((objc_root_class))
> > @interface IntValue
> > @property int value;
> > @end
> > 
> > double test(double4x4 m, IntValue *iv) {
> >   return m[iv.value][iv.value];
> > }
> > ```
> > 
> > Also, I would suggest not doing any checking on incomplete matrix 
> > expressions; just notice that it's still incomplete, build the expression, 
> > and return.  You can do the checking once when you have all the operands 
> > together.
> > Checking dependence is actually just as cheap as checking for C++, there's 
> > no real need to gate. But you need to check for placeholder types in the 
> > index operands before doing these type checks. The best test case here is 
> > an Objective-C property reference, something like:
> 
> Done, I've added a ActOnMatrixSubscriptExpr and added code to deal with 
> placeholder types there.
> 
> > Also, I would suggest not doing any checking on incomplete matrix 
> > expressions; just notice that it's still incomplete, build the expression, 
> > and return. You can do the checking once when you have all the operands 
> > together.
> 
> Done, I initially thought it might be good to still raise an error if the row 
> index was invalid, but given that it's not a valid expression anyways that 
> probably is not too helpful anyways. Doing the checks on the complete 
> expression simplifies things a bit :)
Placeholders actually need to be handled in the `Build` function — they can 
come up in template instantiation, too.



Comment at: clang/lib/Sema/SemaExpr.cpp:4645
+  // Separating the index expressions by parenthesis is not allowed.
+  if (isa(Base) && Base->getType()->isSpecificPlaceholderType(
+  BuiltinType::IncompleteMatrixIdx)) {

Don't check for `ParenExpr` specifically; there are other expressions that are 
handled the same way, like `_Generic`.  You need to check for 
`!isa`.



Comment at: clang/lib/Sema/SemaExpr.cpp:4655
+  // type, in which case the overload resolution for the operator overload
+  // should get the first crack at the overload.
+

Overload placeholder types are used for things like `` where `foo` is the 
name of an overloaded function.  The places that resolve only non-overload 
placeholder types are doing so in order to leave room for overload resolution 
to resolve the overload later, e.g. as part of non-builtin operator handling.  
`operator[]` is like `operator()`: non-builtin operators are only considered 
when the base has class type.  Since you already know that the base type is a 
matrix type, you know that you're using your standard rules, and your standard 
rules have no way to resolve overloads in the index types — correctly, since 
indexes can't be functions or member pointers.

tl;dr: You can (and should) resolve all placeholders here, not just 
non-overload placeholders.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76791



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

[PATCH] D69764: [clang-format] Add East/West Const fixer capability

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

rsmith added a comment.

In D69764#2057945 , @aaron.ballman 
wrote:

> In D69764#2056104 , @rsmith wrote:
>
> > I also don't think this is something that a user would *want* in 
> > `clang-format`: changing the location of `const`s is something that would 
> > likely be done rarely (probably only once) when migrating to a different 
> > coding style, rather than being done on the fly after each edit to a source 
> > file.
>
>
> I'm not certain I agree with this. For instance, you can run clang-format as 
> a precommit step or as part of your CI pipeline to bark at users when they 
> get formatting incorrect while working on a team project. (We do this 
> internally with some of our internal projects.)


You can do the same with clang-tidy checks. If you're running clang-format but 
not clang-tidy as part of your CI, it would likely be worth your while to add 
clang-tidy to your set of CI checks regardless of what we do here. But if you 
want this only as a CI check, and not for reformatting code as you edit it, 
then for me that is a fairly strong signal that this does not belong in 
clang-format.

>> Fundamentally, I don't think this transformation is simply reformatting, and 
>> I don't think it can be done sufficiently-correctly with only a 
>> largely-context-free, heuristic-driven C++ parser. As such, I think this 
>> belongs in `clang-tidy`, not in `clang-format`.
> 
> I think clang-tidy has the machinery needed to do this properly, but I think 
> clang-format is logically where I would go to look for the functionality 
> (certainly before thinking of clang-tidy) because this is more related to 
> formatting than not. That said, if we cannot make it work reliably within 
> clang-format, I'd rather see it in clang-tidy than nowhere.

Right now we have a relatively clear line between the tools. clang-format does 
not parse or really understand the code, and just heuristically puts the 
whitespace and line breaks in the right place, in a way that is ~always 
correct. clang-tidy understands the meaning of the program and can suggest 
changes that are likely correct (but should typically be double-checked by a 
person). I think this kind of change is in the latter category.

I totally agree that it's reasonable to think of this as a reformatting change, 
just as I think it's reasonable to think of (say) reordering the data members 
of a class to the start as a reformatting change, or to think of moving an 
inline function definition out of the class definition as a reformatting 
change, or parenthesizing certain operators as a reformatting change -- and all 
of those could also reasonably be required by some house coding style. But I 
don't think clang-format is the right tool to perform those operations.


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

https://reviews.llvm.org/D69764



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

[PATCH] D76077: [ARM] Add __bf16 as new Bfloat16 C Type

[Sjoerd Meijer via Phabricator via cfe-commits]

SjoerdMeijer added inline comments.



Comment at: clang/test/CodeGen/arm-mangle-bf16.cpp:3
+// RUN: %clang_cc1 -triple arm-arm-none-eabi -target-feature +bf16 -mfloat-abi 
hard -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK32-HARD
+// RUN: %clang_cc1 -triple arm-arm-none-eabi -target-feature +bf16 -mfloat-abi 
softfp -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK32-SOFTFP
+

SjoerdMeijer wrote:
> nit: if the name mangling is Independent of the float ABI, then you might as 
> well one runline and the abi option.
-> ...  then you might as well have only one runline and remove the abi option.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76077



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

[PATCH] D80654: WIP: Make it possible to use the traverse() matcher in clang-query

[Stephen Kelly via Phabricator via cfe-commits]

steveire created this revision.
steveire added a reviewer: ymandel.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D80654

Files:
  clang/include/clang/ASTMatchers/ASTMatchersInternal.h
  clang/include/clang/ASTMatchers/Dynamic/VariantValue.h
  clang/lib/ASTMatchers/ASTMatchersInternal.cpp
  clang/lib/ASTMatchers/Dynamic/Marshallers.h
  clang/lib/ASTMatchers/Dynamic/Registry.cpp
  clang/lib/ASTMatchers/Dynamic/VariantValue.cpp
  clang/unittests/ASTMatchers/Dynamic/RegistryTest.cpp

Index: clang/unittests/ASTMatchers/Dynamic/RegistryTest.cpp
===
--- clang/unittests/ASTMatchers/Dynamic/RegistryTest.cpp
+++ clang/unittests/ASTMatchers/Dynamic/RegistryTest.cpp
@@ -505,6 +505,25 @@
   EXPECT_FALSE(matches("struct X {};", Value));
 }
 
+TEST_F(RegistryTest, Traverse) {
+  EXPECT_TRUE(
+  matches(R"cpp(
+int foo()
+{
+double d = 0;
+return d;
+}
+)cpp",
+  constructMatcher(
+  "returnStmt",
+  constructMatcher(
+  "hasReturnValue",
+  constructMatcher("traverse",
+   StringRef("IgnoreUnlessSpelledInSource"),
+   constructMatcher("declRefExpr"
+  .getTypedMatcher()));
+}
+
 TEST_F(RegistryTest, ParenExpr) {
   Matcher Value = constructMatcher("parenExpr").getTypedMatcher();
   EXPECT_TRUE(
Index: clang/lib/ASTMatchers/Dynamic/VariantValue.cpp
===
--- clang/lib/ASTMatchers/Dynamic/VariantValue.cpp
+++ clang/lib/ASTMatchers/Dynamic/VariantValue.cpp
@@ -80,6 +80,44 @@
 
 VariantMatcher::Payload::~Payload() {}
 
+class VariantMatcher::TraversalPayload : public VariantMatcher::Payload {
+public:
+  TraversalPayload(ast_type_traits::TraversalKind TK,
+   const DynTypedMatcher )
+  : TK(TK), Matcher(Matcher) {}
+
+  llvm::Optional getSingleMatcher() const override {
+return Matcher;
+  }
+
+  std::string getTypeAsString() const override {
+return (Twine("Matcher<") + Matcher.getSupportedKind().asStringRef() + ">")
+.str();
+  }
+
+  llvm::Optional
+  getTypedMatcher(const MatcherOps ) const override {
+// llvm::errs() << "TraversalCode" << "\n";
+// std::terminate();
+
+bool Ignore;
+if (Ops.canConstructFrom(Matcher, Ignore)) {
+  return DynTypedMatcher::constructTraversalWrapper(Matcher, TK);
+}
+return llvm::None;
+  }
+
+  bool isConvertibleTo(ast_type_traits::ASTNodeKind Kind,
+   unsigned *Specificity) const override {
+return ArgKind(Matcher.getSupportedKind())
+.isConvertibleTo(Kind, Specificity);
+  }
+
+private:
+  ast_type_traits::TraversalKind TK;
+  const DynTypedMatcher Matcher;
+};
+
 class VariantMatcher::SinglePayload : public VariantMatcher::Payload {
 public:
   SinglePayload(const DynTypedMatcher ) : Matcher(Matcher) {}
@@ -219,6 +257,12 @@
   return VariantMatcher(std::make_shared(Matcher));
 }
 
+VariantMatcher
+VariantMatcher::TraversalMatcher(ast_type_traits::TraversalKind TK,
+ const DynTypedMatcher ) {
+  return VariantMatcher(std::make_shared(TK, Matcher));
+}
+
 VariantMatcher
 VariantMatcher::PolymorphicMatcher(std::vector Matchers) {
   return VariantMatcher(
Index: clang/lib/ASTMatchers/Dynamic/Registry.cpp
===
--- clang/lib/ASTMatchers/Dynamic/Registry.cpp
+++ clang/lib/ASTMatchers/Dynamic/Registry.cpp
@@ -101,6 +101,9 @@
   // Other:
   // equalsNode
 
+  registerMatcher("traverse",
+  std::make_unique());
+
   REGISTER_OVERLOADED_2(callee);
   REGISTER_OVERLOADED_2(hasAnyCapture);
   REGISTER_OVERLOADED_2(hasPrefix);
Index: clang/lib/ASTMatchers/Dynamic/Marshallers.h
===
--- clang/lib/ASTMatchers/Dynamic/Marshallers.h
+++ clang/lib/ASTMatchers/Dynamic/Marshallers.h
@@ -244,6 +244,31 @@
   static llvm::Optional getBestGuess(const VariantValue );
 };
 
+template <> struct ArgTypeTraits {
+private:
+  static Optional
+  getTraversalKind(llvm::StringRef TK) {
+return llvm::StringSwitch>(TK)
+.Case("TK::AsIs", ast_type_traits::TK_AsIs)
+.Case("TK::IgnoreUnlessSpelledInSource",
+  ast_type_traits::TK_IgnoreUnlessSpelledInSource)
+.Case("TK::IgnoreImplicitCastsAndParentheses",
+  ast_type_traits::TK_IgnoreImplicitCastsAndParentheses)
+.Default(llvm::None);
+  }
+
+public:
+  static bool is(const VariantValue ) {
+return Value.isString() && getTraversalKind(Value.getString());
+  }
+
+  static ast_type_traits::TraversalKind get(const VariantValue ) {
+return *getTraversalKind(Value.getString());
+  }
+
+  static ArgKind getKind() { return 

[PATCH] D60620: [HIP] Support target id by --offload-arch

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: clang/lib/Driver/ToolChains/HIP.cpp:121-123
+  auto Pos = SubArchName.find_first_of("+-");
+  if (Pos != SubArchName.npos)
+SubArchName = SubArchName.substr(0, Pos);

yaxunl wrote:
> tra wrote:
> > yaxunl wrote:
> > > tra wrote:
> > > > Parsing should probably be extracted into a separate function to avoid 
> > > > replicating it all over the place.
> > > > 
> > > > I'd also propose use a different syntax for the properties.
> > > > * use explicit character to separate individual elements. This way 
> > > > splitting the properties becomes independent of what those properties 
> > > > are. If you decide to make properties with values or change their 
> > > > meaning some other way, it would not affect how you compose them.
> > > > * use `name=value` or `name[+-]` for individual properties. This makes 
> > > > it easy to parse individual properties and normalize their names. This 
> > > > makes property map creation independent of the property values.
> > > > 
> > > > Right now `[+-]` serves as both a separator and as the value, which 
> > > > would present problems if you ever need more flexible parametrization 
> > > > of properties. What if a property must be a number or a string. 
> > > > Granted, you can always encode them as a set of bools, but that's 
> > > > rather unpractical. 
> > > > 
> > > > E.g. something like this would work a bit better: 
> > > > `gfx111:foo+:bar=33:buz=string`.
> > > > 
> > > I discussed this with our team.
> > > 
> > > The target id features are not raw GPU properties. They are distilled to 
> > > become a few target features to decide what the compiler should do.
> > > 
> > > Each target feature has 3 values: on, off, and default, which are encoded 
> > > as +feature, -feature, and not present.
> > > 
> > > For runtime, it is simple and clear how to choose device binaries based 
> > > on the target features: it will try exact match, otherwise choose the 
> > > default.
> > > 
> > > For compiler, it is also simple and clear what to do for each target 
> > > feature value, since they corresponding to backend target features.
> > > 
> > > Basically we expect the target id feature to be like flags, not key/value 
> > > pairs. In case we do need key/value pairs, they can still use + as 
> > > delimiter.
> > > 
> > > Another reason we use +/- format is that it is more in line with the 
> > > format of existing clang-offload-bundler id and target triple, which uses 
> > > - as delimiter.
> > > 
> > > Since the target id is an extension of offload arch and users will put it 
> > > into command line, we want to make it short, concise and aesthetically 
> > > appealing, we would avoid using non-alpha-numeric characters in the 
> > > target id features. Target triple components have similar requirements. 
> > > Using : as delimiter seems unnecessary, longer, and more difficult to 
> > > read.
> > > 
> > > Consider the following example
> > > 
> > > 
> > > ```
> > > clang -offload-id gfx908+xnack-sramecc a.hip
> > > 
> > > clang -offload-id gfx908:xnack+:sramecc- a.hip
> > > ```
> > > 
> > > We are more inclined to keep the original format. 
> > You're thinking in terms what's needed by AMDGPU *now*. The scheme you're 
> > proposing is sufficient for your use case and I'm fine with that. I'm 
> > suggesting that you should consider what happens once this change lands.
> > 
> > The functionality you're implementing is exposed to end-users via top-level 
> > clang driver argument. This is visible to users and will be relied on.
> > This will make it hard to change in the future without breaking someone. 
> > It's worth making sure we're not painting ourselves in the corner here.
> > 
> > Also, the functionality may be useful/applicable beyond the scope of amdgpu 
> > and the binary flags will not be sufficient for everyone. The scheme you're 
> > proposing would be somewhat restrictive if I need to pass an integer value 
> > or string. We could use something like `gfx123+foo=456-bar=789` but it 
> > would look rather odd, IMO. 
> > 
> > Granted, none of the above is a showstopper. I guess we could support 
> > multiple formats if it comes to that, but I'd rather not multiply things 
> > later because we didn't think of them earlier.
> > 
> > > Another reason we use +/- format is that it is more in line with the 
> > > format of existing clang-offload-bundler id and target triple, which uses 
> > > - as delimiter.
> > 
> > The point was that commingling field separator and the field value is not 
> > the cleanest approach, IMO. I'd be fine fine with some other character.
> > 
> > > Since the target id is an extension of offload arch and users will put it 
> > > into command line, we want to make it short, concise and aesthetically 
> > > appealing, we would avoid using non-alpha-numeric characters in the 
> > > target id features. Target triple components have similar requirements. 
> > > Using : as delimiter 

[PATCH] D76077: [ARM] Add __bf16 as new Bfloat16 C Type

[Sjoerd Meijer via Phabricator via cfe-commits]

SjoerdMeijer added a comment.

As I wrote in one of the inlined comments, I am relatively unhappy that we have 
both bfloat and bfloat16 as names. But that looks like a complain for another 
patch, and not really this one.




Comment at: clang/lib/Basic/Targets/AArch64.cpp:74
+  BFloat16Width = BFloat16Align = 16;
+  BFloat16Format = ::APFloat::BFloat();
+

stuij wrote:
> SjoerdMeijer wrote:
> > Nit: we use bfloat16 everywhere, would `llvm::APFloat::BFloat16()` be 
> > better for consistency?
> In the IR world bfloat is consistently called bfloat, without the 16. I think 
> this might turn into bikeshedding to justify if either one or both sides of 
> the divide should or should not include the '16'. I can think of arguments to 
> support the various options.
> 
> As I think there's no clear winner, I'd like to take the route of less effort 
> and keep things as is.
ah, I couldn't remember on which patch I commented on the bfloat16 vs bfloat 
naming.
Since everything is called bfloat16, from the architecture extension to the 
source language type, I find this a bit of a missed opportunity to get the 
names consistent. And I wouldn't say that naming of types is bikeshedding. But 
maybe that's just me...



Comment at: clang/lib/Basic/Targets/ARM.cpp:80
 DoubleAlign = LongLongAlign = LongDoubleAlign = SuitableAlign = 32;
+  BFloat16Width = BFloat16Align = 16;
+  BFloat16Format = ::APFloat::BFloat();

Is this tested? Can it be tested?



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:4483
+ bool V1Ty=false,
+ bool HasBFloat16Type=true) {
   int IsQuad = TypeFlags.isQuad();

nit: the linter says some spaces here.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:5514
 
-  llvm::VectorType *VTy = GetNeonType(this, Type, HasLegalHalfType);
+  llvm::VectorType *VTy = GetNeonType(this, Type, HasLegalHalfType, false, 
HasBFloat16Type);
   llvm::Type *Ty = VTy;

nit: looks like the hinter right to be unhappy about the formatting



Comment at: clang/lib/CodeGen/TargetInfo.cpp:6270
 
+  // __bf16  get passed using the bfloat ir type, or using i32 but
+  // with the top 16 bits unspecified.

nit: ir -> IR



Comment at: clang/lib/CodeGen/TargetInfo.cpp:6471
+// FP16/BF16 vectors should be converted to integer vectors
+// This check is similar  to isIllegalVectorType - refactor?
+if ((!getTarget().hasLegalHalfType() &&

nit: perhaps add TODO, or just remove this.



Comment at: clang/lib/Sema/SemaOverload.cpp:1874
+
+// conversions between bfloat and other floats are not permitted
+if (FromType == S.Context.BFloat16Ty || ToType == S.Context.BFloat16Ty)

Nit: conversions -> Conversions,  permitted -> permitted.

Same on line no. 1895.



Comment at: clang/test/CodeGen/arm-bf16-params-returns.c:5
+// RUN: %clang_cc1 -triple aarch64-arm-none-eabi -target-abi aapcs -mfloat-abi 
softfp -target-feature +bf16 -target-feature +neon -emit-llvm -O2 -o - %s | opt 
-S -mem2reg -sroa | FileCheck %s --check-prefix=CHECK64-SOFTFP
+
+// function return types

what happens with `-mfloat-abi=soft`. Does that deserve a test?



Comment at: clang/test/CodeGen/arm-mangle-16bit-float.cpp:4
+
+// CHECK64: define {{.*}}void @_Z3foou6__bf16(half %b)
+// CHECK32: define {{.*}}void @_Z3foou6__bf16(i32 %b.coerce)

LukeGeeson wrote:
> SjoerdMeijer wrote:
> > LukeGeeson wrote:
> > > craig.topper wrote:
> > > > How can bfloat16 be passed as half? Don't they have a different format?
> > > see the above comment about soft-abis
> > Probably I am bit confused too now... are the three possible types that we 
> > are expecing not bfloat, i32, or i16? 
> Hi Sjoerd, Good spot here I forgot to add a default case somewhere, which 
> means AArch32 didn't observe `-mfloat-abi softfp` by default - and hence used 
> bfloat where i32 was expected. 
> 
> I have a local patch for this and will send to Ties to merge into this one :) 
> 
> 
> We're not sure what you mean by i16 however?
Ah, as I said, got confused. Now I see we use i16 for targets that don't 
support bfloat16. So we probably need a test for that.



Comment at: clang/test/CodeGen/arm-mangle-bf16.cpp:3
+// RUN: %clang_cc1 -triple arm-arm-none-eabi -target-feature +bf16 -mfloat-abi 
hard -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK32-HARD
+// RUN: %clang_cc1 -triple arm-arm-none-eabi -target-feature +bf16 -mfloat-abi 
softfp -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK32-SOFTFP
+

nit: if the name mangling is Independent of the float ABI, then you might as 
well one runline and the abi option.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  

[PATCH] D80603: add isAtPosition narrowing matcher for parmVarDecl

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D80603#2057970 , @oontvoo wrote:

> In D80603#2057014 , @aaron.ballman 
> wrote:
>
> > Does the `hasParameter()` matcher not already do this?
>
>
> Yes, it does. But we'd like it to be able to match on the parmVarDecl().


I'm sorry if I'm being dense, but `hasParameter`  traverses to the 
`ParmVarDecl`, so I'm not certain I understand why this new matcher is needed 
as a public matcher. It seems like you can already accomplish this without 
adding a second API to do effectively the same thing: 
`functionDecl(hasParameter(0, parmVarDecl().bind("param")))`, can't you?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80603



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

[PATCH] D80293: [clangd] Run PreambleThread in async mode behind a flag

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

Sorry about the delay on this, I said I'd prioritize it... had a slightly odd 
day.

Haven't reviewed the unit test yet (mostly a reminder to myself).
Generally looks good...




Comment at: clang-tools-extra/clangd/ClangdServer.h:153
 
+/// Whether to run PreamblePeer asynchronously.
+bool AsyncPreambleBuilds = false;

Group with StorePreamblesInMemory.

This comment doesn't make much sense either - PreamblePeer describe's the 
thread's relation to the main ASTWorker thread, but readers here won't know 
what it is. What about:
Reuse even stale preambles, and rebuild them in the background.
This improves latency at the cost of accuracy.



Comment at: clang-tools-extra/clangd/TUScheduler.cpp:244
+  // If NextReq was requested with WantDiagnostics::Yes we cannot just drop
+  // that on the floor. We block the request trying to override the update
+  // instead of the caller forcing diagnostics to don't block in cases 
where

First sentence makes sense, code makes sense, I can't parse the second sentence 
at all.
Just "block until it's built"?

Any maybe something about why we won't deadlock, but tests are enough I guess.



Comment at: clang-tools-extra/clangd/TUScheduler.cpp:292
 dlog("Preamble worker for {0} stopped", FileName);
+BuiltFirst.notify();
   }

add comment // will never build one, or so



Comment at: clang-tools-extra/clangd/TUScheduler.cpp:551
   Semaphore , DebouncePolicy UpdateDebounce,
-  bool StorePreamblesInMemory, ParsingCallbacks ) {
-  std::shared_ptr Worker(
-  new ASTWorker(FileName, CDB, IdleASTs, Barrier, /*RunSync=*/!Tasks,
-UpdateDebounce, StorePreamblesInMemory, Callbacks));
+  bool StorePreamblesInMemory, bool AsyncPreambleBuilds,
+  ParsingCallbacks ) {

we're passing around enough loose booleans we should consider having 
TUScheduler hold its Options struct, and pass it here by refrerence...



Comment at: clang-tools-extra/clangd/TUScheduler.cpp:660
 std::move(CompilerInvocationDiags), WantDiags);
+// Block until first preamble is ready. As patching an empty preamble would
+// imply rebuilding it from scratch.

"ready, as patching..."



Comment at: clang-tools-extra/clangd/TUScheduler.cpp:724
std::move(Req.WantDiags));
+// Set it after notifying ASTPeer about the preamble to prevent any races.
+BuiltFirst.notify();

hmm, we're notifying the ASTPeer, and then setting builtfirst which is being 
waited on... by astpeer.
This suggests to me the AST thread should own the notification, not the 
preamble thread.
And in fact it already has a notification for the first preamble being built! 
why can't we use that one?



Comment at: clang-tools-extra/clangd/TUScheduler.cpp:1133
 
 bool ASTWorker::blockUntilIdle(Deadline Timeout) const {
   std::unique_lock Lock(Mutex);

I think this would be clearer as a loop... and maybe more correct.



Comment at: clang-tools-extra/clangd/TUScheduler.cpp:1146
+  Lock.lock();
+  assert(Requests.empty() && "Received new requests during blockUntilIdle");
+  // Finally make sure ASTWorker has processed all of the preamble updates.

um... isn't that allowed?
If new traffic means the queue doesn't go idle, I think we're supposed to 
return false, rather than crash.



Comment at: clang-tools-extra/clangd/TUScheduler.h:195
+
+/// Whether to run PreamblePeer asynchronously. No-op if AsyncThreadsCount
+/// is 0.

nit: break before second sentence?



Comment at: clang-tools-extra/clangd/tool/ClangdMain.cpp:421
+opt AsyncPreambleBuilds{
+"async-preamble-builds",
+cat(Misc),

I'd drop "builds" at least from the flag name, possibly througout



Comment at: clang-tools-extra/clangd/tool/ClangdMain.cpp:423
+cat(Misc),
+desc("Enable async preamble builds."),
+init(false),

This isn't very descriptive. I'd use some variation of the comment suggested 
for the ClangdServer::Options


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80293



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

[PATCH] D80222: Replace Clang's createRuntimeFunction with the definitions in OMPKinds.def

[Joseph Huber via Phabricator via cfe-commits]

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



Comment at: openmp/runtime/test/tasking/kmp_taskloop.c:100
 th_counter[i] = 0;
-#pragma omp parallel num_threads(N)
+#pragma omp parallel // num_threads(N)
 {

AndreyChurbanov wrote:
> jhuber6 wrote:
> > jhuber6 wrote:
> > > jdoerfert wrote:
> > > > jhuber6 wrote:
> > > > > I am not entirely sure why, but commenting this out causes the 
> > > > > problem to go away. I tried adding proper names to the 
> > > > > forward-declared functions but since clang already knew I had 
> > > > > something called ident_t, I couldn't declare a new struct with the 
> > > > > same name.
> > > > This is not good. The difference should only be that the 
> > > > `kmpc_fork_call` has a different argument, right? Does the segfault 
> > > > happen at compile or runtime?
> > > > 
> > > > You can just use the ident_t clang created, right? Did you print the 
> > > > function names requested by clang as we discussed?
> > > I added an assertion and debug statements. If I try to declare a struct 
> > > named "Ident_t" I get the following error message in the seg-fault. I 
> > > think the seg-fault is compile-time.
> > > 
> > > Found OpenMP runtime function __kmpc_global_thread_num with type i32 
> > > (%struct.ident_t.0*). Expected type is i32 (%struct.ident_t*)
> > > clang: 
> > > /home/jhuber/Documents/llvm-project/llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:124:
> > >  static llvm::Function* 
> > > llvm::OpenMPIRBuilder::getOrCreateRuntimeFunction(llvm::Module&, 
> > > llvm::omp::RuntimeFunction): Assertion `FnTy == Fn->getFunctionType() && 
> > > "Found OpenMP runtime function has mismatched types"' failed.
> > I'm not sure if there's a way around this without changing the 
> > getOrCreateRuntimeFunction method to return a FunctionCallee and removing 
> > the assertion. Clang doesn't know about the ident_t struct when it's 
> > compiling the file, but when its doing the codegen it sees two structs with 
> > the same name and creates a new name. So when it gets the types it says 
> > that ident_t and ident_t.0 don't match. As you said the old version got 
> > around this by adding a bitcasting instruction so it knew how to turn it 
> > into an ident_t pointer.
> Note that this change breaks the test on any system with more that 4 procs.  
> Because array th_counter[4] is indexed by thread number which can easily be 
> greater than 3 if number of threads is not limited.
The problem was that the num_threads clause required an implicit call to 
kmpc_global_thread_num so it could be passed to kmpc_push_num_threads. The 
types of the implicit function and the forward declaration then wouldn't match 
up. I added another forward declaration to explicitly call 
kmpc_push_num_threads. Is this a sufficient solution?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80222



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

[PATCH] D80222: Replace Clang's createRuntimeFunction with the definitions in OMPKinds.def

[Andrey Churbanov via Phabricator via cfe-commits]

AndreyChurbanov added inline comments.



Comment at: openmp/runtime/test/tasking/kmp_taskloop.c:100
 th_counter[i] = 0;
-#pragma omp parallel num_threads(N)
+#pragma omp parallel // num_threads(N)
 {

jhuber6 wrote:
> jhuber6 wrote:
> > jdoerfert wrote:
> > > jhuber6 wrote:
> > > > I am not entirely sure why, but commenting this out causes the problem 
> > > > to go away. I tried adding proper names to the forward-declared 
> > > > functions but since clang already knew I had something called ident_t, 
> > > > I couldn't declare a new struct with the same name.
> > > This is not good. The difference should only be that the `kmpc_fork_call` 
> > > has a different argument, right? Does the segfault happen at compile or 
> > > runtime?
> > > 
> > > You can just use the ident_t clang created, right? Did you print the 
> > > function names requested by clang as we discussed?
> > I added an assertion and debug statements. If I try to declare a struct 
> > named "Ident_t" I get the following error message in the seg-fault. I think 
> > the seg-fault is compile-time.
> > 
> > Found OpenMP runtime function __kmpc_global_thread_num with type i32 
> > (%struct.ident_t.0*). Expected type is i32 (%struct.ident_t*)
> > clang: 
> > /home/jhuber/Documents/llvm-project/llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp:124:
> >  static llvm::Function* 
> > llvm::OpenMPIRBuilder::getOrCreateRuntimeFunction(llvm::Module&, 
> > llvm::omp::RuntimeFunction): Assertion `FnTy == Fn->getFunctionType() && 
> > "Found OpenMP runtime function has mismatched types"' failed.
> I'm not sure if there's a way around this without changing the 
> getOrCreateRuntimeFunction method to return a FunctionCallee and removing the 
> assertion. Clang doesn't know about the ident_t struct when it's compiling 
> the file, but when its doing the codegen it sees two structs with the same 
> name and creates a new name. So when it gets the types it says that ident_t 
> and ident_t.0 don't match. As you said the old version got around this by 
> adding a bitcasting instruction so it knew how to turn it into an ident_t 
> pointer.
Note that this change breaks the test on any system with more that 4 procs.  
Because array th_counter[4] is indexed by thread number which can easily be 
greater than 3 if number of threads is not limited.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80222



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

[PATCH] D80603: add isAtPosition narrowing matcher for parmVarDecl

[Vy Nguyen via Phabricator via cfe-commits]

oontvoo updated this revision to Diff 266615.
oontvoo marked 7 inline comments as done.
oontvoo added a comment.

- Added docs
- Make it work with {block,objcMethod}Decl too.  More tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80603

Files:
  clang/docs/LibASTMatchersReference.html
  clang/include/clang/ASTMatchers/ASTMatchers.h
  clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp

Index: clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
@@ -2643,6 +2643,29 @@
   parmVarDecl(hasDefaultArgument(;
 }
 
+TEST(IsAtPosition, Basic) {
+  EXPECT_TRUE(matches("void x(int a) {}", parmVarDecl(isAtPosition(0;
+  EXPECT_TRUE(matches("void x(int a, int b) {}", parmVarDecl(isAtPosition(0;
+  EXPECT_TRUE(matches("void x(int a, int b) {}", parmVarDecl(isAtPosition(1;
+  EXPECT_TRUE(notMatches("void x(int val) {}", parmVarDecl(isAtPosition(1;
+
+  // Tests with function-decls
+  EXPECT_TRUE(matches("void x(int a);", parmVarDecl(isAtPosition(0;
+  EXPECT_TRUE(matches("void x(int a, int b);", parmVarDecl(isAtPosition(0;
+  EXPECT_TRUE(matches("void x(int a, int b);", parmVarDecl(isAtPosition(1;
+  EXPECT_TRUE(notMatches("void x(int val);", parmVarDecl(isAtPosition(1;
+
+  // Tests with lamdas
+  EXPECT_TRUE(
+  matches("void x() { [](int a) {};  }", parmVarDecl(isAtPosition(0;
+  EXPECT_TRUE(matches("void x() { [](int a, int b) {}; }",
+  parmVarDecl(isAtPosition(0;
+  EXPECT_TRUE(matches("void x() { [](int a, int b) {}; }",
+  parmVarDecl(isAtPosition(1;
+  EXPECT_TRUE(
+  notMatches("void x() { [](int val) {}; }", parmVarDecl(isAtPosition(1;
+}
+
 TEST(IsArray, Basic) {
   EXPECT_TRUE(matches("struct MyClass {}; MyClass *p1 = new MyClass[10];",
   cxxNewExpr(isArray(;
Index: clang/include/clang/ASTMatchers/ASTMatchers.h
===
--- clang/include/clang/ASTMatchers/ASTMatchers.h
+++ clang/include/clang/ASTMatchers/ASTMatchers.h
@@ -3096,6 +3096,37 @@
 internal::TypeList>
 hasAncestor;
 
+/// Matches the ParmVarDecl nodes that are at the N'th position in the parameter
+/// list. The parameter list could be that of either a block, function, or
+/// objc-method.
+///
+///
+/// Given
+///
+/// \code
+/// void f(int a, int b, int c) {
+/// }
+/// \endcode
+///
+/// ``parmVarDecl(isAtPosition(0))`` matches ``int a``.
+///
+/// ``parmVarDecl(isAtPosition(1))`` matches ``int b``.
+AST_MATCHER_P(clang::ParmVarDecl, isAtPosition, unsigned, N) {
+  constexpr char Name[] = "##isAtPosition_parmVar_";
+
+  // The direct parent of any parmVarDecl is a TypeLoc, and not a Decl,
+  // so we have to go up one more level.
+  return parmVarDecl(
+ hasParent(typeLoc(anyOf(hasParent(blockDecl(hasParameter(
+ N, parmVarDecl().bind(Name,
+ hasParent(objcMethodDecl(hasParameter(
+ N, parmVarDecl().bind(Name,
+ hasParent(functionDecl(hasParameter(
+ N, parmVarDecl().bind(Name))),
+ equalsBoundNode(Name))
+  .matches(Node, Finder, Builder);
+}
+
 /// Matches if the provided matcher does not match.
 ///
 /// Example matches Y (matcher = cxxRecordDecl(unless(hasName("X"
Index: clang/docs/LibASTMatchersReference.html
===
--- clang/docs/LibASTMatchersReference.html
+++ clang/docs/LibASTMatchersReference.html
@@ -1226,6 +1226,11 @@
 
 
 
+Matcherhttps://clang.llvm.org/doxygen/classclang_1_1Stmt.html;>StmtfixedPointLiteralMatcherhttps://clang.llvm.org/doxygen/classclang_1_1FixedPointLiteral.html;>FixedPointLiteral...
+Matches fixed point literals
+
+
+
 Matcherhttps://clang.llvm.org/doxygen/classclang_1_1Stmt.html;>StmtfloatLiteralMatcherhttps://clang.llvm.org/doxygen/classclang_1_1FloatingLiteral.html;>FloatingLiteral...
 Matches float literals of all sizes / encodings, e.g.
 1.0, 1.0f, 1.0L and 1e10.
@@ -4671,6 +4676,23 @@
 Usable as: Matcherhttps://clang.llvm.org/doxygen/classclang_1_1FunctionDecl.html;>FunctionDecl, Matcherhttps://clang.llvm.org/doxygen/classclang_1_1VarDecl.html;>VarDecl, Matcherhttps://clang.llvm.org/doxygen/classclang_1_1CXXRecordDecl.html;>CXXRecordDecl
 
 
+
+Matcherclang::ParmVarDeclisAtPositionunsigned N
+Matches the ParmVarDecl nodes that are at the N'th position in the parameter
+list. The parameter list could be that of either a block, function, or
+objc-method.
+
+
+Given
+
+void f(int a, int b, int c) {
+}
+

[PATCH] D80603: add isAtPosition narrowing matcher for parmVarDecl

[Vy Nguyen via Phabricator via cfe-commits]

oontvoo added a comment.

In D80603#2057014 , @aaron.ballman 
wrote:

> Does the `hasParameter()` matcher not already do this?


Yes, it does. But we'd like it to be able to match on the parmVarDecl().




Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:7018
+AST_MATCHER_P(clang::ParmVarDecl, isAtPosition, unsigned, N) {
+  return parmVarDecl(hasAncestor(functionDecl(
+ hasParameter(N, parmVarDecl().bind("this_decl",

ymandel wrote:
> I think that `hasAncestor` will keep going up the chain of ancestors if it 
> fails the match on the first surrounding `functionDecl`. That could make this 
> matcher very expensive.  Why hasParent (or, whatever combination of 
> `hasParent` and other matchers needed to precisely describe the immediately 
> surrounding `functionDecl`)?
> Why [not] hasParent ?

The direct parent of the param is a TypeLoc, so I thought `hasAncestor()` was 
more convenient. But I've changed it to two nested `hasParent()` now.




Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:7022
+  .matches(Node, Finder, Builder);
+}
+

gribozavr2 wrote:
> Could you move it closer to other parameter-related matchers, maybe near the 
> definition of `forEachArgumentWithParam`?
Moved it to after hasAncestor.
(Can't move to near forEachArgumentWithParam because that's before hasAncestor 
and hasParent, which are needed by this)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80603



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

[PATCH] D69764: [clang-format] Add East/West Const fixer capability

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D69764#2056104 , @rsmith wrote:

> I'm uncomfortable about `clang-format` performing this transformation at all. 
> Generally, clang-format only makes changes that are guaranteed to preserve 
> the meaning of the source program, and does not make changes that are only 
> heuristically likely to be semantics-preserving. But this transformation is 
> not behavior-preserving in a variety of cases, such as:
>
>   #define INTPTR int *
>   const INTPTR a;
>   // INTPTR const a; means something else
>


That's an excellent point. I agree that the formatting cannot change the 
meaning of the code that's being formatted -- that would be bad.

> I also don't think this is something that a user would *want* in 
> `clang-format`: changing the location of `const`s is something that would 
> likely be done rarely (probably only once) when migrating to a different 
> coding style, rather than being done on the fly after each edit to a source 
> file.

I'm not certain I agree with this. For instance, you can run clang-format as a 
precommit step or as part of your CI pipeline to bark at users when they get 
formatting incorrect while working on a team project. (We do this internally 
with some of our internal projects.)

> Fundamentally, I don't think this transformation is simply reformatting, and 
> I don't think it can be done sufficiently-correctly with only a 
> largely-context-free, heuristic-driven C++ parser. As such, I think this 
> belongs in `clang-tidy`, not in `clang-format`.

I think clang-tidy has the machinery needed to do this properly, but I think 
clang-format is logically where I would go to look for the functionality 
(certainly before thinking of clang-tidy) because this is more related to 
formatting than not. That said, if we cannot make it work reliably within 
clang-format, I'd rather see it in clang-tidy than nowhere.


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

https://reviews.llvm.org/D69764



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

[PATCH] D80020: [PowerPC] Add support for -mcpu=pwr10 in both clang and llvm

[Lei Huang via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG2368bf52cd77: [PowerPC] Add support for -mcpu=pwr10 in both 
clang and llvm (authored by lei).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80020

Files:
  clang/lib/Basic/Targets/PPC.cpp
  clang/lib/Basic/Targets/PPC.h
  clang/lib/Driver/ToolChains/Arch/PPC.cpp
  clang/test/Misc/target-invalid-cpu-note.c
  clang/test/Preprocessor/init-ppc64.c
  llvm/lib/Support/Host.cpp
  llvm/lib/Target/PowerPC/PPC.td
  llvm/lib/Target/PowerPC/PPCISelLowering.cpp
  llvm/lib/Target/PowerPC/PPCSubtarget.cpp
  llvm/lib/Target/PowerPC/PPCSubtarget.h
  llvm/lib/Target/PowerPC/PPCTargetTransformInfo.cpp
  llvm/test/CodeGen/PowerPC/check-cpu.ll

Index: llvm/test/CodeGen/PowerPC/check-cpu.ll
===
--- llvm/test/CodeGen/PowerPC/check-cpu.ll
+++ llvm/test/CodeGen/PowerPC/check-cpu.ll
@@ -2,9 +2,13 @@
 ; RUN: -mcpu=future < %s | FileCheck %s
 ; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu \
 ; RUN: -mcpu=future < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-linux-gnu \
+; RUN: -mcpu=power10 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-linux-gnu \
+; RUN: -mcpu=pwr10 < %s | FileCheck %s
 
 
-; Test mcpu=future that should be recognized on PowerPC.
+; Test -mcpu=[pwr10|future] is recognized on PowerPC.
 
 ; CHECK-NOT: is not a recognized processor for this target
 ; CHECK: .text
Index: llvm/lib/Target/PowerPC/PPCTargetTransformInfo.cpp
===
--- llvm/lib/Target/PowerPC/PPCTargetTransformInfo.cpp
+++ llvm/lib/Target/PowerPC/PPCTargetTransformInfo.cpp
@@ -651,11 +651,12 @@
   if (CacheLineSize.getNumOccurrences() > 0)
 return CacheLineSize;
 
-  // On P7, P8 or P9 we have a cache line size of 128.
+  // Starting with P7 we have a cache line size of 128.
   unsigned Directive = ST->getCPUDirective();
   // Assume that Future CPU has the same cache line size as the others.
   if (Directive == PPC::DIR_PWR7 || Directive == PPC::DIR_PWR8 ||
-  Directive == PPC::DIR_PWR9 || Directive == PPC::DIR_PWR_FUTURE)
+  Directive == PPC::DIR_PWR9 || Directive == PPC::DIR_PWR10 ||
+  Directive == PPC::DIR_PWR_FUTURE)
 return 128;
 
   // On other processors return a default of 64 bytes.
@@ -687,9 +688,11 @@
   // For P7 and P8, floating-point instructions have a 6-cycle latency and
   // there are two execution units, so unroll by 12x for latency hiding.
   // FIXME: the same for P9 as previous gen until POWER9 scheduling is ready
+  // FIXME: the same for P10 as previous gen until POWER10 scheduling is ready
   // Assume that future is the same as the others.
   if (Directive == PPC::DIR_PWR7 || Directive == PPC::DIR_PWR8 ||
-  Directive == PPC::DIR_PWR9 || Directive == PPC::DIR_PWR_FUTURE)
+  Directive == PPC::DIR_PWR9 || Directive == PPC::DIR_PWR10 ||
+  Directive == PPC::DIR_PWR_FUTURE)
 return 12;
 
   // For most things, modern systems have two execution units (and
Index: llvm/lib/Target/PowerPC/PPCSubtarget.h
===
--- llvm/lib/Target/PowerPC/PPCSubtarget.h
+++ llvm/lib/Target/PowerPC/PPCSubtarget.h
@@ -34,32 +34,33 @@
 
 namespace PPC {
   // -m directive values.
-  enum {
-DIR_NONE,
-DIR_32,
-DIR_440,
-DIR_601,
-DIR_602,
-DIR_603,
-DIR_7400,
-DIR_750,
-DIR_970,
-DIR_A2,
-DIR_E500,
-DIR_E500mc,
-DIR_E5500,
-DIR_PWR3,
-DIR_PWR4,
-DIR_PWR5,
-DIR_PWR5X,
-DIR_PWR6,
-DIR_PWR6X,
-DIR_PWR7,
-DIR_PWR8,
-DIR_PWR9,
-DIR_PWR_FUTURE,
-DIR_64
-  };
+enum {
+  DIR_NONE,
+  DIR_32,
+  DIR_440,
+  DIR_601,
+  DIR_602,
+  DIR_603,
+  DIR_7400,
+  DIR_750,
+  DIR_970,
+  DIR_A2,
+  DIR_E500,
+  DIR_E500mc,
+  DIR_E5500,
+  DIR_PWR3,
+  DIR_PWR4,
+  DIR_PWR5,
+  DIR_PWR5X,
+  DIR_PWR6,
+  DIR_PWR6X,
+  DIR_PWR7,
+  DIR_PWR8,
+  DIR_PWR9,
+  DIR_PWR10,
+  DIR_PWR_FUTURE,
+  DIR_64
+};
 }
 
 class GlobalValue;
@@ -138,6 +139,7 @@
   bool HasAddiLoadFusion;
   bool HasAddisLoadFusion;
   bool IsISA3_0;
+  bool IsISA3_1;
   bool UseLongCalls;
   bool SecurePlt;
   bool VectorsUseTwoUnits;
@@ -308,6 +310,7 @@
   bool hasHTM() const { return HasHTM; }
   bool hasFloat128() const { return HasFloat128; }
   bool isISA3_0() const { return IsISA3_0; }
+  bool isISA3_1() const { return IsISA3_1; }
   bool useLongCalls() const { return UseLongCalls; }
   bool hasFusion() const { return HasFusion; }
   bool hasAddiLoadFusion() const { return HasAddiLoadFusion; }
Index: llvm/lib/Target/PowerPC/PPCSubtarget.cpp
===
--- llvm/lib/Target/PowerPC/PPCSubtarget.cpp
+++ llvm/lib/Target/PowerPC/PPCSubtarget.cpp
@@ 

[PATCH] D80369: [DebugInfo][CallSites] Remove decl subprograms from 'retainedTypes:'

[Adrian Prantl via Phabricator via cfe-commits]

aprantl added a comment.

> The declaration subprograms are in the retained types list - but when 
> retained types are emitted, only types in the retained types list are used, 
> the subprograms (and the types they only indirectly reference) are ignored.

So adding the subprogram nodes to retained types has no effect? That's good to 
know. I think we can remove the code then, as long as the existing tests aren't 
affected.


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

https://reviews.llvm.org/D80369



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

[PATCH] D76791: [Matrix] Implement matrix index expressions ([][]).

[Florian Hahn via Phabricator via cfe-commits]

fhahn added inline comments.



Comment at: clang/include/clang/AST/Expr.h:2648
+/// MatrixSubscriptExpr - Matrix subscript expression for the MatrixType
+/// extension.
+class MatrixSubscriptExpr : public Expr {

rjmccall wrote:
> fhahn wrote:
> > rjmccall wrote:
> > > Oh, that's interesting.  So you've changed this to flatten the component 
> > > expressions?  I think that might be inconsistent with our usual 
> > > source-preservation goals unless you intend to restrict the intermediate 
> > > base expression to be an immediate subscript.  That is, this is okay if 
> > > you're going to require the user to write `matrix[i][j]` and forbid 
> > > `(matrix[i])[j]`, but if you intend to allow the latter, you should 
> > > preserve that structure here.  You can do that while still providing this 
> > > API; you just have to implement `getBase()` etc. by looking through 
> > > parens, and you should have an accessor which returns the syntactic base 
> > > expression.
> > > 
> > > What expression node do you use for the intermediate subscript 
> > > expression?  You should talk about this in the doc comment.
> > > Oh, that's interesting. So you've changed this to flatten the component 
> > > expressions? I think that might be inconsistent with our usual 
> > > source-preservation goals unless you intend to restrict the intermediate 
> > > base expression to be an immediate subscript. That is, this is okay if 
> > > you're going to require the user to write matrix[i][j] and forbid 
> > > (matrix[i])[j], but if you intend to allow the latter, you should 
> > > preserve that structure here. You can do that while still providing this 
> > > API; you just have to implement getBase() etc. by looking through parens, 
> > > and you should have an accessor which returns the syntactic base 
> > > expression.
> > 
> > My intuition was that the matrix subscript operator would be a single 
> > operator with 3 arguments. Allowing things like (matrix[I])[j] has 
> > potential for confusion I think, as there is no way to create an expression 
> > just referencing a row/column on its own. (responded in more details at the 
> > SemaExpr.cpp comment).
> > 
> > > What expression node do you use for the intermediate subscript 
> > > expression? You should talk about this in the doc comment.
> > 
> > Intermediate subscript expressions are represented as 'incomplete' 
> > MatrixSubscriptExpr (type is MatrixIncompleteIdx, ColumnIdx is nullptr). 
> > I've updated the comment.
> > My intuition was that the matrix subscript operator would be a single 
> > operator with 3 arguments. Allowing things like (matrix[I])[j] has 
> > potential for confusion I think, as there is no way to create an expression 
> > just referencing a row/column on its own. (responded in more details at the 
> > SemaExpr.cpp comment).
> 
> I think it's a perfectly reasonable language design to disallow parentheses 
> here; it just wasn't obvious at first that that was what you were intending 
> to do.
> 
> > Intermediate subscript expressions are represented as 'incomplete' 
> > MatrixSubscriptExpr (type is MatrixIncompleteIdx, ColumnIdx is nullptr). 
> > I've updated the comment.
> 
> Thanks.  In that case, there should be a way to more directly query whether a 
> particular expression is complete or not.
> Thanks. In that case, there should be a way to more directly query whether a 
> particular expression is complete or not.

Done, I've added an isIncomplete method. I also added assertions using it in a 
few places.



Comment at: clang/include/clang/Basic/Specifiers.h:159
+
+/// A single matrix element of a matrix.
+OK_MatrixElement

rjmccall wrote:
> fhahn wrote:
> > rjmccall wrote:
> > > redundancy
> > I suppose no comment is sufficient?
> A comment is a good idea; I was just pointing out that you'd written "a 
> matrix element of a matrix".
> 
> If you're intending to allow more complex matrix components in the future 
> (e.g. row/column projections), consider going ahead and calling this 
> `OK_MatrixComponent`. 
I've renamed it to OK_MatrixComponent and added a comment that a matrix 
component is a single element of a matrix.



Comment at: clang/lib/AST/ItaniumMangle.cpp:4238
+  case Expr::MatrixSubscriptExprClass:
+llvm_unreachable("matrix subscript expressions not supported yet");
+

rjmccall wrote:
> fhahn wrote:
> > rjmccall wrote:
> > > This is simple, you should just mangle them syntactically.  `'ixix'  > > expression>  `.  Test case is
> > > 
> > > ```
> > > using double4x4 = double __attribute__((matrix_type(4,4)));
> > > 
> > > template 
> > > auto matrix_subscript(double4x4 m, R r, C c) -> decltype(m[r][c]) {}
> > > 
> > > double test_matrix_subscript(double 4x4 m) { return m[3][2]; }
> > > ```
> > Thanks, I've updated the code as suggested and added the test.  I had to 
> > adjust the test slightly (adding a call to matrix_subscript).
> 

[PATCH] D80369: [DebugInfo][CallSites] Remove decl subprograms from 'retainedTypes:'

[Adrian Prantl via Phabricator via cfe-commits]

aprantl added a comment.

One way to make the tests more robust is capture the output in a `%t.ll` file 
and do repeated `RUN: cat %t.ll | FileCheck --check-prefix=TYPE1` lines. 
Anyway, oif the output is just reshuffled, this should be all fine.


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

https://reviews.llvm.org/D80369



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