[PATCH] D39121: [clang-tidy] Misplaced Operator in Strlen in Alloc

2017-11-01 Thread Balogh , Ádám via Phabricator via cfe-commits
baloghadamsoftware updated this revision to Diff 121102.
baloghadamsoftware added a comment.

Diagnostic message changed.


https://reviews.llvm.org/D39121

Files:
  clang-tidy/bugprone/BugproneTidyModule.cpp
  clang-tidy/bugprone/CMakeLists.txt
  clang-tidy/bugprone/MisplacedOperatorInStrlenInAllocCheck.cpp
  clang-tidy/bugprone/MisplacedOperatorInStrlenInAllocCheck.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/bugprone-misplaced-operator-in-strlen-in-alloc.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/bugprone-misplaced-operator-in-strlen-in-alloc.c
  test/clang-tidy/bugprone-misplaced-operator-in-strlen-in-alloc.cpp

Index: test/clang-tidy/bugprone-misplaced-operator-in-strlen-in-alloc.cpp
===
--- /dev/null
+++ test/clang-tidy/bugprone-misplaced-operator-in-strlen-in-alloc.cpp
@@ -0,0 +1,31 @@
+// RUN: %check_clang_tidy %s bugprone-misplaced-operator-in-strlen-in-alloc %t
+
+namespace std {
+typedef __typeof(sizeof(int)) size_t;
+void *malloc(size_t);
+
+size_t strlen(const char*);
+}
+
+namespace non_std {
+typedef __typeof(sizeof(int)) size_t;
+void *malloc(size_t);
+
+size_t strlen(const char*);
+}
+
+void bad_std_malloc_std_strlen(char *name) {
+  char *new_name = (char*) std::malloc(std::strlen(name + 1));
+  // CHECK-MESSAGES: :[[@LINE-1]]:28: warning: Addition operator is applied to the argument of strlen
+  // CHECK-FIXES: {{^  char \*new_name = \(char\*\) std::malloc\(}}std::strlen(name) + 1{{\);$}}
+}
+
+void ignore_non_std_malloc_std_strlen(char *name) {
+  char *new_name = (char*) non_std::malloc(std::strlen(name + 1));
+  // Ignore functions of the malloc family in custom namespaces
+}
+
+void ignore_std_malloc_non_std_strlen(char *name) {
+  char *new_name = (char*) std::malloc(non_std::strlen(name + 1));
+  // Ignore functions of the strlen family in custom namespaces
+}
Index: test/clang-tidy/bugprone-misplaced-operator-in-strlen-in-alloc.c
===
--- /dev/null
+++ test/clang-tidy/bugprone-misplaced-operator-in-strlen-in-alloc.c
@@ -0,0 +1,78 @@
+// RUN: %check_clang_tidy %s bugprone-misplaced-operator-in-strlen-in-alloc %t
+
+typedef __typeof(sizeof(int)) size_t;
+void *malloc(size_t);
+void *alloca(size_t);
+void *calloc(size_t, size_t);
+void *realloc(void *, size_t);
+
+size_t strlen(const char*);
+size_t strnlen(const char*, size_t);
+size_t strnlen_s(const char*, size_t);
+
+typedef unsigned wchar_t;
+
+size_t wcslen(const wchar_t*);
+size_t wcsnlen(const wchar_t*, size_t);
+size_t wcsnlen_s(const wchar_t*, size_t);
+
+void bad_malloc(char *name) {
+  char *new_name = (char*) malloc(strlen(name + 1));
+  // CHECK-MESSAGES: :[[@LINE-1]]:28: warning: Addition operator is applied to the argument of strlen
+  // CHECK-FIXES: {{^  char \*new_name = \(char\*\) malloc\(}}strlen(name) + 1{{\);$}}
+  new_name = (char*) malloc(strnlen(name + 1, 10));
+  // CHECK-MESSAGES: :[[@LINE-1]]:22: warning: Addition operator is applied to the argument of strnlen
+  // CHECK-FIXES: {{^  new_name = \(char\*\) malloc\(}}strnlen(name, 10) + 1{{\);$}}
+  new_name = (char*) malloc(strnlen_s(name + 1, 10));
+  // CHECK-MESSAGES: :[[@LINE-1]]:22: warning: Addition operator is applied to the argument of strnlen_s
+  // CHECK-FIXES: {{^  new_name = \(char\*\) malloc\(}}strnlen_s(name, 10) + 1{{\);$}}
+}
+
+void bad_malloc_wide(wchar_t *name) {
+  wchar_t *new_name = (wchar_t*) malloc(wcslen(name + 1));
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning: Addition operator is applied to the argument of wcslen
+  // CHECK-FIXES: {{^  wchar_t \*new_name = \(wchar_t\*\) malloc\(}}wcslen(name) + 1{{\);$}}
+  new_name = (wchar_t*) malloc(wcsnlen(name + 1, 10));
+  // CHECK-MESSAGES: :[[@LINE-1]]:25: warning: Addition operator is applied to the argument of wcsnlen
+  // CHECK-FIXES: {{^  new_name = \(wchar_t\*\) malloc\(}}wcsnlen(name, 10) + 1{{\);$}}
+  new_name = (wchar_t*) malloc(wcsnlen_s(name + 1, 10));
+  // CHECK-MESSAGES: :[[@LINE-1]]:25: warning: Addition operator is applied to the argument of wcsnlen_s
+  // CHECK-FIXES: {{^  new_name = \(wchar_t\*\) malloc\(}}wcsnlen_s(name, 10) + 1{{\);$}}
+}
+
+void bad_alloca(char *name) {
+  char *new_name = (char*) alloca(strlen(name + 1));
+  // CHECK-MESSAGES: :[[@LINE-1]]:28: warning: Addition operator is applied to the argument of strlen
+  // CHECK-FIXES: {{^  char \*new_name = \(char\*\) alloca\(}}strlen(name) + 1{{\);$}}
+}
+
+void bad_calloc(char *name) {
+  char *new_names = (char*) calloc(2, strlen(name + 1));
+  // CHECK-MESSAGES: :[[@LINE-1]]:29: warning: Addition operator is applied to the argument of strlen
+  // CHECK-FIXES: {{^  char \*new_names = \(char\*\) calloc\(2, }}strlen(name) + 1{{\);$}}
+}
+
+void bad_realloc(char * old_name, char *name) {
+  char *new_name = (char*) realloc(old_name, strlen(name + 1));
+  // CHECK-MESSAGES: :[[@LINE-1]]:28: warning: Addition operator is applied to the argument of strlen
+  // C

[PATCH] D39121: [clang-tidy] Misplaced Operator in Strlen in Alloc

2017-11-01 Thread Balogh , Ádám via Phabricator via cfe-commits
baloghadamsoftware added a comment.

OK, I will test it on some real code tomorrow, but today is a holiday here.


https://reviews.llvm.org/D39121



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


[PATCH] D39372: Make DiagnosticIDs::getAllDiagnostics static.

2017-11-01 Thread András Leitereg via Phabricator via cfe-commits
leanil updated this revision to Diff 121104.
leanil added a comment.

Update usages of the function.
Checked with clang-tidy readability-static-accessed-through-instance.


https://reviews.llvm.org/D39372

Files:
  include/clang/Basic/DiagnosticIDs.h
  lib/Basic/Diagnostic.cpp
  lib/Basic/DiagnosticIDs.cpp


Index: lib/Basic/DiagnosticIDs.cpp
===
--- lib/Basic/DiagnosticIDs.cpp
+++ lib/Basic/DiagnosticIDs.cpp
@@ -578,7 +578,7 @@
 }
 
 void DiagnosticIDs::getAllDiagnostics(diag::Flavor Flavor,
- SmallVectorImpl &Diags) const 
{
+  SmallVectorImpl &Diags) {
   for (unsigned i = 0; i != StaticDiagInfoSize; ++i)
 if (StaticDiagInfo[i].getFlavor() == Flavor)
   Diags.push_back(StaticDiagInfo[i].DiagID);
Index: lib/Basic/Diagnostic.cpp
===
--- lib/Basic/Diagnostic.cpp
+++ lib/Basic/Diagnostic.cpp
@@ -364,7 +364,7 @@
   SourceLocation Loc) {
   // Get all the diagnostics.
   SmallVector AllDiags;
-  Diags->getAllDiagnostics(Flavor, AllDiags);
+  DiagnosticIDs::getAllDiagnostics(Flavor, AllDiags);
 
   // Set the mapping.
   for (diag::kind Diag : AllDiags)
Index: include/clang/Basic/DiagnosticIDs.h
===
--- include/clang/Basic/DiagnosticIDs.h
+++ include/clang/Basic/DiagnosticIDs.h
@@ -292,8 +292,8 @@
  SmallVectorImpl &Diags) const;
 
   /// \brief Get the set of all diagnostic IDs.
-  void getAllDiagnostics(diag::Flavor Flavor,
- SmallVectorImpl &Diags) const;
+  static void getAllDiagnostics(diag::Flavor Flavor,
+SmallVectorImpl &Diags);
 
   /// \brief Get the diagnostic option with the closest edit distance to the
   /// given group name.


Index: lib/Basic/DiagnosticIDs.cpp
===
--- lib/Basic/DiagnosticIDs.cpp
+++ lib/Basic/DiagnosticIDs.cpp
@@ -578,7 +578,7 @@
 }
 
 void DiagnosticIDs::getAllDiagnostics(diag::Flavor Flavor,
- SmallVectorImpl &Diags) const {
+  SmallVectorImpl &Diags) {
   for (unsigned i = 0; i != StaticDiagInfoSize; ++i)
 if (StaticDiagInfo[i].getFlavor() == Flavor)
   Diags.push_back(StaticDiagInfo[i].DiagID);
Index: lib/Basic/Diagnostic.cpp
===
--- lib/Basic/Diagnostic.cpp
+++ lib/Basic/Diagnostic.cpp
@@ -364,7 +364,7 @@
   SourceLocation Loc) {
   // Get all the diagnostics.
   SmallVector AllDiags;
-  Diags->getAllDiagnostics(Flavor, AllDiags);
+  DiagnosticIDs::getAllDiagnostics(Flavor, AllDiags);
 
   // Set the mapping.
   for (diag::kind Diag : AllDiags)
Index: include/clang/Basic/DiagnosticIDs.h
===
--- include/clang/Basic/DiagnosticIDs.h
+++ include/clang/Basic/DiagnosticIDs.h
@@ -292,8 +292,8 @@
  SmallVectorImpl &Diags) const;
 
   /// \brief Get the set of all diagnostic IDs.
-  void getAllDiagnostics(diag::Flavor Flavor,
- SmallVectorImpl &Diags) const;
+  static void getAllDiagnostics(diag::Flavor Flavor,
+SmallVectorImpl &Diags);
 
   /// \brief Get the diagnostic option with the closest edit distance to the
   /// given group name.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] r317083 - Add LLVM_FALLTHROUGH to silence warning. NFCI.

2017-11-01 Thread Simon Pilgrim via cfe-commits
Author: rksimon
Date: Wed Nov  1 02:22:03 2017
New Revision: 317083

URL: http://llvm.org/viewvc/llvm-project?rev=317083&view=rev
Log:
Add LLVM_FALLTHROUGH to silence warning. NFCI.

Modified:
clang-tools-extra/trunk/clangd/ClangdUnit.cpp

Modified: clang-tools-extra/trunk/clangd/ClangdUnit.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdUnit.cpp?rev=317083&r1=317082&r2=317083&view=diff
==
--- clang-tools-extra/trunk/clangd/ClangdUnit.cpp (original)
+++ clang-tools-extra/trunk/clangd/ClangdUnit.cpp Wed Nov  1 02:22:03 2017
@@ -529,7 +529,7 @@ private:
 // the code-completion string, typically a keyword or the name of
 // a declarator or macro.
 Item.filterText = Chunk.Text;
-// Note intentional fallthrough here.
+LLVM_FALLTHROUGH;
   case CodeCompletionString::CK_Text:
 // A piece of text that should be placed in the buffer,
 // e.g., parentheses or a comma in a function call.


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


r317089 - Reformat.

2017-11-01 Thread NAKAMURA Takumi via cfe-commits
Author: chapuni
Date: Wed Nov  1 06:47:48 2017
New Revision: 317089

URL: http://llvm.org/viewvc/llvm-project?rev=317089&view=rev
Log:
Reformat.

Modified:
cfe/trunk/include/clang/Sema/Sema.h

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=317089&r1=317088&r2=317089&view=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Wed Nov  1 06:47:48 2017
@@ -1734,7 +1734,7 @@ public:
 NameClassification(ParsedType Type) : Kind(NC_Type), Type(Type) {}
 
 NameClassification(const IdentifierInfo *Keyword)
-  : Kind(NC_Keyword), Keyword(Keyword) { }
+: Kind(NC_Keyword), Keyword(Keyword) {}
 
 static NameClassification Error() {
   return NameClassification(NC_Error);


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


r317091 - Fix warnings discovered by rL317076. [-Wunused-private-field]

2017-11-01 Thread NAKAMURA Takumi via cfe-commits
Author: chapuni
Date: Wed Nov  1 06:47:55 2017
New Revision: 317091

URL: http://llvm.org/viewvc/llvm-project?rev=317091&view=rev
Log:
Fix warnings discovered by rL317076. [-Wunused-private-field]

Modified:
cfe/trunk/include/clang/Sema/Sema.h

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=317091&r1=317090&r2=317091&view=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Wed Nov  1 06:47:55 2017
@@ -1724,7 +1724,6 @@ public:
 ExprResult Expr;
 TemplateName Template;
 ParsedType Type;
-const IdentifierInfo *Keyword;
 
 explicit NameClassification(NameClassificationKind Kind) : Kind(Kind) {}
 
@@ -1733,8 +1732,7 @@ public:
 
 NameClassification(ParsedType Type) : Kind(NC_Type), Type(Type) {}
 
-NameClassification(const IdentifierInfo *Keyword)
-: Kind(NC_Keyword), Keyword(Keyword) {}
+NameClassification(const IdentifierInfo *Keyword) : Kind(NC_Keyword) {}
 
 static NameClassification Error() {
   return NameClassification(NC_Error);


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


[PATCH] D39481: [CodeGen] fix const-ness of builtin equivalents of and functions that might set errno

2017-11-01 Thread Sanjay Patel via Phabricator via cfe-commits
spatel added a comment.

In https://reviews.llvm.org/D39481#912378, @efriedma wrote:

> Granted, I'm not sure all of those are right... I'm pretty sure, for example, 
> cbrt can't set errno, and carg can.  But I'd prefer to deal with that in a 
> separate patch.


I figured we have to be ultra-conservative here, and there are docs out there 
like this:

  "On successful completion, cbrt() returns the cube root of x. If x is NaN, 
cbrt() returns NaN and errno may be set to [EDOM]. "

http://pubs.opengroup.org/onlinepubs/7908799/xsh/cbrt.html


https://reviews.llvm.org/D39481



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


[PATCH] D37187: [Analyzer] Fix Bug 25609 - Assertion UNREACHABLE: 'Unexpected ProgramPoint' with widen-loops=true

2017-11-01 Thread Henry Wong via Phabricator via cfe-commits
MTC added a comment.

ping?




Comment at: lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:651-652
+  } else if (StoreSite->getLocation().getAs()) {
+os << "Reach the max loop limit.";
+os << " Assigning a conjured symbol";
+if (R->canPrintPretty()) {

zaks.anna wrote:
> xazax.hun wrote:
> > zaks.anna wrote:
> > > MTC wrote:
> > > > NoQ wrote:
> > > > > This is user-facing text, and users shouldn't know about conjured 
> > > > > symbols, and "max" shouldn't be shortened, and i'm not sure what 
> > > > > else. I'd probably suggest something along the lines of "Contents of 
> > > > > <...> are wiped", but this is still not good enough.
> > > > > 
> > > > > Also could you add a test that displays this note? I.e. with 
> > > > > `-analyzer-output=text`.
> > > > Thanks for your review. 
> > > > 
> > > > You are right, whether this information should be displayed to the user 
> > > > is a question worth discussing.
> > > I am not convinced that we need to print this information to the user. 
> > > The problem here is that it leaks internal implementation details about 
> > > the analyzer. The users should not know about "loop limits" and 
> > > "invalidation" and most of the users would not even know what this means. 
> > > I can see how this is useful to the analyzer developers for debugging the 
> > > analyzer, but not to the end user.
> > > 
> > While we might not want to expose this to the user this can be really 
> > useful to understand what the analyzer is doing when we debugging a false 
> > positive finding. Maybe it would be worth to introduce a developer mode or 
> > verbose mode for those purposes. What do you think?
> I'd be fine with that in theory, though the downside is that it would pollute 
> the code a bit. One trick that's often used to better understand a report 
> when debugging is to remove the path note pruning (by passing a flag). I am 
> not sure if that approach can be extended for this case. Ex: maybe we could 
> have special markers on the notes saying that they are for debug purposes 
> only and have the pruning remove them.
> 
> By the way, is this change related to the other change from this patch?
Thank you for your review!
Agree with you, and Artem also recommends not exposing too much internal 
implementation to the user.



Comment at: lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:651-652
+  } else if (StoreSite->getLocation().getAs()) {
+os << "Reach the max loop limit.";
+os << " Assigning a conjured symbol";
+if (R->canPrintPretty()) {

MTC wrote:
> zaks.anna wrote:
> > xazax.hun wrote:
> > > zaks.anna wrote:
> > > > MTC wrote:
> > > > > NoQ wrote:
> > > > > > This is user-facing text, and users shouldn't know about conjured 
> > > > > > symbols, and "max" shouldn't be shortened, and i'm not sure what 
> > > > > > else. I'd probably suggest something along the lines of "Contents 
> > > > > > of <...> are wiped", but this is still not good enough.
> > > > > > 
> > > > > > Also could you add a test that displays this note? I.e. with 
> > > > > > `-analyzer-output=text`.
> > > > > Thanks for your review. 
> > > > > 
> > > > > You are right, whether this information should be displayed to the 
> > > > > user is a question worth discussing.
> > > > I am not convinced that we need to print this information to the user. 
> > > > The problem here is that it leaks internal implementation details about 
> > > > the analyzer. The users should not know about "loop limits" and 
> > > > "invalidation" and most of the users would not even know what this 
> > > > means. I can see how this is useful to the analyzer developers for 
> > > > debugging the analyzer, but not to the end user.
> > > > 
> > > While we might not want to expose this to the user this can be really 
> > > useful to understand what the analyzer is doing when we debugging a false 
> > > positive finding. Maybe it would be worth to introduce a developer mode 
> > > or verbose mode for those purposes. What do you think?
> > I'd be fine with that in theory, though the downside is that it would 
> > pollute the code a bit. One trick that's often used to better understand a 
> > report when debugging is to remove the path note pruning (by passing a 
> > flag). I am not sure if that approach can be extended for this case. Ex: 
> > maybe we could have special markers on the notes saying that they are for 
> > debug purposes only and have the pruning remove them.
> > 
> > By the way, is this change related to the other change from this patch?
> Thank you for your review!
> Agree with you, and Artem also recommends not exposing too much internal 
> implementation to the user.
Thank you, Gábor!
That's a good point. I think this idea requires  a little bit of work to be 
done,  and it should be done by someone more familiar with BugReport or 
PathDiagnostic, :). 




Comment at: lib/StaticAnalyzer/Core/BugReporterVisitors.cpp:

[PATCH] D37808: [clang-tidy] Add new hicpp-multiway-paths-covered check for missing branches

2017-11-01 Thread Jonas Toth via Phabricator via cfe-commits
JonasToth updated this revision to Diff 121134.
JonasToth added a comment.

- remove double whitespace


https://reviews.llvm.org/D37808

Files:
  clang-tidy/hicpp/CMakeLists.txt
  clang-tidy/hicpp/HICPPTidyModule.cpp
  clang-tidy/hicpp/MultiwayPathsCoveredCheck.cpp
  clang-tidy/hicpp/MultiwayPathsCoveredCheck.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/hicpp-multiway-paths-covered.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/hicpp-multiway-paths-covered-else.cpp
  test/clang-tidy/hicpp-multiway-paths-covered.cpp

Index: test/clang-tidy/hicpp-multiway-paths-covered.cpp
===
--- /dev/null
+++ test/clang-tidy/hicpp-multiway-paths-covered.cpp
@@ -0,0 +1,445 @@
+// RUN: %check_clang_tidy %s hicpp-multiway-paths-covered %t
+
+enum OS { Mac,
+  Windows,
+  Linux };
+
+struct Bitfields {
+  unsigned UInt : 3;
+  int SInt : 1;
+};
+
+int return_integer() { return 42; }
+
+void bad_switch(int i) {
+  switch (i) {
+// CHECK-MESSAGES: [[@LINE-1]]:3: warning: switch with only one case; use if statement
+  case 0:
+break;
+  }
+  // No default in this switch
+  switch (i) {
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: potential uncovered codepath; add a default case
+  case 0:
+break;
+  case 1:
+break;
+  case 2:
+break;
+  }
+
+  // degenerate, maybe even warning
+  switch (i) {
+// CHECK-MESSAGES: [[@LINE-1]]:3: warning: degenerated switch without labels
+  }
+
+  switch (int j = return_integer()) {
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: potential uncovered codepath; add a default case
+  case 0:
+  case 1:
+  case 2:
+break;
+  }
+
+  // Degenerated, only default case.
+  switch (i) {
+// CHECK-MESSAGES: [[@LINE-1]]:3: warning: degenerated switch with default label only
+  default:
+break;
+  }
+
+  // Degenerated, only one case label and default case -> Better as if-stmt.
+  switch (i) {
+// CHECK-MESSAGES: [[@LINE-1]]:3: warning: switch could be better written as if/else statement
+  case 0:
+break;
+  default:
+break;
+  }
+
+  unsigned long long BigNumber = 0;
+  switch (BigNumber) {
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: potential uncovered codepath; add a default case
+  case 0:
+  case 1:
+break;
+  }
+
+  const int &IntRef = i;
+  switch (IntRef) {
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: potential uncovered codepath; add a default case
+  case 0:
+  case 1:
+break;
+  }
+
+  char C = 'A';
+  switch (C) {
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: potential uncovered codepath; add a default case
+  case 'A':
+break;
+  case 'B':
+break;
+  }
+
+  Bitfields Bf;
+  // UInt has 3 bits size.
+  switch (Bf.UInt) {
+// CHECK-MESSAGES: [[@LINE-1]]:3: warning: potential uncovered codepath; add a default case
+  case 0:
+  case 1:
+break;
+  }
+  // All paths explicitly covered.
+  switch (Bf.UInt) {
+  case 0:
+  case 1:
+  case 2:
+  case 3:
+  case 4:
+  case 5:
+  case 6:
+  case 7:
+break;
+  }
+  // SInt has 1 bit size, so this is somewhat degenerated.
+  switch (Bf.SInt) {
+// CHECK-MESSAGES: [[@LINE-1]]:3: warning: switch with only one case; use if statement
+  case 0:
+break;
+  }
+  // All paths explicitly covered.
+  switch (Bf.SInt) {
+  case 0:
+  case 1:
+break;
+  }
+}
+
+void unproblematic_switch(unsigned char c) {
+  switch (c) {
+  case 0:
+  case 1:
+  case 2:
+  case 3:
+  case 4:
+  case 5:
+  case 6:
+  case 7:
+  case 8:
+  case 9:
+  case 10:
+  case 11:
+  case 12:
+  case 13:
+  case 14:
+  case 15:
+  case 16:
+  case 17:
+  case 18:
+  case 19:
+  case 20:
+  case 21:
+  case 22:
+  case 23:
+  case 24:
+  case 25:
+  case 26:
+  case 27:
+  case 28:
+  case 29:
+  case 30:
+  case 31:
+  case 32:
+  case 33:
+  case 34:
+  case 35:
+  case 36:
+  case 37:
+  case 38:
+  case 39:
+  case 40:
+  case 41:
+  case 42:
+  case 43:
+  case 44:
+  case 45:
+  case 46:
+  case 47:
+  case 48:
+  case 49:
+  case 50:
+  case 51:
+  case 52:
+  case 53:
+  case 54:
+  case 55:
+  case 56:
+  case 57:
+  case 58:
+  case 59:
+  case 60:
+  case 61:
+  case 62:
+  case 63:
+  case 64:
+  case 65:
+  case 66:
+  case 67:
+  case 68:
+  case 69:
+  case 70:
+  case 71:
+  case 72:
+  case 73:
+  case 74:
+  case 75:
+  case 76:
+  case 77:
+  case 78:
+  case 79:
+  case 80:
+  case 81:
+  case 82:
+  case 83:
+  case 84:
+  case 85:
+  case 86:
+  case 87:
+  case 88:
+  case 89:
+  case 90:
+  case 91:
+  case 92:
+  case 93:
+  case 94:
+  case 95:
+  case 96:
+  case 97:
+  case 98:
+  case 99:
+  case 100:
+  case 101:
+  case 102:
+  case 103:
+  case 104:
+  case 105:
+  case 106:
+  case 107:
+  case 108:
+  case 109:
+  case 110:
+  case 111:
+  case 112:
+  case 113:
+  case 114:
+  case 115:
+  case 116:
+  case 117:
+  case 118:
+  case 119:
+  case 120:
+  case 121:
+  case 122:
+  case 123:
+  case 124:
+  case 125:
+  case 126:
+  case 127:
+  case 128:
+  case 129:
+  case 130:
+  

[PATCH] D39053: [Bitfield] Add more cases to making the bitfield a separate location

2017-11-01 Thread Strahinja Petrovic via Phabricator via cfe-commits
spetrovic added a comment.

I was looking if I can reslove this problem in backend. Example:

C code:

typedef struct {
unsigned int f1 : 28;
unsigned int f2 : 4;
unsigned int f3 : 12;
} S5;

void foo(S5 *cmd) {
cmd->f3 = 5;
}

. ll file (without the patch):

%struct.S5 = type { i48 }

define void @foo(%struct.S5* nocapture %cmd) local_unnamed_addr #0 {
entry:

  %0 = bitcast %struct.S5* %cmd to i64*
  %bf.load = load i64, i64* %0, align 4
  %bf.clear = and i64 %bf.load, -4293918721
  %bf.set = or i64 %bf.clear, 5242880
  store i64 %bf.set, i64* %0, align 4
  ret void

}

The load (%bf.load = load i64, i64* %0, align 4) is NON_EXTLOAD, and backend 
handles it later as unaligned load. So, maybe one of possible solutions in 
backend is for each architecture to try to catch node pattern and replace 
unaligned loads with normal loads in specific cases, but I'm not sure how 
feasible that is. At the moment, the solution in frontend seems better to me. 
What do you think?


https://reviews.llvm.org/D39053



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


[PATCH] D39239: [AST] Incorrectly qualified unscoped enumeration as template actual parameter.

2017-11-01 Thread Paul Robinson via Phabricator via cfe-commits
probinson added a comment.

Have you tried the GDB suite yet?  If it has no problems, and we can make LLDB 
happy, I'm okay with it.


https://reviews.llvm.org/D39239



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


[PATCH] D39498: [clang-format] Make parseUnaryOperator non-recursive, NFCI

2017-11-01 Thread Benjamin Kramer via Phabricator via cfe-commits
bkramer accepted this revision.
bkramer added a comment.
This revision is now accepted and ready to land.

lg




Comment at: lib/Format/TokenAnnotator.cpp:1671
+parse(PrecedenceArrowAndPeriod);
+for (size_t I = 0, E = Tokens.size(); I < E; ++I)
+  // The actual precedence doesn't matter.

`for (FormatToken *Token : llvm::reverse(Tokens))`


https://reviews.llvm.org/D39498



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


[PATCH] D38284: [clang-tidy] Fix google-readability-namespace-comments handling of C++17 nested namespaces

2017-11-01 Thread Alexandru Octavian Buțiu via Phabricator via cfe-commits
predator5047 updated this revision to Diff 121152.
predator5047 added a comment.

Fixed assert error caused by macros.


https://reviews.llvm.org/D38284

Files:
  clang-tidy/readability/NamespaceCommentCheck.cpp
  clang-tidy/readability/NamespaceCommentCheck.h
  test/clang-tidy/google-readability-nested-namespace-comments.cpp

Index: test/clang-tidy/google-readability-nested-namespace-comments.cpp
===
--- /dev/null
+++ test/clang-tidy/google-readability-nested-namespace-comments.cpp
@@ -0,0 +1,17 @@
+// RUN: %check_clang_tidy %s google-readability-namespace-comments %t
+
+namespace n1::n2 {
+namespace n3 {
+	
+	// So that namespace is not empty.
+	void f();
+	
+	
+// CHECK-MESSAGES: :[[@LINE+4]]:2: warning: namespace 'n3' not terminated with
+// CHECK-MESSAGES: :[[@LINE-7]]:11: note: namespace 'n3' starts here
+// CHECK-MESSAGES: :[[@LINE+2]]:3: warning: namespace 'n1::n2' not terminated with a closing comment [google-readability-namespace-comments]
+// CHECK-MESSAGES: :[[@LINE-10]]:11: note: namespace 'n1::n2' starts here
+}}
+// CHECK-FIXES: }  // namespace n3
+// CHECK-FIXES: }  // namespace n1::n2
+
Index: clang-tidy/readability/NamespaceCommentCheck.h
===
--- clang-tidy/readability/NamespaceCommentCheck.h
+++ clang-tidy/readability/NamespaceCommentCheck.h
@@ -34,6 +34,7 @@
   llvm::Regex NamespaceCommentPattern;
   const unsigned ShortNamespaceLines;
   const unsigned SpacesBeforeComments;
+  llvm::SmallVector Ends;
 };
 
 } // namespace readability
Index: clang-tidy/readability/NamespaceCommentCheck.cpp
===
--- clang-tidy/readability/NamespaceCommentCheck.cpp
+++ clang-tidy/readability/NamespaceCommentCheck.cpp
@@ -23,7 +23,7 @@
  ClangTidyContext *Context)
 : ClangTidyCheck(Name, Context),
   NamespaceCommentPattern("^/[/*] *(end (of )?)? *(anonymous|unnamed)? *"
-  "namespace( +([a-zA-Z0-9_]+))?\\.? *(\\*/)?$",
+  "namespace( +([a-zA-Z0-9_:]+))?\\.? *(\\*/)?$",
   llvm::Regex::IgnoreCase),
   ShortNamespaceLines(Options.get("ShortNamespaceLines", 1u)),
   SpacesBeforeComments(Options.get("SpacesBeforeComments", 1u)) {}
@@ -56,6 +56,15 @@
   return Fix;
 }
 
+static std::string getNamespaceComment(const std::string &NameSpaceName,
+   bool InsertLineBreak) {
+  std::string Fix = "// namespace ";
+  Fix.append(NameSpaceName);
+  if (InsertLineBreak)
+Fix.append("\n");
+  return Fix;
+}
+
 void NamespaceCommentCheck::check(const MatchFinder::MatchResult &Result) {
   const auto *ND = Result.Nodes.getNodeAs("namespace");
   const SourceManager &Sources = *Result.SourceManager;
@@ -74,11 +83,44 @@
   SourceLocation AfterRBrace = ND->getRBraceLoc().getLocWithOffset(1);
   SourceLocation Loc = AfterRBrace;
   Token Tok;
+  SourceLocation LBracketLocation = ND->getLocation();
+  SourceLocation NestedNamespaceBegin = LBracketLocation;
+
+  // Currently for nested namepsace (n1::n2::...) the AST matcher will match foo
+  // then bar instead of a single match. So if we got a nested namespace we have
+  // to skip the next ones.
+  for (const auto &EndOfNameLocation : Ends) {
+if (Sources.isBeforeInTranslationUnit(NestedNamespaceBegin,
+  EndOfNameLocation))
+  return;
+  }
+
+  // Ignore macros
+  if (!ND->getLocation().isMacroID()) {
+while (Lexer::getRawToken(LBracketLocation, Tok, Sources, getLangOpts()) ||
+   !Tok.is(tok::l_brace)) {
+  LBracketLocation = LBracketLocation.getLocWithOffset(1);
+}
+  }
+
+  auto TextRange =
+  Lexer::getAsCharRange(SourceRange(NestedNamespaceBegin, LBracketLocation),
+Sources, getLangOpts());
+  StringRef NestedNamespaceName =
+  Lexer::getSourceText(TextRange, Sources, getLangOpts()).rtrim();
+  bool IsNested = NestedNamespaceName.contains(':');
+
+  if (IsNested)
+Ends.push_back(LBracketLocation);
+  else
+NestedNamespaceName = ND->getName();
+
   // Skip whitespace until we find the next token.
   while (Lexer::getRawToken(Loc, Tok, Sources, getLangOpts()) ||
  Tok.is(tok::semi)) {
 Loc = Loc.getLocWithOffset(1);
   }
+
   if (!locationsInSameFile(Sources, ND->getRBraceLoc(), Loc))
 return;
 
@@ -98,10 +140,14 @@
   StringRef NamespaceNameInComment = Groups.size() > 5 ? Groups[5] : "";
   StringRef Anonymous = Groups.size() > 3 ? Groups[3] : "";
 
-  // Check if the namespace in the comment is the same.
-  if ((ND->isAnonymousNamespace() && NamespaceNameInComment.empty()) ||
-  (ND->getNameAsString() == NamespaceNameInComment &&
-   Anonymous.empty())) {
+  if (IsNested && NestedNamespaceName == NamespaceNameInComment) {
+// C++17 n

[PATCH] D39498: [clang-format] Make parseUnaryOperator non-recursive, NFCI

2017-11-01 Thread Krasimir Georgiev via Phabricator via cfe-commits
krasimir updated this revision to Diff 121156.
krasimir added a comment.

- Address review comments


https://reviews.llvm.org/D39498

Files:
  lib/Format/TokenAnnotator.cpp


Index: lib/Format/TokenAnnotator.cpp
===
--- lib/Format/TokenAnnotator.cpp
+++ lib/Format/TokenAnnotator.cpp
@@ -1662,17 +1662,15 @@
   /// \brief Parse unary operator expressions and surround them with fake
   /// parentheses if appropriate.
   void parseUnaryOperator() {
-if (!Current || Current->isNot(TT_UnaryOperator)) {
-  parse(PrecedenceArrowAndPeriod);
-  return;
+llvm::SmallVector Tokens;
+while (Current && Current->is(TT_UnaryOperator)) {
+  Tokens.push_back(Current);
+  next();
 }
-
-FormatToken *Start = Current;
-next();
-parseUnaryOperator();
-
-// The actual precedence doesn't matter.
-addFakeParenthesis(Start, prec::Unknown);
+parse(PrecedenceArrowAndPeriod);
+for (FormatToken *Token : llvm::reverse(Tokens))
+  // The actual precedence doesn't matter.
+  addFakeParenthesis(Token, prec::Unknown);
   }
 
   void parseConditionalExpr() {


Index: lib/Format/TokenAnnotator.cpp
===
--- lib/Format/TokenAnnotator.cpp
+++ lib/Format/TokenAnnotator.cpp
@@ -1662,17 +1662,15 @@
   /// \brief Parse unary operator expressions and surround them with fake
   /// parentheses if appropriate.
   void parseUnaryOperator() {
-if (!Current || Current->isNot(TT_UnaryOperator)) {
-  parse(PrecedenceArrowAndPeriod);
-  return;
+llvm::SmallVector Tokens;
+while (Current && Current->is(TT_UnaryOperator)) {
+  Tokens.push_back(Current);
+  next();
 }
-
-FormatToken *Start = Current;
-next();
-parseUnaryOperator();
-
-// The actual precedence doesn't matter.
-addFakeParenthesis(Start, prec::Unknown);
+parse(PrecedenceArrowAndPeriod);
+for (FormatToken *Token : llvm::reverse(Tokens))
+  // The actual precedence doesn't matter.
+  addFakeParenthesis(Token, prec::Unknown);
   }
 
   void parseConditionalExpr() {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D39498: [clang-format] Make parseUnaryOperator non-recursive, NFCI

2017-11-01 Thread Krasimir Georgiev via Phabricator via cfe-commits
krasimir added inline comments.



Comment at: lib/Format/TokenAnnotator.cpp:1671
+parse(PrecedenceArrowAndPeriod);
+for (size_t I = 0, E = Tokens.size(); I < E; ++I)
+  // The actual precedence doesn't matter.

bkramer wrote:
> `for (FormatToken *Token : llvm::reverse(Tokens))`
Wow! That's so cool! Thanks!


https://reviews.llvm.org/D39498



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


[PATCH] D39498: [clang-format] Make parseUnaryOperator non-recursive, NFCI

2017-11-01 Thread Krasimir Georgiev via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL317113: [clang-format] Make parseUnaryOperator 
non-recursive, NFCI (authored by krasimir).

Repository:
  rL LLVM

https://reviews.llvm.org/D39498

Files:
  cfe/trunk/lib/Format/TokenAnnotator.cpp


Index: cfe/trunk/lib/Format/TokenAnnotator.cpp
===
--- cfe/trunk/lib/Format/TokenAnnotator.cpp
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp
@@ -1662,17 +1662,15 @@
   /// \brief Parse unary operator expressions and surround them with fake
   /// parentheses if appropriate.
   void parseUnaryOperator() {
-if (!Current || Current->isNot(TT_UnaryOperator)) {
-  parse(PrecedenceArrowAndPeriod);
-  return;
+llvm::SmallVector Tokens;
+while (Current && Current->is(TT_UnaryOperator)) {
+  Tokens.push_back(Current);
+  next();
 }
-
-FormatToken *Start = Current;
-next();
-parseUnaryOperator();
-
-// The actual precedence doesn't matter.
-addFakeParenthesis(Start, prec::Unknown);
+parse(PrecedenceArrowAndPeriod);
+for (FormatToken *Token : llvm::reverse(Tokens))
+  // The actual precedence doesn't matter.
+  addFakeParenthesis(Token, prec::Unknown);
   }
 
   void parseConditionalExpr() {


Index: cfe/trunk/lib/Format/TokenAnnotator.cpp
===
--- cfe/trunk/lib/Format/TokenAnnotator.cpp
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp
@@ -1662,17 +1662,15 @@
   /// \brief Parse unary operator expressions and surround them with fake
   /// parentheses if appropriate.
   void parseUnaryOperator() {
-if (!Current || Current->isNot(TT_UnaryOperator)) {
-  parse(PrecedenceArrowAndPeriod);
-  return;
+llvm::SmallVector Tokens;
+while (Current && Current->is(TT_UnaryOperator)) {
+  Tokens.push_back(Current);
+  next();
 }
-
-FormatToken *Start = Current;
-next();
-parseUnaryOperator();
-
-// The actual precedence doesn't matter.
-addFakeParenthesis(Start, prec::Unknown);
+parse(PrecedenceArrowAndPeriod);
+for (FormatToken *Token : llvm::reverse(Tokens))
+  // The actual precedence doesn't matter.
+  addFakeParenthesis(Token, prec::Unknown);
   }
 
   void parseConditionalExpr() {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r317113 - [clang-format] Make parseUnaryOperator non-recursive, NFCI

2017-11-01 Thread Krasimir Georgiev via cfe-commits
Author: krasimir
Date: Wed Nov  1 11:20:41 2017
New Revision: 317113

URL: http://llvm.org/viewvc/llvm-project?rev=317113&view=rev
Log:
[clang-format] Make parseUnaryOperator non-recursive, NFCI

Summary:
This patch makes the implementation of parseUnaryOperator non-recursive. We had
a problem with a file starting with tens of thousands of +'es and -'es which
caused clang-format to stack overflow.

Reviewers: bkramer

Reviewed By: bkramer

Subscribers: cfe-commits, klimek

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

Modified:
cfe/trunk/lib/Format/TokenAnnotator.cpp

Modified: cfe/trunk/lib/Format/TokenAnnotator.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/TokenAnnotator.cpp?rev=317113&r1=317112&r2=317113&view=diff
==
--- cfe/trunk/lib/Format/TokenAnnotator.cpp (original)
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp Wed Nov  1 11:20:41 2017
@@ -1662,17 +1662,15 @@ private:
   /// \brief Parse unary operator expressions and surround them with fake
   /// parentheses if appropriate.
   void parseUnaryOperator() {
-if (!Current || Current->isNot(TT_UnaryOperator)) {
-  parse(PrecedenceArrowAndPeriod);
-  return;
+llvm::SmallVector Tokens;
+while (Current && Current->is(TT_UnaryOperator)) {
+  Tokens.push_back(Current);
+  next();
 }
-
-FormatToken *Start = Current;
-next();
-parseUnaryOperator();
-
-// The actual precedence doesn't matter.
-addFakeParenthesis(Start, prec::Unknown);
+parse(PrecedenceArrowAndPeriod);
+for (FormatToken *Token : llvm::reverse(Tokens))
+  // The actual precedence doesn't matter.
+  addFakeParenthesis(Token, prec::Unknown);
   }
 
   void parseConditionalExpr() {


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


[PATCH] D39478: [clang-format] Handle leading comments in using declaration

2017-11-01 Thread Daniel Jasper via Phabricator via cfe-commits
djasper accepted this revision.
djasper added a comment.
This revision is now accepted and ready to land.

Some minor remarks, but generally looks good. Thanks for fixing this!




Comment at: lib/Format/UsingDeclarationsSorter.cpp:136
   for (size_t I = 0, E = AnnotatedLines.size(); I != E; ++I) {
+auto FirstTok = AnnotatedLines[I]->First;
 if (AnnotatedLines[I]->InPPDirective ||

  const auto *FirstTok

or

  const FormatToken *FirstTok



Comment at: lib/Format/UsingDeclarationsSorter.cpp:142
 }
-if (AnnotatedLines[I]->First->NewlinesBefore > 1)
+if (FirstTok->NewlinesBefore > 1) {
   endUsingDeclarationBlock(&UsingDeclarations, SourceMgr, &Fixes);

We don't use braces around single-statement ifs in LLVM style.



Comment at: lib/Format/UsingDeclarationsSorter.cpp:145
+}
+auto UsingTok =
+FirstTok->is(tok::comment) ? FirstTok->getNextNonComment() : FirstTok;

  const auto *UsingTok

or

  const FormatToken *UsingTok


https://reviews.llvm.org/D39478



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


[PATCH] D39481: [CodeGen] fix const-ness of builtin equivalents of and functions that might set errno

2017-11-01 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added a comment.

I think we should assume libm complies with the C99 standard (specifically, the 
appendix specifying the behavior of IEEE floating-point).  Otherwise, we have 
no basis to predict the behavior of any standard library call.

From the standard: "Functions with a NaN argument return a NaN result and raise 
no floating-point exception, except where stated otherwise."


https://reviews.llvm.org/D39481



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


[PATCH] D39478: [clang-format] Handle leading comments in using declaration

2017-11-01 Thread Igor Sugak via Phabricator via cfe-commits
sugak updated this revision to Diff 121165.
sugak marked 3 inline comments as done.
sugak added a comment.

Updated per comments.

@djasper : Thank you for the review! Would you commit this for me?


https://reviews.llvm.org/D39478

Files:
  lib/Format/UsingDeclarationsSorter.cpp
  unittests/Format/UsingDeclarationsSorterTest.cpp


Index: unittests/Format/UsingDeclarationsSorterTest.cpp
===
--- unittests/Format/UsingDeclarationsSorterTest.cpp
+++ unittests/Format/UsingDeclarationsSorterTest.cpp
@@ -328,6 +328,13 @@
   {tooling::Range(19, 1)}));
 }
 
+TEST_F(UsingDeclarationsSorterTest, 
SortsUsingDeclarationsWithLeadingkComments) {
+  EXPECT_EQ("/* comment */ using a;\n"
+"/* comment */ using b;",
+sortUsingDeclarations("/* comment */ using b;\n"
+  "/* comment */ using a;"));
+}
+
 } // end namespace
 } // end namespace format
 } // end namespace clang
Index: lib/Format/UsingDeclarationsSorter.cpp
===
--- lib/Format/UsingDeclarationsSorter.cpp
+++ lib/Format/UsingDeclarationsSorter.cpp
@@ -133,15 +133,17 @@
   tooling::Replacements Fixes;
   SmallVector UsingDeclarations;
   for (size_t I = 0, E = AnnotatedLines.size(); I != E; ++I) {
+const auto *FirstTok = AnnotatedLines[I]->First;
 if (AnnotatedLines[I]->InPPDirective ||
-!AnnotatedLines[I]->startsWith(tok::kw_using) ||
-AnnotatedLines[I]->First->Finalized) {
+!AnnotatedLines[I]->startsWith(tok::kw_using) || FirstTok->Finalized) {
   endUsingDeclarationBlock(&UsingDeclarations, SourceMgr, &Fixes);
   continue;
 }
-if (AnnotatedLines[I]->First->NewlinesBefore > 1)
+if (FirstTok->NewlinesBefore > 1)
   endUsingDeclarationBlock(&UsingDeclarations, SourceMgr, &Fixes);
-std::string Label = computeUsingDeclarationLabel(AnnotatedLines[I]->First);
+const auto *UsingTok =
+FirstTok->is(tok::comment) ? FirstTok->getNextNonComment() : FirstTok;
+std::string Label = computeUsingDeclarationLabel(UsingTok);
 if (Label.empty()) {
   endUsingDeclarationBlock(&UsingDeclarations, SourceMgr, &Fixes);
   continue;


Index: unittests/Format/UsingDeclarationsSorterTest.cpp
===
--- unittests/Format/UsingDeclarationsSorterTest.cpp
+++ unittests/Format/UsingDeclarationsSorterTest.cpp
@@ -328,6 +328,13 @@
   {tooling::Range(19, 1)}));
 }
 
+TEST_F(UsingDeclarationsSorterTest, SortsUsingDeclarationsWithLeadingkComments) {
+  EXPECT_EQ("/* comment */ using a;\n"
+"/* comment */ using b;",
+sortUsingDeclarations("/* comment */ using b;\n"
+  "/* comment */ using a;"));
+}
+
 } // end namespace
 } // end namespace format
 } // end namespace clang
Index: lib/Format/UsingDeclarationsSorter.cpp
===
--- lib/Format/UsingDeclarationsSorter.cpp
+++ lib/Format/UsingDeclarationsSorter.cpp
@@ -133,15 +133,17 @@
   tooling::Replacements Fixes;
   SmallVector UsingDeclarations;
   for (size_t I = 0, E = AnnotatedLines.size(); I != E; ++I) {
+const auto *FirstTok = AnnotatedLines[I]->First;
 if (AnnotatedLines[I]->InPPDirective ||
-!AnnotatedLines[I]->startsWith(tok::kw_using) ||
-AnnotatedLines[I]->First->Finalized) {
+!AnnotatedLines[I]->startsWith(tok::kw_using) || FirstTok->Finalized) {
   endUsingDeclarationBlock(&UsingDeclarations, SourceMgr, &Fixes);
   continue;
 }
-if (AnnotatedLines[I]->First->NewlinesBefore > 1)
+if (FirstTok->NewlinesBefore > 1)
   endUsingDeclarationBlock(&UsingDeclarations, SourceMgr, &Fixes);
-std::string Label = computeUsingDeclarationLabel(AnnotatedLines[I]->First);
+const auto *UsingTok =
+FirstTok->is(tok::comment) ? FirstTok->getNextNonComment() : FirstTok;
+std::string Label = computeUsingDeclarationLabel(UsingTok);
 if (Label.empty()) {
   endUsingDeclarationBlock(&UsingDeclarations, SourceMgr, &Fixes);
   continue;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D39502: [Driver] Make clang/cc conforms to UNIX standard

2017-11-01 Thread Steven Wu via Phabricator via cfe-commits
steven_wu created this revision.

This is basically reverting r261774 with a tweak for clang-cl. UNIX
standard states:
When c99 encounters a compilation error that causes an object file not
to be created, it shall write a diagnostic to standard error and
continue to compile other source code operands, but it shall not perform
the link phase and it shall return a non-zero exit status

The same goes for c89 or cc. And they are all alias or shims pointing to
clang on Darwin.

The original commit was intended for CUDA so the error message doesn't
get emit twice for both host and device. It seems that the clang driver
has been changed to model the CUDA dependency differently. Now the
driver behaves the same without this commit.

rdar://problem/32223263


https://reviews.llvm.org/D39502

Files:
  lib/Driver/Compilation.cpp
  test/Driver/output-file-cleanup.c


Index: test/Driver/output-file-cleanup.c
===
--- test/Driver/output-file-cleanup.c
+++ test/Driver/output-file-cleanup.c
@@ -53,6 +53,6 @@
 // RUN: not %clang -S %t-dir/1.c %t-dir/2.c %t-dir/3.c %t-dir/4.c %t-dir/5.c
 // RUN: test -f %t-dir/1.s
 // RUN: test ! -f %t-dir/2.s
-// RUN: test ! -f %t-dir/3.s
+// RUN: test -f %t-dir/3.s
 // RUN: test ! -f %t-dir/4.s
-// RUN: test ! -f %t-dir/5.s
+// RUN: test -f %t-dir/5.s
Index: lib/Driver/Compilation.cpp
===
--- lib/Driver/Compilation.cpp
+++ lib/Driver/Compilation.cpp
@@ -182,16 +182,42 @@
   return ExecutionFailed ? 1 : Res;
 }
 
-void Compilation::ExecuteJobs(
-const JobList &Jobs,
-SmallVectorImpl> &FailingCommands) const {
+typedef SmallVectorImpl< std::pair > FailingCommandList;
+
+static bool ActionFailed(const Action *A,
+ const FailingCommandList &FailingCommands) {
+
+  if (FailingCommands.empty())
+return false;
+
+  for (FailingCommandList::const_iterator CI = FailingCommands.begin(),
+ CE = FailingCommands.end(); CI != CE; ++CI)
+if (A == &(CI->second->getSource()))
+  return true;
+
+  for (const Action *AI : A->inputs())
+if (ActionFailed(AI, FailingCommands))
+  return true;
+
+  return false;
+}
+
+static bool InputsOk(const Command &C,
+ const FailingCommandList &FailingCommands) {
+  return !ActionFailed(&C.getSource(), FailingCommands);
+}
+
+void Compilation::ExecuteJobs(const JobList &Jobs,
+  FailingCommandList &FailingCommands) const {
   for (const auto &Job : Jobs) {
+if (!InputsOk(Job, FailingCommands))
+  continue;
 const Command *FailingCommand = nullptr;
 if (int Res = ExecuteCommand(Job, FailingCommand)) {
   FailingCommands.push_back(std::make_pair(Res, FailingCommand));
-  // Bail as soon as one command fails, so we don't output duplicate error
-  // messages if we die on e.g. the same file.
-  return;
+  // Bail on error in cl mode.
+  if (TheDriver.IsCLMode())
+return;
 }
   }
 }


Index: test/Driver/output-file-cleanup.c
===
--- test/Driver/output-file-cleanup.c
+++ test/Driver/output-file-cleanup.c
@@ -53,6 +53,6 @@
 // RUN: not %clang -S %t-dir/1.c %t-dir/2.c %t-dir/3.c %t-dir/4.c %t-dir/5.c
 // RUN: test -f %t-dir/1.s
 // RUN: test ! -f %t-dir/2.s
-// RUN: test ! -f %t-dir/3.s
+// RUN: test -f %t-dir/3.s
 // RUN: test ! -f %t-dir/4.s
-// RUN: test ! -f %t-dir/5.s
+// RUN: test -f %t-dir/5.s
Index: lib/Driver/Compilation.cpp
===
--- lib/Driver/Compilation.cpp
+++ lib/Driver/Compilation.cpp
@@ -182,16 +182,42 @@
   return ExecutionFailed ? 1 : Res;
 }
 
-void Compilation::ExecuteJobs(
-const JobList &Jobs,
-SmallVectorImpl> &FailingCommands) const {
+typedef SmallVectorImpl< std::pair > FailingCommandList;
+
+static bool ActionFailed(const Action *A,
+ const FailingCommandList &FailingCommands) {
+
+  if (FailingCommands.empty())
+return false;
+
+  for (FailingCommandList::const_iterator CI = FailingCommands.begin(),
+ CE = FailingCommands.end(); CI != CE; ++CI)
+if (A == &(CI->second->getSource()))
+  return true;
+
+  for (const Action *AI : A->inputs())
+if (ActionFailed(AI, FailingCommands))
+  return true;
+
+  return false;
+}
+
+static bool InputsOk(const Command &C,
+ const FailingCommandList &FailingCommands) {
+  return !ActionFailed(&C.getSource(), FailingCommands);
+}
+
+void Compilation::ExecuteJobs(const JobList &Jobs,
+  FailingCommandList &FailingCommands) const {
   for (const auto &Job : Jobs) {
+if (!InputsOk(Job, FailingCommands))
+  continue;
 const Command *FailingCommand = nullptr;
 if (int Res = ExecuteCommand(Job, FailingCommand)) {
   FailingCommands.push_back(std::make_pair(Res, FailingCommand));
-  // Bail a

[PATCH] D39502: [Driver] Make clang/cc conforms to UNIX standard

2017-11-01 Thread Steven Wu via Phabricator via cfe-commits
steven_wu added a comment.

More background here that doesn't fit in the commit message.

The tweak for cl mode is intended for r262420. I don't see any test breakage on 
my machine without that hack but I leave it in there just in case.

A little reasoning behind clang driver for CUDA. This is what I see now with 
clang (trunk):
$ clang -x cuda test.cu -ccc-print-bindings

1. "nvptx64-nvidia-cuda" - "clang", inputs: ["test.cu"], output: 
"/var/folders/cg/pyj86ks15y74w3hkwhm_zltmgp/T/test-fbc2e7.s"
2. "nvptx64-nvidia-cuda" - "NVPTX::Assembler", inputs: 
["/var/folders/cg/pyj86ks15y74w3hkwhm_zltmgp/T/test-fbc2e7.s"], output: 
"/var/folders/cg/pyj86ks15y74w3hkwhm_zltmgp/T/test-beca72.o"
3. "nvptx64-nvidia-cuda" - "NVPTX::Linker", inputs: 
["/var/folders/cg/pyj86ks15y74w3hkwhm_zltmgp/T/test-beca72.o", 
"/var/folders/cg/pyj86ks15y74w3hkwhm_zltmgp/T/test-fbc2e7.s"], output: 
"/var/folders/cg/pyj86ks15y74w3hkwhm_zltmgp/T/test-c3378c.fatbin"
4. "x86_64-apple-darwin17.2.0" - "clang", inputs: ["test.cu", 
"/var/folders/cg/pyj86ks15y74w3hkwhm_zltmgp/T/test-c3378c.fatbin"], output: 
"/var/folders/cg/pyj86ks15y74w3hkwhm_zltmgp/T/test-193005.o"
5. "x86_64-apple-darwin17.2.0" - "darwin::Linker", inputs: 
["/var/folders/cg/pyj86ks15y74w3hkwhm_zltmgp/T/test-193005.o"], output: 
"a.out"

Note the host clang side has the inputs "test.cu" and "test-c3378c.fatbin". 
Which means if the device side compilation failed, the host side will not 
compile because InputOk will return false in this case. Same applies even if 
there are multiple CUDA inputs on the command line. clang will compile all the 
inputs even the first compilation failed but clang will not compile for host 
when device compilation failed for that input file. This is a better behavior 
than the current implementation.

I don't know what is the best way to write test cases for CUDA driver. If 
anyone can suggest the best way to write them, I will happily add them to the 
commit.
This is the behavior after the patch:
$ echo "invalid" > test.cu
$ clang -x cuda test.cu -nocudalib -nocudainc
test.cu:1:1: error: unknown type name 'invalid'
invalid
^
test.cu:1:8: error: expected unqualified-id
invalid

  ^

$ clang -x cuda test.cu test.cu -nocudalib -nocudainc

1. Same error as above, twice, once for each input file.


https://reviews.llvm.org/D39502



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


[PATCH] D39504: [OpenMP] Extend "Avoid VLAs for reduction" optimization to VLAs as base

2017-11-01 Thread Jonas Hahnfeld via Phabricator via cfe-commits
Hahnfeld created this revision.

We can generate constant sized arrays whenever the array section has constant
length, even if the base expression itself is a VLA.


https://reviews.llvm.org/D39504

Files:
  lib/Sema/SemaOpenMP.cpp
  test/OpenMP/for_reduction_codegen.cpp

Index: test/OpenMP/for_reduction_codegen.cpp
===
--- test/OpenMP/for_reduction_codegen.cpp
+++ test/OpenMP/for_reduction_codegen.cpp
@@ -207,6 +207,11 @@
 #pragma omp for reduction(+:arr) reduction(&:arrs)
   for (int i = 0; i < 10; ++i)
 ++arr[1][i];
+  // arr is a VLA, but the array section has constant length so we can generate a constant sized array!
+#pragma omp parallel
+#pragma omp for reduction(+:arr[1][0:2])
+  for (int i = 0; i < 10; ++i)
+++arr[1][i];
 #pragma omp parallel
 #pragma omp for reduction(& : var2[0 : 5][1 : 6])
   for (int i = 0; i < 10; ++i)
@@ -254,15 +259,16 @@
 // CHECK: call void (%{{.+}}*, i{{[0-9]+}}, void (i{{[0-9]+}}*, i{{[0-9]+}}*, ...)*, ...) @__kmpc_fork_call(%{{.+}}* @{{.+}}, i{{[0-9]+}} 6, void (i{{[0-9]+}}*, i{{[0-9]+}}*, ...)* bitcast (void (i{{[0-9]+}}*, i{{[0-9]+}}*, float*, [[S_FLOAT_TY]]*, [[S_FLOAT_TY]]*, float*, [2 x i32]*, [4 x [[S_FLOAT_TY]]]*)* [[MAIN_MICROTASK:@.+]] to void
 // CHECK: call void (%{{.+}}*, i{{[0-9]+}}, void (i{{[0-9]+}}*, i{{[0-9]+}}*, ...)*, ...) @__kmpc_fork_call(%{{.+}}* @{{.+}}, i{{[0-9]+}} 5, void (i{{[0-9]+}}*, i{{[0-9]+}}*, ...)* bitcast (void (i{{[0-9]+}}*, i{{[0-9]+}}*, i64, i64, i32*, [2 x i32]*, [10 x [4 x [[S_FLOAT_TY*)* [[MAIN_MICROTASK1:@.+]] to void
 // CHECK: call void (%{{.+}}*, i{{[0-9]+}}, void (i{{[0-9]+}}*, i{{[0-9]+}}*, ...)*, ...) @__kmpc_fork_call(%{{.+}}* @{{.+}}, i{{[0-9]+}} 4, void (i{{[0-9]+}}*, i{{[0-9]+}}*, ...)* bitcast (void (i{{[0-9]+}}*, i{{[0-9]+}}*, i64, i64, i32*, [10 x [4 x [[S_FLOAT_TY*)* [[MAIN_MICROTASK2:@.+]] to void
-// CHECK: call void (%{{.+}}*, i{{[0-9]+}}, void (i{{[0-9]+}}*, i{{[0-9]+}}*, ...)*, ...) @__kmpc_fork_call(%{{.+}}* @{{.+}}, i{{[0-9]+}} 1, void (i{{[0-9]+}}*, i{{[0-9]+}}*, ...)* bitcast (void (i{{[0-9]+}}*, i{{[0-9]+}}*, [[S_FLOAT_TY]]***)* [[MAIN_MICROTASK3:@.+]] to void
+// CHECK: call void (%{{.+}}*, i{{[0-9]+}}, void (i{{[0-9]+}}*, i{{[0-9]+}}*, ...)*, ...) @__kmpc_fork_call(%{{.+}}* @{{.+}}, i{{[0-9]+}} 3, void (i{{[0-9]+}}*, i{{[0-9]+}}*, ...)* bitcast (void (i{{[0-9]+}}*, i{{[0-9]+}}*, i64, i64, i32*)* [[MAIN_MICROTASK3:@.+]] to void
 // CHECK: call void (%{{.+}}*, i{{[0-9]+}}, void (i{{[0-9]+}}*, i{{[0-9]+}}*, ...)*, ...) @__kmpc_fork_call(%{{.+}}* @{{.+}}, i{{[0-9]+}} 1, void (i{{[0-9]+}}*, i{{[0-9]+}}*, ...)* bitcast (void (i{{[0-9]+}}*, i{{[0-9]+}}*, [[S_FLOAT_TY]]***)* [[MAIN_MICROTASK4:@.+]] to void
 // CHECK: call void (%{{.+}}*, i{{[0-9]+}}, void (i{{[0-9]+}}*, i{{[0-9]+}}*, ...)*, ...) @__kmpc_fork_call(%{{.+}}* @{{.+}}, i{{[0-9]+}} 1, void (i{{[0-9]+}}*, i{{[0-9]+}}*, ...)* bitcast (void (i{{[0-9]+}}*, i{{[0-9]+}}*, [[S_FLOAT_TY]]***)* [[MAIN_MICROTASK5:@.+]] to void
 // CHECK: call void (%{{.+}}*, i{{[0-9]+}}, void (i{{[0-9]+}}*, i{{[0-9]+}}*, ...)*, ...) @__kmpc_fork_call(%{{.+}}* @{{.+}}, i{{[0-9]+}} 1, void (i{{[0-9]+}}*, i{{[0-9]+}}*, ...)* bitcast (void (i{{[0-9]+}}*, i{{[0-9]+}}*, [[S_FLOAT_TY]]***)* [[MAIN_MICROTASK6:@.+]] to void
-// CHECK: call void (%{{.+}}*, i{{[0-9]+}}, void (i{{[0-9]+}}*, i{{[0-9]+}}*, ...)*, ...) @__kmpc_fork_call(%{{.+}}* @{{.+}}, i{{[0-9]+}} 1, void (i{{[0-9]+}}*, i{{[0-9]+}}*, ...)* bitcast (void (i{{[0-9]+}}*, i{{[0-9]+}}*, [5 x [[S_FLOAT_TY]]]*)* [[MAIN_MICROTASK7:@.+]] to void
-// CHECK: call void (%{{.+}}*, i{{[0-9]+}}, void (i{{[0-9]+}}*, i{{[0-9]+}}*, ...)*, ...) @__kmpc_fork_call(%{{.+}}* @{{.+}}, i{{[0-9]+}} 1, void (i{{[0-9]+}}*, i{{[0-9]+}}*, ...)* bitcast (void (i{{[0-9]+}}*, i{{[0-9]+}}*, [4 x [[S_FLOAT_TY]]]*)* [[MAIN_MICROTASK8:@.+]] to void
+// CHECK: call void (%{{.+}}*, i{{[0-9]+}}, void (i{{[0-9]+}}*, i{{[0-9]+}}*, ...)*, ...) @__kmpc_fork_call(%{{.+}}* @{{.+}}, i{{[0-9]+}} 1, void (i{{[0-9]+}}*, i{{[0-9]+}}*, ...)* bitcast (void (i{{[0-9]+}}*, i{{[0-9]+}}*, [[S_FLOAT_TY]]***)* [[MAIN_MICROTASK7:@.+]] to void
+// CHECK: call void (%{{.+}}*, i{{[0-9]+}}, void (i{{[0-9]+}}*, i{{[0-9]+}}*, ...)*, ...) @__kmpc_fork_call(%{{.+}}* @{{.+}}, i{{[0-9]+}} 1, void (i{{[0-9]+}}*, i{{[0-9]+}}*, ...)* bitcast (void (i{{[0-9]+}}*, i{{[0-9]+}}*, [5 x [[S_FLOAT_TY]]]*)* [[MAIN_MICROTASK8:@.+]] to void
 // CHECK: call void (%{{.+}}*, i{{[0-9]+}}, void (i{{[0-9]+}}*, i{{[0-9]+}}*, ...)*, ...) @__kmpc_fork_call(%{{.+}}* @{{.+}}, i{{[0-9]+}} 1, void (i{{[0-9]+}}*, i{{[0-9]+}}*, ...)* bitcast (void (i{{[0-9]+}}*, i{{[0-9]+}}*, [4 x [[S_FLOAT_TY]]]*)* [[MAIN_MICROTASK9:@.+]] to void
 // CHECK: call void (%{{.+}}*, i{{[0-9]+}}, void (i{{[0-9]+}}*, i{{[0-9]+}}*, ...)*, ...) @__kmpc_fork_call(%{{.+}}* @{{.+}}, i{{[0-9]+}} 1, void (i{{[0-9]+}}*, i{{[0-9]+}}*, ...)* bitcast (void (i{{[0-9]+}}*, i{{[0-9]+}}*, [4 x [[S_FLOAT_TY]]]*)* [[MAIN_MICROTASK10:@.+]] to void
 // CHECK: call void (%{{.+}}*, i

[PATCH] D39505: [OpenMP] Show error if VLAs are not supported

2017-11-01 Thread Jonas Hahnfeld via Phabricator via cfe-commits
Hahnfeld created this revision.
Herald added a subscriber: jholewinski.

Some target devices (e.g. Nvidia GPUs) don't support dynamic stack
allocation and hence no VLAs. Print errors with description instead
of failing in the backend or generating code that doesn't work.

This patch handles explicit uses of VLAs (local variable in target
or declare target region) or implicitly generated (private) VLAs
for reductions on VLAs or on array sections with non-constant size.


https://reviews.llvm.org/D39505

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/TargetInfo.h
  include/clang/Sema/Sema.h
  lib/Basic/TargetInfo.cpp
  lib/Basic/Targets/NVPTX.cpp
  lib/Basic/Targets/SPIR.h
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/SemaType.cpp
  test/OpenMP/target_vla_messages.c

Index: test/OpenMP/target_vla_messages.c
===
--- /dev/null
+++ test/OpenMP/target_vla_messages.c
@@ -0,0 +1,191 @@
+// PowerPC supports VLAs.
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown -fopenmp-targets=powerpc64le-unknown-unknown -emit-llvm-bc %s -o %t-ppc-host-ppc.bc
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown -fopenmp-targets=powerpc64le-unknown-unknown -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host-ppc.bc -o %t-ppc-device.ll
+
+// Nvidia GPUs don't support VLAs.
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm-bc %s -o %t-ppc-host-nvptx.bc
+// RUN: %clang_cc1 -verify -DNO_VLA -fopenmp -x c++ -triple nvptx64-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host-nvptx.bc -o %t-nvptx-device.ll
+
+#ifndef NO_VLA
+// expected-no-diagnostics
+#endif
+
+#pragma omp declare target
+void declare(int arg) {
+  int a[2];
+#ifdef NO_VLA
+  // expected-error@+3 {{cannot use variable-length array in a declare target region}}
+  // expected-note@+2 {{the target device does not support allocating variable-length arrays}}
+#endif
+  int vla[arg];
+}
+
+void declare_parallel_reduction(int arg) {
+  int a[2];
+
+#pragma omp parallel reduction(+: a)
+  { }
+
+#pragma omp parallel reduction(+: a[0:2])
+  { }
+
+#ifdef NO_VLA
+  // expected-error@+3 {{cannot generate code for reduction on array section, which requires a variable-length array}}
+  // expected-note@+2 {{the target device does not support allocating variable-length arrays}}
+#endif
+#pragma omp parallel reduction(+: a[0:arg])
+  { }
+}
+#pragma omp end declare target
+
+void target(int arg) {
+#pragma omp target
+  {
+#ifdef NO_VLA
+// expected-error@+3 {{cannot use variable-length array in a target region}}
+// expected-note@+2 {{the target device does not support allocating variable-length arrays}}
+#endif
+int vla[arg];
+  }
+
+#pragma omp target
+  {
+#pragma omp parallel
+{
+#ifdef NO_VLA
+  // expected-error@+3 {{cannot use variable-length array in a target region}}
+  // expected-note@+2 {{the target device does not support allocating variable-length arrays}}
+#endif
+  int vla[arg];
+}
+  }
+}
+
+void teams_reduction(int arg) {
+  int a[2];
+  int vla[arg];
+
+#pragma omp target map(a)
+#pragma omp teams reduction(+: a)
+  { }
+
+#ifdef NO_VLA
+  // expected-error@+4 {{cannot generate code for reduction on variable-length array}}
+  // expected-note@+3 {{the target device does not support allocating variable-length arrays}}
+#endif
+#pragma omp target map(vla)
+#pragma omp teams reduction(+: vla)
+  { }
+  
+#pragma omp target map(a[0:2])
+#pragma omp teams reduction(+: a[0:2])
+  { }
+
+#pragma omp target map(vla[0:2])
+#pragma omp teams reduction(+: vla[0:2])
+  { }
+
+#ifdef NO_VLA
+  // expected-error@+4 {{cannot generate code for reduction on array section, which requires a variable-length array}}
+  // expected-note@+3 {{the target device does not support allocating variable-length arrays}}
+#endif
+#pragma omp target map(a[0:arg])
+#pragma omp teams reduction(+: a[0:arg])
+  { }
+
+#ifdef NO_VLA
+  // expected-error@+4 {{cannot generate code for reduction on array section, which requires a variable-length array}}
+  // expected-note@+3 {{the target device does not support allocating variable-length arrays}}
+#endif
+#pragma omp target map(vla[0:arg])
+#pragma omp teams reduction(+: vla[0:arg])
+  { }
+}
+
+void parallel_reduction(int arg) {
+  int a[2];
+  int vla[arg];
+
+#pragma omp target map(a)
+#pragma omp parallel reduction(+: a)
+  { }
+
+#ifdef NO_VLA
+  // expected-error@+4 {{cannot generate code for reduction on variable-length array}}
+  // expected-note@+3 {{the target device does not support allocating variable-length arrays}}
+#endif
+#pragma omp target map(vla)
+#pragma omp parallel reduction(+: vla)
+  { }
+
+#pragma omp target map(a[0:2])
+#pragma omp parallel reduction(+: a[0:2])
+  { }
+
+#pragma omp target map(

[PATCH] D39504: [OpenMP] Extend "Avoid VLAs for reduction" optimization to VLAs as base

2017-11-01 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev accepted this revision.
ABataev added a comment.
This revision is now accepted and ready to land.

LG


https://reviews.llvm.org/D39504



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


[PATCH] D39279: Stringizing raw string literals containing newline

2017-11-01 Thread Taewook Oh via Phabricator via cfe-commits
twoh added a comment.

Ping. Thanks!


https://reviews.llvm.org/D39279



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


[PATCH] D39502: [Driver] Make clang/cc conforms to UNIX standard

2017-11-01 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith added a comment.

I have a few nitpicks, but otherwise this LGTM.  I'd like to wait for someone 
on the CUDA side to confirm though.




Comment at: lib/Driver/Compilation.cpp:185
 
-void Compilation::ExecuteJobs(
-const JobList &Jobs,
-SmallVectorImpl> &FailingCommands) const {
+typedef SmallVectorImpl< std::pair > FailingCommandList;
+

Have you run clang-format-diff.py on your patch?  There's some funny whitespace 
here.

Also, you might consider splitting this out in a separate NFC commit.



Comment at: lib/Driver/Compilation.cpp:193-196
+  for (FailingCommandList::const_iterator CI = FailingCommands.begin(),
+ CE = FailingCommands.end(); CI != CE; ++CI)
+if (A == &(CI->second->getSource()))
+  return true;

Ranged-based `for` seems better here:
```
for (const auto &CI : FailingCommands)
  if (A == &CI.second->getSource())
return true;
```



Comment at: lib/Driver/Compilation.cpp:218
   FailingCommands.push_back(std::make_pair(Res, FailingCommand));
-  // Bail as soon as one command fails, so we don't output duplicate error
-  // messages if we die on e.g. the same file.
-  return;
+  // Bail on error in cl mode.
+  if (TheDriver.IsCLMode())

I think the longer comment was useful; just tweak it to be cl-mode-specific.



Comment at: test/Driver/output-file-cleanup.c:53-58
 // RUN: not %clang -S %t-dir/1.c %t-dir/2.c %t-dir/3.c %t-dir/4.c %t-dir/5.c
 // RUN: test -f %t-dir/1.s
 // RUN: test ! -f %t-dir/2.s
-// RUN: test ! -f %t-dir/3.s
+// RUN: test -f %t-dir/3.s
 // RUN: test ! -f %t-dir/4.s
+// RUN: test -f %t-dir/5.s

IIRC, the tests were like this before, and then they were changed as convenient 
when the CUDA code was introduced.  I suggest adding a comment around here 
explaining *why* we expect 3.s and 5.s to exist (i.e., for UNIX conformance of 
the cc/c89/c99 aliases) so that the behaviour isn't changed again in the future 
without careful consideration.


https://reviews.llvm.org/D39502



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


[PATCH] D39509: Vary toolchain selection by -fused-ld

2017-11-01 Thread Dave Lee via Phabricator via cfe-commits
kastiglione created this revision.

This change allows binutils to be used for linking with MSVC. Currently, when
using an MSVC target and `-fuse-ld=bfd`, the driver produces an invalid linker
invocation.


https://reviews.llvm.org/D39509

Files:
  lib/Driver/Driver.cpp
  test/Driver/Inputs/Windows/usr/bin/ld.bfd
  test/Driver/fuse-ld.c


Index: test/Driver/fuse-ld.c
===
--- test/Driver/fuse-ld.c
+++ test/Driver/fuse-ld.c
@@ -67,3 +67,23 @@
 // RUN: -gcc-toolchain %S/Inputs/basic_android_tree 2>&1 \
 // RUN:   | FileCheck %s -check-prefix=CHECK-ANDROID-ARM-GOLD-TC
 // CHECK-ANDROID-ARM-GOLD-TC: 
Inputs/basic_android_tree/lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin{{/|\\+}}ld.gold
+
+
+// RUN: %clang %s -### -fuse-ld=link \
+// RUN: -target i686-unknown-windows-msvc 2>&1 \
+// RUN:   | FileCheck %s --check-prefix CHECK-WINDOWS-MSVC-LINK
+// CHECK-WINDOWS-MSVC-LINK: "{{.*}}link.exe"
+// CHECK-WINDOWS-MSVC-LINK-SAME: "-out:{{.*}}"
+
+// RUN: %clang %s -### -fuse-ld=lld \
+// RUN: -target i686-unknown-windows-msvc 2>&1 \
+// RUN:   | FileCheck %s --check-prefix CHECK-WINDOWS-MSVC-LLD
+// CHECK-WINDOWS-MSVC-LLD: "{{.*}}lld-link"
+// CHECK-WINDOWS-MSVC-LLD-SAME: "-out:{{.*}}"
+
+// RUN: %clang %s -### -fuse-ld=bfd \
+// RUN: -target i686-unknown-windows-msvc \
+// RUN: -B %S/Inputs/Windows/usr/bin 2>&1 \
+// RUN:   | FileCheck %s --check-prefix CHECK-WINDOWS-MSVC-BFD
+// CHECK-WINDOWS-MSVC-BFD: "{{.*}}ld.bfd"
+// CHECK-WINDOWS-MSVC-BFD-SAME: "-o"
Index: lib/Driver/Driver.cpp
===
--- lib/Driver/Driver.cpp
+++ lib/Driver/Driver.cpp
@@ -3880,7 +3880,13 @@
 break;
   case llvm::Triple::MSVC:
   case llvm::Triple::UnknownEnvironment:
-TC = llvm::make_unique(*this, Target, Args);
+const auto A = Args.getLastArgValue(options::OPT_fuse_ld_EQ);
+if (A.equals_lower("link") || A.equals_lower("lld"))
+  TC =
+  llvm::make_unique(*this, Target, 
Args);
+else
+  TC = llvm::make_unique(
+  *this, Target, Args);
 break;
   }
   break;


Index: test/Driver/fuse-ld.c
===
--- test/Driver/fuse-ld.c
+++ test/Driver/fuse-ld.c
@@ -67,3 +67,23 @@
 // RUN: -gcc-toolchain %S/Inputs/basic_android_tree 2>&1 \
 // RUN:   | FileCheck %s -check-prefix=CHECK-ANDROID-ARM-GOLD-TC
 // CHECK-ANDROID-ARM-GOLD-TC: Inputs/basic_android_tree/lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin{{/|\\+}}ld.gold
+
+
+// RUN: %clang %s -### -fuse-ld=link \
+// RUN: -target i686-unknown-windows-msvc 2>&1 \
+// RUN:   | FileCheck %s --check-prefix CHECK-WINDOWS-MSVC-LINK
+// CHECK-WINDOWS-MSVC-LINK: "{{.*}}link.exe"
+// CHECK-WINDOWS-MSVC-LINK-SAME: "-out:{{.*}}"
+
+// RUN: %clang %s -### -fuse-ld=lld \
+// RUN: -target i686-unknown-windows-msvc 2>&1 \
+// RUN:   | FileCheck %s --check-prefix CHECK-WINDOWS-MSVC-LLD
+// CHECK-WINDOWS-MSVC-LLD: "{{.*}}lld-link"
+// CHECK-WINDOWS-MSVC-LLD-SAME: "-out:{{.*}}"
+
+// RUN: %clang %s -### -fuse-ld=bfd \
+// RUN: -target i686-unknown-windows-msvc \
+// RUN: -B %S/Inputs/Windows/usr/bin 2>&1 \
+// RUN:   | FileCheck %s --check-prefix CHECK-WINDOWS-MSVC-BFD
+// CHECK-WINDOWS-MSVC-BFD: "{{.*}}ld.bfd"
+// CHECK-WINDOWS-MSVC-BFD-SAME: "-o"
Index: lib/Driver/Driver.cpp
===
--- lib/Driver/Driver.cpp
+++ lib/Driver/Driver.cpp
@@ -3880,7 +3880,13 @@
 break;
   case llvm::Triple::MSVC:
   case llvm::Triple::UnknownEnvironment:
-TC = llvm::make_unique(*this, Target, Args);
+const auto A = Args.getLastArgValue(options::OPT_fuse_ld_EQ);
+if (A.equals_lower("link") || A.equals_lower("lld"))
+  TC =
+  llvm::make_unique(*this, Target, Args);
+else
+  TC = llvm::make_unique(
+  *this, Target, Args);
 break;
   }
   break;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[libcxx] r317124 - [libc++] Don't alias quick_exit if __ANDROID_API__ < 21

2017-11-01 Thread Dan Albert via cfe-commits
Author: danalbert
Date: Wed Nov  1 14:17:56 2017
New Revision: 317124

URL: http://llvm.org/viewvc/llvm-project?rev=317124&view=rev
Log:
[libc++] Don't alias quick_exit if __ANDROID_API__ < 21

Summary:
quick_exit() and at_quick_exit() were introduced in android NDK 21:
https://android.googlesource.com/platform/prebuilts/ndk/+/dev/platform/sysroot/usr/include/stdlib.h#55

This CL conditions `_LIBCPP_HAS_QUICK_EXIT` on `__ANDROID_API__ >= 21`.  The 
only place this macro is used is in some using declarations: `using 
::quick_exit`, `using ::at_quick_exit`.

Also, add a missing include to sys/cdefs.h which is what defines `__BIONIC__`.

Reviewers: thakis, danalbert, EricWF

Reviewed By: danalbert

Subscribers: srhines, krytarowski

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

Modified:
libcxx/trunk/include/__config

Modified: libcxx/trunk/include/__config
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config?rev=317124&r1=317123&r2=317124&view=diff
==
--- libcxx/trunk/include/__config (original)
+++ libcxx/trunk/include/__config Wed Nov  1 14:17:56 2017
@@ -296,6 +296,10 @@
 #define _LIBCPP_NO_CFI
 #endif
 
+#if __libcpp_has_include()
+#include 
+#endif
+
 #if defined(_LIBCPP_COMPILER_CLANG)
 
 // _LIBCPP_ALTERNATE_STRING_LAYOUT is an old name for
@@ -407,7 +411,7 @@ typedef __char32_t char32_t;
 #define _LIBCPP_HAS_C11_FEATURES
 #elif defined(__linux__)
 #if !defined(_LIBCPP_HAS_MUSL_LIBC)
-#if __GLIBC_PREREQ(2, 15) || defined(__BIONIC__)
+#if __GLIBC_PREREQ(2, 15) || (defined(__BIONIC__) && (__ANDROID_API__ >= 21))
 #define _LIBCPP_HAS_QUICK_EXIT
 #endif
 #if __GLIBC_PREREQ(2, 17)


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


[libunwind] r317125 - [libunwind] Don't use dl_iterate_phdr if __ANDROID_API__ < 21

2017-11-01 Thread Dan Albert via cfe-commits
Author: danalbert
Date: Wed Nov  1 14:26:06 2017
New Revision: 317125

URL: http://llvm.org/viewvc/llvm-project?rev=317125&view=rev
Log:
[libunwind] Don't use dl_iterate_phdr if __ANDROID_API__ < 21

Summary:
On ARM, dl_iterate_phdr is only implemented in the Android NDK version 21 or 
later:
https://android.googlesource.com/platform/prebuilts/ndk/+/dev/platform/sysroot/usr/include/link.h#55

Reviewers: thakis, danalbert

Reviewed By: danalbert

Subscribers: dtzWill, aemerson, srhines, kristof.beyls

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

Modified:
libunwind/trunk/src/AddressSpace.hpp

Modified: libunwind/trunk/src/AddressSpace.hpp
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/src/AddressSpace.hpp?rev=317125&r1=317124&r2=317125&view=diff
==
--- libunwind/trunk/src/AddressSpace.hpp (original)
+++ libunwind/trunk/src/AddressSpace.hpp Wed Nov  1 14:26:06 2017
@@ -393,6 +393,14 @@ inline bool LocalAddressSpace::findUnwin
 }
   }
   return false;
+#elif defined(_LIBUNWIND_ARM_EHABI) && defined(__BIONIC__) &&  
\
+(__ANDROID_API__ < 21)
+  int length = 0;
+  info.arm_section =
+  (uintptr_t)dl_unwind_find_exidx((_Unwind_Ptr)targetAddr, &length);
+  info.arm_section_length = (uintptr_t)length;
+  if (info.arm_section && info.arm_section_length)
+return true;
 #elif defined(_LIBUNWIND_ARM_EHABI) || defined(_LIBUNWIND_SUPPORT_DWARF_UNWIND)
   struct dl_iterate_cb_data {
 LocalAddressSpace *addressSpace;


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


[PATCH] D39509: Vary Windows toolchain selection by -fused-ld

2017-11-01 Thread Dave Lee via Phabricator via cfe-commits
kastiglione updated this revision to Diff 121185.
kastiglione added a comment.

Use "link" as default when inspecting -fuse-ld=


https://reviews.llvm.org/D39509

Files:
  lib/Driver/Driver.cpp
  test/Driver/Inputs/Windows/usr/bin/ld.bfd
  test/Driver/fuse-ld.c


Index: test/Driver/fuse-ld.c
===
--- test/Driver/fuse-ld.c
+++ test/Driver/fuse-ld.c
@@ -67,3 +67,23 @@
 // RUN: -gcc-toolchain %S/Inputs/basic_android_tree 2>&1 \
 // RUN:   | FileCheck %s -check-prefix=CHECK-ANDROID-ARM-GOLD-TC
 // CHECK-ANDROID-ARM-GOLD-TC: 
Inputs/basic_android_tree/lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin{{/|\\+}}ld.gold
+
+
+// RUN: %clang %s -### -fuse-ld=link \
+// RUN: -target i686-unknown-windows-msvc 2>&1 \
+// RUN:   | FileCheck %s --check-prefix CHECK-WINDOWS-MSVC-LINK
+// CHECK-WINDOWS-MSVC-LINK: "{{.*}}link.exe"
+// CHECK-WINDOWS-MSVC-LINK-SAME: "-out:{{.*}}"
+
+// RUN: %clang %s -### -fuse-ld=lld \
+// RUN: -target i686-unknown-windows-msvc 2>&1 \
+// RUN:   | FileCheck %s --check-prefix CHECK-WINDOWS-MSVC-LLD
+// CHECK-WINDOWS-MSVC-LLD: "{{.*}}lld-link"
+// CHECK-WINDOWS-MSVC-LLD-SAME: "-out:{{.*}}"
+
+// RUN: %clang %s -### -fuse-ld=bfd \
+// RUN: -target i686-unknown-windows-msvc \
+// RUN: -B %S/Inputs/Windows/usr/bin 2>&1 \
+// RUN:   | FileCheck %s --check-prefix CHECK-WINDOWS-MSVC-BFD
+// CHECK-WINDOWS-MSVC-BFD: "{{.*}}ld.bfd"
+// CHECK-WINDOWS-MSVC-BFD-SAME: "-o"
Index: lib/Driver/Driver.cpp
===
--- lib/Driver/Driver.cpp
+++ lib/Driver/Driver.cpp
@@ -3880,7 +3880,13 @@
 break;
   case llvm::Triple::MSVC:
   case llvm::Triple::UnknownEnvironment:
-TC = llvm::make_unique(*this, Target, Args);
+const auto A = Args.getLastArgValue(options::OPT_fuse_ld_EQ, "link");
+if (A.equals_lower("link") || A.equals_lower("lld"))
+  TC =
+  llvm::make_unique(*this, Target, 
Args);
+else
+  TC = llvm::make_unique(
+  *this, Target, Args);
 break;
   }
   break;


Index: test/Driver/fuse-ld.c
===
--- test/Driver/fuse-ld.c
+++ test/Driver/fuse-ld.c
@@ -67,3 +67,23 @@
 // RUN: -gcc-toolchain %S/Inputs/basic_android_tree 2>&1 \
 // RUN:   | FileCheck %s -check-prefix=CHECK-ANDROID-ARM-GOLD-TC
 // CHECK-ANDROID-ARM-GOLD-TC: Inputs/basic_android_tree/lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin{{/|\\+}}ld.gold
+
+
+// RUN: %clang %s -### -fuse-ld=link \
+// RUN: -target i686-unknown-windows-msvc 2>&1 \
+// RUN:   | FileCheck %s --check-prefix CHECK-WINDOWS-MSVC-LINK
+// CHECK-WINDOWS-MSVC-LINK: "{{.*}}link.exe"
+// CHECK-WINDOWS-MSVC-LINK-SAME: "-out:{{.*}}"
+
+// RUN: %clang %s -### -fuse-ld=lld \
+// RUN: -target i686-unknown-windows-msvc 2>&1 \
+// RUN:   | FileCheck %s --check-prefix CHECK-WINDOWS-MSVC-LLD
+// CHECK-WINDOWS-MSVC-LLD: "{{.*}}lld-link"
+// CHECK-WINDOWS-MSVC-LLD-SAME: "-out:{{.*}}"
+
+// RUN: %clang %s -### -fuse-ld=bfd \
+// RUN: -target i686-unknown-windows-msvc \
+// RUN: -B %S/Inputs/Windows/usr/bin 2>&1 \
+// RUN:   | FileCheck %s --check-prefix CHECK-WINDOWS-MSVC-BFD
+// CHECK-WINDOWS-MSVC-BFD: "{{.*}}ld.bfd"
+// CHECK-WINDOWS-MSVC-BFD-SAME: "-o"
Index: lib/Driver/Driver.cpp
===
--- lib/Driver/Driver.cpp
+++ lib/Driver/Driver.cpp
@@ -3880,7 +3880,13 @@
 break;
   case llvm::Triple::MSVC:
   case llvm::Triple::UnknownEnvironment:
-TC = llvm::make_unique(*this, Target, Args);
+const auto A = Args.getLastArgValue(options::OPT_fuse_ld_EQ, "link");
+if (A.equals_lower("link") || A.equals_lower("lld"))
+  TC =
+  llvm::make_unique(*this, Target, Args);
+else
+  TC = llvm::make_unique(
+  *this, Target, Args);
 break;
   }
   break;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D39509: Vary Windows toolchain selection by -fused-ld

2017-11-01 Thread Shoaib Meenai via Phabricator via cfe-commits
smeenai added inline comments.



Comment at: lib/Driver/Driver.cpp:3884
+const auto A = Args.getLastArgValue(options::OPT_fuse_ld_EQ, "link");
+if (A.equals_lower("link") || A.equals_lower("lld"))
+  TC =

`lld-link` is a valid invocation for LLD as well, so I'd either add that 
option, change the equality option to a start check, or invert the check and 
check for an `-fuse-ld=` option starting with `bfd` (since we want the MSVC 
toolchain to be the default).


https://reviews.llvm.org/D39509



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


[PATCH] D39509: Vary Windows toolchain selection by -fused-ld

2017-11-01 Thread Shoaib Meenai via Phabricator via cfe-commits
smeenai added a comment.

Also title says `-fused-ld` instead of `-fuse-ld`


https://reviews.llvm.org/D39509



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


[PATCH] D39509: Vary Windows toolchain selection by -fuse-ld

2017-11-01 Thread Dave Lee via Phabricator via cfe-commits
kastiglione updated this revision to Diff 121194.
kastiglione added a comment.

Base decision on "bfd" prefix


https://reviews.llvm.org/D39509

Files:
  lib/Driver/Driver.cpp
  test/Driver/Inputs/Windows/usr/bin/ld.bfd
  test/Driver/fuse-ld.c


Index: test/Driver/fuse-ld.c
===
--- test/Driver/fuse-ld.c
+++ test/Driver/fuse-ld.c
@@ -67,3 +67,29 @@
 // RUN: -gcc-toolchain %S/Inputs/basic_android_tree 2>&1 \
 // RUN:   | FileCheck %s -check-prefix=CHECK-ANDROID-ARM-GOLD-TC
 // CHECK-ANDROID-ARM-GOLD-TC: 
Inputs/basic_android_tree/lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin{{/|\\+}}ld.gold
+
+
+// RUN: %clang %s -### -fuse-ld=link \
+// RUN: -target i686-unknown-windows-msvc 2>&1 \
+// RUN:   | FileCheck %s --check-prefix CHECK-WINDOWS-MSVC-LINK
+// CHECK-WINDOWS-MSVC-LINK: "{{.*}}link.exe"
+// CHECK-WINDOWS-MSVC-LINK-SAME: "-out:{{.*}}"
+
+// RUN: %clang %s -### -fuse-ld=lld \
+// RUN: -target i686-unknown-windows-msvc 2>&1 \
+// RUN:   | FileCheck %s --check-prefix CHECK-WINDOWS-MSVC-LLD
+// CHECK-WINDOWS-MSVC-LLD: "{{.*}}lld-link"
+// CHECK-WINDOWS-MSVC-LLD-SAME: "-out:{{.*}}"
+
+// RUN: %clang %s -### -fuse-ld=lld-link \
+// RUN: -target i686-unknown-windows-msvc 2>&1 \
+// RUN:   | FileCheck %s --check-prefix CHECK-WINDOWS-MSVC-LLD-LINK
+// CHECK-WINDOWS-MSVC-LLD-LINK: "{{.*}}lld-link"
+// CHECK-WINDOWS-MSVC-LLD-LINK-SAME: "-out:{{.*}}"
+
+// RUN: %clang %s -### -fuse-ld=bfd \
+// RUN: -target i686-unknown-windows-msvc \
+// RUN: -B %S/Inputs/Windows/usr/bin 2>&1 \
+// RUN:   | FileCheck %s --check-prefix CHECK-WINDOWS-MSVC-BFD
+// CHECK-WINDOWS-MSVC-BFD: "{{.*}}ld.bfd"
+// CHECK-WINDOWS-MSVC-BFD-SAME: "-o"
Index: lib/Driver/Driver.cpp
===
--- lib/Driver/Driver.cpp
+++ lib/Driver/Driver.cpp
@@ -3880,7 +3880,13 @@
 break;
   case llvm::Triple::MSVC:
   case llvm::Triple::UnknownEnvironment:
-TC = llvm::make_unique(*this, Target, Args);
+const auto A = Args.getLastArgValue(options::OPT_fuse_ld_EQ, "link");
+if (A.startswith_lower("bfd"))
+  TC = llvm::make_unique(
+  *this, Target, Args);
+else
+  TC =
+  llvm::make_unique(*this, Target, 
Args);
 break;
   }
   break;


Index: test/Driver/fuse-ld.c
===
--- test/Driver/fuse-ld.c
+++ test/Driver/fuse-ld.c
@@ -67,3 +67,29 @@
 // RUN: -gcc-toolchain %S/Inputs/basic_android_tree 2>&1 \
 // RUN:   | FileCheck %s -check-prefix=CHECK-ANDROID-ARM-GOLD-TC
 // CHECK-ANDROID-ARM-GOLD-TC: Inputs/basic_android_tree/lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin{{/|\\+}}ld.gold
+
+
+// RUN: %clang %s -### -fuse-ld=link \
+// RUN: -target i686-unknown-windows-msvc 2>&1 \
+// RUN:   | FileCheck %s --check-prefix CHECK-WINDOWS-MSVC-LINK
+// CHECK-WINDOWS-MSVC-LINK: "{{.*}}link.exe"
+// CHECK-WINDOWS-MSVC-LINK-SAME: "-out:{{.*}}"
+
+// RUN: %clang %s -### -fuse-ld=lld \
+// RUN: -target i686-unknown-windows-msvc 2>&1 \
+// RUN:   | FileCheck %s --check-prefix CHECK-WINDOWS-MSVC-LLD
+// CHECK-WINDOWS-MSVC-LLD: "{{.*}}lld-link"
+// CHECK-WINDOWS-MSVC-LLD-SAME: "-out:{{.*}}"
+
+// RUN: %clang %s -### -fuse-ld=lld-link \
+// RUN: -target i686-unknown-windows-msvc 2>&1 \
+// RUN:   | FileCheck %s --check-prefix CHECK-WINDOWS-MSVC-LLD-LINK
+// CHECK-WINDOWS-MSVC-LLD-LINK: "{{.*}}lld-link"
+// CHECK-WINDOWS-MSVC-LLD-LINK-SAME: "-out:{{.*}}"
+
+// RUN: %clang %s -### -fuse-ld=bfd \
+// RUN: -target i686-unknown-windows-msvc \
+// RUN: -B %S/Inputs/Windows/usr/bin 2>&1 \
+// RUN:   | FileCheck %s --check-prefix CHECK-WINDOWS-MSVC-BFD
+// CHECK-WINDOWS-MSVC-BFD: "{{.*}}ld.bfd"
+// CHECK-WINDOWS-MSVC-BFD-SAME: "-o"
Index: lib/Driver/Driver.cpp
===
--- lib/Driver/Driver.cpp
+++ lib/Driver/Driver.cpp
@@ -3880,7 +3880,13 @@
 break;
   case llvm::Triple::MSVC:
   case llvm::Triple::UnknownEnvironment:
-TC = llvm::make_unique(*this, Target, Args);
+const auto A = Args.getLastArgValue(options::OPT_fuse_ld_EQ, "link");
+if (A.startswith_lower("bfd"))
+  TC = llvm::make_unique(
+  *this, Target, Args);
+else
+  TC =
+  llvm::make_unique(*this, Target, Args);
 break;
   }
   break;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D39509: Vary Windows toolchain selection by -fuse-ld

2017-11-01 Thread Dave Lee via Phabricator via cfe-commits
kastiglione updated this revision to Diff 121196.
kastiglione added a comment.

Inline the arg variable


https://reviews.llvm.org/D39509

Files:
  lib/Driver/Driver.cpp
  test/Driver/Inputs/Windows/usr/bin/ld.bfd
  test/Driver/fuse-ld.c


Index: test/Driver/fuse-ld.c
===
--- test/Driver/fuse-ld.c
+++ test/Driver/fuse-ld.c
@@ -67,3 +67,29 @@
 // RUN: -gcc-toolchain %S/Inputs/basic_android_tree 2>&1 \
 // RUN:   | FileCheck %s -check-prefix=CHECK-ANDROID-ARM-GOLD-TC
 // CHECK-ANDROID-ARM-GOLD-TC: 
Inputs/basic_android_tree/lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin{{/|\\+}}ld.gold
+
+
+// RUN: %clang %s -### -fuse-ld=link \
+// RUN: -target i686-unknown-windows-msvc 2>&1 \
+// RUN:   | FileCheck %s --check-prefix CHECK-WINDOWS-MSVC-LINK
+// CHECK-WINDOWS-MSVC-LINK: "{{.*}}link.exe"
+// CHECK-WINDOWS-MSVC-LINK-SAME: "-out:{{.*}}"
+
+// RUN: %clang %s -### -fuse-ld=lld \
+// RUN: -target i686-unknown-windows-msvc 2>&1 \
+// RUN:   | FileCheck %s --check-prefix CHECK-WINDOWS-MSVC-LLD
+// CHECK-WINDOWS-MSVC-LLD: "{{.*}}lld-link"
+// CHECK-WINDOWS-MSVC-LLD-SAME: "-out:{{.*}}"
+
+// RUN: %clang %s -### -fuse-ld=lld-link \
+// RUN: -target i686-unknown-windows-msvc 2>&1 \
+// RUN:   | FileCheck %s --check-prefix CHECK-WINDOWS-MSVC-LLD-LINK
+// CHECK-WINDOWS-MSVC-LLD-LINK: "{{.*}}lld-link"
+// CHECK-WINDOWS-MSVC-LLD-LINK-SAME: "-out:{{.*}}"
+
+// RUN: %clang %s -### -fuse-ld=bfd \
+// RUN: -target i686-unknown-windows-msvc \
+// RUN: -B %S/Inputs/Windows/usr/bin 2>&1 \
+// RUN:   | FileCheck %s --check-prefix CHECK-WINDOWS-MSVC-BFD
+// CHECK-WINDOWS-MSVC-BFD: "{{.*}}ld.bfd"
+// CHECK-WINDOWS-MSVC-BFD-SAME: "-o"
Index: lib/Driver/Driver.cpp
===
--- lib/Driver/Driver.cpp
+++ lib/Driver/Driver.cpp
@@ -3880,7 +3880,13 @@
 break;
   case llvm::Triple::MSVC:
   case llvm::Triple::UnknownEnvironment:
-TC = llvm::make_unique(*this, Target, Args);
+if (Args.getLastArgValue(options::OPT_fuse_ld_EQ)
+.startswith_lower("bfd"))
+  TC = llvm::make_unique(
+  *this, Target, Args);
+else
+  TC =
+  llvm::make_unique(*this, Target, 
Args);
 break;
   }
   break;


Index: test/Driver/fuse-ld.c
===
--- test/Driver/fuse-ld.c
+++ test/Driver/fuse-ld.c
@@ -67,3 +67,29 @@
 // RUN: -gcc-toolchain %S/Inputs/basic_android_tree 2>&1 \
 // RUN:   | FileCheck %s -check-prefix=CHECK-ANDROID-ARM-GOLD-TC
 // CHECK-ANDROID-ARM-GOLD-TC: Inputs/basic_android_tree/lib/gcc/arm-linux-androideabi/4.4.3/../../../../arm-linux-androideabi/bin{{/|\\+}}ld.gold
+
+
+// RUN: %clang %s -### -fuse-ld=link \
+// RUN: -target i686-unknown-windows-msvc 2>&1 \
+// RUN:   | FileCheck %s --check-prefix CHECK-WINDOWS-MSVC-LINK
+// CHECK-WINDOWS-MSVC-LINK: "{{.*}}link.exe"
+// CHECK-WINDOWS-MSVC-LINK-SAME: "-out:{{.*}}"
+
+// RUN: %clang %s -### -fuse-ld=lld \
+// RUN: -target i686-unknown-windows-msvc 2>&1 \
+// RUN:   | FileCheck %s --check-prefix CHECK-WINDOWS-MSVC-LLD
+// CHECK-WINDOWS-MSVC-LLD: "{{.*}}lld-link"
+// CHECK-WINDOWS-MSVC-LLD-SAME: "-out:{{.*}}"
+
+// RUN: %clang %s -### -fuse-ld=lld-link \
+// RUN: -target i686-unknown-windows-msvc 2>&1 \
+// RUN:   | FileCheck %s --check-prefix CHECK-WINDOWS-MSVC-LLD-LINK
+// CHECK-WINDOWS-MSVC-LLD-LINK: "{{.*}}lld-link"
+// CHECK-WINDOWS-MSVC-LLD-LINK-SAME: "-out:{{.*}}"
+
+// RUN: %clang %s -### -fuse-ld=bfd \
+// RUN: -target i686-unknown-windows-msvc \
+// RUN: -B %S/Inputs/Windows/usr/bin 2>&1 \
+// RUN:   | FileCheck %s --check-prefix CHECK-WINDOWS-MSVC-BFD
+// CHECK-WINDOWS-MSVC-BFD: "{{.*}}ld.bfd"
+// CHECK-WINDOWS-MSVC-BFD-SAME: "-o"
Index: lib/Driver/Driver.cpp
===
--- lib/Driver/Driver.cpp
+++ lib/Driver/Driver.cpp
@@ -3880,7 +3880,13 @@
 break;
   case llvm::Triple::MSVC:
   case llvm::Triple::UnknownEnvironment:
-TC = llvm::make_unique(*this, Target, Args);
+if (Args.getLastArgValue(options::OPT_fuse_ld_EQ)
+.startswith_lower("bfd"))
+  TC = llvm::make_unique(
+  *this, Target, Args);
+else
+  TC =
+  llvm::make_unique(*this, Target, Args);
 break;
   }
   break;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D39518: [analyzer] do not crash on libcxx03 call_once implementation

2017-11-01 Thread George Karpenkov via Phabricator via cfe-commits
george.karpenkov created this revision.
Herald added a reviewer: EricWF.
Herald added subscribers: szepet, xazax.hun, javed.absar.

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


https://reviews.llvm.org/D39518

Files:
  lib/Analysis/BodyFarm.cpp
  test/Analysis/call_once.cpp


Index: test/Analysis/call_once.cpp
===
--- test/Analysis/call_once.cpp
+++ test/Analysis/call_once.cpp
@@ -1,6 +1,10 @@
 // RUN: %clang_analyze_cc1 -std=c++11 -fblocks 
-analyzer-checker=core,debug.ExprInspection -verify %s
 // RUN: %clang_analyze_cc1 -std=c++11 -fblocks 
-analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBSTDCPP -verify %s
 
+// We do not emulate libcxx03 implementation, but we should not crash either.
+// RUN: %clang_analyze_cc1 -std=c++11 -fblocks -analyzer-checker=core 
-DEMULATE_LIBCXX03 %s
+// RUN: %clang_analyze_cc1 -std=c++11 -fblocks -analyzer-checker=core 
-DEMULATE_LIBCXX03 -DEMULATE_LIBSTDCPP %s
+
 void clang_analyzer_eval(bool);
 
 // Faking std::std::call_once implementation.
@@ -16,8 +20,13 @@
 } once_flag;
 #endif
 
+#ifndef EMULATE_LIBCXX03
 template 
 void call_once(once_flag &o, Callable&& func, Args&&... args) {};
+#else
+template  // libcxx03 call_once
+void call_once(once_flag &o, Callable func, Args...) {};
+#endif
 
 } // namespace std
 
Index: lib/Analysis/BodyFarm.cpp
===
--- lib/Analysis/BodyFarm.cpp
+++ lib/Analysis/BodyFarm.cpp
@@ -412,10 +412,15 @@
 
 CallbackCall = create_call_once_lambda_call(C, M, Callback,
 CallbackRecordDecl, CallArgs);
-  } else {
+  } else if (Callback->getType()->isRValueReferenceType()
+  || Callback->getType()->isLValueReferenceType()) {
 
 // Function pointer case.
 CallbackCall = create_call_once_funcptr_call(C, M, Callback, CallArgs);
+  } else {
+DEBUG(llvm::dbgs() << "Not a lambda expression, and not a function pointer"
+   << ", ignoring the std::call_once call.\n");
+return nullptr;
   }
 
   DeclRefExpr *FlagDecl =


Index: test/Analysis/call_once.cpp
===
--- test/Analysis/call_once.cpp
+++ test/Analysis/call_once.cpp
@@ -1,6 +1,10 @@
 // RUN: %clang_analyze_cc1 -std=c++11 -fblocks -analyzer-checker=core,debug.ExprInspection -verify %s
 // RUN: %clang_analyze_cc1 -std=c++11 -fblocks -analyzer-checker=core,debug.ExprInspection -DEMULATE_LIBSTDCPP -verify %s
 
+// We do not emulate libcxx03 implementation, but we should not crash either.
+// RUN: %clang_analyze_cc1 -std=c++11 -fblocks -analyzer-checker=core -DEMULATE_LIBCXX03 %s
+// RUN: %clang_analyze_cc1 -std=c++11 -fblocks -analyzer-checker=core -DEMULATE_LIBCXX03 -DEMULATE_LIBSTDCPP %s
+
 void clang_analyzer_eval(bool);
 
 // Faking std::std::call_once implementation.
@@ -16,8 +20,13 @@
 } once_flag;
 #endif
 
+#ifndef EMULATE_LIBCXX03
 template 
 void call_once(once_flag &o, Callable&& func, Args&&... args) {};
+#else
+template  // libcxx03 call_once
+void call_once(once_flag &o, Callable func, Args...) {};
+#endif
 
 } // namespace std
 
Index: lib/Analysis/BodyFarm.cpp
===
--- lib/Analysis/BodyFarm.cpp
+++ lib/Analysis/BodyFarm.cpp
@@ -412,10 +412,15 @@
 
 CallbackCall = create_call_once_lambda_call(C, M, Callback,
 CallbackRecordDecl, CallArgs);
-  } else {
+  } else if (Callback->getType()->isRValueReferenceType()
+  || Callback->getType()->isLValueReferenceType()) {
 
 // Function pointer case.
 CallbackCall = create_call_once_funcptr_call(C, M, Callback, CallArgs);
+  } else {
+DEBUG(llvm::dbgs() << "Not a lambda expression, and not a function pointer"
+   << ", ignoring the std::call_once call.\n");
+return nullptr;
   }
 
   DeclRefExpr *FlagDecl =
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r317137 - [ASTMatchers] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).

2017-11-01 Thread Eugene Zelenko via cfe-commits
Author: eugenezelenko
Date: Wed Nov  1 16:09:49 2017
New Revision: 317137

URL: http://llvm.org/viewvc/llvm-project?rev=317137&view=rev
Log:
[ASTMatchers] Fix some Clang-tidy modernize and Include What You Use warnings; 
other minor fixes (NFC).

Modified:
cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
cfe/trunk/include/clang/ASTMatchers/Dynamic/Parser.h
cfe/trunk/include/clang/ASTMatchers/Dynamic/Registry.h
cfe/trunk/lib/ASTMatchers/ASTMatchersInternal.cpp
cfe/trunk/lib/ASTMatchers/Dynamic/Marshallers.h
cfe/trunk/lib/ASTMatchers/Dynamic/Parser.cpp
cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp

Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h?rev=317137&r1=317136&r2=317137&view=diff
==
--- cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h (original)
+++ cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h Wed Nov  1 16:09:49 2017
@@ -1,4 +1,4 @@
-//===--- ASTMatchers.h - Structural query framework -*- C++ 
-*-===//
+//===- ASTMatchers.h - Structural query framework ---*- C++ 
-*-===//
 //
 // The LLVM Compiler Infrastructure
 //
@@ -46,13 +46,48 @@
 #define LLVM_CLANG_ASTMATCHERS_ASTMATCHERS_H
 
 #include "clang/AST/ASTContext.h"
+#include "clang/AST/ASTTypeTraits.h"
+#include "clang/AST/Attr.h"
+#include "clang/AST/Decl.h"
+#include "clang/AST/DeclCXX.h"
 #include "clang/AST/DeclFriend.h"
 #include "clang/AST/DeclObjC.h"
 #include "clang/AST/DeclTemplate.h"
+#include "clang/AST/Expr.h"
+#include "clang/AST/ExprCXX.h"
+#include "clang/AST/ExprObjC.h"
+#include "clang/AST/NestedNameSpecifier.h"
+#include "clang/AST/OperationKinds.h"
+#include "clang/AST/Stmt.h"
+#include "clang/AST/StmtCXX.h"
+#include "clang/AST/StmtObjC.h"
+#include "clang/AST/TemplateBase.h"
+#include "clang/AST/TemplateName.h"
+#include "clang/AST/Type.h"
+#include "clang/AST/TypeLoc.h"
 #include "clang/ASTMatchers/ASTMatchersInternal.h"
 #include "clang/ASTMatchers/ASTMatchersMacros.h"
+#include "clang/Basic/AttrKinds.h"
+#include "clang/Basic/ExceptionSpecificationType.h"
+#include "clang/Basic/IdentifierTable.h"
+#include "clang/Basic/LLVM.h"
+#include "clang/Basic/SourceManager.h"
+#include "clang/Basic/Specifiers.h"
+#include "clang/Basic/TypeTraits.h"
+#include "llvm/ADT/ArrayRef.h"
+#include "llvm/ADT/SmallVector.h"
+#include "llvm/ADT/StringRef.h"
+#include "llvm/Support/Casting.h"
+#include "llvm/Support/Compiler.h"
+#include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/Regex.h"
+#include 
+#include 
 #include 
+#include 
+#include 
+#include 
+#include 
 
 namespace clang {
 namespace ast_matchers {
@@ -78,7 +113,7 @@ public:
   /// \brief Type of mapping from binding identifiers to bound nodes. This type
   /// is an associative container with a key type of \c std::string and a value
   /// type of \c clang::ast_type_traits::DynTypedNode
-  typedef internal::BoundNodesMap::IDToNodeMap IDToNodeMap;
+  using IDToNodeMap = internal::BoundNodesMap::IDToNodeMap;
 
   /// \brief Retrieve mapping from binding identifiers to bound nodes.
   const IDToNodeMap &getMap() const {
@@ -86,13 +121,13 @@ public:
   }
 
 private:
+  friend class internal::BoundNodesTreeBuilder;
+
   /// \brief Create BoundNodes from a pre-filled map of bindings.
   BoundNodes(internal::BoundNodesMap &MyBoundNodes)
   : MyBoundNodes(MyBoundNodes) {}
 
   internal::BoundNodesMap MyBoundNodes;
-
-  friend class internal::BoundNodesTreeBuilder;
 };
 
 /// \brief If the provided matcher matches a node, binds the node to \c ID.
@@ -107,13 +142,13 @@ internal::Matcher id(StringRef ID,
 /// \brief Types of matchers for the top-level classes in the AST class
 /// hierarchy.
 /// @{
-typedef internal::Matcher DeclarationMatcher;
-typedef internal::Matcher StatementMatcher;
-typedef internal::Matcher TypeMatcher;
-typedef internal::Matcher TypeLocMatcher;
-typedef internal::Matcher NestedNameSpecifierMatcher;
-typedef internal::Matcher 
NestedNameSpecifierLocMatcher;
-typedef internal::Matcher CXXCtorInitializerMatcher;
+using DeclarationMatcher = internal::Matcher;
+using StatementMatcher = internal::Matcher;
+using TypeMatcher = internal::Matcher;
+using TypeLocMatcher = internal::Matcher;
+using NestedNameSpecifierMatcher = internal::Matcher;
+using NestedNameSpecifierLocMatcher = 
internal::Matcher;
+using CXXCtorInitializerMatcher = internal::Matcher;
 /// @}
 
 /// \brief Matches any node.
@@ -2186,23 +2221,23 @@ const internal::VariadicAllOfMatcher eachOf = {
-  internal::DynTypedMatcher::VO_EachOf
-};
+const internal::VariadicOperatorMatcherFunc<
+2, std::numeric_limits::max()>
+eachOf = {internal::DynTypedMatcher::VO_EachOf};
 
 /// \brief Matches if any of the given matchers matches.
 ///
 /// Usable as: Any Matcher
-const interna

[PATCH] D39520: [libcxx][CMake] Fix libc++ build when no LLVM source tree is available.

2017-11-01 Thread Volodymyr Sapsai via Phabricator via cfe-commits
vsapsai created this revision.
Herald added a subscriber: mgorny.

Fixes error

> CMake Error at test/CMakeLists.txt:52 (configure_lit_site_cfg):
>  Unknown CMake command "configure_lit_site_cfg".

configure_lit_site_cfg is defined in AddLLVM module and not available
without LLVM source tree. Revert back to configure_file (reverts part of
r313643).  It is possible as libcxx/test/lit.site.cfg.in doesn't use
latest lit capabilities.

Tested with

- in-tree libcxx - no change in generated lit.site.cfg and running tests;
- standalone libcxx with lit checked out next to it - no CMake errors.

If there are other tricky configurations worth testing, let me know.

rdar://problem/35303262


https://reviews.llvm.org/D39520

Files:
  libcxx/test/CMakeLists.txt


Index: libcxx/test/CMakeLists.txt
===
--- libcxx/test/CMakeLists.txt
+++ libcxx/test/CMakeLists.txt
@@ -49,9 +49,10 @@
 
 set(AUTO_GEN_COMMENT "## Autogenerated by libcxx configuration.\n# Do not 
edit!")
 
-configure_lit_site_cfg(
+configure_file(
   ${CMAKE_CURRENT_SOURCE_DIR}/lit.site.cfg.in
-  ${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg)
+  ${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg
+  @ONLY)
 
 set(LIBCXX_TEST_DEPS "")
 


Index: libcxx/test/CMakeLists.txt
===
--- libcxx/test/CMakeLists.txt
+++ libcxx/test/CMakeLists.txt
@@ -49,9 +49,10 @@
 
 set(AUTO_GEN_COMMENT "## Autogenerated by libcxx configuration.\n# Do not edit!")
 
-configure_lit_site_cfg(
+configure_file(
   ${CMAKE_CURRENT_SOURCE_DIR}/lit.site.cfg.in
-  ${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg)
+  ${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg
+  @ONLY)
 
 set(LIBCXX_TEST_DEPS "")
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r317140 - Fix missing -Wregister warning when 'register' is applied to a function parameter.

2017-11-01 Thread Richard Smith via cfe-commits
Author: rsmith
Date: Wed Nov  1 16:38:37 2017
New Revision: 317140

URL: http://llvm.org/viewvc/llvm-project?rev=317140&view=rev
Log:
Fix missing -Wregister warning when 'register' is applied to a function 
parameter.

Modified:
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/test/CXX/dcl.dcl/dcl.spec/dcl.stc/p2.cpp
cfe/trunk/test/SemaCXX/deprecated.cpp
cfe/trunk/test/SemaCXX/varargs.cpp

Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=317140&r1=317139&r2=317140&view=diff
==
--- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDecl.cpp Wed Nov  1 16:38:37 2017
@@ -11718,6 +11718,14 @@ Decl *Sema::ActOnParamDeclarator(Scope *
   StorageClass SC = SC_None;
   if (DS.getStorageClassSpec() == DeclSpec::SCS_register) {
 SC = SC_Register;
+// In C++11, the 'register' storage class specifier is deprecated.
+// In C++17, it is not allowed, but we tolerate it as an extension.
+if (getLangOpts().CPlusPlus11) {
+  Diag(DS.getStorageClassSpecLoc(),
+   getLangOpts().CPlusPlus1z ? diag::ext_register_storage_class
+ : diag::warn_deprecated_register)
+<< FixItHint::CreateRemoval(DS.getStorageClassSpecLoc());
+}
   } else if (getLangOpts().CPlusPlus &&
  DS.getStorageClassSpec() == DeclSpec::SCS_auto) {
 SC = SC_Auto;

Modified: cfe/trunk/test/CXX/dcl.dcl/dcl.spec/dcl.stc/p2.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CXX/dcl.dcl/dcl.spec/dcl.stc/p2.cpp?rev=317140&r1=317139&r2=317140&view=diff
==
--- cfe/trunk/test/CXX/dcl.dcl/dcl.spec/dcl.stc/p2.cpp (original)
+++ cfe/trunk/test/CXX/dcl.dcl/dcl.spec/dcl.stc/p2.cpp Wed Nov  1 16:38:37 2017
@@ -39,6 +39,7 @@ struct S {
 void foo(auto int ap, register int rp) {
 #if __cplusplus >= 201103L // C++11 or later
 // expected-warning@-2 {{'auto' storage class specifier is not permitted in 
C++11, and will not be supported in future releases}}
+// expected-warning@-3 {{'register' storage class specifier is deprecated}}
 #endif
   auto int abo;
 #if __cplusplus >= 201103L // C++11 or later

Modified: cfe/trunk/test/SemaCXX/deprecated.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/deprecated.cpp?rev=317140&r1=317139&r2=317140&view=diff
==
--- cfe/trunk/test/SemaCXX/deprecated.cpp (original)
+++ cfe/trunk/test/SemaCXX/deprecated.cpp Wed Nov  1 16:38:37 2017
@@ -20,7 +20,12 @@ void i() throw(...);
 // expected-warning@-8 {{dynamic exception specifications are deprecated}} 
expected-note@-8 {{use 'noexcept(false)' instead}}
 #endif
 
-void stuff() {
+void stuff(register int q) {
+#if __cplusplus > 201402L
+  // expected-error@-2 {{ISO C++17 does not allow 'register' storage class 
specifier}}
+#elif __cplusplus >= 201103L && !defined(NO_DEPRECATED_FLAGS)
+  // expected-warning@-4 {{'register' storage class specifier is deprecated}}
+#endif
   register int n;
 #if __cplusplus > 201402L
   // expected-error@-2 {{ISO C++17 does not allow 'register' storage class 
specifier}}

Modified: cfe/trunk/test/SemaCXX/varargs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/varargs.cpp?rev=317140&r1=317139&r2=317140&view=diff
==
--- cfe/trunk/test/SemaCXX/varargs.cpp (original)
+++ cfe/trunk/test/SemaCXX/varargs.cpp Wed Nov  1 16:38:37 2017
@@ -8,7 +8,7 @@ void f(const string& s, ...) {  // expec
   __builtin_va_start(ap, s); // expected-warning {{passing an object of 
reference type to 'va_start' has undefined behavior}}
 }
 
-void g(register int i, ...) {
+void g(register int i, ...) { // expected-warning 0-1{{deprecated}}
   __builtin_va_start(ap, i); // UB in C, OK in C++
 }
 


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


[PATCH] D39521: [x86 TargetInfo] Pull CPU handling for the x86 TargetInfo into a .def file.

2017-11-01 Thread Erich Keane via Phabricator via cfe-commits
erichkeane created this revision.

In anticipation of multiversioned target support (and just for
code sanity), this patch extracts as much of the X86 TargetInfo
CPU values into its own file, unifying the support.

This has the side-effect of being a touch more liberal in what it
accepts than GCC, though will normalize all values to the backend
to a much smaller list.

Note that this depends on a llvm change to 86.td that Craig promises
he'll do in the near future.


https://reviews.llvm.org/D39521

Files:
  include/clang/Basic/TargetInfo.h
  include/clang/Basic/X86Target.def
  lib/Basic/Targets/X86.cpp
  lib/Basic/Targets/X86.h
  lib/CodeGen/CGBuiltin.cpp
  lib/CodeGen/CGCall.cpp
  test/CodeGen/attr-target-x86.c

Index: test/CodeGen/attr-target-x86.c
===
--- test/CodeGen/attr-target-x86.c
+++ test/CodeGen/attr-target-x86.c
@@ -36,11 +36,12 @@
 // CHECK: qax{{.*}} #5
 // CHECK: qq{{.*}} #6
 // CHECK: lake{{.*}} #7
-// CHECK: #0 = {{.*}}"target-cpu"="i686" "target-features"="+x87"
+// The below check issues pentiumpro instead of i686, because they have been dealiased.
+// CHECK: #0 = {{.*}}"target-cpu"="pentiumpro" "target-features"="+x87"
 // CHECK: #1 = {{.*}}"target-cpu"="ivybridge" "target-features"="+aes,+avx,+cx16,+f16c,+fsgsbase,+fxsr,+mmx,+pclmul,+popcnt,+rdrnd,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3,+x87,+xsave,+xsaveopt"
-// CHECK: #2 = {{.*}}"target-cpu"="i686" "target-features"="+x87,-aes,-avx,-avx2,-avx512bw,-avx512cd,-avx512dq,-avx512er,-avx512f,-avx512ifma,-avx512pf,-avx512vbmi,-avx512vl,-avx512vpopcntdq,-f16c,-fma,-fma4,-pclmul,-sha,-sse2,-sse3,-sse4.1,-sse4.2,-sse4a,-ssse3,-xop,-xsave,-xsaveopt"
-// CHECK: #3 = {{.*}}"target-cpu"="i686" "target-features"="+mmx,+popcnt,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3,+x87"
-// CHECK: #4 = {{.*}}"target-cpu"="i686" "target-features"="+x87,-avx,-avx2,-avx512bw,-avx512cd,-avx512dq,-avx512er,-avx512f,-avx512ifma,-avx512pf,-avx512vbmi,-avx512vl,-avx512vpopcntdq,-f16c,-fma,-fma4,-sse4.1,-sse4.2,-xop,-xsave,-xsaveopt"
+// CHECK: #2 = {{.*}}"target-cpu"="pentiumpro" "target-features"="+x87,-aes,-avx,-avx2,-avx512bw,-avx512cd,-avx512dq,-avx512er,-avx512f,-avx512ifma,-avx512pf,-avx512vbmi,-avx512vl,-avx512vpopcntdq,-f16c,-fma,-fma4,-pclmul,-sha,-sse2,-sse3,-sse4.1,-sse4.2,-sse4a,-ssse3,-xop,-xsave,-xsaveopt"
+// CHECK: #3 = {{.*}}"target-cpu"="pentiumpro" "target-features"="+mmx,+popcnt,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3,+x87"
+// CHECK: #4 = {{.*}}"target-cpu"="pentiumpro" "target-features"="+x87,-avx,-avx2,-avx512bw,-avx512cd,-avx512dq,-avx512er,-avx512f,-avx512ifma,-avx512pf,-avx512vbmi,-avx512vl,-avx512vpopcntdq,-f16c,-fma,-fma4,-sse4.1,-sse4.2,-xop,-xsave,-xsaveopt"
 // CHECK: #5 = {{.*}}"target-cpu"="ivybridge" "target-features"="+avx,+cx16,+f16c,+fsgsbase,+fxsr,+mmx,+pclmul,+popcnt,+rdrnd,+sse,+sse2,+sse3,+sse4.1,+sse4.2,+ssse3,+x87,+xsave,+xsaveopt,-aes"
-// CHECK: #6 = {{.*}}"target-cpu"="i686" "target-features"="+x87,-3dnow,-3dnowa,-mmx"
+// CHECK: #6 = {{.*}}"target-cpu"="pentiumpro" "target-features"="+x87,-3dnow,-3dnowa,-mmx"
 // CHECK: #7 = {{.*}}"target-cpu"="lakemont" "target-features"="+mmx"
Index: lib/CodeGen/CGCall.cpp
===
--- lib/CodeGen/CGCall.cpp
+++ lib/CodeGen/CGCall.cpp
@@ -1889,7 +1889,8 @@
   getTarget().isValidCPUName(ParsedAttr.Architecture))
 TargetCPU = ParsedAttr.Architecture;
   if (TargetCPU != "")
- FuncAttrs.addAttribute("target-cpu", TargetCPU);
+FuncAttrs.addAttribute("target-cpu",
+   getTarget().normalizeCpuName(TargetCPU));
   if (!Features.empty()) {
 std::sort(Features.begin(), Features.end());
 FuncAttrs.addAttribute(
@@ -1901,7 +1902,8 @@
   // function.
   std::vector &Features = getTarget().getTargetOpts().Features;
   if (TargetCPU != "")
-FuncAttrs.addAttribute("target-cpu", TargetCPU);
+FuncAttrs.addAttribute("target-cpu",
+   getTarget().normalizeCpuName(TargetCPU));
   if (!Features.empty()) {
 std::sort(Features.begin(), Features.end());
 FuncAttrs.addAttribute(
Index: lib/CodeGen/CGBuiltin.cpp
===
--- lib/CodeGen/CGBuiltin.cpp
+++ lib/CodeGen/CGBuiltin.cpp
@@ -7500,79 +7500,6 @@
 }
 
 Value *CodeGenFunction::EmitX86CpuIs(StringRef CPUStr) {
-
-  // This enum contains the vendor, type, and subtype enums from the
-  // runtime library concatenated together. The _START labels mark
-  // the start and are used to adjust the value into the correct
-  // encoding space.
-  enum X86CPUs {
-INTEL = 1,
-AMD,
-CPU_TYPE_START,
-INTEL_BONNELL,
-INTEL_CORE2,
-INTEL_COREI7,
-AMDFAM10H,
-AMDFAM15H,
-INTEL_SILVERMONT,
-INTEL_KNL,
-AMD_BTVER1,
-AMD_BTVER2,
-AMDFAM17H,
-CPU_SUBTYPE_START,
-INTEL_COREI7_NEHALEM,
-   

[libcxx] r317142 - Revert "[libc++] Don't alias quick_exit if __ANDROID_API__ < 21"

2017-11-01 Thread Dan Albert via cfe-commits
Author: danalbert
Date: Wed Nov  1 16:43:07 2017
New Revision: 317142

URL: http://llvm.org/viewvc/llvm-project?rev=317142&view=rev
Log:
Revert "[libc++] Don't alias quick_exit if __ANDROID_API__ < 21"

Broke the Darwin build bots.

This reverts commit f56f1bba1ade4a408d403ff050d50e837bae47df.

Modified:
libcxx/trunk/include/__config

Modified: libcxx/trunk/include/__config
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config?rev=317142&r1=317141&r2=317142&view=diff
==
--- libcxx/trunk/include/__config (original)
+++ libcxx/trunk/include/__config Wed Nov  1 16:43:07 2017
@@ -296,10 +296,6 @@
 #define _LIBCPP_NO_CFI
 #endif
 
-#if __libcpp_has_include()
-#include 
-#endif
-
 #if defined(_LIBCPP_COMPILER_CLANG)
 
 // _LIBCPP_ALTERNATE_STRING_LAYOUT is an old name for
@@ -411,7 +407,7 @@ typedef __char32_t char32_t;
 #define _LIBCPP_HAS_C11_FEATURES
 #elif defined(__linux__)
 #if !defined(_LIBCPP_HAS_MUSL_LIBC)
-#if __GLIBC_PREREQ(2, 15) || (defined(__BIONIC__) && (__ANDROID_API__ >= 21))
+#if __GLIBC_PREREQ(2, 15) || defined(__BIONIC__)
 #define _LIBCPP_HAS_QUICK_EXIT
 #endif
 #if __GLIBC_PREREQ(2, 17)


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


Re: [PATCH] D39520: [libcxx][CMake] Fix libc++ build when no LLVM source tree is available.

2017-11-01 Thread Zachary Turner via cfe-commits
This will remove the ability to use llvm-lit script even if source tree is
available.

Can you put this behind a check that for standalone build?

Also, why was this just found? shouldnt this have been failing on Apple’s
libcxx for the past several months?
On Wed, Nov 1, 2017 at 4:38 PM Volodymyr Sapsai via Phabricator <
revi...@reviews.llvm.org> wrote:

> vsapsai created this revision.
> Herald added a subscriber: mgorny.
>
> Fixes error
>
> > CMake Error at test/CMakeLists.txt:52 (configure_lit_site_cfg):
> >  Unknown CMake command "configure_lit_site_cfg".
>
> configure_lit_site_cfg is defined in AddLLVM module and not available
> without LLVM source tree. Revert back to configure_file (reverts part of
> r313643).  It is possible as libcxx/test/lit.site.cfg.in doesn't use
> latest lit capabilities.
>
> Tested with
>
> - in-tree libcxx - no change in generated lit.site.cfg and running tests;
> - standalone libcxx with lit checked out next to it - no CMake errors.
>
> If there are other tricky configurations worth testing, let me know.
>
> rdar://problem/35303262
>
>
> https://reviews.llvm.org/D39520
>
> Files:
>   libcxx/test/CMakeLists.txt
>
>
> Index: libcxx/test/CMakeLists.txt
> ===
> --- libcxx/test/CMakeLists.txt
> +++ libcxx/test/CMakeLists.txt
> @@ -49,9 +49,10 @@
>
>  set(AUTO_GEN_COMMENT "## Autogenerated by libcxx configuration.\n# Do not
> edit!")
>
> -configure_lit_site_cfg(
> +configure_file(
>${CMAKE_CURRENT_SOURCE_DIR}/lit.site.cfg.in
> -  ${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg)
> +  ${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg
> +  @ONLY)
>
>  set(LIBCXX_TEST_DEPS "")
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D39520: [libcxx][CMake] Fix libc++ build when no LLVM source tree is available.

2017-11-01 Thread Volodymyr Sapsai via cfe-commits
On Nov 1, 2017, at 16:47, Zachary Turner  wrote:
> 
> This will remove the ability to use llvm-lit script even if source tree is 
> available.
Can you please point me to the place where llvm-lit is enabled in 
configure_lit_site_cfg? Asking for my education, to understand lit 
configuration better and to avoid breaking it. And how do you test llvm-lit 
script if source tree is available? I tried to check out libcxx to 
llvm/projects/, `ninja check-libcxx` worked fine. Though I didn’t use extra 
options, so this case might not reflect real-world usage.

> Can you put this behind a check that for standalone build?
> 
> Also, why was this just found? shouldnt this have been failing on Apple’s 
> libcxx for the past several months?
It was found earlier, this specific fix is submitted for review only now.

> On Wed, Nov 1, 2017 at 4:38 PM Volodymyr Sapsai via Phabricator 
> mailto:revi...@reviews.llvm.org>> wrote:
> vsapsai created this revision.
> Herald added a subscriber: mgorny.
> 
> Fixes error
> 
> > CMake Error at test/CMakeLists.txt:52 (configure_lit_site_cfg):
> >  Unknown CMake command "configure_lit_site_cfg".
> 
> configure_lit_site_cfg is defined in AddLLVM module and not available
> without LLVM source tree. Revert back to configure_file (reverts part of
> r313643).  It is possible as libcxx/test/lit.site.cfg.in 
>  doesn't use
> latest lit capabilities.
> 
> Tested with
> 
> - in-tree libcxx - no change in generated lit.site.cfg and running tests;
> - standalone libcxx with lit checked out next to it - no CMake errors.
> 
> If there are other tricky configurations worth testing, let me know.
> 
> rdar://problem/35303262
> 
> 
> https://reviews.llvm.org/D39520 
> 
> Files:
>   libcxx/test/CMakeLists.txt
> 
> 
> Index: libcxx/test/CMakeLists.txt
> ===
> --- libcxx/test/CMakeLists.txt
> +++ libcxx/test/CMakeLists.txt
> @@ -49,9 +49,10 @@
> 
>  set(AUTO_GEN_COMMENT "## Autogenerated by libcxx configuration.\n# Do not 
> edit!")
> 
> -configure_lit_site_cfg(
> +configure_file(
>${CMAKE_CURRENT_SOURCE_DIR}/lit.site.cfg.in 
> -  ${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg)
> +  ${CMAKE_CURRENT_BINARY_DIR}/lit.site.cfg
> +  @ONLY)
> 
>  set(LIBCXX_TEST_DEPS "")
> 
> 
> 

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


Re: [PATCH] D39520: [libcxx][CMake] Fix libc++ build when no LLVM source tree is available.

2017-11-01 Thread Zachary Turner via cfe-commits
On Wed, Nov 1, 2017 at 5:13 PM Volodymyr Sapsai  wrote:

> On Nov 1, 2017, at 16:47, Zachary Turner  wrote:
>
>
> This will remove the ability to use llvm-lit script even if source tree is
> available.
>
> Can you please point me to the place where llvm-lit is enabled in
> configure_lit_site_cfg? Asking for my education, to understand lit
> configuration better and to avoid breaking it. And how do you test llvm-lit
> script if source tree is available? I tried to check out libcxx to
> llvm/projects/, `ninja check-libcxx` worked fine. Though I didn’t use extra
> options, so this case might not reflect real-world usage.
>

configure_lit_site_cfg doesn't actually enable llvm-lit generation, but if
llvm-lit generation is already enabled, then using configure_lit_site_cfg
will cause additional information to be written to the generated llvm-lit
script so that you can use bin/llvm-lit .

I think all you need to do is say:

if (LIBCXX_STANDALONE_BUILD)
  configure_file(...
else()
   configure_lit_site_cfg(...
endif()

If this doesn't work for some reason though, or is too much effort, I'm not
opposed to your original patch, since I think llvm-lit script generation is
unconditionally disabled for libcxx right now anyway.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r317146 - CodeGen: simplify EH personality selection (NFC)

2017-11-01 Thread Saleem Abdulrasool via cfe-commits
Author: compnerd
Date: Wed Nov  1 17:25:40 2017
New Revision: 317146

URL: http://llvm.org/viewvc/llvm-project?rev=317146&view=rev
Log:
CodeGen: simplify EH personality selection (NFC)

Fix a typo in the comment, reorder to ensure that the ordering matches
across the ObjC/ObjC++ cases.  NFCI.

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

Modified: cfe/trunk/lib/CodeGen/CGException.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGException.cpp?rev=317146&r1=317145&r2=317146&view=diff
==
--- cfe/trunk/lib/CodeGen/CGException.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGException.cpp Wed Nov  1 17:25:40 2017
@@ -165,26 +165,27 @@ static const EHPersonality &getCXXPerson
 static const EHPersonality &getObjCXXPersonality(const llvm::Triple &T,
  const LangOptions &L) {
   switch (L.ObjCRuntime.getKind()) {
+  // In the fragile ABI, just use C++ exception handling and hope
+  // they're not doing crazy exception mixing.
+  case ObjCRuntime::FragileMacOSX:
+return getCXXPersonality(T, L);
+
   // The ObjC personality defers to the C++ personality for non-ObjC
   // handlers.  Unlike the C++ case, we use the same personality
   // function on targets using (backend-driven) SJLJ EH.
   case ObjCRuntime::MacOSX:
   case ObjCRuntime::iOS:
   case ObjCRuntime::WatchOS:
-return EHPersonality::NeXT_ObjC;
+return getObjCPersonality(T, L);
 
-  // In the fragile ABI, just use C++ exception handling and hope
-  // they're not doing crazy exception mixing.
-  case ObjCRuntime::FragileMacOSX:
-return getCXXPersonality(T, L);
+  case ObjCRuntime::GNUstep:
+return EHPersonality::GNU_ObjCXX;
 
   // The GCC runtime's personality function inherently doesn't support
-  // mixed EH.  Use the C++ personality just to avoid returning null.
+  // mixed EH.  Use the ObjC personality just to avoid returning null.
   case ObjCRuntime::GCC:
   case ObjCRuntime::ObjFW:
 return getObjCPersonality(T, L);
-  case ObjCRuntime::GNUstep:
-return EHPersonality::GNU_ObjCXX;
   }
   llvm_unreachable("bad runtime kind");
 }


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


[PATCH] D38596: Implement attribute target multiversioning

2017-11-01 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added a comment.

In https://reviews.llvm.org/D38596#910035, @erichkeane wrote:

> > You should add tests for:
> > 
> > - the PCH / Modules case (particularly regarding what happens when merging 
> > multiple copies of the same set of functions, for instance when they're 
> > defined inline); I would expect this doesn't currently work with this 
> > patch, because we only ever load one function body per redeclaration chain
>
> I'm not sure I know what one of those looks like... is there a good test that 
> I can use to learn the modules implementation?


There are a bunch in `test/PCH` and `test/Modules` that you could crib from.

>> - multiversioned functions declared inline
> 
> I don't see anything changing for this situation, but I imagine you have an 
> issue in mind that I'm missing?

You need to make sure you use the correct linkage for the versions and for the 
dispatcher. Your tests seem to demonstrate you're getting this wrong at the 
moment. Also, this is the case where the mangling of the target-specific 
definitions would become part of the ABI.

>> - constant expression evaluation of calls to such functions (which should -- 
>> presumably -- either always use the default version or be rejected as 
>> non-constant)
> 
> I'd say they should always do the default version, but this isn't something I 
> did any work on.  I'll look at that.
> 
>> I would also expect that asking a multiversioned `FunctionDecl` for its 
>> definition would only ever give you the `target("default")` definition or 
>> the one-and-only definition, rather than an arbitrary declaration that 
>> happens to have a body.
> 
> Right, this is a big catch that I didn't think about...

What I'm essentially thinking here is that a declaration with a body for a 
multiversioned function, that isn't for the "default" target, would not be 
treated as being "the definition" at all.

The big pain point here is that we don't know whether a function is 
multiversioned until we see the *second* version of it (or a declaration with 
no target attribute or a declaration with a "default" target), and we generally 
want our AST to be immutable-once-created. I don't see a good way to handle 
this except by mutating the AST when we see the second version (which leads to 
complexity, particularly around PCH -- you need to inform AST mutation 
listeners that this has happened and write a record out into the AST file to 
indicate you've updated an imported entity) -- or by treating any function with 
a target attribute as if it were multiversioned, and not treating a declaration 
with a body as being the definition until / unless we see the first use of it 
(which, again, leads to an AST mutation of some kind at that point).

Keeping the redeclaration chains separate would avoid this problem, but we'd 
still need to do *something* to track the set of versions of the function so we 
can emit them as part of the ifunc.


https://reviews.llvm.org/D38596



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


[PATCH] D38596: Implement attribute target multiversioning

2017-11-01 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added inline comments.



Comment at: lib/Basic/Targets/X86.cpp:1329
+  // implementation in in GCC 7.x in gcc/config/i386/i386.c
+  // ::get_builtin_code_for_version. This list is simplified from that source.
+  const auto TargetArray = {"avx512vpopcntdq",

erichkeane wrote:
> rsmith wrote:
> > Where did this table and code actually come from?
> I took the list of things recognized by GCC, ran them through godbolt to see 
> the list.
OK, that sounds reasonable. Please rephrase this comment; the current wording 
could be read as suggesting this is in some way derived from the GCC source 
code, which is clearly not what you did, nor what we're suggesting that people 
updating this list do.



Comment at: lib/CodeGen/CodeGenModule.cpp:421-423
+  Diags.Report(
+  cast(GD.getDecl())->getFirstDecl()->getLocation(),
+  diag::err_target_without_default);

erichkeane wrote:
> rsmith wrote:
> > I'm not happy with this diagnostic being produced by IR generation. We 
> > should diagnose this at the point of first use of the multiversioned 
> > function, within `Sema`.
> Unfortunately, there is no real way to tell there.  A usage could happen 
> before the 2nd definition, so it wouldn't know that it IS a multiversioning 
> at that point.
I think we should reject any case where new versions of the function are added 
after the first use. Generally we want our extensions to support eager code 
generation, even in cases where that means we reject certain setups that GCC 
copes with.


https://reviews.llvm.org/D38596



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


[PATCH] D38596: Implement attribute target multiversioning

2017-11-01 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

In https://reviews.llvm.org/D38596#913322, @rsmith wrote:

> The big pain point here is that we don't know whether a function is 
> multiversioned until we see the *second* version of it (or a declaration with 
> no target attribute or a declaration with a "default" target), and we 
> generally want our AST to be immutable-once-created. I don't see a good way 
> to handle this except by mutating the AST when we see the second version 
> (which leads to complexity, particularly around PCH -- you need to inform AST 
> mutation listeners that this has happened and write a record out into the AST 
> file to indicate you've updated an imported entity) -- or by treating any 
> function with a target attribute as if it were multiversioned, and not 
> treating a declaration with a body as being the definition until / unless we 
> see the first use of it (which, again, leads to an AST mutation of some kind 
> at that point).
>
> Keeping the redeclaration chains separate would avoid this problem, but we'd 
> still need to do *something* to track the set of versions of the function so 
> we can emit them as part of the ifunc.


That is definitely a pain point.  The solution I've had bouncing around in my 
head is the following, but it has some limitations that GCC doesn't have:
1- Convert to multiversion not permitted unless 1 of the 2 is 'default' (since 
it is required).
2- Convert to multiversion not permitted if the decl has been used.
3- Prevent the 'lookup' from finding the non-default version, this permits 
things like constexpr to work properly.
4- Add a list of the "Multiversion Decls" to the 'default' FunctionDecl.

My hope being that #2 makes it so that no one would really NOTICE the AST 
rewriting, since it hasn't been used.  
#1 enables #3, so that the only 'user' of the multiversion'ed decls ends up 
being the CodeGen emitting the ifunc.
#4 of course is to give CodeGen the ability to emit all of the definitions.

Is there a better way to 'downgrade' the non-default FunctionDecl's to 'not 
lookupable'?  Or is this something I would need to add?

Finally, 1 further idea is that "default" automatically creates it as a 
'multiversion case'.  Since a sole 'default' would be invalid in GCC, I think 
that makes us OK, right?

Thoughts on the above proposal?  I have basically abandoned this review, since 
the changes are pretty intense.  I've also submitted another patch (that Craig 
Topper is helping me with) to cleanup the CPU/Feature definitions to make that 
list more sane.

BTW: Just saw your 2nd response: I think the rejection of cases where 
multiversioning is caused after first-use is the only real way to make this 
sane.

Thanks again for your input!


https://reviews.llvm.org/D38596



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


[PATCH] D39521: [x86 TargetInfo] Pull CPU handling for the x86 TargetInfo into a .def file.

2017-11-01 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added a comment.

Thanks, this looks like a nice cleanup. I wonder of some of the switches over 
`CPUKind` (setting default features and macros) could also be moved into the 
.def file, but let's get this landed first and then see if that looks like an 
improvement.




Comment at: lib/Basic/Targets/X86.h:103-106
+#undef PROC_FAMILY
+#undef PROC
+#undef PROC_VENDOR
+#undef IGNORE_ALIASES

Our convention is for the .def files to be callee-cleanup: the .def file should 
`#undef` all the macros it takes as input, rather than them being `#undef`'d by 
the `#include`r.



Comment at: lib/Basic/Targets/X86.h:113-126
+  // \brief Returns a pair of unsigned integers that contain the __cpu_model
+  // information required to identify the specified Processor Family/Processor.
+  // A valid Processor Family will return a 1 in the first value, and the 
'type'
+  // identifier for the family in the second.  A valid Processor will return a 
2
+  // in the first value, and the 'subtype' identifier for the processor in the
+  // second. If the value provided is not valid for cpu_is identification, will
+  // return a 0 in the second value.

Use a `struct` here rather than a pair/tuple of `unsigned`.



Comment at: lib/CodeGen/CGCall.cpp:1893
+FuncAttrs.addAttribute("target-cpu",
+   getTarget().normalizeCpuName(TargetCPU));
   if (!Features.empty()) {

Is this part of the refactoring or a separate change?


https://reviews.llvm.org/D39521



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


[PATCH] D39522: [clang-rename] Use add_clang_tool

2017-11-01 Thread Shoaib Meenai via Phabricator via cfe-commits
smeenai created this revision.
Herald added a subscriber: mgorny.

`add_clang_tool` includes a call to `add_clang_executable`, but it also
sets up the install rule, and adds an `install-*` target. The latter is
required for using `LLVM_DISTRIBUTION_COMPONENTS`.


https://reviews.llvm.org/D39522

Files:
  tools/clang-rename/CMakeLists.txt


Index: tools/clang-rename/CMakeLists.txt
===
--- tools/clang-rename/CMakeLists.txt
+++ tools/clang-rename/CMakeLists.txt
@@ -3,7 +3,7 @@
   Support
   )
 
-add_clang_executable(clang-rename ClangRename.cpp)
+add_clang_tool(clang-rename ClangRename.cpp)
 
 target_link_libraries(clang-rename
   clangBasic
@@ -14,8 +14,6 @@
   clangToolingRefactor
   )
 
-install(TARGETS clang-rename RUNTIME DESTINATION bin)
-
 install(PROGRAMS clang-rename.py
   DESTINATION share/clang
   COMPONENT clang-rename)


Index: tools/clang-rename/CMakeLists.txt
===
--- tools/clang-rename/CMakeLists.txt
+++ tools/clang-rename/CMakeLists.txt
@@ -3,7 +3,7 @@
   Support
   )
 
-add_clang_executable(clang-rename ClangRename.cpp)
+add_clang_tool(clang-rename ClangRename.cpp)
 
 target_link_libraries(clang-rename
   clangBasic
@@ -14,8 +14,6 @@
   clangToolingRefactor
   )
 
-install(TARGETS clang-rename RUNTIME DESTINATION bin)
-
 install(PROGRAMS clang-rename.py
   DESTINATION share/clang
   COMPONENT clang-rename)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D39521: [x86 TargetInfo] Pull CPU handling for the x86 TargetInfo into a .def file.

2017-11-01 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

In https://reviews.llvm.org/D39521#913337, @rsmith wrote:

> Thanks, this looks like a nice cleanup. I wonder of some of the switches over 
> `CPUKind` (setting default features and macros) could also be moved into the 
> .def file, but let's get this landed first and then see if that looks like an 
> improvement.


Thanks for the feedback Richard!  For the CPUKind features, I'm hoping to talk 
@craig.topper into exposing those somehow from llvm, and just grabbing them 
there :)  Additionally, he has some other ideas that we're going over on how to 
expose the CpuIs information from LLVM, rather than have version of the list 
here.

SO, this patch might get a bit of a diet sometime tomorrow.

Thanks!
-Erich




Comment at: lib/Basic/Targets/X86.h:103-106
+#undef PROC_FAMILY
+#undef PROC
+#undef PROC_VENDOR
+#undef IGNORE_ALIASES

rsmith wrote:
> Our convention is for the .def files to be callee-cleanup: the .def file 
> should `#undef` all the macros it takes as input, rather than them being 
> `#undef`'d by the `#include`r.
Ah, i missed that!  Will do.



Comment at: lib/Basic/Targets/X86.h:113-126
+  // \brief Returns a pair of unsigned integers that contain the __cpu_model
+  // information required to identify the specified Processor Family/Processor.
+  // A valid Processor Family will return a 1 in the first value, and the 
'type'
+  // identifier for the family in the second.  A valid Processor will return a 
2
+  // in the first value, and the 'subtype' identifier for the processor in the
+  // second. If the value provided is not valid for cpu_is identification, will
+  // return a 0 in the second value.

rsmith wrote:
> Use a `struct` here rather than a pair/tuple of `unsigned`.
I can do that... the only real issue is attempting to keep that generic enough 
that other processors can use it.  



Comment at: lib/CodeGen/CGCall.cpp:1893
+FuncAttrs.addAttribute("target-cpu",
+   getTarget().normalizeCpuName(TargetCPU));
   if (!Features.empty()) {

rsmith wrote:
> Is this part of the refactoring or a separate change?
This is a part of this refactoring.  The 'alias' system that this patch creates 
would end up leaking into the backend, so this normalizes back to the 
non-aliased versions.  


https://reviews.llvm.org/D39521



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


[PATCH] D39523: [clang-reorder-fields] Switch to add_clang_tool

2017-11-01 Thread Shoaib Meenai via Phabricator via cfe-commits
smeenai created this revision.
Herald added a subscriber: mgorny.

`add_clang_tool` invokes `add_clang_executable` internally, but it also
takes care of setting up the install rule. It also adds an `install-*`
build target, which is required for `LLVM_DISTRIBUTION_COMPONENTS`.


https://reviews.llvm.org/D39523

Files:
  clang-reorder-fields/tool/CMakeLists.txt


Index: clang-reorder-fields/tool/CMakeLists.txt
===
--- clang-reorder-fields/tool/CMakeLists.txt
+++ clang-reorder-fields/tool/CMakeLists.txt
@@ -1,4 +1,4 @@
-add_clang_executable(clang-reorder-fields ClangReorderFields.cpp)
+add_clang_tool(clang-reorder-fields ClangReorderFields.cpp)
 
 target_link_libraries(clang-reorder-fields
   clangBasic
@@ -8,5 +8,3 @@
   clangTooling
   clangToolingCore
   )
-
-install(TARGETS clang-reorder-fields RUNTIME DESTINATION bin)


Index: clang-reorder-fields/tool/CMakeLists.txt
===
--- clang-reorder-fields/tool/CMakeLists.txt
+++ clang-reorder-fields/tool/CMakeLists.txt
@@ -1,4 +1,4 @@
-add_clang_executable(clang-reorder-fields ClangReorderFields.cpp)
+add_clang_tool(clang-reorder-fields ClangReorderFields.cpp)
 
 target_link_libraries(clang-reorder-fields
   clangBasic
@@ -8,5 +8,3 @@
   clangTooling
   clangToolingCore
   )
-
-install(TARGETS clang-reorder-fields RUNTIME DESTINATION bin)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D39522: [clang-rename] Use add_clang_tool

2017-11-01 Thread Alex Lorenz via Phabricator via cfe-commits
arphaman accepted this revision.
arphaman added a comment.
This revision is now accepted and ready to land.

LGTM.


https://reviews.llvm.org/D39522



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


[PATCH] D39524: [libclang] Add dummy libclang-headers target

2017-11-01 Thread Shoaib Meenai via Phabricator via cfe-commits
smeenai created this revision.
Herald added a subscriber: mgorny.

`LLVM_DISTRIBUTION_COMPONENTS` assumes that each component has both
`component` and `install-component` targets. Add a dummy no-op target
for `libclang-headers` to placate this check.


https://reviews.llvm.org/D39524

Files:
  tools/libclang/CMakeLists.txt


Index: tools/libclang/CMakeLists.txt
===
--- tools/libclang/CMakeLists.txt
+++ tools/libclang/CMakeLists.txt
@@ -141,6 +141,9 @@
   PATTERN ".svn" EXCLUDE
   )
 
+# Add dummy target to placate LLVM_DISTRIBUTION_COMPONENTS.
+add_custom_target(libclang-headers)
+
 if (NOT CMAKE_CONFIGURATION_TYPES) # don't add this for IDE's.
   add_custom_target(install-libclang-headers
 DEPENDS


Index: tools/libclang/CMakeLists.txt
===
--- tools/libclang/CMakeLists.txt
+++ tools/libclang/CMakeLists.txt
@@ -141,6 +141,9 @@
   PATTERN ".svn" EXCLUDE
   )
 
+# Add dummy target to placate LLVM_DISTRIBUTION_COMPONENTS.
+add_custom_target(libclang-headers)
+
 if (NOT CMAKE_CONFIGURATION_TYPES) # don't add this for IDE's.
   add_custom_target(install-libclang-headers
 DEPENDS
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r317147 - PR33746: Store the 'inline'ness of a static data member with the update record

2017-11-01 Thread Richard Smith via cfe-commits
Author: rsmith
Date: Wed Nov  1 18:06:00 2017
New Revision: 317147

URL: http://llvm.org/viewvc/llvm-project?rev=317147&view=rev
Log:
PR33746: Store the 'inline'ness of a static data member with the update record
for instantiating its definition.

We model the 'inline'ness as being instantiated with the static data member in
order to track whether the declaration has become a definition yet.

Added:
cfe/trunk/test/Modules/cxx17-inline-variables.cpp
Modified:
cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
cfe/trunk/lib/Serialization/ASTWriter.cpp

Modified: cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTReaderDecl.cpp?rev=317147&r1=317146&r2=317147&view=diff
==
--- cfe/trunk/lib/Serialization/ASTReaderDecl.cpp (original)
+++ cfe/trunk/lib/Serialization/ASTReaderDecl.cpp Wed Nov  1 18:06:00 2017
@@ -3988,6 +3988,8 @@ void ASTDeclReader::UpdateDecl(Decl *D,
   VarDecl *VD = cast(D);
   VD->getMemberSpecializationInfo()->setPointOfInstantiation(
   ReadSourceLocation());
+  VD->NonParmVarDeclBits.IsInline = Record.readInt();
+  VD->NonParmVarDeclBits.IsInlineSpecified = Record.readInt();
   uint64_t Val = Record.readInt();
   if (Val && !VD->getInit()) {
 VD->setInit(Record.readExpr());

Modified: cfe/trunk/lib/Serialization/ASTWriter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTWriter.cpp?rev=317147&r1=317146&r2=317147&view=diff
==
--- cfe/trunk/lib/Serialization/ASTWriter.cpp (original)
+++ cfe/trunk/lib/Serialization/ASTWriter.cpp Wed Nov  1 18:06:00 2017
@@ -5084,6 +5084,8 @@ void ASTWriter::WriteDeclUpdatesBlocks(R
   case UPD_CXX_INSTANTIATED_STATIC_DATA_MEMBER: {
 const VarDecl *VD = cast(D);
 Record.AddSourceLocation(Update.getLoc());
+Record.push_back(VD->isInline());
+Record.push_back(VD->isInlineSpecified());
 if (VD->getInit()) {
   Record.push_back(!VD->isInitKnownICE() ? 1
  : (VD->isInitICE() ? 3 : 2));

Added: cfe/trunk/test/Modules/cxx17-inline-variables.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/cxx17-inline-variables.cpp?rev=317147&view=auto
==
--- cfe/trunk/test/Modules/cxx17-inline-variables.cpp (added)
+++ cfe/trunk/test/Modules/cxx17-inline-variables.cpp Wed Nov  1 18:06:00 2017
@@ -0,0 +1,30 @@
+// RUN: %clang_cc1 -std=c++17 -fsyntax-only -fmodules %s
+
+#pragma clang module build a
+module a {}
+#pragma clang module contents
+#pragma clang module begin a
+
+template  struct ak { static constexpr c value = e; };
+ak instantiate_class_definition;
+
+#pragma clang module end /* a */
+#pragma clang module endbuild
+
+
+#pragma clang module build o
+module o {}
+#pragma clang module contents
+#pragma clang module begin o
+#pragma clang module import a
+
+inline int instantiate_var_definition() { return ak::value; }
+
+#pragma clang module end
+#pragma clang module endbuild
+
+
+#pragma clang module import o
+#pragma clang module import a
+
+int main() { return ak::value; }


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


[PATCH] D39523: [clang-reorder-fields] Switch to add_clang_tool

2017-11-01 Thread Shoaib Meenai via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL317149: [clang-reorder-fields] Switch to add_clang_tool 
(authored by smeenai).

Repository:
  rL LLVM

https://reviews.llvm.org/D39523

Files:
  clang-tools-extra/trunk/clang-reorder-fields/tool/CMakeLists.txt


Index: clang-tools-extra/trunk/clang-reorder-fields/tool/CMakeLists.txt
===
--- clang-tools-extra/trunk/clang-reorder-fields/tool/CMakeLists.txt
+++ clang-tools-extra/trunk/clang-reorder-fields/tool/CMakeLists.txt
@@ -1,4 +1,4 @@
-add_clang_executable(clang-reorder-fields ClangReorderFields.cpp)
+add_clang_tool(clang-reorder-fields ClangReorderFields.cpp)
 
 target_link_libraries(clang-reorder-fields
   clangBasic
@@ -8,5 +8,3 @@
   clangTooling
   clangToolingCore
   )
-
-install(TARGETS clang-reorder-fields RUNTIME DESTINATION bin)


Index: clang-tools-extra/trunk/clang-reorder-fields/tool/CMakeLists.txt
===
--- clang-tools-extra/trunk/clang-reorder-fields/tool/CMakeLists.txt
+++ clang-tools-extra/trunk/clang-reorder-fields/tool/CMakeLists.txt
@@ -1,4 +1,4 @@
-add_clang_executable(clang-reorder-fields ClangReorderFields.cpp)
+add_clang_tool(clang-reorder-fields ClangReorderFields.cpp)
 
 target_link_libraries(clang-reorder-fields
   clangBasic
@@ -8,5 +8,3 @@
   clangTooling
   clangToolingCore
   )
-
-install(TARGETS clang-reorder-fields RUNTIME DESTINATION bin)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] r317149 - [clang-reorder-fields] Switch to add_clang_tool

2017-11-01 Thread Shoaib Meenai via cfe-commits
Author: smeenai
Date: Wed Nov  1 18:10:05 2017
New Revision: 317149

URL: http://llvm.org/viewvc/llvm-project?rev=317149&view=rev
Log:
[clang-reorder-fields] Switch to add_clang_tool

`add_clang_tool` invokes `add_clang_executable` internally, but it also
takes care of setting up the install rule. It also adds an `install-*`
build target, which is required for `LLVM_DISTRIBUTION_COMPONENTS`.

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

Modified:
clang-tools-extra/trunk/clang-reorder-fields/tool/CMakeLists.txt

Modified: clang-tools-extra/trunk/clang-reorder-fields/tool/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-reorder-fields/tool/CMakeLists.txt?rev=317149&r1=317148&r2=317149&view=diff
==
--- clang-tools-extra/trunk/clang-reorder-fields/tool/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clang-reorder-fields/tool/CMakeLists.txt Wed Nov  1 
18:10:05 2017
@@ -1,4 +1,4 @@
-add_clang_executable(clang-reorder-fields ClangReorderFields.cpp)
+add_clang_tool(clang-reorder-fields ClangReorderFields.cpp)
 
 target_link_libraries(clang-reorder-fields
   clangBasic
@@ -8,5 +8,3 @@ target_link_libraries(clang-reorder-fiel
   clangTooling
   clangToolingCore
   )
-
-install(TARGETS clang-reorder-fields RUNTIME DESTINATION bin)


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


r317150 - [clang-rename] Use add_clang_tool

2017-11-01 Thread Shoaib Meenai via cfe-commits
Author: smeenai
Date: Wed Nov  1 18:11:40 2017
New Revision: 317150

URL: http://llvm.org/viewvc/llvm-project?rev=317150&view=rev
Log:
[clang-rename] Use add_clang_tool

`add_clang_tool` includes a call to `add_clang_executable`, but it also
sets up the install rule, and adds an `install-*` target. The latter is
required for using `LLVM_DISTRIBUTION_COMPONENTS`.

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

Modified:
cfe/trunk/tools/clang-rename/CMakeLists.txt

Modified: cfe/trunk/tools/clang-rename/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-rename/CMakeLists.txt?rev=317150&r1=317149&r2=317150&view=diff
==
--- cfe/trunk/tools/clang-rename/CMakeLists.txt (original)
+++ cfe/trunk/tools/clang-rename/CMakeLists.txt Wed Nov  1 18:11:40 2017
@@ -3,7 +3,7 @@ set(LLVM_LINK_COMPONENTS
   Support
   )
 
-add_clang_executable(clang-rename ClangRename.cpp)
+add_clang_tool(clang-rename ClangRename.cpp)
 
 target_link_libraries(clang-rename
   clangBasic
@@ -14,8 +14,6 @@ target_link_libraries(clang-rename
   clangToolingRefactor
   )
 
-install(TARGETS clang-rename RUNTIME DESTINATION bin)
-
 install(PROGRAMS clang-rename.py
   DESTINATION share/clang
   COMPONENT clang-rename)


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


[PATCH] D39522: [clang-rename] Use add_clang_tool

2017-11-01 Thread Shoaib Meenai via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL317150: [clang-rename] Use add_clang_tool (authored by 
smeenai).

Repository:
  rL LLVM

https://reviews.llvm.org/D39522

Files:
  cfe/trunk/tools/clang-rename/CMakeLists.txt


Index: cfe/trunk/tools/clang-rename/CMakeLists.txt
===
--- cfe/trunk/tools/clang-rename/CMakeLists.txt
+++ cfe/trunk/tools/clang-rename/CMakeLists.txt
@@ -3,7 +3,7 @@
   Support
   )
 
-add_clang_executable(clang-rename ClangRename.cpp)
+add_clang_tool(clang-rename ClangRename.cpp)
 
 target_link_libraries(clang-rename
   clangBasic
@@ -14,8 +14,6 @@
   clangToolingRefactor
   )
 
-install(TARGETS clang-rename RUNTIME DESTINATION bin)
-
 install(PROGRAMS clang-rename.py
   DESTINATION share/clang
   COMPONENT clang-rename)


Index: cfe/trunk/tools/clang-rename/CMakeLists.txt
===
--- cfe/trunk/tools/clang-rename/CMakeLists.txt
+++ cfe/trunk/tools/clang-rename/CMakeLists.txt
@@ -3,7 +3,7 @@
   Support
   )
 
-add_clang_executable(clang-rename ClangRename.cpp)
+add_clang_tool(clang-rename ClangRename.cpp)
 
 target_link_libraries(clang-rename
   clangBasic
@@ -14,8 +14,6 @@
   clangToolingRefactor
   )
 
-install(TARGETS clang-rename RUNTIME DESTINATION bin)
-
 install(PROGRAMS clang-rename.py
   DESTINATION share/clang
   COMPONENT clang-rename)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D39524: [libclang] Add dummy libclang-headers target

2017-11-01 Thread Shoaib Meenai via Phabricator via cfe-commits
smeenai updated this revision to Diff 121223.
smeenai added a comment.

Better comment


https://reviews.llvm.org/D39524

Files:
  tools/libclang/CMakeLists.txt


Index: tools/libclang/CMakeLists.txt
===
--- tools/libclang/CMakeLists.txt
+++ tools/libclang/CMakeLists.txt
@@ -141,6 +141,11 @@
   PATTERN ".svn" EXCLUDE
   )
 
+# LLVM_DISTRIBUTION_COMPONENTS requires that each component have both a
+# component and an install-component target, so add a dummy libclang-headers
+# target to allow using it in LLVM_DISTRIBUTION_COMPONENTS.
+add_custom_target(libclang-headers)
+
 if (NOT CMAKE_CONFIGURATION_TYPES) # don't add this for IDE's.
   add_custom_target(install-libclang-headers
 DEPENDS


Index: tools/libclang/CMakeLists.txt
===
--- tools/libclang/CMakeLists.txt
+++ tools/libclang/CMakeLists.txt
@@ -141,6 +141,11 @@
   PATTERN ".svn" EXCLUDE
   )
 
+# LLVM_DISTRIBUTION_COMPONENTS requires that each component have both a
+# component and an install-component target, so add a dummy libclang-headers
+# target to allow using it in LLVM_DISTRIBUTION_COMPONENTS.
+add_custom_target(libclang-headers)
+
 if (NOT CMAKE_CONFIGURATION_TYPES) # don't add this for IDE's.
   add_custom_target(install-libclang-headers
 DEPENDS
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D39446: [PGO] Detect more structural changes with the stable hash

2017-11-01 Thread Vedant Kumar via Phabricator via cfe-commits
vsk updated this revision to Diff 121224.
vsk marked 2 inline comments as done.
vsk edited the summary of this revision.
vsk added a comment.

- Handle loop nesting, conditions, and out-of-order control flow.
- Improve test coverage. Add a format compatibility test, and check that 
functions which were previously hashed the same way get different hashes now.


https://reviews.llvm.org/D39446

Files:
  lib/CodeGen/CodeGenPGO.cpp
  test/Profile/Inputs/c-captured.proftext
  test/Profile/Inputs/c-counter-overflows.proftext
  test/Profile/Inputs/c-general.proftext
  test/Profile/Inputs/c-unprofiled-blocks.proftext
  test/Profile/Inputs/cxx-class.proftext
  test/Profile/Inputs/cxx-lambda.proftext
  test/Profile/Inputs/cxx-rangefor.proftext
  test/Profile/Inputs/cxx-templates.proftext
  test/Profile/Inputs/cxx-throws.proftext
  test/Profile/Inputs/func-entry.proftext
  test/Profile/Inputs/gcc-flag-compatibility.proftext
  test/Profile/Inputs/objc-general.proftext
  test/Profile/Inputs/objcxx-hash-v2.profdata.v5
  test/Profile/Inputs/objcxx-hash-v2.proftext
  test/Profile/c-outdated-data.c
  test/Profile/objc-general.m
  test/Profile/objcxx-hash-v2.mm

Index: test/Profile/objcxx-hash-v2.mm
===
--- /dev/null
+++ test/Profile/objcxx-hash-v2.mm
@@ -0,0 +1,169 @@
+// REQUIRES: shell
+
+// Check that all of the hashes in this file are unique (i.e, that none of the
+// profiles for these functions are mutually interchangeable).
+//
+// RUN: llvm-profdata show -all-functions %S/Inputs/objcxx-hash-v2.profdata.v5 | grep "Hash: 0x" | sort > %t.hashes
+// RUN: uniq %t.hashes > %t.hashes.unique
+// RUN: diff %t.hashes %t.hashes.unique
+
+// RUN: llvm-profdata merge %S/Inputs/objcxx-hash-v2.proftext -o %t.profdata
+// RUN: %clang_cc1 -std=c++11 -fexceptions -fcxx-exceptions -triple x86_64-apple-macosx10.9 -main-file-name objcxx-hash-v2.mm %s -o /dev/null -emit-llvm -fprofile-instrument-use-path=%t.profdata 2>&1 | FileCheck %s -allow-empty
+// RUN: %clang_cc1 -std=c++11 -fexceptions -fcxx-exceptions -triple x86_64-apple-macosx10.9 -main-file-name objcxx-hash-v2.mm %s -o /dev/null -emit-llvm -fprofile-instrument-use-path=%S/Inputs/objcxx-hash-v2.profdata.v5 2>&1 | FileCheck %s -allow-empty
+
+// CHECK-NOT: warning: profile data may be out of date
+
+int x;
+int arr[1] = {0};
+
+void loop_after_if_else() {
+  if (1)
+x = 1;
+  else
+x = 2;
+  while (0)
+++x;
+}
+
+void loop_in_then_block() {
+  if (1) {
+while (0)
+  ++x;
+  } else {
+x = 2;
+  }
+}
+
+void loop_in_else_block() {
+  if (1) {
+x = 1;
+  } else {
+while (0)
+  ++x;
+  }
+}
+
+void if_inside_of_for() {
+  for (x = 0; x < 0; ++x) {
+x = 1;
+if (1)
+  x = 2;
+  }
+}
+
+void if_outside_of_for() {
+  for (x = 0; x < 0; ++x)
+x = 1;
+  if (1)
+x = 2;
+}
+
+void if_inside_of_while() {
+  while (0) {
+x = 1;
+if (1)
+  x = 2;
+  }
+}
+
+void if_outside_of_while() {
+  while (0)
+x = 1;
+  if (1)
+x = 2;
+}
+
+void nested_dos() {
+  do {
+do {
+  ++x;
+} while (0);
+  } while (0);
+}
+
+void consecutive_dos() {
+  do {
+  } while (0);
+  do {
+++x;
+  } while (0);
+}
+
+void loop_empty() {
+  for (x = 0; x < 5; ++x) {}
+}
+
+void loop_return() {
+  for (x = 0; x < 5; ++x)
+return;
+}
+
+void loop_continue() {
+  for (x = 0; x < 5; ++x)
+continue;
+}
+
+void loop_break() {
+  for (x = 0; x < 5; ++x)
+break;
+}
+
+void no_gotos() {
+  static void *dispatch[] = {&&done};
+  x = 0;
+done:
+  ++x;
+}
+
+void direct_goto() {
+  static void *dispatch[] = {&&done};
+  x = 0;
+  goto done;
+done:
+  ++x;
+}
+
+void indirect_goto() {
+  static void *dispatch[] = {&&done};
+  x = 0;
+  goto *dispatch[x];
+done:
+  ++x;
+}
+
+void nested_for_ranges() {
+  for (int a : arr)
+for (int b : arr)
+  ++x;
+}
+
+void consecutive_for_ranges() {
+  for (int a : arr) {}
+  for (int b : arr)
+++x;
+}
+
+void nested_try_catch() {
+  try {
+try {
+  ++x;
+} catch (...) {}
+  } catch (...) {}
+}
+
+void consecutive_try_catch() {
+  try {} catch (...) {}
+  try {
+++x;
+  } catch (...) {}
+}
+
+void no_throw() {}
+
+void has_throw() {
+  throw 0;
+}
+
+int main() {
+  return 0;
+}
Index: test/Profile/objc-general.m
===
--- test/Profile/objc-general.m
+++ test/Profile/objc-general.m
@@ -3,7 +3,9 @@
 // RUN: %clang_cc1 -triple x86_64-apple-macosx10.9 -main-file-name objc-general.m %s -o - -emit-llvm -fblocks -fprofile-instrument=clang | FileCheck -check-prefix=PGOGEN %s
 
 // RUN: llvm-profdata merge %S/Inputs/objc-general.proftext -o %t.profdata
-// RUN: %clang_cc1 -triple x86_64-apple-macosx10.9 -main-file-name objc-general.m %s -o - -emit-llvm -fblocks -fprofile-instrument-use-path=%t.profdata | FileCheck -check-prefix=PGOUSE %s
+// RUN: %clang_cc1 -triple x86_64-apple-macosx10.9 -main-file-name objc-general.m %s -o - -emit-llvm -fblocks -fprof

[PATCH] D39438: [analyzer] Diagnose stack leaks via block captures

2017-11-01 Thread Alexander Shaposhnikov via Phabricator via cfe-commits
alexshap updated this revision to Diff 121229.
alexshap added a comment.

Refactor the checker, add more tests.


Repository:
  rL LLVM

https://reviews.llvm.org/D39438

Files:
  lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp
  test/Analysis/stack-capture-leak-arc.mm
  test/Analysis/stack-capture-leak-no-arc.mm

Index: test/Analysis/stack-capture-leak-no-arc.mm
===
--- test/Analysis/stack-capture-leak-no-arc.mm
+++ test/Analysis/stack-capture-leak-no-arc.mm
@@ -0,0 +1,23 @@
+// RUN: %clang_analyze_cc1 -triple x86_64-apple-darwin10 -analyzer-checker=core -fblocks -verify %s
+
+typedef struct dispatch_queue_s *dispatch_queue_t;
+typedef void (^dispatch_block_t)(void);
+void dispatch_async(dispatch_queue_t queue, dispatch_block_t block);
+extern dispatch_queue_t queue;
+
+void test_block_inside_block_async_leak_without_arc() {
+  int x = 123;
+  int *p = &x;
+  void (^inner)(void) = ^void(void) {
+int y = x;
+++y; 
+  };
+  dispatch_async(queue, ^void(void) {
+int z = x;
+++z;
+inner(); 
+  });
+  // expected-warning-re@-5{{Address of stack-allocated block declared on line {{.+}} \
+is captured by an asynchronously-executed block}}
+}
+
Index: test/Analysis/stack-capture-leak-arc.mm
===
--- test/Analysis/stack-capture-leak-arc.mm
+++ test/Analysis/stack-capture-leak-arc.mm
@@ -0,0 +1,164 @@
+// RUN: %clang_analyze_cc1 -triple x86_64-apple-darwin10 -analyzer-checker=core -fblocks -fobjc-arc -verify %s
+
+typedef struct dispatch_queue_s *dispatch_queue_t;
+typedef void (^dispatch_block_t)(void);
+void dispatch_async(dispatch_queue_t queue, dispatch_block_t block);
+typedef long dispatch_once_t;
+void dispatch_once(dispatch_once_t *predicate, dispatch_block_t block);
+typedef long dispatch_time_t;
+void dispatch_after(dispatch_time_t when, dispatch_queue_t queue, dispatch_block_t block);
+
+extern dispatch_queue_t queue;
+extern dispatch_once_t *predicate;
+extern dispatch_time_t when;
+
+void test_block_expr_async() {
+  int x = 123;
+  int *p = &x;
+
+  dispatch_async(queue, ^{
+*p = 321;
+  });
+  // expected-warning@-3 {{Address of stack memory associated with local variable 'x' \
+is captured by an asynchronously-executed block}}
+}
+
+void test_block_expr_once_no_leak() {
+  int x = 123;
+  int *p = &x;
+  // synchronous, no warning
+  dispatch_once(predicate, ^{
+*p = 321;
+  });
+}
+
+void test_block_expr_after() {
+  int x = 123;
+  int *p = &x;
+  dispatch_after(when, queue, ^{
+*p = 321;
+  });
+  // expected-warning@-3 {{Address of stack memory associated with local variable 'x' \
+is captured by an asynchronously-executed block}}
+}
+
+void test_block_expr_async_no_leak() {
+  int x = 123;
+  int *p = &x;
+  // no leak
+  dispatch_async(queue, ^{
+int y = x;
+++y;
+  });
+}
+
+void test_block_var_async() {
+  int x = 123;
+  int *p = &x;
+  void (^b)(void) = ^void(void) {
+*p = 1; 
+  };
+  dispatch_async(queue, b);
+  // expected-warning@-1 {{Address of stack memory associated with local variable 'x' \
+is captured by an asynchronously-executed block}}
+}
+
+void test_block_with_ref_async() {
+  int x = 123;
+  int &r = x;
+  void (^b)(void) = ^void(void) {
+r = 1; 
+  };
+  dispatch_async(queue, b);
+  // expected-warning@-1 {{Address of stack memory associated with local variable 'x' \
+is captured by an asynchronously-executed block}}
+}
+
+dispatch_block_t get_leaking_block() {
+  int leaked_x = 791;
+  int *p = &leaked_x;
+  return ^void(void) {
+*p = 1; 
+  };
+  // expected-warning@-3 {{Address of stack memory associated with local variable 'leaked_x' \
+is captured by a returned block}}
+}
+
+void test_returned_from_func_block_async() {
+  dispatch_async(queue, get_leaking_block());
+  // expected-warning@-1 {{Address of stack memory associated with local variable 'leaked_x' \
+is captured by an asynchronously-executed block}}
+}
+
+// synchronous, no leak
+void test_block_var_once() {
+  int x = 123;
+  int *p = &x;
+  void (^b)(void) = ^void(void) {
+*p = 1; 
+  };
+  // no leak
+  dispatch_once(predicate, b);
+}
+
+void test_block_var_after() {
+  int x = 123;
+  int *p = &x;
+  void (^b)(void) = ^void(void) {
+*p = 1; 
+  };
+  dispatch_after(when, queue, b);
+  // expected-warning@-1 {{Address of stack memory associated with local variable 'x' \
+is captured by an asynchronously-executed block}}
+}
+
+void test_block_var_async_no_leak() {
+  int x = 123;
+  int *p = &x;
+  void (^b)(void) = ^void(void) {
+int y = x;
+++y; 
+  };
+  // no leak
+  dispatch_async(queue, b);
+}
+
+void test_block_inside_block_async_no_leak() {
+  int x = 123;
+  int *p = &x;
+  void (^inner)(void) = ^void(void) {
+int y = x;
+++y; 
+  };
+  void (^outer)(void) = ^void(void) {
+int z = x;
+++z;
+inner(); 
+  };
+  // no leak
+  dispatch_async(queue, outer);
+}
+
+@interface NSObject
+@en

[PATCH] D39438: [analyzer] Diagnose stack leaks via block captures

2017-11-01 Thread Alexander Shaposhnikov via Phabricator via cfe-commits
alexshap added inline comments.



Comment at: test/Analysis/stack-async-leak.m:1
+// RUN: %clang_analyze_cc1 -triple x86_64-apple-darwin10 
-analyzer-checker=core -fblocks -fobjc-arc -verify %s
+

dcoughlin wrote:
> Can you add an additional run line testing the expected behavior when ARC is 
> not enabled? You can pass a -DARC_ENABLED=1 or similar to distinguish between 
> the two (for example, to test to make sure that a diagnostic is emitted under 
> MRR but not ARC).
i've tried this, it somehow gets more complicated to read / change the tests - 
decided to create a separate file.


Repository:
  rL LLVM

https://reviews.llvm.org/D39438



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


[PATCH] D39438: [analyzer] Diagnose stack leaks via block captures

2017-11-01 Thread Alexander Shaposhnikov via Phabricator via cfe-commits
alexshap updated this revision to Diff 121230.
alexshap added a comment.

Add more tests for blocks being passed around


Repository:
  rL LLVM

https://reviews.llvm.org/D39438

Files:
  lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp
  test/Analysis/stack-capture-leak-arc.mm
  test/Analysis/stack-capture-leak-no-arc.mm

Index: test/Analysis/stack-capture-leak-no-arc.mm
===
--- test/Analysis/stack-capture-leak-no-arc.mm
+++ test/Analysis/stack-capture-leak-no-arc.mm
@@ -0,0 +1,23 @@
+// RUN: %clang_analyze_cc1 -triple x86_64-apple-darwin10 -analyzer-checker=core -fblocks -verify %s
+
+typedef struct dispatch_queue_s *dispatch_queue_t;
+typedef void (^dispatch_block_t)(void);
+void dispatch_async(dispatch_queue_t queue, dispatch_block_t block);
+extern dispatch_queue_t queue;
+
+void test_block_inside_block_async_leak_without_arc() {
+  int x = 123;
+  int *p = &x;
+  void (^inner)(void) = ^void(void) {
+int y = x;
+++y; 
+  };
+  dispatch_async(queue, ^void(void) {
+int z = x;
+++z;
+inner(); 
+  });
+  // expected-warning-re@-5{{Address of stack-allocated block declared on line {{.+}} \
+is captured by an asynchronously-executed block}}
+}
+
Index: test/Analysis/stack-capture-leak-arc.mm
===
--- test/Analysis/stack-capture-leak-arc.mm
+++ test/Analysis/stack-capture-leak-arc.mm
@@ -0,0 +1,178 @@
+// RUN: %clang_analyze_cc1 -triple x86_64-apple-darwin10 -analyzer-checker=core -fblocks -fobjc-arc -verify %s
+
+typedef struct dispatch_queue_s *dispatch_queue_t;
+typedef void (^dispatch_block_t)(void);
+void dispatch_async(dispatch_queue_t queue, dispatch_block_t block);
+typedef long dispatch_once_t;
+void dispatch_once(dispatch_once_t *predicate, dispatch_block_t block);
+typedef long dispatch_time_t;
+void dispatch_after(dispatch_time_t when, dispatch_queue_t queue, dispatch_block_t block);
+
+extern dispatch_queue_t queue;
+extern dispatch_once_t *predicate;
+extern dispatch_time_t when;
+
+void test_block_expr_async() {
+  int x = 123;
+  int *p = &x;
+
+  dispatch_async(queue, ^{
+*p = 321;
+  });
+  // expected-warning@-3 {{Address of stack memory associated with local variable 'x' \
+is captured by an asynchronously-executed block}}
+}
+
+void test_block_expr_once_no_leak() {
+  int x = 123;
+  int *p = &x;
+  // synchronous, no warning
+  dispatch_once(predicate, ^{
+*p = 321;
+  });
+}
+
+void test_block_expr_after() {
+  int x = 123;
+  int *p = &x;
+  dispatch_after(when, queue, ^{
+*p = 321;
+  });
+  // expected-warning@-3 {{Address of stack memory associated with local variable 'x' \
+is captured by an asynchronously-executed block}}
+}
+
+void test_block_expr_async_no_leak() {
+  int x = 123;
+  int *p = &x;
+  // no leak
+  dispatch_async(queue, ^{
+int y = x;
+++y;
+  });
+}
+
+void test_block_var_async() {
+  int x = 123;
+  int *p = &x;
+  void (^b)(void) = ^void(void) {
+*p = 1; 
+  };
+  dispatch_async(queue, b);
+  // expected-warning@-1 {{Address of stack memory associated with local variable 'x' \
+is captured by an asynchronously-executed block}}
+}
+
+void test_block_with_ref_async() {
+  int x = 123;
+  int &r = x;
+  void (^b)(void) = ^void(void) {
+r = 1; 
+  };
+  dispatch_async(queue, b);
+  // expected-warning@-1 {{Address of stack memory associated with local variable 'x' \
+is captured by an asynchronously-executed block}}
+}
+
+dispatch_block_t get_leaking_block() {
+  int leaked_x = 791;
+  int *p = &leaked_x;
+  return ^void(void) {
+*p = 1; 
+  };
+  // expected-warning@-3 {{Address of stack memory associated with local variable 'leaked_x' \
+is captured by a returned block}}
+}
+
+void test_returned_from_func_block_async() {
+  dispatch_async(queue, get_leaking_block());
+  // expected-warning@-1 {{Address of stack memory associated with local variable 'leaked_x' \
+is captured by an asynchronously-executed block}}
+}
+
+// synchronous, no leak
+void test_block_var_once() {
+  int x = 123;
+  int *p = &x;
+  void (^b)(void) = ^void(void) {
+*p = 1; 
+  };
+  // no leak
+  dispatch_once(predicate, b);
+}
+
+void test_block_var_after() {
+  int x = 123;
+  int *p = &x;
+  void (^b)(void) = ^void(void) {
+*p = 1; 
+  };
+  dispatch_after(when, queue, b);
+  // expected-warning@-1 {{Address of stack memory associated with local variable 'x' \
+is captured by an asynchronously-executed block}}
+}
+
+void test_block_var_async_no_leak() {
+  int x = 123;
+  int *p = &x;
+  void (^b)(void) = ^void(void) {
+int y = x;
+++y; 
+  };
+  // no leak
+  dispatch_async(queue, b);
+}
+
+void test_block_inside_block_async_no_leak() {
+  int x = 123;
+  int *p = &x;
+  void (^inner)(void) = ^void(void) {
+int y = x;
+++y; 
+  };
+  void (^outer)(void) = ^void(void) {
+int z = x;
+++z;
+inner(); 
+  };
+  // no leak
+  dispatch_async(queue, outer);
+}
+
+dispatch_block_t

[clang-tools-extra] r317155 - [clang-tidy] Clean up installation rules

2017-11-01 Thread Shoaib Meenai via cfe-commits
Author: smeenai
Date: Wed Nov  1 18:48:20 2017
New Revision: 317155

URL: http://llvm.org/viewvc/llvm-project?rev=317155&view=rev
Log:
[clang-tidy] Clean up installation rules

An installation rule for the executable with the correct component is
already created by `add_clang_tool`, so the rule in this file is
redundant. Correct the installation component for the Python scripts so
that they also get installed by `install-clang-tidy`.

Modified:
clang-tools-extra/trunk/clang-tidy/tool/CMakeLists.txt

Modified: clang-tools-extra/trunk/clang-tidy/tool/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/tool/CMakeLists.txt?rev=317155&r1=317154&r2=317155&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/tool/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clang-tidy/tool/CMakeLists.txt Wed Nov  1 18:48:20 
2017
@@ -34,8 +34,9 @@ target_link_libraries(clang-tidy
   clangToolingCore
   )
 
-install(TARGETS clang-tidy
-  RUNTIME DESTINATION bin)
-
-install(PROGRAMS clang-tidy-diff.py DESTINATION share/clang)
-install(PROGRAMS run-clang-tidy.py DESTINATION share/clang)
+install(PROGRAMS clang-tidy-diff.py
+  DESTINATION share/clang
+  COMPONENT clang-tidy)
+install(PROGRAMS run-clang-tidy.py
+  DESTINATION share/clang
+  COMPONENT clang-tidy)


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


[libcxx] r317165 - Creating release candidate rc1 from release_501 branch

2017-11-01 Thread Tom Stellard via cfe-commits
Author: tstellar
Date: Wed Nov  1 18:55:53 2017
New Revision: 317165

URL: http://llvm.org/viewvc/llvm-project?rev=317165&view=rev
Log:
Creating release candidate rc1 from release_501 branch

Added:
libcxx/tags/RELEASE_501/rc1/   (props changed)
  - copied from r317164, libcxx/branches/release_50/

Propchange: libcxx/tags/RELEASE_501/rc1/
--
--- svn:mergeinfo (added)
+++ svn:mergeinfo Wed Nov  1 18:55:53 2017
@@ -0,0 +1,2 @@
+/libcxx/branches/apple:136569-137939
+/libcxx/trunk:309296,309307,309474,309838,309851,309917,309920


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


[libcxx] r317164 - Creating release directory for release_501.

2017-11-01 Thread Tom Stellard via cfe-commits
Author: tstellar
Date: Wed Nov  1 18:55:46 2017
New Revision: 317164

URL: http://llvm.org/viewvc/llvm-project?rev=317164&view=rev
Log:
Creating release directory for release_501.

Added:
libcxx/tags/RELEASE_501/

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


[libcxxabi] r317166 - Creating release directory for release_501.

2017-11-01 Thread Tom Stellard via cfe-commits
Author: tstellar
Date: Wed Nov  1 18:55:55 2017
New Revision: 317166

URL: http://llvm.org/viewvc/llvm-project?rev=317166&view=rev
Log:
Creating release directory for release_501.

Added:
libcxxabi/tags/RELEASE_501/

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


[libcxxabi] r317167 - Creating release candidate rc1 from release_501 branch

2017-11-01 Thread Tom Stellard via cfe-commits
Author: tstellar
Date: Wed Nov  1 18:55:58 2017
New Revision: 317167

URL: http://llvm.org/viewvc/llvm-project?rev=317167&view=rev
Log:
Creating release candidate rc1 from release_501 branch

Added:
libcxxabi/tags/RELEASE_501/rc1/
  - copied from r317166, libcxxabi/branches/release_50/

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


[libunwind] r317178 - Creating release directory for release_501.

2017-11-01 Thread Tom Stellard via cfe-commits
Author: tstellar
Date: Wed Nov  1 18:56:29 2017
New Revision: 317178

URL: http://llvm.org/viewvc/llvm-project?rev=317178&view=rev
Log:
Creating release directory for release_501.

Added:
libunwind/tags/RELEASE_501/

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


[libunwind] r317179 - Creating release candidate rc1 from release_501 branch

2017-11-01 Thread Tom Stellard via cfe-commits
Author: tstellar
Date: Wed Nov  1 18:56:32 2017
New Revision: 317179

URL: http://llvm.org/viewvc/llvm-project?rev=317179&view=rev
Log:
Creating release candidate rc1 from release_501 branch

Added:
libunwind/tags/RELEASE_501/rc1/   (props changed)
  - copied from r317178, libunwind/branches/release_50/

Propchange: libunwind/tags/RELEASE_501/rc1/
--
svn:mergeinfo = /libunwind/trunk:308871,309147


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


[PATCH] D38986: [Analyzer] Better unreachable message in enumeration

2017-11-01 Thread George Karpenkov via Phabricator via cfe-commits
george.karpenkov added a comment.

@dcoughlin @NoQ so can this be committed?


https://reviews.llvm.org/D38986



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


[PATCH] D39438: [analyzer] Diagnose stack leaks via block captures

2017-11-01 Thread Alexander Shaposhnikov via Phabricator via cfe-commits
alexshap added inline comments.



Comment at: test/Analysis/stack-capture-leak-arc.mm:68
+  int x = 123;
+  int &r = x;
+  void (^b)(void) = ^void(void) {

c++ reference


Repository:
  rL LLVM

https://reviews.llvm.org/D39438



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


[PATCH] D39505: [OpenMP] Show error if VLAs are not supported

2017-11-01 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: include/clang/Basic/TargetInfo.h:944
+  /// \brief Whether target supports variable-length arrays.
+  bool isVLASupported() const { return VLASupported; }
+

The way you've written this makes it sound like "does the target support 
VLAs?", but the actual semantic checks treat it as "do OpenMP devices on this 
target support VLAs?"  Maybe there should be a more specific way to query 
things about OpenMP devices instead of setting a global flag for the target?


https://reviews.llvm.org/D39505



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


[PATCH] D38986: [Analyzer] Better unreachable message in enumeration

2017-11-01 Thread Devin Coughlin via Phabricator via cfe-commits
dcoughlin added a comment.

Personally, I don't think this is worth it and I find it unpleasant to add 
untestable code -- especially if that code is going to stick around in release 
builds.


https://reviews.llvm.org/D38986



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


[PATCH] D39524: [libclang] Add dummy libclang-headers target

2017-11-01 Thread Argyrios Kyrtzidis via Phabricator via cfe-commits
akyrtzi accepted this revision.
akyrtzi added a comment.
This revision is now accepted and ready to land.

LGTM.


https://reviews.llvm.org/D39524



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


[clang-tools-extra] r317187 - [clangd] Remove redundant install

2017-11-01 Thread Shoaib Meenai via cfe-commits
Author: smeenai
Date: Wed Nov  1 22:02:24 2017
New Revision: 317187

URL: http://llvm.org/viewvc/llvm-project?rev=317187&view=rev
Log:
[clangd] Remove redundant install

`add_clang_tool` already adds the install command, so the one here is
redundant.

Modified:
clang-tools-extra/trunk/clangd/tool/CMakeLists.txt

Modified: clang-tools-extra/trunk/clangd/tool/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/tool/CMakeLists.txt?rev=317187&r1=317186&r2=317187&view=diff
==
--- clang-tools-extra/trunk/clangd/tool/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clangd/tool/CMakeLists.txt Wed Nov  1 22:02:24 2017
@@ -4,8 +4,6 @@ add_clang_tool(clangd
   ClangdMain.cpp
   )
 
-install(TARGETS clangd RUNTIME DESTINATION bin)
-
 set(LLVM_LINK_COMPONENTS
   support
   )


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


r317188 - [libclang] Add dummy libclang-headers target

2017-11-01 Thread Shoaib Meenai via cfe-commits
Author: smeenai
Date: Wed Nov  1 22:04:00 2017
New Revision: 317188

URL: http://llvm.org/viewvc/llvm-project?rev=317188&view=rev
Log:
[libclang] Add dummy libclang-headers target

`LLVM_DISTRIBUTION_COMPONENTS` assumes that each component has both
`component` and `install-component` targets. Add a dummy no-op target
for `libclang-headers` to placate this check.

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

Modified:
cfe/trunk/tools/libclang/CMakeLists.txt

Modified: cfe/trunk/tools/libclang/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/libclang/CMakeLists.txt?rev=317188&r1=317187&r2=317188&view=diff
==
--- cfe/trunk/tools/libclang/CMakeLists.txt (original)
+++ cfe/trunk/tools/libclang/CMakeLists.txt Wed Nov  1 22:04:00 2017
@@ -141,6 +141,11 @@ install(DIRECTORY ../../include/clang-c
   PATTERN ".svn" EXCLUDE
   )
 
+# LLVM_DISTRIBUTION_COMPONENTS requires that each component have both a
+# component and an install-component target, so add a dummy libclang-headers
+# target to allow using it in LLVM_DISTRIBUTION_COMPONENTS.
+add_custom_target(libclang-headers)
+
 if (NOT CMAKE_CONFIGURATION_TYPES) # don't add this for IDE's.
   add_custom_target(install-libclang-headers
 DEPENDS


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


[PATCH] D39524: [libclang] Add dummy libclang-headers target

2017-11-01 Thread Shoaib Meenai via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL317188: [libclang] Add dummy libclang-headers target 
(authored by smeenai).

Repository:
  rL LLVM

https://reviews.llvm.org/D39524

Files:
  cfe/trunk/tools/libclang/CMakeLists.txt


Index: cfe/trunk/tools/libclang/CMakeLists.txt
===
--- cfe/trunk/tools/libclang/CMakeLists.txt
+++ cfe/trunk/tools/libclang/CMakeLists.txt
@@ -141,6 +141,11 @@
   PATTERN ".svn" EXCLUDE
   )
 
+# LLVM_DISTRIBUTION_COMPONENTS requires that each component have both a
+# component and an install-component target, so add a dummy libclang-headers
+# target to allow using it in LLVM_DISTRIBUTION_COMPONENTS.
+add_custom_target(libclang-headers)
+
 if (NOT CMAKE_CONFIGURATION_TYPES) # don't add this for IDE's.
   add_custom_target(install-libclang-headers
 DEPENDS


Index: cfe/trunk/tools/libclang/CMakeLists.txt
===
--- cfe/trunk/tools/libclang/CMakeLists.txt
+++ cfe/trunk/tools/libclang/CMakeLists.txt
@@ -141,6 +141,11 @@
   PATTERN ".svn" EXCLUDE
   )
 
+# LLVM_DISTRIBUTION_COMPONENTS requires that each component have both a
+# component and an install-component target, so add a dummy libclang-headers
+# target to allow using it in LLVM_DISTRIBUTION_COMPONENTS.
+add_custom_target(libclang-headers)
+
 if (NOT CMAKE_CONFIGURATION_TYPES) # don't add this for IDE's.
   add_custom_target(install-libclang-headers
 DEPENDS
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D39251: [libunwind] Fix building for ARM with dwarf exception handling

2017-11-01 Thread Saleem Abdulrasool via Phabricator via cfe-commits
compnerd accepted this revision.
compnerd added inline comments.
This revision is now accepted and ready to land.



Comment at: src/Registers.hpp:1481
+  mutable uint32_t _iwmmx_control[4];
 #endif
 };

Why the change to mark these as mutable?


https://reviews.llvm.org/D39251



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


[PATCH] D39114: [XRay] Initial XRay in Darwin Support

2017-11-01 Thread Dean Michael Berris via Phabricator via cfe-commits
dberris added a comment.

@kubamracek -- if you don't mind having a look at this, I'm looking for 
thoughts/feedback on how we can address the "blockers":

- Assembly for Darwin x86_64 and how we avoid the ELF'isms (do we need to 
implement darwin-specific assembly for MachO?)
- Syscalls, testing, etc. -- whether we need to do anything special here for 
making it work on macOS.


https://reviews.llvm.org/D39114



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