Re: [PATCH] D24809: [libcxx] [cmake] Strip possibly-inherited compiler flags in in-tree build only

2016-09-27 Thread Eric Fiselier via cfe-commits
EricWF accepted this revision.
EricWF added a comment.
This revision is now accepted and ready to land.

LGTM modulo inline comments.



Comment at: CMakeLists.txt:310
@@ -309,4 +309,3 @@
 
-# Remove flags that may have snuck in.
-remove_flags(-DNDEBUG -UNDEBUG -D_DEBUG
- -stdlib=libc++ -stdlib=libstdc++ -lc++abi -m32)
+if (LIBCXX_STANDALONE_BUILD)
+  # Remove flags that may have snuck in.

We always want to strip `-stdlib=` because it's just nonsense to enable 
the STL while building the STL.


https://reviews.llvm.org/D24809



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


Re: [PATCH] D24914: [clang-rename] Do not print out error message upon encountering multiple replacements in the same SourceLocation.

2016-09-27 Thread Alexander Shaposhnikov via cfe-commits
alexshap added a subscriber: alexshap.


Comment at: clang-rename/RenamingAction.cpp:74
@@ +73,3 @@
+  // FIXME: As for clang-rename, adding a replacement fails IFF either the
+  // AST node has been matched multiple times (which shouldn't happen in
+  // reality, need to fix that). For now, just ignore the error as it

Let's consider the following example:
src/include/Point.h:
   struct Point {};
src/a.cpp: 
   include 
src/b.cpp:
   include 
clang-rename -qualified-name Point -new-name Point2 srcs/a.cpp srcs/b.cpp
Renaming failed in /Users/Alexshap/PlayRename/srcs/./include/Point.h! New 
replacement:
/Users/Alexshap/PlayRename/srcs/./include/Point.h: 7:+5:"Point2"
conflicts with existing replacement:
/Users/Alexshap/PlayRename/srcs/./include/Point.h: 7:+5:"Point2"

The thing is that clang-rename is trying to modify the same code twice (as in 
the example) and the return value (Error) of the method Replacements::add 
doesn't allow us to distinguish two cases: A. conflict (trying to apply 
different modifications to the same source code) B. (still conflict, but 
different) (trying to apply the same modification twice). 
In the past when Replacements was a typedef on std::set and clang-rename was 
using insert(...) the case B wasn't an issue. 
P.S. However (imo) the new (FIXME) comment seems to be a little bit misleading.


https://reviews.llvm.org/D24914



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


Re: [PATCH] D24914: [clang-rename] Do not print out error message upon encountering multiple replacements in the same SourceLocation.

2016-09-27 Thread Kirill Bobyrev via cfe-commits
omtcyfz added inline comments.


Comment at: clang-rename/RenamingAction.cpp:74
@@ +73,3 @@
+  // FIXME: As for clang-rename, adding a replacement fails IFF either the
+  // AST node has been matched multiple times (which shouldn't happen in
+  // reality, need to fix that). For now, just ignore the error as it

alexshap wrote:
> Let's consider the following example:
> src/include/Point.h:
>struct Point {};
> src/a.cpp: 
>include 
> src/b.cpp:
>include 
> clang-rename -qualified-name Point -new-name Point2 srcs/a.cpp srcs/b.cpp
> Renaming failed in /Users/Alexshap/PlayRename/srcs/./include/Point.h! New 
> replacement:
> /Users/Alexshap/PlayRename/srcs/./include/Point.h: 7:+5:"Point2"
> conflicts with existing replacement:
> /Users/Alexshap/PlayRename/srcs/./include/Point.h: 7:+5:"Point2"
> 
> The thing is that clang-rename is trying to modify the same code twice (as in 
> the example) and the return value (Error) of the method Replacements::add 
> doesn't allow us to distinguish two cases: A. conflict (trying to apply 
> different modifications to the same source code) B. (still conflict, but 
> different) (trying to apply the same modification twice). 
> In the past when Replacements was a typedef on std::set and clang-rename was 
> using insert(...) the case B wasn't an issue. 
> P.S. However (imo) the new (FIXME) comment seems to be a little bit 
> misleading.
But the thing is that it's never the A. case. Unlike other refactorings, 
clang-rename doesn't introduce any name conflicts, it will only sometimes try 
to rename something multiple times.


https://reviews.llvm.org/D24914



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


Re: [PATCH] D24914: [clang-rename] Do not print out error message upon encountering multiple replacements in the same SourceLocation.

2016-09-27 Thread Alexander Shaposhnikov via cfe-commits
alexshap added inline comments.


Comment at: clang-rename/RenamingAction.cpp:74
@@ +73,3 @@
+  // FIXME: As for clang-rename, adding a replacement fails IFF either the
+  // AST node has been matched multiple times (which shouldn't happen in
+  // reality, need to fix that). For now, just ignore the error as it

omtcyfz wrote:
> alexshap wrote:
> > Let's consider the following example:
> > src/include/Point.h:
> >struct Point {};
> > src/a.cpp: 
> >include 
> > src/b.cpp:
> >include 
> > clang-rename -qualified-name Point -new-name Point2 srcs/a.cpp srcs/b.cpp
> > Renaming failed in /Users/Alexshap/PlayRename/srcs/./include/Point.h! New 
> > replacement:
> > /Users/Alexshap/PlayRename/srcs/./include/Point.h: 7:+5:"Point2"
> > conflicts with existing replacement:
> > /Users/Alexshap/PlayRename/srcs/./include/Point.h: 7:+5:"Point2"
> > 
> > The thing is that clang-rename is trying to modify the same code twice (as 
> > in the example) and the return value (Error) of the method 
> > Replacements::add doesn't allow us to distinguish two cases: A. conflict 
> > (trying to apply different modifications to the same source code) B. (still 
> > conflict, but different) (trying to apply the same modification twice). 
> > In the past when Replacements was a typedef on std::set and clang-rename 
> > was using insert(...) the case B wasn't an issue. 
> > P.S. However (imo) the new (FIXME) comment seems to be a little bit 
> > misleading.
> But the thing is that it's never the A. case. Unlike other refactorings, 
> clang-rename doesn't introduce any name conflicts, it will only sometimes try 
> to rename something multiple times.
Yup


https://reviews.llvm.org/D24914



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


[PATCH] D24954: [ToolChains] Do not assume OpenSUSE for other SUSE variants

2016-09-27 Thread Michał Górny via cfe-commits
mgorny created this revision.
mgorny added reviewers: rafael, theraven, ismail.
mgorny added a subscriber: cfe-commits.

Assume OpenSUSE distribution only when /etc/SuSE-release indicates OpenSUSE, 
rather than for any SUSE distribution. This reverts the behavior change from 
rL185537 which -- along with removing the version check -- also implicitly 
removed the check for OpenSUSE string. This fixes passing unsupported linker 
flags for old binutils on SLES10.


https://reviews.llvm.org/D24954

Files:
  lib/Driver/ToolChains.cpp

Index: lib/Driver/ToolChains.cpp
===
--- lib/Driver/ToolChains.cpp
+++ lib/Driver/ToolChains.cpp
@@ -3912,8 +3912,11 @@
 return UnknownDistro;
   }
 
-  if (D.getVFS().exists("/etc/SuSE-release"))
-return OpenSUSE;
+  File = llvm::MemoryBuffer::getFile("/etc/SuSE-release");
+  if (File)
+return llvm::StringSwitch(File.get()->getBuffer())
+  .StartsWith("openSUSE", OpenSUSE)
+  .Default(UnknownDistro);
 
   if (D.getVFS().exists("/etc/exherbo-release"))
 return Exherbo;


Index: lib/Driver/ToolChains.cpp
===
--- lib/Driver/ToolChains.cpp
+++ lib/Driver/ToolChains.cpp
@@ -3912,8 +3912,11 @@
 return UnknownDistro;
   }
 
-  if (D.getVFS().exists("/etc/SuSE-release"))
-return OpenSUSE;
+  File = llvm::MemoryBuffer::getFile("/etc/SuSE-release");
+  if (File)
+return llvm::StringSwitch(File.get()->getBuffer())
+  .StartsWith("openSUSE", OpenSUSE)
+  .Default(UnknownDistro);
 
   if (D.getVFS().exists("/etc/exherbo-release"))
 return Exherbo;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D24954: [ToolChains] Do not assume OpenSUSE for other SUSE variants

2016-09-27 Thread İsmail Dönmez via cfe-commits
ismail added a comment.

This will break SLES11 and later so it's not OK. Also note that SLES10 is not 
supported anymore.


https://reviews.llvm.org/D24954



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


Re: [PATCH] D24928: [ASTMatcher] Clarify isStaticStorageClass and hasStaticStorageDuration documents.

2016-09-27 Thread Haojian Wu via cfe-commits
hokein updated this revision to Diff 72608.
hokein added a comment.

Address review comments


https://reviews.llvm.org/D24928

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

Index: unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
===
--- unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
+++ unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
@@ -669,7 +669,7 @@
 
 TEST(Matcher, VarDecl_StorageDuration) {
   std::string T =
-"void f() { int x; static int y; } int a;";
+"void f() { int x; static int y; } int a;static int b;extern int c;";
 
   EXPECT_TRUE(matches(T, varDecl(hasName("x"), hasAutomaticStorageDuration(;
   EXPECT_TRUE(
@@ -679,6 +679,8 @@
 
   EXPECT_TRUE(matches(T, varDecl(hasName("y"), hasStaticStorageDuration(;
   EXPECT_TRUE(matches(T, varDecl(hasName("a"), hasStaticStorageDuration(;
+  EXPECT_TRUE(matches(T, varDecl(hasName("b"), hasStaticStorageDuration(;
+  EXPECT_TRUE(matches(T, varDecl(hasName("c"), hasStaticStorageDuration(;
   EXPECT_TRUE(notMatches(T, varDecl(hasName("x"), hasStaticStorageDuration(;
 
   // FIXME: It is really hard to test with thread_local itself because not all
@@ -853,6 +855,7 @@
   matches("static void f() {}", functionDecl(isStaticStorageClass(;
   EXPECT_TRUE(matches("static int i = 1;", varDecl(isStaticStorageClass(;
   EXPECT_TRUE(notMatches("int i = 1;", varDecl(isStaticStorageClass(;
+  EXPECT_TRUE(notMatches("extern int i;", varDecl(isStaticStorageClass(;
   EXPECT_TRUE(notMatches("void f() {}", functionDecl(isStaticStorageClass(;
 }
 
Index: include/clang/ASTMatchers/ASTMatchers.h
===
--- include/clang/ASTMatchers/ASTMatchers.h
+++ include/clang/ASTMatchers/ASTMatchers.h
@@ -2942,16 +2942,20 @@
 }
 
 /// \brief Matches a variable declaration that has static storage duration.
+/// It includes the variable declared at namespace scope and those declared
+/// with "static" and "extern" storage class specifiers.
 ///
-/// Example matches y and a, but not x or z.
-/// (matcher = varDecl(hasStaticStorageDuration())
 /// \code
 /// void f() {
 ///   int x;
 ///   static int y;
 ///   thread_local int z;
 /// }
 /// int a;
+/// static int b;
+/// extern int c;
+/// varDecl(hasStaticStorageDuration())
+///   matches the function declaration y, a, b and c.
 /// \endcode
 AST_MATCHER(VarDecl, hasStaticStorageDuration) {
   return Node.getStorageDuration() == SD_Static;
@@ -3387,13 +3391,15 @@
   return Node.isExternC();
 }
 
-/// \brief Matches variable/function declarations that have static storage class
-/// (with "static" key word) written in the source.
+/// \brief Matches variable/function declarations that have "static" storage
+/// class specifier ("static" keyword) written in the source.
 ///
 /// Given:
 /// \code
 ///   static void f() {}
 ///   static int i = 0;
+///   extern int j;
+///   int k;
 /// \endcode
 /// functionDecl(isStaticStorageClass())
 ///   matches the function declaration f.
Index: docs/LibASTMatchersReference.html
===
--- docs/LibASTMatchersReference.html
+++ docs/LibASTMatchersReference.html
@@ -2611,12 +2611,14 @@
 
 
 MatcherFunctionDecl>isStaticStorageClass
-Matches variablefunction declarations that have static storage class
-(with "static" key word) written in the source.
+Matches variablefunction declarations that have "static" storage
+class specifier ("static" keyword) written in the source.
 
 Given:
   static void f() {}
   static int i = 0;
+  extern int j;
+  int k;
 functionDecl(isStaticStorageClass())
   matches the function declaration f.
 varDecl(isStaticStorageClass())
@@ -3394,15 +3396,19 @@
 
 MatcherVarDecl>hasStaticStorageDuration
 Matches a variable declaration that has static storage duration.
+It includes the variable declared at namespace scope and those declared
+with "static" and "extern" storage class specifiers.
 
-Example matches y and a, but not x or z.
-(matcher = varDecl(hasStaticStorageDuration())
 void f() {
   int x;
   static int y;
   thread_local int z;
 }
 int a;
+static int b;
+extern int c;
+varDecl(hasStaticStorageDuration())
+  matches the function declaration y, a, b and c.
 
 
 
@@ -3488,12 +3494,14 @@
 
 
 MatcherVarDecl>isStaticStorageClass
-Matches variablefunction declarations that have static storage class
-(with "static" key word) written in the source.
+Matches variablefunction declarations that have "static" storage
+class specifier ("static" keyword) written in the source.
 
 Given:
   static void f() {}
   static int i = 0;
+  extern int j;
+  int k;
 functionDe

Re: [PATCH] D24628: [ASAN] Pass previous stack information through __sanitizer_finish_switch_fiber

2016-09-27 Thread Dmitry Vyukov via cfe-commits
dvyukov added a comment.

LGTM

Any other comments? Or I will submit it tomorrow.



Comment at: test/asan/TestCases/Linux/swapcontext_annotation.cc:7
@@ +6,3 @@
+// RUN: %clangxx_asan -std=c++11 -lpthread -O3 %s -o %t && %run %t 2>&1 | 
FileCheck %s
+// RUN: %clangxx_asan -std=c++11 -lpthread -O0 %s -o %t && %run %t 2>&1 | 
FileCheck <( seq 60 | xargs -i -- grep LOOPCHECK %s ) --check-prefix LOOPCHECK
+// RUN: %clangxx_asan -std=c++11 -lpthread -O1 %s -o %t && %run %t 2>&1 | 
FileCheck <( seq 60 | xargs -i -- grep LOOPCHECK %s ) --check-prefix LOOPCHECK

nice


https://reviews.llvm.org/D24628



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


Re: [PATCH] D24752: [Modules] Add missing dependencies to clang builtins modulemap

2016-09-27 Thread Elad Cohen via cfe-commits
eladcohen added a comment.

ping


https://reviews.llvm.org/D24752



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


Re: [PATCH] D24928: [ASTMatcher] Clarify isStaticStorageClass and hasStaticStorageDuration documents.

2016-09-27 Thread Haojian Wu via cfe-commits
This revision was automatically updated to reflect the committed changes.
hokein marked an inline comment as done.
Closed by commit rL282474: [ASTMatcher] Clarify isStaticStorageClass and 
hasStaticStorageDuration… (authored by hokein).

Changed prior to commit:
  https://reviews.llvm.org/D24928?vs=72608&id=72610#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D24928

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

Index: cfe/trunk/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
===
--- cfe/trunk/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
+++ cfe/trunk/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
@@ -669,7 +669,7 @@
 
 TEST(Matcher, VarDecl_StorageDuration) {
   std::string T =
-"void f() { int x; static int y; } int a;";
+"void f() { int x; static int y; } int a;static int b;extern int c;";
 
   EXPECT_TRUE(matches(T, varDecl(hasName("x"), hasAutomaticStorageDuration(;
   EXPECT_TRUE(
@@ -679,6 +679,8 @@
 
   EXPECT_TRUE(matches(T, varDecl(hasName("y"), hasStaticStorageDuration(;
   EXPECT_TRUE(matches(T, varDecl(hasName("a"), hasStaticStorageDuration(;
+  EXPECT_TRUE(matches(T, varDecl(hasName("b"), hasStaticStorageDuration(;
+  EXPECT_TRUE(matches(T, varDecl(hasName("c"), hasStaticStorageDuration(;
   EXPECT_TRUE(notMatches(T, varDecl(hasName("x"), hasStaticStorageDuration(;
 
   // FIXME: It is really hard to test with thread_local itself because not all
@@ -853,6 +855,7 @@
   matches("static void f() {}", functionDecl(isStaticStorageClass(;
   EXPECT_TRUE(matches("static int i = 1;", varDecl(isStaticStorageClass(;
   EXPECT_TRUE(notMatches("int i = 1;", varDecl(isStaticStorageClass(;
+  EXPECT_TRUE(notMatches("extern int i;", varDecl(isStaticStorageClass(;
   EXPECT_TRUE(notMatches("void f() {}", functionDecl(isStaticStorageClass(;
 }
 
Index: cfe/trunk/docs/LibASTMatchersReference.html
===
--- cfe/trunk/docs/LibASTMatchersReference.html
+++ cfe/trunk/docs/LibASTMatchersReference.html
@@ -2611,12 +2611,14 @@
 
 
 MatcherFunctionDecl>isStaticStorageClass
-Matches variablefunction declarations that have static storage class
-(with "static" key word) written in the source.
+Matches variablefunction declarations that have "static" storage
+class specifier ("static" keyword) written in the source.
 
 Given:
   static void f() {}
   static int i = 0;
+  extern int j;
+  int k;
 functionDecl(isStaticStorageClass())
   matches the function declaration f.
 varDecl(isStaticStorageClass())
@@ -3394,15 +3396,19 @@
 
 MatcherVarDecl>hasStaticStorageDuration
 Matches a variable declaration that has static storage duration.
+It includes the variable declared at namespace scope and those declared
+with "static" and "extern" storage class specifiers.
 
-Example matches y and a, but not x or z.
-(matcher = varDecl(hasStaticStorageDuration())
 void f() {
   int x;
   static int y;
   thread_local int z;
 }
 int a;
+static int b;
+extern int c;
+varDecl(hasStaticStorageDuration())
+  matches the function declaration y, a, b and c.
 
 
 
@@ -3488,12 +3494,14 @@
 
 
 MatcherVarDecl>isStaticStorageClass
-Matches variablefunction declarations that have static storage class
-(with "static" key word) written in the source.
+Matches variablefunction declarations that have "static" storage
+class specifier ("static" keyword) written in the source.
 
 Given:
   static void f() {}
   static int i = 0;
+  extern int j;
+  int k;
 functionDecl(isStaticStorageClass())
   matches the function declaration f.
 varDecl(isStaticStorageClass())
Index: cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
===
--- cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
+++ cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
@@ -2943,16 +2943,20 @@
 }
 
 /// \brief Matches a variable declaration that has static storage duration.
+/// It includes the variable declared at namespace scope and those declared
+/// with "static" and "extern" storage class specifiers.
 ///
-/// Example matches y and a, but not x or z.
-/// (matcher = varDecl(hasStaticStorageDuration())
 /// \code
 /// void f() {
 ///   int x;
 ///   static int y;
 ///   thread_local int z;
 /// }
 /// int a;
+/// static int b;
+/// extern int c;
+/// varDecl(hasStaticStorageDuration())
+///   matches the function declaration y, a, b and c.
 /// \endcode
 AST_MATCHER(VarDecl, hasStaticStorageDuration) {
   return Node.getStorageDuration() == SD_Static;
@@ -3388,13 +3392,15 @@
   return Node.isExternC();
 }
 
-/// \brief Matches va

r282474 - [ASTMatcher] Clarify isStaticStorageClass and hasStaticStorageDuration documents.

2016-09-27 Thread Haojian Wu via cfe-commits
Author: hokein
Date: Tue Sep 27 02:53:20 2016
New Revision: 282474

URL: http://llvm.org/viewvc/llvm-project?rev=282474&view=rev
Log:
[ASTMatcher] Clarify isStaticStorageClass and hasStaticStorageDuration 
documents.

Reviewers: aaron.ballman

Subscribers: klimek, cfe-commits

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

Modified:
cfe/trunk/docs/LibASTMatchersReference.html
cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
cfe/trunk/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp

Modified: cfe/trunk/docs/LibASTMatchersReference.html
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LibASTMatchersReference.html?rev=282474&r1=282473&r2=282474&view=diff
==
--- cfe/trunk/docs/LibASTMatchersReference.html (original)
+++ cfe/trunk/docs/LibASTMatchersReference.html Tue Sep 27 02:53:20 2016
@@ -2611,12 +2611,14 @@ functionDecl(isNoThrow()) and functionPr
 
 
 MatcherFunctionDecl>isStaticStorageClass
-Matches 
variablefunction declarations that have static storage class
-(with "static" key word) written in the source.
+Matches 
variablefunction declarations that have "static" storage
+class specifier ("static" keyword) written in the source.
 
 Given:
   static void f() {}
   static int i = 0;
+  extern int j;
+  int k;
 functionDecl(isStaticStorageClass())
   matches the function declaration f.
 varDecl(isStaticStorageClass())
@@ -3394,15 +3396,19 @@ int z;
 
 MatcherVarDecl>hasStaticStorageDuration
 Matches a 
variable declaration that has static storage duration.
+It includes the variable declared at namespace scope and those declared
+with "static" and "extern" storage class specifiers.
 
-Example matches y and a, but not x or z.
-(matcher = varDecl(hasStaticStorageDuration())
 void f() {
   int x;
   static int y;
   thread_local int z;
 }
 int a;
+static int b;
+extern int c;
+varDecl(hasStaticStorageDuration())
+  matches the function declaration y, a, b and c.
 
 
 
@@ -3488,12 +3494,14 @@ functionDecl(isExternC())
 
 
 MatcherVarDecl>isStaticStorageClass
-Matches 
variablefunction declarations that have static storage class
-(with "static" key word) written in the source.
+Matches 
variablefunction declarations that have "static" storage
+class specifier ("static" keyword) written in the source.
 
 Given:
   static void f() {}
   static int i = 0;
+  extern int j;
+  int k;
 functionDecl(isStaticStorageClass())
   matches the function declaration f.
 varDecl(isStaticStorageClass())

Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h?rev=282474&r1=282473&r2=282474&view=diff
==
--- cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h (original)
+++ cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h Tue Sep 27 02:53:20 2016
@@ -2943,9 +2943,9 @@ AST_MATCHER(VarDecl, hasAutomaticStorage
 }
 
 /// \brief Matches a variable declaration that has static storage duration.
+/// It includes the variable declared at namespace scope and those declared
+/// with "static" and "extern" storage class specifiers.
 ///
-/// Example matches y and a, but not x or z.
-/// (matcher = varDecl(hasStaticStorageDuration())
 /// \code
 /// void f() {
 ///   int x;
@@ -2953,6 +2953,10 @@ AST_MATCHER(VarDecl, hasAutomaticStorage
 ///   thread_local int z;
 /// }
 /// int a;
+/// static int b;
+/// extern int c;
+/// varDecl(hasStaticStorageDuration())
+///   matches the function declaration y, a, b and c.
 /// \endcode
 AST_MATCHER(VarDecl, hasStaticStorageDuration) {
   return Node.getStorageDuration() == SD_Static;
@@ -3388,13 +3392,15 @@ AST_POLYMORPHIC_MATCHER(isExternC, AST_P
   return Node.isExternC();
 }
 
-/// \brief Matches variable/function declarations that have static storage 
class
-/// (with "static" key word) written in the source.
+/// \brief Matches variable/function declarations that have "static" storage
+/// class specifier ("static" keyword) written in the source.
 ///
 /// Given:
 /// \code
 ///   static void f() {}
 ///   static int i = 0;
+///   extern int j;
+///   int k;
 /// \endcode
 /// functionDecl(isStaticStorageClass())
 ///   matches the function declaration f.

Modified: cfe/trunk/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp?rev=282474&r1=282473&r2=282474&view=diff
==
--- cfe/trunk/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp (original)
+++ cfe/trunk/unittests/ASTMatchers/ASTMatchersNarrowingTest.cpp Tue Sep 27 
02:53:20 2016
@@ -669,7 +669,7 @@ TEST(Match

[libcxx] r282475 - [cmake] Strip possibly-inherited compiler flags in in-tree build only

2016-09-27 Thread Michal Gorny via cfe-commits
Author: mgorny
Date: Tue Sep 27 02:55:26 2016
New Revision: 282475

URL: http://llvm.org/viewvc/llvm-project?rev=282475&view=rev
Log:
[cmake] Strip possibly-inherited compiler flags in in-tree build only

Strip the set of flags (including debug defs, -m32) that could
be inherited from top-level LLVM build only when in-tree build is
performed. This prevents libcxx from confusingly and undesiredly
stripping user-supplied flags e.g. when performing packaging system
controlled multi-ABI build.

Otherwise, in order to perform 32-bit builds the build scripts would
have to use LIBCXX_BUILD_32_BITS. However, -m32 is only one of the many
different ABI flags for different targets, and it really makes no sense
to add separate CMake options for each possible -m* flag and then keep
a mapping from well-known flags to the custom CMake options.

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

Modified:
libcxx/trunk/CMakeLists.txt

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=282475&r1=282474&r2=282475&view=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Tue Sep 27 02:55:26 2016
@@ -307,9 +307,12 @@ string(TOUPPER "${CMAKE_BUILD_TYPE}" upp
 
 include(HandleLibCXXABI) # Setup the ABI library flags
 
-# Remove flags that may have snuck in.
-remove_flags(-DNDEBUG -UNDEBUG -D_DEBUG
- -stdlib=libc++ -stdlib=libstdc++ -lc++abi -m32)
+if (NOT LIBCXX_STANDALONE_BUILD)
+  # Remove flags that may have snuck in.
+  remove_flags(-DNDEBUG -UNDEBUG -D_DEBUG
+   -lc++abi -m32)
+endif()
+remove_flags(-stdlib=libc++ -stdlib=libstdc++)
 
 # FIXME(EricWF): See the FIXME on LIBCXX_ENABLE_PEDANTIC.
 # Remove the -pedantic flag and -Wno-pedantic and -pedantic-errors


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


Re: [PATCH] D24809: [libcxx] [cmake] Strip possibly-inherited compiler flags in in-tree build only

2016-09-27 Thread Michał Górny via cfe-commits
This revision was automatically updated to reflect the committed changes.
mgorny marked an inline comment as done.
Closed by commit rL282475: [cmake] Strip possibly-inherited compiler flags in 
in-tree build only (authored by mgorny).

Changed prior to commit:
  https://reviews.llvm.org/D24809?vs=72602&id=72611#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D24809

Files:
  libcxx/trunk/CMakeLists.txt

Index: libcxx/trunk/CMakeLists.txt
===
--- libcxx/trunk/CMakeLists.txt
+++ libcxx/trunk/CMakeLists.txt
@@ -307,9 +307,12 @@
 
 include(HandleLibCXXABI) # Setup the ABI library flags
 
-# Remove flags that may have snuck in.
-remove_flags(-DNDEBUG -UNDEBUG -D_DEBUG
- -stdlib=libc++ -stdlib=libstdc++ -lc++abi -m32)
+if (NOT LIBCXX_STANDALONE_BUILD)
+  # Remove flags that may have snuck in.
+  remove_flags(-DNDEBUG -UNDEBUG -D_DEBUG
+   -lc++abi -m32)
+endif()
+remove_flags(-stdlib=libc++ -stdlib=libstdc++)
 
 # FIXME(EricWF): See the FIXME on LIBCXX_ENABLE_PEDANTIC.
 # Remove the -pedantic flag and -Wno-pedantic and -pedantic-errors


Index: libcxx/trunk/CMakeLists.txt
===
--- libcxx/trunk/CMakeLists.txt
+++ libcxx/trunk/CMakeLists.txt
@@ -307,9 +307,12 @@
 
 include(HandleLibCXXABI) # Setup the ABI library flags
 
-# Remove flags that may have snuck in.
-remove_flags(-DNDEBUG -UNDEBUG -D_DEBUG
- -stdlib=libc++ -stdlib=libstdc++ -lc++abi -m32)
+if (NOT LIBCXX_STANDALONE_BUILD)
+  # Remove flags that may have snuck in.
+  remove_flags(-DNDEBUG -UNDEBUG -D_DEBUG
+   -lc++abi -m32)
+endif()
+remove_flags(-stdlib=libc++ -stdlib=libstdc++)
 
 # FIXME(EricWF): See the FIXME on LIBCXX_ENABLE_PEDANTIC.
 # Remove the -pedantic flag and -Wno-pedantic and -pedantic-errors
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D24809: [libcxx] [cmake] Strip possibly-inherited compiler flags in in-tree build only

2016-09-27 Thread Michał Górny via cfe-commits
mgorny marked an inline comment as done.
mgorny added a comment.

Thanks for the review. Tested and committing now.



Comment at: CMakeLists.txt:310
@@ -309,4 +309,3 @@
 
-# Remove flags that may have snuck in.
-remove_flags(-DNDEBUG -UNDEBUG -D_DEBUG
- -stdlib=libc++ -stdlib=libstdc++ -lc++abi -m32)
+if (LIBCXX_STANDALONE_BUILD)
+  # Remove flags that may have snuck in.

EricWF wrote:
> We always want to strip `-stdlib=` because it's just nonsense to enable 
> the STL while building the STL.
Ok, moved it below the endif().


https://reviews.llvm.org/D24809



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


[clang-tools-extra] r282476 - [clang-tidy] Use isStaticStorageClass ast matcher.

2016-09-27 Thread Haojian Wu via cfe-commits
Author: hokein
Date: Tue Sep 27 02:58:52 2016
New Revision: 282476

URL: http://llvm.org/viewvc/llvm-project?rev=282476&view=rev
Log:
[clang-tidy] Use isStaticStorageClass ast matcher.

Modified:

clang-tools-extra/trunk/clang-tidy/readability/StaticDefinitionInAnonymousNamespaceCheck.cpp

Modified: 
clang-tools-extra/trunk/clang-tidy/readability/StaticDefinitionInAnonymousNamespaceCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/StaticDefinitionInAnonymousNamespaceCheck.cpp?rev=282476&r1=282475&r2=282476&view=diff
==
--- 
clang-tools-extra/trunk/clang-tidy/readability/StaticDefinitionInAnonymousNamespaceCheck.cpp
 (original)
+++ 
clang-tools-extra/trunk/clang-tidy/readability/StaticDefinitionInAnonymousNamespaceCheck.cpp
 Tue Sep 27 02:58:52 2016
@@ -18,20 +18,14 @@ namespace clang {
 namespace tidy {
 namespace readability {
 
-namespace {
-AST_POLYMORPHIC_MATCHER(isStatic, AST_POLYMORPHIC_SUPPORTED_TYPES(FunctionDecl,
-  VarDecl)) {
-  return Node.getStorageClass() == SC_Static;
-}
-} // namespace
-
 void StaticDefinitionInAnonymousNamespaceCheck::registerMatchers(
 MatchFinder *Finder) {
-  Finder->addMatcher(namedDecl(anyOf(functionDecl(isDefinition(), isStatic()),
- varDecl(isDefinition(), isStatic())),
-   hasParent(namespaceDecl(isAnonymous(
- .bind("static-def"),
- this);
+  Finder->addMatcher(
+  namedDecl(anyOf(functionDecl(isDefinition(), isStaticStorageClass()),
+  varDecl(isDefinition(), isStaticStorageClass())),
+hasParent(namespaceDecl(isAnonymous(
+  .bind("static-def"),
+  this);
 }
 
 void StaticDefinitionInAnonymousNamespaceCheck::check(


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


[clang-tools-extra] r282477 - [clang-move] Use isStaticStorageClass matcher.

2016-09-27 Thread Haojian Wu via cfe-commits
Author: hokein
Date: Tue Sep 27 03:01:04 2016
New Revision: 282477

URL: http://llvm.org/viewvc/llvm-project?rev=282477&view=rev
Log:
[clang-move] Use isStaticStorageClass matcher.

Modified:
clang-tools-extra/trunk/clang-move/ClangMove.cpp

Modified: clang-tools-extra/trunk/clang-move/ClangMove.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-move/ClangMove.cpp?rev=282477&r1=282476&r2=282477&view=diff
==
--- clang-tools-extra/trunk/clang-move/ClangMove.cpp (original)
+++ clang-tools-extra/trunk/clang-move/ClangMove.cpp Tue Sep 27 03:01:04 2016
@@ -23,12 +23,6 @@ namespace clang {
 namespace move {
 namespace {
 
-// FIXME: Move to ASTMatcher.
-AST_POLYMORPHIC_MATCHER(isStatic, AST_POLYMORPHIC_SUPPORTED_TYPES(FunctionDecl,
-  VarDecl)) {
-  return Node.getStorageClass() == SC_Static;
-}
-
 class FindAllIncludes : public clang::PPCallbacks {
 public:
   explicit FindAllIncludes(SourceManager *SM, ClangMoveTool *const MoveTool)
@@ -241,9 +235,9 @@ void ClangMoveTool::registerMatchers(ast
   // Match static functions/variabale definitions in old cc.
   Finder->addMatcher(
   namedDecl(anyOf(functionDecl(isDefinition(), unless(InMovedClass),
-   isStatic(), InOldCC),
-  varDecl(isDefinition(), unless(InMovedClass), isStatic(),
-  InOldCC)))
+   isStaticStorageClass(), InOldCC),
+  varDecl(isDefinition(), unless(InMovedClass),
+  isStaticStorageClass(), InOldCC)))
   .bind("static_decls"),
   this);
 


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


Re: [PATCH] D24922: [clang-move] Make it support both relative and absolute file path arguments.

2016-09-27 Thread Haojian Wu via cfe-commits
hokein updated this revision to Diff 72613.
hokein added a comment.

Rebase to master


https://reviews.llvm.org/D24922

Files:
  clang-move/ClangMove.cpp
  clang-move/ClangMove.h
  clang-move/tool/ClangMoveMain.cpp
  test/clang-move/Inputs/database_template.json
  test/clang-move/Inputs/test.cpp
  test/clang-move/Inputs/test.h
  test/clang-move/move-class.cpp
  unittests/clang-move/ClangMoveTests.cpp

Index: unittests/clang-move/ClangMoveTests.cpp
===
--- unittests/clang-move/ClangMoveTests.cpp
+++ unittests/clang-move/ClangMoveTests.cpp
@@ -156,9 +156,12 @@
   CreateFiles(Spec.OldCC, TestCC);
 
   std::map FileToReplacements;
-  ClangMoveTool MoveTool(Spec, FileToReplacements);
+  llvm::SmallString<128> InitialDirectory;
+  std::error_code EC = llvm::sys::fs::current_path(InitialDirectory);
+  assert(!EC);
+  (void)EC;
   auto Factory = llvm::make_unique(
-  Spec, FileToReplacements);
+  Spec, FileToReplacements, InitialDirectory.str());
 
   tooling::runToolOnCodeWithArgs(
   Factory->create(), TestCC, {"-std=c++11"}, TestCCName, "clang-move",
Index: test/clang-move/move-class.cpp
===
--- /dev/null
+++ test/clang-move/move-class.cpp
@@ -0,0 +1,39 @@
+// RUN: mkdir -p %T/clang-move/build
+// RUN: sed 's|test_dir|%/T/clang-move|g' %S/Inputs/database_template.json > %T/clang-move/compile_commands.json
+// RUN: cp %S/Inputs/test*  %T/clang-move/
+// RUN: touch test2.h
+// RUN: cd %T/clang-move
+// RUN: clang-move -name="a::Foo" -new_cc=%T/clang-move/new_test.cpp -new_header=%T/clang-move/new_test.h -old_cc=../clang-move/test.cpp -old_header=../clang-move/test.h %T/clang-move/test.cpp
+// RUN: FileCheck -input-file=%T/clang-move/new_test.cpp -check-prefix=CHECK-NEW-TEST-CPP %s
+// RUN: FileCheck -input-file=%T/clang-move/new_test.h -check-prefix=CHECK-NEW-TEST-H %s
+// RUN: FileCheck -input-file=%T/clang-move/test.cpp -check-prefix=CHECK-OLD-TEST-CPP %s
+// RUN: FileCheck -input-file=%T/clang-move/test.h -check-prefix=CHECK-OLD-TEST-H %s
+//
+// RUN: cp %S/Inputs/test*  %T/clang-move/
+// RUN: cd %T/clang-move
+// RUN: clang-move -name="a::Foo" -new_cc=%T/clang-move/new_test.cpp -new_header=%T/clang-move/new_test.h -old_cc=%T/clang-move/test.cpp -old_header=%T/clang-move/test.h %T/clang-move/test.cpp
+// RUN: FileCheck -input-file=%T/clang-move/new_test.cpp -check-prefix=CHECK-NEW-TEST-CPP %s
+// RUN: FileCheck -input-file=%T/clang-move/new_test.h -check-prefix=CHECK-NEW-TEST-H %s
+// RUN: FileCheck -input-file=%T/clang-move/test.cpp -check-prefix=CHECK-OLD-TEST-CPP %s
+// RUN: FileCheck -input-file=%T/clang-move/test.h -check-prefix=CHECK-OLD-TEST-H %s
+//
+// CHECK-NEW-TEST-H: namespace a {
+// CHECK-NEW-TEST-H: class Foo {
+// CHECK-NEW-TEST-H: public:
+// CHECK-NEW-TEST-H:   int f();
+// CHECK-NEW-TEST-H: };
+// CHECK-NEW-TEST-H: } // namespace a
+//
+// CHECK-NEW-TEST-CPP: #include "{{.*}}new_test.h"
+// CHECK-NEW-TEST-CPP: #include "test2.h"
+// CHECK-NEW-TEST-CPP: namespace a {
+// CHECK-NEW-TEST-CPP: int Foo::f() { return 0; }
+// CHECK-NEW-TEST-CPP: } // namespace a
+//
+// CHECK-OLD-TEST-H: namespace a {
+// CHECK-OLD-TEST-H: } // namespace a
+//
+// CHECK-OLD-TEST-CPP: #include "test.h"
+// CHECK-OLD-TEST-CPP: #include "test2.h"
+// CHECK-OLD-TEST-CPP: namespace a {
+// CHECK-OLD-TEST-CPP: } // namespace a
Index: test/clang-move/Inputs/test.h
===
--- /dev/null
+++ test/clang-move/Inputs/test.h
@@ -0,0 +1,6 @@
+namespace a {
+class Foo {
+public:
+  int f();
+};
+} // namespace a
Index: test/clang-move/Inputs/test.cpp
===
--- /dev/null
+++ test/clang-move/Inputs/test.cpp
@@ -0,0 +1,8 @@
+#include "test.h"
+#include "test2.h"
+
+namespace a {
+int Foo::f() {
+  return 0;
+}
+} // namespace a
Index: test/clang-move/Inputs/database_template.json
===
--- /dev/null
+++ test/clang-move/Inputs/database_template.json
@@ -0,0 +1,7 @@
+[
+{
+  "directory": "test_dir/build",
+  "command": "clang++ -o test.o test_dir/test.cpp",
+  "file": "test_dir/test.cpp"
+}
+]
Index: clang-move/tool/ClangMoveMain.cpp
===
--- clang-move/tool/ClangMoveMain.cpp
+++ clang-move/tool/ClangMoveMain.cpp
@@ -17,13 +17,15 @@
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/Process.h"
 #include "llvm/Support/YAMLTraits.h"
+#include "llvm/Support/Path.h"
 #include 
 #include 
 
 using namespace clang;
 using namespace llvm;
 
 namespace {
+
 std::error_code CreateNewFile(const llvm::Twine &path) {
   int fd = 0;
   if (std::error_code ec =
@@ -38,17 +40,23 @@
 cl::opt Name("name", cl::desc("The name of class being moved."),
   cl::cat(ClangMoveCategory));
 
-cl::opt OldHeader("old_header", cl::desc("Old heade

Re: [PATCH] D14326: ASTImporter: expressions, pt.2

2016-09-27 Thread Aleksei Sidorin via cfe-commits
a.sidorin updated the summary for this revision.
a.sidorin added reviewers: ABataev, aaron.ballman.
a.sidorin updated this revision to Diff 72614.
a.sidorin added a comment.

Merge patch https://reviews.llvm.org/D24807 to both fix segmentation fault and 
provide a test for it.


https://reviews.llvm.org/D14326

Files:
  include/clang/AST/ASTImporter.h
  include/clang/AST/DeclFriend.h
  lib/AST/ASTImporter.cpp
  lib/Serialization/ASTReaderStmt.cpp
  lib/Serialization/ASTWriterStmt.cpp
  test/ASTMerge/Inputs/class3.cpp
  test/ASTMerge/class2.cpp
  test/ASTMerge/exprs.cpp
  unittests/AST/ASTImporterTest.cpp

Index: unittests/AST/ASTImporterTest.cpp
===
--- unittests/AST/ASTImporterTest.cpp
+++ unittests/AST/ASTImporterTest.cpp
@@ -456,5 +456,24 @@
 }
 
 
+const internal::VariadicDynCastAllOfMatcher vaArgExpr;
+
+TEST(ImportExpr, ImportVAArgExpr) {
+  MatchVerifier Verifier;
+  EXPECT_TRUE(
+testImport(
+  "void declToImport(__builtin_va_list list, ...) {"
+  "  (void)__builtin_va_arg(list, int); }",
+  Lang_CXX, "", Lang_CXX, Verifier,
+  functionDecl(
+hasBody(
+  compoundStmt(
+has(
+  cStyleCastExpr(
+hasSourceExpression(
+  vaArgExpr();
+}
+
+
 } // end namespace ast_matchers
 } // end namespace clang
Index: test/ASTMerge/exprs.cpp
===
--- /dev/null
+++ test/ASTMerge/exprs.cpp
@@ -0,0 +1,45 @@
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++1z -fcxx-exceptions -emit-pch -o %t.1.ast %S/Inputs/exprs3.cpp
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++1z -fcxx-exceptions -ast-merge %t.1.ast -fsyntax-only -verify %s
+// expected-no-diagnostics
+
+static_assert(Ch1 == 'a');
+static_assert(Ch2 == 'b');
+static_assert(Ch3 == 'c');
+
+static_assert(Ch4 == L'd');
+static_assert(Ch5 == L'e');
+static_assert(Ch6 == L'f');
+
+static_assert(C1 == 12);
+static_assert(C2 == 13);
+
+static_assert(C3 == 12);
+static_assert(C4 == 13);
+
+static_assert(C5 == 22L);
+static_assert(C6 == 23L);
+
+static_assert(C7 == 66LL);
+static_assert(C8 == 67ULL);
+
+static_assert(bval1 == true);
+static_assert(bval2 == false);
+
+static_assert(ExpressionTrait == false);
+
+static_assert(ArrayRank == 2);
+static_assert(ArrayExtent == 20);
+
+void testImport(int *x, const S1 &cs1, S1 &s1) {
+  testNewThrowDelete();
+  testArrayElement(nullptr, 12);
+  testTernaryOp(0, 1, 2);
+  testConstCast(cs1);
+  testStaticCast(s1);
+  testReinterpretCast(s1);
+  testDynamicCast(s1);
+  testScalarInit(42);
+  testOffsetOf();
+  testDefaultArg(12);
+  useTemplateType();
+}
Index: test/ASTMerge/class2.cpp
===
--- /dev/null
+++ test/ASTMerge/class2.cpp
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++1z -emit-pch -o %t.1.ast %S/Inputs/class3.cpp
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++1z -ast-merge %t.1.ast -fsyntax-only -verify %s
+// expected-no-diagnostics
+
+class C3 {
+  int method_1(C2 *x) {
+return x->x;
+  }
+};
Index: test/ASTMerge/Inputs/class3.cpp
===
--- /dev/null
+++ test/ASTMerge/Inputs/class3.cpp
@@ -0,0 +1,26 @@
+class C1 {
+public:
+  C1();
+  ~C1();
+  C1 *method_1() {
+return this;
+  }
+  C1 method_2() {
+return C1();
+  }
+  void method_3() {
+const C1 &ref = C1();
+  }
+};
+
+class C11 : public C1 {
+};
+
+class C2 {
+private:
+  int x;
+  friend class C3;
+public:
+  static_assert(sizeof(x) == sizeof(int), "Error");
+  typedef class C2::C2 InjType;
+};
Index: lib/Serialization/ASTWriterStmt.cpp
===
--- lib/Serialization/ASTWriterStmt.cpp
+++ lib/Serialization/ASTWriterStmt.cpp
@@ -1576,6 +1576,7 @@
   Record.push_back(E->getValue());
   Record.AddSourceRange(E->getSourceRange());
   Record.AddTypeSourceInfo(E->getQueriedTypeSourceInfo());
+  Record.AddStmt(E->getDimensionExpression());
   Code = serialization::EXPR_ARRAY_TYPE_TRAIT;
 }
 
Index: lib/Serialization/ASTReaderStmt.cpp
===
--- lib/Serialization/ASTReaderStmt.cpp
+++ lib/Serialization/ASTReaderStmt.cpp
@@ -1575,6 +1575,7 @@
   E->Loc = Range.getBegin();
   E->RParen = Range.getEnd();
   E->QueriedType = GetTypeSourceInfo(Record, Idx);
+  E->Dimension = Reader.ReadSubExpr();
 }
 
 void ASTStmtReader::VisitExpressionTraitExpr(ExpressionTraitExpr *E) {
Index: lib/AST/ASTImporter.cpp
===
--- lib/AST/ASTImporter.cpp
+++ lib/AST/ASTImporter.cpp
@@ -40,6 +40,7 @@
 // Importing types
 QualType VisitType(const Type *T);
 QualType VisitBuiltinType(const BuiltinType *T);
+QualType VisitDecayedType(const DecayedType *T

Re: [PATCH] D24914: [clang-rename] Do not print out error message upon encountering multiple replacements in the same SourceLocation.

2016-09-27 Thread Kirill Bobyrev via cfe-commits
omtcyfz added inline comments.


Comment at: clang-rename/RenamingAction.cpp:74
@@ +73,3 @@
+  // FIXME: As for clang-rename, adding a replacement fails IFF either the
+  // AST node has been matched multiple times (which shouldn't happen in
+  // reality, need to fix that). For now, just ignore the error as it

alexshap wrote:
> omtcyfz wrote:
> > alexshap wrote:
> > > Let's consider the following example:
> > > src/include/Point.h:
> > >struct Point {};
> > > src/a.cpp: 
> > >include 
> > > src/b.cpp:
> > >include 
> > > clang-rename -qualified-name Point -new-name Point2 srcs/a.cpp srcs/b.cpp
> > > Renaming failed in /Users/Alexshap/PlayRename/srcs/./include/Point.h! New 
> > > replacement:
> > > /Users/Alexshap/PlayRename/srcs/./include/Point.h: 7:+5:"Point2"
> > > conflicts with existing replacement:
> > > /Users/Alexshap/PlayRename/srcs/./include/Point.h: 7:+5:"Point2"
> > > 
> > > The thing is that clang-rename is trying to modify the same code twice 
> > > (as in the example) and the return value (Error) of the method 
> > > Replacements::add doesn't allow us to distinguish two cases: A. conflict 
> > > (trying to apply different modifications to the same source code) B. 
> > > (still conflict, but different) (trying to apply the same modification 
> > > twice). 
> > > In the past when Replacements was a typedef on std::set and clang-rename 
> > > was using insert(...) the case B wasn't an issue. 
> > > P.S. However (imo) the new (FIXME) comment seems to be a little bit 
> > > misleading.
> > But the thing is that it's never the A. case. Unlike other refactorings, 
> > clang-rename doesn't introduce any name conflicts, it will only sometimes 
> > try to rename something multiple times.
> Yup
Hence, I'm not sure what your concern is. Can you please elaborate?


https://reviews.llvm.org/D24914



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


Re: [PATCH] D24914: [clang-rename] Do not print out error message upon encountering multiple replacements in the same SourceLocation.

2016-09-27 Thread Kirill Bobyrev via cfe-commits
omtcyfz updated this revision to Diff 72616.
omtcyfz added a comment.

Slightly change wording.


https://reviews.llvm.org/D24914

Files:
  clang-rename/RenamingAction.cpp

Index: clang-rename/RenamingAction.cpp
===
--- clang-rename/RenamingAction.cpp
+++ clang-rename/RenamingAction.cpp
@@ -68,12 +68,15 @@
<< ":" << FullLoc.getSpellingLineNumber() << ":"
<< FullLoc.getSpellingColumnNumber() << "\n";
   }
-  // FIXME: better error handling.
   tooling::Replacement Replace(SourceMgr, Loc, PrevNameLen, NewName);
   llvm::Error Err = FileToReplaces[Replace.getFilePath()].add(Replace);
+  // FIXME: An error might happen here if USRLocFinder finds the symbol
+  // twice or if the symbol happens to be in a header included multiple
+  // times independently. Such error doesn't mean clang-rename failure and
+  // therefore should be suppressed. However, more careful error handling
+  // might be better.
   if (Err)
-llvm::errs() << "Renaming failed in " << Replace.getFilePath() << "! "
- << llvm::toString(std::move(Err)) << "\n";
+llvm::consumeError(std::move(Err));
 }
   }
 


Index: clang-rename/RenamingAction.cpp
===
--- clang-rename/RenamingAction.cpp
+++ clang-rename/RenamingAction.cpp
@@ -68,12 +68,15 @@
<< ":" << FullLoc.getSpellingLineNumber() << ":"
<< FullLoc.getSpellingColumnNumber() << "\n";
   }
-  // FIXME: better error handling.
   tooling::Replacement Replace(SourceMgr, Loc, PrevNameLen, NewName);
   llvm::Error Err = FileToReplaces[Replace.getFilePath()].add(Replace);
+  // FIXME: An error might happen here if USRLocFinder finds the symbol
+  // twice or if the symbol happens to be in a header included multiple
+  // times independently. Such error doesn't mean clang-rename failure and
+  // therefore should be suppressed. However, more careful error handling
+  // might be better.
   if (Err)
-llvm::errs() << "Renaming failed in " << Replace.getFilePath() << "! "
- << llvm::toString(std::move(Err)) << "\n";
+llvm::consumeError(std::move(Err));
 }
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D24922: [clang-move] Make it support both relative and absolute file path arguments.

2016-09-27 Thread Eric Liu via cfe-commits
ioeric added inline comments.


Comment at: clang-move/ClangMove.cpp:33
@@ +32,3 @@
+  auto EC = llvm::sys::fs::make_absolute(InitialDirectory, AbsolutePath);
+  assert(!EC);
+  (void)EC;

This doesn't seems to be good error handling... maybe also print an error 
message in case this fails in release binary.


Comment at: clang-move/ClangMove.cpp:39
@@ +38,3 @@
+
+std::string MakeAbsolutePath(const SourceManager& SM, StringRef Path) {
+  llvm::SmallString<128> AbsolutePath(Path);

There are two versions of this. Please add comments about the differences.


Comment at: clang-move/ClangMove.cpp:43
@@ +42,3 @@
+  SM.getFileManager().getVirtualFileSystem()->makeAbsolute(AbsolutePath);
+  assert(!EC);
+  (void)EC;

Same as above. Error handling.


Comment at: clang-move/ClangMove.cpp:62
@@ +61,3 @@
+  return MakeAbsolutePath(SourceManager, FileEntry->getName()) ==
+ AbsoluteFilePath;
+}

To generalize the function, maybe also remove dots in `AbsoluteFilePath`?


Comment at: clang-move/ClangMove.cpp:78
@@ -38,2 +77,3 @@
 if (const auto *FileEntry = SM.getFileEntryForID(SM.getFileID(HashLoc)))
-  MoveTool->addIncludes(FileName, IsAngled, FileEntry->getName());
+  MoveTool->addIncludes(FileName, MakeAbsolutePath(SM, SearchPath),
+IsAngled, FileEntry->getName(), SM);

Looks like `MakeAbsolutePath(SM, SearchPath)` can be done in `addIncludes` 
since you are also passing `SM`.


Comment at: clang-move/ClangMove.cpp:109
@@ -68,3 +108,3 @@
 bool IsInHeaderFile(const clang::SourceManager &SM, const clang::Decl *D,
-llvm::StringRef HeaderFile) {
-  if (HeaderFile.empty())
+llvm::StringRef OldHeader,
+llvm::StringRef OriginalRunningDirectory) {

I think it would be easier to read if you put `OriginalRunningDirectory` before 
`OldHeader` .


Comment at: clang-move/ClangMove.h:63
@@ -57,3 +62,3 @@
   // comes from.
-  void addIncludes(llvm::StringRef IncludeHeader, bool IsAngled,
-   llvm::StringRef FileName);
+  void addIncludes(llvm::StringRef IncludeHeader,
+   llvm::StringRef SearchPath,

This function could use more comments. What are those parameters and what are 
they for?


Comment at: clang-move/ClangMove.h:64
@@ +63,3 @@
+  void addIncludes(llvm::StringRef IncludeHeader,
+   llvm::StringRef SearchPath,
+   bool IsAngled,

Should `SearchPath` be absolute or relative?


Comment at: clang-move/ClangMove.h:88
@@ +87,3 @@
+  // clang-move will change its current working directory to the build
+  // directory when analysising the source file. We saves the original working
+  // directory in order to get the absolute file path for the fields in Spec.

s/saves/save the/


https://reviews.llvm.org/D24922



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


Re: [PATCH] D24719: [include-fixer] Add customized editor settings documents.

2016-09-27 Thread Benjamin Kramer via cfe-commits
bkramer accepted this revision.
bkramer added a comment.
This revision is now accepted and ready to land.

lg


https://reviews.llvm.org/D24719



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


Re: [PATCH] D24861: [Sema] extend Wshift-op-parentheses so it warns for multiplicative operators

2016-09-27 Thread Daniel Marjamäki via cfe-commits
danielmarjamaki added a comment.

Compiling 2064 projects resulted in 904 warnings

Here are the results:
https://drive.google.com/file/d/0BykPmWrCOxt2N04tYl8zVHA3MXc/view?usp=sharing

The results looks acceptable imho. The code looks intentional in many cases so 
I believe there are users that will disable this warning. Probably there are 
true positives where the evaluation order is not really known. There were many 
warnings about macro arguments where the macro bitshifts the argument - these 
macros look very shaky to me.

I saw some warnings about such code:

  a * b << c

Maybe we should not warn about this. As far as I see, the result will be the 
same if (a*b) or (b

Re: [PATCH] D14326: ASTImporter: expressions, pt.2

2016-09-27 Thread Alexey Bataev via cfe-commits
ABataev added inline comments.


Comment at: lib/AST/ASTImporter.cpp:3414
@@ +3413,3 @@
+  // FriendDecl is not a NamedDecl so we cannot use localUncachedLookup.
+  CXXRecordDecl *RD = cast(DC);
+  FriendDecl *ImportedFriend = RD->getFirstFriend();

CXXRecordDecl *RD -> auto *RD


Comment at: lib/AST/ASTImporter.cpp:5569
@@ +5568,3 @@
+return nullptr;
+  else
+ToTAInfo.addArgument(ToTALoc);

No need for 'else' here, unconditional statement


Comment at: lib/AST/ASTImporter.cpp:5583
@@ -5414,3 +5582,3 @@
  FoundD,
- /*FIXME:TemplateArgs=*/nullptr);
+ /*TemplateArgs=*/ResInfo);
   if (E->hadMultipleCandidates())

Remove '/*TemplateArgs=*/' comment, it is not required anymore


https://reviews.llvm.org/D14326



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


Re: [PATCH] D24954: [ToolChains] Disable OpenSUSE rules for SLES10

2016-09-27 Thread Michał Górny via cfe-commits
mgorny retitled this revision from "[ToolChains] Do not assume OpenSUSE for 
other SUSE variants" to "[ToolChains] Disable OpenSUSE rules for SLES10".
mgorny updated the summary for this revision.
mgorny updated this revision to Diff 72609.
mgorny added a comment.

Does this one look better for you? Yes, I know it's unsupported, that's why I 
don't really want to put any more effort on it than it is absolutely necessary 
to make clang work somehow.


https://reviews.llvm.org/D24954

Files:
  lib/Driver/ToolChains.cpp

Index: lib/Driver/ToolChains.cpp
===
--- lib/Driver/ToolChains.cpp
+++ lib/Driver/ToolChains.cpp
@@ -3912,8 +3912,11 @@
 return UnknownDistro;
   }
 
-  if (D.getVFS().exists("/etc/SuSE-release"))
-return OpenSUSE;
+  File = llvm::MemoryBuffer::getFile("/etc/SuSE-release");
+  if (File)
+return llvm::StringSwitch(File.get()->getBuffer())
+  .StartsWith("SUSE Linux Enterprise Server 10", UnknownDistro)
+  .Default(OpenSUSE);
 
   if (D.getVFS().exists("/etc/exherbo-release"))
 return Exherbo;


Index: lib/Driver/ToolChains.cpp
===
--- lib/Driver/ToolChains.cpp
+++ lib/Driver/ToolChains.cpp
@@ -3912,8 +3912,11 @@
 return UnknownDistro;
   }
 
-  if (D.getVFS().exists("/etc/SuSE-release"))
-return OpenSUSE;
+  File = llvm::MemoryBuffer::getFile("/etc/SuSE-release");
+  if (File)
+return llvm::StringSwitch(File.get()->getBuffer())
+  .StartsWith("SUSE Linux Enterprise Server 10", UnknownDistro)
+  .Default(OpenSUSE);
 
   if (D.getVFS().exists("/etc/exherbo-release"))
 return Exherbo;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D24922: [clang-move] Make it support both relative and absolute file path arguments.

2016-09-27 Thread Haojian Wu via cfe-commits
hokein added inline comments.


Comment at: clang-move/ClangMove.cpp:62
@@ +61,3 @@
+  return MakeAbsolutePath(SourceManager, FileEntry->getName()) ==
+ AbsoluteFilePath;
+}

ioeric wrote:
> To generalize the function, maybe also remove dots in `AbsoluteFilePath`?
`AbsoluteFilePath` has been removed dots, and the matcher here is only used 
internally by clang-move, so I'd prefer the current way here, if we meet the 
generalized case in the future, I will be happy to extend it.


https://reviews.llvm.org/D24922



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


Re: [PATCH] D24922: [clang-move] Make it support both relative and absolute file path arguments.

2016-09-27 Thread Haojian Wu via cfe-commits
hokein updated this revision to Diff 72619.
hokein marked 8 inline comments as done.
hokein added a comment.

Address review comments.


https://reviews.llvm.org/D24922

Files:
  clang-move/ClangMove.cpp
  clang-move/ClangMove.h
  clang-move/tool/ClangMoveMain.cpp
  test/clang-move/Inputs/database_template.json
  test/clang-move/Inputs/test.cpp
  test/clang-move/Inputs/test.h
  test/clang-move/move-class.cpp
  unittests/clang-move/ClangMoveTests.cpp

Index: unittests/clang-move/ClangMoveTests.cpp
===
--- unittests/clang-move/ClangMoveTests.cpp
+++ unittests/clang-move/ClangMoveTests.cpp
@@ -156,9 +156,12 @@
   CreateFiles(Spec.OldCC, TestCC);
 
   std::map FileToReplacements;
-  ClangMoveTool MoveTool(Spec, FileToReplacements);
+  llvm::SmallString<128> InitialDirectory;
+  std::error_code EC = llvm::sys::fs::current_path(InitialDirectory);
+  assert(!EC);
+  (void)EC;
   auto Factory = llvm::make_unique(
-  Spec, FileToReplacements);
+  Spec, FileToReplacements, InitialDirectory.str());
 
   tooling::runToolOnCodeWithArgs(
   Factory->create(), TestCC, {"-std=c++11"}, TestCCName, "clang-move",
Index: test/clang-move/move-class.cpp
===
--- /dev/null
+++ test/clang-move/move-class.cpp
@@ -0,0 +1,39 @@
+// RUN: mkdir -p %T/clang-move/build
+// RUN: sed 's|test_dir|%/T/clang-move|g' %S/Inputs/database_template.json > %T/clang-move/compile_commands.json
+// RUN: cp %S/Inputs/test*  %T/clang-move/
+// RUN: touch test2.h
+// RUN: cd %T/clang-move
+// RUN: clang-move -name="a::Foo" -new_cc=%T/clang-move/new_test.cpp -new_header=%T/clang-move/new_test.h -old_cc=../clang-move/test.cpp -old_header=../clang-move/test.h %T/clang-move/test.cpp
+// RUN: FileCheck -input-file=%T/clang-move/new_test.cpp -check-prefix=CHECK-NEW-TEST-CPP %s
+// RUN: FileCheck -input-file=%T/clang-move/new_test.h -check-prefix=CHECK-NEW-TEST-H %s
+// RUN: FileCheck -input-file=%T/clang-move/test.cpp -check-prefix=CHECK-OLD-TEST-CPP %s
+// RUN: FileCheck -input-file=%T/clang-move/test.h -check-prefix=CHECK-OLD-TEST-H %s
+//
+// RUN: cp %S/Inputs/test*  %T/clang-move/
+// RUN: cd %T/clang-move
+// RUN: clang-move -name="a::Foo" -new_cc=%T/clang-move/new_test.cpp -new_header=%T/clang-move/new_test.h -old_cc=%T/clang-move/test.cpp -old_header=%T/clang-move/test.h %T/clang-move/test.cpp
+// RUN: FileCheck -input-file=%T/clang-move/new_test.cpp -check-prefix=CHECK-NEW-TEST-CPP %s
+// RUN: FileCheck -input-file=%T/clang-move/new_test.h -check-prefix=CHECK-NEW-TEST-H %s
+// RUN: FileCheck -input-file=%T/clang-move/test.cpp -check-prefix=CHECK-OLD-TEST-CPP %s
+// RUN: FileCheck -input-file=%T/clang-move/test.h -check-prefix=CHECK-OLD-TEST-H %s
+//
+// CHECK-NEW-TEST-H: namespace a {
+// CHECK-NEW-TEST-H: class Foo {
+// CHECK-NEW-TEST-H: public:
+// CHECK-NEW-TEST-H:   int f();
+// CHECK-NEW-TEST-H: };
+// CHECK-NEW-TEST-H: } // namespace a
+//
+// CHECK-NEW-TEST-CPP: #include "{{.*}}new_test.h"
+// CHECK-NEW-TEST-CPP: #include "test2.h"
+// CHECK-NEW-TEST-CPP: namespace a {
+// CHECK-NEW-TEST-CPP: int Foo::f() { return 0; }
+// CHECK-NEW-TEST-CPP: } // namespace a
+//
+// CHECK-OLD-TEST-H: namespace a {
+// CHECK-OLD-TEST-H: } // namespace a
+//
+// CHECK-OLD-TEST-CPP: #include "test.h"
+// CHECK-OLD-TEST-CPP: #include "test2.h"
+// CHECK-OLD-TEST-CPP: namespace a {
+// CHECK-OLD-TEST-CPP: } // namespace a
Index: test/clang-move/Inputs/test.h
===
--- /dev/null
+++ test/clang-move/Inputs/test.h
@@ -0,0 +1,6 @@
+namespace a {
+class Foo {
+public:
+  int f();
+};
+} // namespace a
Index: test/clang-move/Inputs/test.cpp
===
--- /dev/null
+++ test/clang-move/Inputs/test.cpp
@@ -0,0 +1,8 @@
+#include "test.h"
+#include "test2.h"
+
+namespace a {
+int Foo::f() {
+  return 0;
+}
+} // namespace a
Index: test/clang-move/Inputs/database_template.json
===
--- /dev/null
+++ test/clang-move/Inputs/database_template.json
@@ -0,0 +1,7 @@
+[
+{
+  "directory": "test_dir/build",
+  "command": "clang++ -o test.o test_dir/test.cpp",
+  "file": "test_dir/test.cpp"
+}
+]
Index: clang-move/tool/ClangMoveMain.cpp
===
--- clang-move/tool/ClangMoveMain.cpp
+++ clang-move/tool/ClangMoveMain.cpp
@@ -17,13 +17,15 @@
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/Process.h"
 #include "llvm/Support/YAMLTraits.h"
+#include "llvm/Support/Path.h"
 #include 
 #include 
 
 using namespace clang;
 using namespace llvm;
 
 namespace {
+
 std::error_code CreateNewFile(const llvm::Twine &path) {
   int fd = 0;
   if (std::error_code ec =
@@ -38,17 +40,23 @@
 cl::opt Name("name", cl::desc("The name of class being moved."),
   cl::cat(ClangMoveCategory));
 
-cl

Re: [PATCH] D19586: Misleading Indentation check

2016-09-27 Thread Gábor Horváth via cfe-commits
xazax.hun added inline comments.


Comment at: test/clang-tidy/readability-misleading-indentation.cpp:16
@@ +15,3 @@
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: wrong indentation, 
'else' belongs to 'if(cond2)' statement
+  // CHECK-FIXES: {{^}}  // comment1
+

Pajesz wrote:
> alexfh wrote:
> > Did you run the tests after changes? I don't think the `// comment1` line 
> > can actually appear in the fixed code, when it's not there before the fix.
> Could you please explain what check-fixes does and how? Im not sure about it.
You can read the documentation here: 
http://clang.llvm.org/extra/clang-tidy/#testing-checks

Didn't you execute the tests? (Using make check-all or some similar command)

The CHECK-FIXES line will check the content of the file after the fixits are 
applied. The check will fail when the specified pattern is not found in the 
result.


https://reviews.llvm.org/D19586



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


[clang-tools-extra] r282480 - [include-fixer] Add customized editor settings documents.

2016-09-27 Thread Haojian Wu via cfe-commits
Author: hokein
Date: Tue Sep 27 05:43:38 2016
New Revision: 282480

URL: http://llvm.org/viewvc/llvm-project?rev=282480&view=rev
Log:
[include-fixer] Add customized editor settings documents.

Reviewers: bkramer

Subscribers: cfe-commits

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

Modified:
clang-tools-extra/trunk/docs/include-fixer.rst

Modified: clang-tools-extra/trunk/docs/include-fixer.rst
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/docs/include-fixer.rst?rev=282480&r1=282479&r2=282480&view=diff
==
--- clang-tools-extra/trunk/docs/include-fixer.rst (original)
+++ clang-tools-extra/trunk/docs/include-fixer.rst Tue Sep 27 05:43:38 2016
@@ -81,13 +81,40 @@ Make sure vim can find :program:`clang-i
 You can customize the number of headers being shown by setting
 ``let g:clang_include_fixer_maximum_suggested_headers=5``
 
+Customized settings in `.vimrc`:
+
+- ``let g:clang_include_fixer_path = "clang-include-fixer"``
+
+  Set clang-include-fixer binary file path.
+
+- ``let g:clang_include_fixer_maximum_suggested_headers = 3``
+
+  Set the maximum number of ``#includes`` to show. Default is 3.
+
+- ``let g:clang_include_fixer_increment_num = 5``
+
+  Set the increment number of #includes to show every time when pressing ``m``.
+  Default is 5.
+
+- ``let g:clang_include_fixer_jump_to_include = 0``
+
+  Set to 1 if you want to jump to the new inserted ``#include`` line. Default 
is
+  0.
+
+- ``let g:clang_include_fixer_query_mode = 0``
+
+  Set to 1 if you want to insert ``#include`` for the symbol under the cursor.
+  Default is 0. Compared to normal mode, this mode won't parse the source file
+  and only search the sysmbol from database, which is faster than normal mode.
+
 See ``clang-include-fixer.py`` for more details.
 
 Integrate with Emacs
 
 To run `clang-include-fixer` on a potentially unsaved buffer in Emacs.
-Ensure that Emacs finds ``clang-include-fixer.el`` by adding the directory 
containing the file to the ``load-path``
-and requiring the `clang-include-fixer` in your ```.emacs``:
+Ensure that Emacs finds ``clang-include-fixer.el`` by adding the directory
+containing the file to the ``load-path`` and requiring the 
`clang-include-fixer`
+in your ``.emacs``:
 
 .. code-block:: console
 
@@ -100,6 +127,19 @@ Make sure Emacs can find :program:`clang
 
 - Add the path to :program:`clang-include-fixer` to the PATH environment 
variable.
 
+Customized settings in `.emacs`:
+
+- ``(custom-set-variables '(clang-include-fixer-executable 
"/path/to/include-fixer"))``
+
+  Set clang-include-fixer binary file path.
+
+- ``(custom-set-variables '(clang-include-fixer-query-mode t))``
+
+  Set to `t` if you want to insert ``#include`` for the symbol under the 
cursor.
+  Default is `nil`. Compared to normal mode, this mode won't parse the source
+  file and only search the sysmbol from database, which is faster than normal
+  mode.
+
 See ``clang-include-fixer.el`` for more details.
 
 How it Works


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


Re: [PATCH] D24719: [include-fixer] Add customized editor settings documents.

2016-09-27 Thread Haojian Wu via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL282480: [include-fixer] Add customized editor settings 
documents. (authored by hokein).

Changed prior to commit:
  https://reviews.llvm.org/D24719?vs=71792&id=72623#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D24719

Files:
  clang-tools-extra/trunk/docs/include-fixer.rst

Index: clang-tools-extra/trunk/docs/include-fixer.rst
===
--- clang-tools-extra/trunk/docs/include-fixer.rst
+++ clang-tools-extra/trunk/docs/include-fixer.rst
@@ -81,13 +81,40 @@
 You can customize the number of headers being shown by setting
 ``let g:clang_include_fixer_maximum_suggested_headers=5``
 
+Customized settings in `.vimrc`:
+
+- ``let g:clang_include_fixer_path = "clang-include-fixer"``
+
+  Set clang-include-fixer binary file path.
+
+- ``let g:clang_include_fixer_maximum_suggested_headers = 3``
+
+  Set the maximum number of ``#includes`` to show. Default is 3.
+
+- ``let g:clang_include_fixer_increment_num = 5``
+
+  Set the increment number of #includes to show every time when pressing ``m``.
+  Default is 5.
+
+- ``let g:clang_include_fixer_jump_to_include = 0``
+
+  Set to 1 if you want to jump to the new inserted ``#include`` line. Default 
is
+  0.
+
+- ``let g:clang_include_fixer_query_mode = 0``
+
+  Set to 1 if you want to insert ``#include`` for the symbol under the cursor.
+  Default is 0. Compared to normal mode, this mode won't parse the source file
+  and only search the sysmbol from database, which is faster than normal mode.
+
 See ``clang-include-fixer.py`` for more details.
 
 Integrate with Emacs
 
 To run `clang-include-fixer` on a potentially unsaved buffer in Emacs.
-Ensure that Emacs finds ``clang-include-fixer.el`` by adding the directory 
containing the file to the ``load-path``
-and requiring the `clang-include-fixer` in your ```.emacs``:
+Ensure that Emacs finds ``clang-include-fixer.el`` by adding the directory
+containing the file to the ``load-path`` and requiring the 
`clang-include-fixer`
+in your ``.emacs``:
 
 .. code-block:: console
 
@@ -100,6 +127,19 @@
 
 - Add the path to :program:`clang-include-fixer` to the PATH environment 
variable.
 
+Customized settings in `.emacs`:
+
+- ``(custom-set-variables '(clang-include-fixer-executable 
"/path/to/include-fixer"))``
+
+  Set clang-include-fixer binary file path.
+
+- ``(custom-set-variables '(clang-include-fixer-query-mode t))``
+
+  Set to `t` if you want to insert ``#include`` for the symbol under the 
cursor.
+  Default is `nil`. Compared to normal mode, this mode won't parse the source
+  file and only search the sysmbol from database, which is faster than normal
+  mode.
+
 See ``clang-include-fixer.el`` for more details.
 
 How it Works


Index: clang-tools-extra/trunk/docs/include-fixer.rst
===
--- clang-tools-extra/trunk/docs/include-fixer.rst
+++ clang-tools-extra/trunk/docs/include-fixer.rst
@@ -81,13 +81,40 @@
 You can customize the number of headers being shown by setting
 ``let g:clang_include_fixer_maximum_suggested_headers=5``
 
+Customized settings in `.vimrc`:
+
+- ``let g:clang_include_fixer_path = "clang-include-fixer"``
+
+  Set clang-include-fixer binary file path.
+
+- ``let g:clang_include_fixer_maximum_suggested_headers = 3``
+
+  Set the maximum number of ``#includes`` to show. Default is 3.
+
+- ``let g:clang_include_fixer_increment_num = 5``
+
+  Set the increment number of #includes to show every time when pressing ``m``.
+  Default is 5.
+
+- ``let g:clang_include_fixer_jump_to_include = 0``
+
+  Set to 1 if you want to jump to the new inserted ``#include`` line. Default is
+  0.
+
+- ``let g:clang_include_fixer_query_mode = 0``
+
+  Set to 1 if you want to insert ``#include`` for the symbol under the cursor.
+  Default is 0. Compared to normal mode, this mode won't parse the source file
+  and only search the sysmbol from database, which is faster than normal mode.
+
 See ``clang-include-fixer.py`` for more details.
 
 Integrate with Emacs
 
 To run `clang-include-fixer` on a potentially unsaved buffer in Emacs.
-Ensure that Emacs finds ``clang-include-fixer.el`` by adding the directory containing the file to the ``load-path``
-and requiring the `clang-include-fixer` in your ```.emacs``:
+Ensure that Emacs finds ``clang-include-fixer.el`` by adding the directory
+containing the file to the ``load-path`` and requiring the `clang-include-fixer`
+in your ``.emacs``:
 
 .. code-block:: console
 
@@ -100,6 +127,19 @@
 
 - Add the path to :program:`clang-include-fixer` to the PATH environment variable.
 
+Customized settings in `.emacs`:
+
+- ``(custom-set-variables '(clang-include-fixer-executable "/path/to/include-fixer"))``
+
+  Set clang-include-fixer binary file path.
+
+- ``(custom-set-variables '(clang-include-fixer-query-mode t))``
+
+  Set

r282481 - [Power9] Builtins for ELF v.2 ABI conformance - front end portion

2016-09-27 Thread Nemanja Ivanovic via cfe-commits
Author: nemanjai
Date: Tue Sep 27 05:45:22 2016
New Revision: 282481

URL: http://llvm.org/viewvc/llvm-project?rev=282481&view=rev
Log:
[Power9] Builtins for ELF v.2 ABI conformance - front end portion

This patch corresponds to review:
https://reviews.llvm.org/D24397

It adds the __POWER9_VECTOR__ macro and the -mpower9-vector option along with
a number of altivec.h functions (refer to the code review for a list).

Added:
cfe/trunk/test/CodeGen/builtins-ppc-p9vector.c
Modified:
cfe/trunk/include/clang/Basic/BuiltinsPPC.def
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/lib/Headers/altivec.h
cfe/trunk/test/Driver/ppc-dependent-options.cpp
cfe/trunk/test/Preprocessor/predefined-arch-macros.c

Modified: cfe/trunk/include/clang/Basic/BuiltinsPPC.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsPPC.def?rev=282481&r1=282480&r2=282481&view=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsPPC.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsPPC.def Tue Sep 27 05:45:22 2016
@@ -134,6 +134,14 @@ BUILTIN(__builtin_altivec_vcmpequw, "V4i
 BUILTIN(__builtin_altivec_vcmpequd, "V2LLiV2LLiV2LLi", "")
 BUILTIN(__builtin_altivec_vcmpeqfp, "V4iV4fV4f", "")
 
+BUILTIN(__builtin_altivec_vcmpneb, "V16cV16cV16c", "")
+BUILTIN(__builtin_altivec_vcmpneh, "V8sV8sV8s", "")
+BUILTIN(__builtin_altivec_vcmpnew, "V4iV4iV4i", "")
+
+BUILTIN(__builtin_altivec_vcmpnezb, "V16cV16cV16c", "")
+BUILTIN(__builtin_altivec_vcmpnezh, "V8sV8sV8s", "")
+BUILTIN(__builtin_altivec_vcmpnezw, "V4iV4iV4i", "")
+
 BUILTIN(__builtin_altivec_vcmpgtsb, "V16cV16ScV16Sc", "")
 BUILTIN(__builtin_altivec_vcmpgtub, "V16cV16UcV16Uc", "")
 BUILTIN(__builtin_altivec_vcmpgtsh, "V8sV8SsV8Ss", "")
@@ -223,6 +231,11 @@ BUILTIN(__builtin_altivec_vcmpequw_p, "i
 BUILTIN(__builtin_altivec_vcmpequd_p, "iiV2LLiV2LLi", "")
 BUILTIN(__builtin_altivec_vcmpeqfp_p, "iiV4fV4f", "")
 
+BUILTIN(__builtin_altivec_vcmpneb_p, "iiV16cV16c", "")
+BUILTIN(__builtin_altivec_vcmpneh_p, "iiV8sV8s", "")
+BUILTIN(__builtin_altivec_vcmpnew_p, "iiV4iV4i", "")
+BUILTIN(__builtin_altivec_vcmpned_p, "iiV2LLiV2LLi", "")
+
 BUILTIN(__builtin_altivec_vcmpgtsb_p, "iiV16ScV16Sc", "")
 BUILTIN(__builtin_altivec_vcmpgtub_p, "iiV16UcV16Uc", "")
 BUILTIN(__builtin_altivec_vcmpgtsh_p, "iiV8SsV8Ss", "")
@@ -254,6 +267,16 @@ BUILTIN(__builtin_altivec_vclzb, "V16UcV
 BUILTIN(__builtin_altivec_vclzh, "V8UsV8Us", "")
 BUILTIN(__builtin_altivec_vclzw, "V4UiV4Ui", "")
 BUILTIN(__builtin_altivec_vclzd, "V2ULLiV2ULLi", "")
+BUILTIN(__builtin_altivec_vctzb, "V16UcV16Uc", "")
+BUILTIN(__builtin_altivec_vctzh, "V8UsV8Us", "")
+BUILTIN(__builtin_altivec_vctzw, "V4UiV4Ui", "")
+BUILTIN(__builtin_altivec_vctzd, "V2ULLiV2ULLi", "")
+
+// Vector population count built-ins
+BUILTIN(__builtin_altivec_vpopcntb, "V16UcV16Uc", "")
+BUILTIN(__builtin_altivec_vpopcnth, "V8UsV8Us", "")
+BUILTIN(__builtin_altivec_vpopcntw, "V4UiV4Ui", "")
+BUILTIN(__builtin_altivec_vpopcntd, "V2ULLiV2ULLi", "")
 
 // VSX built-ins.
 

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=282481&r1=282480&r2=282481&view=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Tue Sep 27 05:45:22 2016
@@ -1572,6 +1572,10 @@ def mpower8_vector : Flag<["-"], "mpower
 Group;
 def mno_power8_vector : Flag<["-"], "mno-power8-vector">,
 Group;
+def mpower9_vector : Flag<["-"], "mpower9-vector">,
+Group;
+def mno_power9_vector : Flag<["-"], "mno-power9-vector">,
+Group;
 def mpower8_crypto : Flag<["-"], "mcrypto">,
 Group;
 def mnopower8_crypto : Flag<["-"], "mno-crypto">,

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=282481&r1=282480&r2=282481&view=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Tue Sep 27 05:45:22 2016
@@ -870,6 +870,7 @@ class PPCTargetInfo : public TargetInfo
   bool HasHTM;
   bool HasBPERMD;
   bool HasExtDiv;
+  bool HasP9Vector;
 
 protected:
   std::string ABI;
@@ -878,7 +879,7 @@ public:
   PPCTargetInfo(const llvm::Triple &Triple, const TargetOptions &)
 : TargetInfo(Triple), HasVSX(false), HasP8Vector(false),
   HasP8Crypto(false), HasDirectMove(false), HasQPX(false), HasHTM(false),
-  HasBPERMD(false), HasExtDiv(false) {
+  HasBPERMD(false), HasExtDiv(false), HasP9Vector(false) {
 SimdDefaultAlign = 128;
 LongDoubleWidth = LongDoubleAlign = 128;
 LongDoubleFormat = &llvm::APFloat::PPCDoubleDouble;
@@ -1157,6 +1158,8 @@ bool PPCTargetInfo::handleTargetFeatures

Re: [PATCH] D24397: Target Power9 bit counting and vector comparison instructions through builtins (front end portion)

2016-09-27 Thread Nemanja Ivanovic via cfe-commits
nemanjai closed this revision.
nemanjai added a comment.

Committed revision 282481.


Repository:
  rL LLVM

https://reviews.llvm.org/D24397



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


Re: [PATCH] D24800: Merge conflicting replacements when they are order-independent.

2016-09-27 Thread Manuel Klimek via cfe-commits
klimek added inline comments.


Comment at: include/clang/Tooling/Core/Replacement.h:177-178
@@ +176,4 @@
+  ///   - are insertions at the same offset and applying them in either order
+  /// has the same effect, i.e. X + Y = Y + X if one inserts text X and the
+  /// other inserts text Y.
+  /// Examples:

This seems incorrect. What am I missing?


https://reviews.llvm.org/D24800



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


Re: [PATCH] D24800: Merge conflicting replacements when they are order-independent.

2016-09-27 Thread Eric Liu via cfe-commits
ioeric added inline comments.


Comment at: include/clang/Tooling/Core/Replacement.h:177-178
@@ +176,4 @@
+  ///   - are insertions at the same offset and applying them in either order
+  /// has the same effect, i.e. X + Y = Y + X if one inserts text X and the
+  /// other inserts text Y.
+  /// Examples:

klimek wrote:
> This seems incorrect. What am I missing?
Here is the discussion about this: https://reviews.llvm.org/D24717


https://reviews.llvm.org/D24800



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


Re: [PATCH] D14326: ASTImporter: expressions, pt.2

2016-09-27 Thread Aleksei Sidorin via cfe-commits
a.sidorin updated this revision to Diff 72625.
a.sidorin added a comment.

Address review comments; add accidentally missed file.


https://reviews.llvm.org/D14326

Files:
  include/clang/AST/ASTImporter.h
  include/clang/AST/DeclFriend.h
  lib/AST/ASTImporter.cpp
  lib/Serialization/ASTReaderStmt.cpp
  lib/Serialization/ASTWriterStmt.cpp
  test/ASTMerge/Inputs/class3.cpp
  test/ASTMerge/Inputs/exprs3.cpp
  test/ASTMerge/class2.cpp
  test/ASTMerge/exprs.cpp
  unittests/AST/ASTImporterTest.cpp

Index: unittests/AST/ASTImporterTest.cpp
===
--- unittests/AST/ASTImporterTest.cpp
+++ unittests/AST/ASTImporterTest.cpp
@@ -456,5 +456,24 @@
 }
 
 
+const internal::VariadicDynCastAllOfMatcher vaArgExpr;
+
+TEST(ImportExpr, ImportVAArgExpr) {
+  MatchVerifier Verifier;
+  EXPECT_TRUE(
+testImport(
+  "void declToImport(__builtin_va_list list, ...) {"
+  "  (void)__builtin_va_arg(list, int); }",
+  Lang_CXX, "", Lang_CXX, Verifier,
+  functionDecl(
+hasBody(
+  compoundStmt(
+has(
+  cStyleCastExpr(
+hasSourceExpression(
+  vaArgExpr();
+}
+
+
 } // end namespace ast_matchers
 } // end namespace clang
Index: test/ASTMerge/exprs.cpp
===
--- /dev/null
+++ test/ASTMerge/exprs.cpp
@@ -0,0 +1,45 @@
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++1z -fcxx-exceptions -emit-pch -o %t.1.ast %S/Inputs/exprs3.cpp
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++1z -fcxx-exceptions -ast-merge %t.1.ast -fsyntax-only -verify %s
+// expected-no-diagnostics
+
+static_assert(Ch1 == 'a');
+static_assert(Ch2 == 'b');
+static_assert(Ch3 == 'c');
+
+static_assert(Ch4 == L'd');
+static_assert(Ch5 == L'e');
+static_assert(Ch6 == L'f');
+
+static_assert(C1 == 12);
+static_assert(C2 == 13);
+
+static_assert(C3 == 12);
+static_assert(C4 == 13);
+
+static_assert(C5 == 22L);
+static_assert(C6 == 23L);
+
+static_assert(C7 == 66LL);
+static_assert(C8 == 67ULL);
+
+static_assert(bval1 == true);
+static_assert(bval2 == false);
+
+static_assert(ExpressionTrait == false);
+
+static_assert(ArrayRank == 2);
+static_assert(ArrayExtent == 20);
+
+void testImport(int *x, const S1 &cs1, S1 &s1) {
+  testNewThrowDelete();
+  testArrayElement(nullptr, 12);
+  testTernaryOp(0, 1, 2);
+  testConstCast(cs1);
+  testStaticCast(s1);
+  testReinterpretCast(s1);
+  testDynamicCast(s1);
+  testScalarInit(42);
+  testOffsetOf();
+  testDefaultArg(12);
+  useTemplateType();
+}
Index: test/ASTMerge/class2.cpp
===
--- /dev/null
+++ test/ASTMerge/class2.cpp
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++1z -emit-pch -o %t.1.ast %S/Inputs/class3.cpp
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++1z -ast-merge %t.1.ast -fsyntax-only -verify %s
+// expected-no-diagnostics
+
+class C3 {
+  int method_1(C2 *x) {
+return x->x;
+  }
+};
Index: test/ASTMerge/Inputs/exprs3.cpp
===
--- /dev/null
+++ test/ASTMerge/Inputs/exprs3.cpp
@@ -0,0 +1,131 @@
+// Integer literals
+const char Ch1 = 'a';
+const signed char Ch2 = 'b';
+const unsigned char Ch3 = 'c';
+
+const wchar_t Ch4 = L'd';
+const signed wchar_t Ch5 = L'e';
+const unsigned wchar_t Ch6 = L'f';
+
+const short C1 = 12;
+const unsigned short C2 = 13;
+
+const int C3 = 12;
+const unsigned int C4 = 13;
+
+const long C5 = 22;
+const unsigned long C6 = 23;
+
+const long long C7 = 66;
+const unsigned long long C8 = 67;
+
+
+// String literals
+const char str1[] = "ABCD";
+const char str2[] = "ABCD" "0123";
+
+const wchar_t wstr1[] = L"DEF";
+const wchar_t wstr2[] = L"DEF" L"123";
+
+
+// Boolean literals
+const bool bval1 = true;
+const bool bval2 = false;
+
+// Floating Literals
+const float F1 = 12.2F;
+const double F2 = 1E4;
+const long double F3 = 1.2E-3L;
+
+
+// nullptr literal
+const void *vptr = nullptr;
+
+
+int glb_1[4] = { 10, 20, 30, 40 };
+
+struct S1 {
+  int a;
+  int b[3];
+};
+
+struct S2 {
+  int c;
+  S1 d;
+};
+
+S2 glb_2 = { 22, .d.a = 44, .d.b[0] = 55, .d.b[1] = 66 };
+
+void testNewThrowDelete() {
+  throw;
+  char *p = new char[10];
+  delete[] p;
+}
+
+int testArrayElement(int *x, int n) {
+  return x[n];
+}
+
+int testTernaryOp(int c, int x, int y) {
+  return c ? x : y;
+}
+
+S1 &testConstCast(const S1 &x) {
+  return const_cast(x);
+}
+
+S1 &testStaticCast(S1 &x) {
+  return static_cast(x);
+}
+
+S1 &testReinterpretCast(S1 &x) {
+  return reinterpret_cast(x);
+}
+
+S1 &testDynamicCast(S1 &x) {
+  return dynamic_cast(x);
+}
+
+int testScalarInit(int x) {
+  return int(x);
+}
+
+struct S {
+  float f;
+  double d;
+};
+struct T {
+  int i;
+  struct S s[10];
+};
+
+void testOffsetOf() {
+  __builtin_offsetof(struct T, s[2].d);
+}
+
+
+unsigned char asmFunc(unsign

Re: [PATCH] D24905: Fix unreachable code false positive, vardecl in switch

2016-09-27 Thread Gábor Horváth via cfe-commits
xazax.hun added inline comments.


Comment at: lib/StaticAnalyzer/Checkers/UnreachableCodeChecker.cpp:195
@@ +194,3 @@
+if (Optional S = I->getAs()) {
+  if (isa(S->getStmt()))
+return S->getStmt();

Maybe I would prefer something like !isa which is a less intrusive 
change.


Repository:
  rL LLVM

https://reviews.llvm.org/D24905



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


[PATCH] D24958: Test linked to D24957

2016-09-27 Thread Ziv Izhar via cfe-commits
zizhar created this revision.
zizhar added a reviewer: rnk.
zizhar added a subscriber: cfe-commits.
zizhar set the repository for this revision to rL LLVM.

A test for the patch in https://reviews.llvm.org/D24957

Repository:
  rL LLVM

https://reviews.llvm.org/D24958

Files:
  test/CodeGen/ms-inline-asm.c

Index: test/CodeGen/ms-inline-asm.c
===
--- test/CodeGen/ms-inline-asm.c
+++ test/CodeGen/ms-inline-asm.c
@@ -634,6 +634,15 @@
   // CHECK: call void asm sideeffect inteldialect "jmp 
{{.*}}__MSASMLABEL_.5__dollar_label$$\0A\09{{.*}}__MSASMLABEL_.5__dollar_label$$:",
 "~{dirflag},~{fpsr},~{flags}"()
 }
 
+void label6(){
+  __asm {
+  jmp short label
+label:
+  }
+  // CHECK-LABEL: define void @label6
+  // CHECK: call void asm sideeffect inteldialect "jmp 
{{.*}}__MSASMLABEL_.6__label\0A\09{{.*}}__MSASMLABEL_.6__label:", 
"~{dirflag},~{fpsr},~{flags}"()
+}
+
 typedef union _LARGE_INTEGER {
   struct {
 unsigned int LowPart;


Index: test/CodeGen/ms-inline-asm.c
===
--- test/CodeGen/ms-inline-asm.c
+++ test/CodeGen/ms-inline-asm.c
@@ -634,6 +634,15 @@
   // CHECK: call void asm sideeffect inteldialect "jmp {{.*}}__MSASMLABEL_.5__dollar_label$$\0A\09{{.*}}__MSASMLABEL_.5__dollar_label$$:", "~{dirflag},~{fpsr},~{flags}"()
 }
 
+void label6(){
+  __asm {
+  jmp short label
+label:
+  }
+  // CHECK-LABEL: define void @label6
+  // CHECK: call void asm sideeffect inteldialect "jmp {{.*}}__MSASMLABEL_.6__label\0A\09{{.*}}__MSASMLABEL_.6__label:", "~{dirflag},~{fpsr},~{flags}"()
+}
+
 typedef union _LARGE_INTEGER {
   struct {
 unsigned int LowPart;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D24800: Merge conflicting replacements when they are order-independent.

2016-09-27 Thread Manuel Klimek via cfe-commits
klimek added inline comments.


Comment at: include/clang/Tooling/Core/Replacement.h:177-178
@@ +176,4 @@
+  ///   - are insertions at the same offset and applying them in either order
+  /// has the same effect, i.e. X + Y = Y + X if one inserts text X and the
+  /// other inserts text Y.
+  /// Examples:

ioeric wrote:
> klimek wrote:
> > This seems incorrect. What am I missing?
> Here is the discussion about this: https://reviews.llvm.org/D24717
I misunderstood :) Perhaps change to:
, i.e. if X + Y == Y + X when inserting X and Y respectively.


Comment at: include/clang/Tooling/Core/Replacement.h:242
@@ +241,3 @@
+  // If `R` and all existing replacements are order-indepedent, then merge it
+  // with `Replaces` and returns the merged replacements; otheriwse, returns an
+  // error.

typo: otheriwse


Comment at: lib/Tooling/Core/Replacement.cpp:162
@@ +161,3 @@
+auto &Prev = NewReplaces.back();
+auto PrevEnd = Prev.getOffset() + Prev.getLength();
+if (PrevEnd < R.getOffset()) {

I'd not use auto for simple integer types.


Comment at: lib/Tooling/Core/Replacement.cpp:166
@@ +165,3 @@
+} else {
+  assert(PrevEnd == R.getOffset());
+  Replacement NewR(

Add comment why we can assert this.


Comment at: lib/Tooling/Core/Replacement.cpp:179-181
@@ +178,5 @@
+Replacements::mergeIfOrderIndependent(const Replacement &R) const {
+  Replacements Rs(R);
+  Replacements ShiftedRs(getReplacementInChangedCode(R));
+  Replacements ShiftedReplaces;
+  for (const auto &Replace : Replaces)

These names are confusing me...



Comment at: lib/Tooling/Core/Replacement.cpp:184
@@ +183,3 @@
+ShiftedReplaces.Replaces.insert(Rs.getReplacementInChangedCode(Replace));
+  auto MergeRs = merge(ShiftedRs);
+  auto MergeReplaces = Rs.merge(ShiftedReplaces);

This comes from a single replacement - why do we need to call merge?


https://reviews.llvm.org/D24800



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


[libcxx] r282483 - [cmake] Add linker option "-Wl, -z, defs" in standalone build

2016-09-27 Thread Michal Gorny via cfe-commits
Author: mgorny
Date: Tue Sep 27 07:15:35 2016
New Revision: 282483

URL: http://llvm.org/viewvc/llvm-project?rev=282483&view=rev
Log:
[cmake] Add linker option "-Wl,-z,defs" in standalone build

Add the "-Wl,-z,defs" linker option that is used to prevent
underlinking. It is already used by LLVM itself but does not get
propagated into stand-alone build of libc++. This patch ensures
that the option is passed in independently of whether libc++ is built
in-tree or out-of-tree.

Patch by Lei Zhang.

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

Modified:
libcxx/trunk/CMakeLists.txt

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=282483&r1=282482&r2=282483&view=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Tue Sep 27 07:15:35 2016
@@ -319,6 +319,18 @@ remove_flags(-stdlib=libc++ -stdlib=libs
 # so they don't get transformed into -Wno and -errors respectivly.
 remove_flags(-Wno-pedantic -pedantic-errors -pedantic)
 
+# FIXME: this is cribbed from HandleLLVMOptions.cmake.
+if(LIBCXX_STANDALONE_BUILD)
+  # Pass -Wl,-z,defs. This makes sure all symbols are defined. Otherwise a DSO
+  # build might work on ELF but fail on MachO/COFF.
+  if(NOT (${CMAKE_SYSTEM_NAME} MATCHES "Darwin" OR WIN32 OR CYGWIN OR
+  ${CMAKE_SYSTEM_NAME} MATCHES "FreeBSD" OR
+  ${CMAKE_SYSTEM_NAME} MATCHES "OpenBSD") AND
+ NOT LLVM_USE_SANITIZER)
+set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -Wl,-z,defs")
+  endif()
+endif()
+
 # Required flags ==
 set(LIBCXX_STANDARD_VER c++11 CACHE INTERNAL "internal option to change build 
dialect")
 add_compile_flags_if_supported(-std=${LIBCXX_STANDARD_VER})


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


Re: [PATCH] D24119: [libc++] add linker option "-Wl, -z, defs" in standalone build

2016-09-27 Thread Michał Górny via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL282483: [cmake] Add linker option "-Wl,-z,defs" in 
standalone build (authored by mgorny).

Changed prior to commit:
  https://reviews.llvm.org/D24119?vs=69944&id=72632#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D24119

Files:
  libcxx/trunk/CMakeLists.txt

Index: libcxx/trunk/CMakeLists.txt
===
--- libcxx/trunk/CMakeLists.txt
+++ libcxx/trunk/CMakeLists.txt
@@ -319,6 +319,18 @@
 # so they don't get transformed into -Wno and -errors respectivly.
 remove_flags(-Wno-pedantic -pedantic-errors -pedantic)
 
+# FIXME: this is cribbed from HandleLLVMOptions.cmake.
+if(LIBCXX_STANDALONE_BUILD)
+  # Pass -Wl,-z,defs. This makes sure all symbols are defined. Otherwise a DSO
+  # build might work on ELF but fail on MachO/COFF.
+  if(NOT (${CMAKE_SYSTEM_NAME} MATCHES "Darwin" OR WIN32 OR CYGWIN OR
+  ${CMAKE_SYSTEM_NAME} MATCHES "FreeBSD" OR
+  ${CMAKE_SYSTEM_NAME} MATCHES "OpenBSD") AND
+ NOT LLVM_USE_SANITIZER)
+set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -Wl,-z,defs")
+  endif()
+endif()
+
 # Required flags ==
 set(LIBCXX_STANDARD_VER c++11 CACHE INTERNAL "internal option to change build 
dialect")
 add_compile_flags_if_supported(-std=${LIBCXX_STANDARD_VER})


Index: libcxx/trunk/CMakeLists.txt
===
--- libcxx/trunk/CMakeLists.txt
+++ libcxx/trunk/CMakeLists.txt
@@ -319,6 +319,18 @@
 # so they don't get transformed into -Wno and -errors respectivly.
 remove_flags(-Wno-pedantic -pedantic-errors -pedantic)
 
+# FIXME: this is cribbed from HandleLLVMOptions.cmake.
+if(LIBCXX_STANDALONE_BUILD)
+  # Pass -Wl,-z,defs. This makes sure all symbols are defined. Otherwise a DSO
+  # build might work on ELF but fail on MachO/COFF.
+  if(NOT (${CMAKE_SYSTEM_NAME} MATCHES "Darwin" OR WIN32 OR CYGWIN OR
+  ${CMAKE_SYSTEM_NAME} MATCHES "FreeBSD" OR
+  ${CMAKE_SYSTEM_NAME} MATCHES "OpenBSD") AND
+ NOT LLVM_USE_SANITIZER)
+set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -Wl,-z,defs")
+  endif()
+endif()
+
 # Required flags ==
 set(LIBCXX_STANDARD_VER c++11 CACHE INTERNAL "internal option to change build dialect")
 add_compile_flags_if_supported(-std=${LIBCXX_STANDARD_VER})
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r282484 - Silencing a Sphinx diagnostic with options, again.

2016-09-27 Thread Aaron Ballman via cfe-commits
Author: aaronballman
Date: Tue Sep 27 07:17:05 2016
New Revision: 282484

URL: http://llvm.org/viewvc/llvm-project?rev=282484&view=rev
Log:
Silencing a Sphinx diagnostic with options, again.

Warning, treated as error:
/opt/llvm/build.attributes.src/tools/clang/docs/CommandGuide/clang.rst:413: 
WARNING: unknown option: -save-stats=cwd

Modified:
cfe/trunk/docs/CommandGuide/clang.rst

Modified: cfe/trunk/docs/CommandGuide/clang.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/CommandGuide/clang.rst?rev=282484&r1=282483&r2=282484&view=diff
==
--- cfe/trunk/docs/CommandGuide/clang.rst (original)
+++ cfe/trunk/docs/CommandGuide/clang.rst Tue Sep 27 07:17:05 2016
@@ -411,8 +411,8 @@ Driver Options
 .. option:: -save-stats, -save-stats=cwd, -save-stats=obj
 
   Save internal code generation (LLVM) statistics to a file in the current
-  directory (:option:`-save-stats`/:option:`-save-stats=cwd`) or the directory
-  of the output file (:option:`-save-state=obj`).
+  directory (:option:`-save-stats`/"-save-stats=cwd") or the directory
+  of the output file ("-save-state=obj").
 
 .. option:: -integrated-as, -no-integrated-as
 


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


Re: [PATCH] D24380: [migrate-tool] Framework for a codebase-dependent migration tool.

2016-09-27 Thread Eric Liu via cfe-commits
ioeric updated this revision to Diff 72635.
ioeric marked 2 inline comments as done.
ioeric added a comment.

- Replace dummy binary with unit test with dummy environemnt + fake codebase.


https://reviews.llvm.org/D24380

Files:
  CMakeLists.txt
  migrate-tool/AffectedFilesFinder.h
  migrate-tool/BuildManager.h
  migrate-tool/CMakeLists.txt
  migrate-tool/FileSystemManager.h
  migrate-tool/HeaderGenerator.cpp
  migrate-tool/HeaderGenerator.h
  migrate-tool/MigrateTool.cpp
  migrate-tool/MigrateTool.h
  migrate-tool/MigrationEnvironment.h
  migrate-tool/RefactoringManager.h
  unittests/CMakeLists.txt
  unittests/migrate-tool/CMakeLists.txt
  unittests/migrate-tool/DummyMigrateToolTest.cpp
  unittests/migrate-tool/DummyMigrationEnvironment.cpp
  unittests/migrate-tool/DummyMigrationEnvironment.h
  unittests/migrate-tool/HeaderBuildTest.cpp

Index: unittests/migrate-tool/HeaderBuildTest.cpp
===
--- /dev/null
+++ unittests/migrate-tool/HeaderBuildTest.cpp
@@ -0,0 +1,100 @@
+//===-- HeaderGeneratorTest.cpp - HeaderGenerator unit tests --===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "HeaderGenerator.h"
+#include "gtest/gtest.h"
+
+namespace clang {
+namespace migrate_tool {
+
+TEST(HeaderGenerator, Empty) {
+  HeaderGenerator Hdr("a.h");
+  std::string Expected = "#ifndef A_H\n"
+ "#define A_H\n"
+ "\n"
+ "#endif // A_H";
+  EXPECT_EQ(Expected, Hdr.generateContent());
+}
+
+TEST(HeaderGenerator, SingleAlias) {
+  HeaderGenerator Hdr("a/b/c.h");
+  Hdr.addAlias("na::nb::C", "x::y::Z");
+  std::string Expected = "#ifndef A_B_C_H\n"
+ "#define A_B_C_H\n"
+ "namespace na {\n"
+ "namespace nb {\n"
+ "using C = ::x::y::Z;\n"
+ "} // namespace nb\n"
+ "} // namespace na\n"
+ "#endif // A_B_C_H";
+  EXPECT_EQ(Expected, Hdr.generateContent());
+}
+
+TEST(HeaderGenerator, SingleAliasWithIncludes) {
+  HeaderGenerator Hdr("a/b/c.h");
+  Hdr.addInclude("x/y/z.h");
+  Hdr.addInclude("x/y/zz.h");
+  Hdr.addAlias("na::nb::C", "x::y::Z");
+  std::string Expected = "#ifndef A_B_C_H\n"
+ "#define A_B_C_H\n"
+ "#include \"x/y/z.h\"\n"
+ "#include \"x/y/zz.h\"\n"
+ "namespace na {\n"
+ "namespace nb {\n"
+ "using C = ::x::y::Z;\n"
+ "} // namespace nb\n"
+ "} // namespace na\n"
+ "#endif // A_B_C_H";
+  EXPECT_EQ(Expected, Hdr.generateContent());
+}
+
+TEST(HeaderGenerator, MultipleAliasInOneNamespace) {
+  HeaderGenerator Hdr("a/b/c.h");
+  Hdr.addAlias("na::nb::C", "x::y::Z");
+  Hdr.addAlias("na::nb::D", "x::y::D");
+  Hdr.addAlias("na::nb::Q", "x::y::Q");
+  std::string Expected = "#ifndef A_B_C_H\n"
+ "#define A_B_C_H\n"
+ "namespace na {\n"
+ "namespace nb {\n"
+ "using C = ::x::y::Z;\n"
+ "using D = ::x::y::D;\n"
+ "using Q = ::x::y::Q;\n"
+ "} // namespace nb\n"
+ "} // namespace na\n"
+ "#endif // A_B_C_H";
+  EXPECT_EQ(Expected, Hdr.generateContent());
+}
+
+TEST(HeaderGenerator, AliasesInMultipleNamespace) {
+  HeaderGenerator Hdr("a/b/c.h");
+  Hdr.addAlias("nb::Q", "x::Q");
+  Hdr.addAlias("na::nb::C", "x::y::Z");
+  Hdr.addAlias("na::nc::D", "x::y::D");
+  Hdr.addAlias("na::nb::Q", "x::y::Q");
+  std::string Expected = "#ifndef A_B_C_H\n"
+ "#define A_B_C_H\n"
+ "namespace nb {\n"
+ "using Q = ::x::Q;\n"
+ "} // namespace nb\n"
+ "namespace na {\n"
+ "namespace nb {\n"
+ "using C = ::x::y::Z;\n"
+ "using Q = ::x::y::Q;\n"
+ "} // namespace nb\n"
+ "namespace nc {\n"
+ "using D = ::x::y::D;\n"
+ "} // namespace nc\n"
+ "} // namespace na\n"
+ "#endif // A_B_C_H";
+  EXPECT_EQ(Expected, Hdr.generateContent());
+}
+
+} // namespace migrate_tool
+} // namespace clang
Index: unittests/migrate-tool/DummyMigrationEnvironment.h
===
--- /dev/null
+++ unittes

[clang-tools-extra] r282486 - Workaround ASTMatcher crashes. Added some more test cases.

2016-09-27 Thread Eric Liu via cfe-commits
Author: ioeric
Date: Tue Sep 27 07:54:48 2016
New Revision: 282486

URL: http://llvm.org/viewvc/llvm-project?rev=282486&view=rev
Log:
Workaround ASTMatcher crashes. Added some more test cases.

Summary:
- UsingDecl matcher crashed when `UsingShadowDecl` has no parent map. 
Workaround by moving parent check into `UsingDecl`.
- FunctionDecl matcher crashed when there is a lambda defined in parameter list 
(also due to no parent map).
  Workaround by putting `unless(cxxMethodDecl())` before parent check.

Reviewers: klimek, sbenza, aaron.ballman, hokein

Subscribers: aaron.ballman, cfe-commits

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

Modified:
clang-tools-extra/trunk/change-namespace/ChangeNamespace.cpp
clang-tools-extra/trunk/unittests/change-namespace/ChangeNamespaceTests.cpp

Modified: clang-tools-extra/trunk/change-namespace/ChangeNamespace.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/change-namespace/ChangeNamespace.cpp?rev=282486&r1=282485&r2=282486&view=diff
==
--- clang-tools-extra/trunk/change-namespace/ChangeNamespace.cpp (original)
+++ clang-tools-extra/trunk/change-namespace/ChangeNamespace.cpp Tue Sep 27 
07:54:48 2016
@@ -256,9 +256,10 @@ void ChangeNamespaceTool::registerMatche
   auto DeclMatcher = namedDecl(
   hasAncestor(namespaceDecl()),
   unless(anyOf(
-  hasAncestor(namespaceDecl(isAnonymous())),
+  isImplicit(), hasAncestor(namespaceDecl(isAnonymous())),
   hasAncestor(cxxRecordDecl()),
   allOf(IsInMovedNs, unless(cxxRecordDecl(unless(isDefinition(;
+
   // Match TypeLocs on the declaration. Carefully match only the outermost
   // TypeLoc that's directly linked to the old class and don't handle nested
   // name specifier locs.
@@ -271,10 +272,13 @@ void ChangeNamespaceTool::registerMatche
   hasAncestor(decl().bind("dc")))
   .bind("type"),
   this);
+
   // Types in `UsingShadowDecl` is not matched by `typeLoc` above, so we need 
to
   // special case it.
   Finder->addMatcher(
-  usingDecl(hasAnyUsingShadowDecl(IsInMovedNs)).bind("using_decl"), this);
+  usingDecl(IsInMovedNs, hasAnyUsingShadowDecl(decl())).bind("using_decl"),
+  this);
+
   // Handle types in nested name specifier.
   Finder->addMatcher(nestedNameSpecifierLoc(
  hasAncestor(decl(IsInMovedNs).bind("dc")),
@@ -284,18 +288,19 @@ void ChangeNamespaceTool::registerMatche
  this);
 
   // Handle function.
-  // Only handle functions that are defined in a namespace excluding static
-  // methods (qualified by nested specifier) and functions defined in the 
global
-  // namespace.
+  // Only handle functions that are defined in a namespace excluding member
+  // function, static methods (qualified by nested specifier), and functions
+  // defined in the global namespace.
   // Note that the matcher does not exclude calls to out-of-line static method
   // definitions, so we need to exclude them in the callback handler.
-  auto FuncMatcher = functionDecl(
-  hasParent(namespaceDecl()),
-  unless(anyOf(IsInMovedNs, hasAncestor(namespaceDecl(isAnonymous())),
-   hasAncestor(cxxRecordDecl();
+  auto FuncMatcher =
+  functionDecl(unless(anyOf(cxxMethodDecl(), IsInMovedNs,
+hasAncestor(namespaceDecl(isAnonymous())),
+hasAncestor(cxxRecordDecl(,
+   hasParent(namespaceDecl()));
   Finder->addMatcher(
   decl(forEachDescendant(callExpr(callee(FuncMatcher)).bind("call")),
-   IsInMovedNs)
+   IsInMovedNs, unless(isImplicit()))
   .bind("dc"),
   this);
 }
@@ -432,6 +437,8 @@ void ChangeNamespaceTool::moveClassForwa
 
 // Replaces a qualified symbol that refers to a declaration `DeclName` with the
 // shortest qualified name possible when the reference is in `NewNamespace`.
+// FIXME: don't need to add redundant namespace qualifier when there is
+// UsingShadowDecl or using namespace decl.
 void ChangeNamespaceTool::replaceQualifiedSymbolInDeclContext(
 const ast_matchers::MatchFinder::MatchResult &Result, const Decl *DeclCtx,
 SourceLocation Start, SourceLocation End, llvm::StringRef DeclName) {

Modified: 
clang-tools-extra/trunk/unittests/change-namespace/ChangeNamespaceTests.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/unittests/change-namespace/ChangeNamespaceTests.cpp?rev=282486&r1=282485&r2=282486&view=diff
==
--- clang-tools-extra/trunk/unittests/change-namespace/ChangeNamespaceTests.cpp 
(original)
+++ clang-tools-extra/trunk/unittests/change-namespace/ChangeNamespaceTests.cpp 
Tue Sep 27 07:54:48 2016
@@ -229,8 +229,23 @@ TEST_F(ChangeNamespaceTest, MoveFunction
   EXPECT_EQ(format(Expected), runChangeNamespaceOnCode(Cod

Re: [PATCH] D24862: Workaround ASTMatcher crashes. Added some more test cases.

2016-09-27 Thread Eric Liu via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL282486: Workaround ASTMatcher crashes. Added some more test 
cases. (authored by ioeric).

Changed prior to commit:
  https://reviews.llvm.org/D24862?vs=72284&id=72640#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D24862

Files:
  clang-tools-extra/trunk/change-namespace/ChangeNamespace.cpp
  clang-tools-extra/trunk/unittests/change-namespace/ChangeNamespaceTests.cpp

Index: clang-tools-extra/trunk/unittests/change-namespace/ChangeNamespaceTests.cpp
===
--- clang-tools-extra/trunk/unittests/change-namespace/ChangeNamespaceTests.cpp
+++ clang-tools-extra/trunk/unittests/change-namespace/ChangeNamespaceTests.cpp
@@ -229,8 +229,23 @@
   EXPECT_EQ(format(Expected), runChangeNamespaceOnCode(Code));
 }
 
+TEST_F(ChangeNamespaceTest, DoNotCrashWithLambdaAsParameter) {
+  std::string Code =
+  "#include \n"
+  "void f(std::function func, int param) { func(param); } "
+  "void g() { f([](int x) {}, 1); }";
+
+  std::string Expected =
+  "#include \n"
+  "void f(std::function func, int param) { func(param); } "
+  "void g() { f([](int x) {}, 1); }";
+  EXPECT_EQ(format(Expected), runChangeNamespaceOnCode(Code));
+}
+
 TEST_F(ChangeNamespaceTest, FixUsingShadowDecl) {
-  std::string Code = "namespace na {\n"
+  std::string Code = "class GLOB {};\n"
+ "using BLOG = GLOB;\n"
+ "namespace na {\n"
  "namespace nc {\n"
  "class SAME {};\n"
  "}\n"
@@ -245,7 +260,9 @@
  "} // namespace nb\n"
  "} // namespace na\n";
 
-  std::string Expected = "namespace na {\n"
+  std::string Expected = "class GLOB {};\n"
+ "using BLOG = GLOB;\n"
+ "namespace na {\n"
  "namespace nc {\n"
  "class SAME {};\n"
  "}\n"
@@ -265,6 +282,85 @@
   EXPECT_EQ(format(Expected), runChangeNamespaceOnCode(Code));
 }
 
+TEST_F(ChangeNamespaceTest, UsingShadowDeclInFunction) {
+  std::string Code = "namespace glob {\n"
+ "class Glob {};\n"
+ "}\n"
+ "namespace na {\n"
+ "namespace nb {\n"
+ "void f() {\n"
+ "  using glob::Glob;\n"
+ "  Glob g;\n"
+ "}\n"
+ "} // namespace nb\n"
+ "} // namespace na\n";
+
+  // FIXME: don't add namespace qualifier when there is UsingShadowDecl.
+  std::string Expected = "namespace glob {\n"
+ "class Glob {};\n"
+ "}\n"
+ "\n"
+ "namespace x {\n"
+ "namespace y {\n"
+ "void f() {\n"
+ "  using ::glob::Glob;\n"
+ "  glob::Glob g;\n"
+ "}\n"
+ "} // namespace y\n"
+ "} // namespace x\n";
+  EXPECT_EQ(format(Expected), runChangeNamespaceOnCode(Code));
+}
+
+TEST_F(ChangeNamespaceTest, UsingShadowDeclInGlobal) {
+  std::string Code = "namespace glob {\n"
+ "class Glob {};\n"
+ "}\n"
+ "using glob::Glob;\n"
+ "namespace na {\n"
+ "namespace nb {\n"
+ "void f() { Glob g; }\n"
+ "} // namespace nb\n"
+ "} // namespace na\n";
+
+  // FIXME: don't add namespace qualifier when there is UsingShadowDecl.
+  std::string Expected = "namespace glob {\n"
+ "class Glob {};\n"
+ "}\n"
+ "using glob::Glob;\n"
+ "\n"
+ "namespace x {\n"
+ "namespace y {\n"
+ "void f() { glob::Glob g; }\n"
+ "} // namespace y\n"
+ "} // namespace x\n";
+  EXPECT_EQ(format(Expected), runChangeNamespaceOnCode(Code));
+}
+
+TEST_F(ChangeNamespaceTest, UsingNamespace) {
+  std::string Code = "namespace glob {\n"
+ "class Glob {};\n"
+ "}\n"
+ "using namespace glob;\n"
+ "namespace na {\n"
+ "namespace nb {\n"
+ "void f() { Glob g; }\n"
+ "} // namespace nb\n"
+ "} // namespace na\n";
+
+  // FIXME: don't add namespace qualifier when there is "using namespace" decl.
+  std::string Expected = "namespace glob {\n"
+ "class Glob {};\n"
+ "}\n"
+ "using namespace glob;\n"
+ 

[PATCH] D24961: [avx512] Add aliases to some missing avx512 intrinsics.

2016-09-27 Thread Ayman Musa via cfe-commits
aymanmus created this revision.
aymanmus added reviewers: m_zuckerman, igorb, delena.
aymanmus added a subscriber: cfe-commits.

- "//_mm512_cmp_pd_mask//" Intrinsics, where  = {eq, le, lt, neq, nle, 
nlt, ord, unord}.
- //_mm512_cvtepi32lo_pd, _mm512_mask_cvtepi32lo_pd, _mm512_cvtepu32lo_pd, 
_mm512_mask_cvtepu32lo_pd//
- //_mm512_cvtpd_pslo, _mm512_mask_cvtpd_pslo, _mm512_cvtpslo_pd, 
_mm512_mask_cvtpslo_pd//

https://reviews.llvm.org/D24961

Files:
  lib/Headers/avx512fintrin.h
  test/CodeGen/avx512f-builtins.c

Index: lib/Headers/avx512fintrin.h
===
--- lib/Headers/avx512fintrin.h
+++ lib/Headers/avx512fintrin.h
@@ -3555,10 +3555,49 @@
 
 #define _mm512_cmp_ps_mask(A, B, P) \
   _mm512_cmp_round_ps_mask((A), (B), (P), _MM_FROUND_CUR_DIRECTION)
-
 #define _mm512_mask_cmp_ps_mask(U, A, B, P) \
   _mm512_mask_cmp_round_ps_mask((U), (A), (B), (P), _MM_FROUND_CUR_DIRECTION)
 
+#define _mm512_cmpeq_ps_mask(A, B) \
+_mm512_cmp_ps_mask((A), (B), _CMP_EQ_OQ)
+#define _mm512_mask_cmpeq_ps_mask(k, A, B) \
+_mm512_mask_cmp_ps_mask((k), (A), (B), _CMP_EQ_OQ)
+
+#define _mm512_cmplt_ps_mask(A, B) \
+_mm512_cmp_ps_mask((A), (B), _CMP_LT_OS)
+#define _mm512_mask_cmplt_ps_mask(k, A, B) \
+_mm512_mask_cmp_ps_mask((k), (A), (B), _CMP_LT_OS)
+
+#define _mm512_cmple_ps_mask(A, B) \
+_mm512_cmp_ps_mask((A), (B), _CMP_LE_OS)
+#define _mm512_mask_cmple_ps_mask(k, A, B) \
+_mm512_mask_cmp_ps_mask((k), (A), (B), _CMP_LE_OS)
+
+#define _mm512_cmpunord_ps_mask(A, B) \
+_mm512_cmp_ps_mask((A), (B), _CMP_UNORD_Q)
+#define _mm512_mask_cmpunord_ps_mask(k, A, B) \
+_mm512_mask_cmp_ps_mask((k), (A), (B), _CMP_UNORD_Q)
+
+#define _mm512_cmpneq_ps_mask(A, B) \
+_mm512_cmp_ps_mask((A), (B), _CMP_NEQ_UQ)
+#define _mm512_mask_cmpneq_ps_mask(k, A, B) \
+_mm512_mask_cmp_ps_mask((k), (A), (B), _CMP_NEQ_UQ)
+
+#define _mm512_cmpnlt_ps_mask(A, B) \
+_mm512_cmp_ps_mask((A), (B), _CMP_NLT_US)
+#define _mm512_mask_cmpnlt_ps_mask(k, A, B) \
+_mm512_mask_cmp_ps_mask((k), (A), (B), _CMP_NLT_US)
+
+#define _mm512_cmpnle_ps_mask(A, B) \
+_mm512_cmp_ps_mask((A), (B), _CMP_NLE_US)
+#define _mm512_mask_cmpnle_ps_mask(k, A, B) \
+_mm512_mask_cmp_ps_mask((k), (A), (B), _CMP_NLE_US)
+
+#define _mm512_cmpord_ps_mask(A, B) \
+_mm512_cmp_ps_mask((A), (B), _CMP_ORD_Q)
+#define _mm512_mask_cmpord_ps_mask(k, A, B) \
+_mm512_mask_cmp_ps_mask((k), (A), (B), _CMP_ORD_Q)
+
 #define _mm512_cmp_round_pd_mask(A, B, P, R) __extension__ ({ \
   (__mmask8)__builtin_ia32_cmppd512_mask((__v8df)(__m512d)(A), \
  (__v8df)(__m512d)(B), (int)(P), \
@@ -3571,10 +3610,49 @@
 
 #define _mm512_cmp_pd_mask(A, B, P) \
   _mm512_cmp_round_pd_mask((A), (B), (P), _MM_FROUND_CUR_DIRECTION)
-
 #define _mm512_mask_cmp_pd_mask(U, A, B, P) \
   _mm512_mask_cmp_round_pd_mask((U), (A), (B), (P), _MM_FROUND_CUR_DIRECTION)
 
+#define _mm512_cmpeq_pd_mask(A, B) \
+_mm512_cmp_pd_mask((A), (B), _CMP_EQ_OQ)
+#define _mm512_mask_cmpeq_pd_mask(k, A, B) \
+_mm512_mask_cmp_pd_mask((k), (A), (B), _CMP_EQ_OQ)
+
+#define _mm512_cmplt_pd_mask(A, B) \
+_mm512_cmp_pd_mask((A), (B), _CMP_LT_OS)
+#define _mm512_mask_cmplt_pd_mask(k, A, B) \
+_mm512_mask_cmp_pd_mask((k), (A), (B), _CMP_LT_OS)
+
+#define _mm512_cmple_pd_mask(A, B) \
+_mm512_cmp_pd_mask((A), (B), _CMP_LE_OS)
+#define _mm512_mask_cmple_pd_mask(k, A, B) \
+_mm512_mask_cmp_pd_mask((k), (A), (B), _CMP_LE_OS)
+
+#define _mm512_cmpunord_pd_mask(A, B) \
+_mm512_cmp_pd_mask((A), (B), _CMP_UNORD_Q)
+#define _mm512_mask_cmpunord_pd_mask(k, A, B) \
+_mm512_mask_cmp_pd_mask((k), (A), (B), _CMP_UNORD_Q)
+
+#define _mm512_cmpneq_pd_mask(A, B) \
+_mm512_cmp_pd_mask((A), (B), _CMP_NEQ_UQ)
+#define _mm512_mask_cmpneq_pd_mask(k, A, B) \
+_mm512_mask_cmp_pd_mask((k), (A), (B), _CMP_NEQ_UQ)
+
+#define _mm512_cmpnlt_pd_mask(A, B) \
+_mm512_cmp_pd_mask((A), (B), _CMP_NLT_US)
+#define _mm512_mask_cmpnlt_pd_mask(k, A, B) \
+_mm512_mask_cmp_pd_mask((k), (A), (B), _CMP_NLT_US)
+
+#define _mm512_cmpnle_pd_mask(A, B) \
+_mm512_cmp_pd_mask((A), (B), _CMP_NLE_US)
+#define _mm512_mask_cmpnle_pd_mask(k, A, B) \
+_mm512_mask_cmp_pd_mask((k), (A), (B), _CMP_NLE_US)
+
+#define _mm512_cmpord_pd_mask(A, B) \
+_mm512_cmp_pd_mask((A), (B), _CMP_ORD_Q)
+#define _mm512_mask_cmpord_pd_mask(k, A, B) \
+_mm512_mask_cmp_pd_mask((k), (A), (B), _CMP_ORD_Q)
+
 /* Conversion */
 
 #define _mm512_cvtt_roundps_epu32(A, R) __extension__ ({ \
@@ -3703,6 +3781,18 @@
 (__mmask8) __U);
 }
 
+static __inline__ __m512d __DEFAULT_FN_ATTRS
+_mm512_cvtepi32lo_pd(__m512i __A)
+{
+  return (__m512d) _mm512_cvtepi32_pd(_mm512_castsi512_si256(__A));
+}
+
+static __inline__ __m512d __DEFAULT_FN_ATTRS
+_mm512_mask_cvtepi32lo_pd(__m512d __W, __mmask8 __U,__m512i __A)
+{
+  return (__m512d) _mm512_mask_cvtepi32_pd(__W, __U, _mm512_castsi512_si256(__A));
+}
+
 static __inline

Re: [PATCH] D24800: Merge conflicting replacements when they are order-independent.

2016-09-27 Thread Eric Liu via cfe-commits
ioeric added inline comments.


Comment at: lib/Tooling/Core/Replacement.cpp:179-181
@@ +178,5 @@
+Replacements::mergeIfOrderIndependent(const Replacement &R) const {
+  Replacements Rs(R);
+  Replacements ShiftedRs(getReplacementInChangedCode(R));
+  Replacements ShiftedReplaces;
+  for (const auto &Replace : Replaces)

klimek wrote:
> These names are confusing me...
> 
Trying to make names less confusing... any better now? 


Comment at: lib/Tooling/Core/Replacement.cpp:184
@@ +183,3 @@
+ShiftedReplaces.Replaces.insert(Rs.getReplacementInChangedCode(Replace));
+  auto MergeRs = merge(ShiftedRs);
+  auto MergeReplaces = Rs.merge(ShiftedReplaces);

klimek wrote:
> This comes from a single replacement - why do we need to call merge?
Because it refers to code after `Replaces` are applied?


https://reviews.llvm.org/D24800



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


Re: [PATCH] D24800: Merge conflicting replacements when they are order-independent.

2016-09-27 Thread Eric Liu via cfe-commits
ioeric updated this revision to Diff 72642.
ioeric marked 6 inline comments as done.
ioeric added a comment.

- Addressed review comments.


https://reviews.llvm.org/D24800

Files:
  include/clang/Tooling/Core/Replacement.h
  lib/Tooling/Core/Replacement.cpp
  unittests/Tooling/RefactoringTest.cpp

Index: unittests/Tooling/RefactoringTest.cpp
===
--- unittests/Tooling/RefactoringTest.cpp
+++ unittests/Tooling/RefactoringTest.cpp
@@ -101,18 +101,56 @@
 
 TEST_F(ReplacementTest, FailAddReplacements) {
   Replacements Replaces;
-  auto Err = Replaces.add(Replacement("x.cc", 0, 10, "3"));
+  Replacement Deletion("x.cc", 0, 10, "3");
+  auto Err = Replaces.add(Deletion);
   EXPECT_TRUE(!Err);
   llvm::consumeError(std::move(Err));
-  Err = Replaces.add(Replacement("x.cc", 0, 2, ""));
+  Err = Replaces.add(Replacement("x.cc", 0, 2, "a"));
   EXPECT_TRUE((bool)Err);
   llvm::consumeError(std::move(Err));
-  Err = Replaces.add(Replacement("x.cc", 2, 2, ""));
+  Err = Replaces.add(Replacement("x.cc", 2, 2, "a"));
   EXPECT_TRUE((bool)Err);
   llvm::consumeError(std::move(Err));
   Err = Replaces.add(Replacement("y.cc", 20, 2, ""));
   EXPECT_TRUE((bool)Err);
   llvm::consumeError(std::move(Err));
+  EXPECT_EQ(1u, Replaces.size());
+  EXPECT_EQ(Deletion, *Replaces.begin());
+}
+
+TEST_F(ReplacementTest, DeletionInReplacements) {
+  Replacements Replaces;
+  Replacement R("x.cc", 0, 10, "3");
+  auto Err = Replaces.add(R);
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+  Err = Replaces.add(Replacement("x.cc", 0, 2, ""));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+  Err = Replaces.add(Replacement("x.cc", 2, 2, ""));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+  EXPECT_EQ(1u, Replaces.size());
+  EXPECT_EQ(R, *Replaces.begin());
+}
+
+TEST_F(ReplacementTest, OverlappingReplacements) {
+  Replacements Replaces;
+  auto Err = Replaces.add(Replacement("x.cc", 0, 3, "345"));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+  Err = Replaces.add(Replacement("x.cc", 2, 3, "543"));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  EXPECT_EQ(1u, Replaces.size());
+  EXPECT_EQ(Replacement("x.cc", 0, 5, "34543"), *Replaces.begin());
+
+  Err = Replaces.add(Replacement("x.cc", 2, 1, "5"));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+  EXPECT_EQ(1u, Replaces.size());
+  EXPECT_EQ(Replacement("x.cc", 0, 5, "34543"), *Replaces.begin());
 }
 
 TEST_F(ReplacementTest, AddAdjacentInsertionAndReplacement) {
@@ -137,6 +175,116 @@
   EXPECT_EQ(Replaces.size(), 2u);
 }
 
+TEST_F(ReplacementTest, MergeNewDeletions) {
+  Replacements Replaces;
+  Replacement ContainingReplacement("x.cc", 0, 10, "");
+  auto Err = Replaces.add(ContainingReplacement);
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  Err = Replaces.add(Replacement("x.cc", 5, 3, ""));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  Err = Replaces.add(Replacement("x.cc", 0, 10, ""));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  Err = Replaces.add(Replacement("x.cc", 5, 5, ""));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  EXPECT_EQ(1u, Replaces.size());
+  EXPECT_EQ(*Replaces.begin(), ContainingReplacement);
+}
+
+TEST_F(ReplacementTest, MergeOverlappingButNotAdjacentReplacement) {
+  Replacements Replaces;
+  auto Err = Replaces.add(Replacement("x.cc", 0, 2, ""));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  Err = Replaces.add(Replacement("x.cc", 5, 5, ""));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  Replacement After = Replacement("x.cc", 10, 5, "");
+  Err = Replaces.add(After);
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  Replacement ContainingReplacement("x.cc", 0, 10, "");
+  Err = Replaces.add(ContainingReplacement);
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  EXPECT_EQ(2u, Replaces.size());
+  EXPECT_EQ(*Replaces.begin(), ContainingReplacement);
+  EXPECT_EQ(*(++Replaces.begin()), After);
+}
+
+TEST_F(ReplacementTest, InsertionBeforeMergedDeletions) {
+  Replacements Replaces;
+
+  Replacement Insertion("x.cc", 0, 0, "123");
+  auto Err = Replaces.add(Insertion);
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  Err = Replaces.add(Replacement("x.cc", 5, 5, ""));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  Replacement Deletion("x.cc", 0, 10, "");
+  Err = Replaces.add(Deletion);
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  EXPECT_EQ(2u, Replaces.size());
+  EXPECT_EQ(*Replaces.begin(), Insertion);
+  EXPECT_EQ(*(++Replaces.begin()), Deletion);
+}
+
+TEST_F(ReplacementTest, MergeOverlappingDeletions) {
+  Replacements Replaces;
+  auto Err = Replaces.add(Replacement("x.cc", 0, 2, ""));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  Err = Replaces.add(Replacement("x.cc", 0, 5, "

Re: [PATCH] D24961: [avx512] Add aliases to some missing avx512 intrinsics.

2016-09-27 Thread Igor Breger via cfe-commits
igorb accepted this revision.
igorb added a comment.
This revision is now accepted and ready to land.

LGTM


https://reviews.llvm.org/D24961



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


[PATCH] D24962: [ASTMatchers] Let registerMatcher() take a const char * instead of a StringRef

2016-09-27 Thread Martin Böhme via cfe-commits
mboehme created this revision.
mboehme added a reviewer: klimek.
mboehme added a subscriber: cfe-commits.
Herald added a subscriber: klimek.

r282433 added LLVM_ATTRIBUTE_ALWAYS_INLINE to the StringRef(const char *)
constructor. This causes the size of the stack frame for
RegistryMaps::RegistryMaps() to become excessive when compiling with gcc. This
change avoids inlining the StringRef constructor for every REGISTER_MATCHER
line.

https://reviews.llvm.org/D24962

Files:
  lib/ASTMatchers/Dynamic/Registry.cpp

Index: lib/ASTMatchers/Dynamic/Registry.cpp
===
--- lib/ASTMatchers/Dynamic/Registry.cpp
+++ lib/ASTMatchers/Dynamic/Registry.cpp
@@ -40,11 +40,11 @@
   const ConstructorMap &constructors() const { return Constructors; }
 
 private:
-  void registerMatcher(StringRef MatcherName, MatcherDescriptor *Callback);
+  void registerMatcher(const char *MatcherName, MatcherDescriptor *Callback);
   ConstructorMap Constructors;
 };
 
-void RegistryMaps::registerMatcher(StringRef MatcherName,
+void RegistryMaps::registerMatcher(const char *MatcherName,
MatcherDescriptor *Callback) {
   assert(Constructors.find(MatcherName) == Constructors.end());
   Constructors[MatcherName] = Callback;


Index: lib/ASTMatchers/Dynamic/Registry.cpp
===
--- lib/ASTMatchers/Dynamic/Registry.cpp
+++ lib/ASTMatchers/Dynamic/Registry.cpp
@@ -40,11 +40,11 @@
   const ConstructorMap &constructors() const { return Constructors; }
 
 private:
-  void registerMatcher(StringRef MatcherName, MatcherDescriptor *Callback);
+  void registerMatcher(const char *MatcherName, MatcherDescriptor *Callback);
   ConstructorMap Constructors;
 };
 
-void RegistryMaps::registerMatcher(StringRef MatcherName,
+void RegistryMaps::registerMatcher(const char *MatcherName,
MatcherDescriptor *Callback) {
   assert(Constructors.find(MatcherName) == Constructors.end());
   Constructors[MatcherName] = Callback;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D24119: [libc++] add linker option "-Wl, -z, defs" in standalone build

2016-09-27 Thread Asiri Rathnayake via cfe-commits
rmaprath added a subscriber: rmaprath.


Comment at: libcxx/trunk/CMakeLists.txt:329
@@ +328,3 @@
+  ${CMAKE_SYSTEM_NAME} MATCHES "OpenBSD") AND
+ NOT LLVM_USE_SANITIZER)
+set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -Wl,-z,defs")

Perhaps we should exclude `LIBCXX_HAS_EXTERNAL_THREAD_API` as well? Because 
there we explicitly strip off these flags.


Repository:
  rL LLVM

https://reviews.llvm.org/D24119



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


Re: [PATCH] D24962: [ASTMatchers] Let registerMatcher() take a const char * instead of a StringRef

2016-09-27 Thread Martin Böhme via cfe-commits
mboehme abandoned this revision.
mboehme added a comment.

Abandoning after discussion with klimek.


https://reviews.llvm.org/D24962



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


r282488 - [avx512] Add aliases to some missing avx512 intrinsics.

2016-09-27 Thread Ayman Musa via cfe-commits
Author: aymanmus
Date: Tue Sep 27 09:06:32 2016
New Revision: 282488

URL: http://llvm.org/viewvc/llvm-project?rev=282488&view=rev
Log:
[avx512] Add aliases to some missing avx512 intrinsics.

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

Modified:
cfe/trunk/lib/Headers/avx512fintrin.h
cfe/trunk/test/CodeGen/avx512f-builtins.c

Modified: cfe/trunk/lib/Headers/avx512fintrin.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/avx512fintrin.h?rev=282488&r1=282487&r2=282488&view=diff
==
--- cfe/trunk/lib/Headers/avx512fintrin.h (original)
+++ cfe/trunk/lib/Headers/avx512fintrin.h Tue Sep 27 09:06:32 2016
@@ -3555,10 +3555,49 @@ _mm512_mask_blend_epi32(__mmask16 __U, _
 
 #define _mm512_cmp_ps_mask(A, B, P) \
   _mm512_cmp_round_ps_mask((A), (B), (P), _MM_FROUND_CUR_DIRECTION)
-
 #define _mm512_mask_cmp_ps_mask(U, A, B, P) \
   _mm512_mask_cmp_round_ps_mask((U), (A), (B), (P), _MM_FROUND_CUR_DIRECTION)
 
+#define _mm512_cmpeq_ps_mask(A, B) \
+_mm512_cmp_ps_mask((A), (B), _CMP_EQ_OQ)
+#define _mm512_mask_cmpeq_ps_mask(k, A, B) \
+_mm512_mask_cmp_ps_mask((k), (A), (B), _CMP_EQ_OQ)
+
+#define _mm512_cmplt_ps_mask(A, B) \
+_mm512_cmp_ps_mask((A), (B), _CMP_LT_OS)
+#define _mm512_mask_cmplt_ps_mask(k, A, B) \
+_mm512_mask_cmp_ps_mask((k), (A), (B), _CMP_LT_OS)
+
+#define _mm512_cmple_ps_mask(A, B) \
+_mm512_cmp_ps_mask((A), (B), _CMP_LE_OS)
+#define _mm512_mask_cmple_ps_mask(k, A, B) \
+_mm512_mask_cmp_ps_mask((k), (A), (B), _CMP_LE_OS)
+
+#define _mm512_cmpunord_ps_mask(A, B) \
+_mm512_cmp_ps_mask((A), (B), _CMP_UNORD_Q)
+#define _mm512_mask_cmpunord_ps_mask(k, A, B) \
+_mm512_mask_cmp_ps_mask((k), (A), (B), _CMP_UNORD_Q)
+
+#define _mm512_cmpneq_ps_mask(A, B) \
+_mm512_cmp_ps_mask((A), (B), _CMP_NEQ_UQ)
+#define _mm512_mask_cmpneq_ps_mask(k, A, B) \
+_mm512_mask_cmp_ps_mask((k), (A), (B), _CMP_NEQ_UQ)
+
+#define _mm512_cmpnlt_ps_mask(A, B) \
+_mm512_cmp_ps_mask((A), (B), _CMP_NLT_US)
+#define _mm512_mask_cmpnlt_ps_mask(k, A, B) \
+_mm512_mask_cmp_ps_mask((k), (A), (B), _CMP_NLT_US)
+
+#define _mm512_cmpnle_ps_mask(A, B) \
+_mm512_cmp_ps_mask((A), (B), _CMP_NLE_US)
+#define _mm512_mask_cmpnle_ps_mask(k, A, B) \
+_mm512_mask_cmp_ps_mask((k), (A), (B), _CMP_NLE_US)
+
+#define _mm512_cmpord_ps_mask(A, B) \
+_mm512_cmp_ps_mask((A), (B), _CMP_ORD_Q)
+#define _mm512_mask_cmpord_ps_mask(k, A, B) \
+_mm512_mask_cmp_ps_mask((k), (A), (B), _CMP_ORD_Q)
+
 #define _mm512_cmp_round_pd_mask(A, B, P, R) __extension__ ({ \
   (__mmask8)__builtin_ia32_cmppd512_mask((__v8df)(__m512d)(A), \
  (__v8df)(__m512d)(B), (int)(P), \
@@ -3571,10 +3610,49 @@ _mm512_mask_blend_epi32(__mmask16 __U, _
 
 #define _mm512_cmp_pd_mask(A, B, P) \
   _mm512_cmp_round_pd_mask((A), (B), (P), _MM_FROUND_CUR_DIRECTION)
-
 #define _mm512_mask_cmp_pd_mask(U, A, B, P) \
   _mm512_mask_cmp_round_pd_mask((U), (A), (B), (P), _MM_FROUND_CUR_DIRECTION)
 
+#define _mm512_cmpeq_pd_mask(A, B) \
+_mm512_cmp_pd_mask((A), (B), _CMP_EQ_OQ)
+#define _mm512_mask_cmpeq_pd_mask(k, A, B) \
+_mm512_mask_cmp_pd_mask((k), (A), (B), _CMP_EQ_OQ)
+
+#define _mm512_cmplt_pd_mask(A, B) \
+_mm512_cmp_pd_mask((A), (B), _CMP_LT_OS)
+#define _mm512_mask_cmplt_pd_mask(k, A, B) \
+_mm512_mask_cmp_pd_mask((k), (A), (B), _CMP_LT_OS)
+
+#define _mm512_cmple_pd_mask(A, B) \
+_mm512_cmp_pd_mask((A), (B), _CMP_LE_OS)
+#define _mm512_mask_cmple_pd_mask(k, A, B) \
+_mm512_mask_cmp_pd_mask((k), (A), (B), _CMP_LE_OS)
+
+#define _mm512_cmpunord_pd_mask(A, B) \
+_mm512_cmp_pd_mask((A), (B), _CMP_UNORD_Q)
+#define _mm512_mask_cmpunord_pd_mask(k, A, B) \
+_mm512_mask_cmp_pd_mask((k), (A), (B), _CMP_UNORD_Q)
+
+#define _mm512_cmpneq_pd_mask(A, B) \
+_mm512_cmp_pd_mask((A), (B), _CMP_NEQ_UQ)
+#define _mm512_mask_cmpneq_pd_mask(k, A, B) \
+_mm512_mask_cmp_pd_mask((k), (A), (B), _CMP_NEQ_UQ)
+
+#define _mm512_cmpnlt_pd_mask(A, B) \
+_mm512_cmp_pd_mask((A), (B), _CMP_NLT_US)
+#define _mm512_mask_cmpnlt_pd_mask(k, A, B) \
+_mm512_mask_cmp_pd_mask((k), (A), (B), _CMP_NLT_US)
+
+#define _mm512_cmpnle_pd_mask(A, B) \
+_mm512_cmp_pd_mask((A), (B), _CMP_NLE_US)
+#define _mm512_mask_cmpnle_pd_mask(k, A, B) \
+_mm512_mask_cmp_pd_mask((k), (A), (B), _CMP_NLE_US)
+
+#define _mm512_cmpord_pd_mask(A, B) \
+_mm512_cmp_pd_mask((A), (B), _CMP_ORD_Q)
+#define _mm512_mask_cmpord_pd_mask(k, A, B) \
+_mm512_mask_cmp_pd_mask((k), (A), (B), _CMP_ORD_Q)
+
 /* Conversion */
 
 #define _mm512_cvtt_roundps_epu32(A, R) __extension__ ({ \
@@ -3703,6 +3781,18 @@ _mm512_maskz_cvtepi32_pd (__mmask8 __U,
 (__mmask8) __U);
 }
 
+static __inline__ __m512d __DEFAULT_FN_ATTRS
+_mm512_cvtepi32lo_pd(__m512i __A)
+{
+  return (__m512d) _mm512_cvtepi32_pd(_mm512_castsi512_si256(__A));
+}
+
+static __inline__ __m512d __DEFAULT_FN_ATTRS
+_mm512_mask_cvtepi32lo_

[PATCH] D24963: [change-namespace] fix namespace specifier of global variables.

2016-09-27 Thread Eric Liu via cfe-commits
ioeric created this revision.
ioeric added a reviewer: hokein.
ioeric added a subscriber: cfe-commits.

https://reviews.llvm.org/D24963

Files:
  change-namespace/ChangeNamespace.cpp
  unittests/change-namespace/ChangeNamespaceTests.cpp

Index: unittests/change-namespace/ChangeNamespaceTests.cpp
===
--- unittests/change-namespace/ChangeNamespaceTests.cpp
+++ unittests/change-namespace/ChangeNamespaceTests.cpp
@@ -447,6 +447,72 @@
   EXPECT_EQ(format(Expected), runChangeNamespaceOnCode(Code));
 }
 
+TEST_F(ChangeNamespaceTest, MoveAndFixGlobalVariables) {
+  std::string Code = "namespace na {\n"
+ "int GlobA;\n"
+ "static int GlobAStatic = 0;\n"
+ "namespace nc { int GlobC; }\n"
+ "namespace nb {\n"
+ "int GlobB;\n"
+ "void f() {\n"
+ "  int a = GlobA;\n"
+ "  int b = GlobAStatic;\n"
+ "  int c = nc::GlobC;\n"
+ "}\n"
+ "} // namespace nb\n"
+ "} // namespace na\n";
+
+  std::string Expected = "namespace na {\n"
+ "int GlobA;\n"
+ "static int GlobAStatic = 0;\n"
+ "namespace nc { int GlobC; }\n"
+ "\n"
+ "} // namespace na\n"
+ "namespace x {\n"
+ "namespace y {\n"
+ "int GlobB;\n"
+ "void f() {\n"
+ "  int a = na::GlobA;\n"
+ "  int b = na::GlobAStatic;\n"
+ "  int c = na::nc::GlobC;\n"
+ "}\n"
+ "}  // namespace y\n"
+ "}  // namespace x\n";
+
+  EXPECT_EQ(format(Expected), runChangeNamespaceOnCode(Code));
+}
+
+TEST_F(ChangeNamespaceTest, DoNotFixStaticVariableOfClass) {
+  std::string Code = "namespace na {\n"
+ "class A {\n"
+ "public:\n"
+ "static int A1;\n"
+ "static int A2;\n"
+ "}\n"
+ "static int A::A1 = 0;\n"
+ "namespace nb {\n"
+ "void f() { int a = A::A1; int b = A::A2; }"
+ "} // namespace nb\n"
+ "} // namespace na\n";
+
+  std::string Expected = "namespace na {\n"
+ "class A {\n"
+ "public:\n"
+ "static int A1;\n"
+ "static int A2;\n"
+ "}\n"
+ "static int A::A1 = 0;\n"
+ "\n"
+ "} // namespace na\n"
+ "namespace x {\n"
+ "namespace y {\n"
+ "void f() { int a = na::A::A1; int b = na::A::A2; }"
+ "}  // namespace y\n"
+ "}  // namespace x\n";
+
+  EXPECT_EQ(format(Expected), runChangeNamespaceOnCode(Code));
+}
+
 } // anonymous namespace
 } // namespace change_namespace
 } // namespace clang
Index: change-namespace/ChangeNamespace.cpp
===
--- change-namespace/ChangeNamespace.cpp
+++ change-namespace/ChangeNamespace.cpp
@@ -230,8 +230,6 @@
   DiffNewNamespace = joinNamespaces(NewNsSplitted);
 }
 
-// FIXME: handle the following symbols:
-//   - Variable references.
 void ChangeNamespaceTool::registerMatchers(ast_matchers::MatchFinder *Finder) {
   // Match old namespace blocks.
   std::string FullOldNs = "::" + OldNamespace;
@@ -303,6 +301,14 @@
IsInMovedNs, unless(isImplicit()))
   .bind("dc"),
   this);
+
+  auto GlobalVarMatcher = varDecl(
+  hasGlobalStorage(), hasParent(namespaceDecl()),
+  unless(anyOf(IsInMovedNs, hasAncestor(namespaceDecl(isAnonymous());
+  Finder->addMatcher(declRefExpr(IsInMovedNs, hasAncestor(decl().bind("dc")),
+ to(GlobalVarMatcher.bind("var_decl")))
+ .bind("var_ref"),
+ this);
 }
 
 void ChangeNamespaceTool::run(
@@ -324,8 +330,19 @@
   } else if (const auto *TLoc = Result.Nodes.getNodeAs("type")) {
 fixTypeLoc(Result, startLocationForType(*TLoc), EndLocationForType(*TLoc),
*TLoc);
+  } else if (const auto *VarRef = Result.Nodes.getNodeAs("var_ref")){
+const auto *Var = Result.Nodes.getNodeAs("var_decl");
+assert(Var);
+if (Var->getCanonicalDecl()->isStaticDataMember())
+  return;
+std::string Name = Var->getQualifiedNameAsString();
+const clang::Decl *Context = Result.Nodes.getNodeAs("dc");
+assert(Context && "Empty decl context.");
+clang::SourceRange VarRefRange = VarRef->getSource

Re: [PATCH] D24119: [libc++] add linker option "-Wl, -z, defs" in standalone build

2016-09-27 Thread Lei Zhang via cfe-commits
zlei added inline comments.


Comment at: libcxx/trunk/CMakeLists.txt:329
@@ +328,3 @@
+  ${CMAKE_SYSTEM_NAME} MATCHES "OpenBSD") AND
+ NOT LLVM_USE_SANITIZER)
+set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -Wl,-z,defs")

rmaprath wrote:
> Perhaps we should exclude `LIBCXX_HAS_EXTERNAL_THREAD_API` as well? Because 
> there we explicitly strip off these flags.
I agree. Could you prepare a patch for it?

BTW, I really don't like duplicating code snippet from llvm. Is there any 
better solution for that?


Repository:
  rL LLVM

https://reviews.llvm.org/D24119



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


Re: [PATCH] D24825: [X86] Remove the mm_malloc.h include guard hack from the X86 builtins tests

2016-09-27 Thread Simon Pilgrim via cfe-commits
RKSimon accepted this revision.
RKSimon added a comment.
This revision is now accepted and ready to land.

LGTM


https://reviews.llvm.org/D24825



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


Re: [PATCH] D24717: Merge deletions that are contained in a larger deletion.

2016-09-27 Thread Eric Liu via cfe-commits
ioeric abandoned this revision.
ioeric added a comment.

Abandon in favor of https://reviews.llvm.org/D24800


https://reviews.llvm.org/D24717



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


Re: [PATCH] D24864: [libcxxabi] Refactor pthread usage into a separate API

2016-09-27 Thread Asiri Rathnayake via cfe-commits
rmaprath added inline comments.


Comment at: src/config.h:22
@@ +21,3 @@
+
+#if defined(__GNUC__) || defined(__clang__)
+#define _LIBCXXABI_PRAGMA(_parameter_) _Pragma(#_parameter_)

EricWF wrote:
> What's the point of defining `_LIBCXXABI_WARNING`? It's unused and seems 
> unneeded.
Good catch. I have copy-pasted this lot without checking.


Comment at: src/config.h:41
@@ +40,3 @@
+defined(__CloudABI__) || \
+defined(__sun__)
+#  define _LIBCXXABI_HAS_THREAD_API_PTHREAD

compnerd wrote:
> Can you change this to `defined(__sun__) && defined(_POSIX_THREADS)` at the 
> very least?  There is no reason to assume pthreads on Solaris.  Solaris 
> Threads are a valid threading model.
Not sure if I understand completely, `libcxxabi` currently either supports 
`pthread` or no-threads, either of which can be explicitly configured through a 
cmake option. So I don't see the point in checking for `_POSIX_THREADS` here as 
the only current threading option is `pthread`. When we add another threading 
system into the mix (like external threading), that too will be configurable 
with a cmake option, the defaulting to `pthread` is only when no particular 
threading system is selected.

Or is it that `pthread.h` et. al can be provided by Solaris Threads as well? 
So, the pthread API has two implementations on Solaris?


Comment at: src/config.h:42
@@ +41,3 @@
+defined(__sun__)
+#  define _LIBCXXABI_HAS_THREAD_API_PTHREAD
+# else

compnerd wrote:
> Can we use `_LIBCXXABI_USE_THREAD_API_PTHREAD` instead?  You can have more 
> than one threading API on a platform, and wish to use a specific one.
Makes sense. Need to change the convention used in `libcxx` too, but that can 
be done later.


Comment at: src/config.h:46
@@ +45,3 @@
+# endif
+#endif
+

compnerd wrote:
> I really think that we should use `_POSIX_THREADS` macro rather than this 
> enumeration approach.
`_LIBCXXABI_USE_THREAD_API_` allows us to be consistent with naming of the 
different threading variants (e.g. I'm going to add 
`_LIBCXXABI_USE_THREAD_API_EXTENRAL` soon). Is there some functional benefit to 
using `_POSIX_THREADS` for the pthread variant?


Comment at: src/fallback_malloc.ipp:30
@@ -29,3 +29,3 @@
 #ifndef _LIBCXXABI_HAS_NO_THREADS
-static pthread_mutex_t heap_mutex = PTHREAD_MUTEX_INITIALIZER;
+static __libcxxabi_mutex_t heap_mutex = _LIBCXXABI_MUTEX_INITIALIZER;
 #else

Thanks for the catch.


https://reviews.llvm.org/D24864



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


Re: [PATCH] D24119: [libc++] add linker option "-Wl, -z, defs" in standalone build

2016-09-27 Thread Asiri Rathnayake via cfe-commits
rmaprath added inline comments.


Comment at: libcxx/trunk/CMakeLists.txt:329
@@ +328,3 @@
+  ${CMAKE_SYSTEM_NAME} MATCHES "OpenBSD") AND
+ NOT LLVM_USE_SANITIZER)
+set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -Wl,-z,defs")

zlei wrote:
> rmaprath wrote:
> > Perhaps we should exclude `LIBCXX_HAS_EXTERNAL_THREAD_API` as well? Because 
> > there we explicitly strip off these flags.
> I agree. Could you prepare a patch for it?
> 
> BTW, I really don't like duplicating code snippet from llvm. Is there any 
> better solution for that?
Sure, I'll do a patch.

Btw, I think this configuration is better placed in `HandleOutOfTreeLLVM.cmake` 
module.

I'll see if I can find a better way to do this.


Repository:
  rL LLVM

https://reviews.llvm.org/D24119



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


[PATCH] D24965: [clang-tidy] Fix cppcoreguidelines-pro-type-member-init false negatives

2016-09-27 Thread Malcolm Parsons via cfe-commits
malcolm.parsons created this revision.
malcolm.parsons added reviewers: alexfh, aaron.ballman, omtcyfz.
malcolm.parsons added subscribers: cfe-commits, mgehre.
Herald added a subscriber: nemanjai.

Handle classes with default constructors that are defaulted or are not
present in the AST.
Classes with virtual methods or virtual bases are not trivially
default constructible, so their members and bases need to be initialized.

https://reviews.llvm.org/D24965

Files:
  clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.cpp
  clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.h
  clang-tidy/utils/TypeTraits.cpp
  test/clang-tidy/cppcoreguidelines-pro-type-member-init.cpp

Index: test/clang-tidy/cppcoreguidelines-pro-type-member-init.cpp
===
--- test/clang-tidy/cppcoreguidelines-pro-type-member-init.cpp
+++ test/clang-tidy/cppcoreguidelines-pro-type-member-init.cpp
@@ -367,3 +367,25 @@
   PositiveIndirectMember() {}
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these fields: A
 };
+
+struct PositiveVirtualMethod {
+  // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: constructor does not initialize these fields: F
+  int F;
+  // CHECK-FIXES: int F{};
+  virtual int f() = 0;
+};
+
+struct PositiveVirtualDestructor {
+  // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: constructor does not initialize these fields: F
+  PositiveVirtualDestructor() = default;
+  int F;
+  // CHECK-FIXES: int F{};
+  virtual ~PositiveVirtualDestructor() {}
+};
+
+struct PositiveVirtualBase : public virtual NegativeAggregateType {
+  // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: constructor does not initialize these bases: NegativeAggregateType
+  // CHECK-MESSAGES: :[[@LINE-2]]:8: warning: constructor does not initialize these fields: F
+  int F;
+  // CHECK-FIXES: int F{};
+};
Index: clang-tidy/utils/TypeTraits.cpp
===
--- clang-tidy/utils/TypeTraits.cpp
+++ clang-tidy/utils/TypeTraits.cpp
@@ -58,6 +58,9 @@
   // constructible.
   if (ClassDecl->hasUserProvidedDefaultConstructor())
 return false;
+  // A polymorphic class is not trivially constructible
+  if (ClassDecl->isPolymorphic())
+return false;
   // A class is trivially constructible if it has a trivial default constructor.
   if (ClassDecl->hasTrivialDefaultConstructor())
 return true;
@@ -71,6 +74,8 @@
   for (const CXXBaseSpecifier &Base : ClassDecl->bases()) {
 if (!isTriviallyDefaultConstructible(Base.getType(), Context))
   return false;
+if (Base.isVirtual())
+  return false;
   }
 
   return true;
Index: clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.h
===
--- clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.h
+++ clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.h
@@ -46,11 +46,13 @@
   // To fix: Write a data member initializer, or mention it in the member
   // initializer list.
   void checkMissingMemberInitializer(ASTContext &Context,
+ const CXXRecordDecl *ClassDecl,
  const CXXConstructorDecl *Ctor);
 
   // A subtle side effect of Type.6 part 2:
   // Make sure to initialize trivially constructible base classes.
   void checkMissingBaseClassInitializer(const ASTContext &Context,
+const CXXRecordDecl *ClassDecl,
 const CXXConstructorDecl *Ctor);
 
   // Checks Type.6 part 2:
Index: clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.cpp
===
--- clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.cpp
+++ clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.cpp
@@ -269,6 +269,19 @@
IsNonTrivialDefaultConstructor))
   .bind("ctor"),
   this);
+
+  // Match classes with a default constructor that is defaulted or is not in the
+  // AST.
+  Finder->addMatcher(
+  cxxRecordDecl(
+  isDefinition(),
+  anyOf(has(cxxConstructorDecl(isDefaultConstructor(), isDefaulted(),
+   unless(isImplicit(,
+unless(has(cxxConstructorDecl(,
+  unless(isTriviallyDefaultConstructible()))
+  .bind("record"),
+  this);
+
   auto HasDefaultConstructor = hasInitializer(
   cxxConstructExpr(unless(requiresZeroInitialization()),
hasDeclaration(cxxConstructorDecl(
@@ -287,8 +300,13 @@
 // Skip declarations delayed by late template parsing without a body.
 if (!Ctor->getBody())
   return;
-checkMissingMemberInitializer(*Result.Context, Ctor);
-checkMissingBaseClassInitializer(*Result.Context, Ctor);
+checkMissingMemberInitializer(*Result.Context, Ctor->getParent(), Ctor);
+checkMissingBaseClassInitializer(*Result.Context, Ctor->getParent(),

Re: [PATCH] D24864: [libcxxabi] Refactor pthread usage into a separate API

2016-09-27 Thread Asiri Rathnayake via cfe-commits
rmaprath updated this revision to Diff 72653.
rmaprath added a comment.
Herald added subscribers: mgorny, beanz.

Address review comments from @compnerd and @EricWF.


https://reviews.llvm.org/D24864

Files:
  CMakeLists.txt
  src/config.h
  src/cxa_exception.cpp
  src/cxa_exception_storage.cpp
  src/cxa_guard.cpp
  src/fallback_malloc.ipp
  src/threading_support.h
  test/test_fallback_malloc.pass.cpp

Index: test/test_fallback_malloc.pass.cpp
===
--- test/test_fallback_malloc.pass.cpp
+++ test/test_fallback_malloc.pass.cpp
@@ -10,7 +10,7 @@
 #include 
 #include 
 
-#include 
+#include "../src/threading_support.h"
 
 typedef std::deque container;
 
Index: src/threading_support.h
===
--- /dev/null
+++ src/threading_support.h
@@ -0,0 +1,82 @@
+//=== threading_support.h -===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef _LIBCXXABI_THREADING_SUPPORT_H
+#define _LIBCXXABI_THREADING_SUPPORT_H
+
+#include "__cxxabi_config.h"
+#include "config.h"
+
+#ifndef _LIBCXXABI_HAS_NO_THREADS
+
+#if defined(_LIBCXXABI_USE_THREAD_API_PTHREAD)
+#include 
+
+#define _LIBCXXABI_THREAD_ABI_VISIBILITY inline _LIBCXXABI_INLINE_VISIBILITY
+
+// Mutex
+typedef pthread_mutex_t __libcxxabi_mutex_t;
+#define _LIBCXXABI_MUTEX_INITIALIZER PTHREAD_MUTEX_INITIALIZER
+
+_LIBCXXABI_THREAD_ABI_VISIBILITY
+int __libcxxabi_mutex_lock(__libcxxabi_mutex_t *mutex) {
+  return pthread_mutex_lock(mutex);
+}
+
+_LIBCXXABI_THREAD_ABI_VISIBILITY
+int __libcxxabi_mutex_unlock(__libcxxabi_mutex_t *mutex) {
+  return pthread_mutex_unlock(mutex);
+}
+
+// Condition variable
+typedef pthread_cond_t __libcxxabi_condvar_t;
+#define _LIBCXXABI_CONDVAR_INITIALIZER PTHREAD_COND_INITIALIZER
+
+_LIBCXXABI_THREAD_ABI_VISIBILITY
+int __libcxxabi_condvar_wait(__libcxxabi_condvar_t *cv,
+ __libcxxabi_mutex_t *mutex) {
+  return pthread_cond_wait(cv, mutex);
+}
+
+_LIBCXXABI_THREAD_ABI_VISIBILITY
+int __libcxxabi_condvar_broadcast(__libcxxabi_condvar_t *cv) {
+  return pthread_cond_broadcast(cv);
+}
+
+// Execute once
+typedef pthread_once_t __libcxxabi_exec_once_flag;
+#define _LIBCXXABI_EXEC_ONCE_INITIALIZER PTHREAD_ONCE_INIT
+
+_LIBCXXABI_THREAD_ABI_VISIBILITY
+int __libcxxabi_execute_once(__libcxxabi_exec_once_flag *flag,
+ void (*init_routine)(void)) {
+  return pthread_once(flag, init_routine);
+}
+
+// TLS
+typedef pthread_key_t __libcxxabi_tls_key;
+
+_LIBCXXABI_THREAD_ABI_VISIBILITY
+int __libcxxabi_tls_create(__libcxxabi_tls_key *key,
+   void (*destructor)(void *)) {
+  return pthread_key_create(key, destructor);
+}
+
+_LIBCXXABI_THREAD_ABI_VISIBILITY
+void *__libcxxabi_tls_get(__libcxxabi_tls_key key) {
+  return pthread_getspecific(key);
+}
+
+_LIBCXXABI_THREAD_ABI_VISIBILITY
+int __libcxxabi_tls_set(__libcxxabi_tls_key key, void *value) {
+  return pthread_setspecific(key, value);
+}
+#endif // _LIBCXXABI_USE_THREAD_API_PTHREAD
+#endif // !_LIBCXXABI_HAS_NO_THREADS
+#endif // _LIBCXXABI_THREADING_SUPPORT_H
Index: src/fallback_malloc.ipp
===
--- src/fallback_malloc.ipp
+++ src/fallback_malloc.ipp
@@ -27,25 +27,25 @@
 
 // When POSIX threads are not available, make the mutex operations a nop
 #ifndef _LIBCXXABI_HAS_NO_THREADS
-static pthread_mutex_t heap_mutex = PTHREAD_MUTEX_INITIALIZER;
+static __libcxxabi_mutex_t heap_mutex = _LIBCXXABI_MUTEX_INITIALIZER;
 #else
 static void * heap_mutex = 0;
 #endif
 
 class mutexor {
 public:
 #ifndef _LIBCXXABI_HAS_NO_THREADS
-mutexor ( pthread_mutex_t *m ) : mtx_(m) { pthread_mutex_lock ( mtx_ ); }
-~mutexor () { pthread_mutex_unlock ( mtx_ ); }
+mutexor ( __libcxxabi_mutex_t *m ) : mtx_(m) { __libcxxabi_mutex_lock ( mtx_ ); }
+~mutexor () { __libcxxabi_mutex_unlock ( mtx_ ); }
 #else
 mutexor ( void * ) {}
 ~mutexor () {}
 #endif
 private:
 mutexor ( const mutexor &rhs );
 mutexor & operator = ( const mutexor &rhs );
 #ifndef _LIBCXXABI_HAS_NO_THREADS
-pthread_mutex_t *mtx_;
+__libcxxabi_mutex_t *mtx_;
 #endif
 };
 
Index: src/cxa_guard.cpp
===
--- src/cxa_guard.cpp
+++ src/cxa_guard.cpp
@@ -11,20 +11,18 @@
 
 #include "abort_message.h"
 #include "config.h"
+#include "threading_support.h"
 
-#ifndef _LIBCXXABI_HAS_NO_THREADS
-#  include 
-#endif
 #include 
 
 /*
 This implementation must be careful to not call code external to this file
 which will turn around and try to call __cxa_guard_acquire reentrantly.
 For this reason, the headers of

Re: [PATCH] D14326: ASTImporter: expressions, pt.2

2016-09-27 Thread Aaron Ballman via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.

LGTM with two minor nits.



Comment at: lib/AST/ASTImporter.cpp:5563-5564
@@ +5562,4 @@
+const TemplateArgumentLoc *FromArgArray = E->getTemplateArgs();
+for (unsigned i = 0, e = E->getNumTemplateArgs(); i < e; i++) {
+  const TemplateArgumentLoc &FromLoc = FromArgArray[i];
+  bool Error = false;

Any particular reason not to use a range-based for loop over 
`template_arguments()`?


Comment at: lib/AST/ASTImporter.cpp:6283
@@ +6282,3 @@
+
+
+Expr *ASTNodeImporter::VisitCXXNewExpr(CXXNewExpr *CE) {

Spurious newline.


https://reviews.llvm.org/D14326



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


Re: [libcxx] r282483 - [cmake] Add linker option "-Wl, -z, defs" in standalone build

2016-09-27 Thread Joerg Sonnenberger via cfe-commits
On Tue, Sep 27, 2016 at 12:15:35PM -, Michal Gorny via cfe-commits wrote:
> Author: mgorny
> Date: Tue Sep 27 07:15:35 2016
> New Revision: 282483
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=282483&view=rev
> Log:
> [cmake] Add linker option "-Wl,-z,defs" in standalone build
> 
> Add the "-Wl,-z,defs" linker option that is used to prevent
> underlinking. It is already used by LLVM itself but does not get
> propagated into stand-alone build of libc++. This patch ensures
> that the option is passed in independently of whether libc++ is built
> in-tree or out-of-tree.

Can we turn this into a positive list on platforms where it is known to
work? While I generally find it useful, linker and (GCC) spec stupidity
can easily break it.

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


r282492 - Update to commit r282488, fix the buildboot failure.

2016-09-27 Thread Ayman Musa via cfe-commits
Author: aymanmus
Date: Tue Sep 27 10:37:31 2016
New Revision: 282492

URL: http://llvm.org/viewvc/llvm-project?rev=282492&view=rev
Log:
Update to commit r282488, fix the buildboot failure.

Modified:
cfe/trunk/lib/Headers/avx512fintrin.h

Modified: cfe/trunk/lib/Headers/avx512fintrin.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/avx512fintrin.h?rev=282492&r1=282491&r2=282492&view=diff
==
--- cfe/trunk/lib/Headers/avx512fintrin.h (original)
+++ cfe/trunk/lib/Headers/avx512fintrin.h Tue Sep 27 10:37:31 2016
@@ -9381,13 +9381,13 @@ _mm512_maskz_cvtps_pd (__mmask8 __U, __m
 }
 
 static __inline__ __m512 __DEFAULT_FN_ATTRS
-_mm512_cvtpslo_pd (__m512d __A)
+_mm512_cvtpslo_pd (__m512 __A)
 {
   return (__m512) _mm512_cvtps_pd(_mm512_castps512_ps256(__A));
 }
 
 static __inline__ __m512 __DEFAULT_FN_ATTRS
-_mm512_mask_cvtpslo_pd (__m512d __W, __mmask8 __U, __m512d __A)
+_mm512_mask_cvtpslo_pd (__m512d __W, __mmask8 __U, __m512 __A)
 {
   return (__m512) _mm512_mask_cvtps_pd(__W, __U, _mm512_castps512_ps256(__A));
 }


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


Re: [PATCH] D24800: Merge conflicting replacements when they are order-independent.

2016-09-27 Thread Manuel Klimek via cfe-commits
klimek added inline comments.


Comment at: lib/Tooling/Core/Replacement.cpp:179-181
@@ +178,5 @@
+llvm::Expected
+Replacements::mergeIfOrderIndependent(const Replacement &R) const {
+  Replacements Rs(R);
+  Replacements RsShiftedByReplaces(getReplacementInChangedCode(R));
+  Replacements ReplacesShiftedByRs;

I think this is a bit subtle and needs a lot more comments to guide me along 
what is happening and why ...


https://reviews.llvm.org/D24800



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


Re: [PATCH] D24800: Merge conflicting replacements when they are order-independent.

2016-09-27 Thread Eric Liu via cfe-commits
ioeric added inline comments.


Comment at: lib/Tooling/Core/Replacement.cpp:179-181
@@ +178,5 @@
+llvm::Expected
+Replacements::mergeIfOrderIndependent(const Replacement &R) const {
+  Replacements Rs(R);
+  Replacements RsShiftedByReplaces(getReplacementInChangedCode(R));
+  Replacements ReplacesShiftedByRs;

klimek wrote:
> I think this is a bit subtle and needs a lot more comments to guide me along 
> what is happening and why ...
Ahh, right! Should've done that...

Comments added.


https://reviews.llvm.org/D24800



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


Re: [PATCH] D24800: Merge conflicting replacements when they are order-independent.

2016-09-27 Thread Eric Liu via cfe-commits
ioeric updated this revision to Diff 72666.
ioeric marked 3 inline comments as done.
ioeric added a comment.

- Addressed review comments.


https://reviews.llvm.org/D24800

Files:
  include/clang/Tooling/Core/Replacement.h
  lib/Tooling/Core/Replacement.cpp
  unittests/Tooling/RefactoringTest.cpp

Index: unittests/Tooling/RefactoringTest.cpp
===
--- unittests/Tooling/RefactoringTest.cpp
+++ unittests/Tooling/RefactoringTest.cpp
@@ -101,18 +101,56 @@
 
 TEST_F(ReplacementTest, FailAddReplacements) {
   Replacements Replaces;
-  auto Err = Replaces.add(Replacement("x.cc", 0, 10, "3"));
+  Replacement Deletion("x.cc", 0, 10, "3");
+  auto Err = Replaces.add(Deletion);
   EXPECT_TRUE(!Err);
   llvm::consumeError(std::move(Err));
-  Err = Replaces.add(Replacement("x.cc", 0, 2, ""));
+  Err = Replaces.add(Replacement("x.cc", 0, 2, "a"));
   EXPECT_TRUE((bool)Err);
   llvm::consumeError(std::move(Err));
-  Err = Replaces.add(Replacement("x.cc", 2, 2, ""));
+  Err = Replaces.add(Replacement("x.cc", 2, 2, "a"));
   EXPECT_TRUE((bool)Err);
   llvm::consumeError(std::move(Err));
   Err = Replaces.add(Replacement("y.cc", 20, 2, ""));
   EXPECT_TRUE((bool)Err);
   llvm::consumeError(std::move(Err));
+  EXPECT_EQ(1u, Replaces.size());
+  EXPECT_EQ(Deletion, *Replaces.begin());
+}
+
+TEST_F(ReplacementTest, DeletionInReplacements) {
+  Replacements Replaces;
+  Replacement R("x.cc", 0, 10, "3");
+  auto Err = Replaces.add(R);
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+  Err = Replaces.add(Replacement("x.cc", 0, 2, ""));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+  Err = Replaces.add(Replacement("x.cc", 2, 2, ""));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+  EXPECT_EQ(1u, Replaces.size());
+  EXPECT_EQ(R, *Replaces.begin());
+}
+
+TEST_F(ReplacementTest, OverlappingReplacements) {
+  Replacements Replaces;
+  auto Err = Replaces.add(Replacement("x.cc", 0, 3, "345"));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+  Err = Replaces.add(Replacement("x.cc", 2, 3, "543"));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  EXPECT_EQ(1u, Replaces.size());
+  EXPECT_EQ(Replacement("x.cc", 0, 5, "34543"), *Replaces.begin());
+
+  Err = Replaces.add(Replacement("x.cc", 2, 1, "5"));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+  EXPECT_EQ(1u, Replaces.size());
+  EXPECT_EQ(Replacement("x.cc", 0, 5, "34543"), *Replaces.begin());
 }
 
 TEST_F(ReplacementTest, AddAdjacentInsertionAndReplacement) {
@@ -137,6 +175,116 @@
   EXPECT_EQ(Replaces.size(), 2u);
 }
 
+TEST_F(ReplacementTest, MergeNewDeletions) {
+  Replacements Replaces;
+  Replacement ContainingReplacement("x.cc", 0, 10, "");
+  auto Err = Replaces.add(ContainingReplacement);
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  Err = Replaces.add(Replacement("x.cc", 5, 3, ""));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  Err = Replaces.add(Replacement("x.cc", 0, 10, ""));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  Err = Replaces.add(Replacement("x.cc", 5, 5, ""));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  EXPECT_EQ(1u, Replaces.size());
+  EXPECT_EQ(*Replaces.begin(), ContainingReplacement);
+}
+
+TEST_F(ReplacementTest, MergeOverlappingButNotAdjacentReplacement) {
+  Replacements Replaces;
+  auto Err = Replaces.add(Replacement("x.cc", 0, 2, ""));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  Err = Replaces.add(Replacement("x.cc", 5, 5, ""));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  Replacement After = Replacement("x.cc", 10, 5, "");
+  Err = Replaces.add(After);
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  Replacement ContainingReplacement("x.cc", 0, 10, "");
+  Err = Replaces.add(ContainingReplacement);
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  EXPECT_EQ(2u, Replaces.size());
+  EXPECT_EQ(*Replaces.begin(), ContainingReplacement);
+  EXPECT_EQ(*(++Replaces.begin()), After);
+}
+
+TEST_F(ReplacementTest, InsertionBeforeMergedDeletions) {
+  Replacements Replaces;
+
+  Replacement Insertion("x.cc", 0, 0, "123");
+  auto Err = Replaces.add(Insertion);
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  Err = Replaces.add(Replacement("x.cc", 5, 5, ""));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  Replacement Deletion("x.cc", 0, 10, "");
+  Err = Replaces.add(Deletion);
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  EXPECT_EQ(2u, Replaces.size());
+  EXPECT_EQ(*Replaces.begin(), Insertion);
+  EXPECT_EQ(*(++Replaces.begin()), Deletion);
+}
+
+TEST_F(ReplacementTest, MergeOverlappingDeletions) {
+  Replacements Replaces;
+  auto Err = Replaces.add(Replacement("x.cc", 0, 2, ""));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  Err = Replaces.add(Replacement("x.cc", 0, 5, "

[PATCH] D24969: [Sema] Use the instantiated name of destructors in FindInstantiatedDecl and RebuildMemberExpr

2016-09-27 Thread Akira Hatanaka via cfe-commits
ahatanak created this revision.
ahatanak added reviewers: doug.gregor, rsmith.
ahatanak added a subscriber: cfe-commits.

This fixes PR30361.

clang was failing to compile the test case because it was passing "~C1" 
instead of "~C1" to FindInstantiatedDecl and RebuildMemberExpr.

https://reviews.llvm.org/D24969

Files:
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  lib/Sema/TreeTransform.h
  test/SemaCXX/destructor.cpp

Index: test/SemaCXX/destructor.cpp
===
--- test/SemaCXX/destructor.cpp
+++ test/SemaCXX/destructor.cpp
@@ -431,3 +431,21 @@
 
 // The constructor definition should not have errors
 Invalid::~Invalid() {}
+
+namespace PR30361 {
+template 
+struct C1 {
+  ~C1() {}
+  void foo1();
+};
+
+template
+void C1::foo1() {
+  C1::~C1();
+}
+
+void foo1() {
+  C1 x;
+  x.foo1();
+}
+}
Index: lib/Sema/TreeTransform.h
===
--- lib/Sema/TreeTransform.h
+++ lib/Sema/TreeTransform.h
@@ -2122,6 +2122,11 @@
NamedDecl *FirstQualifierInScope) {
 ExprResult BaseResult = getSema().PerformMemberExprBaseConversion(Base,
   isArrow);
+DeclarationNameInfo DNI = MemberNameInfo;
+
+if (isa(FoundDecl))
+  DNI = getDerived().TransformDeclarationNameInfo(MemberNameInfo);
+
 if (!Member->getDeclName()) {
   // We have a reference to an unnamed field.  This is always the
   // base of an anonymous struct/union member access, i.e. the
@@ -2139,7 +2144,7 @@
   Base = BaseResult.get();
   ExprValueKind VK = isArrow ? VK_LValue : Base->getValueKind();
   MemberExpr *ME = new (getSema().Context)
-  MemberExpr(Base, isArrow, OpLoc, Member, MemberNameInfo,
+  MemberExpr(Base, isArrow, OpLoc, Member, DNI,
  cast(Member)->getType(), VK, OK_Ordinary);
   return ME;
 }
@@ -2152,7 +2157,7 @@
 
 // FIXME: this involves duplicating earlier analysis in a lot of
 // cases; we should avoid this when possible.
-LookupResult R(getSema(), MemberNameInfo, Sema::LookupMemberName);
+LookupResult R(getSema(), DNI, Sema::LookupMemberName);
 R.addDecl(FoundDecl);
 R.resolveKind();
 
Index: lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -4845,7 +4845,11 @@
 
 NamedDecl *Result = nullptr;
 if (D->getDeclName()) {
-  DeclContext::lookup_result Found = ParentDC->lookup(D->getDeclName());
+  DeclarationName Name = D->getDeclName();
+  if (auto *DD = dyn_cast(D))
+Name =
+SubstDeclarationNameInfo(DD->getNameInfo(), 
TemplateArgs).getName();
+  DeclContext::lookup_result Found = ParentDC->lookup(Name);
   Result = findInstantiationOf(Context, D, Found.begin(), Found.end());
 } else {
   // Since we don't have a name for the entity we're looking for,


Index: test/SemaCXX/destructor.cpp
===
--- test/SemaCXX/destructor.cpp
+++ test/SemaCXX/destructor.cpp
@@ -431,3 +431,21 @@
 
 // The constructor definition should not have errors
 Invalid::~Invalid() {}
+
+namespace PR30361 {
+template 
+struct C1 {
+  ~C1() {}
+  void foo1();
+};
+
+template
+void C1::foo1() {
+  C1::~C1();
+}
+
+void foo1() {
+  C1 x;
+  x.foo1();
+}
+}
Index: lib/Sema/TreeTransform.h
===
--- lib/Sema/TreeTransform.h
+++ lib/Sema/TreeTransform.h
@@ -2122,6 +2122,11 @@
NamedDecl *FirstQualifierInScope) {
 ExprResult BaseResult = getSema().PerformMemberExprBaseConversion(Base,
   isArrow);
+DeclarationNameInfo DNI = MemberNameInfo;
+
+if (isa(FoundDecl))
+  DNI = getDerived().TransformDeclarationNameInfo(MemberNameInfo);
+
 if (!Member->getDeclName()) {
   // We have a reference to an unnamed field.  This is always the
   // base of an anonymous struct/union member access, i.e. the
@@ -2139,7 +2144,7 @@
   Base = BaseResult.get();
   ExprValueKind VK = isArrow ? VK_LValue : Base->getValueKind();
   MemberExpr *ME = new (getSema().Context)
-  MemberExpr(Base, isArrow, OpLoc, Member, MemberNameInfo,
+  MemberExpr(Base, isArrow, OpLoc, Member, DNI,
  cast(Member)->getType(), VK, OK_Ordinary);
   return ME;
 }
@@ -2152,7 +2157,7 @@
 
 // FIXME: this involves duplicating earlier analysis in a lot of
 // cases; we should avoid this when possible.
-LookupResult R(getSema(), MemberNameInfo, Sema::LookupMemberName);
+LookupResult R(getSema(), DNI, Sema::LookupMemberName);
 R.addDecl(FoundDecl);
 R.resolveKind();
 
Index: lib/Sema/SemaTem

r282500 - Adapt to LLVM optimization remark interface change. NFC

2016-09-27 Thread Adam Nemet via cfe-commits
Author: anemet
Date: Tue Sep 27 11:15:21 2016
New Revision: 282500

URL: http://llvm.org/viewvc/llvm-project?rev=282500&view=rev
Log:
Adapt to LLVM optimization remark interface change. NFC

Modified:
cfe/trunk/lib/CodeGen/CodeGenAction.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenAction.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenAction.cpp?rev=282500&r1=282499&r2=282500&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenAction.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenAction.cpp Tue Sep 27 11:15:21 2016
@@ -514,7 +514,7 @@ void BackendConsumer::EmitOptimizationMe
 
   std::string Msg;
   raw_string_ostream MsgStream(Msg);
-  MsgStream << D.getMsg().str();
+  MsgStream << D.getMsg();
 
   if (D.getHotness())
 MsgStream << " (hotness: " << *D.getHotness() << ")";


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


r282504 - Revert "Adapt to LLVM optimization remark interface change. NFC"

2016-09-27 Thread Adam Nemet via cfe-commits
Author: anemet
Date: Tue Sep 27 11:39:27 2016
New Revision: 282504

URL: http://llvm.org/viewvc/llvm-project?rev=282504&view=rev
Log:
Revert "Adapt to LLVM optimization remark interface change. NFC"

This reverts commit r282500.

Modified:
cfe/trunk/lib/CodeGen/CodeGenAction.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenAction.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenAction.cpp?rev=282504&r1=282503&r2=282504&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenAction.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenAction.cpp Tue Sep 27 11:39:27 2016
@@ -514,7 +514,7 @@ void BackendConsumer::EmitOptimizationMe
 
   std::string Msg;
   raw_string_ostream MsgStream(Msg);
-  MsgStream << D.getMsg();
+  MsgStream << D.getMsg().str();
 
   if (D.getHotness())
 MsgStream << " (hotness: " << *D.getHotness() << ")";


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


Re: [PATCH] D24752: [Modules] Add missing dependencies to clang builtins modulemap

2016-09-27 Thread Bruno Cardoso Lopes via cfe-commits
bruno added a subscriber: bruno.


Comment at: lib/Headers/module.modulemap:133
@@ -131,2 +132,3 @@
 explicit module aes {
+  export sse2
   header "__wmmintrin_aes.h"

The mmx case above makes sense to me, but I find conceptually odd that we need 
to re-export sse2 in aes module, why not explicitly #include  in 
the source file?


https://reviews.llvm.org/D24752



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


Re: [PATCH] D24861: [Sema] extend Wshift-op-parentheses so it warns for multiplicative operators

2016-09-27 Thread Bruno Cardoso Lopes via cfe-commits
bruno added a subscriber: bruno.
bruno added a comment.

Hi Daniel,

This is very nice.

In https://reviews.llvm.org/D24861#553606, @danielmarjamaki wrote:

> Compiling 2064 projects resulted in 904 warnings
>
> Here are the results:
>  https://drive.google.com/file/d/0BykPmWrCOxt2N04tYl8zVHA3MXc/view?usp=sharing
>
> The results looks acceptable imho. The code looks intentional in many cases 
> so I believe there are users that will disable this warning. Probably there 
> are true positives where the evaluation order is not really known. There were 
> many warnings about macro arguments where the macro bitshifts the argument - 
> these macros look very shaky to me.
>
> I saw some warnings about such code:
>
>   a * b << c
>   
>
> Maybe we should not warn about this. As far as I see, the result will be the 
> same if (a*b) or (b< signedness issues. What do you think? I'll keep these warnings for now.


Any idea on how expensive would be to reason about these false positives and 
avoid them?


Repository:
  rL LLVM

https://reviews.llvm.org/D24861



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


Re: [PATCH] D24886: Add [[clang::suppress(rule, ...)]] attribute

2016-09-27 Thread Matthias Gehre via cfe-commits
mgehre added a comment.

Thank your very much for your comments!
Let me try to give me reasoning for those points:

1. But it's missing some pieces, like test cases

I though about how to test this, having no semantic meaning itself.
I could look at the AST dump, but it does not even show the
rules that were passed, only that a "SuppressAttr" exists. Would that be enough?

2. Also, I suspect we will want this attribute to also be written on types

I was thinking about a case were that was useful, and didn't find any. 
Which of course doesn't mean that there is none. I will add this.

3. No new undocumented attributes, please.

I completely agree that it cannot be merged like this. This depends a bit
on how our discussion turns out: Will this be specific to C++ Core Guidelines, 
or
clang-tidy or both or none? Then, should the clang documentation mention 
clang-tidy?
(or does that violate layering?)

4. Should we diagnose if asked to suppress a diagnostic that we don't support?

I image that the users workflow would be like this: Run clang-tidy (e.g. by 
build server);
get a warning; add [[suppress]], run clang-tidy again; see that the warning is 
gone. I don't see a big
risk in not diagnosing a wrongly spelled suppression, because the user will 
notice right away
that the warning is not suppressed. There is not other implicit side-effect.
As an ad-don, diagnosing if the spelling is just slightly off seems like a 
bonus to me, but I hope
that this could be deferred to another patch.

5. I'd suggest asking the editors of the core guidelines what attribute 
namespace they'd like used.

I followed your advice and asked here:
https://github.com/isocpp/CppCoreGuidelines/issues/742
I will post updates to that issue here.

6. I believe this attribute should be used to silence diagnostics for more than 
just the C++ Core Guidelines,

so I don't think it makes sense to let them dictate what attribute namespace 
should be used.
Maybe I wanted to much here. There are two conflicting goals:

1. Suppress C++ Core Guidelines rules in a vendor-neutral way
2. Suppress specific clang(-tidy) warnings

I'm getting the feeling that we cannot have both in the same attribute.
For example, the C++ Core Guidelines say that the "No reinterpret_cast" rules 
shall be suppressed either by
saying "type" (also suppresses all other type related rules) or by saying 
"type.1" or by saying
"type1-dont-use-reinterpret_cast".
When we want to suppress other clang(-tidy) warnings, it would make sense from 
a usability point of view
to take the warning ids that clang(-tidy) outputs. For that particular C++ Core 
Guideline rule, it would be
"cppcoreguidelines-pro-type-reinterpret-cast".
So even if we had the same attribute name for both goals, the rule names would 
have to differ.

What are your opinions on this point? (Should I put this on the mailing list?)


https://reviews.llvm.org/D24886



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


Re: [PATCH] D24278: [analyzer] Extend bug reports with extra notes.

2016-09-27 Thread Anna Zaks via cfe-commits
zaks.anna accepted this revision.
zaks.anna added a comment.
This revision is now accepted and ready to land.

I have no further comments.


https://reviews.llvm.org/D24278



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


Re: [PATCH] D24848: [clang-tidy] fix false-positive for cppcoreguidelines-pro-type-member-init with in-class initializers

2016-09-27 Thread Matthias Gehre via cfe-commits
mgehre updated this revision to Diff 72677.
mgehre added a comment.

Rename the struct that was introduced in the test. Note that I need to keep the 
function Bug30487,
because that is where the false-positive warning was emitted.


https://reviews.llvm.org/D24848

Files:
  clang-tidy/utils/TypeTraits.cpp
  test/clang-tidy/cppcoreguidelines-pro-type-member-init.cpp

Index: test/clang-tidy/cppcoreguidelines-pro-type-member-init.cpp
===
--- test/clang-tidy/cppcoreguidelines-pro-type-member-init.cpp
+++ test/clang-tidy/cppcoreguidelines-pro-type-member-init.cpp
@@ -73,6 +73,11 @@
   NegativeInClassInitialized() {}
 };
 
+struct NegativeInClassInitializedDefaulted {
+  int F = 0;
+  NegativeInClassInitializedDefaulted() = default;
+};
+
 struct NegativeConstructorDelegated {
   int F;
 
@@ -367,3 +372,8 @@
   PositiveIndirectMember() {}
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize 
these fields: A
 };
+
+void Bug30487()
+{
+  NegativeInClassInitializedDefaulted s;
+}
Index: clang-tidy/utils/TypeTraits.cpp
===
--- clang-tidy/utils/TypeTraits.cpp
+++ clang-tidy/utils/TypeTraits.cpp
@@ -62,8 +62,10 @@
   if (ClassDecl->hasTrivialDefaultConstructor())
 return true;
 
-  // If all its fields are trivially constructible.
+  // If all its fields are trivially constructible and have no default 
initializers.
   for (const FieldDecl *Field : ClassDecl->fields()) {
+if (Field->hasInClassInitializer())
+  return false;
 if (!isTriviallyDefaultConstructible(Field->getType(), Context))
   return false;
   }


Index: test/clang-tidy/cppcoreguidelines-pro-type-member-init.cpp
===
--- test/clang-tidy/cppcoreguidelines-pro-type-member-init.cpp
+++ test/clang-tidy/cppcoreguidelines-pro-type-member-init.cpp
@@ -73,6 +73,11 @@
   NegativeInClassInitialized() {}
 };
 
+struct NegativeInClassInitializedDefaulted {
+  int F = 0;
+  NegativeInClassInitializedDefaulted() = default;
+};
+
 struct NegativeConstructorDelegated {
   int F;
 
@@ -367,3 +372,8 @@
   PositiveIndirectMember() {}
   // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these fields: A
 };
+
+void Bug30487()
+{
+  NegativeInClassInitializedDefaulted s;
+}
Index: clang-tidy/utils/TypeTraits.cpp
===
--- clang-tidy/utils/TypeTraits.cpp
+++ clang-tidy/utils/TypeTraits.cpp
@@ -62,8 +62,10 @@
   if (ClassDecl->hasTrivialDefaultConstructor())
 return true;
 
-  // If all its fields are trivially constructible.
+  // If all its fields are trivially constructible and have no default initializers.
   for (const FieldDecl *Field : ClassDecl->fields()) {
+if (Field->hasInClassInitializer())
+  return false;
 if (!isTriviallyDefaultConstructible(Field->getType(), Context))
   return false;
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D24848: [clang-tidy] fix false-positive for cppcoreguidelines-pro-type-member-init with in-class initializers

2016-09-27 Thread Aaron Ballman via cfe-commits
On Tue, Sep 27, 2016 at 2:05 PM, Matthias Gehre  wrote:
> mgehre updated this revision to Diff 72677.
> mgehre added a comment.
>
> Rename the struct that was introduced in the test. Note that I need to keep 
> the function Bug30487,
> because that is where the false-positive warning was emitted.

We usually use namespaces for this when working with C++ code, where
the namespace identifier is pr30487 (e.g.).

~Aaron

>
>
> https://reviews.llvm.org/D24848
>
> Files:
>   clang-tidy/utils/TypeTraits.cpp
>   test/clang-tidy/cppcoreguidelines-pro-type-member-init.cpp
>
> Index: test/clang-tidy/cppcoreguidelines-pro-type-member-init.cpp
> ===
> --- test/clang-tidy/cppcoreguidelines-pro-type-member-init.cpp
> +++ test/clang-tidy/cppcoreguidelines-pro-type-member-init.cpp
> @@ -73,6 +73,11 @@
>NegativeInClassInitialized() {}
>  };
>
> +struct NegativeInClassInitializedDefaulted {
> +  int F = 0;
> +  NegativeInClassInitializedDefaulted() = default;
> +};
> +
>  struct NegativeConstructorDelegated {
>int F;
>
> @@ -367,3 +372,8 @@
>PositiveIndirectMember() {}
>// CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not 
> initialize these fields: A
>  };
> +
> +void Bug30487()
> +{
> +  NegativeInClassInitializedDefaulted s;
> +}
> Index: clang-tidy/utils/TypeTraits.cpp
> ===
> --- clang-tidy/utils/TypeTraits.cpp
> +++ clang-tidy/utils/TypeTraits.cpp
> @@ -62,8 +62,10 @@
>if (ClassDecl->hasTrivialDefaultConstructor())
>  return true;
>
> -  // If all its fields are trivially constructible.
> +  // If all its fields are trivially constructible and have no default 
> initializers.
>for (const FieldDecl *Field : ClassDecl->fields()) {
> +if (Field->hasInClassInitializer())
> +  return false;
>  if (!isTriviallyDefaultConstructible(Field->getType(), Context))
>return false;
>}
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D23712: [OpenCL] Override supported OpenCL extensions with -cl-ext option

2016-09-27 Thread Anastasia Stulova via cfe-commits
Anastasia added inline comments.


Comment at: include/clang/Basic/OpenCLOptions.h:39
@@ +38,3 @@
+
+  void set(llvm::StringRef Ext, bool Enable = true) {
+assert(!Ext.empty() && "Extension is empty.");

yaxunl wrote:
> Better add a comments for this function about its semantics, i.e., if Ext 
> does not starts with +/-, it is enabled/disabled by \p Enable, otherwise +/- 
> overrides \p Enable, since this is not obvious.
Indeed, generally it would be nice to add a comment explaining the purpose of 
this functions. I don't think the name is descriptive enough.


Comment at: include/clang/Driver/Options.td:394
@@ -393,1 +393,3 @@
   HelpText<"OpenCL only. Specify that single precision floating-point divide 
and sqrt used in the program source are correctly rounded.">;
+def cl_ext_EQ : CommaJoined<["-"], "cl-ext=">, Group, 
Flags<[CC1Option]>,
+  HelpText<"OpenCL only. Enable or disable specific OpenCL extensions 
separated by comma. Use 'all' for all extensions.">;

I would see it as cc1 option instead to avoid confusions on its intension.


Comment at: include/clang/Driver/Options.td:395
@@ -394,1 +394,3 @@
+def cl_ext_EQ : CommaJoined<["-"], "cl-ext=">, Group, 
Flags<[CC1Option]>,
+  HelpText<"OpenCL only. Enable or disable specific OpenCL extensions 
separated by comma. Use 'all' for all extensions.">;
 def client__name : JoinedOrSeparate<["-"], "client_name">;

Could we also add a short statement, that +/- are used to turn the extesions on 
and off. 


Comment at: lib/Basic/Targets.cpp:1882
@@ -1881,1 +1881,3 @@
+
+setOpenCLExtensionOpts();
   }

Is this really target specific? I feel this should rather go into common code.


https://reviews.llvm.org/D23712



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


Re: [PATCH] D24886: Add [[clang::suppress(rule, ...)]] attribute

2016-09-27 Thread Aaron Ballman via cfe-commits
aaron.ballman added a comment.

In https://reviews.llvm.org/D24886#554130, @mgehre wrote:

> Thank your very much for your comments!
>  Let me try to give me reasoning for those points:
>
> 1. But it's missing some pieces, like test cases I though about how to test 
> this, having no semantic meaning itself. I could look at the AST dump, but it 
> does not even show the rules that were passed, only that a "SuppressAttr" 
> exists. Would that be enough?


That's a good start. Other tests that are required: the attribute appertains to 
the proper syntactic constructs and is diagnosed otherwise, attribute has the 
correct number and kind of arguments, the arguments are sane, etc.

> 2. Also, I suspect we will want this attribute to also be written on types I 
> was thinking about a case were that was useful, and didn't find any. Which of 
> course doesn't mean that there is none. I will add this.


If there are no use cases for it, then I guess we don't need to support it.

> 3. No new undocumented attributes, please. I completely agree that it cannot 
> be merged like this. This depends a bit on how our discussion turns out: Will 
> this be specific to C++ Core Guidelines, or clang-tidy or both or none? Then, 
> should the clang documentation mention clang-tidy? (or does that violate 
> layering?)


I agree, we want to make sure the docs reflect our intended design. I don't 
think it's a problem for the clang docs to mention clang-tidy. Certainly we 
have LLVM documentation that mentions clang.

> 4. Should we diagnose if asked to suppress a diagnostic that we don't 
> support? I image that the users workflow would be like this: Run clang-tidy 
> (e.g. by build server); get a warning; add [[suppress]], run clang-tidy 
> again; see that the warning is gone. I don't see a big risk in not diagnosing 
> a wrongly spelled suppression, because the user will notice right away that 
> the warning is not suppressed. There is not other implicit side-effect.


I think that's definitely a reasonable use case, but I don't think it's a 
compelling explanation of why we should not warn the user "I have no idea what 
you're talking about", either. The same could be said of many diagnostics we 
give -- the user will notice that their code doesn't work properly. However, I 
tend to be in the camp of "warn on suspicious activity" camp.

> As an ad-don, diagnosing if the spelling is just slightly off seems like a 
> bonus to me, but I hope

>  that this could be deferred to another patch.


Certainly!

> 5. I'd suggest asking the editors of the core guidelines what attribute 
> namespace they'd like used. I followed your advice and asked here: 
> https://github.com/isocpp/CppCoreGuidelines/issues/742 I will post updates to 
> that issue here.


Thanks!

> 6. I believe this attribute should be used to silence diagnostics for more 
> than just the C++ Core Guidelines, so I don't think it makes sense to let 
> them dictate what attribute namespace should be used. Maybe I wanted to much 
> here. There are two conflicting goals:

> 7. Suppress C++ Core Guidelines rules in a vendor-neutral way

> 8. Suppress specific clang(-tidy) warnings I'm getting the feeling that we 
> cannot have both in the same attribute.


I think we do our users a major disservice by not trying to do both with the 
same attribute. As a user, I do not want to have to remember which way to spell 
an attribute to silence warnings. This is especially important were we ever to 
allow triggering clang-tidy diagnostics through the clang frontend.

> For example, the C++ Core Guidelines say that the "No reinterpret_cast" rules 
> shall be suppressed either by

>  saying "type" (also suppresses all other type related rules) or by saying 
> "type.1" or by saying

>  "type1-dont-use-reinterpret_cast".

>  When we want to suppress other clang(-tidy) warnings, it would make sense 
> from a usability point of view

>  to take the warning ids that clang(-tidy) outputs. For that particular C++ 
> Core Guideline rule, it would be

>  "cppcoreguidelines-pro-type-reinterpret-cast".

>  So even if we had the same attribute name for both goals, the rule names 
> would have to differ.

> 

> What are your opinions on this point? (Should I put this on the mailing list?)


I guess I fail to see what the technical issue is (and perhaps I'm just 
obtuse), but I think that getting a wider audience is not a bad idea.


https://reviews.llvm.org/D24886



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


[PATCH] D24975: [CUDA] Add #pragma clang force_cuda_host_device_{begin, end} pragmas.

2016-09-27 Thread Justin Lebar via cfe-commits
jlebar created this revision.
jlebar added a reviewer: rsmith.
jlebar added subscribers: cfe-commits, jhen, tra.

These cause us to consider all functions in-between to be __host__
__device__.

You can nest these pragmas; you just can't have more 'end's than
'begin's.

https://reviews.llvm.org/D24975

Files:
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Parse/Parser.h
  clang/include/clang/Sema/Sema.h
  clang/lib/Parse/ParsePragma.cpp
  clang/lib/Sema/SemaCUDA.cpp
  clang/test/Parser/cuda-force-host-device.cu

Index: clang/test/Parser/cuda-force-host-device.cu
===
--- /dev/null
+++ clang/test/Parser/cuda-force-host-device.cu
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+// Check the force_cuda_host_device_{begin,end} pragmas.
+
+#pragma clang force_cuda_host_device_begin
+void f();
+#pragma clang force_cuda_host_device_begin
+void g();
+#pragma clang force_cuda_host_device_end
+void h();
+#pragma clang force_cuda_host_device_end
+
+void i(); // expected-note {{not viable}}
+
+void host() {
+  f();
+  g();
+  h();
+  i();
+}
+
+__attribute__((device)) void device() {
+  f();
+  g();
+  h();
+  i(); // expected-error {{no matching function}}
+}
Index: clang/lib/Sema/SemaCUDA.cpp
===
--- clang/lib/Sema/SemaCUDA.cpp
+++ clang/lib/Sema/SemaCUDA.cpp
@@ -23,6 +23,19 @@
 #include "llvm/ADT/SmallVector.h"
 using namespace clang;
 
+void Sema::PushForceCUDAHostDevice() {
+  assert(getLangOpts().CUDA && "May be called only for CUDA compilations.");
+  ForceCUDAHostDeviceDepth++;
+}
+
+bool Sema::PopForceCUDAHostDevice() {
+  assert(getLangOpts().CUDA && "May be called only for CUDA compilations.");
+  if (ForceCUDAHostDeviceDepth == 0)
+return false;
+  ForceCUDAHostDeviceDepth--;
+  return true;
+}
+
 ExprResult Sema::ActOnCUDAExecConfigExpr(Scope *S, SourceLocation oc,
  MultiExprArg ExecConfig,
  SourceLocation GGGLoc) {
@@ -441,9 +454,23 @@
 //  * a __device__ function with this signature was already declared, in which
 //case in which case we output an error, unless the __device__ decl is in a
 //system header, in which case we leave the constexpr function unattributed.
+//
+// In addition, all function decls are treated as __host__ __device__ when
+// ForceCUDAHostDeviceDepth > 0 (corresponding to code within a
+//   #pragma clang force_cuda_host_device_begin/end
+// pair).
 void Sema::maybeAddCUDAHostDeviceAttrs(Scope *S, FunctionDecl *NewD,
const LookupResult &Previous) {
   assert(getLangOpts().CUDA && "May be called only for CUDA compilations.");
+
+  if (ForceCUDAHostDeviceDepth > 0) {
+if (!NewD->hasAttr())
+  NewD->addAttr(CUDAHostAttr::CreateImplicit(Context));
+if (!NewD->hasAttr())
+  NewD->addAttr(CUDADeviceAttr::CreateImplicit(Context));
+return;
+  }
+
   if (!getLangOpts().CUDAHostDeviceConstexpr || !NewD->isConstexpr() ||
   NewD->isVariadic() || NewD->hasAttr() ||
   NewD->hasAttr() || NewD->hasAttr())
Index: clang/lib/Parse/ParsePragma.cpp
===
--- clang/lib/Parse/ParsePragma.cpp
+++ clang/lib/Parse/ParsePragma.cpp
@@ -167,6 +167,26 @@
 Token &FirstToken) override;
 };
 
+struct PragmaForceCUDAHostDeviceStartHandler : public PragmaHandler {
+  PragmaForceCUDAHostDeviceStartHandler(Sema &Actions)
+  : PragmaHandler("force_cuda_host_device_begin"), Actions(Actions) {}
+  void HandlePragma(Preprocessor &PP, PragmaIntroducerKind Introducer,
+Token &NameTok) override;
+
+private:
+  Sema &Actions;
+};
+
+struct PragmaForceCUDAHostDeviceEndHandler : public PragmaHandler {
+  PragmaForceCUDAHostDeviceEndHandler(Sema &Actions)
+  : PragmaHandler("force_cuda_host_device_end"), Actions(Actions) {}
+  void HandlePragma(Preprocessor &PP, PragmaIntroducerKind Introducer,
+Token &NameTok) override;
+
+private:
+  Sema &Actions;
+};
+
 }  // end namespace
 
 void Parser::initializePragmaHandlers() {
@@ -239,6 +259,15 @@
 PP.AddPragmaHandler(MSIntrinsic.get());
   }
 
+  if (getLangOpts().CUDA) {
+CUDAForceHostDeviceStartHandler.reset(
+new PragmaForceCUDAHostDeviceStartHandler(Actions));
+PP.AddPragmaHandler("clang", CUDAForceHostDeviceStartHandler.get());
+CUDAForceHostDeviceEndHandler.reset(
+new PragmaForceCUDAHostDeviceEndHandler(Actions));
+PP.AddPragmaHandler("clang", CUDAForceHostDeviceEndHandler.get());
+  }
+
   OptimizeHandler.reset(new PragmaOptimizeHandler(Actions));
   PP.AddPragmaHandler("clang", OptimizeHandler.get());
 
@@ -309,6 +338,13 @@
 MSIntrinsic.reset();
   }
 
+  if (getLangOpts().CUDA) {
+PP.RemovePragmaHandler("clang", CUDAForceHostDeviceStartHandler.get());
+CUDAForceHostDe

[PATCH] D24978: [CUDA] Rename cuda_builtin_vars.h to __clang_cuda_builtin_vars.h.

2016-09-27 Thread Justin Lebar via cfe-commits
jlebar created this revision.
jlebar added a reviewer: tra.
jlebar added a subscriber: cfe-commits.
Herald added subscribers: mgorny, beanz.

This matches the idiom we use for our other CUDA wrapper headers.

https://reviews.llvm.org/D24978

Files:
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Headers/CMakeLists.txt
  clang/lib/Headers/__clang_cuda_builtin_vars.h
  clang/lib/Headers/__clang_cuda_runtime_wrapper.h
  clang/lib/Headers/cuda_builtin_vars.h
  clang/test/CodeGenCUDA/cuda-builtin-vars.cu
  clang/test/SemaCUDA/cuda-builtin-vars.cu

Index: clang/test/SemaCUDA/cuda-builtin-vars.cu
===
--- clang/test/SemaCUDA/cuda-builtin-vars.cu
+++ clang/test/SemaCUDA/cuda-builtin-vars.cu
@@ -1,6 +1,6 @@
 // RUN: %clang_cc1 "-triple" "nvptx-nvidia-cuda" -fcuda-is-device -fsyntax-only -verify %s
 
-#include "cuda_builtin_vars.h"
+#include "__clang_cuda_builtin_vars.h"
 __attribute__((global))
 void kernel(int *out) {
   int i = 0;
@@ -34,20 +34,20 @@
 
   out[i++] = warpSize;
   warpSize = 0; // expected-error {{cannot assign to variable 'warpSize' with const-qualified type 'const int'}}
-  // expected-note@cuda_builtin_vars.h:* {{variable 'warpSize' declared const here}}
+  // expected-note@__clang_cuda_builtin_vars.h:* {{variable 'warpSize' declared const here}}
 
   // Make sure we can't construct or assign to the special variables.
   __cuda_builtin_threadIdx_t x; // expected-error {{calling a private constructor of class '__cuda_builtin_threadIdx_t'}}
-  // expected-note@cuda_builtin_vars.h:* {{declared private here}}
+  // expected-note@__clang_cuda_builtin_vars.h:* {{declared private here}}
 
   __cuda_builtin_threadIdx_t y = threadIdx; // expected-error {{calling a private constructor of class '__cuda_builtin_threadIdx_t'}}
-  // expected-note@cuda_builtin_vars.h:* {{declared private here}}
+  // expected-note@__clang_cuda_builtin_vars.h:* {{declared private here}}
 
   threadIdx = threadIdx; // expected-error {{'operator=' is a private member of '__cuda_builtin_threadIdx_t'}}
-  // expected-note@cuda_builtin_vars.h:* {{declared private here}}
+  // expected-note@__clang_cuda_builtin_vars.h:* {{declared private here}}
 
   void *ptr = &threadIdx; // expected-error {{'operator&' is a private member of '__cuda_builtin_threadIdx_t'}}
-  // expected-note@cuda_builtin_vars.h:* {{declared private here}}
+  // expected-note@__clang_cuda_builtin_vars.h:* {{declared private here}}
 
   // Following line should've caused an error as one is not allowed to
   // take address of a built-in variable in CUDA. Alas there's no way
Index: clang/test/CodeGenCUDA/cuda-builtin-vars.cu
===
--- clang/test/CodeGenCUDA/cuda-builtin-vars.cu
+++ clang/test/CodeGenCUDA/cuda-builtin-vars.cu
@@ -1,6 +1,6 @@
 // RUN: %clang_cc1 "-triple" "nvptx-nvidia-cuda" -emit-llvm -fcuda-is-device -o - %s | FileCheck %s
 
-#include "cuda_builtin_vars.h"
+#include "__clang_cuda_builtin_vars.h"
 
 // CHECK: define void @_Z6kernelPi(i32* %out)
 __attribute__((global))
Index: clang/lib/Headers/__clang_cuda_runtime_wrapper.h
===
--- clang/lib/Headers/__clang_cuda_runtime_wrapper.h
+++ clang/lib/Headers/__clang_cuda_runtime_wrapper.h
@@ -72,9 +72,9 @@
 #define __CUDA_ARCH__ 350
 #endif
 
-#include "cuda_builtin_vars.h"
+#include "__clang_cuda_builtin_vars.h"
 
-// No need for device_launch_parameters.h as cuda_builtin_vars.h above
+// No need for device_launch_parameters.h as __clang_cuda_builtin_vars.h above
 // has taken care of builtin variables declared in the file.
 #define __DEVICE_LAUNCH_PARAMETERS_H__
 
@@ -267,8 +267,8 @@
 }
 } // namespace std
 
-// Out-of-line implementations from cuda_builtin_vars.h.  These need to come
-// after we've pulled in the definition of uint3 and dim3.
+// Out-of-line implementations from __clang_cuda_builtin_vars.h.  These need to
+// come after we've pulled in the definition of uint3 and dim3.
 
 __device__ inline __cuda_builtin_threadIdx_t::operator uint3() const {
   uint3 ret;
@@ -299,10 +299,10 @@
 
 // curand_mtgp32_kernel helpfully redeclares blockDim and threadIdx in host
 // mode, giving them their "proper" types of dim3 and uint3.  This is
-// incompatible with the types we give in cuda_builtin_vars.h.  As as hack,
-// force-include the header (nvcc doesn't include it by default) but redefine
-// dim3 and uint3 to our builtin types.  (Thankfully dim3 and uint3 are only
-// used here for the redeclarations of blockDim and threadIdx.)
+// incompatible with the types we give in __clang_cuda_builtin_vars.h.  As as
+// hack, force-include the header (nvcc doesn't include it by default) but
+// redefine dim3 and uint3 to our builtin types.  (Thankfully dim3 and uint3 are
+// only used here for the redeclarations of blockDim and threadIdx.)
 #pragma push_macro("dim3")
 #pragma push_macro("uint3")
 #define dim3 __cuda

[PATCH] D24977: [CUDA] Declare our __device__ math functions in the same inline namespace as our standard library.

2016-09-27 Thread Justin Lebar via cfe-commits
jlebar created this revision.
jlebar added a reviewer: tra.
jlebar added subscribers: jhen, cfe-commits.

Currently we declare our inline __device__ math functions in namespace
std.  But libstdc++ and libc++ declare these functions in an inline
namespace inside namespace std.  We need to match this because, in a
later patch, we want to get e.g.  to use our device overloads,
and it only will if those overloads are in the right inline namespace.

https://reviews.llvm.org/D24977

Files:
  clang/lib/Headers/__clang_cuda_cmath.h
  clang/lib/Headers/__clang_cuda_math_forward_declares.h

Index: clang/lib/Headers/__clang_cuda_math_forward_declares.h
===
--- clang/lib/Headers/__clang_cuda_math_forward_declares.h
+++ clang/lib/Headers/__clang_cuda_math_forward_declares.h
@@ -185,7 +185,19 @@
 __DEVICE__ double trunc(double);
 __DEVICE__ float trunc(float);
 
+// We need to define these overloads in exactly the namespace our standard
+// library uses (including the right inline namespace), otherwise they won't be
+// picked up by other functions in the standard library (e.g. functions in
+// ).  Thus the ugliness below.
+#ifdef _LIBCPP_BEGIN_NAMESPACE_STD
+_LIBCPP_BEGIN_NAMESPACE_STD
+#else
 namespace std {
+#ifdef _GLIBCXX_BEGIN_NAMESPACE_VERSION
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
+#endif
+#endif
+
 using ::abs;
 using ::acos;
 using ::acosh;
@@ -259,7 +271,15 @@
 using ::tanh;
 using ::tgamma;
 using ::trunc;
+
+#ifdef _LIBCPP_END_NAMESPACE_STD
+_LIBCPP_END_NAMESPACE_STD
+#else
+#ifdef _GLIBCXX_BEGIN_NAMESPACE_VERSION
+_GLIBCXX_END_NAMESPACE_VERSION
+#endif
 } // namespace std
+#endif
 
 #pragma pop_macro("__DEVICE__")
 
Index: clang/lib/Headers/__clang_cuda_cmath.h
===
--- clang/lib/Headers/__clang_cuda_cmath.h
+++ clang/lib/Headers/__clang_cuda_cmath.h
@@ -316,7 +316,19 @@
   return std::scalbn((double)__x, __exp);
 }
 
+// We need to define these overloads in exactly the namespace our standard
+// library uses (including the right inline namespace), otherwise they won't be
+// picked up by other functions in the standard library (e.g. functions in
+// ).  Thus the ugliness below.
+#ifdef _LIBCPP_BEGIN_NAMESPACE_STD
+_LIBCPP_BEGIN_NAMESPACE_STD
+#else
 namespace std {
+#ifdef _GLIBCXX_BEGIN_NAMESPACE_VERSION
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
+#endif
+#endif
+
 // Pull the new overloads we defined above into namespace std.
 using ::acos;
 using ::acosh;
@@ -451,7 +463,15 @@
 using ::tanhf;
 using ::tgammaf;
 using ::truncf;
-}
+
+#ifdef _LIBCPP_END_NAMESPACE_STD
+_LIBCPP_END_NAMESPACE_STD
+#else
+#ifdef _GLIBCXX_BEGIN_NAMESPACE_VERSION
+_GLIBCXX_END_NAMESPACE_VERSION
+#endif
+} // namespace std
+#endif
 
 #undef __DEVICE__
 


Index: clang/lib/Headers/__clang_cuda_math_forward_declares.h
===
--- clang/lib/Headers/__clang_cuda_math_forward_declares.h
+++ clang/lib/Headers/__clang_cuda_math_forward_declares.h
@@ -185,7 +185,19 @@
 __DEVICE__ double trunc(double);
 __DEVICE__ float trunc(float);
 
+// We need to define these overloads in exactly the namespace our standard
+// library uses (including the right inline namespace), otherwise they won't be
+// picked up by other functions in the standard library (e.g. functions in
+// ).  Thus the ugliness below.
+#ifdef _LIBCPP_BEGIN_NAMESPACE_STD
+_LIBCPP_BEGIN_NAMESPACE_STD
+#else
 namespace std {
+#ifdef _GLIBCXX_BEGIN_NAMESPACE_VERSION
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
+#endif
+#endif
+
 using ::abs;
 using ::acos;
 using ::acosh;
@@ -259,7 +271,15 @@
 using ::tanh;
 using ::tgamma;
 using ::trunc;
+
+#ifdef _LIBCPP_END_NAMESPACE_STD
+_LIBCPP_END_NAMESPACE_STD
+#else
+#ifdef _GLIBCXX_BEGIN_NAMESPACE_VERSION
+_GLIBCXX_END_NAMESPACE_VERSION
+#endif
 } // namespace std
+#endif
 
 #pragma pop_macro("__DEVICE__")
 
Index: clang/lib/Headers/__clang_cuda_cmath.h
===
--- clang/lib/Headers/__clang_cuda_cmath.h
+++ clang/lib/Headers/__clang_cuda_cmath.h
@@ -316,7 +316,19 @@
   return std::scalbn((double)__x, __exp);
 }
 
+// We need to define these overloads in exactly the namespace our standard
+// library uses (including the right inline namespace), otherwise they won't be
+// picked up by other functions in the standard library (e.g. functions in
+// ).  Thus the ugliness below.
+#ifdef _LIBCPP_BEGIN_NAMESPACE_STD
+_LIBCPP_BEGIN_NAMESPACE_STD
+#else
 namespace std {
+#ifdef _GLIBCXX_BEGIN_NAMESPACE_VERSION
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
+#endif
+#endif
+
 // Pull the new overloads we defined above into namespace std.
 using ::acos;
 using ::acosh;
@@ -451,7 +463,15 @@
 using ::tanhf;
 using ::tgammaf;
 using ::truncf;
-}
+
+#ifdef _LIBCPP_END_NAMESPACE_STD
+_LIBCPP_END_NAMESPACE_STD
+#else
+#ifdef _GLIBCXX_BEGIN_NAMESPACE_VERSION
+_GLIBCXX_END_NAMESPACE_VERSION
+#endif
+} // namespace std
+#endif
 
 #undef __DEVICE__
 
_

Re: [PATCH] D24916: [analyzer] Extend bug reports with extra notes - CloneChecker

2016-09-27 Thread Anna Zaks via cfe-commits
zaks.anna added inline comments.


Comment at: test/Analysis/copypaste/functions.cpp:7
@@ -6,3 +6,3 @@
 
-int max(int a, int b) { // expected-warning{{Detected code clone.}}
+int max(int a, int b) { // expected-warning{{Clone of this code was detected}}
   log();

"was" -> "is"?
Do we use past or present elsewhere?


Comment at: test/Analysis/copypaste/suspicious-clones.cpp:61
@@ -60,3 +60,3 @@
   b /= a + b;
-  c -= b * a; // expected-warning{{suspicious code clone detected; did you 
mean to use 'a'?}}
+  c -= b * a; // expected-warning{{Suspicious code clone detected; did you 
mean to use 'a'?}}
   return c;

The error message seems too verbose and focused on the implementation rather 
than user (ex: "suspicious code clone" and "suggestion is based").

Maybe we could say something like this:

- Did you mean to use 'a'?
- Similar code snippet here




https://reviews.llvm.org/D24916



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


[PATCH] D24979: [CUDA] Support and std::min/max on the device.

2016-09-27 Thread Justin Lebar via cfe-commits
jlebar created this revision.
jlebar added a reviewer: tra.
jlebar added subscribers: cfe-commits, jhen.
Herald added subscribers: mgorny, beanz.

We do this by wrapping  and .

Tests are in the test-suite.   support to come separately.

https://reviews.llvm.org/D24979

Files:
  clang/lib/Driver/ToolChains.cpp
  clang/lib/Headers/CMakeLists.txt
  clang/lib/Headers/__clang_cuda_complex_builtins.h
  clang/lib/Headers/__clang_cuda_runtime_wrapper.h
  clang/lib/Headers/cuda_wrappers/algorithm
  clang/lib/Headers/cuda_wrappers/complex

Index: clang/lib/Headers/cuda_wrappers/complex
===
--- /dev/null
+++ clang/lib/Headers/cuda_wrappers/complex
@@ -0,0 +1,79 @@
+/*=== complex - CUDA wrapper for  --===
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ *
+ *===---===
+ */
+
+#pragma once
+
+// Wrapper around  that forces its functions to be __host__
+// __device__.
+
+// First, include host-only headers we think are likely to be included by
+// , so that the pragma below only applies to  itself.
+#if __cplusplus >= 201103L
+#include 
+#endif
+#include 
+#include 
+#include 
+
+// Next, include our  wrapper, to ensure that device overloads of
+// std::min/max are available.
+#include 
+
+#pragma clang force_cuda_host_device_begin
+
+// When compiling for device, ask libstdc++ to use its own implements of
+// complex functions, rather than calling builtins (which resolve to library
+// functions that don't exist when compiling CUDA device code).
+//
+// This is a little dicey, because it causes libstdc++ to define a different
+// set of overloads on host and device.
+//
+//   // Present only when compiling for host.
+//   __host__ __device__ void complex sin(const complex& x) {
+// return __builtin_csinf(x);
+//   }
+//
+//   // Present when compiling for host and for device.
+//   template 
+//   void __host__ __device__ complex sin(const complex& x) {
+// return complex(sin(x.real()) * cosh(x.imag()),
+//   cos(x.real()), sinh(x.imag()));
+//   }
+//
+// This is safe because when compiling for device, all function calls in
+// __host__ code to sin() will still resolve to *something*, even if they don't
+// resolve to the same function as they resolve to when compiling for host.  We
+// don't care that they don't resolve to the right function because we won't
+// codegen this host code when compiling for device.
+
+#pragma push_macro("_GLIBCXX_USE_C99_COMPLEX")
+#pragma push_macro("_GLIBCXX_USE_C99_COMPLEX_TR1")
+#define _GLIBCXX_USE_C99_COMPLEX 0
+#define _GLIBCXX_USE_C99_COMPLEX_TR1 0
+
+#include_next 
+
+#pragma pop_macro("_GLIBCXX_USE_C99_COMPLEX_TR1")
+#pragma pop_macro("_GLIBCXX_USE_C99_COMPLEX")
+
+#pragma clang force_cuda_host_device_end
Index: clang/lib/Headers/cuda_wrappers/algorithm
===
--- /dev/null
+++ clang/lib/Headers/cuda_wrappers/algorithm
@@ -0,0 +1,96 @@
+/*=== complex - CUDA wrapper for  ===
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEM

Re: [PATCH] D24119: [libc++] add linker option "-Wl, -z, defs" in standalone build

2016-09-27 Thread Michał Górny via cfe-commits
mgorny reopened this revision.
mgorny added a comment.
This revision is now accepted and ready to land.

I'm starting to regret that I've committed this. It breaks horribly any 
pure-LLVM build, i.e. without linking to libgcc_s. It seems that the build 
system is completely unprepared to link to compiler-rt or libunwind when 
linking the shared library, and with -DLIBCXX_HAS_GCC_S_LIB=OFF, it fails due 
to a lot of missing symbols. I am going to revert this until we get the build 
system working completely.


Repository:
  rL LLVM

https://reviews.llvm.org/D24119



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


[libcxx] r282524 - Revert r282483 - [cmake] Add linker option "-Wl, -z, defs" in standalone build

2016-09-27 Thread Michal Gorny via cfe-commits
Author: mgorny
Date: Tue Sep 27 13:54:02 2016
New Revision: 282524

URL: http://llvm.org/viewvc/llvm-project?rev=282524&view=rev
Log:
Revert r282483 - [cmake] Add linker option "-Wl,-z,defs" in standalone build

Revert r282483 as it causes build failures due to missing symbols when
not linking to -lgcc_s (i.e. doing pure LLVM stack build). The patch can
be reintroduced when the build system is fixed to add all needed
libraries (libunwind, compiler-rt).

Modified:
libcxx/trunk/CMakeLists.txt

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=282524&r1=282523&r2=282524&view=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Tue Sep 27 13:54:02 2016
@@ -319,18 +319,6 @@ remove_flags(-stdlib=libc++ -stdlib=libs
 # so they don't get transformed into -Wno and -errors respectivly.
 remove_flags(-Wno-pedantic -pedantic-errors -pedantic)
 
-# FIXME: this is cribbed from HandleLLVMOptions.cmake.
-if(LIBCXX_STANDALONE_BUILD)
-  # Pass -Wl,-z,defs. This makes sure all symbols are defined. Otherwise a DSO
-  # build might work on ELF but fail on MachO/COFF.
-  if(NOT (${CMAKE_SYSTEM_NAME} MATCHES "Darwin" OR WIN32 OR CYGWIN OR
-  ${CMAKE_SYSTEM_NAME} MATCHES "FreeBSD" OR
-  ${CMAKE_SYSTEM_NAME} MATCHES "OpenBSD") AND
- NOT LLVM_USE_SANITIZER)
-set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -Wl,-z,defs")
-  endif()
-endif()
-
 # Required flags ==
 set(LIBCXX_STANDARD_VER c++11 CACHE INTERNAL "internal option to change build 
dialect")
 add_compile_flags_if_supported(-std=${LIBCXX_STANDARD_VER})


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


Re: [PATCH] D24886: Add [[clang::suppress(rule, ...)]] attribute

2016-09-27 Thread Malcolm Parsons via cfe-commits
malcolm.parsons added a subscriber: malcolm.parsons.
malcolm.parsons added a comment.

In https://reviews.llvm.org/D24886#554130, @mgehre wrote:

> 2. Also, I suspect we will want this attribute to also be written on types I 
> was thinking about a case were that was useful, and didn't find any. Which of 
> course doesn't mean that there is none. I will add this.


I would like to suppress cppcoreguidelines-pro-type-union-access for all member 
functions of a class.
It might be useful to suppress cppcoreguidelines-pro-type-member-init for all 
constructors of a class.


https://reviews.llvm.org/D24886



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


Re: [PATCH] D24119: [libc++] add linker option "-Wl, -z, defs" in standalone build

2016-09-27 Thread Asiri Rathnayake via cfe-commits
rmaprath added a comment.

In https://reviews.llvm.org/D24119#554234, @mgorny wrote:

> I'm starting to regret that I've committed this. It breaks horribly any 
> pure-LLVM build, i.e. without linking to libgcc_s. It seems that the build 
> system is completely unprepared to link to compiler-rt or libunwind when 
> linking the shared library, and with -DLIBCXX_HAS_GCC_S_LIB=OFF, it fails due 
> to a lot of missing symbols. I am going to revert this until we get the build 
> system working completely.


Doesn't `-DLIBCXXABI_USE_LLVM_UNWINDER=ON` make it possible to build without 
`libgcc_s`? Or is this something else?


Repository:
  rL LLVM

https://reviews.llvm.org/D24119



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


Re: [PATCH] D24848: [clang-tidy] fix false-positive for cppcoreguidelines-pro-type-member-init with in-class initializers

2016-09-27 Thread Malcolm Parsons via cfe-commits
malcolm.parsons added a comment.

In https://reviews.llvm.org/D24848#554145, @mgehre wrote:

> Rename the struct that was introduced in the test. Note that I need to keep 
> the function Bug30487,
>  because that is where the false-positive warning was emitted.


https://reviews.llvm.org/D24965 will allow you to write a positive test instead:

  struct PositivePartiallyInClassInitialized {
// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: constructor does not initialize 
these fields: G
int F = 0;
int G;
// CHECK-FIXES: int G{};
  };


https://reviews.llvm.org/D24848



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


Re: [PATCH] D24914: [clang-rename] Do not print out error message upon encountering multiple replacements in the same SourceLocation.

2016-09-27 Thread Alexander Shaposhnikov via cfe-commits
alexshap added inline comments.


Comment at: clang-rename/RenamingAction.cpp:74
@@ +73,3 @@
+  // FIXME: An error might happen here if USRLocFinder finds the symbol
+  // twice or if the symbol happens to be in a header included multiple
+  // times independently. Such error doesn't mean clang-rename failure and

My concerns were about wording, the new version looks good to me.
I think the long-term fix would be to improve the interface of the class 
Replacements,
but it's clearly not in the scope of this patch (the other tools have the same 
issue), 
so to me your diff is OK.


https://reviews.llvm.org/D24914



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


Re: [PATCH] D24914: [clang-rename] Do not print out error message upon encountering multiple replacements in the same SourceLocation.

2016-09-27 Thread Kirill Bobyrev via cfe-commits
omtcyfz added inline comments.


Comment at: clang-rename/RenamingAction.cpp:74
@@ +73,3 @@
+  // FIXME: An error might happen here if USRLocFinder finds the symbol
+  // twice or if the symbol happens to be in a header included multiple
+  // times independently. Such error doesn't mean clang-rename failure and

alexshap wrote:
> My concerns were about wording, the new version looks good to me.
> I think the long-term fix would be to improve the interface of the class 
> Replacements,
> but it's clearly not in the scope of this patch (the other tools have the 
> same issue), 
> so to me your diff is OK.
Eric actually has a patch for that: https://reviews.llvm.org/D24800


https://reviews.llvm.org/D24914



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


Re: [PATCH] D24975: [CUDA] Add #pragma clang force_cuda_host_device_{begin, end} pragmas.

2016-09-27 Thread Artem Belevich via cfe-commits
tra added a comment.

LGTM. Should we add new pragma description to docs/LanguageExtensions.rst ?


https://reviews.llvm.org/D24975



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


r282533 - Adapt to LLVM EnableStatistics() change.

2016-09-27 Thread Matthias Braun via cfe-commits
Author: matze
Date: Tue Sep 27 14:38:59 2016
New Revision: 282533

URL: http://llvm.org/viewvc/llvm-project?rev=282533&view=rev
Log:
Adapt to LLVM EnableStatistics() change.

Modified:
cfe/trunk/lib/Frontend/CompilerInstance.cpp
cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp

Modified: cfe/trunk/lib/Frontend/CompilerInstance.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInstance.cpp?rev=282533&r1=282532&r2=282533&view=diff
==
--- cfe/trunk/lib/Frontend/CompilerInstance.cpp (original)
+++ cfe/trunk/lib/Frontend/CompilerInstance.cpp Tue Sep 27 14:38:59 2016
@@ -859,7 +859,7 @@ bool CompilerInstance::ExecuteAction(Fro
 createFrontendTimer();
 
   if (getFrontendOpts().ShowStats || !getFrontendOpts().StatsFile.empty())
-llvm::EnableStatistics();
+llvm::EnableStatistics(false);
 
   for (const FrontendInputFile &FIF : getFrontendOpts().Inputs) {
 // Reset the ID tables if we are reusing the SourceManager and parsing

Modified: cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp?rev=282533&r1=282532&r2=282533&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp Tue Sep 27 
14:38:59 2016
@@ -188,7 +188,7 @@ public:
 Injector(injector) {
 DigestAnalyzerOptions();
 if (Opts->PrintStats) {
-  llvm::EnableStatistics();
+  llvm::EnableStatistics(false);
   TUTotalTimer = new llvm::Timer("Analyzer Total Time");
 }
   }


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


Re: [PATCH] D24119: [libc++] add linker option "-Wl, -z, defs" in standalone build

2016-09-27 Thread Michał Górny via cfe-commits
mgorny added a comment.

In https://reviews.llvm.org/D24119#554251, @rmaprath wrote:

> Doesn't `-DLIBCXXABI_USE_LLVM_UNWINDER=ON` make it possible to build without 
> `libgcc_s`? Or is this something else?


It's supposed to but it doesn't add the necessary libraries when linking 
libc++.so.


Repository:
  rL LLVM

https://reviews.llvm.org/D24119



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


[PATCH] D24981: [Coverage] The coverage region for a switch should cover the code after the switch

2016-09-27 Thread Alex Lorenz via cfe-commits
arphaman created this revision.
arphaman added a reviewer: vsk.
arphaman added a subscriber: cfe-commits.
arphaman set the repository for this revision to rL LLVM.

This patch fixes a regression introduced in r262697 that changed the way the 
coverage regions for switch are constructed. The PGO instrumentation counter 
for switch statements refers to a counter at the exit of the switch, and thus 
the coverage region for the switch statement should cover the code that comes 
after the switch, and not the switch statement itself.

This patch should fix the issue exposed by the new coverage bot where the 
switches with all cases returning get zero coverage:  
http://lab.llvm.org:8080/coverage/coverage-reports/clang/coverage/Users/buildslave/jenkins/sharedspace/clang-stage2-coverage-R@2/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp.html#L520.

Repository:
  rL LLVM

https://reviews.llvm.org/D24981

Files:
  lib/CodeGen/CoverageMappingGen.cpp
  test/CoverageMapping/switch.c
  test/CoverageMapping/switchmacro.c

Index: test/CoverageMapping/switchmacro.c
===
--- test/CoverageMapping/switchmacro.c
+++ test/CoverageMapping/switchmacro.c
@@ -4,7 +4,7 @@
 
 // CHECK: foo
 int foo(int i) { // CHECK-NEXT: File 0, [[@LINE]]:16 -> {{[0-9]+}}:2 = #0
-  switch (i) {   // CHECK-NEXT: File 0, [[@LINE]]:3 -> {{[0-9]+}}:4 = #1
+  switch (i) {
   default:   // CHECK-NEXT: File 0, [[@LINE]]:3 -> {{[0-9]+}}:11 = #2
 if (i == 1)  // CHECK-NEXT: File 0, [[@LINE]]:9 -> [[@LINE]]:15 = #2
   return 0;  // CHECK-NEXT: File 0, [[@LINE]]:7 -> [[@LINE]]:15 = #3
Index: test/CoverageMapping/switch.c
===
--- test/CoverageMapping/switch.c
+++ test/CoverageMapping/switch.c
@@ -1,44 +1,44 @@
 // RUN: %clang_cc1 -fprofile-instrument=clang -fcoverage-mapping -dump-coverage-mapping -emit-llvm-only -main-file-name switch.c %s | FileCheck %s
 // CHECK: foo
 void foo(int i) {   // CHECK-NEXT: File 0, [[@LINE]]:17 -> [[@LINE+8]]:2 = #0
-  switch(i) {   // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+5]]:4 = #1
+  switch(i) {
   case 1:   // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+3]]:10 = #2
 return;
   case 2:   // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+1]]:10 = #3
 break;
   }
-  int x = 0;
+  int x = 0;// CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+1]]:2 = #1
 }
 
 void nop() {}
 
 // CHECK: bar
 void bar(int i) {   // CHECK-NEXT: File 0, [[@LINE]]:17 -> [[@LINE+20]]:2 = #0
-  switch (i)// CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+1]]:6 = #1
+  switch (i)
 ;   // CHECK-NEXT: File 0, [[@LINE]]:5 -> [[@LINE]]:6 = 0
 
-  switch (i) {  // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+1]]:4 = #2
+  switch (i) {  // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+16]]:2 = #1
   }
 
-  switch (i)// CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+1]]:10 = #3
+  switch (i)// CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+13]]:2 = #2
 nop();  // CHECK-NEXT: File 0, [[@LINE]]:5 -> [[@LINE]]:10 = 0
 
-  switch (i)// CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+2]]:10 = #4
+  switch (i)// CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+10]]:2 = #3
   case 1:   // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+1]]:10 = #5
 nop();
 
-  switch (i) {  // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+4]]:4 = #6
+  switch (i) {  // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+6]]:2 = #4
 nop();  // CHECK-NEXT: File 0, [[@LINE]]:5 -> [[@LINE+2]]:10 = 0
   case 1:   // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+1]]:10 = #7
 nop();
   }
-  nop();
+  nop();// CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+1]]:2 = #6
 }
 
 // CHECK-NEXT: main
 int main() {// CHECK-NEXT: File 0, [[@LINE]]:12 -> [[@LINE+34]]:2 = #0
   int i = 0;
-  switch(i) {   // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+9]]:4 = #1
+  switch(i) {
   case 0:   // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+7]]:10 = #2
 i = 1;
 break;
@@ -48,7 +48,7 @@
   default:  // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+1]]:10 = #4
 break;
   }
-  switch(i) {   // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+8]]:4 = #5
+  switch(i) {   // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+22]]:2 = #1
   case 0:   // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+6]]:10 = #6
 i = 1;
 break;
@@ -58,16 +58,16 @@
 break;
   }
 
-  switch(i) {   // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+7]]:4 = #9
+  switch(i) {   // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+12]]:2 = #5
   case 1:   // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+5]]:11 = #10
   case 2:   // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+4]]:11 = (#10 + #11)
 i = 11;
   case 3:   // CHECK-NEXT: File 0, [[@LINE]]:3 -> [[@LINE+2]]:11 = ((#10 + 

Re: [PATCH] D24977: [CUDA] Declare our __device__ math functions in the same inline namespace as our standard library.

2016-09-27 Thread Artem Belevich via cfe-commits
tra accepted this revision.
tra added a comment.
This revision is now accepted and ready to land.

That is way too much knowledge about details of standard library implementation.
If it changes, I suspect users will end up with a rather uninformative error.
Is there a way to produce somewhat more sensible error if/when our assumptions 
about namespaces are violated?
We could whitelist libc++/libstdc++ version we've tested with and produce 
#warning "Unsupported standard library version" if we see something else.


https://reviews.llvm.org/D24977



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


[PATCH] D24984: [libunwind] Add support for a single-threaded libunwind build

2016-09-27 Thread Asiri Rathnayake via cfe-commits
rmaprath created this revision.
rmaprath added reviewers: jroelofs, compnerd, logan.
rmaprath added a subscriber: cfe-commits.
Herald added subscribers: mgorny, beanz.

The EHABI unwinder is thread-agnostic, SJLJ unwinder and the DWARF unwinder 
have a couple of `pthread` dependencies.

This patch makes it possible to build the whole of `libunwind` for a 
single-threaded environment.

https://reviews.llvm.org/D24984

Files:
  CMakeLists.txt
  src/CMakeLists.txt
  src/UnwindCursor.hpp
  src/Unwind_AppleExtras.cpp
  src/config.h

Index: src/config.h
===
--- src/config.h
+++ src/config.h
@@ -85,13 +85,20 @@
   } while (0)
 #define _LIBUNWIND_LOG(msg, ...) fprintf(stderr, "libunwind: " msg "\n", __VA_ARGS__)
 
+#if defined(_LIBUNWIND_HAS_NO_THREADS)
+  // only used with pthread calls, not needed for the single-threaded builds
+  #define _LIBUNWIND_LOG_NON_ZERO(x)
+#endif
+
 // Macros that define away in non-Debug builds
 #ifdef NDEBUG
   #define _LIBUNWIND_DEBUG_LOG(msg, ...)
   #define _LIBUNWIND_TRACE_API(msg, ...)
   #define _LIBUNWIND_TRACING_UNWINDING 0
   #define _LIBUNWIND_TRACE_UNWINDING(msg, ...)
-  #define _LIBUNWIND_LOG_NON_ZERO(x) x
+  #ifndef _LIBUNWIND_LOG_NON_ZERO
+#define _LIBUNWIND_LOG_NON_ZERO(x) x
+  #endif
 #else
   #ifdef __cplusplus
 extern "C" {
@@ -102,12 +109,14 @@
 }
   #endif
   #define _LIBUNWIND_DEBUG_LOG(msg, ...)  _LIBUNWIND_LOG(msg, __VA_ARGS__)
-  #define _LIBUNWIND_LOG_NON_ZERO(x) \
-do { \
-  int _err = x; \
-  if ( _err != 0 ) \
-_LIBUNWIND_LOG("" #x "=%d in %s", _err, __FUNCTION__); \
- } while (0)
+  #ifndef _LIBUNWIND_LOG_NON_ZERO
+#define _LIBUNWIND_LOG_NON_ZERO(x) \
+  do { \
+int _err = x; \
+if ( _err != 0 ) \
+  _LIBUNWIND_LOG("" #x "=%d in %s", _err, __FUNCTION__); \
+   } while (0)
+  #endif
   #define _LIBUNWIND_TRACE_API(msg, ...) \
 do { \
   if ( logAPIs() ) _LIBUNWIND_LOG(msg, __VA_ARGS__); \
Index: src/Unwind_AppleExtras.cpp
===
--- src/Unwind_AppleExtras.cpp
+++ src/Unwind_AppleExtras.cpp
@@ -185,21 +185,29 @@
 
 #if !defined(FOR_DYLD) && _LIBUNWIND_BUILD_SJLJ_APIS
 
-#include 
+#ifndef _LIBUNWIND_HAS_NO_THREADS
+  #include 
+#else
+  _Unwind_FunctionContext *fc_ = nullptr;
+#endif
 
 // Accessors to get get/set linked list of frames for sjlj based execeptions.
 _LIBUNWIND_HIDDEN
 struct _Unwind_FunctionContext *__Unwind_SjLj_GetTopOfFunctionStack() {
+#ifndef _LIBUNWIND_HAS_NO_THREADS
   return (struct _Unwind_FunctionContext *)
 _pthread_getspecific_direct(__PTK_LIBC_DYLD_Unwind_SjLj_Key);
+#else
+  return fc_;
+#endif
 }
 
 _LIBUNWIND_HIDDEN
 void __Unwind_SjLj_SetTopOfFunctionStack(struct _Unwind_FunctionContext *fc) {
+#ifndef _LIBUNWIND_HAS_NO_THREADS
   _pthread_setspecific_direct(__PTK_LIBC_DYLD_Unwind_SjLj_Key, fc);
+#else
+  fc_ = fc;
+#endif
 }
 #endif
-
-
-
-
Index: src/UnwindCursor.hpp
===
--- src/UnwindCursor.hpp
+++ src/UnwindCursor.hpp
@@ -16,7 +16,9 @@
 #include 
 #include 
 #include 
-#include 
+#ifndef _LIBUNWIND_HAS_NO_THREADS
+  #include 
+#endif
 #include 
 
 #ifdef __APPLE__
@@ -60,7 +62,9 @@
 
   // These fields are all static to avoid needing an initializer.
   // There is only one instance of this class per process.
+#ifndef _LIBUNWIND_HAS_NO_THREADS
   static pthread_rwlock_t _lock;
+#endif
 #ifdef __APPLE__
   static void dyldUnloadHook(const struct mach_header *mh, intptr_t slide);
   static bool _registeredForDyldUnloads;
@@ -87,8 +91,10 @@
 template 
 typename DwarfFDECache::entry DwarfFDECache::_initialBuffer[64];
 
+#ifndef _LIBUNWIND_HAS_NO_THREADS
 template 
 pthread_rwlock_t DwarfFDECache::_lock = PTHREAD_RWLOCK_INITIALIZER;
+#endif
 
 #ifdef __APPLE__
 template 
Index: src/CMakeLists.txt
===
--- src/CMakeLists.txt
+++ src/CMakeLists.txt
@@ -53,7 +53,9 @@
 set(libraries ${LIBUNWINDCXX_ABI_LIBRARIES})
 append_if(libraries LIBUNWIND_HAS_C_LIB c)
 append_if(libraries LIBUNWIND_HAS_DL_LIB dl)
-append_if(libraries LIBUNWIND_HAS_PTHREAD_LIB pthread)
+if (LIBUNWIND_ENABLE_THREADS)
+  append_if(libraries LIBUNWIND_HAS_PTHREAD_LIB pthread)
+endif()
 
 # Setup flags.
 append_if(LIBUNWIND_COMPILE_FLAGS LIBUNWIND_HAS_FPIC_FLAG -fPIC)
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -107,6 +107,7 @@
 option(LIBUNWIND_ENABLE_STATIC "Build libunwind as a static library." ON)
 option(LIBUNWIND_ENABLE_CROSS_UNWINDING "Enable cross-platform unwinding support." OFF)
 option(LIBUNWIND_ENABLE_ARM_WMMX "Enable unwinding support for ARM WMMX registers." OFF)
+option(LIBUNWIND_ENABLE_THREADS "Build libunwind with threading support." ON)
 

Re: [PATCH] D24977: [CUDA] Declare our __device__ math functions in the same inline namespace as our standard library.

2016-09-27 Thread Justin Lebar via cfe-commits
jlebar added a comment.

> That is way too much knowledge about details of standard library 
> implementation.


Honestly I think this looks a lot scarier than it is.  Or, to be specific, I 
think we are already relying on implementation details much more implicit and 
fragile than what is explicit here.  See the git log of all of the changes I've 
had to make to this file before now to make us compatible with all of the 
standard libraries we want to support.

> If it changes, I suspect users will end up with a rather uninformative error.


You mean, if the standard libraries change the macro they're using here?  If 
so, we'll fall back to plain "namespace std", which is what we had before, so 
it should work fine.  In fact the only way I think this can affect things one 
way or another is if the standard library does

  namespace std {
  inline namespace foo {
  void some_fn(std::complex);
  
  void test() {
some_fn(std::complex());
  }
  } // inline namespace foo
  }  // namespace std

ADL on some_fn will prefer the some_fn inside std::foo, so if we declare an 
overload of some_fn inside plain namespace std, it won't match.

> We could whitelist libc++/libstdc++ version we've tested with and produce 
> #warning "Unsupported standard library version" if we see something else.


In practice, we are testing with versions of libstdc++ that are so much newer 
than what anyone has on their systems, I am not exactly worried about this.

But I think more generally these questions are probably better handled in a 
separate patch?  Like I say, we are already rather tightly-coupled to the 
standard libraries -- I don't think this patch changes that reality too much.


https://reviews.llvm.org/D24977



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


Re: [PATCH] D24979: [CUDA] Support and std::min/max on the device.

2016-09-27 Thread Artem Belevich via cfe-commits
tra added a subscriber: echristo.
tra added a comment.

This looks like fix-includes and it may be somewhat shaky if users start 
messing with include paths. You may want to get @echristo's input on that. I' 
personally would prefer to force-include these files. I suspect it will not 
change things much as we already include a lot.



Comment at: clang/lib/Driver/ToolChains.cpp:4704
@@ +4703,3 @@
+llvm::sys::path::append(P, "include");
+llvm::sys::path::append(P, "cuda_wrappers");
+addSystemInclude(DriverArgs, CC1Args, P);

path::append accepts multiple path parts so you can construct path in one call.


https://reviews.llvm.org/D24979



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


Re: [PATCH] D24977: [CUDA] Declare our __device__ math functions in the same inline namespace as our standard library.

2016-09-27 Thread Artem Belevich via cfe-commits
tra added a comment.

OK.


https://reviews.llvm.org/D24977



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


Re: [PATCH] D24981: [Coverage] The coverage region for a switch should cover the code after the switch

2016-09-27 Thread Vedant Kumar via cfe-commits
vsk accepted this revision.
vsk added a comment.
This revision is now accepted and ready to land.

LGTM, thank you!

It makes sense to inherit the current region's counter when we see a new 
switch. That should fix the 0 execution count we see on the condition.


Repository:
  rL LLVM

https://reviews.llvm.org/D24981



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


Re: [PATCH] D24979: [CUDA] Support and std::min/max on the device.

2016-09-27 Thread Justin Lebar via cfe-commits
jlebar added a comment.

> I' personally would prefer to force-include these files. I suspect it will 
> not change things much as we already include a lot.


We have already had bugs filed by users whose root cause was that we #included 
more things than nvcc #includes.  I know exact compatibility with nvcc is not 
our goal, but unless we have a good reason I don't think we should break 
compatibility with nvcc *and* the C++ standard by force-including additional 
system headers.

> This looks like fix-includes and it may be somewhat shaky if users start 
> messing with include paths.


We add this include path first, so I think it should be OK?  What do you think, 
@echristo.


https://reviews.llvm.org/D24979



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


  1   2   >