[PATCH] D69145: Give readability-redundant-member-init an option IgnoreBaseInCopyConstructors to avoid breaking code with gcc -Werror=extra

2019-10-29 Thread Conrad Poelman via Phabricator via cfe-commits
poelmanc updated this revision to Diff 226847.
poelmanc added a comment.

Changed default to 1, updated help accordingly, and removed an extraneous set 
of braces around a one-line statement.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D69145

Files:
  clang-tools-extra/clang-tidy/readability/RedundantMemberInitCheck.cpp
  clang-tools-extra/clang-tidy/readability/RedundantMemberInitCheck.h
  clang-tools-extra/docs/clang-tidy/checks/readability-redundant-member-init.rst
  
clang-tools-extra/test/clang-tidy/checkers/readability-redundant-member-init.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/readability-redundant-member-init.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/readability-redundant-member-init.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/readability-redundant-member-init.cpp
@@ -1,4 +1,8 @@
 // RUN: %check_clang_tidy %s readability-redundant-member-init %t
+// RUN:   -config="{CheckOptions: \
+// RUN: [{key: readability-redundant-member-init.IgnoreBaseInCopyConstructors, \
+// RUN:   value: 1}] \
+// RUN: }"
 
 struct S {
   S() = default;
@@ -116,6 +120,35 @@
   };
 };
 
+// struct whose inline copy constructor default-initializes its base class
+struct WithCopyConstructor1 : public T {
+  WithCopyConstructor1(const WithCopyConstructor1& other) : T(),
+f(),
+g()
+  {}
+  S f, g;
+};
+// No warning in copy constructor about T since IgnoreBaseInCopyConstructors=1
+// CHECK-MESSAGES: :[[@LINE-6]]:5: warning: initializer for member 'f' is redundant
+// CHECK-MESSAGES: :[[@LINE-6]]:5: warning: initializer for member 'g' is redundant
+// CHECK-FIXES: WithCopyConstructor1(const WithCopyConstructor1& other) : T()
+// CHECK-NEXT: 
+// CHECK-NEXT: 
+// CHECK-NEXT: {}
+
+// struct whose copy constructor default-initializes its base class
+struct WithCopyConstructor2 : public T {
+  WithCopyConstructor2(const WithCopyConstructor2& other);
+  S a;
+};
+WithCopyConstructor2::WithCopyConstructor2(const WithCopyConstructor2& other)
+  : T(), a()
+{}
+// No warning in copy constructor about T since IgnoreBaseInCopyConstructors=1
+// CHECK-MESSAGES: :[[@LINE-3]]:10: warning: initializer for member 'a' is redundant
+// CHECK-FIXES: {{^}}  : T() {{$}}
+// CHECK-NEXT: {}
+
 // Initializer not written
 struct NF1 {
   NF1() {}
Index: clang-tools-extra/docs/clang-tidy/checks/readability-redundant-member-init.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/readability-redundant-member-init.rst
+++ clang-tools-extra/docs/clang-tidy/checks/readability-redundant-member-init.rst
@@ -6,7 +6,8 @@
 Finds member initializations that are unnecessary because the same default
 constructor would be called if they were not present.
 
-Example:
+Example
+---
 
 .. code-block:: c++
 
@@ -18,3 +19,27 @@
   private:
 std::string s;
   };
+
+Options
+---
+
+.. option:: IgnoreBaseInCopyConstructors
+
+Default is ``1``.
+
+When non-zero, the check will ignore unnecessary base class initializations
+within copy constructors, since some compilers issue warnings/errors when
+base classes are not explicitly intialized in copy constructors. For example,
+``gcc`` with ``-Wextra`` or ``-Werror=extra`` issues warning or error
+``base class ‘Bar’ should be explicitly initialized in the copy constructor``
+if ``Bar()`` were removed in the following example:
+
+.. code-block:: c++
+
+  // Explicitly initializing member s and base class Bar is unnecessary.
+  struct Foo : public Bar {
+// Remove s() below. If IgnoreBaseInCopyConstructors!=0, keep Bar().
+Foo(const Foo& foo) : Bar(), s() {}
+std::string s;
+  };
+
Index: clang-tools-extra/clang-tidy/readability/RedundantMemberInitCheck.h
===
--- clang-tools-extra/clang-tidy/readability/RedundantMemberInitCheck.h
+++ clang-tools-extra/clang-tidy/readability/RedundantMemberInitCheck.h
@@ -23,9 +23,15 @@
 class RedundantMemberInitCheck : public ClangTidyCheck {
 public:
   RedundantMemberInitCheck(StringRef Name, ClangTidyContext *Context)
-  : ClangTidyCheck(Name, Context) {}
+  : ClangTidyCheck(Name, Context),
+IgnoreBaseInCopyConstructors(
+Options.get("IgnoreBaseInCopyConstructors", 1)) {}
+  void storeOptions(ClangTidyOptions::OptionMap &Opts) override;
   void registerMatchers(ast_matchers::MatchFinder *Finder) override;
   void check(const ast_matchers::MatchFinder::MatchResult &Result) override;
+
+private:
+  bool IgnoreBaseInCopyConstructors;
 };
 
 } // namespace readability
Index: clang-tools-extra/clang-tidy/readability/RedundantMemberInitCheck.cpp
===
--- clang-tools-extra/clang-tidy/readability/Redunda

[PATCH] D68937: [clangd] Add parameter renaming to define-inline code action

2019-10-29 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet updated this revision to Diff 226849.
kadircet added a comment.

- Handle unnamed parameters explicitly


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68937

Files:
  clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp
  clang-tools-extra/clangd/unittests/TweakTests.cpp

Index: clang-tools-extra/clangd/unittests/TweakTests.cpp
===
--- clang-tools-extra/clangd/unittests/TweakTests.cpp
+++ clang-tools-extra/clangd/unittests/TweakTests.cpp
@@ -1489,6 +1489,45 @@
   EXPECT_EQ(apply(Test), Expected);
 }
 
+TEST_F(DefineInlineTest, TransformParamNames) {
+  EXPECT_EQ(apply(R"cpp(
+void foo(int, bool b, int T\
+est);
+
+void ^foo(int f, bool x, int z) {})cpp"), R"cpp(
+void foo(int f, bool x, int z){}
+
+)cpp");
+}
+
+TEST_F(DefineInlineTest, TransformTemplParamNames) {
+  EXPECT_EQ(apply(R"cpp(
+struct Foo {
+  struct Bar {
+template  class, template class Y,
+  int, int Z>
+void foo(X, Y, int W = 5 * Z + 2);
+  };
+};
+
+template  class V, template class W,
+  int X, int Y>
+void Foo::Bar::f^oo(U, W, int Q) {})cpp"),
+R"cpp(
+struct Foo {
+  struct Bar {
+template  class V, template class W,
+  int X, int Y>
+void foo(U, W, int Q = 5 * Y + 2){}
+  };
+};
+
+)cpp");
+}
+
 TEST_F(DefineInlineTest, TransformInlineNamespaces) {
   auto Test = R"cpp(
 namespace a { inline namespace b { namespace { struct Foo{}; } } }
Index: clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp
===
--- clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp
+++ clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp
@@ -226,6 +226,97 @@
   return QualifiedFunc->substr(BodyBegin, BodyEnd - BodyBegin + 1);
 }
 
+/// Generates Replacements for changing template and function parameter names in
+/// \p Dest to be the same as in \p Source.
+llvm::Expected
+renameParameters(const FunctionDecl *Dest, const FunctionDecl *Source) {
+  tooling::Replacements Replacements;
+
+  llvm::DenseMap ParamToNewName;
+  llvm::DenseMap> RefLocs;
+  auto HandleParam = [&](const NamedDecl *DestParam,
+ const NamedDecl *SourceParam) {
+// No need to rename if parameters already have the same name.
+if (DestParam->getName() == SourceParam->getName())
+  return;
+std::string NewName;
+// Unnamed parameters won't be visited in findExplicitReferences. So add
+// them here.
+if (DestParam->getName().empty()) {
+  RefLocs[DestParam].push_back(DestParam->getLocation());
+  // If decl is unnamed in destination we pad the new name to avoid gluing
+  // with previous token, e.g. foo(int^) shouldn't turn into foo(intx).
+  NewName = " ";
+}
+NewName.append(SourceParam->getName());
+ParamToNewName[DestParam->getCanonicalDecl()] = std::move(NewName);
+  };
+
+  // Populate mapping for template parameters.
+  auto *DestTempl = Dest->getDescribedFunctionTemplate();
+  auto *SourceTempl = Source->getDescribedFunctionTemplate();
+  assert(bool(DestTempl) == bool(SourceTempl));
+  if (DestTempl) {
+const auto *DestTPL = DestTempl->getTemplateParameters();
+const auto *SourceTPL = SourceTempl->getTemplateParameters();
+assert(DestTPL->size() == SourceTPL->size());
+
+for (size_t I = 0, EP = DestTPL->size(); I != EP; ++I)
+  HandleParam(DestTPL->getParam(I), SourceTPL->getParam(I));
+  }
+
+  // Populate mapping for function params.
+  for (size_t I = 0, E = Dest->param_size(); I != E; ++I)
+HandleParam(Dest->getParamDecl(I), Source->getParamDecl(I));
+
+  llvm::Error RenamingErrors = llvm::Error::success();
+  const SourceManager &SM = Dest->getASTContext().getSourceManager();
+  const LangOptions &LangOpts = Dest->getASTContext().getLangOpts();
+  // Collect other references in function signautre, i.e parameter types and
+  // default arguments.
+  findExplicitReferences(
+  // Use function template in case of templated functions to visit template
+  // parameters.
+  DestTempl ? llvm::dyn_cast(DestTempl) : llvm::dyn_cast(Dest),
+  [&](ReferenceLoc Ref) {
+if (Ref.Targets.size() != 1)
+  return;
+const auto *Target =
+llvm::cast(Ref.Targets.front()->getCanonicalDecl());
+auto It = ParamToNewName.find(Target);
+if (It == ParamToNewName.end())
+  return;
+RefLocs[Target].push_back(Ref.NameLoc);
+  });
+
+  for (auto &Entry : RefLocs) {
+const auto *OldDecl = Entry.first;
+llvm::StringRef OldName = OldDecl->getName();
+llvm::StringRef NewName = ParamToNewName[OldDecl];
+for (const SourceLocation &RefLoc : Entry.second) {
+  // Can't rely on OldName.size() because of multi-line identifiers, 

[PATCH] D68937: [clangd] Add parameter renaming to define-inline code action

2019-10-29 Thread pre-merge checks [bot] via Phabricator via cfe-commits
merge_guards_bot added a comment.

Build result: pass - 59704 tests passed, 0 failed and 762 were skipped.
Log files: console-log.txt 
,
 CMakeCache.txt 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68937



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


Re: [llvm-dev] Zorg migration to GitHub/monorepo

2019-10-29 Thread Diana Picus via cfe-commits
Hi Galina,

On Tue, 29 Oct 2019 at 04:42, Galina Kistanova  wrote:
>
> Hello Nemanja,
>
> > a commit to a project that shouldn't trigger builds on a libcxx bot (i.e. 
> > the change was in llvm).
>
> With all due respect, this does not sound right.
> I'm not sure how changes in a code a particular bot builds and tests
> should not trigger builds. In many cases this will lead to false blame
> lists, which is very annoying for developers, and hurt a quality of a
> bot. Could somebody elaborate a valid use case for this, please? If
> this is what Diana meant, of course.

Yes, this is what I meant. In the past, we only triggered builds for
commits to libcxx, libcxxabi and libunwind. E.g.
http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-armv7-linux/builds/1048

So I actually thought the bots were building without checking out
llvm. I now realize I was wrong and they did pull and build llvm as
well, so I guess the previous behaviour was buggy. Thanks for helping
us clarify this issue!

Cheers,
Diana

> > I have a somewhat orthogonal but related question. In the past, commits to 
> > compiler-rt did not trigger builds on llvm/clang/sanitizer bots. Has this 
> > behaviour been rectified with the move to github?
>
> Before the move we had a set of schedulers with manually specified
> list of projects to listen and assigned per group of bots. This was an
> error prone as people were adding bots without realizing that a group
> they add a bot to does not listen for a changes in some of the
> projects that particular bot depends on. You have mentioned an example
> of such issues.
>
> Now we use the dependency list for each of the monorepo-ready build
> factory (depends_on_projects param) to figure out what changes should
> trigger a build, as well as to configure the "-DLLVM_ENABLE_PROJECTS="
> cmake arg. The dependency list could be redefined per builder, if for
> any reason a build factory default doesn't work well. All the
> schedulers are configured automatically and every bot is served with
> changes to any and all projects it claims a dependency on. This should
> give a better and transparent way to define and track what would and
> what would not trigger a build. This is the idea at least. Some work
> remains to be done as not all of the build factories let redefine the
> dependency list yet, not all set "-DLLVM_ENABLE_PROJECTS=" properly,
> and such.
>
> Thanks
>
> Galina
>
> On Mon, Oct 28, 2019 at 5:09 PM Nemanja Ivanovic
>  wrote:
> >
> > I think what she is referring to was that the build seemed to be triggered 
> > by a commit to a project that shouldn't trigger builds on a libcxx bot 
> > (i.e. the change was in llvm).
> >
> > I have a somewhat orthogonal but related question. In the past, commits to 
> > compiler-rt did not trigger builds on llvm/clang/sanitizer bots. Has this 
> > behaviour been rectified with the move to github? I am really sorry if you 
> > already answered this question and I just missed it.
> >
> > On Mon, Oct 28, 2019 at 2:37 PM Galina Kistanova via llvm-dev 
> >  wrote:
> >>
> >> Hi Diana,
> >>
> >> It is not clear from your description of what is the problem. Could
> >> you elaborate, please?
> >>
> >> I have looked at the build history closer and see that this build
> >> configuration depends on libcxx, libcxxabi, libunwind, llvm projects,
> >> and changes to any of these would trigger a build. Depending on a bot
> >> performance, patches could be grouped to a longer blame list. To me,
> >> this is exactly how it supposedly should be. Are you missing any
> >> particular changes in libcxx, libcxxabi,or libunwind project which
> >> should trigger a build but they didn't? If so, could you point me to
> >> such change, please?
> >>
> >> Thanks
> >>
> >> Galina
> >>
> >>
> >>
> >> On Mon, Oct 28, 2019 at 5:16 AM Diana Picus  wrote:
> >> >
> >> > Hi Galina,
> >> >
> >> > It seems that our libcxx bots are now triggering builds for any changes 
> >> > to llvm:
> >> > http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux/builds/2434
> >> >
> >> > Should I file a bug report for this?
> >> >
> >> > Thanks,
> >> > Diana
> >> >
> >> > On Sat, 19 Oct 2019 at 11:36, Galina Kistanova via cfe-commits
> >> >  wrote:
> >> > >
> >> > > Hello everyone,
> >> > >
> >> > > The staging master is ready to accept bots from the list I have sent 
> >> > > yesterday. Don't wait too long.
> >> > >
> >> > > The master has been updated and works with both SVN and Github 
> >> > > monorepo now.
> >> > >
> >> > > The following builders are already listening for changes in monorepo 
> >> > > and building monorepo. More are coming.
> >> > >
> >> > > * clang-sphinx-docs
> >> > > * clang-tools-sphinx-docs
> >> > > * clang-x86_64-linux-abi-test
> >> > > * clang-lld-x86_64-2stage
> >> > > * libcxx-libcxxabi-singlethreaded-x86_64-linux-debian
> >> > > * libcxx-sphinx-docs
> >> > > * libunwind-sphinx-docs
> >> > > * lld-sphinx-docs
> >> > > * lld-x86_64-darwin13
> >> > > * lld-x86_64-ubu

[PATCH] D69506: [clangd] Add missing highlights for using decls.

2019-10-29 Thread Haojian Wu via Phabricator via cfe-commits
hokein updated this revision to Diff 226851.
hokein marked 2 inline comments as done.
hokein added a comment.

address remaining nits.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69506

Files:
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp


Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -584,6 +584,11 @@
   return $TemplateParameter[[T]]::$DependentName[[Field]];
 }
   };
+)cpp",
+  // Highlighting the using decl as the underlying using shadow decl.
+  R"cpp(
+  void $Function[[foo]]();
+  using ::$Function[[foo]];
 )cpp"};
   for (const auto &TestCase : TestCases) {
 checkHighlightings(TestCase);
Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -37,6 +37,10 @@
 
 llvm::Optional kindForType(const Type *TP);
 llvm::Optional kindForDecl(const NamedDecl *D) {
+  if (auto *USD = dyn_cast(D)) {
+if (auto *Target = USD->getTargetDecl())
+  D = Target;
+  }
   if (auto *TD = dyn_cast(D)) {
 if (auto *Templated = TD->getTemplatedDecl())
   D = Templated;
@@ -99,11 +103,10 @@
 return kindForDecl(TD);
   return llvm::None;
 }
-// Given a set of candidate declarations for an unresolved name,
-// if the declarations all have the same highlighting kind, return
-// that highlighting kind, otherwise return None.
-llvm::Optional
-kindForCandidateDecls(llvm::iterator_range Decls) {
+// Given a set of candidate declarations, if the declarations all have the same
+// highlighting kind, return that highlighting kind, otherwise return None.
+template 
+llvm::Optional kindForCandidateDecls(IteratorRange Decls) {
   llvm::Optional Result;
   for (NamedDecl *Decl : Decls) {
 auto Kind = kindForDecl(Decl);
@@ -196,6 +199,12 @@
 return true;
   }
 
+  bool VisitUsingDecl(UsingDecl *UD) {
+if (auto K = kindForCandidateDecls(UD->shadows()))
+  addToken(UD->getLocation(), *K);
+return true;
+  }
+
   bool VisitDeclRefExpr(DeclRefExpr *Ref) {
 if (canHighlightName(Ref->getNameInfo().getName()))
   addToken(Ref->getLocation(), Ref->getDecl());


Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -584,6 +584,11 @@
   return $TemplateParameter[[T]]::$DependentName[[Field]];
 }
   };
+)cpp",
+  // Highlighting the using decl as the underlying using shadow decl.
+  R"cpp(
+  void $Function[[foo]]();
+  using ::$Function[[foo]];
 )cpp"};
   for (const auto &TestCase : TestCases) {
 checkHighlightings(TestCase);
Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -37,6 +37,10 @@
 
 llvm::Optional kindForType(const Type *TP);
 llvm::Optional kindForDecl(const NamedDecl *D) {
+  if (auto *USD = dyn_cast(D)) {
+if (auto *Target = USD->getTargetDecl())
+  D = Target;
+  }
   if (auto *TD = dyn_cast(D)) {
 if (auto *Templated = TD->getTemplatedDecl())
   D = Templated;
@@ -99,11 +103,10 @@
 return kindForDecl(TD);
   return llvm::None;
 }
-// Given a set of candidate declarations for an unresolved name,
-// if the declarations all have the same highlighting kind, return
-// that highlighting kind, otherwise return None.
-llvm::Optional
-kindForCandidateDecls(llvm::iterator_range Decls) {
+// Given a set of candidate declarations, if the declarations all have the same
+// highlighting kind, return that highlighting kind, otherwise return None.
+template 
+llvm::Optional kindForCandidateDecls(IteratorRange Decls) {
   llvm::Optional Result;
   for (NamedDecl *Decl : Decls) {
 auto Kind = kindForDecl(Decl);
@@ -196,6 +199,12 @@
 return true;
   }
 
+  bool VisitUsingDecl(UsingDecl *UD) {
+if (auto K = kindForCandidateDecls(UD->shadows()))
+  addToken(UD->getLocation(), *K);
+return true;
+  }
+
   bool VisitDeclRefExpr(DeclRefExpr *Ref) {
 if (canHighlightName(Ref->getNameInfo().getName()))
   addToken(Ref->getLocation(), Ref->getDecl());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/

[clang-tools-extra] 94cd2f0 - [clangd] Add missing highlights for using decls.

2019-10-29 Thread Haojian Wu via cfe-commits

Author: Haojian Wu
Date: 2019-10-29T09:49:42+01:00
New Revision: 94cd2f03032475e26767cf11eb81fefb00fc4dc0

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

LOG: [clangd] Add missing highlights for using decls.

Reviewers: ilya-biryukov

Subscribers: MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang-tools-extra/clangd/SemanticHighlighting.cpp
clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/SemanticHighlighting.cpp 
b/clang-tools-extra/clangd/SemanticHighlighting.cpp
index 464cbc4fcf85..62d3a164b5b8 100644
--- a/clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ b/clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -37,6 +37,10 @@ bool canHighlightName(DeclarationName Name) {
 
 llvm::Optional kindForType(const Type *TP);
 llvm::Optional kindForDecl(const NamedDecl *D) {
+  if (auto *USD = dyn_cast(D)) {
+if (auto *Target = USD->getTargetDecl())
+  D = Target;
+  }
   if (auto *TD = dyn_cast(D)) {
 if (auto *Templated = TD->getTemplatedDecl())
   D = Templated;
@@ -99,11 +103,10 @@ llvm::Optional kindForType(const Type 
*TP) {
 return kindForDecl(TD);
   return llvm::None;
 }
-// Given a set of candidate declarations for an unresolved name,
-// if the declarations all have the same highlighting kind, return
-// that highlighting kind, otherwise return None.
-llvm::Optional
-kindForCandidateDecls(llvm::iterator_range Decls) {
+// Given a set of candidate declarations, if the declarations all have the same
+// highlighting kind, return that highlighting kind, otherwise return None.
+template 
+llvm::Optional kindForCandidateDecls(IteratorRange Decls) {
   llvm::Optional Result;
   for (NamedDecl *Decl : Decls) {
 auto Kind = kindForDecl(Decl);
@@ -196,6 +199,12 @@ class HighlightingTokenCollector
 return true;
   }
 
+  bool VisitUsingDecl(UsingDecl *UD) {
+if (auto K = kindForCandidateDecls(UD->shadows()))
+  addToken(UD->getLocation(), *K);
+return true;
+  }
+
   bool VisitDeclRefExpr(DeclRefExpr *Ref) {
 if (canHighlightName(Ref->getNameInfo().getName()))
   addToken(Ref->getLocation(), Ref->getDecl());

diff  --git a/clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp 
b/clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
index 9d33b523f69b..139773b616ea 100644
--- a/clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ b/clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -584,6 +584,11 @@ TEST(SemanticHighlighting, GetsCorrectTokens) {
   return $TemplateParameter[[T]]::$DependentName[[Field]];
 }
   };
+)cpp",
+  // Highlighting the using decl as the underlying using shadow decl.
+  R"cpp(
+  void $Function[[foo]]();
+  using ::$Function[[foo]];
 )cpp"};
   for (const auto &TestCase : TestCases) {
 checkHighlightings(TestCase);



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


[PATCH] D69506: [clangd] Add missing highlights for using decls.

2019-10-29 Thread Haojian Wu via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG94cd2f030324: [clangd] Add missing highlights for using 
decls. (authored by hokein).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69506

Files:
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp


Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -584,6 +584,11 @@
   return $TemplateParameter[[T]]::$DependentName[[Field]];
 }
   };
+)cpp",
+  // Highlighting the using decl as the underlying using shadow decl.
+  R"cpp(
+  void $Function[[foo]]();
+  using ::$Function[[foo]];
 )cpp"};
   for (const auto &TestCase : TestCases) {
 checkHighlightings(TestCase);
Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -37,6 +37,10 @@
 
 llvm::Optional kindForType(const Type *TP);
 llvm::Optional kindForDecl(const NamedDecl *D) {
+  if (auto *USD = dyn_cast(D)) {
+if (auto *Target = USD->getTargetDecl())
+  D = Target;
+  }
   if (auto *TD = dyn_cast(D)) {
 if (auto *Templated = TD->getTemplatedDecl())
   D = Templated;
@@ -99,11 +103,10 @@
 return kindForDecl(TD);
   return llvm::None;
 }
-// Given a set of candidate declarations for an unresolved name,
-// if the declarations all have the same highlighting kind, return
-// that highlighting kind, otherwise return None.
-llvm::Optional
-kindForCandidateDecls(llvm::iterator_range Decls) {
+// Given a set of candidate declarations, if the declarations all have the same
+// highlighting kind, return that highlighting kind, otherwise return None.
+template 
+llvm::Optional kindForCandidateDecls(IteratorRange Decls) {
   llvm::Optional Result;
   for (NamedDecl *Decl : Decls) {
 auto Kind = kindForDecl(Decl);
@@ -196,6 +199,12 @@
 return true;
   }
 
+  bool VisitUsingDecl(UsingDecl *UD) {
+if (auto K = kindForCandidateDecls(UD->shadows()))
+  addToken(UD->getLocation(), *K);
+return true;
+  }
+
   bool VisitDeclRefExpr(DeclRefExpr *Ref) {
 if (canHighlightName(Ref->getNameInfo().getName()))
   addToken(Ref->getLocation(), Ref->getDecl());


Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -584,6 +584,11 @@
   return $TemplateParameter[[T]]::$DependentName[[Field]];
 }
   };
+)cpp",
+  // Highlighting the using decl as the underlying using shadow decl.
+  R"cpp(
+  void $Function[[foo]]();
+  using ::$Function[[foo]];
 )cpp"};
   for (const auto &TestCase : TestCases) {
 checkHighlightings(TestCase);
Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -37,6 +37,10 @@
 
 llvm::Optional kindForType(const Type *TP);
 llvm::Optional kindForDecl(const NamedDecl *D) {
+  if (auto *USD = dyn_cast(D)) {
+if (auto *Target = USD->getTargetDecl())
+  D = Target;
+  }
   if (auto *TD = dyn_cast(D)) {
 if (auto *Templated = TD->getTemplatedDecl())
   D = Templated;
@@ -99,11 +103,10 @@
 return kindForDecl(TD);
   return llvm::None;
 }
-// Given a set of candidate declarations for an unresolved name,
-// if the declarations all have the same highlighting kind, return
-// that highlighting kind, otherwise return None.
-llvm::Optional
-kindForCandidateDecls(llvm::iterator_range Decls) {
+// Given a set of candidate declarations, if the declarations all have the same
+// highlighting kind, return that highlighting kind, otherwise return None.
+template 
+llvm::Optional kindForCandidateDecls(IteratorRange Decls) {
   llvm::Optional Result;
   for (NamedDecl *Decl : Decls) {
 auto Kind = kindForDecl(Decl);
@@ -196,6 +199,12 @@
 return true;
   }
 
+  bool VisitUsingDecl(UsingDecl *UD) {
+if (auto K = kindForCandidateDecls(UD->shadows()))
+  addToken(UD->getLocation(), *K);
+return true;
+  }
+
   bool VisitDeclRefExpr(DeclRefExpr *Ref) {
 if (canHighlightName(Ref->getNameInfo().getName()))
   addToken(Ref->getLocation(), Ref->getDecl());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https

Re: r374288 - Recommit "[Clang] Pragma vectorize_width() implies vectorize(enable)"

2019-10-29 Thread Sjoerd Meijer via cfe-commits
Hi All,

Apologies for the delay in responding, I was away from keyboard (llvm dev conf).

This is a real funny patch! It is a (simple) fix that uncovers quite a few 
things. Anyway, thanks Michael for your analysis! As I will need to make some 
changes this time (this wasn't the case last time), I definitely definitely 
open a new review soon.

Cheers,
Sjoerd.

From: Michael Kruse 
Sent: 25 October 2019 23:18
To: Jordan Rupprecht 
Cc: Michael Kruse ; Hans Wennborg 
; cfe-commits ; Hal Finkel 
; Sjoerd Meijer 
Subject: Re: r374288 - Recommit "[Clang] Pragma vectorize_width() implies 
vectorize(enable)"

@sjoerdmeijer

Before recommitting, please re-open the patch review.

Michael

Am Do., 24. Okt. 2019 um 18:45 Uhr schrieb Jordan Rupprecht
:
>
> Reverted in 6d424a161bf3e52730371da0b9439ed93a8ce406 due to the issue 
> described here. Should hopefully be a trivial fix forward.
>
> On Tue, Oct 22, 2019 at 2:46 PM Michael Kruse  
> wrote:
>>
>> Am Mo., 21. Okt. 2019 um 23:44 Uhr schrieb Jordan Rupprecht
>> :
>> > At any rate, it sounds like this is not a codegen bug at all, but just an 
>> > over-eager warning?
>>
>> That interpretation is different from mine. Codgen emits the following
>> from vectorize(disable)
>>
>> !4 = !{!"llvm.loop.vectorize.enable", i1 true}
>>
>> which is is not what I'd expect.
>>
>> Michael
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D69544: [clangd] NFC, reuse the source manager variable in the RawStringLiteral apply method

2019-10-29 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov accepted this revision.
ilya-biryukov added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69544



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


[clang-tools-extra] f821ab8 - [clangd] NFC, use URI::resolve to simplify the code.

2019-10-29 Thread Haojian Wu via cfe-commits

Author: Haojian Wu
Date: 2019-10-29T10:53:16+01:00
New Revision: f821ab807debdc973066ea43ac23173ef08dc2f5

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

LOG: [clangd] NFC, use URI::resolve to simplify the code.

Added: 


Modified: 
clang-tools-extra/clangd/refactor/Rename.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/refactor/Rename.cpp 
b/clang-tools-extra/clangd/refactor/Rename.cpp
index f38815a1f14a..a594f7a78102 100644
--- a/clang-tools-extra/clangd/refactor/Rename.cpp
+++ b/clang-tools-extra/clangd/refactor/Rename.cpp
@@ -25,17 +25,13 @@ llvm::Optional filePath(const SymbolLocation 
&Loc,
  llvm::StringRef HintFilePath) {
   if (!Loc)
 return None;
-  auto Uri = URI::parse(Loc.FileURI);
-  if (!Uri) {
-elog("Could not parse URI {0}: {1}", Loc.FileURI, Uri.takeError());
+  auto Path = URI::resolve(Loc.FileURI, HintFilePath);
+  if (!Path) {
+elog("Could not resolve URI {0}: {1}", Loc.FileURI, Path.takeError());
 return None;
   }
-  auto U = URIForFile::fromURI(*Uri, HintFilePath);
-  if (!U) {
-elog("Could not resolve URI {0}: {1}", Loc.FileURI, U.takeError());
-return None;
-  }
-  return U->file().str();
+
+  return *Path;
 }
 
 // Query the index to find some other files where the Decl is referenced.



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


[PATCH] D69517: [clangd] Add a hidden tweak to dump symbol under the curosr.

2019-10-29 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov accepted this revision.
ilya-biryukov added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69517



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


[PATCH] D69517: [clangd] Add a hidden tweak to dump symbol under the curosr.

2019-10-29 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov added a comment.

NIT: a typo in the title: s/curosr/cursor


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69517



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


[PATCH] D68937: [clangd] Add parameter renaming to define-inline code action

2019-10-29 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov added a comment.

Just a few final NITs from my side. 
And would also be nice to get tests with macros.




Comment at: clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp:251
+}
+NewName.append(SourceParam->getName());
+ParamToNewName[DestParam->getCanonicalDecl()] = std::move(NewName);

NIT: maybe use assignment syntax?
 `NewName += SourceParam->getName()`



Comment at: clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp:270
+  for (size_t I = 0, E = Dest->param_size(); I != E; ++I)
+HandleParam(Dest->getParamDecl(I), Source->getParamDecl(I));
+

NIT: also add `assert(Source->param_size() == Dest->param_size())`?



Comment at: clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp:275
+  const LangOptions &LangOpts = Dest->getASTContext().getLangOpts();
+  // Collect other references in function signautre, i.e parameter types and
+  // default arguments.

s/signautre/signature



Comment at: clang-tools-extra/clangd/unittests/TweakTests.cpp:1492
 
+TEST_F(DefineInlineTest, TransformParamNames) {
+  EXPECT_EQ(apply(R"cpp(

Could you add tests with some parameter references inside macro expansions?
To make sure we don't crash and don't produce invalid edits? Failing is 
obviously ok


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68937



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


[PATCH] D69543: [WIP][clangd] Add a tweak refactoring to wrap Objective-C string literals in `NSLocalizedString` macros

2019-10-29 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added inline comments.



Comment at: clang-tools-extra/clangd/unittests/TweakTests.cpp:127
+TEST_F(ObjCLocalizeStringLiteralTest, Test) {
+  ExtraArgs.push_back("-x=objective-c");
+  Context = Expression;

make sure this is rebased on top of 
http://github.com/llvm/llvm-project/commit/1a9c01c7f6c7e88676440869bbbe9f43fa45b109



Comment at: clang-tools-extra/clangd/unittests/TweakTests.cpp:129
+  Context = Expression;
+  EXPECT_AVAILABLE("@\"test string\"");
+}

maybe use raw string literals?
```
R"(@"teststring")"
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69543



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


[PATCH] D69215: [DWARF5] Added support for deleted C++ special member functions.

2019-10-29 Thread Sourabh Singh Tomar via Phabricator via cfe-commits
SouraVX added a comment.

Hi Adrian, Thanks for taking out time for reviewing this. I've again updated 
doc.
Currently we're in process of getting commit access, discussion with Tom in 
progress

So, could you please commit these changes.
Thank you so much!


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

https://reviews.llvm.org/D69215



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


[PATCH] D69215: [DWARF5] Added support for deleted C++ special member functions.

2019-10-29 Thread Sourabh Singh Tomar via Phabricator via cfe-commits
SouraVX updated this revision to Diff 226867.
SouraVX added a comment.

Updated doc.


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

https://reviews.llvm.org/D69215

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/CodeGenCXX/debug-info-deleted.cpp
  llvm/docs/SourceLevelDebugging.rst
  llvm/include/llvm/BinaryFormat/Dwarf.h
  llvm/include/llvm/IR/DebugInfoFlags.def
  llvm/include/llvm/IR/DebugInfoMetadata.h
  llvm/lib/BinaryFormat/Dwarf.cpp
  llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
  llvm/test/DebugInfo/X86/DW_AT_deleted.ll

Index: llvm/test/DebugInfo/X86/DW_AT_deleted.ll
===
--- /dev/null
+++ llvm/test/DebugInfo/X86/DW_AT_deleted.ll
@@ -0,0 +1,110 @@
+; RUN: llc < %s -filetype=obj -o %t
+; RUN: llvm-dwarfdump -v %t | FileCheck %s
+
+; C++ source to regenerate:
+; class deleted {
+; public:
+;   // Defaulted on purpose, so as to facilitate object creation
+;deleted() = default;
+; 
+;   deleted(const deleted &) = delete;
+;   deleted &operator=(const deleted &) = delete;
+; 
+;   deleted(deleted &&) = delete;
+;   deleted &operator=(deleted &&) = delete;
+; 
+;   ~deleted() = default;
+; };
+; 
+; void foo() {
+;   deleted obj1;
+; }
+; $ clang++ -O0 -g -gdwarf-5 debug-info-deleted.cpp -c
+
+
+; CHECK: .debug_abbrev contents:
+
+; CHECK: [7] DW_TAG_subprogram   DW_CHILDREN_yes
+; CHECK: DW_AT_deleted   DW_FORM_flag_present
+; CHECK: [9] DW_TAG_subprogram   DW_CHILDREN_yes
+; CHECK: DW_AT_deleted   DW_FORM_flag_present
+
+; CHECK: .debug_info contents:
+
+; CHECK: DW_TAG_subprogram [7]
+; CHECK-NEXT: DW_AT_name [DW_FORM_strx1](indexed (0006) string = "deleted") 
+; CHECK:  DW_AT_deleted [DW_FORM_flag_present]  (true)
+
+; CHECK: DW_TAG_subprogram [9]
+; CHECK-NEXT: DW_AT_linkage_name [DW_FORM_strx1](indexed (0007) string = "_ZN7deletedaSERKS_") 
+; CHECK:  DW_AT_deleted [DW_FORM_flag_present]  (true)
+
+; CHECK: DW_TAG_subprogram [7]
+; CHECK-NEXT: DW_AT_name [DW_FORM_strx1](indexed (0006) string = "deleted") 
+; CHECK:  DW_AT_deleted [DW_FORM_flag_present]  (true)
+
+; CHECK: DW_TAG_subprogram [9]
+; CHECK-NEXT: DW_AT_linkage_name [DW_FORM_strx1](indexed (0009) string = "_ZN7deletedaSEOS_")
+; CHECK-NEXT: DW_AT_name [DW_FORM_strx1](indexed (0008) string = "operator=")
+; CHECK:  DW_AT_deleted [DW_FORM_flag_present]  (true)
+
+; ModuleID = 'debug-info-deleted.cpp'
+source_filename = "debug-info-deleted.cpp"
+target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+%class.deleted = type { i8 }
+
+; Function Attrs: noinline nounwind optnone uwtable
+define dso_local void @_Z3foov() #0 !dbg !7 {
+  %1 = alloca %class.deleted, align 1
+  call void @llvm.dbg.declare(metadata %class.deleted* %1, metadata !10, metadata !DIExpression()), !dbg !34
+  ret void, !dbg !35
+}
+
+; Function Attrs: nounwind readnone speculatable willreturn
+declare void @llvm.dbg.declare(metadata, metadata, metadata) #1
+
+attributes #0 = { noinline nounwind optnone uwtable }
+attributes #1 = { nounwind readnone speculatable willreturn }
+
+!llvm.dbg.cu = !{!0}
+!llvm.module.flags = !{!3, !4, !5}
+!llvm.ident = !{!6}
+
+!0 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus_14, file: !1, producer: "clang version 10.0.0 (https://github.com/llvm/llvm-project.git 715c47d5de9aa8860050992a7aaf27dca53f7f4a)", isOptimized: false, runtimeVersion: 0, emissionKind: FullDebug, enums: !2, nameTableKind: None)
+!1 = !DIFile(filename: "debug-info-deleted.cpp", directory: "/home/sourabh/work/dwarf/c_c++/c++11", checksumkind: CSK_MD5, checksum: "49dc56907586479c64634558b060292d")
+!2 = !{}
+!3 = !{i32 2, !"Dwarf Version", i32 5}
+!4 = !{i32 2, !"Debug Info Version", i32 3}
+!5 = !{i32 1, !"wchar_size", i32 4}
+!6 = !{!"clang version 10.0.0 (https://github.com/llvm/llvm-project.git 715c47d5de9aa8860050992a7aaf27dca53f7f4a)"}
+!7 = distinct !DISubprogram(name: "foo", linkageName: "_Z3foov", scope: !1, file: !1, line: 14, type: !8, scopeLine: 14, flags: DIFlagPrototyped, spFlags: DISPFlagDefinition, unit: !0, retainedNodes: !2)
+!8 = !DISubroutineType(types: !9)
+!9 = !{null}
+!10 = !DILocalVariable(name: "obj1", scope: !7, file: !1, line: 15, type: !11)
+!11 = distinct !DICompositeType(tag: DW_TAG_class_type, name: "deleted", file: !1, line: 1, size: 8, flags: DIFlagTypePassByReference, elements: !12, identifier: "_ZTS7deleted")
+!12 = !{!13, !17, !22, !26, !30, !33}
+!13 = !DISubprogram(name: "deleted", scope: !11, file: !1, line: 3, type: !14, scopeLine: 3, flags: DIFlagPublic | DIFlagPrototyped, spFlags: 0)
+!14 = !DISubroutineType(types: !15)
+!15 = !{null, !16}
+!16 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !11, size: 64, flags: DIFlagArtificial | DIFlagObjectPointer)
+!17 = !DISubprogram(name: "deleted", scope: !11, file: !1, line: 5, type: !18, scopeLine: 5, flags: DIFlagPublic | DIFlagPrototyped, spFlags: DISPFlagDel

[PATCH] D69498: IR: Invert convergent attribute handling

2019-10-29 Thread Nicolai Hähnle via Phabricator via cfe-commits
nhaehnle added a comment.

As you know, I am very much in favor of this change, and really anything that 
re-establishes the rule that code is treated maximally conservatively when 
there are no attributes or metadata.

There is one slight concern here because what we arguably need in SIMT targets 
is two attributes, which I'm going to call `allowconvergence` and 
`allowdivergence` for now. Convergent operations are operations that 
communicate with some set of other threads that is implicitly affected by where 
the operation is in control flow. If we have as a baseline that this set of 
threads must not be changed at all by transforms, then there are two directions 
in which this can be relaxed:

- It may be correct to transform code in a way that may cause **more** threads 
to communicate. This applies e.g. to OpenCL uniform barriers and could be 
expressed as `allowconvergence`.
- It may be correct to transform code in a way that may cause **fewer** threads 
to communicate. This applies to readanylane-style operations (which are 
implicit e.g. in some of our buffer and image intrinsics) and could be 
expressed as `allowdivergence`.

Though non-SIMT targets may not want to add two attributes everywhere. Perhaps 
a viable path forward is to take this change towards `noconvergent` now if we 
can still add `allowconvergence` and `allowdivergence` later; `noconvergent` 
would then simply be the union of those two attributes in the end.


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

https://reviews.llvm.org/D69498



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


[PATCH] D68937: [clangd] Add parameter renaming to define-inline code action

2019-10-29 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet updated this revision to Diff 226868.
kadircet marked 3 inline comments as done.
kadircet added a comment.

- Handle macros in parameter names.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68937

Files:
  clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp
  clang-tools-extra/clangd/unittests/TweakTests.cpp

Index: clang-tools-extra/clangd/unittests/TweakTests.cpp
===
--- clang-tools-extra/clangd/unittests/TweakTests.cpp
+++ clang-tools-extra/clangd/unittests/TweakTests.cpp
@@ -40,9 +40,9 @@
 #include 
 
 using ::testing::AllOf;
+using ::testing::ElementsAre;
 using ::testing::HasSubstr;
 using ::testing::StartsWith;
-using ::testing::ElementsAre;
 
 namespace clang {
 namespace clangd {
@@ -1489,6 +1489,64 @@
   EXPECT_EQ(apply(Test), Expected);
 }
 
+TEST_F(DefineInlineTest, TransformParamNames) {
+  EXPECT_EQ(apply(R"cpp(
+void foo(int, bool b, int T\
+est);
+
+void ^foo(int f, bool x, int z) {})cpp"),
+R"cpp(
+void foo(int f, bool x, int z){}
+
+)cpp");
+
+  EXPECT_EQ(apply(R"cpp(
+#define TYPE int
+#define PARAM TYPE Z
+#define BODY(x) 5 * (x) + 2
+template 
+void foo(PARAM, TYPE Q, TYPE, TYPE W = BODY(P));
+
+template 
+void ^foo(int a, int b, int c, int d) {})cpp"),
+R"cpp(
+#define TYPE int
+#define PARAM TYPE Z
+#define BODY(x) 5 * (x) + 2
+template 
+void foo(PARAM, TYPE b, TYPE c, TYPE d = BODY(x)){}
+
+)cpp");
+}
+
+TEST_F(DefineInlineTest, TransformTemplParamNames) {
+  EXPECT_EQ(apply(R"cpp(
+struct Foo {
+  struct Bar {
+template  class, template class Y,
+  int, int Z>
+void foo(X, Y, int W = 5 * Z + 2);
+  };
+};
+
+template  class V, template class W,
+  int X, int Y>
+void Foo::Bar::f^oo(U, W, int Q) {})cpp"),
+R"cpp(
+struct Foo {
+  struct Bar {
+template  class V, template class W,
+  int X, int Y>
+void foo(U, W, int Q = 5 * Y + 2){}
+  };
+};
+
+)cpp");
+}
+
 TEST_F(DefineInlineTest, TransformInlineNamespaces) {
   auto Test = R"cpp(
 namespace a { inline namespace b { namespace { struct Foo{}; } } }
Index: clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp
===
--- clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp
+++ clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp
@@ -226,6 +226,105 @@
   return QualifiedFunc->substr(BodyBegin, BodyEnd - BodyBegin + 1);
 }
 
+/// Generates Replacements for changing template and function parameter names in
+/// \p Dest to be the same as in \p Source.
+llvm::Expected
+renameParameters(const FunctionDecl *Dest, const FunctionDecl *Source) {
+  tooling::Replacements Replacements;
+
+  llvm::DenseMap ParamToNewName;
+  llvm::DenseMap> RefLocs;
+  auto HandleParam = [&](const NamedDecl *DestParam,
+ const NamedDecl *SourceParam) {
+// No need to rename if parameters already have the same name.
+if (DestParam->getName() == SourceParam->getName())
+  return;
+std::string NewName;
+// Unnamed parameters won't be visited in findExplicitReferences. So add
+// them here.
+if (DestParam->getName().empty()) {
+  RefLocs[DestParam].push_back(DestParam->getLocation());
+  // If decl is unnamed in destination we pad the new name to avoid gluing
+  // with previous token, e.g. foo(int^) shouldn't turn into foo(intx).
+  NewName = " ";
+}
+NewName.append(SourceParam->getName());
+ParamToNewName[DestParam->getCanonicalDecl()] = std::move(NewName);
+  };
+
+  // Populate mapping for template parameters.
+  auto *DestTempl = Dest->getDescribedFunctionTemplate();
+  auto *SourceTempl = Source->getDescribedFunctionTemplate();
+  assert(bool(DestTempl) == bool(SourceTempl));
+  if (DestTempl) {
+const auto *DestTPL = DestTempl->getTemplateParameters();
+const auto *SourceTPL = SourceTempl->getTemplateParameters();
+assert(DestTPL->size() == SourceTPL->size());
+
+for (size_t I = 0, EP = DestTPL->size(); I != EP; ++I)
+  HandleParam(DestTPL->getParam(I), SourceTPL->getParam(I));
+  }
+
+  // Populate mapping for function params.
+  assert(Dest->param_size() == Source->param_size());
+  for (size_t I = 0, E = Dest->param_size(); I != E; ++I)
+HandleParam(Dest->getParamDecl(I), Source->getParamDecl(I));
+
+  llvm::Error RenamingErrors = llvm::Error::success();
+  const SourceManager &SM = Dest->getASTContext().getSourceManager();
+  const LangOptions &LangOpts = Dest->getASTContext().getLangOpts();
+  // Collect other references in function signature, i.e parameter types and
+  // default arguments.
+  findExplicitReferences(
+  // Use function template in case of templated functions to visit te

[PATCH] D68937: [clangd] Add parameter renaming to define-inline code action

2019-10-29 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov added inline comments.



Comment at: clang-tools-extra/clangd/unittests/TweakTests.cpp:1517
+template 
+void foo(PARAM, TYPE b, TYPE c, TYPE d = BODY(x)){}
+

We fail to rename the parameter in that case, right?
Should the action not be available or maybe show an error message?

Also ok with keeping the current behavior if we add a FIXME mentioning it would 
be nice to fix this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68937



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


[PATCH] D67706: [clang][analyzer] Using CallDescription in StreamChecker.

2019-10-29 Thread Balázs Kéri via Phabricator via cfe-commits
balazske added a comment.

Ping again


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67706



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


[PATCH] D69145: Give readability-redundant-member-init an option IgnoreBaseInCopyConstructors to avoid breaking code with gcc -Werror=extra

2019-10-29 Thread Malcolm Parsons via Phabricator via cfe-commits
malcolm.parsons added a comment.

I like that this check warns about copy constructors that don't copy.
The warning can be suppressed with a NOLINT comment if not copying is 
intentional.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D69145



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


[PATCH] D68937: [clangd] Add parameter renaming to define-inline code action

2019-10-29 Thread pre-merge checks [bot] via Phabricator via cfe-commits
merge_guards_bot added a comment.

Build result: pass - 59704 tests passed, 0 failed and 762 were skipped.
Log files: console-log.txt 
,
 CMakeCache.txt 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68937



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


[PATCH] D63607: [clang][driver] Add basic --driver-mode=flang support for fortran

2019-10-29 Thread Peter Waller via Phabricator via cfe-commits
peterwaller-arm marked an inline comment as done.
peterwaller-arm added a comment.

I'm still awaiting commit access, please can someone submit this on my behalf?


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

https://reviews.llvm.org/D63607



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


[PATCH] D67706: [clang][analyzer] Using CallDescription in StreamChecker.

2019-10-29 Thread Csaba Dabis via Phabricator via cfe-commits
Charusso added a reviewer: Charusso.
Charusso requested changes to this revision.
Charusso added a comment.
This revision now requires changes to proceed.

Could you please mark resolved issues as resolved? I would like to see what we 
miss, and what has been done.




Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:61
+  using FnCheck = bool (StreamChecker::*)(const CallEvent &,
+  CheckerContext &) const;
+

I prefer `std::function`, because it is modern.
```
  using StreamCheck = 
  std::function;
```
I think it is fine with pointers, but at some point we need to modernize this.



Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:64
+  CallDescriptionMap Callbacks = {
+  {{"fopen"}, &StreamChecker::evalFopen},
+  {{"tmpfile"}, &StreamChecker::evalTmpfile},

Because `evalFopen()` is basically the `OpenFileAux(Call, C);`, I think we 
could simplify the API by removing unnecessary one-liners so here you could 
write `{{"fopen"}, &StreamChecker::OpenFileAux`, that is why the `CallEvent` 
parameter is so generic and useful.



Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:99
+  Optional CheckNullStream(SVal SV, CheckerContext &C) const;
+  Optional CheckDoubleClose(const CallEvent &Call,
+ CheckerContext &C) const;

This `Optional` is not necessary. When the state is changed, you can rely on 
`CheckerContext::isDifferent()` to see whether the modeling was succeeded. 
Therefore you could revert the `bool` return values as well.



Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:117
 
-  ASTContext &Ctx = C.getASTContext();
-  if (!II_fopen)
-II_fopen = &Ctx.Idents.get("fopen");
-  if (!II_tmpfile)
-II_tmpfile = &Ctx.Idents.get("tmpfile");
-  if (!II_fclose)
-II_fclose = &Ctx.Idents.get("fclose");
-  if (!II_fread)
-II_fread = &Ctx.Idents.get("fread");
-  if (!II_fwrite)
-II_fwrite = &Ctx.Idents.get("fwrite");
-  if (!II_fseek)
-II_fseek = &Ctx.Idents.get("fseek");
-  if (!II_ftell)
-II_ftell = &Ctx.Idents.get("ftell");
-  if (!II_rewind)
-II_rewind = &Ctx.Idents.get("rewind");
-  if (!II_fgetpos)
-II_fgetpos = &Ctx.Idents.get("fgetpos");
-  if (!II_fsetpos)
-II_fsetpos = &Ctx.Idents.get("fsetpos");
-  if (!II_clearerr)
-II_clearerr = &Ctx.Idents.get("clearerr");
-  if (!II_feof)
-II_feof = &Ctx.Idents.get("feof");
-  if (!II_ferror)
-II_ferror = &Ctx.Idents.get("ferror");
-  if (!II_fileno)
-II_fileno = &Ctx.Idents.get("fileno");
-
-  if (FD->getIdentifier() == II_fopen) {
-Fopen(C, CE);
-return true;
-  }
-  if (FD->getIdentifier() == II_tmpfile) {
-Tmpfile(C, CE);
-return true;
-  }
-  if (FD->getIdentifier() == II_fclose) {
-Fclose(C, CE);
-return true;
-  }
-  if (FD->getIdentifier() == II_fread) {
-Fread(C, CE);
-return true;
-  }
-  if (FD->getIdentifier() == II_fwrite) {
-Fwrite(C, CE);
-return true;
-  }
-  if (FD->getIdentifier() == II_fseek) {
-Fseek(C, CE);
-return true;
-  }
-  if (FD->getIdentifier() == II_ftell) {
-Ftell(C, CE);
-return true;
-  }
-  if (FD->getIdentifier() == II_rewind) {
-Rewind(C, CE);
-return true;
-  }
-  if (FD->getIdentifier() == II_fgetpos) {
-Fgetpos(C, CE);
-return true;
-  }
-  if (FD->getIdentifier() == II_fsetpos) {
-Fsetpos(C, CE);
-return true;
-  }
-  if (FD->getIdentifier() == II_clearerr) {
-Clearerr(C, CE);
-return true;
-  }
-  if (FD->getIdentifier() == II_feof) {
-Feof(C, CE);
-return true;
-  }
-  if (FD->getIdentifier() == II_ferror) {
-Ferror(C, CE);
-return true;
-  }
-  if (FD->getIdentifier() == II_fileno) {
-Fileno(C, CE);
-return true;
+  return (this->*Callback)(Call, C);
+}

Why do you inject `this`?



Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:137
+  return *Callback;
 }
 

I would move this tiny `identifyCall()` into `evalCall()` as the purpose of 
`evalCall()` is the validation of the `Callback` in this case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67706



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


[clang-tools-extra] 80b0cdd - [clangd] Add a hidden tweak to dump symbol under the cursor.

2019-10-29 Thread Haojian Wu via cfe-commits

Author: Haojian Wu
Date: 2019-10-29T13:06:34+01:00
New Revision: 80b0cdde0ffc4ca59e99fed3dcb18412ff97568c

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

LOG: [clangd] Add a hidden tweak to dump symbol under the cursor.

Summary:
This provides a convenient way to see the SymbolID/USR of the symbol, mainly
for debugging purpose.

Reviewers: ilya-biryukov

Subscribers: MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang-tools-extra/clangd/refactor/tweaks/DumpAST.cpp
clang-tools-extra/clangd/unittests/TweakTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/refactor/tweaks/DumpAST.cpp 
b/clang-tools-extra/clangd/refactor/tweaks/DumpAST.cpp
index 9baa8fa4ad6a..ed3725bf7ea1 100644
--- a/clang-tools-extra/clangd/refactor/tweaks/DumpAST.cpp
+++ b/clang-tools-extra/clangd/refactor/tweaks/DumpAST.cpp
@@ -9,6 +9,7 @@
 // Some of these are fairly clang-specific and hidden (e.g. textual AST dumps).
 // Others are more generally useful (class layout) and are exposed by default.
 
//===--===//
+#include "XRefs.h"
 #include "refactor/Tweak.h"
 #include "clang/AST/ASTTypeTraits.h"
 #include "clang/AST/Type.h"
@@ -94,6 +95,32 @@ class ShowSelectionTree : public Tweak {
 };
 REGISTER_TWEAK(ShowSelectionTree)
 
+/// Dumps the symbol under the cursor.
+/// Inputs:
+/// void foo();
+///  ^^^
+/// Message:
+///  foo -
+///  
{"containerName":null,"id":"CA2EBE44A1D76D2A","name":"foo","usr":"c:@F@foo#"}
+class DumpSymbol : public Tweak {
+  const char *id() const override final;
+  bool prepare(const Selection &Inputs) override { return true; }
+  Expected apply(const Selection &Inputs) override {
+std::string Storage;
+llvm::raw_string_ostream Out(Storage);
+
+for (auto &Sym : getSymbolInfo(
+ Inputs.AST,
+ sourceLocToPosition(Inputs.AST.getSourceManager(), 
Inputs.Cursor)))
+  Out << Sym;
+return Effect::showMessage(Out.str());
+  }
+  std::string title() const override { return "Dump symbol under the cursor"; }
+  Intent intent() const override { return Info; }
+  bool hidden() const override { return true; }
+};
+REGISTER_TWEAK(DumpSymbol)
+
 /// Shows the layout of the RecordDecl under the cursor.
 /// Input:
 /// struct X { int foo; };

diff  --git a/clang-tools-extra/clangd/unittests/TweakTests.cpp 
b/clang-tools-extra/clangd/unittests/TweakTests.cpp
index f68dff131d9d..f14383b24081 100644
--- a/clang-tools-extra/clangd/unittests/TweakTests.cpp
+++ b/clang-tools-extra/clangd/unittests/TweakTests.cpp
@@ -133,6 +133,15 @@ TEST_F(DumpASTTest, Test) {
 HasSubstr(" 'int' 2")));
 }
 
+TWEAK_TEST(DumpSymbol);
+TEST_F(DumpSymbolTest, Test) {
+  std::string ID = R"("id":"CA2EBE44A1D76D2A")";
+  std::string USR = R"("usr":"c:@F@foo#")";
+  EXPECT_THAT(apply("void f^oo();"),
+  AllOf(StartsWith("message:"), testing::HasSubstr(ID),
+testing::HasSubstr(USR)));
+}
+
 TWEAK_TEST(ShowSelectionTree);
 TEST_F(ShowSelectionTreeTest, Test) {
   EXPECT_AVAILABLE("^int f^oo() { re^turn 2 ^+ 2; }");



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


[PATCH] D69517: [clangd] Add a hidden tweak to dump symbol under the cursor.

2019-10-29 Thread Haojian Wu via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG80b0cdde0ffc: [clangd] Add a hidden tweak to dump symbol 
under the cursor. (authored by hokein).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69517

Files:
  clang-tools-extra/clangd/refactor/tweaks/DumpAST.cpp
  clang-tools-extra/clangd/unittests/TweakTests.cpp


Index: clang-tools-extra/clangd/unittests/TweakTests.cpp
===
--- clang-tools-extra/clangd/unittests/TweakTests.cpp
+++ clang-tools-extra/clangd/unittests/TweakTests.cpp
@@ -133,6 +133,15 @@
 HasSubstr(" 'int' 2")));
 }
 
+TWEAK_TEST(DumpSymbol);
+TEST_F(DumpSymbolTest, Test) {
+  std::string ID = R"("id":"CA2EBE44A1D76D2A")";
+  std::string USR = R"("usr":"c:@F@foo#")";
+  EXPECT_THAT(apply("void f^oo();"),
+  AllOf(StartsWith("message:"), testing::HasSubstr(ID),
+testing::HasSubstr(USR)));
+}
+
 TWEAK_TEST(ShowSelectionTree);
 TEST_F(ShowSelectionTreeTest, Test) {
   EXPECT_AVAILABLE("^int f^oo() { re^turn 2 ^+ 2; }");
Index: clang-tools-extra/clangd/refactor/tweaks/DumpAST.cpp
===
--- clang-tools-extra/clangd/refactor/tweaks/DumpAST.cpp
+++ clang-tools-extra/clangd/refactor/tweaks/DumpAST.cpp
@@ -9,6 +9,7 @@
 // Some of these are fairly clang-specific and hidden (e.g. textual AST dumps).
 // Others are more generally useful (class layout) and are exposed by default.
 
//===--===//
+#include "XRefs.h"
 #include "refactor/Tweak.h"
 #include "clang/AST/ASTTypeTraits.h"
 #include "clang/AST/Type.h"
@@ -94,6 +95,32 @@
 };
 REGISTER_TWEAK(ShowSelectionTree)
 
+/// Dumps the symbol under the cursor.
+/// Inputs:
+/// void foo();
+///  ^^^
+/// Message:
+///  foo -
+///  
{"containerName":null,"id":"CA2EBE44A1D76D2A","name":"foo","usr":"c:@F@foo#"}
+class DumpSymbol : public Tweak {
+  const char *id() const override final;
+  bool prepare(const Selection &Inputs) override { return true; }
+  Expected apply(const Selection &Inputs) override {
+std::string Storage;
+llvm::raw_string_ostream Out(Storage);
+
+for (auto &Sym : getSymbolInfo(
+ Inputs.AST,
+ sourceLocToPosition(Inputs.AST.getSourceManager(), 
Inputs.Cursor)))
+  Out << Sym;
+return Effect::showMessage(Out.str());
+  }
+  std::string title() const override { return "Dump symbol under the cursor"; }
+  Intent intent() const override { return Info; }
+  bool hidden() const override { return true; }
+};
+REGISTER_TWEAK(DumpSymbol)
+
 /// Shows the layout of the RecordDecl under the cursor.
 /// Input:
 /// struct X { int foo; };


Index: clang-tools-extra/clangd/unittests/TweakTests.cpp
===
--- clang-tools-extra/clangd/unittests/TweakTests.cpp
+++ clang-tools-extra/clangd/unittests/TweakTests.cpp
@@ -133,6 +133,15 @@
 HasSubstr(" 'int' 2")));
 }
 
+TWEAK_TEST(DumpSymbol);
+TEST_F(DumpSymbolTest, Test) {
+  std::string ID = R"("id":"CA2EBE44A1D76D2A")";
+  std::string USR = R"("usr":"c:@F@foo#")";
+  EXPECT_THAT(apply("void f^oo();"),
+  AllOf(StartsWith("message:"), testing::HasSubstr(ID),
+testing::HasSubstr(USR)));
+}
+
 TWEAK_TEST(ShowSelectionTree);
 TEST_F(ShowSelectionTreeTest, Test) {
   EXPECT_AVAILABLE("^int f^oo() { re^turn 2 ^+ 2; }");
Index: clang-tools-extra/clangd/refactor/tweaks/DumpAST.cpp
===
--- clang-tools-extra/clangd/refactor/tweaks/DumpAST.cpp
+++ clang-tools-extra/clangd/refactor/tweaks/DumpAST.cpp
@@ -9,6 +9,7 @@
 // Some of these are fairly clang-specific and hidden (e.g. textual AST dumps).
 // Others are more generally useful (class layout) and are exposed by default.
 //===--===//
+#include "XRefs.h"
 #include "refactor/Tweak.h"
 #include "clang/AST/ASTTypeTraits.h"
 #include "clang/AST/Type.h"
@@ -94,6 +95,32 @@
 };
 REGISTER_TWEAK(ShowSelectionTree)
 
+/// Dumps the symbol under the cursor.
+/// Inputs:
+/// void foo();
+///  ^^^
+/// Message:
+///  foo -
+///  {"containerName":null,"id":"CA2EBE44A1D76D2A","name":"foo","usr":"c:@F@foo#"}
+class DumpSymbol : public Tweak {
+  const char *id() const override final;
+  bool prepare(const Selection &Inputs) override { return true; }
+  Expected apply(const Selection &Inputs) override {
+std::string Storage;
+llvm::raw_string_ostream Out(Storage);
+
+for (auto &Sym : getSymbolInfo(
+ Inputs.AST,
+ sourceLocToPosition(Inputs.AST.getSourceManager(), Inputs.Cursor)))
+  Out << Sym;
+return Effect::showMessage(Out.str());
+  }
+  std::string title() const override {

[PATCH] D69548: Give clang-tidy readability-redundant-string-init a customizable list of string types to fix

2019-10-29 Thread Eugene Zelenko via Phabricator via cfe-commits
Eugene.Zelenko added a comment.

Please mention new option in Release Notes (in new options section, if there is 
no such yet, see previous release for order of sections).




Comment at: 
clang-tools-extra/clang-tidy/readability/RedundantStringInitCheck.h:13
 #include "../ClangTidyCheck.h"
 
+#include 

Please remove empty line.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/readability-redundant-string-init.rst:27
+
+Default is ``basic_string``.
+

Please use single back-ticks for options. Same below.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D69548



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


[PATCH] D69548: Give clang-tidy readability-redundant-string-init a customizable list of string types to fix

2019-10-29 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added a comment.

Thanks you so much for this patch, I obviously like it! So many of us who write 
our own string classes we tend to make them have similar interfaces to 
std::string anyway for obvious reasons (some of us actually add decent 
startWith,endsWith and contains functions!), so I think this is a great 
addition... I'm gonna mention that there are other checks that are pertinent, 
but let us see if this one gets accepted first. You get my LGTM, but let's run 
it by the code owners.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D69548



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


Re: [clang] bd87916 - [clang] Add no_builtin attribute

2019-10-29 Thread Guillaume Chatelet via cfe-commits
hi Vlad,

I've spend a big part of my day digging into this and I'm less and less
convinced that my patch broke the builds.
IIUC the built bots are still failing although my patch has been
reverted for quite some time now.

Am I missing something?

On Mon, Oct 28, 2019 at 11:24 PM Vlad Tsyrklevich 
wrote:

> I've reverted this change as it was causing ASan/MSan failures in
> check-clang, e.g. take a look at the bottom 2 failures here:
> http://lab.llvm.org:8014/builders/sanitizer-x86_64-linux-bootstrap/builds/124/steps/check-clang%20asan/logs/stdio
>  or
> here
> http://lab.llvm.org:8014/builders/sanitizer-x86_64-linux-fast/builds/126/steps/check-clang%20msan/logs/stdio
>
> On Mon, Oct 28, 2019 at 9:30 AM Guillaume Chatelet via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>>
>> Author: Guillaume Chatelet
>> Date: 2019-10-28T17:30:11+01:00
>> New Revision: bd87916109483d33455cbf20da2309197b983cdd
>>
>> URL:
>> https://github.com/llvm/llvm-project/commit/bd87916109483d33455cbf20da2309197b983cdd
>> DIFF:
>> https://github.com/llvm/llvm-project/commit/bd87916109483d33455cbf20da2309197b983cdd.diff
>>
>> LOG: [clang] Add no_builtin attribute
>>
>> Summary:
>> This is a follow up on https://reviews.llvm.org/D61634
>> This patch is simpler and only adds the no_builtin attribute.
>>
>> Reviewers: tejohnson, courbet, theraven, t.p.northover, jdoerfert
>>
>> Subscribers: mgrang, cfe-commits
>>
>> Tags: #clang
>>
>> Differential Revision: https://reviews.llvm.org/D68028
>>
>> Added:
>> clang/test/CodeGen/no-builtin.cpp
>> clang/test/Sema/no-builtin.cpp
>>
>> Modified:
>> clang/include/clang/AST/Decl.h
>> clang/include/clang/Basic/Attr.td
>> clang/include/clang/Basic/AttrDocs.td
>> clang/include/clang/Basic/DiagnosticSemaKinds.td
>> clang/lib/CodeGen/CGCall.cpp
>> clang/lib/Sema/SemaDecl.cpp
>> clang/lib/Sema/SemaDeclAttr.cpp
>> clang/test/Misc/pragma-attribute-supported-attributes-list.test
>>
>> Removed:
>>
>>
>>
>>
>> 
>> diff  --git a/clang/include/clang/AST/Decl.h
>> b/clang/include/clang/AST/Decl.h
>> index b3e7a570fd6d..16094c0988fa 100644
>> --- a/clang/include/clang/AST/Decl.h
>> +++ b/clang/include/clang/AST/Decl.h
>> @@ -2031,6 +2031,10 @@ class FunctionDecl : public DeclaratorDecl,
>>///
>>/// This does not determine whether the function has been defined
>> (e.g., in a
>>/// previous definition); for that information, use isDefined.
>> +  ///
>> +  /// Note: the function declaration does not become a definition until
>> the
>> +  /// parser reaches the definition, if called before, this function
>> will return
>> +  /// `false`.
>>bool isThisDeclarationADefinition() const {
>>  return isDeletedAsWritten() || isDefaulted() || Body ||
>> hasSkippedBody() ||
>> isLateTemplateParsed() || willHaveBody() || hasDefiningAttr();
>>
>> diff  --git a/clang/include/clang/Basic/Attr.td
>> b/clang/include/clang/Basic/Attr.td
>> index 4557a614d361..d5018f444e1c 100644
>> --- a/clang/include/clang/Basic/Attr.td
>> +++ b/clang/include/clang/Basic/Attr.td
>> @@ -3427,3 +3427,10 @@ def ObjCExternallyRetained : InheritableAttr {
>>let Subjects = SubjectList<[NonParmVar, Function, Block, ObjCMethod]>;
>>let Documentation = [ObjCExternallyRetainedDocs];
>>  }
>> +
>> +def NoBuiltin : Attr {
>> +  let Spellings = [Clang<"no_builtin">];
>> +  let Args = [VariadicStringArgument<"BuiltinNames">];
>> +  let Subjects = SubjectList<[Function]>;
>> +  let Documentation = [NoBuiltinDocs];
>> +}
>>
>> diff  --git a/clang/include/clang/Basic/AttrDocs.td
>> b/clang/include/clang/Basic/AttrDocs.td
>> index 6e79d0bb3631..9d0d27407573 100644
>> --- a/clang/include/clang/Basic/AttrDocs.td
>> +++ b/clang/include/clang/Basic/AttrDocs.td
>> @@ -4413,3 +4413,40 @@ and is not a general mechanism for declaring
>> arbitrary aliases for
>>  clang builtin functions.
>>}];
>>  }
>> +
>> +def NoBuiltinDocs : Documentation {
>> +  let Category = DocCatFunction;
>> +  let Content = [{
>> +.. Note:: This attribute is not yet fully implemented, it is validated
>> but has
>> +no effect on the generated code.
>> +
>> +The ``__attribute__((no_builtin))`` is similar to the ``-fno-builtin``
>> flag
>> +except it is specific to the body of a function. The attribute may also
>> be
>> +applied to a virtual function but has no effect on the behavior of
>> overriding
>> +functions in a derived class.
>> +
>> +It accepts one or more strings corresponding to the specific names of the
>> +builtins to disable (e.g. "memcpy", "memset").
>> +If the attribute is used without parameters it will disable all buitins
>> at
>> +once.
>> +
>> +.. code-block:: c++
>> +
>> +  // The compiler is not allowed to add any builtin to foo's body.
>> +  void foo(char* data, size_t count) __attribute__((no_builtin)) {
>> +// The compiler is not allowed to convert the loop into
>> +// `__builtin_memset(data, 0xFE, co

Re: [clang] bd87916 - [clang] Add no_builtin attribute

2019-10-29 Thread Guillaume Chatelet via cfe-commits
For instance here are the kind of errors I have by running a sanitized
clang on master (with or without my patch it doesn't make a difference)

cd /redacted/git/llvm-project/llvm/build-msan &&
> /redacted/git/llvm-project/llvm/build-msan/bin/llvm-tblgen
> -gen-opt-parser-defs -I /redacted/git/llvm-project/llvm/tools/llvm-lipo -I
> /redacted/git/llvm-project/llvm/include
> /redacted/git/llvm-project/llvm/tools/llvm-lipo/LipoOpts.td
> --write-if-changed -o tools/llvm-lipo/LipoOpts.inc -d
> tools/llvm-lipo/LipoOpts.inc.d
> ==127351==WARNING: MemorySanitizer: use-of-uninitialized-value
> #0 0x1015ae9 in
> llvm::StringRef::split(llvm::SmallVectorImpl&, char, int,
> bool) const
> /redacted/git/llvm-project/llvm/build-msan/../lib/Support/StringRef.cpp:348:3
> #1 0x102e1d5 in llvm::Triple::Triple(llvm::Twine const&)
> /redacted/git/llvm-project/llvm/build-msan/../lib/Support/Triple.cpp:731:19
> #2 0x107dd7d in llvm::sys::getProcessTriple()
> /redacted/git/llvm-project/llvm/build-msan/../lib/Support/Host.cpp:1532:10
> #3 0xf873d7 in ParseCommandLineOptions
> /redacted/git/llvm-project/llvm/build-msan/../lib/Support/CommandLine.cpp:1267:17
> #4 0xf873d7 in llvm::cl::ParseCommandLineOptions(int, char const*
> const*, llvm::StringRef, llvm::raw_ostream*, char const*, bool)
> /redacted/git/llvm-project/llvm/build-msan/../lib/Support/CommandLine.cpp:1242:24
> #5 0xef2ea7 in main
> /redacted/git/llvm-project/llvm/build-msan/../utils/TableGen/TableGen.cpp:267:3
> #6 0x7f6202abf52a in __libc_start_main
> (/lib/x86_64-linux-gnu/libc.so.6+0x2352a)
> #7 0x42d4a9 in _start
> (/redacted/git/llvm-project/llvm/build-msan/bin/llvm-tblgen+0x42d4a9)
>   Uninitialized value was stored to memory at
> #0 0x102ecc6 in StringRef
> /redacted/git/llvm-project/llvm/build-msan/../include/llvm/ADT/StringRef.h:111:27
> #1 0x102ecc6 in llvm::Triple::Triple(llvm::Twine const&)
> /redacted/git/llvm-project/llvm/build-msan/../lib/Support/Triple.cpp:731:3
> #2 0x107dd7d in llvm::sys::getProcessTriple()
> /redacted/git/llvm-project/llvm/build-msan/../lib/Support/Host.cpp:1532:10
> #3 0xf873d7 in ParseCommandLineOptions
> /redacted/git/llvm-project/llvm/build-msan/../lib/Support/CommandLine.cpp:1267:17
> #4 0xf873d7 in llvm::cl::ParseCommandLineOptions(int, char const*
> const*, llvm::StringRef, llvm::raw_ostream*, char const*, bool)
> /redacted/git/llvm-project/llvm/build-msan/../lib/Support/CommandLine.cpp:1242:24
> #5 0xef2ea7 in main
> /redacted/git/llvm-project/llvm/build-msan/../utils/TableGen/TableGen.cpp:267:3
> #6 0x7f6202abf52a in __libc_start_main
> (/lib/x86_64-linux-gnu/libc.so.6+0x2352a)
>   Uninitialized value was created by an allocation of 'PT' in the stack
> frame of function '_ZN4llvm3sys16getProcessTripleEv'
> #0 0x107d9a0 in llvm::sys::getProcessTriple()
> /redacted/git/llvm-project/llvm/build-msan/../lib/Support/Host.cpp:1530
>

On Tue, Oct 29, 2019 at 1:32 PM Guillaume Chatelet 
wrote:

> hi Vlad,
>
> I've spend a big part of my day digging into this and I'm less and less
> convinced that my patch broke the builds.
> IIUC the built bots are still failing although my patch has been
> reverted for quite some time now.
>
> Am I missing something?
>
> On Mon, Oct 28, 2019 at 11:24 PM Vlad Tsyrklevich 
> wrote:
>
>> I've reverted this change as it was causing ASan/MSan failures in
>> check-clang, e.g. take a look at the bottom 2 failures here:
>> http://lab.llvm.org:8014/builders/sanitizer-x86_64-linux-bootstrap/builds/124/steps/check-clang%20asan/logs/stdio
>>  or
>> here
>> http://lab.llvm.org:8014/builders/sanitizer-x86_64-linux-fast/builds/126/steps/check-clang%20msan/logs/stdio
>>
>> On Mon, Oct 28, 2019 at 9:30 AM Guillaume Chatelet via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>>
>>> Author: Guillaume Chatelet
>>> Date: 2019-10-28T17:30:11+01:00
>>> New Revision: bd87916109483d33455cbf20da2309197b983cdd
>>>
>>> URL:
>>> https://github.com/llvm/llvm-project/commit/bd87916109483d33455cbf20da2309197b983cdd
>>> DIFF:
>>> https://github.com/llvm/llvm-project/commit/bd87916109483d33455cbf20da2309197b983cdd.diff
>>>
>>> LOG: [clang] Add no_builtin attribute
>>>
>>> Summary:
>>> This is a follow up on https://reviews.llvm.org/D61634
>>> This patch is simpler and only adds the no_builtin attribute.
>>>
>>> Reviewers: tejohnson, courbet, theraven, t.p.northover, jdoerfert
>>>
>>> Subscribers: mgrang, cfe-commits
>>>
>>> Tags: #clang
>>>
>>> Differential Revision: https://reviews.llvm.org/D68028
>>>
>>> Added:
>>> clang/test/CodeGen/no-builtin.cpp
>>> clang/test/Sema/no-builtin.cpp
>>>
>>> Modified:
>>> clang/include/clang/AST/Decl.h
>>> clang/include/clang/Basic/Attr.td
>>> clang/include/clang/Basic/AttrDocs.td
>>> clang/include/clang/Basic/DiagnosticSemaKinds.td
>>> clang/lib/CodeGen/CGCall.cpp
>>> clang/lib/Sema/SemaDecl.cpp
>>> clang/lib/Sema/SemaDeclAttr.cpp
>>> clang/test/Misc/pragma-attribute-supported-attributes-

[PATCH] D69322: [hip][cuda] Enable extended lambda support on Windows.

2019-10-29 Thread Michael Liao via Phabricator via cfe-commits
hliao added a comment.

PING for review


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69322



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


[PATCH] D69560: [clang-tidy] Add 'cppcoreguidelines-avoid-adjacent-arguments-of-same-type' check

2019-10-29 Thread Whisperity via Phabricator via cfe-commits
whisperity created this revision.
whisperity added reviewers: aaron.ballman, alexfh, Eugene.Zelenko, JonasToth, 
NoQ, Szelethus, xazax.hun, baloghadamsoftware, Charusso.
whisperity added a project: clang-tools-extra.
Herald added subscribers: cfe-commits, ormris, kbarton, mgorny, nemanjai.
Herald added a project: clang.

This check finds function definitions where arguments of the same type follow 
each other directly, making call sites prone to calling the function with 
swapped or badly ordered arguments.

The relevant C++ Core Guidelines rules to which conformity is checked is found 
at: 
http://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#i24-avoid-adjacent-unrelated-parameters-of-the-same-type


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D69560

Files:
  
clang-tools-extra/clang-tidy/cppcoreguidelines/AdjacentArgumentsOfSameTypeCheck.cpp
  
clang-tools-extra/clang-tidy/cppcoreguidelines/AdjacentArgumentsOfSameTypeCheck.h
  clang-tools-extra/clang-tidy/cppcoreguidelines/CMakeLists.txt
  clang-tools-extra/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-avoid-adjacent-arguments-of-same-type.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/test/clang-tidy/cppcoreguidelines-avoid-adjacent-arguments-of-same-type-cvr-on.cpp
  
clang-tools-extra/test/clang-tidy/cppcoreguidelines-avoid-adjacent-arguments-of-same-type-default.cpp
  
clang-tools-extra/test/clang-tidy/cppcoreguidelines-avoid-adjacent-arguments-of-same-type-verbose.cpp

Index: clang-tools-extra/test/clang-tidy/cppcoreguidelines-avoid-adjacent-arguments-of-same-type-verbose.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/cppcoreguidelines-avoid-adjacent-arguments-of-same-type-verbose.cpp
@@ -0,0 +1,420 @@
+// RUN: %check_clang_tidy %s \
+// RUN:   cppcoreguidelines-avoid-adjacent-arguments-of-same-type %t \
+// RUN:   -config='{CheckOptions: [ \
+// RUN: {key: cppcoreguidelines-avoid-adjacent-arguments-of-same-type.MinimumLength, value: 2}, \
+// RUN: {key: cppcoreguidelines-avoid-adjacent-arguments-of-same-type.CVRMixPossible, value: 1} \
+// RUN:   ]}' --
+
+void library(void *vp, void *vp2, void *vp3, int n, int m);
+// NO-WARN: The user has no chance to change only declared (usually library)
+// functions, so no diagnostic is made.
+
+struct T {};
+
+void create(T **out_t) {} // NO-WARN
+
+void copy(T *p, T *q, int n) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:11: warning: 2 adjacent arguments for 'copy' of similar type ('T *') are easily swapped by mistake [cppcoreguidelines-avoid-adjacent-arguments-of-same-type]
+// CHECK-MESSAGES: :[[@LINE-2]]:20: note: last argument in the adjacent range here
+
+void mov(T *dst, const T *src) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: 2 adjacent arguments for 'mov' of similar type are
+// CHECK-MESSAGES: :[[@LINE-2]]:27: note: last argument in the adjacent range here
+// CHECK-MESSAGES: :[[@LINE-3]]:18: note: at a call site, 'const T *' might bind with same force as 'T *'
+
+void compare01(T t1, T t2) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:16: warning: 2 adjacent arguments for 'compare01' of similar type ('T') are
+// CHECK-MESSAGES: :[[@LINE-2]]:24: note: last argument in the adjacent range
+
+void compare02(const T t1, T t2) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:16: warning: 2 adjacent arguments for 'compare02' of similar type are
+// CHECK-MESSAGES: :[[@LINE-2]]:30: note: last argument in the adjacent range
+// CHECK-MESSAGES: :[[@LINE-3]]:28: note: at a call site, 'T' might bind with same force as 'const T'
+
+void compare03(T t1, const T t2) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:16: warning: 2 adjacent arguments for 'compare03' of similar type are
+// CHECK-MESSAGES: :[[@LINE-2]]:30: note: last argument in the adjacent range
+// CHECK-MESSAGES: :[[@LINE-3]]:22: note: at a call site, 'const T' might bind with same force as 'T'
+
+void compare04(const T &t1, T t2) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:16: warning: 2 adjacent arguments for 'compare04' of similar type are
+// CHECK-MESSAGES: :[[@LINE-2]]:31: note: last argument in the adjacent range
+// CHECK-MESSAGES: :[[@LINE-3]]:29: note: at a call site, 'T' might bind with same force as 'const T &'
+
+void compare05(T t1, const T &t2) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:16: warning: 2 adjacent arguments for 'compare05' of similar type are
+// CHECK-MESSAGES: :[[@LINE-2]]:31: note: last argument in the adjacent range
+// CHECK-MESSAGES: :[[@LINE-3]]:22: note: at a call site, 'const T &' might bind with same force as 'T'
+
+void compare06(const T &t1, const T &t2) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:16: warning: 2 adjacent arguments for 'compare06' of similar type ('const T &') are
+// CHECK-MESSAGES: :[[@LINE-2]]:38: note: last argument in the adjacent range
+
+void compare07(const T &t1, const

[PATCH] D69560: [clang-tidy] Add 'cppcoreguidelines-avoid-adjacent-arguments-of-same-type' check

2019-10-29 Thread Whisperity via Phabricator via cfe-commits
whisperity added a comment.
Herald added a subscriber: wuzish.

A few interesting "true positive" findings:

- F10568770: 
AnalysisDeclContext.cpp_9aaed563ddd9ebd73fdd228c2883b8e7.plist.html 
 (Such cases with many `bool`s are being 
discussed on enhancing type safety and type strength 

- F10568771: bitcoingui.cpp_27769deaa63c894e4fc430d7122c368d.plist.html 

- F10568773: CheckerRegistry.cpp_d0d988840a154a07670cc410e23a7c8e.plist.html 

- F10568775: text_format.cc_f34502df2725b30018c086b6767cbd26.plist.html 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69560



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


[PATCH] D69378: [AArch64][SVE] Implement masked store intrinsics

2019-10-29 Thread Kerry McLaughlin via Phabricator via cfe-commits
kmclaughlin updated this revision to Diff 226885.
kmclaughlin added a comment.

- Removed masked load tests from sve-masked-ldst-trunc.ll


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

https://reviews.llvm.org/D69378

Files:
  llvm/lib/Target/AArch64/AArch64InstrInfo.td
  llvm/lib/Target/AArch64/AArch64SVEInstrInfo.td
  llvm/lib/Target/AArch64/AArch64TargetTransformInfo.h
  llvm/test/CodeGen/AArch64/sve-masked-ldst-nonext.ll
  llvm/test/CodeGen/AArch64/sve-masked-ldst-trunc.ll

Index: llvm/test/CodeGen/AArch64/sve-masked-ldst-trunc.ll
===
--- /dev/null
+++ llvm/test/CodeGen/AArch64/sve-masked-ldst-trunc.ll
@@ -0,0 +1,60 @@
+; RUN: llc -mtriple=aarch64--linux-gnu -mattr=+sve < %s | FileCheck %s
+
+;
+; Masked Stores
+;
+
+define void @masked_trunc_store_nxv2i8( *%a,  %val,  *%b,  %mask) {
+; CHECK-LABEL: masked_trunc_store_nxv2i8:
+; CHECK: st1b { [[IN:z[0-9]]].d }, [[PG:p[0-9]]], [x1]
+  %trunc = trunc  %val to 
+  call void @llvm.masked.store.nxv2i8( %trunc,  *%b, i32 8,  %mask)
+  ret void
+}
+
+define void @masked_trunc_store_nxv2i16( *%a,  %val,  *%b,  %mask) {
+; CHECK-LABEL: masked_trunc_store_nxv2i16:
+; CHECK: st1h { [[IN:z[0-9]]].d }, [[PG:p[0-9]]], [x1]
+  %trunc = trunc  %val to 
+  call void @llvm.masked.store.nxv2i16( %trunc,  *%b, i32 8,  %mask)
+  ret void
+}
+
+define void @masked_trunc_store_nxv2i32( *%a,  %val,  *%b,  %mask) {
+; CHECK-LABEL: masked_trunc_store_nxv2i32:
+; CHECK: st1w { [[IN:z[0-9]]].d }, [[PG:p[0-9]]], [x1]
+  %trunc = trunc  %val to 
+  call void @llvm.masked.store.nxv2i32( %trunc,  *%b, i32 8,  %mask)
+  ret void
+}
+
+define void @masked_trunc_store_nxv4i8( *%a,  %val,  *%b,  %mask) {
+; CHECK-LABEL: masked_trunc_store_nxv4i8:
+; CHECK: st1b { [[IN:z[0-9]]].s }, [[PG:p[0-9]]], [x1]
+  %trunc = trunc  %val to 
+  call void @llvm.masked.store.nxv4i8( %trunc,  *%b, i32 4,  %mask)
+  ret void
+}
+
+define void @masked_trunc_store_nxv4i16( *%a,  %val,  *%b,  %mask) {
+; CHECK-LABEL: masked_trunc_store_nxv4i16:
+; CHECK: st1h { [[IN:z[0-9]]].s }, [[PG:p[0-9]]], [x1]
+  %trunc = trunc  %val to 
+  call void @llvm.masked.store.nxv4i16( %trunc,  *%b, i32 4,  %mask)
+  ret void
+}
+
+define void @masked_trunc_store_nxv8i8( *%a,  %val,  *%b,  %mask) {
+; CHECK-LABEL: masked_trunc_store_nxv8i8:
+; CHECK: st1b { [[IN:z[0-9]]].h }, [[PG:p[0-9]]], [x1]
+  %trunc = trunc  %val to 
+  call void @llvm.masked.store.nxv8i8( %trunc,  *%b, i32 2,  %mask)
+  ret void
+}
+
+declare void @llvm.masked.store.nxv2i8(, *, i32, )
+declare void @llvm.masked.store.nxv2i16(, *, i32, )
+declare void @llvm.masked.store.nxv2i32(, *, i32, )
+declare void @llvm.masked.store.nxv4i8(, *, i32, )
+declare void @llvm.masked.store.nxv4i16(, *, i32, )
+declare void @llvm.masked.store.nxv8i8(, *, i32, )
Index: llvm/test/CodeGen/AArch64/sve-masked-ldst-nonext.ll
===
--- llvm/test/CodeGen/AArch64/sve-masked-ldst-nonext.ll
+++ llvm/test/CodeGen/AArch64/sve-masked-ldst-nonext.ll
@@ -74,6 +74,80 @@
   ret  %load
 }
 
+;
+; Masked Stores
+;
+
+define void @masked_store_nxv2i64( *%a,  %val,  %mask) {
+; CHECK-LABEL: masked_store_nxv2i64:
+; CHECK: st1d { [[IN]].d }, [[PG]], [x0]
+  call void @llvm.masked.store.nxv2i64( %val,  *%a, i32 8,  %mask)
+  ret void
+}
+
+define void @masked_store_nxv4i32( *%a,  %val,  %mask) {
+; CHECK-LABEL: masked_store_nxv4i32:
+; CHECK: st1w { [[IN]].s }, [[PG]], [x0]
+  call void @llvm.masked.store.nxv4i32( %val,  *%a, i32 4,  %mask)
+  ret void
+}
+
+define void @masked_store_nxv8i16( *%a,  %val,  %mask) {
+; CHECK-LABEL: masked_store_nxv8i16:
+; CHECK: st1h { [[IN]].h }, [[PG]], [x0]
+  call void @llvm.masked.store.nxv8i16( %val,  *%a, i32 2,  %mask)
+  ret void
+}
+
+define void @masked_store_nxv16i8( *%a,  %val,  %mask) {
+; CHECK-LABEL: masked_store_nxv16i8:
+; CHECK: st1b { [[IN]].b }, [[PG]], [x0]
+  call void @llvm.masked.store.nxv16i8( %val,  *%a, i32 1,  %mask)
+  ret void
+}
+
+define void @masked_store_nxv2f64( *%a,  %val,  %mask) {
+; CHECK-LABEL: masked_store_nxv2f64:
+; CHECK: st1d { [[IN]].d }, [[PG]], [x0]
+  call void @llvm.masked.store.nxv2f64( %val,  *%a, i32 8,  %mask)
+  ret void
+}
+
+define void @masked_store_nxv2f32( *%a,  %val,  %mask) {
+; CHECK-LABEL: masked_store_nxv2f32:
+; CHECK: st1w { [[IN]].d }, [[PG]], [x0]
+  call void @llvm.masked.store.nxv2f32( %val,  *%a, i32 4,  %mask)
+  ret void
+}
+
+define void @masked_store_nxv2f16( *%a,  %val,  %mask) {
+; CHECK-LABEL: masked_store_nxv2f16:
+; CHECK: st1h { [[IN]].d }, [[PG]], [x0]
+  call void @llvm.masked.store.nxv2f16( %val,  *%a, i32 4,  %mask)
+  ret void
+}
+
+define void @masked_store_nxv4f32( *%a,  %val,  %mask) {
+; CHECK-LABEL: masked_store_nxv4f32:
+; CHECK: st1w { [[IN]].s }, [[PG]], [x0]
+  call void @llvm.masked.store.nxv4f32( %val,  *%a, i32 4,  %mask)
+  ret void
+}
+
+define void @masked_store_nxv4f16( *%a,  %val,  %mask) {
+; CHECK-LABEL: masked_s

[PATCH] D69378: [AArch64][SVE] Implement masked store intrinsics

2019-10-29 Thread Sander de Smalen via Phabricator via cfe-commits
sdesmalen added a comment.

Thanks for the changes to the tests.




Comment at: llvm/test/CodeGen/AArch64/sve-masked-ldst-trunc.ll:9
+; CHECK-LABEL: masked_trunc_store_nxv2i8:
+; CHECK: st1b { [[IN:z[0-9]]].d }, [[PG:p[0-9]]], [x1]
+  %trunc = trunc  %val to 

I think it may be worth testing for z1.d explicitly and use CHECK-NEXT to make 
sure there are no other instructions that could do the truncation.


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

https://reviews.llvm.org/D69378



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


[clang] 99f5196 - [Hexagon] Handle remaining registers in getRegisterByName()

2019-10-29 Thread Krzysztof Parzyszek via cfe-commits

Author: Krzysztof Parzyszek
Date: 2019-10-29T08:56:01-05:00
New Revision: 99f51960fdb5559d6720281bff9a63041452bf9a

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

LOG: [Hexagon] Handle remaining registers in getRegisterByName()

This fixes https://llvm.org/PR43829.

Added: 
llvm/test/CodeGen/Hexagon/reg-by-name.ll

Modified: 
clang/lib/Basic/Targets/Hexagon.cpp
llvm/lib/Target/Hexagon/HexagonISelLowering.cpp

Removed: 




diff  --git a/clang/lib/Basic/Targets/Hexagon.cpp 
b/clang/lib/Basic/Targets/Hexagon.cpp
index be23fd2536e0..fcb94b93d69d 100644
--- a/clang/lib/Basic/Targets/Hexagon.cpp
+++ b/clang/lib/Basic/Targets/Hexagon.cpp
@@ -100,7 +100,10 @@ const char *const HexagonTargetInfo::GCCRegNames[] = {
 "r9",  "r10", "r11", "r12", "r13", "r14", "r15", "r16", "r17",
 "r18", "r19", "r20", "r21", "r22", "r23", "r24", "r25", "r26",
 "r27", "r28", "r29", "r30", "r31", "p0",  "p1",  "p2",  "p3",
-"sa0", "lc0", "sa1", "lc1", "m0",  "m1",  "usr", "ugp"
+"sa0", "lc0", "sa1", "lc1", "m0",  "m1",  "usr", "ugp",
+"r1:0", "r3:2", "r5:4", "r7:6", "r9:8", "r11:10", "r13:12", "r15:14",
+"r17:16", "r19:18", "r21:20", "r23:22", "r25:24", "r27:26", "r29:28",
+"r31:30"
 };
 
 ArrayRef HexagonTargetInfo::getGCCRegNames() const {

diff  --git a/llvm/lib/Target/Hexagon/HexagonISelLowering.cpp 
b/llvm/lib/Target/Hexagon/HexagonISelLowering.cpp
index 8a8986e232a0..09f5fd82cade 100644
--- a/llvm/lib/Target/Hexagon/HexagonISelLowering.cpp
+++ b/llvm/lib/Target/Hexagon/HexagonISelLowering.cpp
@@ -240,11 +240,73 @@ bool HexagonTargetLowering::mayBeEmittedAsTailCall(const 
CallInst *CI) const {
   return true;
 }
 
-Register HexagonTargetLowering::getRegisterByName(const char* RegName, EVT VT,
-  const MachineFunction &) 
const {
+Register HexagonTargetLowering::getRegisterByName(
+  const char* RegName, EVT VT, const MachineFunction &) const {
   // Just support r19, the linux kernel uses it.
   Register Reg = StringSwitch(RegName)
+ .Case("r0", Hexagon::R0)
+ .Case("r1", Hexagon::R1)
+ .Case("r2", Hexagon::R2)
+ .Case("r3", Hexagon::R3)
+ .Case("r4", Hexagon::R4)
+ .Case("r5", Hexagon::R5)
+ .Case("r6", Hexagon::R6)
+ .Case("r7", Hexagon::R7)
+ .Case("r8", Hexagon::R8)
+ .Case("r9", Hexagon::R9)
+ .Case("r10", Hexagon::R10)
+ .Case("r11", Hexagon::R11)
+ .Case("r12", Hexagon::R12)
+ .Case("r13", Hexagon::R13)
+ .Case("r14", Hexagon::R14)
+ .Case("r15", Hexagon::R15)
+ .Case("r16", Hexagon::R16)
+ .Case("r17", Hexagon::R17)
+ .Case("r18", Hexagon::R18)
  .Case("r19", Hexagon::R19)
+ .Case("r20", Hexagon::R20)
+ .Case("r21", Hexagon::R21)
+ .Case("r22", Hexagon::R22)
+ .Case("r23", Hexagon::R23)
+ .Case("r24", Hexagon::R24)
+ .Case("r25", Hexagon::R25)
+ .Case("r26", Hexagon::R26)
+ .Case("r27", Hexagon::R27)
+ .Case("r28", Hexagon::R28)
+ .Case("r29", Hexagon::R29)
+ .Case("r30", Hexagon::R30)
+ .Case("r31", Hexagon::R31)
+ .Case("r1:0", Hexagon::D0)
+ .Case("r3:2", Hexagon::D1)
+ .Case("r5:4", Hexagon::D2)
+ .Case("r7:6", Hexagon::D3)
+ .Case("r9:8", Hexagon::D4)
+ .Case("r11:10", Hexagon::D5)
+ .Case("r13:12", Hexagon::D6)
+ .Case("r15:14", Hexagon::D7)
+ .Case("r17:16", Hexagon::D8)
+ .Case("r19:18", Hexagon::D9)
+ .Case("r21:20", Hexagon::D10)
+ .Case("r23:22", Hexagon::D11)
+ .Case("r25:24", Hexagon::D12)
+ .Case("r27:26", Hexagon::D13)
+ .Case("r29:28", Hexagon::D14)
+ .Case("r31:30", Hexagon::D15)
+ .Case("sp", Hexagon::R29)
+ .Case("fp", Hexagon::R30)
+ .Case("lr", Hexagon::R31)
+ .Case("p0", Hexagon::P0)
+ .Case("p1", Hexagon::P1)
+ .Case("p2", Hexagon::P2)
+ .Case("p3", Hexagon::P3)
+ .Case("sa0", Hexagon:

[PATCH] D67983: [ObjC] Diagnose implicit type coercion from ObjC 'Class' to object pointer types.

2019-10-29 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

Just doing nothing is fine with me.

I'll note that this change required several changes in our Obj-C++ codebase, 
and we don't have all that much Obj-C++ code in Chromium. Most of the changes 
made the code better, but I'd imagine that folks with more Obj-C++ code might 
need some amount of time to adopt their code. (Our changes: 
https://chromium-review.googlesource.com/c/chromium/src/+/1878075 
https://chromium-review.googlesource.com/c/chromium/src/+/1884671 )


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67983



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


[PATCH] D69560: [clang-tidy] Add 'cppcoreguidelines-avoid-adjacent-arguments-of-same-type' check

2019-10-29 Thread Eugene Zelenko via Phabricator via cfe-commits
Eugene.Zelenko added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/cppcoreguidelines/AdjacentArgumentsOfSameTypeCheck.cpp:1
+//===--- AvoidAdjacentArgumentsOfSameTypeCheck.cpp - clang-tidy 
===//
+//

Please adjust length to 80 characters.



Comment at: 
clang-tools-extra/clang-tidy/cppcoreguidelines/AdjacentArgumentsOfSameTypeCheck.cpp:9
+
+#include 
+#include 

Please C++ headers aster LLVM ones.



Comment at: 
clang-tools-extra/clang-tidy/cppcoreguidelines/AdjacentArgumentsOfSameTypeCheck.cpp:35
+/// This method attempts to discard everything as much as possible.
+const Type *stripType(const Type *T);
+

Functions should be static. Anonymous namespace only for types definitions.



Comment at: 
clang-tools-extra/clang-tidy/cppcoreguidelines/AdjacentArgumentsOfSameTypeCheck.cpp:488
+void AdjacentArgumentsOfSameTypeCheck::registerMatchers(MatchFinder *Finder) {
+  if (!getLangOpts().CPlusPlus)
+return;

Check seems to be useful for C and probably for Objective-C.



Comment at: clang-tools-extra/docs/ReleaseNotes.rst:94
+
+  This check finds function definitions where arguments of the same type follow
+  each other directly, making call sites prone to calling the function with

Please remove //This check//.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-avoid-adjacent-arguments-of-same-type.rst:6
+
+This check finds function definitions where arguments of the same type follow
+each other directly, making call sites prone to calling the function with

Please remove //This check//.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-avoid-adjacent-arguments-of-same-type.rst:56
+diagnostic is emitted.
+Defaults to ``3`` for sake of user-friendliness.
+Can be any (positive integer) number.

Please use single back-tick for option values.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-avoid-adjacent-arguments-of-same-type.rst:65
+sequence.
+If ``0`` (default value), the check assumes such arguments cannot be mixed
+up at a potential call site.

Please use single back-tick for option values.



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-avoid-adjacent-arguments-of-same-type.rst:125
+const typename vector::element_type & LeftBegin) { /* ... 
*/ }
\ No newline at end of file


Please add new line.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69560



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


[PATCH] D67216: [cfi] Add flag to always generate .debug_frame

2019-10-29 Thread Oliver Stannard (Linaro) via Phabricator via cfe-commits
ostannard accepted this revision.
ostannard added a comment.
This revision is now accepted and ready to land.

LGTM


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

https://reviews.llvm.org/D67216



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


[PATCH] D69433: [clang-format] [NFC] update the documentation in Format.h to allow dump_format_style.py to get a little closer to being correct. (part 2)

2019-10-29 Thread Mitchell via Phabricator via cfe-commits
mitchell-stellar added a comment.

Sounds like you know what you're doing.

LGTM


Repository:
  rC Clang

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

https://reviews.llvm.org/D69433



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


[clang] c09c065 - [OPENMP]Fix PR43772: No warning in non-combined target regions.

2019-10-29 Thread Alexey Bataev via cfe-commits

Author: Alexey Bataev
Date: 2019-10-29T10:31:24-04:00
New Revision: c09c0651a43b75044dc99e7c69acbcfaffd08aa2

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

LOG: [OPENMP]Fix PR43772: No warning in non-combined target regions.

Need to analyze inner target regions in case of implicit mapping of the
data members when target region is created in one of the class member
functions.

Added: 


Modified: 
clang/lib/Sema/SemaOpenMP.cpp
clang/test/OpenMP/distribute_simd_loop_messages.cpp
clang/test/OpenMP/teams_distribute_codegen.cpp
clang/test/OpenMP/teams_distribute_parallel_for_codegen.cpp
clang/test/OpenMP/teams_distribute_simd_codegen.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaOpenMP.cpp b/clang/lib/Sema/SemaOpenMP.cpp
index 8b1fca89dee8..b3b8fd655f14 100644
--- a/clang/lib/Sema/SemaOpenMP.cpp
+++ b/clang/lib/Sema/SemaOpenMP.cpp
@@ -2768,6 +2768,7 @@ class DSAAttrChecker final : public 
StmtVisitor {
   DSAStackTy *Stack;
   Sema &SemaRef;
   bool ErrorFound = false;
+  bool TryCaptureCXXThisMembers = false;
   CapturedStmt *CS = nullptr;
   llvm::SmallVector ImplicitFirstprivate;
   llvm::SmallVector ImplicitMap;
@@ -2779,12 +2780,26 @@ class DSAAttrChecker final : public 
StmtVisitor {
 if (!S->hasAssociatedStmt() || !S->getAssociatedStmt())
   return;
 visitSubCaptures(S->getInnermostCapturedStmt());
+// Try to capture inner this->member references to generate correct 
mappings
+// and diagnostics.
+if (TryCaptureCXXThisMembers ||
+(isOpenMPTargetExecutionDirective(Stack->getCurrentDirective()) &&
+ llvm::any_of(S->getInnermostCapturedStmt()->captures(),
+  [](const CapturedStmt::Capture &C) {
+return C.capturesThis();
+  }))) {
+  bool SavedTryCaptureCXXThisMembers = TryCaptureCXXThisMembers;
+  TryCaptureCXXThisMembers = true;
+  Visit(S->getInnermostCapturedStmt()->getCapturedStmt());
+  TryCaptureCXXThisMembers = SavedTryCaptureCXXThisMembers;
+}
   }
 
 public:
   void VisitDeclRefExpr(DeclRefExpr *E) {
-if (E->isTypeDependent() || E->isValueDependent() ||
-E->containsUnexpandedParameterPack() || E->isInstantiationDependent())
+if (TryCaptureCXXThisMembers || E->isTypeDependent() ||
+E->isValueDependent() || E->containsUnexpandedParameterPack() ||
+E->isInstantiationDependent())
   return;
 if (auto *VD = dyn_cast(E->getDecl())) {
   // Check the datasharing rules for the expressions in the clauses.
@@ -3018,7 +3033,7 @@ class DSAAttrChecker final : public 
StmtVisitor {
   })) {
 Visit(E->getBase());
   }
-} else {
+} else if (!TryCaptureCXXThisMembers) {
   Visit(E->getBase());
 }
   }

diff  --git a/clang/test/OpenMP/distribute_simd_loop_messages.cpp 
b/clang/test/OpenMP/distribute_simd_loop_messages.cpp
index 423e5f1b1166..183fdfd90cfb 100644
--- a/clang/test/OpenMP/distribute_simd_loop_messages.cpp
+++ b/clang/test/OpenMP/distribute_simd_loop_messages.cpp
@@ -4,6 +4,22 @@
 // RUN: %clang_cc1 -fsyntax-only -fopenmp-simd -x c++ -std=c++11 -fexceptions 
-fcxx-exceptions -verify=expected,omp4 %s -Wuninitialized
 // RUN: %clang_cc1 -fsyntax-only -fopenmp-simd -fopenmp-version=50 -x c++ 
-std=c++11 -fexceptions -fcxx-exceptions -verify=expected,omp5 %s 
-Wuninitialized
 
+class S5 {
+  int a;
+  S5() : a(0) {}
+
+public:
+  S5(int v) : a(v) {}
+  S5 &operator=(S5 &s) {
+#pragma omp target
+#pragma omp teams
+#pragma omp distribute simd
+for (int k = 0; k < s.a; ++k) // expected-warning {{Non-trivial type 'S5' 
is mapped, only trivial types are guaranteed to be mapped correctly}}
+  ++s.a;
+return *this;
+  }
+};
+
 static int sii;
 // expected-note@+1 {{defined as threadprivate or thread local}}
 #pragma omp threadprivate(sii)

diff  --git a/clang/test/OpenMP/teams_distribute_codegen.cpp 
b/clang/test/OpenMP/teams_distribute_codegen.cpp
index 0065c6cbd51c..151fa2da49f9 100644
--- a/clang/test/OpenMP/teams_distribute_codegen.cpp
+++ b/clang/test/OpenMP/teams_distribute_codegen.cpp
@@ -158,7 +158,7 @@ struct SS{
   // CK3: define {{.*}}i32 @{{.+}}foo{{.+}}(
   int foo(void) {
 
-  // CK3: call i32 @__tgt_target_teams(i64 -1, i8* @{{[^,]+}}, i32 1, i8** 
%{{[^,]+}}, i8** %{{[^,]+}}, i{{64|32}}* {{.+}}@{{[^,]+}}, i32 0, i32 0), i64* 
{{.+}}@{{[^,]+}}, i32 0, i32 0), i32 0, i32 0)
+  // CK3: call i32 @__tgt_target_teams(i64 -1, i8* @{{[^,]+}}, i32 2, i8** 
%{{[^,]+}}, i8** %{{[^,]+}}, i{{64|32}}* %{{.+}}, i64* {{.+}}@{{[^,]+}}, i32 0, 
i32 0), i32 0, i32 0)
   // CK3: call void @[[OFFL1:.+]]([[SSI]]* %{{.+}})
 #pragma omp target
 #pragma omp teams distribute
@@ -174,7 +174,7 @@ struct SS{
   // CK3: define internal void @[[OUTL1]

[clang] 98f3151 - [clang] Add no_builtin attribute

2019-10-29 Thread Guillaume Chatelet via cfe-commits

Author: Guillaume Chatelet
Date: 2019-10-29T15:50:29+01:00
New Revision: 98f3151a7dded8838fafcb5f46e6c8358def96b8

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

LOG: [clang] Add no_builtin attribute

Summary:
This is a follow up on https://reviews.llvm.org/D61634
This patch is simpler and only adds the no_builtin attribute.

Reviewers: tejohnson, courbet, theraven, t.p.northover, jdoerfert

Subscribers: mgrang, cfe-commits

Tags: #clang

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

This is a re-submit after it got reverted in 
https://reviews.llvm.org/rGbd8791610948 since the breakage doesn't seem to come 
from this patch.

Added: 
clang/test/CodeGen/no-builtin.cpp
clang/test/Sema/no-builtin.cpp

Modified: 
clang/include/clang/AST/Decl.h
clang/include/clang/Basic/Attr.td
clang/include/clang/Basic/AttrDocs.td
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/lib/CodeGen/CGCall.cpp
clang/lib/Sema/SemaDecl.cpp
clang/lib/Sema/SemaDeclAttr.cpp
clang/test/Misc/pragma-attribute-supported-attributes-list.test

Removed: 




diff  --git a/clang/include/clang/AST/Decl.h b/clang/include/clang/AST/Decl.h
index b3e7a570fd6d..16094c0988fa 100644
--- a/clang/include/clang/AST/Decl.h
+++ b/clang/include/clang/AST/Decl.h
@@ -2031,6 +2031,10 @@ class FunctionDecl : public DeclaratorDecl,
   ///
   /// This does not determine whether the function has been defined (e.g., in a
   /// previous definition); for that information, use isDefined.
+  ///
+  /// Note: the function declaration does not become a definition until the
+  /// parser reaches the definition, if called before, this function will 
return
+  /// `false`.
   bool isThisDeclarationADefinition() const {
 return isDeletedAsWritten() || isDefaulted() || Body || hasSkippedBody() ||
isLateTemplateParsed() || willHaveBody() || hasDefiningAttr();

diff  --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index 4557a614d361..d5018f444e1c 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -3427,3 +3427,10 @@ def ObjCExternallyRetained : InheritableAttr {
   let Subjects = SubjectList<[NonParmVar, Function, Block, ObjCMethod]>;
   let Documentation = [ObjCExternallyRetainedDocs];
 }
+
+def NoBuiltin : Attr {
+  let Spellings = [Clang<"no_builtin">];
+  let Args = [VariadicStringArgument<"BuiltinNames">];
+  let Subjects = SubjectList<[Function]>;
+  let Documentation = [NoBuiltinDocs];
+}

diff  --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index 6e79d0bb3631..9d0d27407573 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -4413,3 +4413,40 @@ and is not a general mechanism for declaring arbitrary 
aliases for
 clang builtin functions.
   }];
 }
+
+def NoBuiltinDocs : Documentation {
+  let Category = DocCatFunction;
+  let Content = [{
+.. Note:: This attribute is not yet fully implemented, it is validated but has
+no effect on the generated code.
+
+The ``__attribute__((no_builtin))`` is similar to the ``-fno-builtin`` flag
+except it is specific to the body of a function. The attribute may also be
+applied to a virtual function but has no effect on the behavior of overriding
+functions in a derived class.
+
+It accepts one or more strings corresponding to the specific names of the
+builtins to disable (e.g. "memcpy", "memset").
+If the attribute is used without parameters it will disable all buitins at
+once.
+
+.. code-block:: c++
+
+  // The compiler is not allowed to add any builtin to foo's body.
+  void foo(char* data, size_t count) __attribute__((no_builtin)) {
+// The compiler is not allowed to convert the loop into
+// `__builtin_memset(data, 0xFE, count);`.
+for (size_t i = 0; i < count; ++i)
+  data[i] = 0xFE;
+  }
+
+  // The compiler is not allowed to add the `memcpy` builtin to bar's body.
+  void bar(char* data, size_t count) __attribute__((no_builtin("memcpy"))) {
+// The compiler is allowed to convert the loop into
+// `__builtin_memset(data, 0xFE, count);` but cannot generate any
+// `__builtin_memcpy`
+for (size_t i = 0; i < count; ++i)
+  data[i] = 0xFE;
+  }
+  }];
+}

diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index c93edb2f91c2..2313c60f006f 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -3604,6 +3604,15 @@ def err_attribute_overloadable_no_prototype : Error<
 def err_attribute_overloadable_multiple_unmarked_overloads : Error<
   "at most one overload for a given name may lack the 'overloadable' "
   "attribute">;
+def warn_a

[PATCH] D69433: [clang-format] [NFC] update the documentation in Format.h to allow dump_format_style.py to get a little closer to being correct. (part 2)

2019-10-29 Thread Sam McCall via Phabricator via cfe-commits
sammccall accepted this revision.
sammccall added a comment.

Apologies for this mess, I didn't know about dump_format_style. Thanks for 
cleaning this up!

Generally the differences were intentional and I think the text in Format.h was 
mostly better :-( Happy to unify but a bunch of suggestions accordingly.




Comment at: clang/docs/ClangFormatStyleOptions.rst:2336
 Use C++03-compatible syntax.
+``Cpp03``: deprecated alias for ``c++03``
 

`Cpp03` is a deprecated alias for `c++03`.
The colons were just to give terse bullets, these are no longer bullets and I 
think they hurt readability.



Comment at: clang/docs/ClangFormatStyleOptions.rst:2343
 Use C++14-compatible syntax.
+``Cpp11``: deprecated alias for ``Latest``
 

I'm not sure why this is grouped here. Did you intend this to be under 
`LS_Latest`?



Comment at: clang/docs/ClangFormatStyleOptions.rst:2343
 Use C++14-compatible syntax.
+``Cpp11``: deprecated alias for ``Latest``
 

sammccall wrote:
> I'm not sure why this is grouped here. Did you intend this to be under 
> `LS_Latest`?
`Cpp11` is a deprecated alias for `Latest`, for historical reasons.



Comment at: clang/docs/tools/dump_format_style.py:175
+val = line.replace(',', '')
+pos = val.find(" // ")
+if (pos != -1):

MyDeveloperDay wrote:
> MyDeveloperDay wrote:
> > mitchell-stellar wrote:
> > > MyDeveloperDay wrote:
> > > > mitchell-stellar wrote:
> > > > > This seems quite flimsy to me, as it depends on an undocumented 
> > > > > comment style. It is true that if the file(s) in question are 
> > > > > properly clang-formatted, then this would probably not fail, but it 
> > > > > does not appear to be a very robust solution.
> > > > I'd tend to agree, but this whole dump_format_style.py is flimsy.. take 
> > > > a look at this review {D31574} 
> > > > 
> > > > When you added this line, you forgot the third /
> > > > 
> > > > ```// Different ways to wrap braces after control statements.```
> > > > 
> > > > Also, the extra empty line in the LanguageStandard both caused the 
> > > > whole python file to fail with an exception.
> > > > 
> > > > Do you have a suggestion for something better? (which doesn't leave the 
> > > > Format.h looking too odd)
> > > I would go back to the `/// c++03: Parse and format as C++03.` style. 
> > > `///` is a Doxygen comment, and I think documentation should be generated 
> > > solely from Doxygen comments, even if it requires a bit of 
> > > post-processing. (The extra `/` needed after `//` in the ticket you 
> > > mentioned is justified.)
> > The Doxygen documentation is used for source-level documentation, this is 
> > user-level documentation which the restructured text output .rst is used.
> > 
> > In the past the ClangFormatStyleOpions.rst has been generated from the 
> > Format.h via this script, we should break that.
> > 
> > The "In configuation" part is super important because it explains to user 
> > what to put into their .clang-format file.
> > 
> > We have to either have some form of markup that says `LS_Cpp03 == c++03` in 
> > the documentation
> *we shouldn't break that*
> The "In configuation" part is super important because it explains to user 
> what to put into their .clang-format file.

Honestly, I'm not sure why the docs say "LS_Foo (in configuration: Foo)" rather 
than just "Foo" - why do users care what the enum is?

But this is an existing practice, and should be changed separately if at all.



Comment at: clang/include/clang/Format/Format.h:1986
   /// The historical aliases ``Cpp03`` and ``Cpp11`` are deprecated.
   enum LanguageStandard {
+/// Use C++03-compatible syntax.

MyDeveloperDay wrote:
> Again focus is on the rst being the desired text and getting them to be 
> aligned. @sammccall  please correct me if my assumption is incorrect
I think "Parse and format as C++03" is better here. In the RST it's redundant, 
as the description for `Standard` precedes this block. But if we have to pick 
one, I'd go with "Parse and format as C++03".



Comment at: clang/include/clang/Format/Format.h:2001
 LS_Latest,
-/// Auto: Automatic detection based on the input.
-/// Parse using the latest language version. Format based on detected 
input.
+/// Automatic detection based on the input.
 LS_Auto,

The new text (two lines) is better, please add it back.



Comment at: clang/include/clang/Format/Format.h:2005
 
-  /// Format compatible with this standard, e.g. use ``A >``
-  /// instead of ``A>`` for ``LS_Cpp03``.
+  /// Parse and Format C++ constructs compatible with this standard.
+  /// \code

nit: "Parse and Format" -> "Parse and format"


Repository:
  rC Clang

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

https://reviews.ll

[PATCH] D69162: [clangd] Remove using-namespace present inside a namespace.

2019-10-29 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov added a comment.

The most important comment is in the tests. Is there a way to have the same 
effect with less changes?




Comment at: clang-tools-extra/clangd/refactor/tweaks/RemoveUsingNamespace.cpp:47
   const UsingDirectiveDecl *TargetDirective = nullptr;
+  const NamespaceDecl *ContainingNS = nullptr;
 };

NIT: could you add a short comment mentioning this is exactly the `DeclContext` 
of `TargetDirective`?



Comment at: 
clang-tools-extra/clangd/refactor/tweaks/RemoveUsingNamespace.cpp:110
+  auto DeclCtx = TargetDirective->getDeclContext();
+  if (!dyn_cast(DeclCtx))
 return false;

This check looks redundant now that we check the decl context is a namespace of 
a translation unit.
I think it was originally intended to check the whether the `using namespace` 
is inside a function or not.



Comment at: 
clang-tools-extra/clangd/refactor/tweaks/RemoveUsingNamespace.cpp:173
+
+CharSourceRange RemoveQualifier;
+RemoveQualifier.setBegin(Ref.Qualifier ? Ref.Qualifier.getBeginLoc() : 
Loc);

NIT: maybe simplify to
```
QualifierReplacements.push_back(
  CharSourceRange::getTokenRange(
Ref.Qualifier ? Ref.Qualifier.getBeginLoc : Loc, 
Loc));
```
?



Comment at: 
clang-tools-extra/clangd/refactor/tweaks/RemoveUsingNamespace.cpp:180
+  if (ContainingNS)
+findExplicitReferences(ContainingNS, SelectRefToQualify);
+  else

Do we also need to run in the redeclarations of the same namespace?
```
namespace clangd {
  using namespace clang;
}

namespace clangd {
  /*clang::*/Decl* D = nullptr;
}
```



Comment at: 
clang-tools-extra/clangd/refactor/tweaks/RemoveUsingNamespace.cpp:182
+  else
+for (auto &D : Inputs.AST.getLocalTopLevelDecls())
+  findExplicitReferences(D, SelectRefToQualify);

NIT: could you add braces around the branches of the if statement?
for loop is complicated, so it probably qualifies as something that asks for 
the braces.



Comment at: clang-tools-extra/clangd/unittests/TweakTests.cpp:898
+A::B::vector V3;
+A::B::std::vector V4;
+::A::B::std::vector V5;

Is there a way to avoid re-qualifying this?
We should aim for minimal changes and there is probably a simple way to achieve 
this by only qualifying when the qualifier itself references the `ContainingNS` 
and target is inside the target namespace of the directive being removed.

Or this too complicated for some reason?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69162



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


[PATCH] D69566: [ASTImporter] Add support for BuiltinTemplateDecl

2019-10-29 Thread Raphael Isemann via Phabricator via cfe-commits
teemperor created this revision.
teemperor added reviewers: martong, a.sidorin.
Herald added subscribers: cfe-commits, kristina, rnkovacs.
Herald added a reviewer: shafik.
Herald added a project: clang.

That decl kind is currently not implemented. BuiltinTemplateDecl is for decls 
that are hardcoded in the
ASTContext, so we can import them like we do other builtin decls by just taking 
the equivalent
decl from the target ASTContext.


Repository:
  rC Clang

https://reviews.llvm.org/D69566

Files:
  clang/lib/AST/ASTImporter.cpp
  clang/test/Import/builtin-template/Inputs/S.cpp
  clang/test/Import/builtin-template/test.cpp


Index: clang/test/Import/builtin-template/test.cpp
===
--- /dev/null
+++ clang/test/Import/builtin-template/test.cpp
@@ -0,0 +1,30 @@
+// RUN: clang-import-test -dump-ast -import %S/Inputs/S.cpp -expression %s 
-Xcc -DSEQ | FileCheck --check-prefix=CHECK-SEQ %s
+// RUN: clang-import-test -dump-ast -import %S/Inputs/S.cpp -expression %s 
-Xcc -DPACK | FileCheck --check-prefix=CHECK-PACK %s
+// RUN: clang-import-test -dump-ast -import %S/Inputs/S.cpp -expression %s 
-Xcc -DPACK -Xcc -DSEQ | FileCheck --check-prefixes=CHECK-SEQ,CHECK-PACK %s
+
+// CHECK-SEQ: BuiltinTemplateDecl
+// CHECK-SEQ-SAME: 
+// CHECK-SEQ-SAME: implicit
+// CHECK-SEQ-SAME: __make_integer_seq
+
+// CHECK-PACK: BuiltinTemplateDecl
+// CHECK-PACK-SAME: 
+// CHECK-PACK-SAME: implicit
+// CHECK-PACK-SAME: __type_pack_element
+
+void expr() {
+#ifdef SEQ
+  typedef MakeSeq M1;
+  M1 m1;
+  typedef MakeSeq M2;
+  M2 m2;
+  static_assert(M1::PackSize == 3, "");
+  static_assert(M2::PackSize == 4, "");
+#endif
+
+#ifdef PACK
+  static_assert(__is_same(TypePackElement<0, X<0>>, X<0>), "");
+  static_assert(__is_same(TypePackElement<0, X<0>, X<1>>, X<0>), "");
+  static_assert(__is_same(TypePackElement<1, X<0>, X<1>>, X<1>), "");
+#endif
+}
Index: clang/test/Import/builtin-template/Inputs/S.cpp
===
--- /dev/null
+++ clang/test/Import/builtin-template/Inputs/S.cpp
@@ -0,0 +1,16 @@
+template 
+struct Seq {
+  static constexpr T PackSize = sizeof...(I);
+};
+
+template 
+using MakeSeq = __make_integer_seq;
+
+
+using SizeT = decltype(sizeof(int));
+
+template 
+using TypePackElement = __type_pack_element;
+
+template 
+struct X;
Index: clang/lib/AST/ASTImporter.cpp
===
--- clang/lib/AST/ASTImporter.cpp
+++ clang/lib/AST/ASTImporter.cpp
@@ -44,6 +44,7 @@
 #include "clang/AST/TypeLoc.h"
 #include "clang/AST/TypeVisitor.h"
 #include "clang/AST/UnresolvedSet.h"
+#include "clang/Basic/Builtins.h"
 #include "clang/Basic/ExceptionSpecificationType.h"
 #include "clang/Basic/FileManager.h"
 #include "clang/Basic/IdentifierTable.h"
@@ -483,6 +484,7 @@
 ExpectedDecl VisitUsingDirectiveDecl(UsingDirectiveDecl *D);
 ExpectedDecl VisitUnresolvedUsingValueDecl(UnresolvedUsingValueDecl *D);
 ExpectedDecl VisitUnresolvedUsingTypenameDecl(UnresolvedUsingTypenameDecl 
*D);
+ExpectedDecl VisitBuiltinTemplateDecl(BuiltinTemplateDecl *D);
 
 Expected
 ImportObjCTypeParamList(ObjCTypeParamList *list);
@@ -4464,6 +4466,20 @@
   return ToUsing;
 }
 
+ExpectedDecl ASTNodeImporter::VisitBuiltinTemplateDecl(BuiltinTemplateDecl *D) 
{
+  Decl* ToD = nullptr;
+  switch (D->getBuiltinTemplateKind()) {
+  case BuiltinTemplateKind::BTK__make_integer_seq:
+ToD = Importer.getToContext().getMakeIntegerSeqDecl();
+break;
+  case BuiltinTemplateKind::BTK__type_pack_element:
+ToD = Importer.getToContext().getTypePackElementDecl();
+break;
+  }
+  assert(ToD && "BuiltinTemplateDecl of unsupported kind!");
+  Importer.MapImported(D, ToD);
+  return ToD;
+}
 
 Error ASTNodeImporter::ImportDefinition(
 ObjCInterfaceDecl *From, ObjCInterfaceDecl *To, ImportDefinitionKind Kind) 
{


Index: clang/test/Import/builtin-template/test.cpp
===
--- /dev/null
+++ clang/test/Import/builtin-template/test.cpp
@@ -0,0 +1,30 @@
+// RUN: clang-import-test -dump-ast -import %S/Inputs/S.cpp -expression %s -Xcc -DSEQ | FileCheck --check-prefix=CHECK-SEQ %s
+// RUN: clang-import-test -dump-ast -import %S/Inputs/S.cpp -expression %s -Xcc -DPACK | FileCheck --check-prefix=CHECK-PACK %s
+// RUN: clang-import-test -dump-ast -import %S/Inputs/S.cpp -expression %s -Xcc -DPACK -Xcc -DSEQ | FileCheck --check-prefixes=CHECK-SEQ,CHECK-PACK %s
+
+// CHECK-SEQ: BuiltinTemplateDecl
+// CHECK-SEQ-SAME: 
+// CHECK-SEQ-SAME: implicit
+// CHECK-SEQ-SAME: __make_integer_seq
+
+// CHECK-PACK: BuiltinTemplateDecl
+// CHECK-PACK-SAME: 
+// CHECK-PACK-SAME: implicit
+// CHECK-PACK-SAME: __type_pack_element
+
+void expr() {
+#ifdef SEQ
+  typedef MakeSeq M1;
+  M1 m1;
+  typedef MakeSeq M2;
+  M2 m2;
+  static_assert(M1::PackSize == 3, "");
+  static_assert(M2::PackSize == 4, "");
+#endif
+
+#ifdef PACK
+  static_asser

[PATCH] D69560: [clang-tidy] Add 'cppcoreguidelines-avoid-adjacent-arguments-of-same-type' check

2019-10-29 Thread Whisperity via Phabricator via cfe-commits
whisperity added reviewers: Szelethus, baloghadamsoftware.
whisperity edited subscribers, added: baloghadamsoftware, NoQ; removed: 
Szelethus.
whisperity added a comment.

@Szelethus and @baloghadamsoftware are colleagues to me whom are far more 
knowledgeable about check development and I want them to see that I want a 
review from them. I specifically didn't do an "internal with colleagues" 
downstream review with regards to this code.




Comment at: 
clang-tools-extra/clang-tidy/cppcoreguidelines/AdjacentArgumentsOfSameTypeCheck.cpp:488
+void AdjacentArgumentsOfSameTypeCheck::registerMatchers(MatchFinder *Finder) {
+  if (!getLangOpts().CPlusPlus)
+return;

Eugene.Zelenko wrote:
> Check seems to be useful for C and probably for Objective-C.
I'm not knowledgeable about Objective-C at all to make a decision on how the 
"adjacent argument ranges" could be calculated and what mixups are possible. As 
for C, should a `cppcoreguidelines-` check be enabled for C? Or you mean we 
should allow it to work, and the user will toggle how they see fit.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69560



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


[PATCH] D69567: [AArch64][SVE] Implement additional integer arithmetic intrinsics

2019-10-29 Thread Kerry McLaughlin via Phabricator via cfe-commits
kmclaughlin created this revision.
kmclaughlin added reviewers: huntergr, sdesmalen.
Herald added subscribers: psnobl, rkruppe, hiraditya, kristof.beyls, tschuett.
Herald added a project: LLVM.

Add intrinsics for the following:

- sxt[b|h|w] & uxt[b|h|w]
- cls & clz
- not & cnot


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D69567

Files:
  llvm/include/llvm/IR/IntrinsicsAArch64.td
  llvm/lib/Target/AArch64/AArch64SVEInstrInfo.td
  llvm/lib/Target/AArch64/SVEInstrFormats.td
  llvm/test/CodeGen/AArch64/sve-intrinsics-conversion.ll
  llvm/test/CodeGen/AArch64/sve-intrinsics-counting-bits.ll
  llvm/test/CodeGen/AArch64/sve-intrinsics-logical.ll

Index: llvm/test/CodeGen/AArch64/sve-intrinsics-logical.ll
===
--- /dev/null
+++ llvm/test/CodeGen/AArch64/sve-intrinsics-logical.ll
@@ -0,0 +1,99 @@
+; RUN: llc -mtriple=aarch64-linux-gnu -mattr=+sve < %s | FileCheck %s
+
+;
+; CNOT
+;
+
+define  @cnot_i8( %a,  %pg,  %b) {
+; CHECK-LABEL: cnot_i8:
+; CHECK: cnot z0.b, p0/m, z1.b
+; CHECK-NEXT: ret
+  %out = call  @llvm.aarch64.sve.cnot.nxv16i8( %a,
+ %pg,
+ %b)
+  ret  %out
+}
+
+define  @cnot_i16( %a,  %pg,  %b) {
+; CHECK-LABEL: cnot_i16:
+; CHECK: cnot z0.h, p0/m, z1.h
+; CHECK-NEXT: ret
+  %out = call  @llvm.aarch64.sve.cnot.nxv8i16( %a,
+ %pg,
+ %b)
+  ret  %out
+}
+
+define  @cnot_i32( %a,  %pg,  %b) {
+; CHECK-LABEL: cnot_i32:
+; CHECK: cnot z0.s, p0/m, z1.s
+; CHECK-NEXT: ret
+  %out = call  @llvm.aarch64.sve.cnot.nxv4i32( %a,
+ %pg,
+ %b)
+  ret  %out
+}
+
+define  @cnot_i64( %a,  %pg,  %b) {
+; CHECK-LABEL: cnot_i64:
+; CHECK: cnot z0.d, p0/m, z1.d
+; CHECK-NEXT: ret
+  %out = call  @llvm.aarch64.sve.cnot.nxv2i64( %a,
+ %pg,
+ %b)
+  ret  %out
+}
+
+;
+; NOT
+;
+
+define  @not_i8( %a,  %pg,  %b) {
+; CHECK-LABEL: not_i8:
+; CHECK: not z0.b, p0/m, z1.b
+; CHECK-NEXT: ret
+  %out = call  @llvm.aarch64.sve.not.nxv16i8( %a,
+%pg,
+%b)
+  ret  %out
+}
+
+define  @not_i16( %a,  %pg,  %b) {
+; CHECK-LABEL: not_i16:
+; CHECK: not z0.h, p0/m, z1.h
+; CHECK-NEXT: ret
+  %out = call  @llvm.aarch64.sve.not.nxv8i16( %a,
+%pg,
+%b)
+  ret  %out
+}
+
+define  @not_i32( %a,  %pg,  %b) {
+; CHECK-LABEL: not_i32:
+; CHECK: not z0.s, p0/m, z1.s
+; CHECK-NEXT: ret
+  %out = call  @llvm.aarch64.sve.not.nxv4i32( %a,
+%pg,
+%b)
+  ret  %out
+}
+
+define  @not_i64( %a,  %pg,  %b) {
+; CHECK-LABEL: not_i64:
+; CHECK: not z0.d, p0/m, z1.d
+; CHECK-NEXT: ret
+  %out = call  @llvm.aarch64.sve.not.nxv2i64( %a,
+%pg,
+%b)
+  ret  %out
+}
+
+declare  @llvm.aarch64.sve.cnot.nxv16i8(, , )
+declare  @llvm.aarch64.sve.cnot.nxv8i16(, , )
+declare  @llvm.aarch64.sve.cnot.nxv4i32(, , )
+declare  @llvm.aarch64.sve.cnot.nxv2i64(, , )
+
+declare  @llvm.aarch64.sve.not.nxv16i8(, , )
+declare  @llvm.aarch64.sve.not.nxv8i16(, , )
+declare  @llvm.aarch64.sve.not.nxv4i32(, , )
+declare  @llvm.aarch64.sve.not.nxv2i64(, , )
Index: llvm/test/CodeGen/AArch64/sve-intrinsics-counting-bits.ll
===
--- llvm/test/CodeGen/AArch64/sve-intrinsics-counting-bits.ll
+++ llvm/test/CodeGen/AArch64/sve-intrinsics-counting-bits.ll
@@ -1,6 +1,94 @@
 ; RUN: llc -mtriple=aarch64-linux-gnu -mattr=+sve < %s | FileCheck %s
 
 ;
+; CLS
+;
+
+define  @cls_i8( %a,  %pg,  %b) {
+; CHECK-LABEL: cls_i8:
+; CHECK: cls z0.b, p0/m, z1.b
+; CHECK-NEXT: ret
+  %out = call  @llvm.aarch64.sve.cls.nxv16i8( %a,
+%pg,
+%b)
+  ret  %out
+}
+
+define  @cls_i16( %a,  %pg,  %b) {
+; CHECK-LABEL: cls_i16:
+; CHECK: cls z0.h, p0/m, z1.h
+; CHECK-NEXT: ret
+  %out = call  @llvm.aarch64.sve.cls.nxv8i16( %a,
+%pg,
+%b)
+  ret  %out
+}
+
+define  @cls_i32( %a,  %pg,  %b) {
+; CHECK-LABEL: cls_i32:
+; C

[PATCH] D62731: Add support for options -frounding-math, ftrapping-math, -fp-model=, and -fp-exception-behavior=, : Specify floating point behavior

2019-10-29 Thread Melanie Blower via Phabricator via cfe-commits
mibintc updated this revision to Diff 226907.
mibintc added a comment.

In response to comments from @rjmccall I inserted into the UsersManual the 
one-line summary of frounding-math that had been omitted and changed the 
semantics of frounding-math to not also set exception-behavior to strict


Repository:
  rL LLVM

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

https://reviews.llvm.org/D62731

Files:
  clang/docs/UsersManual.rst
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Basic/LangOptions.h
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/fpconstrained.c
  clang/test/Driver/clang_f_opts.c
  clang/test/Driver/fast-math.c
  clang/test/Driver/fp-model.c
  llvm/include/llvm/Target/TargetOptions.h

Index: llvm/include/llvm/Target/TargetOptions.h
===
--- llvm/include/llvm/Target/TargetOptions.h
+++ llvm/include/llvm/Target/TargetOptions.h
@@ -107,7 +107,7 @@
   public:
 TargetOptions()
 : PrintMachineCode(false), UnsafeFPMath(false), NoInfsFPMath(false),
-  NoNaNsFPMath(false), NoTrappingFPMath(false),
+  NoNaNsFPMath(false), NoTrappingFPMath(true), RoundingFPMath(false),
   NoSignedZerosFPMath(false),
   HonorSignDependentRoundingFPMathOption(false), NoZerosInBSS(false),
   GuaranteedTailCallOpt(false), StackSymbolOrdering(true),
@@ -154,6 +154,11 @@
 /// specifies that there are no trap handlers to handle exceptions.
 unsigned NoTrappingFPMath : 1;
 
+/// RoundingFPMath - This flag is enabled when the
+/// -enable-rounding-fp-math is specified on the command line. This
+/// specifies dynamic rounding mode.
+unsigned RoundingFPMath : 1;
+
 /// NoSignedZerosFPMath - This flag is enabled when the
 /// -enable-no-signed-zeros-fp-math is specified on the command line. This
 /// specifies that optimizations are allowed to treat the sign of a zero
Index: clang/test/Driver/fp-model.c
===
--- /dev/null
+++ clang/test/Driver/fp-model.c
@@ -0,0 +1,130 @@
+// Test that incompatible combinations of -ffp-model= options
+// and other floating point options get a warning diagnostic.
+//
+// REQUIRES: clang-driver
+
+// RUN: %clang -### -ffp-model=fast -ffp-contract=off -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=WARN %s
+// WARN: warning: overriding '-ffp-model=fast' option with '-ffp-contract=off' [-Woverriding-t-option]
+
+// RUN: %clang -### -ffp-model=fast -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=WARN1 %s
+// WARN1: warning: overriding '-ffp-model=fast' option with '-ffp-contract=on' [-Woverriding-t-option]
+
+// RUN: %clang -### -ffp-model=strict -fassociative-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=WARN2 %s
+// WARN2: warning: overriding '-ffp-model=strict' option with '-fassociative-math' [-Woverriding-t-option]
+
+// RUN: %clang -### -ffp-model=strict -ffast-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=WARN3 %s
+// WARN3: warning: overriding '-ffp-model=strict' option with '-ffast-math' [-Woverriding-t-option]
+
+// RUN: %clang -### -ffp-model=strict -ffinite-math-only -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=WARN4 %s
+// WARN4: warning: overriding '-ffp-model=strict' option with '-ffinite-math-only' [-Woverriding-t-option]
+
+// RUN: %clang -### -ffp-model=strict -ffp-contract=fast -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=WARN5 %s
+// WARN5: warning: overriding '-ffp-model=strict' option with '-ffp-contract=fast' [-Woverriding-t-option]
+
+// RUN: %clang -### -ffp-model=strict -ffp-contract=off -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=WARN6 %s
+// WARN6: warning: overriding '-ffp-model=strict' option with '-ffp-contract=off' [-Woverriding-t-option]
+
+// RUN: %clang -### -ffp-model=strict -ffp-contract=on -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=WARN7 %s
+// WARN7: warning: overriding '-ffp-model=strict' option with '-ffp-contract=on' [-Woverriding-t-option]
+
+// RUN: %clang -### -ffp-model=strict -fno-honor-infinities -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=WARN8 %s
+// WARN8: warning: overriding '-ffp-model=strict' option with '-fno-honor-infinities' [-Woverriding-t-option]
+
+// RUN: %clang -### -ffp-model=strict -fno-honor-nans -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=WARN9 %s
+// WARN9: warning: overriding '-ffp-model=strict' option with '-fno-honor-nans' [-Woverriding-t-option]
+
+// RUN: %clang -### -ffp-model=strict -fno-rounding-math -c %s 2>&1 \
+// RUN:   | FileCheck --check-prefix=WARNa %s
+// WARNa: warning: overriding '-ffp-model=strict' option with '-fno-rounding-math' [-Woverriding-t-option]
+
+// RUN: %clang -### -

[PATCH] D62731: Add support for options -frounding-math, ftrapping-math, -fp-model=, and -fp-exception-behavior=, : Specify floating point behavior

2019-10-29 Thread Melanie Blower via Phabricator via cfe-commits
mibintc added a comment.

In D62731#1724290 , @rjmccall wrote:

> Is the exception-strictness of `-frounding-math` actually considered to be 
> specified behavior, or is it just a consequence of the current 
> implementation?  There are definitely some optimizations that we can't do 
> under strict FP exceptions that we can still do in principle while respecting 
> a dynamic FP rounding mode; for example, the rounding mode can only be 
> changed by a call (or inline assembly), so you can still reorder FP 
> operations around "lesser" side effects, like stores.  We can document it 
> even if it's not required behavior, but we should be clear about what it is.


I had thought that it was intended behavior, but I re-checked my notes and 
realize I was wrong about that. So I've changed the document and the driver, 
and updated the test. Thanks again for your careful reading.

> My suggested wording started with a sentence briefly summarizing what the 
> option did that I think you accidentally dropped.

Yes, it's there now.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D62731



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


[PATCH] D68937: [clangd] Add parameter renaming to define-inline code action

2019-10-29 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added inline comments.



Comment at: clang-tools-extra/clangd/unittests/TweakTests.cpp:1517
+template 
+void foo(PARAM, TYPE b, TYPE c, TYPE d = BODY(x)){}
+

ilya-biryukov wrote:
> We fail to rename the parameter in that case, right?
> Should the action not be available or maybe show an error message?
> 
> Also ok with keeping the current behavior if we add a FIXME mentioning it 
> would be nice to fix this.
somehow forgot my stashed changes ...

yes this was supposed to bail out on failure, but leave the macro occurrence if 
parameter names are the same.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68937



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


[PATCH] D68937: [clangd] Add parameter renaming to define-inline code action

2019-10-29 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet updated this revision to Diff 226909.
kadircet marked 2 inline comments as done.
kadircet added a comment.

- Use Lexer::makeFileCharRange


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68937

Files:
  clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp
  clang-tools-extra/clangd/unittests/TweakTests.cpp

Index: clang-tools-extra/clangd/unittests/TweakTests.cpp
===
--- clang-tools-extra/clangd/unittests/TweakTests.cpp
+++ clang-tools-extra/clangd/unittests/TweakTests.cpp
@@ -40,9 +40,9 @@
 #include 
 
 using ::testing::AllOf;
+using ::testing::ElementsAre;
 using ::testing::HasSubstr;
 using ::testing::StartsWith;
-using ::testing::ElementsAre;
 
 namespace clang {
 namespace clangd {
@@ -1377,7 +1377,7 @@
   // Template body is not parsed until instantiation time on windows, which
   // results in arbitrary failures as function body becomes NULL.
   ExtraArgs.push_back("-fno-delayed-template-parsing");
-  for(const auto &Case : Cases)
+  for (const auto &Case : Cases)
 EXPECT_EQ(apply(Case.first), Case.second) << Case.first;
 }
 
@@ -1420,7 +1420,7 @@
 }
 
 TEST_F(DefineInlineTest, TransformDeclRefs) {
-  auto Test =R"cpp(
+  auto Test = R"cpp(
 namespace a {
   template  class Bar {
   public:
@@ -1489,6 +1489,71 @@
   EXPECT_EQ(apply(Test), Expected);
 }
 
+TEST_F(DefineInlineTest, TransformParamNames) {
+  EXPECT_EQ(apply(R"cpp(
+void foo(int, bool b, int T\
+est);
+
+void ^foo(int f, bool x, int z) {})cpp"),
+R"cpp(
+void foo(int f, bool x, int z){}
+
+)cpp");
+
+  EXPECT_EQ(apply(R"cpp(
+#define PARAM int Z
+void foo(PARAM);
+
+void ^foo(int X) {})cpp"),
+"fail: Cant rename parameter inside macro body.");
+
+  EXPECT_EQ(apply(R"cpp(
+#define TYPE int
+#define PARAM TYPE Z
+#define BODY(x) 5 * (x) + 2
+template 
+void foo(PARAM, TYPE Q, TYPE, TYPE W = BODY(P));
+
+template 
+void ^foo(int Z, int b, int c, int d) {})cpp"),
+R"cpp(
+#define TYPE int
+#define PARAM TYPE Z
+#define BODY(x) 5 * (x) + 2
+template 
+void foo(PARAM, TYPE b, TYPE c, TYPE d = BODY(x)){}
+
+)cpp");
+}
+
+TEST_F(DefineInlineTest, TransformTemplParamNames) {
+  EXPECT_EQ(apply(R"cpp(
+struct Foo {
+  struct Bar {
+template  class, template class Y,
+  int, int Z>
+void foo(X, Y, int W = 5 * Z + 2);
+  };
+};
+
+template  class V, template class W,
+  int X, int Y>
+void Foo::Bar::f^oo(U, W, int Q) {})cpp"),
+R"cpp(
+struct Foo {
+  struct Bar {
+template  class V, template class W,
+  int X, int Y>
+void foo(U, W, int Q = 5 * Y + 2){}
+  };
+};
+
+)cpp");
+}
+
 TEST_F(DefineInlineTest, TransformInlineNamespaces) {
   auto Test = R"cpp(
 namespace a { inline namespace b { namespace { struct Foo{}; } } }
@@ -1527,7 +1592,7 @@
   void fo^o() { return ; })cpp",
"fail: Couldn't find semicolon for target declaration."},
   };
-  for(const auto& Case: Cases)
+  for (const auto &Case : Cases)
 EXPECT_EQ(apply(Case.first), Case.second) << Case.first;
 }
 
@@ -1585,7 +1650,7 @@
   void TARGET(){ return; }
   )cpp"},
   };
-  for(const auto& Case: Cases)
+  for (const auto &Case : Cases)
 EXPECT_EQ(apply(Case.first), Case.second) << Case.first;
 }
 
Index: clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp
===
--- clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp
+++ clang-tools-extra/clangd/refactor/tweaks/DefineInline.cpp
@@ -226,6 +226,117 @@
   return QualifiedFunc->substr(BodyBegin, BodyEnd - BodyBegin + 1);
 }
 
+/// Generates Replacements for changing template and function parameter names in
+/// \p Dest to be the same as in \p Source.
+llvm::Expected
+renameParameters(const FunctionDecl *Dest, const FunctionDecl *Source) {
+  tooling::Replacements Replacements;
+
+  llvm::DenseMap ParamToNewName;
+  llvm::DenseMap> RefLocs;
+  auto HandleParam = [&](const NamedDecl *DestParam,
+ const NamedDecl *SourceParam) {
+// No need to rename if parameters already have the same name.
+if (DestParam->getName() == SourceParam->getName())
+  return;
+std::string NewName;
+// Unnamed parameters won't be visited in findExplicitReferences. So add
+// them here.
+if (DestParam->getName().empty()) {
+  RefLocs[DestParam].push_back(DestParam->getLocation());
+  // If decl is unnamed in destination we pad the new name to avoid gluing
+  // with previous token, e.g. foo(int^) shouldn't turn into foo(intx).
+  NewName = " ";
+}
+NewName.append(SourceParam->getName());
+ParamToNewName[DestParam->getCanonicalDecl()] = std::move(NewName);

[clang] 5607ff1 - Fix missing memcpy builtin on ppc64be

2019-10-29 Thread Guillaume Chatelet via cfe-commits

Author: Guillaume Chatelet
Date: 2019-10-29T16:35:32+01:00
New Revision: 5607ff12fad9a54728a3cda0eacaffee02e4b434

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

LOG: Fix missing memcpy builtin on ppc64be
See D68028

Added: 


Modified: 
clang/test/CodeGen/no-builtin.cpp
clang/test/Sema/no-builtin.cpp

Removed: 




diff  --git a/clang/test/CodeGen/no-builtin.cpp 
b/clang/test/CodeGen/no-builtin.cpp
index 3c5d681282da..24df100d8717 100644
--- a/clang/test/CodeGen/no-builtin.cpp
+++ b/clang/test/CodeGen/no-builtin.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -triple x86_64-linux-gnu -S -emit-llvm -o - %s | FileCheck 
%s
+// UNSUPPORTED: ppc64be
 
 // CHECK-LABEL: define void @foo_no_mempcy() #0
 extern "C" void foo_no_mempcy() __attribute__((no_builtin("memcpy"))) {}

diff  --git a/clang/test/Sema/no-builtin.cpp b/clang/test/Sema/no-builtin.cpp
index 40781abd3037..8908f38333bd 100644
--- a/clang/test/Sema/no-builtin.cpp
+++ b/clang/test/Sema/no-builtin.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown -fsyntax-only -verify %s
+// UNSUPPORTED: ppc64be
 
 /// Prevent use of all builtins.
 void valid_attribute_all_1() __attribute__((no_builtin)) {}



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


[PATCH] D69433: [clang-format] [NFC] update the documentation in Format.h to allow dump_format_style.py to get a little closer to being correct. (part 2)

2019-10-29 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay marked 4 inline comments as done.
MyDeveloperDay added inline comments.



Comment at: clang/docs/ClangFormatStyleOptions.rst:2343
 Use C++14-compatible syntax.
+``Cpp11``: deprecated alias for ``Latest``
 

sammccall wrote:
> sammccall wrote:
> > I'm not sure why this is grouped here. Did you intend this to be under 
> > `LS_Latest`?
> `Cpp11` is a deprecated alias for `Latest`, for historical reasons.
yes correct I'll make that change with regard to its position.



Comment at: clang/docs/tools/dump_format_style.py:175
+val = line.replace(',', '')
+pos = val.find(" // ")
+if (pos != -1):

sammccall wrote:
> MyDeveloperDay wrote:
> > MyDeveloperDay wrote:
> > > mitchell-stellar wrote:
> > > > MyDeveloperDay wrote:
> > > > > mitchell-stellar wrote:
> > > > > > This seems quite flimsy to me, as it depends on an undocumented 
> > > > > > comment style. It is true that if the file(s) in question are 
> > > > > > properly clang-formatted, then this would probably not fail, but it 
> > > > > > does not appear to be a very robust solution.
> > > > > I'd tend to agree, but this whole dump_format_style.py is flimsy.. 
> > > > > take a look at this review {D31574} 
> > > > > 
> > > > > When you added this line, you forgot the third /
> > > > > 
> > > > > ```// Different ways to wrap braces after control statements.```
> > > > > 
> > > > > Also, the extra empty line in the LanguageStandard both caused the 
> > > > > whole python file to fail with an exception.
> > > > > 
> > > > > Do you have a suggestion for something better? (which doesn't leave 
> > > > > the Format.h looking too odd)
> > > > I would go back to the `/// c++03: Parse and format as C++03.` style. 
> > > > `///` is a Doxygen comment, and I think documentation should be 
> > > > generated solely from Doxygen comments, even if it requires a bit of 
> > > > post-processing. (The extra `/` needed after `//` in the ticket you 
> > > > mentioned is justified.)
> > > The Doxygen documentation is used for source-level documentation, this is 
> > > user-level documentation which the restructured text output .rst is used.
> > > 
> > > In the past the ClangFormatStyleOpions.rst has been generated from the 
> > > Format.h via this script, we should break that.
> > > 
> > > The "In configuation" part is super important because it explains to user 
> > > what to put into their .clang-format file.
> > > 
> > > We have to either have some form of markup that says `LS_Cpp03 == c++03` 
> > > in the documentation
> > *we shouldn't break that*
> > The "In configuation" part is super important because it explains to user 
> > what to put into their .clang-format file.
> 
> Honestly, I'm not sure why the docs say "LS_Foo (in configuration: Foo)" 
> rather than just "Foo" - why do users care what the enum is?
> 
> But this is an existing practice, and should be changed separately if at all.
I have a tendency to agree with you here..  who cares about the LK_ in the 
LK_Cpp value?

{F10569311}

However I know as a clang-format developer I really care about seeing them from 
the perspective of being able to easily search in the code for things like  
`BCIS_BeforeComma`, otherwise, it's harder for me to work out which setting 
goes with which setting without going into Format.h and searching (but that's 
just me being lazy), but from a users perspective I wonder how many people put 
the enum name in the configuration by mistake..


Oh dear... it turns out this is a problem 

https://github.com/search?l=YAML&q=LK_Cpp&type=Code

From time it time it appears people are using the enum name incorrectly.

{F10569361}

@klimek maybe we should consider making this to make it a little clearer.

{F10569372}

I feel we might be guiding people incorrectly.

{F10569374}




Repository:
  rC Clang

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

https://reviews.llvm.org/D69433



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


[PATCH] D68937: [clangd] Add parameter renaming to define-inline code action

2019-10-29 Thread pre-merge checks [bot] via Phabricator via cfe-commits
merge_guards_bot added a comment.

Build result: pass - 59704 tests passed, 0 failed and 762 were skipped.
Log files: console-log.txt 
,
 CMakeCache.txt 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68937



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


[PATCH] D69567: [AArch64][SVE] Implement additional integer arithmetic intrinsics

2019-10-29 Thread Sander de Smalen via Phabricator via cfe-commits
sdesmalen accepted this revision.
sdesmalen added a comment.
This revision is now accepted and ready to land.

Thanks, LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69567



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


[PATCH] D69322: [hip][cuda] Enable extended lambda support on Windows.

2019-10-29 Thread Artem Belevich via Phabricator via cfe-commits
tra added a reviewer: rnk.
tra added a subscriber: rnk.
tra added a comment.

@rnk Reid, would you be the right person to look at the change on the Windows' 
side?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69322



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


[PATCH] D62731: Add support for options -frounding-math, ftrapping-math, -fp-model=, and -fp-exception-behavior=, : Specify floating point behavior

2019-10-29 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

Thanks.  A few things about the functionality parts of the patch now.




Comment at: clang/include/clang/Basic/CodeGenOptions.def:238
 CODEGENOPT(UnsafeFPMath  , 1, 0) ///< Allow unsafe floating point optzns.
+CODEGENOPT(RoundingFPMath, 1, 0) ///< Rounding floating point optzns.
 CODEGENOPT(UnwindTables  , 1, 0) ///< Emit unwind tables.

Why do we need both a code-gen option and a language option?



Comment at: clang/include/clang/Basic/LangOptions.h:366
+  FPEB = Value;
+}
+

Everything here is a "setting", and in the context of this type they're all FP. 
 Please name these methods something like `getRoundingMode()`.

Does this structure really need to exist as opposed to tracking the dimensions 
separately?  Don't we already track some of this somewhere?  We should subsume 
that state into these values rather than tracking them separately.



Comment at: clang/lib/CodeGen/CodeGenFunction.cpp:108
+void CodeGenFunction::SetFPModel(void)
+{
+  auto fpRoundingMode = 
getLangOpts().getFPMOptions().getFPRoundingModeSetting();

Code style: please use `()` instead of `(void)`, and please place open-braces 
on the same line as the declaration.



Comment at: clang/lib/CodeGen/CodeGenFunction.h:4158
+  /// SetFPModel - Control floating point behavior via fp-model settings.
+  void SetFPModel(void);
+

Don't use `(void)`, please.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D62731



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


[PATCH] D69566: [ASTImporter] Add support for BuiltinTemplateDecl

2019-10-29 Thread Gabor Marton via Phabricator via cfe-commits
martong accepted this revision.
martong added a comment.
This revision is now accepted and ready to land.

LGTM! Thanks!




Comment at: clang/lib/AST/ASTImporter.cpp:4479
+  }
+  assert(ToD && "BuiltinTemplateDecl of unsupported kind!");
+  Importer.MapImported(D, ToD);

Nit: perhaps `llvm_unreachable` is more appropriate here.


Repository:
  rC Clang

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

https://reviews.llvm.org/D69566



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


[PATCH] D69498: IR: Invert convergent attribute handling

2019-10-29 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

In D69498#1724625 , @kariddi wrote:

> One thing to probably note is that its not only a "target specific" issue, 
> but a language specific issue as well (IMHO). OpenCL, CUDA, SYCL are all 
> languages (to name a few) that have a concept of "convergence" and its not 
> related only to the fact that they mostly run on a GPU, but to their 
> programming model as well with respect to accessing textures and SIMD-wide 
> communication and decision making (ballot)
>
> Considering that Clang has support for these languages it kind of makes sense 
> to me that the frontend is taking care of implementing the supported 
> languages correctly by applying the proper attributes.


It absolutely makes sense for Clang as a GPU-programming frontend to set 
attributes appropriately when targeting the GPU.  I'm objecting to making 
"convergence" and related "code layout is semantics" properties a universal 
part of the IR semantics that literally every frontend has to know about in 
order to get reasonable behavior from LLVM.  I know that doing so makes sense 
to GPU backend developers because you mostly work exclusively on GPU 
toolchains, but AFAIK there are half a dozen GPU frontends and they're all 
forks of Clang, whereas there are dozens of LLVM frontends out there that don't 
care about targeting the GPU and quite possibly never will.  (And even if they 
do target GPUs, they often will not care about exposing thread groups; many 
programming environments are just interested in taking advantage of the GPU's 
parallel-computation power and have no interest in inter-thread interference.)

John.


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

https://reviews.llvm.org/D69498



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


[clang] 1c85a2e - isBuiltinFunc() uses StringRef instead of const char*

2019-10-29 Thread Guillaume Chatelet via cfe-commits

Author: Guillaume Chatelet
Date: 2019-10-29T17:36:55+01:00
New Revision: 1c85a2e8dc7e76761d301f9a35374e0aafc757ec

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

LOG: isBuiltinFunc() uses StringRef instead of const char*

Summary: This prevents a bug when passing nullptr, StringRef ctor would call 
strlen(nullptr).

Reviewers: vlad.tsyrklevich

Subscribers: cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang/include/clang/Basic/Builtins.h
clang/lib/Basic/Builtins.cpp
clang/lib/Sema/SemaDeclAttr.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/Builtins.h 
b/clang/include/clang/Basic/Builtins.h
index fed0dae20193..af07d4241438 100644
--- a/clang/include/clang/Basic/Builtins.h
+++ b/clang/include/clang/Basic/Builtins.h
@@ -224,7 +224,7 @@ class Context {
 
   /// Returns true if this is a libc/libm function without the '__builtin_'
   /// prefix.
-  static bool isBuiltinFunc(const char *Name);
+  static bool isBuiltinFunc(llvm::StringRef Name);
 
   /// Returns true if this is a builtin that can be redeclared.  Returns true
   /// for non-builtins.

diff  --git a/clang/lib/Basic/Builtins.cpp b/clang/lib/Basic/Builtins.cpp
index d23c280d4758..0cd89df41b67 100644
--- a/clang/lib/Basic/Builtins.cpp
+++ b/clang/lib/Basic/Builtins.cpp
@@ -47,8 +47,7 @@ void Builtin::Context::InitializeTarget(const TargetInfo 
&Target,
 AuxTSRecords = AuxTarget->getTargetBuiltins();
 }
 
-bool Builtin::Context::isBuiltinFunc(const char *Name) {
-  StringRef FuncName(Name);
+bool Builtin::Context::isBuiltinFunc(llvm::StringRef FuncName) {
   for (unsigned i = Builtin::NotBuiltin + 1; i != Builtin::FirstTSBuiltin; ++i)
 if (FuncName.equals(BuiltinInfo[i].Name))
   return strchr(BuiltinInfo[i].Attributes, 'f') != nullptr;

diff  --git a/clang/lib/Sema/SemaDeclAttr.cpp b/clang/lib/Sema/SemaDeclAttr.cpp
index 99eb23c3fe61..7f68d2014916 100644
--- a/clang/lib/Sema/SemaDeclAttr.cpp
+++ b/clang/lib/Sema/SemaDeclAttr.cpp
@@ -1096,7 +1096,7 @@ static void handleNoBuiltinAttr(Sema &S, Decl *D, const 
ParsedAttr &AL) {
   if (!S.checkStringLiteralArgumentAttr(AL, I, BuiltinName, &LiteralLoc))
 return;
 
-  if (Builtin::Context::isBuiltinFunc(BuiltinName.data()))
+  if (Builtin::Context::isBuiltinFunc(BuiltinName))
 AddBuiltinName(BuiltinName);
   else
 S.Diag(LiteralLoc, 
diag::warn_attribute_no_builtin_invalid_builtin_name)



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


[PATCH] D69360: [NFC] Refactor representation of materialized temporaries

2019-10-29 Thread Gabor Marton via Phabricator via cfe-commits
martong added inline comments.
Herald added a subscriber: rnkovacs.



Comment at: clang/lib/AST/ASTImporter.cpp:7004
+  // FIXME: Should ManglingNumber get numbers associated with 'to' context?
+  auto* To = MaterializeTemporaryDecl::Create(Temporary, ExtendingDecl,
+  D->getManglingNumber());

Could you please use `GetImportedOrCreateDecl(...)` 
instead? We wrap every Decl creation in the ASTImporter so things that must be 
done right after creating a node is handled in one place.
Also, you can remove the next statement with `MapImported`.




Comment at: clang/lib/AST/ASTImporter.cpp:7021
   Expr *ToTemporaryExpr;
-  const ValueDecl *ToExtendingDecl;
-  std::tie(ToType, ToTemporaryExpr, ToExtendingDecl) = *Imp;
+  MaterializeTemporaryDecl *MaterialzedDecl;
+  std::tie(ToType, ToTemporaryExpr, MaterialzedDecl) = *Imp;

(An `i` is missing in `MaterialzedDecl`) And for consistency with the previous 
lines, perhaps it should be called as `ToMaterializedDecl`.


Repository:
  rC Clang

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

https://reviews.llvm.org/D69360



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


[PATCH] D69569: isBuiltinFunc() uses StringRef instead of const char*

2019-10-29 Thread Guillaume Chatelet via Phabricator via cfe-commits
gchatelet created this revision.
gchatelet added a reviewer: vlad.tsyrklevich.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
gchatelet edited the summary of this revision.

This prevents a bug when passing `nullptr`, `StringRef` ctor would call 
`strlen(nullptr)`.
This should fix 98f3151a7dded8838fafcb5f46e6c8358def96b8 
 breaking 
sanitizer-x86_64-linux-bootstrap-msan.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D69569

Files:
  clang/include/clang/Basic/Builtins.h
  clang/lib/Basic/Builtins.cpp
  clang/lib/Sema/SemaDeclAttr.cpp


Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -1096,7 +1096,7 @@
   if (!S.checkStringLiteralArgumentAttr(AL, I, BuiltinName, &LiteralLoc))
 return;
 
-  if (Builtin::Context::isBuiltinFunc(BuiltinName.data()))
+  if (Builtin::Context::isBuiltinFunc(BuiltinName))
 AddBuiltinName(BuiltinName);
   else
 S.Diag(LiteralLoc, 
diag::warn_attribute_no_builtin_invalid_builtin_name)
Index: clang/lib/Basic/Builtins.cpp
===
--- clang/lib/Basic/Builtins.cpp
+++ clang/lib/Basic/Builtins.cpp
@@ -47,8 +47,7 @@
 AuxTSRecords = AuxTarget->getTargetBuiltins();
 }
 
-bool Builtin::Context::isBuiltinFunc(const char *Name) {
-  StringRef FuncName(Name);
+bool Builtin::Context::isBuiltinFunc(llvm::StringRef FuncName) {
   for (unsigned i = Builtin::NotBuiltin + 1; i != Builtin::FirstTSBuiltin; ++i)
 if (FuncName.equals(BuiltinInfo[i].Name))
   return strchr(BuiltinInfo[i].Attributes, 'f') != nullptr;
Index: clang/include/clang/Basic/Builtins.h
===
--- clang/include/clang/Basic/Builtins.h
+++ clang/include/clang/Basic/Builtins.h
@@ -224,7 +224,7 @@
 
   /// Returns true if this is a libc/libm function without the '__builtin_'
   /// prefix.
-  static bool isBuiltinFunc(const char *Name);
+  static bool isBuiltinFunc(llvm::StringRef Name);
 
   /// Returns true if this is a builtin that can be redeclared.  Returns true
   /// for non-builtins.


Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -1096,7 +1096,7 @@
   if (!S.checkStringLiteralArgumentAttr(AL, I, BuiltinName, &LiteralLoc))
 return;
 
-  if (Builtin::Context::isBuiltinFunc(BuiltinName.data()))
+  if (Builtin::Context::isBuiltinFunc(BuiltinName))
 AddBuiltinName(BuiltinName);
   else
 S.Diag(LiteralLoc, diag::warn_attribute_no_builtin_invalid_builtin_name)
Index: clang/lib/Basic/Builtins.cpp
===
--- clang/lib/Basic/Builtins.cpp
+++ clang/lib/Basic/Builtins.cpp
@@ -47,8 +47,7 @@
 AuxTSRecords = AuxTarget->getTargetBuiltins();
 }
 
-bool Builtin::Context::isBuiltinFunc(const char *Name) {
-  StringRef FuncName(Name);
+bool Builtin::Context::isBuiltinFunc(llvm::StringRef FuncName) {
   for (unsigned i = Builtin::NotBuiltin + 1; i != Builtin::FirstTSBuiltin; ++i)
 if (FuncName.equals(BuiltinInfo[i].Name))
   return strchr(BuiltinInfo[i].Attributes, 'f') != nullptr;
Index: clang/include/clang/Basic/Builtins.h
===
--- clang/include/clang/Basic/Builtins.h
+++ clang/include/clang/Basic/Builtins.h
@@ -224,7 +224,7 @@
 
   /// Returns true if this is a libc/libm function without the '__builtin_'
   /// prefix.
-  static bool isBuiltinFunc(const char *Name);
+  static bool isBuiltinFunc(llvm::StringRef Name);
 
   /// Returns true if this is a builtin that can be redeclared.  Returns true
   /// for non-builtins.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D69569: isBuiltinFunc() uses StringRef instead of const char*

2019-10-29 Thread Guillaume Chatelet via Phabricator via cfe-commits
This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rG1c85a2e8dc7e: isBuiltinFunc() uses StringRef instead of 
const char* (authored by gchatelet).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69569

Files:
  clang/include/clang/Basic/Builtins.h
  clang/lib/Basic/Builtins.cpp
  clang/lib/Sema/SemaDeclAttr.cpp


Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -1096,7 +1096,7 @@
   if (!S.checkStringLiteralArgumentAttr(AL, I, BuiltinName, &LiteralLoc))
 return;
 
-  if (Builtin::Context::isBuiltinFunc(BuiltinName.data()))
+  if (Builtin::Context::isBuiltinFunc(BuiltinName))
 AddBuiltinName(BuiltinName);
   else
 S.Diag(LiteralLoc, 
diag::warn_attribute_no_builtin_invalid_builtin_name)
Index: clang/lib/Basic/Builtins.cpp
===
--- clang/lib/Basic/Builtins.cpp
+++ clang/lib/Basic/Builtins.cpp
@@ -47,8 +47,7 @@
 AuxTSRecords = AuxTarget->getTargetBuiltins();
 }
 
-bool Builtin::Context::isBuiltinFunc(const char *Name) {
-  StringRef FuncName(Name);
+bool Builtin::Context::isBuiltinFunc(llvm::StringRef FuncName) {
   for (unsigned i = Builtin::NotBuiltin + 1; i != Builtin::FirstTSBuiltin; ++i)
 if (FuncName.equals(BuiltinInfo[i].Name))
   return strchr(BuiltinInfo[i].Attributes, 'f') != nullptr;
Index: clang/include/clang/Basic/Builtins.h
===
--- clang/include/clang/Basic/Builtins.h
+++ clang/include/clang/Basic/Builtins.h
@@ -224,7 +224,7 @@
 
   /// Returns true if this is a libc/libm function without the '__builtin_'
   /// prefix.
-  static bool isBuiltinFunc(const char *Name);
+  static bool isBuiltinFunc(llvm::StringRef Name);
 
   /// Returns true if this is a builtin that can be redeclared.  Returns true
   /// for non-builtins.


Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -1096,7 +1096,7 @@
   if (!S.checkStringLiteralArgumentAttr(AL, I, BuiltinName, &LiteralLoc))
 return;
 
-  if (Builtin::Context::isBuiltinFunc(BuiltinName.data()))
+  if (Builtin::Context::isBuiltinFunc(BuiltinName))
 AddBuiltinName(BuiltinName);
   else
 S.Diag(LiteralLoc, diag::warn_attribute_no_builtin_invalid_builtin_name)
Index: clang/lib/Basic/Builtins.cpp
===
--- clang/lib/Basic/Builtins.cpp
+++ clang/lib/Basic/Builtins.cpp
@@ -47,8 +47,7 @@
 AuxTSRecords = AuxTarget->getTargetBuiltins();
 }
 
-bool Builtin::Context::isBuiltinFunc(const char *Name) {
-  StringRef FuncName(Name);
+bool Builtin::Context::isBuiltinFunc(llvm::StringRef FuncName) {
   for (unsigned i = Builtin::NotBuiltin + 1; i != Builtin::FirstTSBuiltin; ++i)
 if (FuncName.equals(BuiltinInfo[i].Name))
   return strchr(BuiltinInfo[i].Attributes, 'f') != nullptr;
Index: clang/include/clang/Basic/Builtins.h
===
--- clang/include/clang/Basic/Builtins.h
+++ clang/include/clang/Basic/Builtins.h
@@ -224,7 +224,7 @@
 
   /// Returns true if this is a libc/libm function without the '__builtin_'
   /// prefix.
-  static bool isBuiltinFunc(const char *Name);
+  static bool isBuiltinFunc(llvm::StringRef Name);
 
   /// Returns true if this is a builtin that can be redeclared.  Returns true
   /// for non-builtins.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D69569: isBuiltinFunc() uses StringRef instead of const char*

2019-10-29 Thread Vlad Tsyrklevich via Phabricator via cfe-commits
vlad.tsyrklevich added a comment.

Fix LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69569



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


[PATCH] D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK

2019-10-29 Thread Michał Górny via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
mgorny marked an inline comment as done.
Closed by commit rG2a0fcae3d4d1: [lld] [ELF] Add '-z nognustack' opt 
to suppress emitting PT_GNU_STACK (authored by mgorny).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D56554

Files:
  lld/ELF/Config.h
  lld/ELF/Driver.cpp
  lld/ELF/Writer.cpp
  lld/docs/ld.lld.1
  lld/test/ELF/gnustack.s

Index: lld/test/ELF/gnustack.s
===
--- lld/test/ELF/gnustack.s
+++ lld/test/ELF/gnustack.s
@@ -10,6 +10,9 @@
 # RUN: ld.lld %t1 -o %t -z noexecstack
 # RUN: llvm-readobj --program-headers -S %t | FileCheck --check-prefix=RW %s
 
+# RUN: ld.lld %t1 -o %t -z nognustack
+# RUN: llvm-readobj --program-headers -s %t | FileCheck --check-prefix=NOGNUSTACK %s
+
 # RW:  Type: PT_GNU_STACK
 # RW-NEXT: Offset: 0x0
 # RW-NEXT: VirtualAddress: 0x0
@@ -35,5 +38,7 @@
 # RWX-NEXT: ]
 # RWX-NEXT: Alignment: 0
 
+# NOGNUSTACK-NOT: Type: PT_GNU_STACK
+
 .globl _start
 _start:
Index: lld/docs/ld.lld.1
===
--- lld/docs/ld.lld.1
+++ lld/docs/ld.lld.1
@@ -655,6 +655,11 @@
 flag to indicate that the object may not be opened by
 .Xr dlopen 3 .
 .Pp
+.It Cm nognustack
+Do not emit the
+.Dv PT_GNU_STACK
+segment.
+.Pp
 .It Cm norelro
 Do not indicate that portions of the object shold be mapped read-only
 after initial relocation processing.
Index: lld/ELF/Writer.cpp
===
--- lld/ELF/Writer.cpp
+++ lld/ELF/Writer.cpp
@@ -2172,14 +2172,16 @@
   if (OutputSection *cmd = findSection(".openbsd.randomdata", partNo))
 addHdr(PT_OPENBSD_RANDOMIZE, cmd->getPhdrFlags())->add(cmd);
 
-  // PT_GNU_STACK is a special section to tell the loader to make the
-  // pages for the stack non-executable. If you really want an executable
-  // stack, you can pass -z execstack, but that's not recommended for
-  // security reasons.
-  unsigned perm = PF_R | PF_W;
-  if (config->zExecstack)
-perm |= PF_X;
-  addHdr(PT_GNU_STACK, perm)->p_memsz = config->zStackSize;
+  if (config->zGnustack != GnuStackKind::None) {
+// PT_GNU_STACK is a special section to tell the loader to make the
+// pages for the stack non-executable. If you really want an executable
+// stack, you can pass -z execstack, but that's not recommended for
+// security reasons.
+unsigned perm = PF_R | PF_W;
+if (config->zGnustack == GnuStackKind::Exec)
+  perm |= PF_X;
+addHdr(PT_GNU_STACK, perm)->p_memsz = config->zStackSize;
+  }
 
   // PT_OPENBSD_WXNEEDED is a OpenBSD-specific header to mark the executable
   // is expected to perform W^X violations, such as calling mprotect(2) or
Index: lld/ELF/Driver.cpp
===
--- lld/ELF/Driver.cpp
+++ lld/ELF/Driver.cpp
@@ -394,6 +394,20 @@
   return SeparateSegmentKind::None;
 }
 
+static GnuStackKind getZGnuStack(opt::InputArgList &args) {
+  for (auto *arg : args.filtered_reverse(OPT_z)) {
+if (StringRef("execstack") == arg->getValue())
+  return GnuStackKind::Exec;
+if (StringRef("noexecstack") == arg->getValue())
+  return GnuStackKind::NoExec;
+if (StringRef("nognustack") == arg->getValue())
+  return GnuStackKind::None;
+  }
+
+  // default
+  return GnuStackKind::NoExec;
+}
+
 static bool isKnownZFlag(StringRef s) {
   return s == "combreloc" || s == "copyreloc" || s == "defs" ||
  s == "execstack" || s == "global" || s == "hazardplt" ||
@@ -402,6 +416,7 @@
  s == "separate-code" || s == "separate-loadable-segments" ||
  s == "nocombreloc" || s == "nocopyreloc" || s == "nodefaultlib" ||
  s == "nodelete" || s == "nodlopen" || s == "noexecstack" ||
+ s == "nognustack" ||
  s == "nokeep-text-section-prefix" || s == "norelro" ||
  s == "noseparate-code" || s == "notext" || s == "now" ||
  s == "origin" || s == "relro" || s == "retpolineplt" ||
@@ -951,6 +966,7 @@
   config->zCopyreloc = getZFlag(args, "copyreloc", "nocopyreloc", true);
   config->zExecstack = getZFlag(args, "execstack", "noexecstack", false);
   config->zGlobal = hasZOption(args, "global");
+  config->zGnustack = getZGnuStack(args);
   config->zHazardplt = hasZOption(args, "hazardplt");
   config->zIfuncNoplt = hasZOption(args, "ifunc-noplt");
   config->zInitfirst = hasZOption(args, "initfirst");
Index: lld/ELF/Config.h
===
--- lld/ELF/Config.h
+++ lld/ELF/Config.h
@@ -64,6 +64,9 @@
 // For -z noseparate-code, -z separate-code and -z separate-loadable-segments.
 enum class SeparateSegmentKind { None, Code, Loadable };
 
+// For -z *stack
+enum class GnuStackKind { None, Exec, NoExec };
+
 struct SymbolVersion {
   llvm::StringRef name;
   bool isExtern

[PATCH] D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK

2019-10-29 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added inline comments.



Comment at: lld/ELF/Driver.cpp:357
+
+  // default
+  return GnuStackKind::NoExec;

mgorny wrote:
> MaskRay wrote:
> > MaskRay wrote:
> > > This is obvious. The comment can be removed.
> > Not done. `// default` can be deleted I think.
> You didn't give me time to upload updated patch ;-).
You had plenty of time updating the patch but you still committed without 
changing this part...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D56554



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


[PATCH] D56554: [ELF] Add '-z nognustack' opt to suppress emitting PT_GNU_STACK

2019-10-29 Thread Michał Górny via Phabricator via cfe-commits
mgorny marked an inline comment as done.
mgorny added inline comments.



Comment at: lld/ELF/Driver.cpp:357
+
+  // default
+  return GnuStackKind::NoExec;

MaskRay wrote:
> mgorny wrote:
> > MaskRay wrote:
> > > MaskRay wrote:
> > > > This is obvious. The comment can be removed.
> > > Not done. `// default` can be deleted I think.
> > You didn't give me time to upload updated patch ;-).
> You had plenty of time updating the patch but you still committed without 
> changing this part...
I'm really sorry, I thought I did that. You commented before I actually 
uploaded the new patch, and no comments afterwards got me confused.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D56554



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


[PATCH] D60220: [CUDA][Windows] Final fix for bug 38811 (Step 3 of 3)

2019-10-29 Thread Dimitry Andric via Phabricator via cfe-commits
dim added a comment.

Hm, I would really say that `__isnan` and the other `__` prefixed functions are 
Linuxisms, or more accurately, glibc-isms.  They also don't exist on e.g. macOS:

  $ cat check-isnan.cpp
  #include 
  
  int check_isnan(double d)
  {
return ::__isnan(d);
  }
  
  $ clang -v
  Apple clang version 11.0.0 (clang-1100.0.33.8)
  Target: x86_64-apple-darwin18.7.0
  Thread model: posix
  InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
  
  $ clang -c check-isnan.cpp
  check-isnan.cpp:5:12: error: no member named '__isnan' in the global 
namespace; did you mean 'isnan'?
return ::__isnan(d);
   ~~^~~
 isnan
  
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/math.h:519:1:
 note: 'isnan' declared here
  isnan(_A1 __lcpp_x) _NOEXCEPT
  ^
  1 error generated.

Why can't the regular `isnan` be used instead?  Or is this a CUDA-specific 
requirement?  (Apologies, but I know next to nothing about CUDA :) )


Repository:
  rC Clang

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

https://reviews.llvm.org/D60220



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


[PATCH] D68733: Use -fdebug-compilation-dir to form absolute paths in coverage mappings

2019-10-29 Thread Vedant Kumar via Phabricator via cfe-commits
vsk added a comment.

In D68733#1723734 , @liaoyuke wrote:

> In D68733#1702609 , @vsk wrote:
>
> > Thanks, lgtm!
> >
> > In PR43614 I mentioned adding an extra argument to llvm-cov to specify the 
> > base directory. On second thought, the existing `-path-equivalence` option 
> > should make that unnecessary.
>
>
> I just tested out this CL, and I don't think it's working correctly (even 
> with -path-equivalence flag)
>
> The command I used is:
>  
> /usr/local/google/home/liaoyuke/chromium/src/third_party/llvm-build/Release+Asserts/bin/llvm-cov
>  show -format=html 
> -output-dir=/usr/local/google/home/liaoyuke/chromium/src/out/output_test_path 
> -instr-profile=/usr/local/google/home/liaoyuke/chromium/src/out/output_test_path/linux/coverage.profdata
>  -path-equivalence=../..,/usr/local/google/home/liaoyuke/chromium/src 
> out/coverage/base_unittests


Hi @liaoyuke, thanks for trying this out.

> And the generated html files are as following: 
> https://imgur.com/gallery/dlgQXhy
>  Specifically, there are a few problems:
> 
> 1. The index.html files still show relative paths, but I'm expecting an 
> absolute path given that I passed in the -path-equivalence flag.

I have a question about the option you passed: 
`-path-equivalence=../..,`. If I read this patch correctly, the 
final coverage mapping will contain (what looks like) absolute paths which are 
just rooted at the debug compilation dir. So, why remap `../..` instead of 
``?

> 2. The file level line-by-line view's styling is completely off, there is no 
> table and no highlights.

Interesting. Have you confirmed that the issue does not reproduce without 
-fdebug-compilation-dir/-path-equivalence?

> 3. I also tried the "llvm-cov export" command, it seems that it doesn't 
> respect the -path-equivalence flag at all, and the produced json still uses 
> relative paths in them. (I'm guessing the root cause is the same as 1)

Hm, actually this could be a bug in llvm-cov. Reading through the source, it 
looks like the path remapping is done before the exporter is created, but 
perhaps I've missed something.

> Am I using the -path-equivalence flag correctly? And any other suggestions to 
> work this around?




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68733



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


[PATCH] D60220: [CUDA][Windows] Final fix for bug 38811 (Step 3 of 3)

2019-10-29 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

In D60220#1725633 , @dim wrote:

> Hm, I would really say that `__isnan` and the other `__` prefixed functions 
> are Linuxisms, or more accurately, glibc-isms.  They also don't exist on e.g. 
> macOS:
>
> Why can't the regular `isnan` be used instead?  Or is this a CUDA-specific 
> requirement?  (Apologies, but I know next to nothing about CUDA :) )


Well, that's what *CUDA* headers use, as written by NVIDIA. We have no control 
over them. :-(


Repository:
  rC Clang

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

https://reviews.llvm.org/D60220



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


[PATCH] D69498: IR: Invert convergent attribute handling

2019-10-29 Thread Marcello Maggioni via Phabricator via cfe-commits
kariddi added a comment.

In D69498#1725528 , @rjmccall wrote:

> It absolutely makes sense for Clang as a GPU-programming frontend to set 
> attributes appropriately when targeting the GPU.  I'm objecting to making 
> "convergence" and related "code layout is semantics" properties a universal 
> part of the IR semantics that literally every frontend has to know about in 
> order to get reasonable behavior from LLVM.  I know that doing so makes sense 
> to GPU backend developers because you mostly work exclusively on GPU 
> toolchains, but AFAIK there are half a dozen GPU frontends and they're all 
> forks of Clang, whereas there are dozens of LLVM frontends out there that 
> don't care about targeting the GPU and quite possibly never will.  (And even 
> if they do target GPUs, they often will not care about exposing thread 
> groups; many programming environments are just interested in taking advantage 
> of the GPU's parallel-computation power and have no interest in inter-thread 
> interference.)
>
> John.


I agree that the issue with making it "transparent" as a concept to whoever is 
not interested in programming models that have the concept of SIMD-wide 
execution is an open issue (not only related to this patch, but in general to 
the convergent idea as a whole, where writing a llvm pass that maintains 
convergence now is an extra burden to the developer of such pass that wasn't 
there before and that is probably completely orthogonal to the interest of the 
pass writer probably targeting C/C++ or other non-parallel languages). I opened 
some discussions going on the other related RFC for extending the concept of 
convergent to avoid hoisting as well regarding how are we gonna avoid burdening 
the LLVM community and maintain the invariants we want with respect to this 
concept.
I have no idea what the impact of the convergent attribute is in Clang (with 
the exception of adding the flag itself), but a lot of the heavy-lifting I know 
its in LVLM itself.

That said I just want to point out that some of these languages run on CPUs as 
well (like openCL ) and they share the same properties with respect to 
instructions that read execution masks of neighboring threads and making sure 
threads stay converged when executing them. It's certainly unfortunate that 
LLVM has some deficiencies in supporting these concepts and that the so far 
proposed solutions are not burden free for the rest of the community. :-/


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

https://reviews.llvm.org/D69498



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


[clang] efed314 - Revert "[clang-format] Remove the dependency on frontend"

2019-10-29 Thread Vlad Tsyrklevich via cfe-commits

Author: Vlad Tsyrklevich
Date: 2019-10-29T10:48:03-07:00
New Revision: efed314118c7c287a71b8a8d67953a98d8a718d5

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

LOG: Revert "[clang-format] Remove the dependency on frontend"

This reverts commit ec66603ac7ea655be5c2c5f508c5bf0d5eaeb65b. It was
causing ubsan failures like the following on the ubsan bot:
llvm/lib/Support/SourceMgr.cpp:440:48: runtime error: pointer index expression 
with base 0x overflowed to 0xfffa

Added: 


Modified: 
clang/tools/clang-format/CMakeLists.txt
clang/tools/clang-format/ClangFormat.cpp

Removed: 




diff  --git a/clang/tools/clang-format/CMakeLists.txt 
b/clang/tools/clang-format/CMakeLists.txt
index 35ecdb11253c..28ac4fb5913e 100644
--- a/clang/tools/clang-format/CMakeLists.txt
+++ b/clang/tools/clang-format/CMakeLists.txt
@@ -7,6 +7,7 @@ add_clang_tool(clang-format
 set(CLANG_FORMAT_LIB_DEPS
   clangBasic
   clangFormat
+  clangFrontend
   clangRewrite
   clangToolingCore
   )

diff  --git a/clang/tools/clang-format/ClangFormat.cpp 
b/clang/tools/clang-format/ClangFormat.cpp
index cbbb52bd0aa8..db00d41d0351 100644
--- a/clang/tools/clang-format/ClangFormat.cpp
+++ b/clang/tools/clang-format/ClangFormat.cpp
@@ -18,6 +18,7 @@
 #include "clang/Basic/SourceManager.h"
 #include "clang/Basic/Version.h"
 #include "clang/Format/Format.h"
+#include "clang/Frontend/TextDiagnosticPrinter.h"
 #include "clang/Rewrite/Core/Rewriter.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/FileSystem.h"
@@ -299,9 +300,12 @@ emitReplacementWarnings(const Replacements &Replaces, 
StringRef AssumedFileName,
   IntrusiveRefCntPtr DiagOpts = new DiagnosticOptions();
   DiagOpts->ShowColors = (ShowColors && !NoShowColors);
 
+  TextDiagnosticPrinter *DiagsBuffer =
+  new TextDiagnosticPrinter(llvm::errs(), &*DiagOpts, false);
+
   IntrusiveRefCntPtr DiagID(new DiagnosticIDs());
   IntrusiveRefCntPtr Diags(
-  new DiagnosticsEngine(DiagID, &*DiagOpts));
+  new DiagnosticsEngine(DiagID, &*DiagOpts, DiagsBuffer));
 
   IntrusiveRefCntPtr InMemoryFileSystem(
   new llvm::vfs::InMemoryFileSystem);
@@ -310,40 +314,24 @@ emitReplacementWarnings(const Replacements &Replaces, 
StringRef AssumedFileName,
   FileID FileID = createInMemoryFile(AssumedFileName, Code.get(), Sources,
  Files, InMemoryFileSystem.get());
 
-  FileManager &FileMgr = Sources.getFileManager();
-  llvm::ErrorOr FileEntryPtr =
-  FileMgr.getFile(AssumedFileName);
+  const unsigned ID = Diags->getCustomDiagID(
+  WarningsAsErrors ? clang::DiagnosticsEngine::Error
+   : clang::DiagnosticsEngine::Warning,
+  "code should be clang-formatted [-Wclang-format-violations]");
 
   unsigned Errors = 0;
+  DiagsBuffer->BeginSourceFile(LangOptions(), nullptr);
   if (WarnFormat && !NoWarnFormat) {
 for (const auto &R : Replaces) {
-  PresumedLoc PLoc = Sources.getPresumedLoc(
-  
Sources.getLocForStartOfFile(FileID).getLocWithOffset(R.getOffset()));
-
-  SourceLocation LineBegin =
-  Sources.translateFileLineCol(FileEntryPtr.get(), PLoc.getLine(), 1);
-  SourceLocation NextLineBegin = Sources.translateFileLineCol(
-  FileEntryPtr.get(), PLoc.getLine() + 1, 1);
-
-  const char *StartBuf = Sources.getCharacterData(LineBegin);
-  const char *EndBuf = Sources.getCharacterData(NextLineBegin);
-
-  StringRef Line(StartBuf, (EndBuf - StartBuf) - 1);
-
-  SMDiagnostic Diags(
-  llvm::SourceMgr(), SMLoc(), AssumedFileName, PLoc.getLine(),
-  PLoc.getColumn(),
-  WarningsAsErrors ? SourceMgr::DiagKind::DK_Error
-   : SourceMgr::DiagKind::DK_Warning,
-  "code should be clang-formatted [-Wclang-format-violations]", Line,
-  ArrayRef>());
-
-  Diags.print(nullptr, llvm::errs(), (ShowColors && !NoShowColors));
+  Diags->Report(
+  Sources.getLocForStartOfFile(FileID).getLocWithOffset(R.getOffset()),
+  ID);
   Errors++;
   if (ErrorLimit && Errors >= ErrorLimit)
 break;
 }
   }
+  DiagsBuffer->EndSourceFile();
   return WarningsAsErrors;
 }
 



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


Re: [clang] ec66603 - [clang-format] Remove the dependency on frontend

2019-10-29 Thread Vlad Tsyrklevich via cfe-commits
I've reverted this commit as it was causing UBSan failures on the ubsan
bot. These failures looked like:
llvm/lib/Support/SourceMgr.cpp:440:48: runtime error: pointer index
expression with base 0x overflowed to 0xfffa

Looking at a backtrace, this line was reached from the
`Diags.print(nullptr, llvm::errs(), (ShowColors && !NoShowColors));` call
introduced in this change.

I apologize for the delay in this revert, normally reverts happen in under
a day but in this case this change was committed right as we switched to
GitHub and it took a while to get the sanitizers buildbots working properly
and track down failures.

On Thu, Oct 24, 2019 at 11:17 AM via cfe-commits 
wrote:

>
> Author: paulhoad
> Date: 2019-10-24T19:03:57+01:00
> New Revision: ec66603ac7ea655be5c2c5f508c5bf0d5eaeb65b
>
> URL:
> https://github.com/llvm/llvm-project/commit/ec66603ac7ea655be5c2c5f508c5bf0d5eaeb65b
> DIFF:
> https://github.com/llvm/llvm-project/commit/ec66603ac7ea655be5c2c5f508c5bf0d5eaeb65b.diff
>
> LOG: [clang-format] Remove the dependency on frontend
>
> Summary:
> Address review comments from {D68554} by trying to drop the dependency
> again on Frontend whilst keeping the same format diagnostic messages
>
> Not completely happy with having to do a split in order to get the
> StringRef for the Line the error occurred on, but could see a way to use
> SourceManager and SourceLocation to give me a single line?
>
> But this removes the dependency on frontend which should keep the binary
> size down.
>
> Reviewers: thakis, klimek, mitchell-stellar
>
> Reviewed By: klimek
>
> Subscribers: mgorny, cfe-commits
>
> Tags: #clang, #clang-format
>
> Differential Revision: https://reviews.llvm.org/D68969
>
> Added:
>
>
> Modified:
> clang/tools/clang-format/CMakeLists.txt
> clang/tools/clang-format/ClangFormat.cpp
>
> Removed:
>
>
>
>
> 
> diff  --git a/clang/tools/clang-format/CMakeLists.txt
> b/clang/tools/clang-format/CMakeLists.txt
> index 28ac4fb5913e..35ecdb11253c 100644
> --- a/clang/tools/clang-format/CMakeLists.txt
> +++ b/clang/tools/clang-format/CMakeLists.txt
> @@ -7,7 +7,6 @@ add_clang_tool(clang-format
>  set(CLANG_FORMAT_LIB_DEPS
>clangBasic
>clangFormat
> -  clangFrontend
>clangRewrite
>clangToolingCore
>)
>
> diff  --git a/clang/tools/clang-format/ClangFormat.cpp
> b/clang/tools/clang-format/ClangFormat.cpp
> index f39c18bae3ff..a10541d88f07 100644
> --- a/clang/tools/clang-format/ClangFormat.cpp
> +++ b/clang/tools/clang-format/ClangFormat.cpp
> @@ -18,7 +18,6 @@
>  #include "clang/Basic/SourceManager.h"
>  #include "clang/Basic/Version.h"
>  #include "clang/Format/Format.h"
> -#include "clang/Frontend/TextDiagnosticPrinter.h"
>  #include "clang/Rewrite/Core/Rewriter.h"
>  #include "llvm/Support/CommandLine.h"
>  #include "llvm/Support/FileSystem.h"
> @@ -325,12 +324,9 @@ emitReplacementWarnings(const Replacements &Replaces,
> StringRef AssumedFileName,
>IntrusiveRefCntPtr DiagOpts = new
> DiagnosticOptions();
>DiagOpts->ShowColors = (ShowColors && !NoShowColors);
>
> -  TextDiagnosticPrinter *DiagsBuffer =
> -  new TextDiagnosticPrinter(llvm::errs(), &*DiagOpts, false);
> -
>IntrusiveRefCntPtr DiagID(new DiagnosticIDs());
>IntrusiveRefCntPtr Diags(
> -  new DiagnosticsEngine(DiagID, &*DiagOpts, DiagsBuffer));
> +  new DiagnosticsEngine(DiagID, &*DiagOpts));
>
>IntrusiveRefCntPtr InMemoryFileSystem(
>new llvm::vfs::InMemoryFileSystem);
> @@ -339,24 +335,40 @@ emitReplacementWarnings(const Replacements
> &Replaces, StringRef AssumedFileName,
>FileID FileID = createInMemoryFile(AssumedFileName, Code.get(), Sources,
>   Files, InMemoryFileSystem.get());
>
> -  const unsigned ID = Diags->getCustomDiagID(
> -  WarningsAsErrors ? clang::DiagnosticsEngine::Error
> -   : clang::DiagnosticsEngine::Warning,
> -  "code should be clang-formatted [-Wclang-format-violations]");
> +  FileManager &FileMgr = Sources.getFileManager();
> +  llvm::ErrorOr FileEntryPtr =
> +  FileMgr.getFile(AssumedFileName);
>
>unsigned Errors = 0;
> -  DiagsBuffer->BeginSourceFile(LangOptions(), nullptr);
>if (WarnFormat && !NoWarnFormat) {
>  for (const auto &R : Replaces) {
> -  Diags->Report(
> -
> Sources.getLocForStartOfFile(FileID).getLocWithOffset(R.getOffset()),
> -  ID);
> +  PresumedLoc PLoc = Sources.getPresumedLoc(
> +
> Sources.getLocForStartOfFile(FileID).getLocWithOffset(R.getOffset()));
> +
> +  SourceLocation LineBegin =
> +  Sources.translateFileLineCol(FileEntryPtr.get(),
> PLoc.getLine(), 1);
> +  SourceLocation NextLineBegin = Sources.translateFileLineCol(
> +  FileEntryPtr.get(), PLoc.getLine() + 1, 1);
> +
> +  const char *StartBuf = Sources.getCharacterData(LineBegin);
> +  const char *EndBuf = Sources.getCharacterData(NextLineBegi

[PATCH] D69573: [clang-format] [PR36294] AlwaysBreakAfterReturnType works incorrectly for some operator functions

2019-10-29 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay created this revision.
MyDeveloperDay added reviewers: mitchell-stellar, klimek, owenpan, sammccall.
MyDeveloperDay added projects: clang-format, clang-tools-extra.
Herald added a project: clang.

https://bugs.llvm.org/show_bug.cgi?id=36294

Addressing bug related to returning after return type not being honoured for 
some operator types.

  $ bin/clang-format --style="{BasedOnStyle: llvm, AlwaysBreakAfterReturnType: 
TopLevelDefinitions}" /tmp/foo.cpp
  class Foo {
  public:
bool operator!() const;
bool operator<(Foo const &) const;
bool operator*() const;
bool operator->() const;
bool operator+() const;
bool operator-() const;
bool f() const;
  };
  
  bool Foo::operator!() const { return true; }
  bool
  Foo::operator<(Foo const &) const {
return true;
  }
  bool Foo::operator*() const { return true; }
  bool Foo::operator->() const { return true; }
  bool
  Foo::operator+() const {
return true;
  }
  bool
  Foo::operator-() const {
return true;
  }
  bool
  Foo::f() const {
return true;
  }


Repository:
  rC Clang

https://reviews.llvm.org/D69573

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


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -6111,7 +6111,13 @@
"void\n"
"A::operator>>() {}\n"
"void\n"
-   "A::operator+() {}\n",
+   "A::operator+() {}\n"
+   "void\n"
+   "A::operator*() {}\n"
+   "void\n"
+   "A::operator->() {}\n"
+   "void\n"
+   "A::operator!() {}\n",
Style);
   verifyFormat("void *operator new(std::size_t s);", // No break here.
Style);
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -1344,8 +1344,10 @@
 Contexts.back().IsExpression = false;
 } else if (Current.is(tok::kw_new)) {
   Contexts.back().CanBeExpression = false;
-} else if (Current.isOneOf(tok::semi, tok::exclaim)) {
+} else if (Current.isOneOf(tok::semi, tok::exclaim) &&
+   !(Current.Previous && Current.Previous->is(tok::kw_operator))) {
   // This should be the condition or increment in a for-loop.
+  // but not operator !()
   Contexts.back().IsExpression = true;
 }
   }
@@ -2085,6 +2087,8 @@
 return Next;
   if (Next->is(TT_OverloadedOperator))
 continue;
+  if (Next->isOneOf(tok::star, tok::arrow))
+continue;
   if (Next->isOneOf(tok::kw_new, tok::kw_delete)) {
 // For 'new[]' and 'delete[]'.
 if (Next->Next && Next->Next->is(tok::l_square) && Next->Next->Next &&


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -6111,7 +6111,13 @@
"void\n"
"A::operator>>() {}\n"
"void\n"
-   "A::operator+() {}\n",
+   "A::operator+() {}\n"
+   "void\n"
+   "A::operator*() {}\n"
+   "void\n"
+   "A::operator->() {}\n"
+   "void\n"
+   "A::operator!() {}\n",
Style);
   verifyFormat("void *operator new(std::size_t s);", // No break here.
Style);
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -1344,8 +1344,10 @@
 Contexts.back().IsExpression = false;
 } else if (Current.is(tok::kw_new)) {
   Contexts.back().CanBeExpression = false;
-} else if (Current.isOneOf(tok::semi, tok::exclaim)) {
+} else if (Current.isOneOf(tok::semi, tok::exclaim) &&
+   !(Current.Previous && Current.Previous->is(tok::kw_operator))) {
   // This should be the condition or increment in a for-loop.
+  // but not operator !()
   Contexts.back().IsExpression = true;
 }
   }
@@ -2085,6 +2087,8 @@
 return Next;
   if (Next->is(TT_OverloadedOperator))
 continue;
+  if (Next->isOneOf(tok::star, tok::arrow))
+continue;
   if (Next->isOneOf(tok::kw_new, tok::kw_delete)) {
 // For 'new[]' and 'delete[]'.
 if (Next->Next && Next->Next->is(tok::l_square) && Next->Next->Next &&
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D60220: [CUDA][Windows] Final fix for bug 38811 (Step 3 of 3)

2019-10-29 Thread Evgeny Mankov via Phabricator via cfe-commits
emankov added a comment.

In D60220#1725633 , @dim wrote:

>   $ cat check-isnan.cpp
>   #include 
>  
>   int check_isnan(double d)
>   {
> return ::__isnan(d);
>   }
>   $ clang -c check-isnan.cpp
>   Why can't the regular `isnan` be used instead?  Or is this a CUDA-specific 
> requirement?  (Apologies, but I know next to nothing about CUDA :) )




1. `#include "cuda_runtime.h"`
2. as long as `__isnan` is a devide function, it should be called from 
`__devide__` or `__global__` function
3. `clang -c check-isnan.cpp -x cuda`


Repository:
  rC Clang

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

https://reviews.llvm.org/D60220



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


[PATCH] D69574: Remove lazy thread-initialisation

2019-10-29 Thread Matthew Malcomson via Phabricator via cfe-commits
mmalcomson created this revision.
mmalcomson added reviewers: eugenis, pcc, Sanitizers.
mmalcomson added a project: Sanitizers.
Herald added subscribers: llvm-commits, cfe-commits, jfb, hiraditya, srhines.
Herald added projects: clang, LLVM.

As I asked in the comments of https://reviews.llvm.org/D69199, if we're no 
longer accounting for the late-binding feature then I believe we can remove 
this lazy thread initialisation complexity.
I've tested with clang and gcc on linux that various threading programs work as 
expected.

Remove lazy thread initialisation

This was an experiment made possible by a non-standard feature of the Android
dynamic loader.

It required introducing a flag to tell the compiler which ABI was being 
targeted.
This flag is no longer needed, since the generated code now works for both 
ABI's.

We leave that flag untouched for backwards compatibility.  This also means that
if we need to distinguish between targeted ABI's again we can do that without
disturbing any existing workflows.

We leave a comment in the source code and mention in the help text to explain
this for any confused person reading the code in the future.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D69574

Files:
  clang/include/clang/Driver/Options.td
  compiler-rt/lib/hwasan/hwasan_interceptors.cpp
  compiler-rt/lib/hwasan/hwasan_linux.cpp
  llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
  llvm/test/Instrumentation/HWAddressSanitizer/lazy-thread-init.ll

Index: llvm/test/Instrumentation/HWAddressSanitizer/lazy-thread-init.ll
===
--- llvm/test/Instrumentation/HWAddressSanitizer/lazy-thread-init.ll
+++ /dev/null
@@ -1,39 +0,0 @@
-; RUN: opt -S -hwasan < %s | FileCheck %s
-
-target triple = "aarch64--linux-android"
-
-declare i32 @bar([16 x i32]* %p)
-
-define void @alloca() sanitize_hwaddress "hwasan-abi"="interceptor" {
-  ; CHECK: alloca [16 x i32]
-  ; CHECK: [[A:%[^ ]*]] = call i8* @llvm.thread.pointer()
-  ; CHECK: [[B:%[^ ]*]] = getelementptr i8, i8* [[A]], i32 48
-  ; CHECK: [[C:%[^ ]*]] = bitcast i8* [[B]] to i64*
-  ; CHECK: [[LOAD:%[^ ]*]] = load i64, i64* [[C]]
-  ; CHECK: [[ICMP:%[^ ]*]] = icmp eq i64 [[LOAD]], 0
-  ; CHECK: br i1 [[ICMP]], label %[[INIT:[^,]*]], label %[[CONT:[^,]*]], !prof [[PROF:![0-9]+]]
-
-  ; CHECK: [[INIT]]:
-  ; CHECK: call void @__hwasan_thread_enter()
-  ; CHECK: [[RELOAD:%[^ ]*]] = load i64, i64* [[C]]
-  ; CHECK: br label %[[CONT]]
-
-  ; CHECK: [[CONT]]:
-  ; CHECK: phi i64 [ [[LOAD]], %0 ], [ [[RELOAD]], %[[INIT]] ]
-  ; CHECK: alloca i8
-
-  %p = alloca [16 x i32]
-  %size = call i32 @bar([16 x i32]* %p)
-  %q = alloca i8, i32 %size
-  ret void
-}
-
-define i32 @load(i32* %p) sanitize_hwaddress "hwasan-abi"="interceptor" {
-  ; CHECK: [[SHADOW:%[^ ]*]] = call i8* asm "", "=r,0"([0 x i8]* @__hwasan_shadow)
-  ; CHECK-NOT: icmp
-  ; CHECK: call void @llvm.hwasan.check.memaccess(i8* [[SHADOW]],
-  %v = load i32, i32* %p
-  ret i32 %v
-}
-
-; CHECK: [[PROF]] = !{!"branch_weights", i32 1, i32 10}
Index: llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
===
--- llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
+++ llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
@@ -284,7 +284,6 @@
 
   FunctionCallee HwasanTagMemoryFunc;
   FunctionCallee HwasanGenerateTagFunc;
-  FunctionCallee HwasanThreadEnterFunc;
 
   Constant *ShadowGlobal;
 
@@ -473,9 +472,6 @@
 
   HWAsanHandleVfork =
   M.getOrInsertFunction("__hwasan_handle_vfork", IRB.getVoidTy(), IntptrTy);
-
-  HwasanThreadEnterFunc =
-  M.getOrInsertFunction("__hwasan_thread_enter", IRB.getVoidTy());
 }
 
 Value *HWAddressSanitizer::getDynamicShadowIfunc(IRBuilder<> &IRB) {
@@ -934,34 +930,13 @@
   Value *SlotPtr = getHwasanThreadSlotPtr(IRB, IntptrTy);
   assert(SlotPtr);
 
-  Instruction *ThreadLong = IRB.CreateLoad(IntptrTy, SlotPtr);
-
-  Function *F = IRB.GetInsertBlock()->getParent();
-  if (F->getFnAttribute("hwasan-abi").getValueAsString() == "interceptor") {
-Value *ThreadLongEqZero =
-IRB.CreateICmpEQ(ThreadLong, ConstantInt::get(IntptrTy, 0));
-auto *Br = cast(SplitBlockAndInsertIfThen(
-ThreadLongEqZero, cast(ThreadLongEqZero)->getNextNode(),
-false, MDBuilder(*C).createBranchWeights(1, 10)));
-
-IRB.SetInsertPoint(Br);
-// FIXME: This should call a new runtime function with a custom calling
-// convention to avoid needing to spill all arguments here.
-IRB.CreateCall(HwasanThreadEnterFunc);
-LoadInst *ReloadThreadLong = IRB.CreateLoad(IntptrTy, SlotPtr);
-
-IRB.SetInsertPoint(&*Br->getSuccessor(0)->begin());
-PHINode *ThreadLongPhi = IRB.CreatePHI(IntptrTy, 2);
-ThreadLongPhi->addIncoming(ThreadLong, ThreadLong->getParent());
-ThreadLongPhi->addIncoming(ReloadThreadLong, ReloadThreadLong->getParent());
-ThreadLong = ThreadLongPhi;
-  }
-
+  Value *

[PATCH] D69574: Remove lazy thread-initialisation

2019-10-29 Thread Evgenii Stepanov via Phabricator via cfe-commits
eugenis added a comment.

LGTM keeping the flag looks like the right thing to do.
I'll leave this for @pcc to accept.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69574



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


[PATCH] D69478: [Sema] Allow warnStackExhausted to show more info

2019-10-29 Thread Mark de Wever via Phabricator via cfe-commits
Mordante added a comment.

@rsmith also doesn't like the approach `runWithSufficientStackSpace` in D69479 
. So I'll try to use a different approach. If 
that succeeds I have no use case for this patch and will probably abandon it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69478



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


[PATCH] D69479: [Sema] Warn about possible stack exhaution

2019-10-29 Thread Mark de Wever via Phabricator via cfe-commits
Mordante added a comment.

I'll look at a worklist first, before fixing the other issues. However it seems 
it's not as trivial as I hoped. The recursion occurs in the `SequenceChecker` 
which has a `WorkList` but that's not used for this part. I'll try to find a 
solution.


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

https://reviews.llvm.org/D69479



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


[PATCH] D69573: [clang-format] [PR36294] AlwaysBreakAfterReturnType works incorrectly for some operator functions

2019-10-29 Thread Sam McCall via Phabricator via cfe-commits
sammccall added inline comments.



Comment at: clang/lib/Format/TokenAnnotator.cpp:1347
   Contexts.back().CanBeExpression = false;
-} else if (Current.isOneOf(tok::semi, tok::exclaim)) {
+} else if (Current.isOneOf(tok::semi, tok::exclaim) &&
+   !(Current.Previous && Current.Previous->is(tok::kw_operator))) {

This seems clearer as `is semi || (is exclaim && !previous is operator)`, as 
`operator;` isn't relevant here.
`&& !Current.is(TT_OverloadedOperator) would be even better of course`



Comment at: clang/lib/Format/TokenAnnotator.cpp:2090
 continue;
+  if (Next->isOneOf(tok::star, tok::arrow))
+continue;

This seems like it's supposed to be handled by the token annotator, and the 
same cause will result in bugs in other places - why aren't these tokens being 
marked as TT_OverloadedOperator?

I'd guess the deeper fix is in the `kw_operator` case in consumeToken(). The 
way it's written looks suspect, though I'm not an expert on any of this.


Repository:
  rC Clang

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

https://reviews.llvm.org/D69573



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


[PATCH] D69435: [clang-tidy] New checker performance-trivially-destructible-check

2019-10-29 Thread Anton Bikineev via Phabricator via cfe-commits
AntonBikineev added a comment.

Does anybody have suggestions on this?


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

https://reviews.llvm.org/D69435



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


[PATCH] D69577: [clang-format] [PR35518] C++17 deduction guides are wrongly formatted

2019-10-29 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay created this revision.
MyDeveloperDay added reviewers: klimek, mitchell-stellar, owenpan, sammccall.
MyDeveloperDay added projects: clang-format, clang-tools-extra.
Herald added a project: clang.

see https://bugs.llvm.org/show_bug.cgi?id=35518

clang-format removes spaces around deduction guides but not trailing return 
types, make the consistent

  template  S(T)->S;
  auto f(int, int) -> double;

becomes

  template  S(T) -> S;
  auto f(int, int) -> double;




Repository:
  rC Clang

https://reviews.llvm.org/D69577

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


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -4977,6 +4977,15 @@
   verifyFormat("void f() { auto a = b->c(); }");
 }
 
+TEST_F(FormatTest, DeductionGuides) {
+  verifyFormat("template  A(const T &, const T &) -> A;");
+  verifyFormat("template  explicit A(T &, T &&) -> A;");
+  verifyFormat("template  S(Ts...) -> S;");
+  verifyFormat(
+  "template \n"
+  "array(T &&... t) -> array, sizeof...(T)>;");
+}
+
 TEST_F(FormatTest, BreaksFunctionDeclarationsWithTrailingTokens) {
   // Avoid breaking before trailing 'const' or other trailing annotations, if
   // they are not function-like.
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -2932,6 +2932,16 @@
 return Right.is(TT_TemplateCloser) && Left.is(TT_TemplateCloser) &&
(Style.Standard < FormatStyle::LS_Cpp11 || Style.SpacesInAngles);
   }
+
+  // Deduction guides add a space around the arrow  "...) -> A".
+  if (Left.is(tok::r_paren) &&
+  Right.startsSequence(tok::arrow, TT_TrailingAnnotation,
+   TT_TemplateOpener))
+return true;
+  if (Left.is(tok::arrow) &&
+  Right.startsSequence(TT_TrailingAnnotation, TT_TemplateOpener))
+return true;
+
   if (Right.isOneOf(tok::arrow, tok::arrowstar, tok::periodstar) ||
   Left.isOneOf(tok::arrow, tok::period, tok::arrowstar, tok::periodstar) ||
   (Right.is(tok::period) && Right.isNot(TT_DesignatedInitializerPeriod)))


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -4977,6 +4977,15 @@
   verifyFormat("void f() { auto a = b->c(); }");
 }
 
+TEST_F(FormatTest, DeductionGuides) {
+  verifyFormat("template  A(const T &, const T &) -> A;");
+  verifyFormat("template  explicit A(T &, T &&) -> A;");
+  verifyFormat("template  S(Ts...) -> S;");
+  verifyFormat(
+  "template \n"
+  "array(T &&... t) -> array, sizeof...(T)>;");
+}
+
 TEST_F(FormatTest, BreaksFunctionDeclarationsWithTrailingTokens) {
   // Avoid breaking before trailing 'const' or other trailing annotations, if
   // they are not function-like.
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -2932,6 +2932,16 @@
 return Right.is(TT_TemplateCloser) && Left.is(TT_TemplateCloser) &&
(Style.Standard < FormatStyle::LS_Cpp11 || Style.SpacesInAngles);
   }
+
+  // Deduction guides add a space around the arrow  "...) -> A".
+  if (Left.is(tok::r_paren) &&
+  Right.startsSequence(tok::arrow, TT_TrailingAnnotation,
+   TT_TemplateOpener))
+return true;
+  if (Left.is(tok::arrow) &&
+  Right.startsSequence(TT_TrailingAnnotation, TT_TemplateOpener))
+return true;
+
   if (Right.isOneOf(tok::arrow, tok::arrowstar, tok::periodstar) ||
   Left.isOneOf(tok::arrow, tok::period, tok::arrowstar, tok::periodstar) ||
   (Right.is(tok::period) && Right.isNot(TT_DesignatedInitializerPeriod)))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D69498: IR: Invert convergent attribute handling

2019-10-29 Thread Mehdi AMINI via Phabricator via cfe-commits
mehdi_amini added a comment.

Maybe we can start by looking into the motivation for this patch:

> There is a burden on frontends in environments that care about convergent 
> operations to add the attribute just in case it is needed. This has proven to 
> be somewhat problematic, and different frontend projects have consistently 
> run into problems related to this.

Can you clarify what kind of problems? Do you have concrete examples?


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

https://reviews.llvm.org/D69498



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


Re: [llvm-dev] Zorg migration to GitHub/monorepo

2019-10-29 Thread Galina Kistanova via cfe-commits
Thanks for explaining, Diana.
And you are welcome. I’m glad this is not an issue with missing
changes or something.

Thanks

Galina

On Tue, Oct 29, 2019 at 1:48 AM Diana Picus  wrote:
>
> Hi Galina,
>
> On Tue, 29 Oct 2019 at 04:42, Galina Kistanova  wrote:
> >
> > Hello Nemanja,
> >
> > > a commit to a project that shouldn't trigger builds on a libcxx bot (i.e. 
> > > the change was in llvm).
> >
> > With all due respect, this does not sound right.
> > I'm not sure how changes in a code a particular bot builds and tests
> > should not trigger builds. In many cases this will lead to false blame
> > lists, which is very annoying for developers, and hurt a quality of a
> > bot. Could somebody elaborate a valid use case for this, please? If
> > this is what Diana meant, of course.
>
> Yes, this is what I meant. In the past, we only triggered builds for
> commits to libcxx, libcxxabi and libunwind. E.g.
> http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-armv7-linux/builds/1048
>
> So I actually thought the bots were building without checking out
> llvm. I now realize I was wrong and they did pull and build llvm as
> well, so I guess the previous behaviour was buggy. Thanks for helping
> us clarify this issue!
>
> Cheers,
> Diana
>
> > > I have a somewhat orthogonal but related question. In the past, commits 
> > > to compiler-rt did not trigger builds on llvm/clang/sanitizer bots. Has 
> > > this behaviour been rectified with the move to github?
> >
> > Before the move we had a set of schedulers with manually specified
> > list of projects to listen and assigned per group of bots. This was an
> > error prone as people were adding bots without realizing that a group
> > they add a bot to does not listen for a changes in some of the
> > projects that particular bot depends on. You have mentioned an example
> > of such issues.
> >
> > Now we use the dependency list for each of the monorepo-ready build
> > factory (depends_on_projects param) to figure out what changes should
> > trigger a build, as well as to configure the "-DLLVM_ENABLE_PROJECTS="
> > cmake arg. The dependency list could be redefined per builder, if for
> > any reason a build factory default doesn't work well. All the
> > schedulers are configured automatically and every bot is served with
> > changes to any and all projects it claims a dependency on. This should
> > give a better and transparent way to define and track what would and
> > what would not trigger a build. This is the idea at least. Some work
> > remains to be done as not all of the build factories let redefine the
> > dependency list yet, not all set "-DLLVM_ENABLE_PROJECTS=" properly,
> > and such.
> >
> > Thanks
> >
> > Galina
> >
> > On Mon, Oct 28, 2019 at 5:09 PM Nemanja Ivanovic
> >  wrote:
> > >
> > > I think what she is referring to was that the build seemed to be 
> > > triggered by a commit to a project that shouldn't trigger builds on a 
> > > libcxx bot (i.e. the change was in llvm).
> > >
> > > I have a somewhat orthogonal but related question. In the past, commits 
> > > to compiler-rt did not trigger builds on llvm/clang/sanitizer bots. Has 
> > > this behaviour been rectified with the move to github? I am really sorry 
> > > if you already answered this question and I just missed it.
> > >
> > > On Mon, Oct 28, 2019 at 2:37 PM Galina Kistanova via llvm-dev 
> > >  wrote:
> > >>
> > >> Hi Diana,
> > >>
> > >> It is not clear from your description of what is the problem. Could
> > >> you elaborate, please?
> > >>
> > >> I have looked at the build history closer and see that this build
> > >> configuration depends on libcxx, libcxxabi, libunwind, llvm projects,
> > >> and changes to any of these would trigger a build. Depending on a bot
> > >> performance, patches could be grouped to a longer blame list. To me,
> > >> this is exactly how it supposedly should be. Are you missing any
> > >> particular changes in libcxx, libcxxabi,or libunwind project which
> > >> should trigger a build but they didn't? If so, could you point me to
> > >> such change, please?
> > >>
> > >> Thanks
> > >>
> > >> Galina
> > >>
> > >>
> > >>
> > >> On Mon, Oct 28, 2019 at 5:16 AM Diana Picus  
> > >> wrote:
> > >> >
> > >> > Hi Galina,
> > >> >
> > >> > It seems that our libcxx bots are now triggering builds for any 
> > >> > changes to llvm:
> > >> > http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux/builds/2434
> > >> >
> > >> > Should I file a bug report for this?
> > >> >
> > >> > Thanks,
> > >> > Diana
> > >> >
> > >> > On Sat, 19 Oct 2019 at 11:36, Galina Kistanova via cfe-commits
> > >> >  wrote:
> > >> > >
> > >> > > Hello everyone,
> > >> > >
> > >> > > The staging master is ready to accept bots from the list I have sent 
> > >> > > yesterday. Don't wait too long.
> > >> > >
> > >> > > The master has been updated and works with both SVN and Github 
> > >> > > monorepo now.
> > >> > >
> > >> > > The following builders are already listening for chan

[PATCH] D68912: Adds -Wrange-loop-analysis to -Wall

2019-10-29 Thread Mark de Wever via Phabricator via cfe-commits
Mordante added a comment.

In D68912#1723722 , @aaron.ballman 
wrote:

> In D68912#1723691 , @xbolva00 wrote:
>
> > >> Does this analysis require CFG support
> >
> > https://reviews.llvm.org/D69292 also requires CFG support.
>
>
> Yes, it does.
>
> > Generally, is CFG support ok for -Wall if the warning has few false 
> > positives?
>
> I think it also depends on the performance of the diagnostic.
>
> >>> I am wondering if the diagnostic was kept out of -Wall for a reason.
> > 
> > Yes, it would be good to find why this was disabled (never enabled?).


I don't know, @rtrieu originally added the warnings, maybe he can answer that 
question.

>> @Mordante can you compile LLVM itself with this patch?

I compiled LLVM and Clang and it adds 145 unique warnings. I wouldn't mind to 
fix those and the other subprojects, so I can test whether the tests have false 
positives.
Am I correct to assume these patches all need to be reviewed?

> I'd be curious to know how the timing changes between compilations as well; 
> does this regress performance considerably?

I did a partial build of LLVM the timings are quite similar:

Before:
real7m44.918s
user14m41.052s
sys 0m16.560s

After:
real7m52.934s
user14m39.968s
sys 0m16.932s


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

https://reviews.llvm.org/D68912



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


[PATCH] D69498: IR: Invert convergent attribute handling

2019-10-29 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added a comment.

In D69498#1725819 , @mehdi_amini wrote:

> Maybe we can start by looking into the motivation for this patch:
>
> > There is a burden on frontends in environments that care about convergent 
> > operations to add the attribute just in case it is needed. This has proven 
> > to be somewhat problematic, and different frontend projects have 
> > consistently run into problems related to this.
>
> Can you clarify what kind of problems? Do you have concrete examples?


The frontend has to put convergent on everything that is not known to be 
non-convergent right now. That is, the front-end and all function generating 
constructs need to know about convergent to preserve correctness. Dropping 
convergent is also not sound. Frontends in the past put convergent only on 
barriers or similar calls but not on all functions that might transitively call 
barriers, leading to subtle bugs.


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

https://reviews.llvm.org/D69498



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


[PATCH] D62731: Add support for options -frounding-math, ftrapping-math, -fp-model=, and -fp-exception-behavior=, : Specify floating point behavior

2019-10-29 Thread Melanie Blower via Phabricator via cfe-commits
mibintc added inline comments.



Comment at: clang/include/clang/Basic/CodeGenOptions.def:238
 CODEGENOPT(UnsafeFPMath  , 1, 0) ///< Allow unsafe floating point optzns.
+CODEGENOPT(RoundingFPMath, 1, 0) ///< Rounding floating point optzns.
 CODEGENOPT(UnwindTables  , 1, 0) ///< Emit unwind tables.

rjmccall wrote:
> Why do we need both a code-gen option and a language option?
The main reason i added it to LangOptions.h is because I saw the FPContract 
support in there and I thought I'd get on that bandwagon.  My ultimate goal, 
after committing the command line options, is to add support for controlling 
rounding mode and exception behavior with pragma's embedded in the functions, 
similar to https://reviews.llvm.org/D69272.  

There's a patch here that I like, to add rounding-mode and exception-behavior 
to FPOptions https://reviews.llvm.org/D65994, but it hasn't been committed yet.



Repository:
  rL LLVM

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

https://reviews.llvm.org/D62731



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


[PATCH] D69498: IR: Invert convergent attribute handling

2019-10-29 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm added a comment.

In D69498#1725819 , @mehdi_amini wrote:

> Maybe we can start by looking into the motivation for this patch:
>
> > There is a burden on frontends in environments that care about convergent 
> > operations to add the attribute just in case it is needed. This has proven 
> > to be somewhat problematic, and different frontend projects have 
> > consistently run into problems related to this.
>
> Can you clarify what kind of problems? Do you have concrete examples?


Basically no frontend has gotten this right, including clang and non-clang 
frontends. There's a gradual discovery process that it's necessary in the first 
place, and then a long tail of contexts where it's discovered it's missing. As 
I mentioned before, SYCL and OpenMP are both still broken in this regard. For 
example in clang, convergent wasn't initially added to all functions, and then 
it was discovered that transforms on indirect callers violated it. Then later 
it was discovered this was broken for inline asm. Then some specific intrinsic 
call sites were a problem. Then there are special cases that don't necessarily 
go through the standard user function codegen paths which don't get the default 
attributes. Some odd places where IR is compiled into the user library that 
didn't have convergent added. The discovery of convergent violations is 
painful; more painful than discovering that control flow didn't optimize the 
way you expected. It requires eternal vigilance and all developers to be aware 
of it.

The short version is the fact that most developers aren't aware of and don't 
understand the subtleties of convergence, and making sure the front-end does 
something in all contexts requires a lot of diligence. It's very easy to 
introduce these difficult to introduce bugs when calls are broken by default.


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

https://reviews.llvm.org/D69498



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


[PATCH] D68912: Adds -Wrange-loop-analysis to -Wall

2019-10-29 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 added a comment.

> I compiled LLVM and Clang and it adds 145 unique warnings. I wouldn't mind to 
> fix those and the other subprojects, so I can test whether the tests have 
> false positives.
>  Am I correct to assume these patches all need to be reviewed?

Can you upload the list with new warnings somewhere? How many false positives?

I dont think you have to fix them as a prerequisite - buildbots do not use 
-Werror.


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

https://reviews.llvm.org/D68912



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


[clang] 5259031 - Fix argument numbering confusion when diagnosing a non-viable operator().

2019-10-29 Thread Richard Smith via cfe-commits

Author: Richard Smith
Date: 2019-10-29T13:08:39-07:00
New Revision: 52590319a225768404591e60803d0bfa84a8b5cd

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

LOG: Fix argument numbering confusion when diagnosing a non-viable operator().

This could lead to crashes if operator() is a variadic template, as we
could end up asking for an out-of-bounds argument.

Added: 


Modified: 
clang/lib/Sema/SemaOverload.cpp
clang/test/SemaCXX/overload-member-call.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaOverload.cpp b/clang/lib/Sema/SemaOverload.cpp
index 1547108b4af6..2987007f4f23 100644
--- a/clang/lib/Sema/SemaOverload.cpp
+++ b/clang/lib/Sema/SemaOverload.cpp
@@ -11001,7 +11001,8 @@ CompleteNonViableCandidate(Sema &S, OverloadCandidate 
*Cand,
 !isa(Cand->Function)) {
   // Conversion 0 is 'this', which doesn't have a corresponding parameter.
   ConvIdx = 1;
-  if (CSK == OverloadCandidateSet::CSK_Operator)
+  if (CSK == OverloadCandidateSet::CSK_Operator &&
+  Cand->Function->getDeclName().getCXXOverloadedOperator() != OO_Call)
 // Argument 0 is 'this', which doesn't have a corresponding parameter.
 ArgIdx = 1;
 }
@@ -11016,9 +11017,10 @@ CompleteNonViableCandidate(Sema &S, OverloadCandidate 
*Cand,
   for (unsigned ParamIdx = Reversed ? ParamTypes.size() - 1 : 0;
ConvIdx != ConvCount;
++ConvIdx, ++ArgIdx, ParamIdx += (Reversed ? -1 : 1)) {
+assert(ArgIdx < Args.size() && "no argument for this arg conversion");
 if (Cand->Conversions[ConvIdx].isInitialized()) {
   // We've already checked this conversion.
-} else if (ArgIdx < ParamTypes.size()) {
+} else if (ParamIdx < ParamTypes.size()) {
   if (ParamTypes[ParamIdx]->isDependentType())
 Cand->Conversions[ConvIdx].setAsIdentityConversion(
 Args[ArgIdx]->getType());

diff  --git a/clang/test/SemaCXX/overload-member-call.cpp 
b/clang/test/SemaCXX/overload-member-call.cpp
index 41f3946de0bf..90f95fc916e7 100644
--- a/clang/test/SemaCXX/overload-member-call.cpp
+++ b/clang/test/SemaCXX/overload-member-call.cpp
@@ -114,3 +114,10 @@ namespace b7398190 {
   const S *p;
   int k = p->f(); // expected-error {{no matching member function for call to 
'f'}}
 }
+
+void member_call_op_template(int *p) {
+  // Ensure that we don't get confused about relative parameter / argument
+  // indexing here.
+  [](int, int, auto...){}(p, p); // expected-error {{no matching function}} 
expected-note {{no known conversion}}
+}
+



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


[PATCH] D69582: Let clang driver support parallel jobs

2019-10-29 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl created this revision.
yaxunl added reviewers: tra, rsmith, rjmccall.
Herald added subscribers: jfb, mgorny.

It is observed that device code compilation takes most of the compilation time 
when
clang compiles CUDA/HIP programs since device code usually contains complicated
computation code. Often times such code are highly coupled, which results in
a few large source files which become bottlenecks of a whole project. Things 
become
worse when such code is compiled with multiple gpu archs, since clang compiles 
for
each gpu arch sequentially. In practice, it is common to compile for more than 
5 gpu
archs.

To alleviate this issue, this patch implements a simple scheduler which let 
clang
driver compile independent jobs in parallel.

This patch tries to minimize impact on existing clang driver. No changes to 
action
builder and tool chain. It introduces a driver option -parallel-jobs=n to 
control number
of parallel jobs to launch. By default it is 1, and it is NFC per clang driver 
behavior.
If llvm/clang is built with LLVM_ENABLE_THREADS off, this change is also NFC.

The basic design of the scheduler is to find the dependence among the jobs and
use a thread to launches a job when its dependent jobs are done.


https://reviews.llvm.org/D69582

Files:
  clang/include/clang/Basic/OptionUtils.h
  clang/include/clang/Driver/Driver.h
  clang/include/clang/Driver/Job.h
  clang/include/clang/Driver/Options.td
  clang/include/clang/Frontend/Utils.h
  clang/lib/Basic/CMakeLists.txt
  clang/lib/Basic/OptionUtils.cpp
  clang/lib/Driver/Compilation.cpp
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/Job.cpp
  clang/lib/Frontend/CompilerInvocation.cpp

Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -3622,35 +3622,8 @@
   return llvm::APInt(64, code).toString(36, /*Signed=*/false);
 }
 
-template
-static IntTy getLastArgIntValueImpl(const ArgList &Args, OptSpecifier Id,
-IntTy Default,
-DiagnosticsEngine *Diags) {
-  IntTy Res = Default;
-  if (Arg *A = Args.getLastArg(Id)) {
-if (StringRef(A->getValue()).getAsInteger(10, Res)) {
-  if (Diags)
-Diags->Report(diag::err_drv_invalid_int_value) << A->getAsString(Args)
-   << A->getValue();
-}
-  }
-  return Res;
-}
-
 namespace clang {
 
-// Declared in clang/Frontend/Utils.h.
-int getLastArgIntValue(const ArgList &Args, OptSpecifier Id, int Default,
-   DiagnosticsEngine *Diags) {
-  return getLastArgIntValueImpl(Args, Id, Default, Diags);
-}
-
-uint64_t getLastArgUInt64Value(const ArgList &Args, OptSpecifier Id,
-   uint64_t Default,
-   DiagnosticsEngine *Diags) {
-  return getLastArgIntValueImpl(Args, Id, Default, Diags);
-}
-
 IntrusiveRefCntPtr
 createVFSFromCompilerInvocation(const CompilerInvocation &CI,
 DiagnosticsEngine &Diags) {
Index: clang/lib/Driver/Job.cpp
===
--- clang/lib/Driver/Job.cpp
+++ clang/lib/Driver/Job.cpp
@@ -39,9 +39,11 @@
  ArrayRef Inputs)
 : Source(Source), Creator(Creator), Executable(Executable),
   Arguments(Arguments) {
-  for (const auto &II : Inputs)
+  for (const auto &II : Inputs) {
 if (II.isFilename())
   InputFilenames.push_back(II.getFilename());
+DependentActions.push_back(II.getAction());
+  }
 }
 
 /// Check if the compiler flag in question should be skipped when
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -37,13 +37,14 @@
 #include "ToolChains/NaCl.h"
 #include "ToolChains/NetBSD.h"
 #include "ToolChains/OpenBSD.h"
-#include "ToolChains/PS4CPU.h"
 #include "ToolChains/PPCLinux.h"
+#include "ToolChains/PS4CPU.h"
 #include "ToolChains/RISCVToolchain.h"
 #include "ToolChains/Solaris.h"
 #include "ToolChains/TCE.h"
 #include "ToolChains/WebAssembly.h"
 #include "ToolChains/XCore.h"
+#include "clang/Basic/OptionUtils.h"
 #include "clang/Basic/Version.h"
 #include "clang/Config/config.h"
 #include "clang/Driver/Action.h"
@@ -54,6 +55,7 @@
 #include "clang/Driver/SanitizerArgs.h"
 #include "clang/Driver/Tool.h"
 #include "clang/Driver/ToolChain.h"
+#include "clang/Driver/Util.h"
 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SmallSet.h"
@@ -129,7 +131,7 @@
   CCLogDiagnostics(false), CCGenDiagnostics(false),
   TargetTriple(TargetTriple), CCCGenericGCCName(""), Saver(Alloc),
   CheckInputsExist(true), GenReproducer(false),
-  SuppressMissingInputWarning(false) {
+  SuppressMissingInputWarning(false), NumParallelJobs(1) {
 
   // Provide

[PATCH] D69181: [clang-tidy] Adding misc-signal-terminated-thread check

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

LGTM aside from the release notes alias request.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D69181



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


[PATCH] D69360: [NFC] Refactor representation of materialized temporaries

2019-10-29 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added a comment.

Thanks, I like this a lot.

There are a few more changes we'll need in addition to this before we can 
properly serialize `APValue`s referring to such temporaries:

1. Merging during deserialization. For example, if we have

  inline int &&r = 123;

in two different modules, we should merge the two 
`LifetimeExtendedTemporaryDecl`s for the `123`. This will require making the 
decl derive from `Mergeable<...>` and adding a little logic to ASTReader to 
look up lifetime-extended declarations by their extending decl and mangling 
number.

2. Change the constant expression representation for a pointer or reference for 
a materialized temporary to refer to the temporary declaration instead.

3. Change CodeGen / name mangling to operate on the new declaration node rather 
than `MaterializedTemporaryExpr`. (This will be needed once `CodeGen` starts 
seeing constant `APValue`s referring to the new declaration nodes.)

I'm happy for the above to be done in a follow-up; as is, this change is a good 
refactoring and a basis for the above extensions.




Comment at: clang/include/clang/AST/DeclCXX.h:3057
+/// MaterializeTemporaryExpr
+class MaterializeTemporaryDecl final : public Decl {
+  friend class MaterializeTemporaryExpr;

Since we should only use this for lifetime-extended temporaries, not for any 
materialized temporary, how about renaming to `LifetimeExtendedTemporaryDecl`?



Comment at: clang/include/clang/AST/DeclCXX.h:3071
+
+  mutable APValue* Value = nullptr;
+

Clang coding convention puts the `*` on the right (please fix throughout the 
patch).



Comment at: clang/include/clang/AST/DeclCXX.h:3101-3106
+  Stmt* getStmtWithTemporary() {
+return StmtWithTemporary;
+  }
+  const Stmt* getStmtWithTemporary() const {
+return StmtWithTemporary;
+  }

We should expose this as an `Expr*` rather than a `Stmt*`, since it must always 
be an expression. Also maybe `getSubExpr()` or `getTemporaryExpr()` would be a 
better name?

Please include a comment here saying that this isn't necessarily the 
initializer of the temporary due to the C++98 delayed materialization rules, 
but that `skipRValueSubobjectAdjustments` can be used to find said initializer 
within the subexpression.



Comment at: clang/include/clang/AST/ExprCXX.h:4469-4471
+  /// Get the storage for the constant value of a materialized temporary
+  /// of static storage duration.
+  APValue *getOrCreateValue(ASTContext &Ctx, bool MayCreate) const;

This should live on the declaration, not here.



Comment at: clang/include/clang/AST/ExprCXX.h:4516
+auto ES = State.get();
+return child_range(&ES->StmtWithTemporary, &ES->StmtWithTemporary + 1);
   }

Instead of the friend decl / direct member access, it would be cleaner to a 
`children` function to the declaration and call it from here.



Comment at: clang/include/clang/AST/RecursiveASTVisitor.h:2125
+DEF_TRAVERSE_DECL(MaterializeTemporaryDecl, {
+  TRY_TO(TraverseDecl(D->getExtendingDecl()));
+  TRY_TO(TraverseStmt(D->getStmtWithTemporary()));

We should not traverse the extending declaration here; the temporary just has a 
backreference to the extending decl, it doesn't *contain* the extending decl.

Also, this is unreachable in normal circumstances. I think traversing the 
`MaterializeTemporaryExpr` should visit the lifetime-extended temporary 
declaration if there is one.


Repository:
  rC Clang

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

https://reviews.llvm.org/D69360



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


[PATCH] D69533: Thread safety analysis: Peel away NoOp implicit casts in initializers

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

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69533



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


[PATCH] D69238: Fix clang-tidy readability-redundant-string-init for c++17/c++2a

2019-10-29 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/readability/RedundantStringInitCheck.cpp:67-70
+// With -std c++14 or earlier (!LangOps.CPlusPlus17), it was sufficient to
+// return CtorExpr->getSourceRange(). However, starting with c++17, parsing
+// the expression 'std::string Name = ""' results in a CtorExpr whose
+// SourceRange includes just '""' rather than the previous 'Name = ""'.

Are you sure that this behavioral difference isn't just a bug in Clang? I can't 
think of why the source range should differ based on language mode, so I wonder 
if the correct thing to do is fix how we calculate the source range in Clang?



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/readability-redundant-string-init.cpp:106
   DECL_STRING(e, "");
-  // CHECK-MESSAGES: [[@LINE-1]]:15: warning: redundant string initialization
+  // CHECK-MESSAGES: [[@LINE-1]]:1{{[58]}}: warning: redundant string 
initialization
 

poelmanc wrote:
> aaron.ballman wrote:
> > Why does this need a regex?
> Thanks, I added a comment explaining that the character position of the 
> warning differs slightly between C++11/14 (reports at the 'e') and C++17/2x 
> (reports at the '"'), since the underlying parsing code has changed.
Thank you for the explanation!


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D69238



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


[clang] f919be3 - [DWARF5] Added support for deleted C++ special member functions.

2019-10-29 Thread Adrian Prantl via cfe-commits

Author: Adrian Prantl
Date: 2019-10-29T13:44:06-07:00
New Revision: f919be336583349d883ba0dfdb3b2479a190b67c

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

LOG: [DWARF5] Added support for deleted C++ special member functions.

This patch adds support for deleted C++ special member functions in
clang and llvm. Also added Defaulted member encodings for future
support for defaulted member functions.

Patch by Sourabh Singh Tomar!

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

Added: 
clang/test/CodeGenCXX/debug-info-deleted.cpp
llvm/test/DebugInfo/X86/DW_AT_deleted.ll

Modified: 
clang/lib/CodeGen/CGDebugInfo.cpp
llvm/docs/SourceLevelDebugging.rst
llvm/include/llvm/BinaryFormat/Dwarf.h
llvm/include/llvm/IR/DebugInfoFlags.def
llvm/include/llvm/IR/DebugInfoMetadata.h
llvm/lib/BinaryFormat/Dwarf.cpp
llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGDebugInfo.cpp 
b/clang/lib/CodeGen/CGDebugInfo.cpp
index 7c63743f3b43..292d13e62bd4 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -1607,8 +1607,31 @@ llvm::DISubprogram *CGDebugInfo::CreateCXXMemberFunction(
 ContainingType = RecordTy;
   }
 
+  // We're checking for deleted C++ special member functions
+  // [Ctors,Dtors, Copy/Move]
+  auto checkAttrDeleted = [&SPFlags](const auto *Method) {
+if (Method->getCanonicalDecl()->isDeleted())
+  SPFlags |= llvm::DISubprogram::SPFlagDeleted;
+  };
+
+  switch (Method->getKind()) {
+
+  case Decl::CXXConstructor:
+  case Decl::CXXDestructor:
+checkAttrDeleted(Method);
+break;
+  case Decl::CXXMethod:
+if (Method->isCopyAssignmentOperator() ||
+Method->isMoveAssignmentOperator())
+  checkAttrDeleted(Method);
+break;
+  default:
+break;
+  }
+
   if (Method->isNoReturn())
 Flags |= llvm::DINode::FlagNoReturn;
+
   if (Method->isStatic())
 Flags |= llvm::DINode::FlagStaticMember;
   if (Method->isImplicit())

diff  --git a/clang/test/CodeGenCXX/debug-info-deleted.cpp 
b/clang/test/CodeGenCXX/debug-info-deleted.cpp
new file mode 100644
index ..d7d0b6dba49e
--- /dev/null
+++ b/clang/test/CodeGenCXX/debug-info-deleted.cpp
@@ -0,0 +1,31 @@
+// Test for debug info for C++11 deleted member functions
+
+//Supported: -O0, standalone DI
+// RUN: %clang_cc1 -emit-llvm -triple x86_64-linux-gnu %s -o - \
+// RUN:   -O0 -disable-llvm-passes \
+// RUN:   -debug-info-kind=standalone \
+// RUN: | FileCheck %s -check-prefix=ATTR
+
+// ATTR: DISubprogram(name: "deleted", {{.*}}, flags: DIFlagPublic | 
DIFlagPrototyped,
+// ATTR: DISubprogram(name: "deleted", {{.*}}, flags: DIFlagPublic | 
DIFlagPrototyped, spFlags: DISPFlagDeleted
+// ATTR: DISubprogram(name: "operator=", linkageName: "_ZN7deletedaSERKS_", 
{{.*}}, flags: DIFlagPublic | DIFlagPrototyped, spFlags: DISPFlagDeleted
+// ATTR: DISubprogram(name: "deleted", {{.*}}, flags: DIFlagPublic | 
DIFlagPrototyped, spFlags: DISPFlagDeleted
+// ATTR: DISubprogram(name: "operator=", linkageName: "_ZN7deletedaSEOS_", 
{{.*}}, flags: DIFlagPublic | DIFlagPrototyped, spFlags: DISPFlagDeleted
+// ATTR: DISubprogram(name: "~deleted", {{.*}}, flags: DIFlagPublic | 
DIFlagPrototyped,
+class deleted {
+public:
+  // Defaulted on purpose, so as to facilitate object creation
+  deleted() = default;
+
+  deleted(const deleted &) = delete;
+  deleted &operator=(const deleted &) = delete;
+
+  deleted(deleted &&) = delete;
+  deleted &operator=(deleted &&) = delete;
+
+  ~deleted() = default;
+};
+
+void foo() {
+  deleted obj1;
+}

diff  --git a/llvm/docs/SourceLevelDebugging.rst 
b/llvm/docs/SourceLevelDebugging.rst
index a887810db4d8..978184743314 100644
--- a/llvm/docs/SourceLevelDebugging.rst
+++ b/llvm/docs/SourceLevelDebugging.rst
@@ -989,6 +989,39 @@ a C/C++ front-end would generate the following descriptors:
   ...
   }
 
+C++ specific debug information
+==
+
+C++ special member functions information
+
+
+DWARF v5 introduces attributes defined to enhance debugging information of C++ 
programs. LLVM can generate (or omit) these appropriate DWARF attributes. In 
C++ a special member function Ctors, Dtors, Copy/Move Ctors, assignment 
operators can be declared with C++11 keyword deleted. This is represented in 
LLVM using spFlags value DISPFlagDeleted.
+
+Given a class declaration with copy constructor declared as deleted:
+
+.. code-block:: c
+
+  class foo {
+   public:
+ foo(const foo&) = deleted;
+  };
+
+A C++ frontend would generate follwing:
+
+.. code-block:: text
+
+  !17 = !DISubprogram(name: "foo", scope: !11, file: !1, line: 5, type: !18, 
scopeLine: 5, flags: DIFlagPublic | DIFlagPrototyped, spFlags: DISP

[PATCH] D69548: Give clang-tidy readability-redundant-string-init a customizable list of string types to fix

2019-10-29 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/readability/RedundantStringInitCheck.cpp:21
 
+const char DefaultStringNames[] = "basic_string";
+

I think the default should probably be `::std::basic_string` to avoid getting 
other things named `basic_string`?



Comment at: 
clang-tools-extra/docs/clang-tidy/checks/readability-redundant-string-init.rst:27
+
+Default is ``basic_string``.
+

Eugene.Zelenko wrote:
> Please use single back-ticks for options. Same below.
Should update this as well if you go with the suggest change to 
`::std::basic_string`.



Comment at: clang/include/clang/ASTMatchers/ASTMatchers.h:2563-2565
+inline internal::Matcher hasListedName(const 
std::vector &Names) {
+  return internal::Matcher(new internal::HasNameMatcher(Names));
+}

I think we should try to get the existing `hasAnyName()` matcher to work with a 
vector of strings instead of adding a new matcher to do the same thing.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D69548



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


[PATCH] D69573: [clang-format] [PR36294] AlwaysBreakAfterReturnType works incorrectly for some operator functions

2019-10-29 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay updated this revision to Diff 226961.
MyDeveloperDay added a comment.

Trying to address review comments


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

https://reviews.llvm.org/D69573

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


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -6111,7 +6111,13 @@
"void\n"
"A::operator>>() {}\n"
"void\n"
-   "A::operator+() {}\n",
+   "A::operator+() {}\n"
+   "void\n"
+   "A::operator*() {}\n"
+   "void\n"
+   "A::operator->() {}\n"
+   "void\n"
+   "A::operator!() {}\n",
Style);
   verifyFormat("void *operator new(std::size_t s);", // No break here.
Style);
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -952,7 +952,7 @@
 consumeToken();
 if (CurrentToken &&
 CurrentToken->Previous->isOneOf(TT_BinaryOperator, 
TT_UnaryOperator,
-tok::comma))
+tok::comma, tok::arrow))
   CurrentToken->Previous->Type = TT_OverloadedOperator;
   }
   if (CurrentToken) {
@@ -1344,8 +1344,12 @@
 Contexts.back().IsExpression = false;
 } else if (Current.is(tok::kw_new)) {
   Contexts.back().CanBeExpression = false;
-} else if (Current.isOneOf(tok::semi, tok::exclaim)) {
+} else if (Current.is(tok::semi) ||
+   (Current.is(tok::exclaim) && Current.Previous &&
+!Current.Previous->is(tok::kw_operator))) {
   // This should be the condition or increment in a for-loop.
+  // But not operator !() (can't use TT_OverloadedOperator here as its not
+  // been annotated yet).
   Contexts.back().IsExpression = true;
 }
   }
@@ -2085,6 +2089,8 @@
 return Next;
   if (Next->is(TT_OverloadedOperator))
 continue;
+  if (Next->is(TT_PointerOrReference))
+continue;
   if (Next->isOneOf(tok::kw_new, tok::kw_delete)) {
 // For 'new[]' and 'delete[]'.
 if (Next->Next && Next->Next->is(tok::l_square) && Next->Next->Next &&


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -6111,7 +6111,13 @@
"void\n"
"A::operator>>() {}\n"
"void\n"
-   "A::operator+() {}\n",
+   "A::operator+() {}\n"
+   "void\n"
+   "A::operator*() {}\n"
+   "void\n"
+   "A::operator->() {}\n"
+   "void\n"
+   "A::operator!() {}\n",
Style);
   verifyFormat("void *operator new(std::size_t s);", // No break here.
Style);
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -952,7 +952,7 @@
 consumeToken();
 if (CurrentToken &&
 CurrentToken->Previous->isOneOf(TT_BinaryOperator, TT_UnaryOperator,
-tok::comma))
+tok::comma, tok::arrow))
   CurrentToken->Previous->Type = TT_OverloadedOperator;
   }
   if (CurrentToken) {
@@ -1344,8 +1344,12 @@
 Contexts.back().IsExpression = false;
 } else if (Current.is(tok::kw_new)) {
   Contexts.back().CanBeExpression = false;
-} else if (Current.isOneOf(tok::semi, tok::exclaim)) {
+} else if (Current.is(tok::semi) ||
+   (Current.is(tok::exclaim) && Current.Previous &&
+!Current.Previous->is(tok::kw_operator))) {
   // This should be the condition or increment in a for-loop.
+  // But not operator !() (can't use TT_OverloadedOperator here as its not
+  // been annotated yet).
   Contexts.back().IsExpression = true;
 }
   }
@@ -2085,6 +2089,8 @@
 return Next;
   if (Next->is(TT_OverloadedOperator))
 continue;
+  if (Next->is(TT_PointerOrReference))
+continue;
   if (Next->isOneOf(tok::kw_new, tok::kw_delete)) {
 // For 'new[]' and 'delete[]'.
 if (Next->Next && Next->Next->is(tok::l_square) && Next->Next->Next &&
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D69162: [clangd] Remove using-namespace present inside a namespace.

2019-10-29 Thread UTKARSH SAXENA via Phabricator via cfe-commits
usaxena95 updated this revision to Diff 226962.
usaxena95 marked 7 inline comments as done.
usaxena95 added a comment.

Addressed comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69162

Files:
  clang-tools-extra/clangd/refactor/tweaks/RemoveUsingNamespace.cpp
  clang-tools-extra/clangd/unittests/TweakTests.cpp

Index: clang-tools-extra/clangd/unittests/TweakTests.cpp
===
--- clang-tools-extra/clangd/unittests/TweakTests.cpp
+++ clang-tools-extra/clangd/unittests/TweakTests.cpp
@@ -789,15 +789,23 @@
 map m;
   }
 )cpp"},
-  {// Available only for top level namespace decl.
-   R"cpp(
-namespace aa {
-  namespace bb { struct map {}; }
-  using namespace b^b;
-}
-int main() { aa::map m; }
+  {
+  // FIXME: Does not remove usages outside the enclosing NS.
+  R"cpp(
+  namespace aa {
+  namespace bb { struct map {}; }
+  using namespace b^b;
+  }
+  int main() { aa::map m; }
 )cpp",
-   "unavailable"},
+  R"cpp(
+  namespace aa {
+  namespace bb { struct map {}; }
+  
+  }
+  int main() { aa::map m; }
+)cpp",
+  },
   {// FIXME: Unavailable for namespaces containing using-namespace decl.
R"cpp(
   namespace aa {
@@ -875,7 +883,116 @@
   int main() {
 std::vector V;
   }
-)cpp"}};
+)cpp"},
+  {// using inner namespaces.
+   R"cpp(
+  namespace A { namespace B { 
+  inline namespace ns1 { namespace std { struct vector {}; } }
+  using namespace st^d;
+  using namespace A::B::std;
+  using namespace B::std;
+  void func() { 
+vector V1;
+B::vector V2;
+A::B::vector V3;
+A::B::std::vector V4;  // Already qualified with TargetNS. 
+::A::B::std::vector V5;
+::A::B::ns1::std::vector V6;
+  }
+  }}
+)cpp",
+   R"cpp(
+  namespace A { namespace B { 
+  inline namespace ns1 { namespace std { struct vector {}; } }
+  
+  
+  
+  void func() { 
+std::vector V1;
+std::vector V2;
+std::vector V3;
+A::B::std::vector V4;  // Already qualified with TargetNS. 
+::A::B::std::vector V5;
+::A::B::ns1::std::vector V6;
+  }
+  }}
+)cpp"},
+  {// using outer namespaces.
+   R"cpp(
+  namespace std { struct vector {}; }
+  namespace A { namespace B { 
+  using namespace st^d;
+  void func() { 
+vector V1;
+B::vector V2;
+A::B::vector V3;
+::A::B::vector V4;
+  }
+  }}
+)cpp",
+   R"cpp(
+  namespace std { struct vector {}; }
+  namespace A { namespace B { 
+  
+  void func() { 
+std::vector V1;
+std::vector V2;
+std::vector V3;
+std::vector V4;
+  }
+  }}
+)cpp"},
+  { // Redecls of a namespace.
+   R"cpp(
+  namespace std { struct vector {}; }
+  namespace A { namespace B { using namespace st^d; }}
+  namespace A { namespace B { int func() { vector V1;}}}
+)cpp",
+   R"cpp(
+  namespace std { struct vector {}; }
+  namespace A { namespace B {  }}
+  namespace A { namespace B { int func() { std::vector V1;}}}
+)cpp"},
+  {// using namespace for outer and inner namespaces: remove inner.
+   R"cpp(
+  namespace out { namespace std { struct vector{}; }}
+  namespace A {
+  using namespace out;
+  using namespace st^d;
+  void func() { vector V;}
+  }
+)cpp",
+   R"cpp(
+  namespace out { namespace std { struct vector{}; }}
+  namespace A {
+  using namespace out;
+  
+  void func() { std::vector V;}
+  }
+)cpp"},
+  {// using namespace for outer and inner namespaces: remove outer.
+   R"cpp(
+  namespace out { namespace std { struct vector{}; }}
+  namespace A {
+  using namespace ou^t;
+  using namespace std;
+  void func() { vector V;}
+  }
+)cpp",
+   R"cpp(
+  namespace out { namespace std { struct vector{}; }}
+  namespace A {
+  
+  using namespace out::std;
+  void func() { vector V;}
+  }
+)cpp"},
+  {// Not available for contexts that are not global or namespaces.
+   R"cpp(
+  namespace std { struct vector {}; }
+  int main() { if(true) { using namespace st^d;}}
+)cpp",
+   "unavailable"}};
   for (auto C : Cases)
 EXPECT_EQ(C.second, apply(C.first)) << C.first;
 }
Index: clang-tools-extra/clangd/refactor/tweaks/RemoveUsingNamespace.cpp
===
--- clang-tools-extra/clangd/refactor/tweaks/RemoveUsingNamespace.cpp
+++ clang-tools-extra/clangd/refactor/tweaks/RemoveUsingNamespace.cpp
@@ -18,6 +18,7 @@
 #inc

[PATCH] D69162: [clangd] Remove using-namespace present inside a namespace.

2019-10-29 Thread UTKARSH SAXENA via Phabricator via cfe-commits
usaxena95 added inline comments.



Comment at: 
clang-tools-extra/clangd/refactor/tweaks/RemoveUsingNamespace.cpp:180
+  if (ContainingNS)
+findExplicitReferences(ContainingNS, SelectRefToQualify);
+  else

ilya-biryukov wrote:
> Do we also need to run in the redeclarations of the same namespace?
> ```
> namespace clangd {
>   using namespace clang;
> }
> 
> namespace clangd {
>   /*clang::*/Decl* D = nullptr;
> }
> ```
Aah. Didn't know we have the redecls here itself. I had a FIXME as a negative 
test for this. Fixed that now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69162



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


  1   2   >