[PATCH] D62616: [CodeComplete] Add a bit more whitespace to completed patterns

2019-06-03 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov added a comment.

In D62616#1522284 , @gribozavr wrote:

> I totally agree about the space before the opening curly, but the space 
> before the opening paren is a matter of style.  Certainly it does match LLVM 
> style better, but it does not match some other styles.
>
> I guess there's no way to satisfy everyone without an automatic reformatter, 
> and if we were to pick a "default" style it might as well be LLVM, so I 
> approve.


Totally agree. I was also torn on this, but since there's no reasonable way to 
get the formatting options on code completion now, matching the LLVM style 
looks like the best trade-off.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62616



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


[PATCH] D61967: [clang-tidy] Add a close-on-exec check on pipe() in Android module.

2019-06-03 Thread Dmitri Gribenko via Phabricator via cfe-commits
gribozavr accepted this revision.
gribozavr added inline comments.
This revision is now accepted and ready to land.



Comment at: clang-tools-extra/test/clang-tidy/android-cloexec-pipe.cpp:5
+
+void f() {
+  int pipefd[2];

Please give the tests informative names instead of `f`, `g` etc.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61967



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


[PATCH] D62736: [clang-tidy] Fix make-unique check to work in C++17 mode.

2019-06-03 Thread Haojian Wu via Phabricator via cfe-commits
hokein marked 2 inline comments as done.
hokein added inline comments.



Comment at: clang-tools-extra/clang-tidy/modernize/MakeSmartPtrCheck.cpp:311
+  }
+}
+if (CEArg->isStdInitListInitialization())

gribozavr wrote:
> So `Foo(Bar{1, 2})` is not problematic, it is just that we can't tell it 
> apart from `Foo({1,2})`?
Yes, the `Foo(Bar{1, 2})` is not problematic, we should ignore this case, as 
discussed, I'll change it in a follow-up patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62736



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


[PATCH] D62736: [clang-tidy] Fix make-unique check to work in C++17 mode.

2019-06-03 Thread Haojian Wu via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
hokein marked an inline comment as done.
Closed by commit rL362361: [clang-tidy] Fix make-unique check to work in C++17 
mode. (authored by hokein, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D62736?vs=202434&id=202659#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D62736

Files:
  clang-tools-extra/trunk/clang-tidy/modernize/MakeSmartPtrCheck.cpp
  clang-tools-extra/trunk/test/clang-tidy/modernize-make-unique.cpp


Index: clang-tools-extra/trunk/test/clang-tidy/modernize-make-unique.cpp
===
--- clang-tools-extra/trunk/test/clang-tidy/modernize-make-unique.cpp
+++ clang-tools-extra/trunk/test/clang-tidy/modernize-make-unique.cpp
@@ -1,5 +1,5 @@
-// RUN: %check_clang_tidy -std=c++14 %s modernize-make-unique %t -- -- -I 
%S/Inputs/modernize-smart-ptr
-// FIXME: Fix the checker to work in C++17 mode.
+// RUN: %check_clang_tidy -std=c++14,c++17 %s modernize-make-unique %t -- -- 
-I %S/Inputs/modernize-smart-ptr
+// FIXME: Fix the test code in C++2a mode.
 
 #include "unique_ptr.h"
 #include "initializer_list.h"
@@ -455,10 +455,10 @@
 
   std::unique_ptr PJ2 = std::unique_ptr(new J(E{1, 2}, 1));
   // CHECK-MESSAGES: :[[@LINE-1]]:28: warning: use std::make_unique instead
-  // CHECK-FIXES: std::unique_ptr PJ2 = std::make_unique(E{1, 2}, 1);
+  // CHECK-FIXES: std::unique_ptr PJ2 = std::unique_ptr(new J(E{1, 2}, 
1));
   PJ2.reset(new J(E{1, 2}, 1));
   // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use std::make_unique instead
-  // CHECK-FIXES: PJ2 = std::make_unique(E{1, 2}, 1);
+  // CHECK-FIXES: PJ2.reset(new J(E{1, 2}, 1));
 
   std::unique_ptr PJ3 = std::unique_ptr(new J{ {1, 2}, 1 });
   // CHECK-MESSAGES: :[[@LINE-1]]:28: warning: use std::make_unique instead
@@ -469,10 +469,10 @@
 
   std::unique_ptr PJ4 = std::unique_ptr(new J{E{1, 2}, 1});
   // CHECK-MESSAGES: :[[@LINE-1]]:28: warning: use std::make_unique instead
-  // CHECK-FIXES: std::unique_ptr PJ4 = std::make_unique(E{1, 2}, 1);
+  // CHECK-FIXES: std::unique_ptr PJ4 = std::unique_ptr(new J{E{1, 2}, 
1});
   PJ4.reset(new J{E{1, 2}, 1});
   // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use std::make_unique instead
-  // CHECK-FIXES:  PJ4 = std::make_unique(E{1, 2}, 1);
+  // CHECK-FIXES: PJ4.reset(new J{E{1, 2}, 1});
 
   std::unique_ptr FF = std::unique_ptr(new Foo());
   // CHECK-MESSAGES: :[[@LINE-1]]:29: warning:
Index: clang-tools-extra/trunk/clang-tidy/modernize/MakeSmartPtrCheck.cpp
===
--- clang-tools-extra/trunk/clang-tidy/modernize/MakeSmartPtrCheck.cpp
+++ clang-tools-extra/trunk/clang-tidy/modernize/MakeSmartPtrCheck.cpp
@@ -298,11 +298,20 @@
 return true;
   // Check whether we implicitly construct a class from a
   // std::initializer_list.
-  if (const auto *ImplicitCE = dyn_cast(Arg)) {
-if (ImplicitCE->isStdInitListInitialization())
+  if (const auto *CEArg = dyn_cast(Arg)) {
+// Strip the elidable move constructor, it is present in the AST for
+// C++11/14, e.g. Foo(Bar{1, 2}), the move constructor is around the
+// init-list constructor.
+if (CEArg->isElidable()) {
+  if (const auto *TempExp = CEArg->getArg(0)) {
+if (const auto *UnwrappedCE =
+dyn_cast(TempExp->IgnoreImplicit()))
+  CEArg = UnwrappedCE;
+  }
+}
+if (CEArg->isStdInitListInitialization())
   return true;
   }
-  return false;
 }
 return false;
   };


Index: clang-tools-extra/trunk/test/clang-tidy/modernize-make-unique.cpp
===
--- clang-tools-extra/trunk/test/clang-tidy/modernize-make-unique.cpp
+++ clang-tools-extra/trunk/test/clang-tidy/modernize-make-unique.cpp
@@ -1,5 +1,5 @@
-// RUN: %check_clang_tidy -std=c++14 %s modernize-make-unique %t -- -- -I %S/Inputs/modernize-smart-ptr
-// FIXME: Fix the checker to work in C++17 mode.
+// RUN: %check_clang_tidy -std=c++14,c++17 %s modernize-make-unique %t -- -- -I %S/Inputs/modernize-smart-ptr
+// FIXME: Fix the test code in C++2a mode.
 
 #include "unique_ptr.h"
 #include "initializer_list.h"
@@ -455,10 +455,10 @@
 
   std::unique_ptr PJ2 = std::unique_ptr(new J(E{1, 2}, 1));
   // CHECK-MESSAGES: :[[@LINE-1]]:28: warning: use std::make_unique instead
-  // CHECK-FIXES: std::unique_ptr PJ2 = std::make_unique(E{1, 2}, 1);
+  // CHECK-FIXES: std::unique_ptr PJ2 = std::unique_ptr(new J(E{1, 2}, 1));
   PJ2.reset(new J(E{1, 2}, 1));
   // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use std::make_unique instead
-  // CHECK-FIXES: PJ2 = std::make_unique(E{1, 2}, 1);
+  // CHECK-FIXES: PJ2.reset(new J(E{1, 2}, 1));
 
   std::unique_ptr PJ3 

[clang-tools-extra] r362361 - [clang-tidy] Fix make-unique check to work in C++17 mode.

2019-06-03 Thread Haojian Wu via cfe-commits
Author: hokein
Date: Mon Jun  3 01:14:15 2019
New Revision: 362361

URL: http://llvm.org/viewvc/llvm-project?rev=362361&view=rev
Log:
[clang-tidy] Fix make-unique check to work in C++17 mode.

Summary:
Previously, we intended to omit the check fix to the case when constructor has
any braced-init-list argument. But the HasListInitializedArgument was not
correct to handle all cases (Foo(Bar{1, 2}) will return false in C++14
mode).

This patch fixes it, corrects the tests, and makes the check to run at C++17 
mode.

Reviewers: gribozavr

Subscribers: xazax.hun, cfe-commits

Tags: #clang

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

Modified:
clang-tools-extra/trunk/clang-tidy/modernize/MakeSmartPtrCheck.cpp
clang-tools-extra/trunk/test/clang-tidy/modernize-make-unique.cpp

Modified: clang-tools-extra/trunk/clang-tidy/modernize/MakeSmartPtrCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/modernize/MakeSmartPtrCheck.cpp?rev=362361&r1=362360&r2=362361&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/modernize/MakeSmartPtrCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/modernize/MakeSmartPtrCheck.cpp Mon Jun  
3 01:14:15 2019
@@ -298,11 +298,20 @@ bool MakeSmartPtrCheck::replaceNew(Diagn
 return true;
   // Check whether we implicitly construct a class from a
   // std::initializer_list.
-  if (const auto *ImplicitCE = dyn_cast(Arg)) {
-if (ImplicitCE->isStdInitListInitialization())
+  if (const auto *CEArg = dyn_cast(Arg)) {
+// Strip the elidable move constructor, it is present in the AST for
+// C++11/14, e.g. Foo(Bar{1, 2}), the move constructor is around the
+// init-list constructor.
+if (CEArg->isElidable()) {
+  if (const auto *TempExp = CEArg->getArg(0)) {
+if (const auto *UnwrappedCE =
+dyn_cast(TempExp->IgnoreImplicit()))
+  CEArg = UnwrappedCE;
+  }
+}
+if (CEArg->isStdInitListInitialization())
   return true;
   }
-  return false;
 }
 return false;
   };

Modified: clang-tools-extra/trunk/test/clang-tidy/modernize-make-unique.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/modernize-make-unique.cpp?rev=362361&r1=362360&r2=362361&view=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/modernize-make-unique.cpp (original)
+++ clang-tools-extra/trunk/test/clang-tidy/modernize-make-unique.cpp Mon Jun  
3 01:14:15 2019
@@ -1,5 +1,5 @@
-// RUN: %check_clang_tidy -std=c++14 %s modernize-make-unique %t -- -- -I 
%S/Inputs/modernize-smart-ptr
-// FIXME: Fix the checker to work in C++17 mode.
+// RUN: %check_clang_tidy -std=c++14,c++17 %s modernize-make-unique %t -- -- 
-I %S/Inputs/modernize-smart-ptr
+// FIXME: Fix the test code in C++2a mode.
 
 #include "unique_ptr.h"
 #include "initializer_list.h"
@@ -455,10 +455,10 @@ void initialization(int T, Base b) {
 
   std::unique_ptr PJ2 = std::unique_ptr(new J(E{1, 2}, 1));
   // CHECK-MESSAGES: :[[@LINE-1]]:28: warning: use std::make_unique instead
-  // CHECK-FIXES: std::unique_ptr PJ2 = std::make_unique(E{1, 2}, 1);
+  // CHECK-FIXES: std::unique_ptr PJ2 = std::unique_ptr(new J(E{1, 2}, 
1));
   PJ2.reset(new J(E{1, 2}, 1));
   // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use std::make_unique instead
-  // CHECK-FIXES: PJ2 = std::make_unique(E{1, 2}, 1);
+  // CHECK-FIXES: PJ2.reset(new J(E{1, 2}, 1));
 
   std::unique_ptr PJ3 = std::unique_ptr(new J{ {1, 2}, 1 });
   // CHECK-MESSAGES: :[[@LINE-1]]:28: warning: use std::make_unique instead
@@ -469,10 +469,10 @@ void initialization(int T, Base b) {
 
   std::unique_ptr PJ4 = std::unique_ptr(new J{E{1, 2}, 1});
   // CHECK-MESSAGES: :[[@LINE-1]]:28: warning: use std::make_unique instead
-  // CHECK-FIXES: std::unique_ptr PJ4 = std::make_unique(E{1, 2}, 1);
+  // CHECK-FIXES: std::unique_ptr PJ4 = std::unique_ptr(new J{E{1, 2}, 
1});
   PJ4.reset(new J{E{1, 2}, 1});
   // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: use std::make_unique instead
-  // CHECK-FIXES:  PJ4 = std::make_unique(E{1, 2}, 1);
+  // CHECK-FIXES: PJ4.reset(new J{E{1, 2}, 1});
 
   std::unique_ptr FF = std::unique_ptr(new Foo());
   // CHECK-MESSAGES: :[[@LINE-1]]:29: warning:


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


r362363 - [CodeComplete] Add a bit more whitespace to completed patterns

2019-06-03 Thread Ilya Biryukov via cfe-commits
Author: ibiryukov
Date: Mon Jun  3 01:34:25 2019
New Revision: 362363

URL: http://llvm.org/viewvc/llvm-project?rev=362363&view=rev
Log:
[CodeComplete] Add a bit more whitespace to completed patterns

Summary:
E.g. we now turn `while(<#cond#>){` into `while (<#cond#>) {`

This slightly improves the final output. Should not affect clients that
format the result on their own.

Reviewers: gribozavr

Reviewed By: gribozavr

Subscribers: jkorous, arphaman, kadircet, cfe-commits

Tags: #clang

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

Modified:
cfe/trunk/lib/Sema/SemaCodeComplete.cpp
cfe/trunk/test/CodeCompletion/ordinary-name-cxx11.cpp
cfe/trunk/test/CodeCompletion/ordinary-name.cpp

Modified: cfe/trunk/lib/Sema/SemaCodeComplete.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaCodeComplete.cpp?rev=362363&r1=362362&r2=362363&view=diff
==
--- cfe/trunk/lib/Sema/SemaCodeComplete.cpp (original)
+++ cfe/trunk/lib/Sema/SemaCodeComplete.cpp Mon Jun  3 01:34:25 2019
@@ -1900,6 +1900,7 @@ static void AddOrdinaryNameResults(Sema:
 Builder.AddTypedTextChunk("namespace");
 Builder.AddChunk(CodeCompletionString::CK_HorizontalSpace);
 Builder.AddPlaceholderChunk("identifier");
+Builder.AddChunk(CodeCompletionString::CK_HorizontalSpace);
 Builder.AddChunk(CodeCompletionString::CK_LeftBrace);
 Builder.AddChunk(CodeCompletionString::CK_VerticalSpace);
 Builder.AddPlaceholderChunk("declarations");
@@ -2048,15 +2049,19 @@ static void AddOrdinaryNameResults(Sema:
 if (SemaRef.getLangOpts().CPlusPlus && Results.includeCodePatterns() &&
 SemaRef.getLangOpts().CXXExceptions) {
   Builder.AddTypedTextChunk("try");
+  Builder.AddChunk(CodeCompletionString::CK_HorizontalSpace);
   Builder.AddChunk(CodeCompletionString::CK_LeftBrace);
   Builder.AddChunk(CodeCompletionString::CK_VerticalSpace);
   Builder.AddPlaceholderChunk("statements");
   Builder.AddChunk(CodeCompletionString::CK_VerticalSpace);
   Builder.AddChunk(CodeCompletionString::CK_RightBrace);
+  Builder.AddChunk(CodeCompletionString::CK_HorizontalSpace);
   Builder.AddTextChunk("catch");
+  Builder.AddChunk(CodeCompletionString::CK_HorizontalSpace);
   Builder.AddChunk(CodeCompletionString::CK_LeftParen);
   Builder.AddPlaceholderChunk("declaration");
   Builder.AddChunk(CodeCompletionString::CK_RightParen);
+  Builder.AddChunk(CodeCompletionString::CK_HorizontalSpace);
   Builder.AddChunk(CodeCompletionString::CK_LeftBrace);
   Builder.AddChunk(CodeCompletionString::CK_VerticalSpace);
   Builder.AddPlaceholderChunk("statements");
@@ -2070,12 +2075,14 @@ static void AddOrdinaryNameResults(Sema:
 if (Results.includeCodePatterns()) {
   // if (condition) { statements }
   Builder.AddTypedTextChunk("if");
+  Builder.AddChunk(CodeCompletionString::CK_HorizontalSpace);
   Builder.AddChunk(CodeCompletionString::CK_LeftParen);
   if (SemaRef.getLangOpts().CPlusPlus)
 Builder.AddPlaceholderChunk("condition");
   else
 Builder.AddPlaceholderChunk("expression");
   Builder.AddChunk(CodeCompletionString::CK_RightParen);
+  Builder.AddChunk(CodeCompletionString::CK_HorizontalSpace);
   Builder.AddChunk(CodeCompletionString::CK_LeftBrace);
   Builder.AddChunk(CodeCompletionString::CK_VerticalSpace);
   Builder.AddPlaceholderChunk("statements");
@@ -2085,12 +2092,14 @@ static void AddOrdinaryNameResults(Sema:
 
   // switch (condition) { }
   Builder.AddTypedTextChunk("switch");
+  Builder.AddChunk(CodeCompletionString::CK_HorizontalSpace);
   Builder.AddChunk(CodeCompletionString::CK_LeftParen);
   if (SemaRef.getLangOpts().CPlusPlus)
 Builder.AddPlaceholderChunk("condition");
   else
 Builder.AddPlaceholderChunk("expression");
   Builder.AddChunk(CodeCompletionString::CK_RightParen);
+  Builder.AddChunk(CodeCompletionString::CK_HorizontalSpace);
   Builder.AddChunk(CodeCompletionString::CK_LeftBrace);
   Builder.AddChunk(CodeCompletionString::CK_VerticalSpace);
   Builder.AddPlaceholderChunk("cases");
@@ -2118,12 +2127,14 @@ static void AddOrdinaryNameResults(Sema:
 if (Results.includeCodePatterns()) {
   /// while (condition) { statements }
   Builder.AddTypedTextChunk("while");
+  Builder.AddChunk(CodeCompletionString::CK_HorizontalSpace);
   Builder.AddChunk(CodeCompletionString::CK_LeftParen);
   if (SemaRef.getLangOpts().CPlusPlus)
 Builder.AddPlaceholderChunk("condition");
   else
 Builder.AddPlaceholderChunk("expression");
   Builder.AddChunk(CodeCompletionString::CK_RightParen);
+  Builder.AddChunk(CodeCompletionString::CK_HorizontalSpace);
   Builder.AddChunk(CodeCompletionString::CK_LeftBrace);
   Builder.AddChunk(CodeCompletionString::CK_Ver

[clang-tools-extra] r362363 - [CodeComplete] Add a bit more whitespace to completed patterns

2019-06-03 Thread Ilya Biryukov via cfe-commits
Author: ibiryukov
Date: Mon Jun  3 01:34:25 2019
New Revision: 362363

URL: http://llvm.org/viewvc/llvm-project?rev=362363&view=rev
Log:
[CodeComplete] Add a bit more whitespace to completed patterns

Summary:
E.g. we now turn `while(<#cond#>){` into `while (<#cond#>) {`

This slightly improves the final output. Should not affect clients that
format the result on their own.

Reviewers: gribozavr

Reviewed By: gribozavr

Subscribers: jkorous, arphaman, kadircet, cfe-commits

Tags: #clang

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

Modified:
clang-tools-extra/trunk/clangd/unittests/CodeCompleteTests.cpp

Modified: clang-tools-extra/trunk/clangd/unittests/CodeCompleteTests.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/unittests/CodeCompleteTests.cpp?rev=362363&r1=362362&r2=362363&view=diff
==
--- clang-tools-extra/trunk/clangd/unittests/CodeCompleteTests.cpp (original)
+++ clang-tools-extra/trunk/clangd/unittests/CodeCompleteTests.cpp Mon Jun  3 
01:34:25 2019
@@ -2436,7 +2436,7 @@ TEST(CompletionTest, CursorInSnippets) {
   EXPECT_THAT(
   Results.Completions,
   Contains(AllOf(Named("while"),
- SnippetSuffix("(${1:condition}){\n${0:statements}\n}";
+ SnippetSuffix(" (${1:condition}) 
{\n${0:statements}\n}";
   // However, snippets for functions must *not* end with $0.
   EXPECT_THAT(Results.Completions,
   Contains(AllOf(Named("while_foo"),


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


[PATCH] D62616: [CodeComplete] Add a bit more whitespace to completed patterns

2019-06-03 Thread Phabricator via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL362363: [CodeComplete] Add a bit more whitespace to 
completed patterns (authored by ibiryukov, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D62616?vs=202011&id=202662#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D62616

Files:
  cfe/trunk/lib/Sema/SemaCodeComplete.cpp
  cfe/trunk/test/CodeCompletion/ordinary-name-cxx11.cpp
  cfe/trunk/test/CodeCompletion/ordinary-name.cpp
  clang-tools-extra/trunk/clangd/unittests/CodeCompleteTests.cpp

Index: clang-tools-extra/trunk/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/trunk/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/trunk/clangd/unittests/CodeCompleteTests.cpp
@@ -2436,7 +2436,7 @@
   EXPECT_THAT(
   Results.Completions,
   Contains(AllOf(Named("while"),
- SnippetSuffix("(${1:condition}){\n${0:statements}\n}";
+ SnippetSuffix(" (${1:condition}) {\n${0:statements}\n}";
   // However, snippets for functions must *not* end with $0.
   EXPECT_THAT(Results.Completions,
   Contains(AllOf(Named("while_foo"),
Index: cfe/trunk/lib/Sema/SemaCodeComplete.cpp
===
--- cfe/trunk/lib/Sema/SemaCodeComplete.cpp
+++ cfe/trunk/lib/Sema/SemaCodeComplete.cpp
@@ -1900,6 +1900,7 @@
 Builder.AddTypedTextChunk("namespace");
 Builder.AddChunk(CodeCompletionString::CK_HorizontalSpace);
 Builder.AddPlaceholderChunk("identifier");
+Builder.AddChunk(CodeCompletionString::CK_HorizontalSpace);
 Builder.AddChunk(CodeCompletionString::CK_LeftBrace);
 Builder.AddChunk(CodeCompletionString::CK_VerticalSpace);
 Builder.AddPlaceholderChunk("declarations");
@@ -2048,15 +2049,19 @@
 if (SemaRef.getLangOpts().CPlusPlus && Results.includeCodePatterns() &&
 SemaRef.getLangOpts().CXXExceptions) {
   Builder.AddTypedTextChunk("try");
+  Builder.AddChunk(CodeCompletionString::CK_HorizontalSpace);
   Builder.AddChunk(CodeCompletionString::CK_LeftBrace);
   Builder.AddChunk(CodeCompletionString::CK_VerticalSpace);
   Builder.AddPlaceholderChunk("statements");
   Builder.AddChunk(CodeCompletionString::CK_VerticalSpace);
   Builder.AddChunk(CodeCompletionString::CK_RightBrace);
+  Builder.AddChunk(CodeCompletionString::CK_HorizontalSpace);
   Builder.AddTextChunk("catch");
+  Builder.AddChunk(CodeCompletionString::CK_HorizontalSpace);
   Builder.AddChunk(CodeCompletionString::CK_LeftParen);
   Builder.AddPlaceholderChunk("declaration");
   Builder.AddChunk(CodeCompletionString::CK_RightParen);
+  Builder.AddChunk(CodeCompletionString::CK_HorizontalSpace);
   Builder.AddChunk(CodeCompletionString::CK_LeftBrace);
   Builder.AddChunk(CodeCompletionString::CK_VerticalSpace);
   Builder.AddPlaceholderChunk("statements");
@@ -2070,12 +2075,14 @@
 if (Results.includeCodePatterns()) {
   // if (condition) { statements }
   Builder.AddTypedTextChunk("if");
+  Builder.AddChunk(CodeCompletionString::CK_HorizontalSpace);
   Builder.AddChunk(CodeCompletionString::CK_LeftParen);
   if (SemaRef.getLangOpts().CPlusPlus)
 Builder.AddPlaceholderChunk("condition");
   else
 Builder.AddPlaceholderChunk("expression");
   Builder.AddChunk(CodeCompletionString::CK_RightParen);
+  Builder.AddChunk(CodeCompletionString::CK_HorizontalSpace);
   Builder.AddChunk(CodeCompletionString::CK_LeftBrace);
   Builder.AddChunk(CodeCompletionString::CK_VerticalSpace);
   Builder.AddPlaceholderChunk("statements");
@@ -2085,12 +2092,14 @@
 
   // switch (condition) { }
   Builder.AddTypedTextChunk("switch");
+  Builder.AddChunk(CodeCompletionString::CK_HorizontalSpace);
   Builder.AddChunk(CodeCompletionString::CK_LeftParen);
   if (SemaRef.getLangOpts().CPlusPlus)
 Builder.AddPlaceholderChunk("condition");
   else
 Builder.AddPlaceholderChunk("expression");
   Builder.AddChunk(CodeCompletionString::CK_RightParen);
+  Builder.AddChunk(CodeCompletionString::CK_HorizontalSpace);
   Builder.AddChunk(CodeCompletionString::CK_LeftBrace);
   Builder.AddChunk(CodeCompletionString::CK_VerticalSpace);
   Builder.AddPlaceholderChunk("cases");
@@ -2118,12 +2127,14 @@
 if (Results.includeCodePatterns()) {
   /// while (condition) { statements }
   Builder.AddTypedTextChunk("while");
+  Builder.AddChunk(CodeCompletionString::CK_HorizontalSpace);
   Builder.AddChunk(CodeCompletionString::CK_LeftParen);
   if (SemaRef.getLangOpts().CPlusPlus)
 Builder.AddPlaceholderChunk("condition");
  

[PATCH] D62471: [clangd] SymbolCollector support for relations

2019-06-03 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet accepted this revision.
kadircet added a comment.
This revision is now accepted and ready to land.

LGTM, thanks!

I suppose there are only two patches left now?

- Exposing relations in `SymbolIndex`.
- Implementing children resolution using that information.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62471



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


[PATCH] D62804: [clangd] Enable extraction of system includes from custom toolchains

2019-06-03 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet created this revision.
kadircet added a reviewer: sammccall.
Herald added subscribers: cfe-commits, arphaman, jkorous, MaskRay, 
ilya-biryukov.
Herald added a project: clang.

Some custom toolchains come with their own header files and compiler
drivers. Those compiler drivers implicitly know about include search path for
those headers. This patch aims to extract that information from drivers and add
it to the command line when invoking clang frontend.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D62804

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
  clang-tools-extra/clangd/GlobalCompilationDatabase.h
  clang-tools-extra/clangd/test/system-include-extractor.test
  clang-tools-extra/clangd/tool/ClangdMain.cpp

Index: clang-tools-extra/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -268,6 +268,13 @@
 "Always used text-based completion")),
 llvm::cl::init(CodeCompleteOptions().RunParser), llvm::cl::Hidden);
 
+static llvm::cl::opt TrustedCompilerDriverGlob(
+"trusted-compiler-driver-glob",
+llvm::cl::desc("Tells clangd to extract system includes from drivers "
+   "maching the glob. Only accepts ** for sequence match and * "
+   "for non-sequence match."),
+llvm::cl::init(""));
+
 namespace {
 
 /// \brief Supports a test URI scheme with relaxed constraints for lit tests.
@@ -521,6 +528,7 @@
 return ClangTidyOptProvider->getOptions(File);
   };
   Opts.SuggestMissingIncludes = SuggestMissingIncludes;
+  Opts.TrustedCompilerDriverGlob = TrustedCompilerDriverGlob;
   llvm::Optional OffsetEncodingFromFlag;
   if (ForceOffsetEncoding != OffsetEncoding::UnsupportedEncoding)
 OffsetEncodingFromFlag = ForceOffsetEncoding;
Index: clang-tools-extra/clangd/test/system-include-extractor.test
===
--- /dev/null
+++ clang-tools-extra/clangd/test/system-include-extractor.test
@@ -0,0 +1,41 @@
+# RUN: rm -rf %t.dir && mkdir -p %t.dir
+
+# RUN: echo '#!/bin/bash' >> %t.dir/my_driver.sh
+# RUN: echo 'echo line to ignore' >> %t.dir/my_driver.sh
+# RUN: echo 'echo \#include \<...\> search starts here:' >> %t.dir/my_driver.sh
+# RUN: echo 'echo %t.dir/my/dir/' >> %t.dir/my_driver.sh
+# RUN: echo 'echo End of search list.' >> %t.dir/my_driver.sh
+# RUN: chmod +x %t.dir/my_driver.sh
+
+# RUN: mkdir -p %t.dir/my/dir
+# RUN: touch %t.dir/my/dir/a.h
+
+# RUN: echo '[{"directory": "%/t.dir", "command": "%/t.dir/my_driver.sh the-file.cpp", "file": "the-file.cpp"}]' > %t.dir/compile_commands.json
+
+# RUN: sed -e "s|INPUT_DIR|%/t.dir|g" %s > %t.test.1
+# On Windows, we need the URI in didOpen to look like "uri":"file:///C:/..."
+# (with the extra slash in the front), so we add it here.
+# RUN: sed -e "s|file://\([A-Z]\):/|file:///\1:/|g" %t.test.1 > %t.test
+
+# RUN: clangd -lit-test -trusted-compiler-driver-glob="**/*.sh" < %t.test | FileCheck -strict-whitespace %t.test
+{"jsonrpc":"2.0","id":0,"method":"initialize","params":{}}
+---
+{
+  "jsonrpc":"2.0",
+  "method":"textDocument/didOpen",
+  "params": {
+"textDocument": {
+  "uri": "file://INPUT_DIR/the-file.cpp",
+  "languageId":"cpp",
+  "version":1,
+  "text":"#include "
+}
+  }
+}
+# CHECK:   "method": "textDocument/publishDiagnostics",
+# CHECK-NEXT:   "params": {
+# CHECK-NEXT: "diagnostics": [],
+---
+{"jsonrpc":"2.0","id":1,"method":"shutdown"}
+---
+{"jsonrpc":"2.0","method":"exit"}
Index: clang-tools-extra/clangd/GlobalCompilationDatabase.h
===
--- clang-tools-extra/clangd/GlobalCompilationDatabase.h
+++ clang-tools-extra/clangd/GlobalCompilationDatabase.h
@@ -91,6 +91,14 @@
   llvm::Optional CompileCommandsDir;
 };
 
+/// Extracts system include search path from trusted drivers and adds them to
+/// the compile flags.
+/// Returns nullptr when \p TrustedCompilerDriverGlob is empty or \p Base is
+/// nullptr.
+std::unique_ptr getSystemIncludeExtractorDatabase(
+llvm::StringRef TrustedCompilerDriverGlob,
+std::unique_ptr Base);
+
 /// Wraps another compilation database, and supports overriding the commands
 /// using an in-memory mapping.
 class OverlayCDB : public GlobalCompilationDatabase {
Index: clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
===
--- clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
+++ clang-tools-extra/clangd/GlobalCompilationDatabase.cpp
@@ -8,12 +8,31 @@
 
 #include "GlobalCompilationDatabase.h"
 #include "Logger.h"
+#include "Path.h"
+#include "Trace.h"
+#include "clang/Driver/Types.h"
 #include "clang/Frontend/CompilerInvocation.h"
 

[PATCH] D61487: [clang-tidy] Make the plugin honor NOLINT

2019-06-03 Thread Dmitri Gribenko via Phabricator via cfe-commits
gribozavr added inline comments.



Comment at: clang-tidy/ClangTidyDiagnosticConsumer.cpp:472
   if (Info.hasSourceManager())
 checkFilters(Info.getLocation(), Info.getSourceManager());
 }

nik wrote:
> gribozavr wrote:
> > It seems like the `checkFilters` call should not be skipped even if we have 
> > another diagnostic engine.
> checkFilters() sets some state so that later finalizeLastError() can remove 
> diagnostics/errors from ClangTidyDiagnosticConsumer::Errors and also track 
> some statistics.
> 
> Statistics are not relevant for the pluginc case as they should not be 
> printed out for that case.
> The filtering happening in finalizeLastError() does not look relevant as the 
> plugin currently only supports the "-checks=..." argument but not the e.g. 
> header and line filter. When checks are created in 
> ClangTidyCheckFactories::createChecks, the "-checks=..." argument is honored, 
> so that the !Context.isCheckEnabled(...) in finalizeLastError() is also not 
> relevant.
> 
> I agree that checkFilters()/finalizeLastError() will be needed once the 
> plugin case should support the other filtering options (header + line 
> filter), but note that this goes beyond the scope of this change here, which 
> is NOLINT filtering.
> 
> This is all new to me, so if I miss something regarding the 
> checkFilters()/finalizeLastError() thingy, please tell me, preferably with an 
> example if possible :)
It might be not relevant right now, but that code has invariants about how 
those two functions are called. Even if things happen to work, I think this 
code is too complicated to allow breaking those invariants in some cases.



Comment at: clang-tidy/ClangTidyDiagnosticConsumer.cpp:207
   CheckNamesByDiagnosticID.try_emplace(ID, CheckName);
+  CustomDiagIdParamsByDiagnosticID.try_emplace(
+  ID, CustomDiagIdParams(Level, FormatString));

Did you consider adding this query API to DiagnosticIDs instead? To me it looks 
weird that creation of custom diag IDs is handled by one class (DiagnosticIDs), 
and queries -- by another (ClangTidyContext).



Comment at: test/clang-tidy/nolintnextline-plugin.cpp:47
+
+// RUN: c-index-test -test-load-source-reparse 2 all %s -Xclang -add-plugin 
-Xclang clang-tidy -Xclang -plugin-arg-clang-tidy -Xclang 
-checks='-*,google-explicit-constructor' 2>&1 | FileCheck %s

Why not on the first line?


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D61487



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


[PATCH] D62582: [CodeComplete] Improve overload handling for C++ qualified and ref-qualified methods.

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

LGTM




Comment at: lib/Sema/SemaCodeComplete.cpp:1314
+  Result &Incumbent = Results[Entry.second];
+  Method->dumpColor();
+  Incumbent.Declaration->dumpColor();

A leftover debug output. Please remove before landing


Repository:
  rC Clang

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

https://reviews.llvm.org/D62582



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


[PATCH] D62729: [ARM] Fix recent breakage of -mfpu=none.

2019-06-03 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham marked an inline comment as done.
simon_tatham added inline comments.



Comment at: clang/test/CodeGen/arm-mfpu-none.c:2
+// REQUIRES: arm-registered-target
+// RUN: %clang -target arm-none-eabi -mcpu=cortex-m4 -mfpu=none -S -o - %s | 
FileCheck %s
+

dmgreen wrote:
> simon_tatham wrote:
> > dmgreen wrote:
> > > lebedev.ri wrote:
> > > > Generally clang codegen tests should test `-emit-llvm -S` output
> > > Perhaps add to the tests in clang/test/Driver/arm-mfpu.c instead?
> > @lebedev.ri : looking at the IR doesn't show up what I'm trying to test in 
> > this case. And I modelled this on existing tests in test/CodeGen, such as 
> > `arm-eabi.c`, which also need to test the real assembler output in order to 
> > do their job.
> > 
> > @dmgreen: it's true that I could also make `test/Driver/arm-mfpu.c` check 
> > that the extra feature name is appearing in the cc1 command line where I 
> > currently think it should be, but I think that wouldn't replace this test. 
> > The real point of this test is that the //currently// right feature names 
> > might not stay right, if the feature set is reorganised again in future – 
> > and if that happens, then whoever does it will probably rewrite most of 
> > `arm-mfpu.c` anyway.
> > 
> > So this is an end-to-end check that //whatever// detailed command line is 
> > generated by the driver in these circumstances, it is sufficient to ensure 
> > that the final generated code really doesn't include FP instructions.
> I believe that the idea is that if we test each step, so make sure we have 
> tests from clang driver -> clang-cl and clang -> llvm-ir and llvm -> asm, 
> then it should all be tested. And because each has a well defined interfaces 
> along each step of the way it should keep working. Any integration tests are 
> often left to external tests like the test suite.
> 
> But I do see some precedent for this in other places. If you add the extra 
> checks in test/Driver/arm-mfpu.c, then I think this is fine. (And I guess if 
> someone objects we can always take it out :) )
I think the shortcomings of that step-by-step testing strategy are exactly what 
caused the breakage in the first place.

If you know you're changing the mapping from driver arguments to cc1 feature 
options, then you change the test that //obviously// goes with the change you 
just made; but you leave unchanged the test that says the //previous// set of 
cc1 options caused the behaviour you wanted – because nothing will remind you 
that that needs changing as well (or make you aware that that test even exists 
to be updated, if you didn't already know).

An end-to-end test that ensures that //this// user input continues to cause 
//that// ultimate output code, regardless of the intervening details, would 
have prevented this bug arising last week, where the other strategy didn't. 
(Indeed, an end-to-end test of exactly that kind in our //downstream// tests is 
how we spotted it shortly after the change landed.)

So I still think I'd prefer not to remove this end-to-end test (though I will 
if people absolutely insist). But I'll add those extra checks you mention in 
`arm-mfpu.c`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62729



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


[PATCH] D62574: Initial draft of target-configurable address spaces.

2019-06-03 Thread Bevin Hansson via Phabricator via cfe-commits
ebevhan added a comment.

In D62574#1523835 , @Anastasia wrote:

> > This patch does not address the issue with the accessors
> >  on Qualifiers (isAddressSpaceSupersetOf, compatiblyIncludes),
> >  because I don't know how to solve it without breaking a ton of
> >  rather nice encapsulation. Either, every mention of compatiblyIncludes
> >  must be replaced with a call to a corresponding ASTContext method,
> >  Qualifiers must have a handle to ASTContext, or ASTContext must be
> >  passed to every such call. This revision mentions the issue in a comment:
> >  https://reviews.llvm.org/D49294
>
> I think using ASTContext helper is ok then.


Alright. Just to clarify, you mean the first option (using a new accessor on 
ASTContext and replacing all existing compatiblyIncludes with that)?

I'll have to see if that's possible without breaking a few more interfaces, 
since you can throw around Qualifiers and check for compatibility without an 
ASTContext today.

> I was just thinking about testing the new logic. Should we add something like 
>  `-ffake-address-space-map` 
> (https://clang.llvm.org/docs/UsersManual.html#opencl-specific-options) that 
> will force targets to use some implementation of fake address space 
> conversions? It was quite useful in OpenCL before we added concrete targets 
> with address spaces. Alternatively, we can try to use SPIR that is a generic 
> Clang-only target that has address spaces.

Well, there are a couple targets which have target address spaces even today, I 
think. AMDGPU should be one, right?

I forgot to mention; this patch also disables two "extensions" that Clang has, 
namely that subtraction and comparison on pointers of different address spaces 
is legal regardless of address space compatibility. I'm pretty sure that these 
extensions only exist because Clang hasn't had support for targets to express 
address space compatibility until now. According to the docs, x86 uses address 
spaces for certain types of segment access: 
https://clang.llvm.org/docs/LanguageExtensions.html#memory-references-to-specified-segments

If x86 (or any target that uses target address spaces) wants to keep using this 
and still keep such pointers implicitly compatible with each other, it will 
need to configure this in its target hooks.




Comment at: lib/Sema/SemaOverload.cpp:3171
+  // qualification conversion for disjoint address spaces make address space
+  // casts *work*?
   Qualifiers FromQuals = FromType.getQualifiers();

Anastasia wrote:
> I guess if address spaces don't overlap we don't have a valid qualification 
> conversion. This seems to align with the logic for cv. My guess is that none 
> of the other conversions will be valid for non overlapping address spaces and 
> the error will occur.
> 
> I think at this point we might not need to know if it's implicit or explicit? 
> I believe we might have a separate check for this somewhere because it works 
> for OpenCL. I don't know though if it might simplify the flow if we move this 
> logic rather here.
> 
> The cv checks above seem to use `CStyle` flag. I am wondering if we could use 
> it to detect implicit or explicit. Because we can only cast address space 
> with C style cast at the moment.  Although after adding `addrspace_cast` 
> operator that will no longer be the only way.
> I guess if address spaces don't overlap we don't have a valid qualification 
> conversion. This seems to align with the logic for cv. My guess is that none 
> of the other conversions will be valid for non overlapping address spaces and 
> the error will occur.

Right. So the reasoning is that if the address spaces are disjoint according to 
the overlap rule, then it cannot be considered a qualification conversion.

But with the new hooks, it's possible for a target to allow explicit conversion 
even if address spaces do not overlap according to the rules. So even though 
there is no overlap, such a conversion could still be a qualification 
conversion if it was explicit (either via a c-style cast or an 
`addrspace_cast`). This is in fact the default for all targets (see the patch 
in TargetInfo.h).

I think I need a refresher on how the casts were meant to work; were both 
`static_cast` and `reinterpret_cast` supposed to be capable of implicit 
conversion (say, private -> generic) but only `addrspace_cast` for the other 
direction (generic -> private)? Or was `reinterpret_cast` supposed to fail in 
the first case?



Comment at: lib/Sema/SemaOverload.cpp:5150
 
+  // FIXME: hasAddressSpace is wrong; this check will be skipped if FromType is
+  // not qualified with an address space, but if there's no implicit conversion

Anastasia wrote:
> Agree! We need to check that address spaces are not identical and then 
> validity!
> 
> But I guess it's ok for C++ because we can't add addr space qualifier to 
> implicit object parameter yet?
> 
> It's 

r362371 - [OpenCL] Declare builtin functions using TableGen

2019-06-03 Thread Sven van Haastregt via cfe-commits
Author: svenvh
Date: Mon Jun  3 02:39:11 2019
New Revision: 362371

URL: http://llvm.org/viewvc/llvm-project?rev=362371&view=rev
Log:
[OpenCL] Declare builtin functions using TableGen

This patch adds a `-fdeclare-opencl-builtins` command line option to
the clang frontend.  This enables clang to verify OpenCL C builtin
function declarations using a fast StringMatcher lookup, instead of
including the opencl-c.h file with the `-finclude-default-header`
option.  This avoids the large parse time penalty of the header file.

This commit only adds the basic infrastructure and some of the OpenCL
builtins.  It does not cover all builtins defined by the various OpenCL
specifications.  As such, it is not a replacement for
`-finclude-default-header` yet.

RFC: http://lists.llvm.org/pipermail/cfe-dev/2018-November/060041.html

Co-authored-by: Pierre Gondois
Co-authored-by: Joey Gouly
Co-authored-by: Sven van Haastregt

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

Added:
cfe/trunk/include/clang/Basic/OpenCLBuiltins.td
cfe/trunk/test/SemaOpenCL/fdeclare-opencl-builtins.cl
cfe/trunk/utils/TableGen/ClangOpenCLBuiltinEmitter.cpp
Modified:
cfe/trunk/include/clang/Basic/CMakeLists.txt
cfe/trunk/include/clang/Basic/LangOptions.def
cfe/trunk/include/clang/Driver/CC1Options.td
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/lib/Sema/SemaLookup.cpp
cfe/trunk/utils/TableGen/CMakeLists.txt
cfe/trunk/utils/TableGen/TableGen.cpp
cfe/trunk/utils/TableGen/TableGenBackends.h

Modified: cfe/trunk/include/clang/Basic/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/CMakeLists.txt?rev=362371&r1=362370&r2=362371&view=diff
==
--- cfe/trunk/include/clang/Basic/CMakeLists.txt (original)
+++ cfe/trunk/include/clang/Basic/CMakeLists.txt Mon Jun  3 02:39:11 2019
@@ -41,6 +41,12 @@ clang_tablegen(AttrHasAttributeImpl.inc
   TARGET ClangAttrHasAttributeImpl
   )
 
+clang_tablegen(OpenCLBuiltins.inc
+  -I ${CMAKE_CURRENT_SOURCE_DIR}/../../ -gen-clang-opencl-builtins
+  SOURCE OpenCLBuiltins.td
+  TARGET ClangOpenCLBuiltinsImpl
+  )
+
 # ARM NEON
 clang_tablegen(arm_neon.inc -gen-arm-neon-sema
   SOURCE arm_neon.td

Modified: cfe/trunk/include/clang/Basic/LangOptions.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/LangOptions.def?rev=362371&r1=362370&r2=362371&view=diff
==
--- cfe/trunk/include/clang/Basic/LangOptions.def (original)
+++ cfe/trunk/include/clang/Basic/LangOptions.def Mon Jun  3 02:39:11 2019
@@ -256,6 +256,7 @@ LANGOPT(CFProtectionBranch , 1, 0, "Cont
 LANGOPT(FakeAddressSpaceMap , 1, 0, "OpenCL fake address space map")
 ENUM_LANGOPT(AddressSpaceMapMangling , AddrSpaceMapMangling, 2, ASMM_Target, 
"OpenCL address space map mangling mode")
 LANGOPT(IncludeDefaultHeader, 1, 0, "Include default header file for OpenCL")
+LANGOPT(DeclareOpenCLBuiltins, 1, 0, "Declare OpenCL builtin functions")
 BENIGN_LANGOPT(DelayedTemplateParsing , 1, 0, "delayed template parsing")
 LANGOPT(BlocksRuntimeOptional , 1, 0, "optional blocks runtime")
 LANGOPT(

Added: cfe/trunk/include/clang/Basic/OpenCLBuiltins.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/OpenCLBuiltins.td?rev=362371&view=auto
==
--- cfe/trunk/include/clang/Basic/OpenCLBuiltins.td (added)
+++ cfe/trunk/include/clang/Basic/OpenCLBuiltins.td Mon Jun  3 02:39:11 2019
@@ -0,0 +1,296 @@
+//==--- OpenCLBuiltins.td - OpenCL builtin declarations 
---===//
+//
+// The LLVM Compiler Infrastructure
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file contains TableGen definitions for OpenCL builtin function
+// declarations.  In case of an unresolved function name in OpenCL, Clang will
+// check for a function described in this file when -fdeclare-opencl-builtins
+// is specified.
+//
+//===--===//
+
+//===--===//
+//  Definitions of miscellaneous basic entities.
+//===--===//
+// Versions of OpenCL
+class Version {
+  int Version = _Version;
+}
+def CL10: Version<100>;
+def CL11: Version<110>;
+def CL12: Version<120>;
+def CL20: Version<200>;
+
+// Address spaces
+// Pointer types need to be assigned an address space.
+class AddressSpace {
+  string AddrSpace = _AS;
+}
+def default_as: AddressSpace<"clang::LangAS::

[PATCH] D60763: Prototype OpenCL BIFs using Tablegen

2019-06-03 Thread Sven van Haastregt via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL362371: [OpenCL] Declare builtin functions using TableGen 
(authored by svenvh, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D60763?vs=200961&id=202673#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D60763

Files:
  cfe/trunk/include/clang/Basic/CMakeLists.txt
  cfe/trunk/include/clang/Basic/LangOptions.def
  cfe/trunk/include/clang/Basic/OpenCLBuiltins.td
  cfe/trunk/include/clang/Driver/CC1Options.td
  cfe/trunk/lib/Frontend/CompilerInvocation.cpp
  cfe/trunk/lib/Sema/SemaLookup.cpp
  cfe/trunk/test/SemaOpenCL/fdeclare-opencl-builtins.cl
  cfe/trunk/utils/TableGen/CMakeLists.txt
  cfe/trunk/utils/TableGen/ClangOpenCLBuiltinEmitter.cpp
  cfe/trunk/utils/TableGen/TableGen.cpp
  cfe/trunk/utils/TableGen/TableGenBackends.h

Index: cfe/trunk/include/clang/Driver/CC1Options.td
===
--- cfe/trunk/include/clang/Driver/CC1Options.td
+++ cfe/trunk/include/clang/Driver/CC1Options.td
@@ -778,7 +778,9 @@
 def fdefault_calling_conv_EQ : Joined<["-"], "fdefault-calling-conv=">,
   HelpText<"Set default calling convention">, Values<"cdecl,fastcall,stdcall,vectorcall,regcall">;
 def finclude_default_header : Flag<["-"], "finclude-default-header">,
-  HelpText<"Include the default header file for OpenCL">;
+  HelpText<"Include default header file for OpenCL">;
+def fdeclare_opencl_builtins : Flag<["-"], "fdeclare-opencl-builtins">,
+  HelpText<"Add OpenCL builtin function declarations (experimental)">;
 def fpreserve_vec3_type : Flag<["-"], "fpreserve-vec3-type">,
   HelpText<"Preserve 3-component vector type">;
 def fwchar_type_EQ : Joined<["-"], "fwchar-type=">,
Index: cfe/trunk/include/clang/Basic/CMakeLists.txt
===
--- cfe/trunk/include/clang/Basic/CMakeLists.txt
+++ cfe/trunk/include/clang/Basic/CMakeLists.txt
@@ -41,6 +41,12 @@
   TARGET ClangAttrHasAttributeImpl
   )
 
+clang_tablegen(OpenCLBuiltins.inc
+  -I ${CMAKE_CURRENT_SOURCE_DIR}/../../ -gen-clang-opencl-builtins
+  SOURCE OpenCLBuiltins.td
+  TARGET ClangOpenCLBuiltinsImpl
+  )
+
 # ARM NEON
 clang_tablegen(arm_neon.inc -gen-arm-neon-sema
   SOURCE arm_neon.td
Index: cfe/trunk/include/clang/Basic/OpenCLBuiltins.td
===
--- cfe/trunk/include/clang/Basic/OpenCLBuiltins.td
+++ cfe/trunk/include/clang/Basic/OpenCLBuiltins.td
@@ -0,0 +1,296 @@
+//==--- OpenCLBuiltins.td - OpenCL builtin declarations ---===//
+//
+// The LLVM Compiler Infrastructure
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file contains TableGen definitions for OpenCL builtin function
+// declarations.  In case of an unresolved function name in OpenCL, Clang will
+// check for a function described in this file when -fdeclare-opencl-builtins
+// is specified.
+//
+//===--===//
+
+//===--===//
+//  Definitions of miscellaneous basic entities.
+//===--===//
+// Versions of OpenCL
+class Version {
+  int Version = _Version;
+}
+def CL10: Version<100>;
+def CL11: Version<110>;
+def CL12: Version<120>;
+def CL20: Version<200>;
+
+// Address spaces
+// Pointer types need to be assigned an address space.
+class AddressSpace {
+  string AddrSpace = _AS;
+}
+def default_as: AddressSpace<"clang::LangAS::Default">;
+def private_as: AddressSpace<"clang::LangAS::opencl_private">;
+def global_as : AddressSpace<"clang::LangAS::opencl_global">;
+def constant_as   : AddressSpace<"clang::LangAS::opencl_constant">;
+def local_as  : AddressSpace<"clang::LangAS::opencl_local">;
+def generic_as: AddressSpace<"clang::LangAS::opencl_generic">;
+
+
+// Qualified Type. Allow to retrieve one ASTContext QualType.
+class QualType {
+  // Name of the field or function in a clang::ASTContext
+  // E.g. Name="IntTy" for the int type, and "getIntPtrType()" for an intptr_t
+  string Name = _Name;
+}
+
+// Helper class to store type access qualifiers (volatile, const, ...).
+class Qualifier {
+  string QualName = _QualName;
+}
+
+//===--===//
+//  OpenCL C classes for types
+//===--===//
+// OpenCL types (int,

[PATCH] D62580: [OpenCL] Use long instead of long long in x86 builtins

2019-06-03 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia accepted this revision.
Anastasia added a comment.

LGTM! Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62580



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


[PATCH] D60455: [SYCL] Implement SYCL device code outlining

2019-06-03 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added inline comments.



Comment at: clang/test/CodeGenSYCL/device-functions.cpp:24
+}
+// CHECK: define spir_func void @{{.*}}foo
+// CHECK: define linkonce_odr spir_func i32 @{{.*}}bar

Fznamznon wrote:
> Anastasia wrote:
> > I can't see where the SPIR calling convention is currently set for SYCL?
> If I understand correct it's set automatically on AST level because we use 
> SPIR-based triple for device code. Only in case of C++ methods clang doesn't 
> set SPIR calling convention. We did a modification in our codebase to get 
> SPIR calling convention for C++ methods too (available [[ 
> https://github.com/intel/llvm/blob/c13cb8df84418cb5d682f3bbee89090ebb0d00be/clang/lib/AST/ASTContext.cpp#L10015
>  | here ]] ) 
> 
Ok and what happens if some other target is used - not SPIR?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60455



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


r362375 - Revert rL362358 : PR42104: Support instantiations of lambdas that implicitly capture packs.

2019-06-03 Thread Simon Pilgrim via cfe-commits
Author: rksimon
Date: Mon Jun  3 02:56:09 2019
New Revision: 362375

URL: http://llvm.org/viewvc/llvm-project?rev=362375&view=rev
Log:
Revert rL362358 : PR42104: Support instantiations of lambdas that implicitly 
capture packs.

Two changes:
 * Track odr-use via FunctionParmPackExprs to properly handle dependent
   odr-uses of packs in generic lambdas.
 * Do not instantiate implicit captures; instead, regenerate them by
   instantiating the body of the lambda. This is necessary to
   distinguish between cases where only one element of a pack is
   captured and cases where the entire pack is captured.

Fixes http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win 
buildbot failures

Removed:
cfe/trunk/test/SemaTemplate/lambda-capture-pack.cpp
Modified:
cfe/trunk/include/clang/Sema/ScopeInfo.h
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Sema/ScopeInfo.cpp
cfe/trunk/lib/Sema/SemaExpr.cpp
cfe/trunk/lib/Sema/SemaExprCXX.cpp
cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp
cfe/trunk/lib/Sema/TreeTransform.h
cfe/trunk/test/SemaCXX/cxx1y-generic-lambdas-capturing.cpp

Modified: cfe/trunk/include/clang/Sema/ScopeInfo.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/ScopeInfo.h?rev=362375&r1=362374&r2=362375&view=diff
==
--- cfe/trunk/include/clang/Sema/ScopeInfo.h (original)
+++ cfe/trunk/include/clang/Sema/ScopeInfo.h Mon Jun  3 02:56:09 2019
@@ -15,7 +15,6 @@
 #define LLVM_CLANG_SEMA_SCOPEINFO_H
 
 #include "clang/AST/Expr.h"
-#include "clang/AST/ExprCXX.h"
 #include "clang/AST/Type.h"
 #include "clang/Basic/CapturedStmt.h"
 #include "clang/Basic/LLVM.h"
@@ -914,8 +913,7 @@ public:
   ///   };
   /// }
   void addPotentialCapture(Expr *VarExpr) {
-assert(isa(VarExpr) || isa(VarExpr) ||
-   isa(VarExpr));
+assert(isa(VarExpr) || isa(VarExpr));
 PotentiallyCapturingExprs.push_back(VarExpr);
   }
 
@@ -967,15 +965,13 @@ public:
   ///  building such a node. So we need a rule that anyone can implement and 
get
   ///  exactly the same result".
   void markVariableExprAsNonODRUsed(Expr *CapturingVarExpr) {
-assert(isa(CapturingVarExpr) ||
-   isa(CapturingVarExpr) ||
-   isa(CapturingVarExpr));
+assert(isa(CapturingVarExpr)
+|| isa(CapturingVarExpr));
 NonODRUsedCapturingExprs.insert(CapturingVarExpr);
   }
   bool isVariableExprMarkedAsNonODRUsed(Expr *CapturingVarExpr) const {
-assert(isa(CapturingVarExpr) ||
-   isa(CapturingVarExpr) ||
-   isa(CapturingVarExpr));
+assert(isa(CapturingVarExpr)
+  || isa(CapturingVarExpr));
 return NonODRUsedCapturingExprs.count(CapturingVarExpr);
   }
   void removePotentialCapture(Expr *E) {
@@ -997,8 +993,9 @@ public:
   PotentialThisCaptureLocation.isValid();
   }
 
-  void visitPotentialCaptures(
-  llvm::function_ref Callback) const;
+  // When passed the index, returns the VarDecl and Expr associated
+  // with the index.
+  void getPotentialVariableCapture(unsigned Idx, VarDecl *&VD, Expr *&E) const;
 };
 
 FunctionScopeInfo::WeakObjectProfileTy::WeakObjectProfileTy()

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=362375&r1=362374&r2=362375&view=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Mon Jun  3 02:56:09 2019
@@ -4179,7 +4179,6 @@ public:
   void MarkVariableReferenced(SourceLocation Loc, VarDecl *Var);
   void MarkDeclRefReferenced(DeclRefExpr *E, const Expr *Base = nullptr);
   void MarkMemberReferenced(MemberExpr *E);
-  void MarkFunctionParmPackReferenced(FunctionParmPackExpr *E);
   void MarkCaptureUsedInEnclosingContext(VarDecl *Capture, SourceLocation Loc,
  unsigned CapturingScopeIndex);
 

Modified: cfe/trunk/lib/Sema/ScopeInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/ScopeInfo.cpp?rev=362375&r1=362374&r2=362375&view=diff
==
--- cfe/trunk/lib/Sema/ScopeInfo.cpp (original)
+++ cfe/trunk/lib/Sema/ScopeInfo.cpp Mon Jun  3 02:56:09 2019
@@ -229,20 +229,20 @@ bool CapturingScopeInfo::isVLATypeCaptur
   return false;
 }
 
-void LambdaScopeInfo::visitPotentialCaptures(
-llvm::function_ref Callback) const {
-  for (Expr *E : PotentiallyCapturingExprs) {
-if (auto *DRE = dyn_cast(E)) {
-  Callback(cast(DRE->getFoundDecl()), E);
-} else if (auto *ME = dyn_cast(E)) {
-  Callback(cast(ME->getMemberDecl()), E);
-} else if (auto *FP = dyn_cast(E)) {
-  for (VarDecl *VD : *FP)
-Callback(VD, E);
-} else {
-  llvm_unreachable("unexpected expression in potential captures list");
-}
-  }
+void LambdaScop

[PATCH] D60697: [ARM] Allow "-march=foo+fp" to vary with foo.

2019-06-03 Thread Oliver Stannard (Linaro) via Phabricator via cfe-commits
ostannard added inline comments.



Comment at: llvm/lib/Support/ARMTargetParser.cpp:551
+
+  // If the default FPU already supports double-precision, or if
+  // there is no double-prec FPU that extends it, then "fp.dp"

Could you also add tests for the error cases here? I think these are:
* +fp.dp, but the FPU is already double-precision
* +fp.dp, but no double-precision FPU exists (are there any FPUs which cause 
this?)
* +[no]fp or +[no]fp.dp for a CPU/arch which doesn't have any FPUs.

I also don't see any tests for the negated forms of either feature.


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

https://reviews.llvm.org/D60697



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


[PATCH] D62580: [OpenCL] Use long instead of long long in x86 builtins

2019-06-03 Thread Karl-Johan Karlsson via Phabricator via cfe-commits
Ka-Ka added inline comments.



Comment at: clang/test/CodeGen/builtins-x86.c:127-128
 
-  tmp_V2LLi = __builtin_ia32_undef128();
-  tmp_V4LLi = __builtin_ia32_undef256();
+  tmp_V2LLi = (V2LLi)__builtin_ia32_undef128();
+  tmp_V4LLi = (V4LLi)__builtin_ia32_undef256();
 

I don't like the introduced casts. Can we change the testcase to operate on the 
appropriate types instead?
The above two lines could probably be replaced by:
  tmp_V2d = __builtin_ia32_undef128();
  tmp_V4d = __builtin_ia32_undef256();
What do you think?




Comment at: clang/test/CodeGen/builtins-x86.c:228-231
+  tmp_V8s = (V8s)__builtin_ia32_packsswb128(tmp_V8s, tmp_V8s);
+  tmp_V4i = (V4i)__builtin_ia32_packssdw128(tmp_V4i, tmp_V4i);
+  tmp_V8s = (V8s)__builtin_ia32_packuswb128(tmp_V8s, tmp_V8s);
   tmp_V8s = __builtin_ia32_pmulhuw128(tmp_V8s, tmp_V8s);

same here?



Comment at: clang/test/CodeGen/builtins-x86.c:250
   tmp_V4s = __builtin_ia32_phsubsw(tmp_V4s, tmp_V4s);
-  tmp_V16c = __builtin_ia32_pmaddubsw128(tmp_V16c, tmp_V16c);
+  tmp_V16c = (V16c)__builtin_ia32_pmaddubsw128(tmp_V16c, tmp_V16c);
   tmp_V8c = __builtin_ia32_pmaddubsw(tmp_V8c, tmp_V8c);

and here?



Comment at: clang/test/CodeGen/builtins-x86.c:428
   tmp_V4i = __builtin_ia32_psradi128(tmp_V4i, tmp_i);
-  tmp_V8s = __builtin_ia32_pmaddwd128(tmp_V8s, tmp_V8s);
+  tmp_V8s = (V8s)__builtin_ia32_pmaddwd128(tmp_V8s, tmp_V8s);
   (void) __builtin_ia32_monitor(tmp_vp, tmp_Ui, tmp_Ui);

Can we change this line to?
  tmp_V4i = __builtin_ia32_pmaddwd128(tmp_V8s, tmp_V8s);




Comment at: clang/test/CodeGen/builtins-x86.c:432
   tmp_V16c = __builtin_ia32_lddqu(tmp_cCp);
-  tmp_V2LLi = __builtin_ia32_palignr128(tmp_V2LLi, tmp_V2LLi, imm_i);
-  tmp_V1LLi = __builtin_ia32_palignr(tmp_V1LLi, tmp_V1LLi, imm_i);
+  tmp_V2LLi = (V2LLi)__builtin_ia32_palignr128((V16c)tmp_V2LLi, 
(V16c)tmp_V2LLi, imm_i);
+  tmp_V1LLi = (V1LLi)__builtin_ia32_palignr((V8c)tmp_V1LLi, (V8c)tmp_V1LLi, 
imm_i);

Can we change this line to?
  tmp_V16c = __builtin_ia32_palignr128(tmp_V16c, tmp_V16c, imm_i);




Comment at: clang/test/CodeGen/builtins-x86.c:433
+  tmp_V2LLi = (V2LLi)__builtin_ia32_palignr128((V16c)tmp_V2LLi, 
(V16c)tmp_V2LLi, imm_i);
+  tmp_V1LLi = (V1LLi)__builtin_ia32_palignr((V8c)tmp_V1LLi, (V8c)tmp_V1LLi, 
imm_i);
 #ifdef USE_SSE4

Can we change this line to?
  tmp_V8c = __builtin_ia32_palignr(tmp_V8c, tmp_V8c, imm_i);



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62580



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


[PATCH] D62729: [ARM] Fix recent breakage of -mfpu=none.

2019-06-03 Thread Simon Tatham via Phabricator via cfe-commits
simon_tatham updated this revision to Diff 202681.
simon_tatham added a comment.

Added the extra checks in `arm-mfpu.c`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62729

Files:
  clang/lib/Driver/ToolChains/Arch/ARM.cpp
  clang/test/CodeGen/arm-mfpu-none.c
  clang/test/Driver/arm-mfpu.c
  llvm/lib/Support/ARMTargetParser.cpp


Index: llvm/lib/Support/ARMTargetParser.cpp
===
--- llvm/lib/Support/ARMTargetParser.cpp
+++ llvm/lib/Support/ARMTargetParser.cpp
@@ -198,6 +198,7 @@
 Features.push_back("-fp-armv8");
 break;
   case FPUVersion::NONE:
+Features.push_back("-fpregs");
 Features.push_back("-vfp2");
 Features.push_back("-vfp3");
 Features.push_back("-fp16");
Index: clang/test/Driver/arm-mfpu.c
===
--- clang/test/Driver/arm-mfpu.c
+++ clang/test/Driver/arm-mfpu.c
@@ -318,6 +318,7 @@
 // RUN:   | FileCheck --check-prefix=CHECK-NO-FP %s
 // CHECK-NO-FP-NOT: "-target-feature" "+soft-float"
 // CHECK-NO-FP: "-target-feature" "+soft-float-abi"
+// CHECK-NO-FP: "-target-feature" "-fpregs"
 // CHECK-NO-FP: "-target-feature" "-vfp2"
 // CHECK-NO-FP: "-target-feature" "-vfp3"
 // CHECK-NO-FP: "-target-feature" "-vfp4"
@@ -363,6 +364,7 @@
 // CHECK-SOFT-ABI-FP: "-target-feature" "-fp-armv8"
 // CHECK-SOFT-ABI-FP: "-target-feature" "-neon"
 // CHECK-SOFT-ABI-FP: "-target-feature" "-crypto"
+// CHECK-SOFT-ABI-FP: "-target-feature" "-fpregs"
 
 // RUN: %clang -target arm-linux-androideabi21 %s -### -c 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-ARM5-ANDROID-FP-DEFAULT %s
Index: clang/test/CodeGen/arm-mfpu-none.c
===
--- /dev/null
+++ clang/test/CodeGen/arm-mfpu-none.c
@@ -0,0 +1,8 @@
+// REQUIRES: arm-registered-target
+// RUN: %clang -target arm-none-eabi -mcpu=cortex-m4 -mfpu=none -S -o - %s | 
FileCheck %s
+
+// CHECK-LABEL: compute
+// CHECK-NOT: {{s[0-9]}}
+float compute(float a, float b) {
+  return (a+b) * (a-b);
+}
Index: clang/lib/Driver/ToolChains/Arch/ARM.cpp
===
--- clang/lib/Driver/ToolChains/Arch/ARM.cpp
+++ clang/lib/Driver/ToolChains/Arch/ARM.cpp
@@ -430,8 +430,8 @@
 llvm::ARM::getFPUFeatures(llvm::ARM::FK_NONE, Features);
 
 // Disable hardware FP features which have been enabled.
-// FIXME: Disabling vfp2 and neon should be enough as all the other
-//features are dependent on these 2 features in LLVM. However
+// FIXME: Disabling fpregs should be enough all by itself, since all
+//the other FP features are dependent on it. However
 //there is currently no easy way to test this in clang, so for
 //now just be explicit and disable all known dependent features
 //as well.
@@ -439,6 +439,11 @@
 "neon", "crypto", "dotprod", "fp16fml"})
   if (std::find(std::begin(Features), std::end(Features), "+" + Feature) 
!= std::end(Features))
 Features.push_back(Args.MakeArgString("-" + Feature));
+
+// Disable the base feature unconditionally, even if it was not
+// explicitly in the features list (e.g. if we had +vfp3, which
+// implies it).
+Features.push_back("-fpregs");
   }
 
   // En/disable crc code generation.


Index: llvm/lib/Support/ARMTargetParser.cpp
===
--- llvm/lib/Support/ARMTargetParser.cpp
+++ llvm/lib/Support/ARMTargetParser.cpp
@@ -198,6 +198,7 @@
 Features.push_back("-fp-armv8");
 break;
   case FPUVersion::NONE:
+Features.push_back("-fpregs");
 Features.push_back("-vfp2");
 Features.push_back("-vfp3");
 Features.push_back("-fp16");
Index: clang/test/Driver/arm-mfpu.c
===
--- clang/test/Driver/arm-mfpu.c
+++ clang/test/Driver/arm-mfpu.c
@@ -318,6 +318,7 @@
 // RUN:   | FileCheck --check-prefix=CHECK-NO-FP %s
 // CHECK-NO-FP-NOT: "-target-feature" "+soft-float"
 // CHECK-NO-FP: "-target-feature" "+soft-float-abi"
+// CHECK-NO-FP: "-target-feature" "-fpregs"
 // CHECK-NO-FP: "-target-feature" "-vfp2"
 // CHECK-NO-FP: "-target-feature" "-vfp3"
 // CHECK-NO-FP: "-target-feature" "-vfp4"
@@ -363,6 +364,7 @@
 // CHECK-SOFT-ABI-FP: "-target-feature" "-fp-armv8"
 // CHECK-SOFT-ABI-FP: "-target-feature" "-neon"
 // CHECK-SOFT-ABI-FP: "-target-feature" "-crypto"
+// CHECK-SOFT-ABI-FP: "-target-feature" "-fpregs"
 
 // RUN: %clang -target arm-linux-androideabi21 %s -### -c 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-ARM5-ANDROID-FP-DEFAULT %s
Index: clang/test/CodeGen/arm-mfpu-none.c
===
--- /dev/null
+++ clang/test/CodeGen/arm-mfpu-none.c
@@ -0,0 +1,8 @@
+// REQUIRES: arm-register

[PATCH] D60455: [SYCL] Implement SYCL device code outlining

2019-06-03 Thread Mariya Podchishchaeva via Phabricator via cfe-commits
Fznamznon added inline comments.



Comment at: clang/test/CodeGenSYCL/device-functions.cpp:24
+}
+// CHECK: define spir_func void @{{.*}}foo
+// CHECK: define linkonce_odr spir_func i32 @{{.*}}bar

Anastasia wrote:
> Fznamznon wrote:
> > Anastasia wrote:
> > > I can't see where the SPIR calling convention is currently set for SYCL?
> > If I understand correct it's set automatically on AST level because we use 
> > SPIR-based triple for device code. Only in case of C++ methods clang 
> > doesn't set SPIR calling convention. We did a modification in our codebase 
> > to get SPIR calling convention for C++ methods too (available [[ 
> > https://github.com/intel/llvm/blob/c13cb8df84418cb5d682f3bbee89090ebb0d00be/clang/lib/AST/ASTContext.cpp#L10015
> >  | here ]] ) 
> > 
> Ok and what happens if some other target is used - not SPIR?
There will be no SPIR calling convention for device functions.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60455



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


[PATCH] D59934: Compare SourceLocations from different TUs by FileID

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

The problem has not necessarily do something with macro expansion. If a 
function is imported in CTU mode and for any reason source locations inside it 
are compared against source locations in the original TU these locations are 
(from `SourceManager` point of view) in different TUs. But from TU point of 
view these are in the same TU because the AST import (AST import keeps the 
original filename and location in the new source location, so the new 
`SourceLocation` is in the same TU but different source file). Maybe this is a 
new case related to CTU mode in the compare function so it is correct to handle 
this case too (without assert).


Repository:
  rC Clang

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

https://reviews.llvm.org/D59934



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


[PATCH] D59934: Compare SourceLocations from different TUs by FileID

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

The following ASTImporterTest reproduces the assert:

  TEST_P(ASTImporterOptionSpecificTestBase, SourceLocationDifferentTU) {
TranslationUnitDecl *ToTU = getToTuDecl("void f1();", Lang_CXX11);
Decl *FromTU = getTuDecl("void f2();", Lang_CXX11, "input.cc");
auto *ToF1 = FirstDeclMatcher().match(ToTU, functionDecl());
auto *FromF2 = FirstDeclMatcher().match(FromTU, 
functionDecl());
  
auto *ToF2 = Import(FromF2, Lang_CXX11);
  
bool Before1 = 
ToTU->getASTContext().getSourceManager().isBeforeInTranslationUnit(ToF1->getLocation(),
 ToF2->getLocation());
bool Before2 = 
ToTU->getASTContext().getSourceManager().isBeforeInTranslationUnit(ToF2->getLocation(),
 ToF1->getLocation());
EXPECT_NE(Before1, Before2);
  }


Repository:
  rC Clang

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

https://reviews.llvm.org/D59934



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


r362379 - Fix compilation warning about unused variable [NFC]

2019-06-03 Thread Mikael Holmen via cfe-commits
Author: uabelho
Date: Mon Jun  3 03:50:41 2019
New Revision: 362379

URL: http://llvm.org/viewvc/llvm-project?rev=362379&view=rev
Log:
Fix compilation warning about unused variable [NFC]

Modified:
cfe/trunk/lib/Driver/Driver.cpp

Modified: cfe/trunk/lib/Driver/Driver.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=362379&r1=362378&r2=362379&view=diff
==
--- cfe/trunk/lib/Driver/Driver.cpp (original)
+++ cfe/trunk/lib/Driver/Driver.cpp Mon Jun  3 03:50:41 2019
@@ -1007,7 +1007,7 @@ Compilation *Driver::BuildCompilation(Ar
 
   // Check for working directory option before accessing any files
   if (Arg *WD = Args.getLastArg(options::OPT_working_directory))
-if (std::error_code EC = VFS->setCurrentWorkingDirectory(WD->getValue()))
+if (VFS->setCurrentWorkingDirectory(WD->getValue()))
   Diag(diag::err_drv_unable_to_set_working_directory) << WD->getValue();
 
   // FIXME: This stuff needs to go into the Compilation, not the driver.


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


[PATCH] D62580: [OpenCL] Use long instead of long long in x86 builtins

2019-06-03 Thread Karl-Johan Karlsson via Phabricator via cfe-commits
Ka-Ka accepted this revision.
Ka-Ka added a comment.

Thanks!


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

https://reviews.llvm.org/D62580



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


[PATCH] D62580: [OpenCL] Use long instead of long long in x86 builtins

2019-06-03 Thread Alexander Batashev via Phabricator via cfe-commits
alexbatashev marked 6 inline comments as done.
alexbatashev added a comment.

@Ka-Ka done


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

https://reviews.llvm.org/D62580



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


[PATCH] D62729: [ARM] Fix recent breakage of -mfpu=none.

2019-06-03 Thread Dave Green via Phabricator via cfe-commits
dmgreen accepted this revision.
dmgreen added a comment.
This revision is now accepted and ready to land.

LGTM. Thanks for adding the new test. I agree with keeping both tests ( I 
wasn't very clear).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62729



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


r362380 - [ARM] Fix recent breakage of -mfpu=none.

2019-06-03 Thread Simon Tatham via cfe-commits
Author: statham
Date: Mon Jun  3 04:02:53 2019
New Revision: 362380

URL: http://llvm.org/viewvc/llvm-project?rev=362380&view=rev
Log:
[ARM] Fix recent breakage of -mfpu=none.

The recent change D60691 introduced a bug in clang when handling
option combinations such as `-mcpu=cortex-m4 -mfpu=none`. Those
options together should select Cortex-M4 but disable all use of
hardware FP, but in fact, now hardware FP instructions can still be
generated in that mode.

The reason is because the handling of FPUVersion::NONE disables all
the same feature names it used to, of which the base one is `vfp2`.
But now there are further features below that, like `vfp2d16fp` and
(following D60694) `fpregs`, which also need to be turned off to
disable hardware FP completely.

Added a tiny test which double-checks that compiling a simple FP
function doesn't access the FP registers.

Reviewers: SjoerdMeijer, dmgreen

Reviewed By: dmgreen

Subscribers: lebedev.ri, javed.absar, kristof.beyls, hiraditya, cfe-commits, 
llvm-commits

Tags: #clang, #llvm

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

Added:
cfe/trunk/test/CodeGen/arm-mfpu-none.c   (with props)
Modified:
cfe/trunk/lib/Driver/ToolChains/Arch/ARM.cpp
cfe/trunk/test/Driver/arm-mfpu.c

Modified: cfe/trunk/lib/Driver/ToolChains/Arch/ARM.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Arch/ARM.cpp?rev=362380&r1=362379&r2=362380&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Arch/ARM.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Arch/ARM.cpp Mon Jun  3 04:02:53 2019
@@ -430,8 +430,8 @@ fp16_fml_fallthrough:
 llvm::ARM::getFPUFeatures(llvm::ARM::FK_NONE, Features);
 
 // Disable hardware FP features which have been enabled.
-// FIXME: Disabling vfp2 and neon should be enough as all the other
-//features are dependent on these 2 features in LLVM. However
+// FIXME: Disabling fpregs should be enough all by itself, since all
+//the other FP features are dependent on it. However
 //there is currently no easy way to test this in clang, so for
 //now just be explicit and disable all known dependent features
 //as well.
@@ -439,6 +439,11 @@ fp16_fml_fallthrough:
 "neon", "crypto", "dotprod", "fp16fml"})
   if (std::find(std::begin(Features), std::end(Features), "+" + Feature) 
!= std::end(Features))
 Features.push_back(Args.MakeArgString("-" + Feature));
+
+// Disable the base feature unconditionally, even if it was not
+// explicitly in the features list (e.g. if we had +vfp3, which
+// implies it).
+Features.push_back("-fpregs");
   }
 
   // En/disable crc code generation.

Added: cfe/trunk/test/CodeGen/arm-mfpu-none.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/arm-mfpu-none.c?rev=362380&view=auto
==
--- cfe/trunk/test/CodeGen/arm-mfpu-none.c (added)
+++ cfe/trunk/test/CodeGen/arm-mfpu-none.c Mon Jun  3 04:02:53 2019
@@ -0,0 +1,8 @@
+// REQUIRES: arm-registered-target
+// RUN: %clang -target arm-none-eabi -mcpu=cortex-m4 -mfpu=none -S -o - %s | 
FileCheck %s
+
+// CHECK-LABEL: compute
+// CHECK-NOT: {{s[0-9]}}
+float compute(float a, float b) {
+  return (a+b) * (a-b);
+}

Propchange: cfe/trunk/test/CodeGen/arm-mfpu-none.c
--
svn:eol-style = native

Propchange: cfe/trunk/test/CodeGen/arm-mfpu-none.c
--
svn:keywords = Rev Date Author URL Id

Modified: cfe/trunk/test/Driver/arm-mfpu.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/arm-mfpu.c?rev=362380&r1=362379&r2=362380&view=diff
==
--- cfe/trunk/test/Driver/arm-mfpu.c (original)
+++ cfe/trunk/test/Driver/arm-mfpu.c Mon Jun  3 04:02:53 2019
@@ -318,6 +318,7 @@
 // RUN:   | FileCheck --check-prefix=CHECK-NO-FP %s
 // CHECK-NO-FP-NOT: "-target-feature" "+soft-float"
 // CHECK-NO-FP: "-target-feature" "+soft-float-abi"
+// CHECK-NO-FP: "-target-feature" "-fpregs"
 // CHECK-NO-FP: "-target-feature" "-vfp2"
 // CHECK-NO-FP: "-target-feature" "-vfp3"
 // CHECK-NO-FP: "-target-feature" "-vfp4"
@@ -363,6 +364,7 @@
 // CHECK-SOFT-ABI-FP: "-target-feature" "-fp-armv8"
 // CHECK-SOFT-ABI-FP: "-target-feature" "-neon"
 // CHECK-SOFT-ABI-FP: "-target-feature" "-crypto"
+// CHECK-SOFT-ABI-FP: "-target-feature" "-fpregs"
 
 // RUN: %clang -target arm-linux-androideabi21 %s -### -c 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-ARM5-ANDROID-FP-DEFAULT %s


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


[PATCH] D62729: [ARM] Fix recent breakage of -mfpu=none.

2019-06-03 Thread Phabricator via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL362380: [ARM] Fix recent breakage of -mfpu=none. (authored 
by statham, committed by ).
Herald added a subscriber: kristina.

Changed prior to commit:
  https://reviews.llvm.org/D62729?vs=202681&id=202688#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D62729

Files:
  cfe/trunk/lib/Driver/ToolChains/Arch/ARM.cpp
  cfe/trunk/test/CodeGen/arm-mfpu-none.c
  cfe/trunk/test/Driver/arm-mfpu.c
  llvm/trunk/lib/Support/ARMTargetParser.cpp


Index: llvm/trunk/lib/Support/ARMTargetParser.cpp
===
--- llvm/trunk/lib/Support/ARMTargetParser.cpp
+++ llvm/trunk/lib/Support/ARMTargetParser.cpp
@@ -198,6 +198,7 @@
 Features.push_back("-fp-armv8");
 break;
   case FPUVersion::NONE:
+Features.push_back("-fpregs");
 Features.push_back("-vfp2");
 Features.push_back("-vfp3");
 Features.push_back("-fp16");
Index: cfe/trunk/lib/Driver/ToolChains/Arch/ARM.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/Arch/ARM.cpp
+++ cfe/trunk/lib/Driver/ToolChains/Arch/ARM.cpp
@@ -430,8 +430,8 @@
 llvm::ARM::getFPUFeatures(llvm::ARM::FK_NONE, Features);
 
 // Disable hardware FP features which have been enabled.
-// FIXME: Disabling vfp2 and neon should be enough as all the other
-//features are dependent on these 2 features in LLVM. However
+// FIXME: Disabling fpregs should be enough all by itself, since all
+//the other FP features are dependent on it. However
 //there is currently no easy way to test this in clang, so for
 //now just be explicit and disable all known dependent features
 //as well.
@@ -439,6 +439,11 @@
 "neon", "crypto", "dotprod", "fp16fml"})
   if (std::find(std::begin(Features), std::end(Features), "+" + Feature) 
!= std::end(Features))
 Features.push_back(Args.MakeArgString("-" + Feature));
+
+// Disable the base feature unconditionally, even if it was not
+// explicitly in the features list (e.g. if we had +vfp3, which
+// implies it).
+Features.push_back("-fpregs");
   }
 
   // En/disable crc code generation.
Index: cfe/trunk/test/Driver/arm-mfpu.c
===
--- cfe/trunk/test/Driver/arm-mfpu.c
+++ cfe/trunk/test/Driver/arm-mfpu.c
@@ -318,6 +318,7 @@
 // RUN:   | FileCheck --check-prefix=CHECK-NO-FP %s
 // CHECK-NO-FP-NOT: "-target-feature" "+soft-float"
 // CHECK-NO-FP: "-target-feature" "+soft-float-abi"
+// CHECK-NO-FP: "-target-feature" "-fpregs"
 // CHECK-NO-FP: "-target-feature" "-vfp2"
 // CHECK-NO-FP: "-target-feature" "-vfp3"
 // CHECK-NO-FP: "-target-feature" "-vfp4"
@@ -363,6 +364,7 @@
 // CHECK-SOFT-ABI-FP: "-target-feature" "-fp-armv8"
 // CHECK-SOFT-ABI-FP: "-target-feature" "-neon"
 // CHECK-SOFT-ABI-FP: "-target-feature" "-crypto"
+// CHECK-SOFT-ABI-FP: "-target-feature" "-fpregs"
 
 // RUN: %clang -target arm-linux-androideabi21 %s -### -c 2>&1 \
 // RUN:   | FileCheck --check-prefix=CHECK-ARM5-ANDROID-FP-DEFAULT %s
Index: cfe/trunk/test/CodeGen/arm-mfpu-none.c
===
--- cfe/trunk/test/CodeGen/arm-mfpu-none.c
+++ cfe/trunk/test/CodeGen/arm-mfpu-none.c
@@ -0,0 +1,8 @@
+// REQUIRES: arm-registered-target
+// RUN: %clang -target arm-none-eabi -mcpu=cortex-m4 -mfpu=none -S -o - %s | 
FileCheck %s
+
+// CHECK-LABEL: compute
+// CHECK-NOT: {{s[0-9]}}
+float compute(float a, float b) {
+  return (a+b) * (a-b);
+}


Index: llvm/trunk/lib/Support/ARMTargetParser.cpp
===
--- llvm/trunk/lib/Support/ARMTargetParser.cpp
+++ llvm/trunk/lib/Support/ARMTargetParser.cpp
@@ -198,6 +198,7 @@
 Features.push_back("-fp-armv8");
 break;
   case FPUVersion::NONE:
+Features.push_back("-fpregs");
 Features.push_back("-vfp2");
 Features.push_back("-vfp3");
 Features.push_back("-fp16");
Index: cfe/trunk/lib/Driver/ToolChains/Arch/ARM.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/Arch/ARM.cpp
+++ cfe/trunk/lib/Driver/ToolChains/Arch/ARM.cpp
@@ -430,8 +430,8 @@
 llvm::ARM::getFPUFeatures(llvm::ARM::FK_NONE, Features);
 
 // Disable hardware FP features which have been enabled.
-// FIXME: Disabling vfp2 and neon should be enough as all the other
-//features are dependent on these 2 features in LLVM. However
+// FIXME: Disabling fpregs should be enough all by itself, since all
+//the other FP features are dependent on it. However
 //there is currently no easy way to test this in clang, so for
 //now just be explicit and disable all known dependent features
 // 

[PATCH] D62156: [Sema][PR41730] Diagnose addr space mismatch while constructing objects

2019-06-03 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia updated this revision to Diff 202690.
Anastasia marked an inline comment as done.
Anastasia added a comment.

Changed FIXME to a regular comment, modified wording.


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

https://reviews.llvm.org/D62156

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Sema/Overload.h
  lib/Sema/SemaDeclCXX.cpp
  lib/Sema/SemaInit.cpp
  lib/Sema/SemaOverload.cpp
  test/CodeGenCXX/address-space-of-this.cpp
  test/CodeGenOpenCLCXX/addrspace-ctor.cl
  test/SemaCXX/address-space-ctor.cpp

Index: test/SemaCXX/address-space-ctor.cpp
===
--- /dev/null
+++ test/SemaCXX/address-space-ctor.cpp
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 %s -std=c++14 -triple=spir -verify -fsyntax-only
+// RUN: %clang_cc1 %s -std=c++17 -triple=spir -verify -fsyntax-only
+
+struct MyType {
+  MyType(int i) : i(i) {}
+  int i;
+};
+
+//expected-note@-5{{candidate constructor (the implicit copy constructor) not viable: no known conversion from 'int' to 'const MyType &' for 1st argument}}
+//expected-note@-6{{candidate constructor (the implicit move constructor) not viable: no known conversion from 'int' to 'MyType &&' for 1st argument}}
+//expected-note@-6{{candidate constructor ignored: cannot be used to construct an object in address space '__attribute__((address_space(10)))'}}
+//expected-note@-8{{candidate constructor ignored: cannot be used to construct an object in address space '__attribute__((address_space(10)))'}}
+//expected-note@-9{{candidate constructor ignored: cannot be used to construct an object in address space '__attribute__((address_space(10)))'}}
+//expected-note@-9{{candidate constructor ignored: cannot be used to construct an object in address space '__attribute__((address_space(10)))'}}
+
+// FIXME: We can't implicitly convert between address spaces yet.
+MyType __attribute__((address_space(10))) m1 = 123; //expected-error{{no viable conversion from 'int' to '__attribute__((address_space(10))) MyType'}}
+MyType __attribute__((address_space(10))) m2(123);  //expected-error{{no matching constructor for initialization of '__attribute__((address_space(10))) MyType'}}
Index: test/CodeGenOpenCLCXX/addrspace-ctor.cl
===
--- /dev/null
+++ test/CodeGenOpenCLCXX/addrspace-ctor.cl
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 %s -triple spir-unknown-unknown -cl-std=c++ -emit-llvm -O0 -o - | FileCheck %s
+
+struct MyType {
+  MyType(int i) : i(i) {}
+  MyType(int i) __constant : i(i) {}
+  int i;
+};
+
+//CHECK: call void @_ZNU3AS26MyTypeC1Ei(%struct.MyType addrspace(2)* @const1, i32 1)
+__constant MyType const1 = 1;
+//CHECK: call void @_ZNU3AS26MyTypeC1Ei(%struct.MyType addrspace(2)* @const2, i32 2)
+__constant MyType const2(2);
+//CHECK: call void @_ZNU3AS46MyTypeC1Ei(%struct.MyType addrspace(4)* addrspacecast (%struct.MyType addrspace(1)* @glob to %struct.MyType addrspace(4)*), i32 1)
+MyType glob(1);
Index: test/CodeGenCXX/address-space-of-this.cpp
===
--- test/CodeGenCXX/address-space-of-this.cpp
+++ test/CodeGenCXX/address-space-of-this.cpp
@@ -1,8 +1,11 @@
 // RUN: %clang_cc1 %s -std=c++14 -triple=spir -emit-llvm -o - | FileCheck %s
 // RUN: %clang_cc1 %s -std=c++17 -triple=spir -emit-llvm -o - | FileCheck %s
+// XFAIL: *
 
+// FIXME: We can't compile address space method qualifiers yet.
+// Therefore there is no way to check correctness of this code.
 struct MyType {
-  MyType(int i) : i(i) {}
+  MyType(int i) __attribute__((address_space(10))) : i(i) {}
   int i;
 };
 //CHECK: call void @_ZN6MyTypeC1Ei(%struct.MyType* addrspacecast (%struct.MyType addrspace(10)* @m to %struct.MyType*), i32 123)
Index: lib/Sema/SemaOverload.cpp
===
--- lib/Sema/SemaOverload.cpp
+++ lib/Sema/SemaOverload.cpp
@@ -6101,6 +6101,15 @@
 return;
   }
 }
+
+// Check that the constructor is capable of constructing an object in the
+// destination address space.
+if (!Qualifiers::isAddressSpaceSupersetOf(
+Constructor->getMethodQualifiers().getAddressSpace(),
+CandidateSet.getDestAS())) {
+  Candidate.Viable = false;
+  Candidate.FailureKind = ovl_fail_object_addrspace_mismatch;
+}
   }
 
   unsigned NumParams = Proto->getNumParams();
@@ -10392,9 +10401,12 @@
 /// It would be great to be able to express per-candidate problems
 /// more richly for those diagnostic clients that cared, but we'd
 /// still have to be just as careful with the default diagnostics.
+/// \param CtorDestAS Addr space of object being constructed (for ctor
+/// candidates only).
 static void NoteFunctionCandidate(Sema &S, OverloadCandidate *Cand,
   unsigned NumArgs,
-  bool TakingCandidateAddress) {
+  boo

[PATCH] D62156: [Sema][PR41730] Diagnose addr space mismatch while constructing objects

2019-06-03 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia marked 2 inline comments as done.
Anastasia added inline comments.



Comment at: lib/Sema/SemaOverload.cpp:6095
+// Check that addr space of an object being constructed is convertible to
+// the one ctor qualified with.
+if (!Qualifiers::isAddressSpaceSupersetOf(

rjmccall wrote:
> Anastasia wrote:
> > rjmccall wrote:
> > > "Check that the constructor is capable of constructing an object in the 
> > > destination address space."
> > > 
> > > Should there be an exception here for trivial default/copy/move 
> > > constructors?
> > Good point. Current implementation is generating one overload of each 
> > default/copy/move in generic address space only. But we could potentially 
> > look at changing this. If we could add extra overloads once we encounter 
> > each new ctor invocation it would be the easiest approach and this code 
> > would still be applicable. However, I would need to understand the 
> > feasibility in more details. May be this is something for the future work? 
> > Or do you have other suggestions? 
> It's fine to leave it as future work.  I think synthesizing new overloads 
> after the fact will probably be problematic for the AST, though, and it'll be 
> easier to just treat trivial copy/move constructors (and assignment 
> operators, for that matter) as implicitly being able to construct objects in 
> all possible address spaces (as well as *from* all possible address spaces).
Ok, thanks! I will look into this later as a separate patch then.


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

https://reviews.llvm.org/D62156



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


[PATCH] D62808: [clangd] Print the ignored variant symbols

2019-06-03 Thread Haojian Wu via Phabricator via cfe-commits
hokein created this revision.
hokein added a reviewer: sammccall.
Herald added subscribers: kadircet, arphaman, jkorous, MaskRay, ilya-biryukov.
Herald added a project: clang.

so that we can better track those symbols.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D62808

Files:
  clang-tools-extra/clangd/include-mapping/gen_std.py
  clang-tools-extra/clangd/include-mapping/test.py

Index: clang-tools-extra/clangd/include-mapping/test.py
===
--- clang-tools-extra/clangd/include-mapping/test.py
+++ clang-tools-extra/clangd/include-mapping/test.py
@@ -15,26 +15,30 @@
 
   def testParseIndexPage(self):
 html = """
- abs() (int) 
- abs<>() (std::complex) 
+ abs()(int)
+ abs<>()(std::complex)
  acos() 
  acosh() (since C++11) 
  as_bytes<>() (since C++20) 
  """
 
-actual = ParseIndexPage(html)
-expected = [
-  ("abs", "abs.html", True),
-  ("abs", "complex/abs.html", True),
-  ("acos", "acos.html", False),
-  ("acosh", "acosh.html", False),
-  ("as_bytes", "as_bytes.html", False),
+(actual, variant) = ParseIndexPage(html)
+expected_actual = [
+  ("acos", "acos.html"),
+  ("acosh", "acosh.html"),
+  ("as_bytes", "as_bytes.html"),
 ]
-self.assertEqual(len(actual), len(expected))
+expected_variant = [
+  ("abs", "(int)"),
+  ("abs", "(std::complex)")
+]
+self.assertEqual(len(actual), len(expected_actual))
 for i in range(0, len(actual)):
-  self.assertEqual(expected[i][0], actual[i][0])
-  self.assertTrue(actual[i][1].endswith(expected[i][1]))
-  self.assertEqual(expected[i][2], actual[i][2])
+  self.assertEqual(expected_actual[i][0], actual[i][0])
+  self.assertTrue(actual[i][1].endswith(expected_actual[i][1]))
+self.assertEqual(len(variant), len(expected_variant))
+for i in range(0, len(variant)):
+  self.assertEqual(expected_variant[i], variant[i])
 
 
   def testParseSymbolPage_SingleHeader(self):
Index: clang-tools-extra/clangd/include-mapping/gen_std.py
===
--- clang-tools-extra/clangd/include-mapping/gen_std.py
+++ clang-tools-extra/clangd/include-mapping/gen_std.py
@@ -114,9 +114,12 @@
   abs() (int) 
   acos() 
 
-  Returns a list of tuple (symbol_name, relative_path_to_symbol_page, variant).
+  Returns a tuple
+( a list of tuple (symbol_name, relative_path_to_symbol_page),
+  a list of tuple (variant_symbol_name, caption_text) )
   """
   symbols = []
+  variant_symbols = []
   soup = BeautifulSoup(index_page_html, "html.parser")
   for symbol_href in soup.select("a[title]"):
 # Ignore annotated symbols like "acos<>() (std::complex)".
@@ -127,9 +130,12 @@
 variant = isinstance(caption, NavigableString) and "(" in caption
 symbol_tt = symbol_href.find("tt")
 if symbol_tt:
-  symbols.append((symbol_tt.text.rstrip("<>()"), # strip any trailing <>()
-  symbol_href["href"], variant))
-  return symbols
+  symbol_name = symbol_tt.text.rstrip("<>()") # strip any trailing <>()
+  if variant:
+variant_symbols.append((symbol_name, caption))
+  else:
+symbols.append((symbol_name, symbol_href["href"]))
+  return (symbols, variant_symbols)
 
 class Symbol:
 
@@ -163,11 +169,8 @@
   with open(index_page_path, "r") as f:
 # Read each symbol page in parallel.
 results = [] # (symbol_name, promise of [header...])
-for symbol_name, symbol_page_path, variant in ParseIndexPage(f.read()):
-  # Variant symbols (e.g. the std::locale version of isalpha) add ambiguity.
-  # FIXME: use these as a fallback rather than ignoring entirely.
-  if variant:
-continue
+(symbols, variant_symbols) = ParseIndexPage(f.read())
+for symbol_name, symbol_page_path in symbols:
   path = os.path.join(root_dir, symbol_page_path)
   results.append((symbol_name,
   pool.apply_async(ReadSymbolPage, (path, symbol_name
@@ -177,6 +180,11 @@
 for symbol_name, lazy_headers in results:
   symbol_headers[symbol_name].update(lazy_headers.get())
 
+for variant_symbol_name, caption in variant_symbols:
+  if variant_symbol_name not in symbol_headers:
+sys.stderr.write("Ignore variant symbol %s%s\n" % (variant_symbol_name,
+ caption))
+
   symbols = []
   for name, headers in sorted(symbol_headers.items(), key=lambda t : t[0]):
 symbols.append(Symbol(name, namespace, list(headers)))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r362398 - [OpenCL] Undefine cl_intel_planar_yuv extension

2019-06-03 Thread Andrew Savonichev via cfe-commits
Author: asavonic
Date: Mon Jun  3 06:02:43 2019
New Revision: 362398

URL: http://llvm.org/viewvc/llvm-project?rev=362398&view=rev
Log:
[OpenCL] Undefine cl_intel_planar_yuv extension

Summary:

Remove unnecessary definition (otherwise the extension will be defined
where it's not supposed to be defined).

Consider the code:

  #pragma OPENCL EXTENSION cl_intel_planar_yuv : begin
  // some declarations
  #pragma OPENCL EXTENSION cl_intel_planar_yuv : end

is enough for extension to become known for clang.

Patch by: Dmitry Sidorov 

Reviewers: Anastasia, yaxunl

Reviewed By: Anastasia

Tags: #clang

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

Modified:
cfe/trunk/lib/Headers/opencl-c.h
cfe/trunk/test/Headers/opencl-c-header.cl
cfe/trunk/test/SemaOpenCL/extension-begin.cl

Modified: cfe/trunk/lib/Headers/opencl-c.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/opencl-c.h?rev=362398&r1=362397&r2=362398&view=diff
==
--- cfe/trunk/lib/Headers/opencl-c.h (original)
+++ cfe/trunk/lib/Headers/opencl-c.h Mon Jun  3 06:02:43 2019
@@ -22,9 +22,6 @@
 #endif //__OPENCL_C_VERSION__ < CL_VERSION_2_0
 
 #if __OPENCL_C_VERSION__ >= CL_VERSION_1_2
-#ifndef cl_intel_planar_yuv
-#define cl_intel_planar_yuv
-#endif // cl_intel_planar_yuv
 #pragma OPENCL EXTENSION cl_intel_planar_yuv : begin
 #pragma OPENCL EXTENSION cl_intel_planar_yuv : end
 #endif // __OPENCL_C_VERSION__ >= CL_VERSION_1_2

Modified: cfe/trunk/test/Headers/opencl-c-header.cl
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Headers/opencl-c-header.cl?rev=362398&r1=362397&r2=362398&view=diff
==
--- cfe/trunk/test/Headers/opencl-c-header.cl (original)
+++ cfe/trunk/test/Headers/opencl-c-header.cl Mon Jun  3 06:02:43 2019
@@ -77,9 +77,6 @@ void test_image3dwo(write_only image3d_t
 // OpenCL 1.2 onwards.
 #if defined(__OPENCL_CPP_VERSION__) || (__OPENCL_C_VERSION__ >= CL_VERSION_1_2)
 // expected-no-diagnostics
-#ifndef cl_intel_planar_yuv
-#error "Missing cl_intel_planar_yuv define"
-#endif
 #else //__OPENCL_C_VERSION__
 // expected-warning@+2{{unknown OpenCL extension 'cl_intel_planar_yuv' - 
ignoring}}
 #endif //__OPENCL_C_VERSION__

Modified: cfe/trunk/test/SemaOpenCL/extension-begin.cl
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaOpenCL/extension-begin.cl?rev=362398&r1=362397&r2=362398&view=diff
==
--- cfe/trunk/test/SemaOpenCL/extension-begin.cl (original)
+++ cfe/trunk/test/SemaOpenCL/extension-begin.cl Mon Jun  3 06:02:43 2019
@@ -16,6 +16,13 @@
 //
 // RUN: %clang_cc1 -cl-std=CL2.0 -DIMPLICIT_INCLUDE -include 
%S/extension-begin.h -triple spir-unknown-unknown -O0 -emit-llvm -o - -fmodules 
-fimplicit-module-maps -fmodules-cache-path=%t.modules %s -verify -pedantic
 
+#pragma OPENCL EXTENSION my_ext : enable
+#ifndef IMPLICIT_INCLUDE
+// expected-warning@-2 {{unknown OpenCL extension 'my_ext' - ignoring}}
+// expected-warning@+2 {{unknown OpenCL extension 'my_ext' - ignoring}}
+#endif // IMPLICIT_INCLUDE
+#pragma OPENCL EXTENSION my_ext : disable
+
 #ifndef IMPLICIT_INCLUDE
 #include "extension-begin.h"
 #endif // IMPLICIT_INCLUDE


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


[PATCH] D58666: [OpenCL] Undefine cl_intel_planar_yuv extension

2019-06-03 Thread Andrew Savonichev via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL362398: [OpenCL] Undefine cl_intel_planar_yuv extension 
(authored by asavonic, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D58666?vs=188338&id=202700#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D58666

Files:
  cfe/trunk/lib/Headers/opencl-c.h
  cfe/trunk/test/Headers/opencl-c-header.cl
  cfe/trunk/test/SemaOpenCL/extension-begin.cl


Index: cfe/trunk/test/Headers/opencl-c-header.cl
===
--- cfe/trunk/test/Headers/opencl-c-header.cl
+++ cfe/trunk/test/Headers/opencl-c-header.cl
@@ -77,9 +77,6 @@
 // OpenCL 1.2 onwards.
 #if defined(__OPENCL_CPP_VERSION__) || (__OPENCL_C_VERSION__ >= CL_VERSION_1_2)
 // expected-no-diagnostics
-#ifndef cl_intel_planar_yuv
-#error "Missing cl_intel_planar_yuv define"
-#endif
 #else //__OPENCL_C_VERSION__
 // expected-warning@+2{{unknown OpenCL extension 'cl_intel_planar_yuv' - 
ignoring}}
 #endif //__OPENCL_C_VERSION__
Index: cfe/trunk/test/SemaOpenCL/extension-begin.cl
===
--- cfe/trunk/test/SemaOpenCL/extension-begin.cl
+++ cfe/trunk/test/SemaOpenCL/extension-begin.cl
@@ -16,6 +16,13 @@
 //
 // RUN: %clang_cc1 -cl-std=CL2.0 -DIMPLICIT_INCLUDE -include 
%S/extension-begin.h -triple spir-unknown-unknown -O0 -emit-llvm -o - -fmodules 
-fimplicit-module-maps -fmodules-cache-path=%t.modules %s -verify -pedantic
 
+#pragma OPENCL EXTENSION my_ext : enable
+#ifndef IMPLICIT_INCLUDE
+// expected-warning@-2 {{unknown OpenCL extension 'my_ext' - ignoring}}
+// expected-warning@+2 {{unknown OpenCL extension 'my_ext' - ignoring}}
+#endif // IMPLICIT_INCLUDE
+#pragma OPENCL EXTENSION my_ext : disable
+
 #ifndef IMPLICIT_INCLUDE
 #include "extension-begin.h"
 #endif // IMPLICIT_INCLUDE
Index: cfe/trunk/lib/Headers/opencl-c.h
===
--- cfe/trunk/lib/Headers/opencl-c.h
+++ cfe/trunk/lib/Headers/opencl-c.h
@@ -22,9 +22,6 @@
 #endif //__OPENCL_C_VERSION__ < CL_VERSION_2_0
 
 #if __OPENCL_C_VERSION__ >= CL_VERSION_1_2
-#ifndef cl_intel_planar_yuv
-#define cl_intel_planar_yuv
-#endif // cl_intel_planar_yuv
 #pragma OPENCL EXTENSION cl_intel_planar_yuv : begin
 #pragma OPENCL EXTENSION cl_intel_planar_yuv : end
 #endif // __OPENCL_C_VERSION__ >= CL_VERSION_1_2


Index: cfe/trunk/test/Headers/opencl-c-header.cl
===
--- cfe/trunk/test/Headers/opencl-c-header.cl
+++ cfe/trunk/test/Headers/opencl-c-header.cl
@@ -77,9 +77,6 @@
 // OpenCL 1.2 onwards.
 #if defined(__OPENCL_CPP_VERSION__) || (__OPENCL_C_VERSION__ >= CL_VERSION_1_2)
 // expected-no-diagnostics
-#ifndef cl_intel_planar_yuv
-#error "Missing cl_intel_planar_yuv define"
-#endif
 #else //__OPENCL_C_VERSION__
 // expected-warning@+2{{unknown OpenCL extension 'cl_intel_planar_yuv' - ignoring}}
 #endif //__OPENCL_C_VERSION__
Index: cfe/trunk/test/SemaOpenCL/extension-begin.cl
===
--- cfe/trunk/test/SemaOpenCL/extension-begin.cl
+++ cfe/trunk/test/SemaOpenCL/extension-begin.cl
@@ -16,6 +16,13 @@
 //
 // RUN: %clang_cc1 -cl-std=CL2.0 -DIMPLICIT_INCLUDE -include %S/extension-begin.h -triple spir-unknown-unknown -O0 -emit-llvm -o - -fmodules -fimplicit-module-maps -fmodules-cache-path=%t.modules %s -verify -pedantic
 
+#pragma OPENCL EXTENSION my_ext : enable
+#ifndef IMPLICIT_INCLUDE
+// expected-warning@-2 {{unknown OpenCL extension 'my_ext' - ignoring}}
+// expected-warning@+2 {{unknown OpenCL extension 'my_ext' - ignoring}}
+#endif // IMPLICIT_INCLUDE
+#pragma OPENCL EXTENSION my_ext : disable
+
 #ifndef IMPLICIT_INCLUDE
 #include "extension-begin.h"
 #endif // IMPLICIT_INCLUDE
Index: cfe/trunk/lib/Headers/opencl-c.h
===
--- cfe/trunk/lib/Headers/opencl-c.h
+++ cfe/trunk/lib/Headers/opencl-c.h
@@ -22,9 +22,6 @@
 #endif //__OPENCL_C_VERSION__ < CL_VERSION_2_0
 
 #if __OPENCL_C_VERSION__ >= CL_VERSION_1_2
-#ifndef cl_intel_planar_yuv
-#define cl_intel_planar_yuv
-#endif // cl_intel_planar_yuv
 #pragma OPENCL EXTENSION cl_intel_planar_yuv : begin
 #pragma OPENCL EXTENSION cl_intel_planar_yuv : end
 #endif // __OPENCL_C_VERSION__ >= CL_VERSION_1_2
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D62445: [test] Fix plugin tests

2019-06-03 Thread David Zarzycki via Phabricator via cfe-commits
davezarzycki added a comment.

This broke non-PIC builds. Fixed: r362399


Repository:
  rL LLVM

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

https://reviews.llvm.org/D62445



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


[PATCH] D62413: [OpenCL][PR41727] Prevent ICE on global dtors

2019-06-03 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia updated this revision to Diff 202708.
Anastasia added a comment.

- Guard OpenCL specific IR generation under OpenCL lang mode


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

https://reviews.llvm.org/D62413

Files:
  lib/CodeGen/CGDeclCXX.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/CodeGen/ItaniumCXXABI.cpp
  test/CodeGenOpenCLCXX/atexit.cl

Index: test/CodeGenOpenCLCXX/atexit.cl
===
--- /dev/null
+++ test/CodeGenOpenCLCXX/atexit.cl
@@ -0,0 +1,11 @@
+//RUN: %clang_cc1 %s -triple spir -cl-std=c++ -emit-llvm -O0 -o - | FileCheck %s
+
+struct S {
+  ~S(){};
+};
+S s;
+
+//CHECK-LABEL: define internal void @__cxx_global_var_init()
+// call i32 @__cxa_atexit(void (i8*)* bitcast (void (%struct.S addrspace(4)*)* @_ZNU3AS41SD1Ev to void (i8*)*), i8 addrspace(1)* getelementptr inbounds (%struct.S, %struct.S addrspace(1)* @s, i32 0, i32 0), i8 addrspace(1)* @__dso_handle)
+
+//declare i32 @__cxa_atexit(void (i8*)*, i8 addrspace(1)*, i8 addrspace(1)*)
Index: lib/CodeGen/ItaniumCXXABI.cpp
===
--- lib/CodeGen/ItaniumCXXABI.cpp
+++ lib/CodeGen/ItaniumCXXABI.cpp
@@ -2282,8 +2282,19 @@
   llvm::Type *dtorTy =
 llvm::FunctionType::get(CGF.VoidTy, CGF.Int8PtrTy, false)->getPointerTo();
 
+  // Preserve address space of addr.
+  auto AddrAS = addr ? addr->getType()->getPointerAddressSpace() : 0;
+  auto AddrInt8PtrTy =
+  AddrAS ? CGF.Int8Ty->getPointerTo(AddrAS) : CGF.Int8PtrTy;
+
+  // Create a variable that binds the atexit to this shared object.
+  llvm::Constant *handle =
+  CGF.CGM.CreateRuntimeVariable(CGF.Int8Ty, "__dso_handle");
+  auto *GV = cast(handle->stripPointerCasts());
+  GV->setVisibility(llvm::GlobalValue::HiddenVisibility);
+
   // extern "C" int __cxa_atexit(void (*f)(void *), void *p, void *d);
-  llvm::Type *paramTys[] = { dtorTy, CGF.Int8PtrTy, CGF.Int8PtrTy };
+  llvm::Type *paramTys[] = {dtorTy, AddrInt8PtrTy, handle->getType()};
   llvm::FunctionType *atexitTy =
 llvm::FunctionType::get(CGF.IntTy, paramTys, false);
 
@@ -2292,12 +2303,6 @@
   if (llvm::Function *fn = dyn_cast(atexit.getCallee()))
 fn->setDoesNotThrow();
 
-  // Create a variable that binds the atexit to this shared object.
-  llvm::Constant *handle =
-  CGF.CGM.CreateRuntimeVariable(CGF.Int8Ty, "__dso_handle");
-  auto *GV = cast(handle->stripPointerCasts());
-  GV->setVisibility(llvm::GlobalValue::HiddenVisibility);
-
   if (!addr)
 // addr is null when we are trying to register a dtor annotated with
 // __attribute__((destructor)) in a constructor function. Using null here is
@@ -2307,7 +2312,7 @@
 
   llvm::Value *args[] = {llvm::ConstantExpr::getBitCast(
  cast(dtor.getCallee()), dtorTy),
- llvm::ConstantExpr::getBitCast(addr, CGF.Int8PtrTy),
+ llvm::ConstantExpr::getBitCast(addr, AddrInt8PtrTy),
  handle};
   CGF.EmitNounwindRuntimeCall(atexit, args);
 }
Index: lib/CodeGen/CodeGenModule.cpp
===
--- lib/CodeGen/CodeGenModule.cpp
+++ lib/CodeGen/CodeGenModule.cpp
@@ -3566,8 +3566,12 @@
 llvm::Constant *
 CodeGenModule::CreateRuntimeVariable(llvm::Type *Ty,
  StringRef Name) {
-  auto *Ret =
-  GetOrCreateLLVMGlobal(Name, llvm::PointerType::getUnqual(Ty), nullptr);
+  auto PtrTy =
+  getContext().getLangOpts().OpenCL
+  ? llvm::PointerType::get(
+Ty, getContext().getTargetAddressSpace(LangAS::opencl_global))
+  : llvm::PointerType::getUnqual(Ty);
+  auto *Ret = GetOrCreateLLVMGlobal(Name, PtrTy, nullptr);
   setDSOLocal(cast(Ret->stripPointerCasts()));
   return Ret;
 }
Index: lib/CodeGen/CGDeclCXX.cpp
===
--- lib/CodeGen/CGDeclCXX.cpp
+++ lib/CodeGen/CGDeclCXX.cpp
@@ -14,6 +14,7 @@
 #include "CGCXXABI.h"
 #include "CGObjCRuntime.h"
 #include "CGOpenMPRuntime.h"
+#include "TargetInfo.h"
 #include "clang/Basic/CodeGenOptions.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/IR/Intrinsics.h"
@@ -118,9 +119,22 @@
 CXXDestructorDecl *Dtor = Record->getDestructor();
 
 Func = CGM.getAddrAndTypeOfCXXStructor(GlobalDecl(Dtor, Dtor_Complete));
-Argument = llvm::ConstantExpr::getBitCast(
-Addr.getPointer(), CGF.getTypes().ConvertType(Type)->getPointerTo());
-
+if (CGF.getContext().getLangOpts().OpenCL) {
+  // FIXME: A solution is needed for opencl_constant. We could create
+  // atexit_constant, but more generic solution would probably be to mangle
+  // address space?
+  auto DestTy = CGF.getTypes().ConvertType(Type)->getPointerTo(
+  CGM.getContext().getTargetAddressSpace(LangAS::opencl_global));
+  auto SrcAS = D.getType().getQualifiers().getAddressSpace();
+  if (LangAS::opencl_global == Src

[PATCH] D62739: AMDGPU: Always emit amdgpu-flat-work-group-size

2019-06-03 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm marked an inline comment as done.
arsenm added inline comments.



Comment at: lib/CodeGen/TargetInfo.cpp:7885
+// By default, restrict the maximum size to 256.
+F->addFnAttr("amdgpu-flat-work-group-size", "128,256");
   }

yaxunl wrote:
> arsenm wrote:
> > b-sumner wrote:
> > > Theoretically, shouldn't the minimum be 1?
> > That's what I thought, but the backend is defaulting to 2 * wave size now
> I don't get it. This attribute indicates the possible workgroup size range 
> this kernel may be run with, right? It only depends on how user execute the 
> kernel. How is it related to backend defaults?
The backend currently assumes 128,256 by default as the bounds. I want to make 
this a frontend decision, and make the backend assumption the most conservative 
default


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

https://reviews.llvm.org/D62739



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


[PATCH] D62413: [OpenCL][PR41727] Prevent ICE on global dtors

2019-06-03 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia marked an inline comment as done.
Anastasia added inline comments.



Comment at: lib/CodeGen/CGDeclCXX.cpp:132
+  Argument = CGM.getTargetCodeGenInfo().performAddrSpaceCast(
+  CGM, Addr.getPointer(), SrcAS, LangAS::opencl_global, DestTy);
 

rjmccall wrote:
> Should this code be conditional to OpenCL?  And why does `_cxa_atexit` take a 
> `__global` pointer instead of, say, a `__generic` one?
The only objects that are destructible globally in OpenCL are `__global` and 
`__constant`. However `__constant` isn't convertible to `__generic`. Therefore, 
I am adding `__global` directly to avoid extra conversion. I am not yet sure 
how to handle `__constant`though and how much destructing objects in read-only 
memory segments would make sense anyway. I think I will address this separately.


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

https://reviews.llvm.org/D62413



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


[PATCH] D62782: Fix -Wdouble-promotion warnings.

2019-06-03 Thread Marshall Clow via Phabricator via cfe-commits
mclow.lists added a comment.

This looks fine to me; but where were you getting these warnings?


Repository:
  rCXX libc++

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

https://reviews.llvm.org/D62782



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


[PATCH] D59744: Fix i386 ABI "__m64" type bug

2019-06-03 Thread Wei Xiao via Phabricator via cfe-commits
wxiao3 added a comment.

Consider other Systems (e.g Darwin, PS4 and FreeBSD) don't want to spend any 
effort dealing with the ramifications of ABI breaks (as discussed in 
https://reviews.llvm.org/D60748) at present, I only fix the bug for Linux. If 
other system wants the fix, the only thing needed is to add a flag (like 
"IsLinuxABI" ) to enable it.


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

https://reviews.llvm.org/D59744



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


[PATCH] D48866: [clang-tidy] Add incorrect-pointer-cast checker

2019-06-03 Thread Balázs Benics via Phabricator via cfe-commits
steakhal commandeered this revision.
steakhal added a reviewer: hgabii.
steakhal added a comment.

If you don't mind I will finish the leftover work. This will still be committed 
under your name.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D48866



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


[PATCH] D48866: [clang-tidy] Add incorrect-pointer-cast checker

2019-06-03 Thread Balázs Benics via Phabricator via cfe-commits
steakhal updated this revision to Diff 202717.
steakhal added a comment.

Unfortunately the changes that I've made are not available in a diff because 
I've moved to the monorepo version.
Although, you can see the changes in detail on my llvm-project github fork 
.

There were only minor changes.

- Updated the license, as requested
- Moved the checker to the 'bugprone' category from 'misc'
- Fixed bug: now using `getAsRecordDecl` instead of `getAsCXXRecordDecl`

**There is still an open question** whether we should relay on the warnings of 
the `-Wcast-align` option, but I'm not convinced.


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

https://reviews.llvm.org/D48866

Files:
  clang-tools-extra/clang-tidy/bugprone/BugproneTidyModule.cpp
  clang-tools-extra/clang-tidy/bugprone/CMakeLists.txt
  clang-tools-extra/clang-tidy/bugprone/IncorrectPointerCastCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/IncorrectPointerCastCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/bugprone-incorrect-pointer-cast.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/bugprone-incorrect-pointer-cast.cpp

Index: clang-tools-extra/test/clang-tidy/bugprone-incorrect-pointer-cast.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/bugprone-incorrect-pointer-cast.cpp
@@ -0,0 +1,206 @@
+// RUN: %check_clang_tidy %s bugprone-incorrect-pointer-cast %t -- \
+// RUN:   -config="{CheckOptions: [{key: bugprone-incorrect-pointer-cast.WarnForDifferentSignedness, value: 1}]}" --
+
+bool b;
+char __attribute__((aligned(4))) a[16];
+
+struct S0 {
+  char a[16];
+};
+
+struct S01 {
+  char __attribute__((aligned(4))) a[16];
+  struct S0 __attribute__((aligned(4))) s0;
+};
+
+struct S1 {
+  int a;
+  int b;
+};
+
+struct S2 {
+  int a;
+};
+
+struct S3 {
+  int a;
+  double b;
+};
+
+struct S4 {
+  int x;
+  double y;
+};
+
+struct S5 {
+  double y;
+  int x;
+};
+
+struct __attribute__((aligned(16))) SAligned {
+  char buffer[16];
+};
+
+void initDouble(double *d) {
+  *d = 0.5;
+}
+
+void castCharToInt(void) {
+  char c = 'x';
+  b = (int *)&c;
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: cast from 'char' to 'int' may lead to access memory based on invalid memory layout; pointed to type is wider than the allocated type [bugprone-incorrect-pointer-cast]
+  b = reinterpret_cast(&c);
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: cast from 'char' to 'int' may lead to access memory based on invalid memory layout; pointed to type is wider than the allocated type [bugprone-incorrect-pointer-cast]
+}
+
+void castCharToSort(char c) {
+  b = (short *)&c;
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: cast from 'char' to 'short' may lead to access memory based on invalid memory layout; pointed to type is wider than the allocated type [bugprone-incorrect-pointer-cast]
+  b = reinterpret_cast(&c);
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: cast from 'char' to 'short' may lead to access memory based on invalid memory layout; pointed to type is wider than the allocated type [bugprone-incorrect-pointer-cast]
+}
+
+void castShortToInt(short s) {
+  b = (int *)&s;
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: cast from 'short' to 'int' may lead to access memory based on invalid memory layout; pointed to type is wider than the allocated type [bugprone-incorrect-pointer-cast]
+  b = reinterpret_cast(&s);
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: cast from 'short' to 'int' may lead to access memory based on invalid memory layout; pointed to type is wider than the allocated type [bugprone-incorrect-pointer-cast]
+}
+
+void castWideCharToLong(wchar_t wc) {
+  b = (long *)&wc;
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: cast from 'wchar_t' to 'long' may lead to access memory based on invalid memory layout; pointed to type is wider than the allocated type [bugprone-incorrect-pointer-cast]
+  b = reinterpret_cast(&wc);
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: cast from 'wchar_t' to 'long' may lead to access memory based on invalid memory layout; pointed to type is wider than the allocated type [bugprone-incorrect-pointer-cast]
+}
+
+void castFloatToDouble(float f) {
+  initDouble((double *)&f);
+  // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: cast from 'float' to 'double' may lead to access memory based on invalid memory layout; pointed to type is wider than the allocated type [bugprone-incorrect-pointer-cast]
+  initDouble(reinterpret_cast(&f));
+  // CHECK-MESSAGES: :[[@LINE-1]]:14: warning: cast from 'float' to 'double' may lead to access memory based on invalid memory layout; pointed to type is wider than the allocated type [bugprone-incorrect-pointer-cast]
+}
+
+void castToS2(char *data, unsigned offset) {
+  b = (struct S2 *)(data + offset);
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: wa

[PATCH] D62591: [OpenCL][PR42031] Prevent deducing addr space in type alias.

2019-06-03 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia updated this revision to Diff 202721.
Anastasia added a comment.

- Exclude pointee from early return in addr space deduction
- Improved testing: added FileCheck and avoid testing unnecessary bits


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

https://reviews.llvm.org/D62591

Files:
  lib/Sema/SemaType.cpp
  test/SemaOpenCLCXX/address-space-deduction.cl


Index: test/SemaOpenCLCXX/address-space-deduction.cl
===
--- test/SemaOpenCLCXX/address-space-deduction.cl
+++ test/SemaOpenCLCXX/address-space-deduction.cl
@@ -1,13 +1,13 @@
-//RUN: %clang_cc1 %s -cl-std=c++ -pedantic -ast-dump -verify
+//RUN: %clang_cc1 %s -cl-std=c++ -pedantic -ast-dump -verify | FileCheck %s
 
 //expected-no-diagnostics
 
-//CHECK: |-VarDecl  foo {{.*}} 'const __global int' constexpr cinit
+//CHECK: |-VarDecl {{.*}} foo 'const __global int'
 constexpr int foo = 0;
 
 class c {
 public:
-  //CHECK: `-VarDecl {{.*}} foo2 'const __global int' static constexpr cinit
+  //CHECK: `-VarDecl {{.*}} foo2 'const __global int'
   static constexpr int foo2 = 0;
 };
 
@@ -15,7 +15,7 @@
 void xxx(T *in) {
   // This pointer can't be deduced to generic because addr space
   // will be taken from the template argument.
-  //CHECK: `-VarDecl {{.*}} i 'T *' cinit
+  //CHECK: `-VarDecl {{.*}} i 'T *'
   T *i = in;
 }
 
@@ -23,3 +23,16 @@
   int foo[10];
   xxx(&foo[0]);
 }
+
+struct c1 {};
+
+// We only deduce addr space in type alias in pointer types.
+//CHECK: TypeAliasDecl {{.*}} alias_c1 'c1'
+using alias_c1 = c1;
+//CHECK: TypeAliasDecl {{.*}} alias_c1_ptr '__generic c1 *'
+using alias_c1_ptr = c1 *;
+
+struct c2 {
+  alias_c1 y;
+  alias_c1_ptr ptr = &y;
+};
Index: lib/Sema/SemaType.cpp
===
--- lib/Sema/SemaType.cpp
+++ lib/Sema/SemaType.cpp
@@ -7350,6 +7350,9 @@
   (D.getContext() == DeclaratorContext::MemberContext &&
(!IsPointee &&
 D.getDeclSpec().getStorageClassSpec() != DeclSpec::SCS_static)) ||
+  // Do not deduce addr space of non-pointee in type alias because it
+  // doesn't define any object.
+  (D.getContext() == DeclaratorContext::AliasDeclContext && !IsPointee) ||
   // Do not deduce addr space for types used to define a typedef and the
   // typedef itself, except the pointee type of a pointer type which is 
used
   // to define the typedef.


Index: test/SemaOpenCLCXX/address-space-deduction.cl
===
--- test/SemaOpenCLCXX/address-space-deduction.cl
+++ test/SemaOpenCLCXX/address-space-deduction.cl
@@ -1,13 +1,13 @@
-//RUN: %clang_cc1 %s -cl-std=c++ -pedantic -ast-dump -verify
+//RUN: %clang_cc1 %s -cl-std=c++ -pedantic -ast-dump -verify | FileCheck %s
 
 //expected-no-diagnostics
 
-//CHECK: |-VarDecl  foo {{.*}} 'const __global int' constexpr cinit
+//CHECK: |-VarDecl {{.*}} foo 'const __global int'
 constexpr int foo = 0;
 
 class c {
 public:
-  //CHECK: `-VarDecl {{.*}} foo2 'const __global int' static constexpr cinit
+  //CHECK: `-VarDecl {{.*}} foo2 'const __global int'
   static constexpr int foo2 = 0;
 };
 
@@ -15,7 +15,7 @@
 void xxx(T *in) {
   // This pointer can't be deduced to generic because addr space
   // will be taken from the template argument.
-  //CHECK: `-VarDecl {{.*}} i 'T *' cinit
+  //CHECK: `-VarDecl {{.*}} i 'T *'
   T *i = in;
 }
 
@@ -23,3 +23,16 @@
   int foo[10];
   xxx(&foo[0]);
 }
+
+struct c1 {};
+
+// We only deduce addr space in type alias in pointer types.
+//CHECK: TypeAliasDecl {{.*}} alias_c1 'c1'
+using alias_c1 = c1;
+//CHECK: TypeAliasDecl {{.*}} alias_c1_ptr '__generic c1 *'
+using alias_c1_ptr = c1 *;
+
+struct c2 {
+  alias_c1 y;
+  alias_c1_ptr ptr = &y;
+};
Index: lib/Sema/SemaType.cpp
===
--- lib/Sema/SemaType.cpp
+++ lib/Sema/SemaType.cpp
@@ -7350,6 +7350,9 @@
   (D.getContext() == DeclaratorContext::MemberContext &&
(!IsPointee &&
 D.getDeclSpec().getStorageClassSpec() != DeclSpec::SCS_static)) ||
+  // Do not deduce addr space of non-pointee in type alias because it
+  // doesn't define any object.
+  (D.getContext() == DeclaratorContext::AliasDeclContext && !IsPointee) ||
   // Do not deduce addr space for types used to define a typedef and the
   // typedef itself, except the pointee type of a pointer type which is used
   // to define the typedef.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D62591: [OpenCL][PR42031] Prevent deducing addr space in type alias.

2019-06-03 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added a comment.

@mantognini Good spot! Thanks!


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

https://reviews.llvm.org/D62591



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


[PATCH] D48866: [clang-tidy] Add incorrect-pointer-cast checker

2019-06-03 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

Some basic thoughts




Comment at: 
clang-tools-extra/clang-tidy/bugprone/IncorrectPointerCastCheck.cpp:63
+ "cast from %0 to %1 may lead to access memory based on invalid memory 
"
+ "layout; pointed to type is wider than the allocated type")
+<< SrcPointedType << DestPointedType;

this reads weirdly, should be
"new type is wider (%2) than the original type (%3)"




Comment at: 
clang-tools-extra/clang-tidy/bugprone/IncorrectPointerCastCheck.cpp:69-70
+ "cast from %0 to %1 may lead to access memory based on invalid "
+ "memory layout; pointed to type is strictly aligned than the "
+ "allocated type")
+<< SrcPointedType << DestPointedType;

"*more* strictly aligned" perhaps?
Similarly, specify the actual values.



Comment at: 
clang-tools-extra/clang-tidy/bugprone/IncorrectPointerCastCheck.cpp:88
+  if (SrcField.getType() != DestField.getType() || SrcIterator == SrcEnd) {
+FieldsAreSame = false;
+  }

`break;'?



Comment at: 
clang-tools-extra/clang-tidy/bugprone/IncorrectPointerCastCheck.cpp:95
+   "cast from %0 to %1 may lead to access memory based on invalid "
+   "memory layout; struct members are incompatible")
+  << SrcPointedType << DestPointedType;

Would be better to at least point to first two incompatible fields



Comment at: 
clang-tools-extra/clang-tidy/bugprone/IncorrectPointerCastCheck.cpp:98-107
+  } else if (WarnForDifferentSignedness &&
+ ((SrcPointedType->isSignedIntegerType() &&
+   DestPointedType->isUnsignedIntegerType()) ||
+  (SrcPointedType->isUnsignedIntegerType() &&
+   DestPointedType->isSignedIntegerType( {
+diag(castExpr->getBeginLoc(),
+ "cast from %0 to %1 may lead to access memory based on invalid "

What does this mean?
How can signedness affect memory layout?



Comment at: clang-tools-extra/clang-tidy/bugprone/IncorrectPointerCastCheck.h:18
+
+/// Warns for cases when pointer is cast and the pointed to type is 
incompatible
+/// with allocated memory area type. This may lead to access memory based on

is cast*ed*
s/pointed to/new/



Comment at: clang-tools-extra/clang-tidy/bugprone/IncorrectPointerCastCheck.h:19
+/// Warns for cases when pointer is cast and the pointed to type is 
incompatible
+/// with allocated memory area type. This may lead to access memory based on
+/// invalid memory layout.

How do you know anything about the actual `allocated memory area type`.
You probably want to talk about the original type before cast.


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

https://reviews.llvm.org/D48866



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


[PATCH] D59673: [Clang] Harmonize Split DWARF options with llc

2019-06-03 Thread Aaron Puchert via Phabricator via cfe-commits
aaronpuchert marked an inline comment as done.
aaronpuchert added a comment.

In D59673#1521413 , @dblaikie wrote:

> Might be easier as a few patches - renaming the existing option, adding the 
> new one, then removing the single split dwarf flag handling in favor of 
> implying that by the absence of an output file name.


No problem, makes sense to me. I'll see if it's possible to separate these 
changes.

> if I'm reading what this patch does

Yes, that seems to be how `llc` behaves, and I want to copy that.




Comment at: lib/CodeGen/BackendUtil.cpp:847
   default:
-if (!CodeGenOpts.SplitDwarfFile.empty() &&
-(CodeGenOpts.getSplitDwarfMode() == CodeGenOptions::SplitFileFission)) 
{
-  DwoOS = openOutputFile(CodeGenOpts.SplitDwarfFile);
+if (CodeGenOpts.EnableSplitDwarf && !CodeGenOpts.SplitDwarfOutput.empty()) 
{
+  DwoOS = openOutputFile(CodeGenOpts.SplitDwarfOutput);

dblaikie wrote:
> Why did this add a check for EnableSplitDwarf here that wasn't there before?
I just changed the order, the check was there as 
`(CodeGenOpts.getSplitDwarfMode() == CodeGenOptions::SplitFileFission)` in the 
second line of the `if`.


Repository:
  rC Clang

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

https://reviews.llvm.org/D59673



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


[PATCH] D50989: Remove Darwin support from POWER backend.

2019-06-03 Thread Kit Barton via Phabricator via cfe-commits
kbarton closed this revision.
kbarton added a comment.
Herald added a subscriber: jsji.

This landed in https://reviews.llvm.org/rL340770.


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

https://reviews.llvm.org/D50989



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


[PATCH] D60455: [SYCL] Implement SYCL device code outlining

2019-06-03 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added inline comments.



Comment at: clang/test/CodeGenSYCL/device-functions.cpp:24
+}
+// CHECK: define spir_func void @{{.*}}foo
+// CHECK: define linkonce_odr spir_func i32 @{{.*}}bar

Fznamznon wrote:
> Anastasia wrote:
> > Fznamznon wrote:
> > > Anastasia wrote:
> > > > I can't see where the SPIR calling convention is currently set for SYCL?
> > > If I understand correct it's set automatically on AST level because we 
> > > use SPIR-based triple for device code. Only in case of C++ methods clang 
> > > doesn't set SPIR calling convention. We did a modification in our 
> > > codebase to get SPIR calling convention for C++ methods too (available [[ 
> > > https://github.com/intel/llvm/blob/c13cb8df84418cb5d682f3bbee89090ebb0d00be/clang/lib/AST/ASTContext.cpp#L10015
> > >  | here ]] ) 
> > > 
> > Ok and what happens if some other target is used - not SPIR?
> There will be no SPIR calling convention for device functions.
Just FYI at some point we generalized SPIR calling convention to be used for 
kernels irrespective from target by default (see 
`TargetCodeGenInfo::getOpenCLKernelCallingConv`). Not sure if it might make 
sense to do for SYCL device functions too. I am not saying it belongs to this 
patch though.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60455



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


[PATCH] D48866: [clang-tidy] Add incorrect-pointer-cast checker

2019-06-03 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

Also, this kinda feels like this shouldn't be a single check.

1. I'm very much looking forward the alignment part of this, the 
`reinterpret_cast<>()` specifically. It would be good to have a switch to also 
diagnose casts from `void*` here. But indeed, if it comes from c-style cast, 
`-Wcast-align` will already have diagnosed it.
2. Then there is 'cast increases type width' check, makes sense i suppose.
3. 'struct layout mismatch', makes sense.
4. I don't understand the 'different signdness' part.


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

https://reviews.llvm.org/D48866



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


[PATCH] D48866: [clang-tidy] Add incorrect-pointer-cast checker

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

The problem with the `-Wcast-align` is that it will only fire for C-style 
bitcast expressions, not for `reinterpret_cast` ones. example 

Does anyone know why is that behavior?


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

https://reviews.llvm.org/D48866



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


[PATCH] D48866: [clang-tidy] Add incorrect-pointer-cast checker

2019-06-03 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

In D48866#1527506 , @steakhal wrote:

> The problem with the `-Wcast-align` is that it will only fire for C-style 
> bitcast expressions, not for `reinterpret_cast` ones. example 
> 
>  Does anyone know why is that behavior?


Because `reinterpret_cast` is by definition allowed to perform these casts, so 
it is assumed that no warning should be issued.
This part of the check i look forward to.


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

https://reviews.llvm.org/D48866



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


[PATCH] D62445: [test] Fix plugin tests

2019-06-03 Thread Don Hinton via Phabricator via cfe-commits
hintonda added a comment.

In D62445#1527368 , @davezarzycki 
wrote:

> This broke non-PIC builds. Fixed: r362399


Sorry for the breakage, and thanks for the fix!


Repository:
  rL LLVM

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

https://reviews.llvm.org/D62445



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


r362409 - [PR41567][Sema] Fixed cast kind in addr space conversions

2019-06-03 Thread Anastasia Stulova via cfe-commits
Author: stulova
Date: Mon Jun  3 08:42:36 2019
New Revision: 362409

URL: http://llvm.org/viewvc/llvm-project?rev=362409&view=rev
Log:
[PR41567][Sema] Fixed cast kind in addr space conversions

This change sets missing cast kind correctly in the address
space conversion case.

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


Added:
cfe/trunk/test/CodeGenOpenCLCXX/addrspace-conversion.cl
Modified:
cfe/trunk/lib/Sema/SemaCast.cpp

Modified: cfe/trunk/lib/Sema/SemaCast.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaCast.cpp?rev=362409&r1=362408&r2=362409&view=diff
==
--- cfe/trunk/lib/Sema/SemaCast.cpp (original)
+++ cfe/trunk/lib/Sema/SemaCast.cpp Mon Jun  3 08:42:36 2019
@@ -2450,6 +2450,10 @@ void CastOperation::CheckCXXCStyleCast(b
 tcr = TryAddressSpaceCast(Self, SrcExpr, DestType, /*CStyle*/ true, msg);
 if (SrcExpr.isInvalid())
   return;
+
+if (isValidCast(tcr))
+  Kind = CK_AddressSpaceConversion;
+
 if (tcr == TC_NotApplicable) {
   // ... or if that is not possible, a static_cast, ignoring const, ...
   tcr = TryStaticCast(Self, SrcExpr, DestType, CCK, OpRange, msg, Kind,

Added: cfe/trunk/test/CodeGenOpenCLCXX/addrspace-conversion.cl
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenOpenCLCXX/addrspace-conversion.cl?rev=362409&view=auto
==
--- cfe/trunk/test/CodeGenOpenCLCXX/addrspace-conversion.cl (added)
+++ cfe/trunk/test/CodeGenOpenCLCXX/addrspace-conversion.cl Mon Jun  3 08:42:36 
2019
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 %s -triple spir-unknown-unknown -cl-std=c++ -emit-llvm -O0 
-o - | FileCheck %s
+
+void bar(__generic volatile unsigned int* ptr)
+{
+  //CHECK: addrspacecast i32 addrspace(4)* %{{.+}} to i32 addrspace(1)*
+  auto gptr = (__global volatile unsigned int*)ptr;
+}


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


[PATCH] D62299: [PR41567][Sema] Fixed cast kind in addr space conversions

2019-06-03 Thread Phabricator via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL362409: [PR41567][Sema] Fixed cast kind in addr space 
conversions (authored by stulova, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D62299?vs=200920&id=202730#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D62299

Files:
  cfe/trunk/lib/Sema/SemaCast.cpp
  cfe/trunk/test/CodeGenOpenCLCXX/addrspace-conversion.cl


Index: cfe/trunk/lib/Sema/SemaCast.cpp
===
--- cfe/trunk/lib/Sema/SemaCast.cpp
+++ cfe/trunk/lib/Sema/SemaCast.cpp
@@ -2450,6 +2450,10 @@
 tcr = TryAddressSpaceCast(Self, SrcExpr, DestType, /*CStyle*/ true, msg);
 if (SrcExpr.isInvalid())
   return;
+
+if (isValidCast(tcr))
+  Kind = CK_AddressSpaceConversion;
+
 if (tcr == TC_NotApplicable) {
   // ... or if that is not possible, a static_cast, ignoring const, ...
   tcr = TryStaticCast(Self, SrcExpr, DestType, CCK, OpRange, msg, Kind,
Index: cfe/trunk/test/CodeGenOpenCLCXX/addrspace-conversion.cl
===
--- cfe/trunk/test/CodeGenOpenCLCXX/addrspace-conversion.cl
+++ cfe/trunk/test/CodeGenOpenCLCXX/addrspace-conversion.cl
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 %s -triple spir-unknown-unknown -cl-std=c++ -emit-llvm -O0 
-o - | FileCheck %s
+
+void bar(__generic volatile unsigned int* ptr)
+{
+  //CHECK: addrspacecast i32 addrspace(4)* %{{.+}} to i32 addrspace(1)*
+  auto gptr = (__global volatile unsigned int*)ptr;
+}


Index: cfe/trunk/lib/Sema/SemaCast.cpp
===
--- cfe/trunk/lib/Sema/SemaCast.cpp
+++ cfe/trunk/lib/Sema/SemaCast.cpp
@@ -2450,6 +2450,10 @@
 tcr = TryAddressSpaceCast(Self, SrcExpr, DestType, /*CStyle*/ true, msg);
 if (SrcExpr.isInvalid())
   return;
+
+if (isValidCast(tcr))
+  Kind = CK_AddressSpaceConversion;
+
 if (tcr == TC_NotApplicable) {
   // ... or if that is not possible, a static_cast, ignoring const, ...
   tcr = TryStaticCast(Self, SrcExpr, DestType, CCK, OpRange, msg, Kind,
Index: cfe/trunk/test/CodeGenOpenCLCXX/addrspace-conversion.cl
===
--- cfe/trunk/test/CodeGenOpenCLCXX/addrspace-conversion.cl
+++ cfe/trunk/test/CodeGenOpenCLCXX/addrspace-conversion.cl
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 %s -triple spir-unknown-unknown -cl-std=c++ -emit-llvm -O0 -o - | FileCheck %s
+
+void bar(__generic volatile unsigned int* ptr)
+{
+  //CHECK: addrspacecast i32 addrspace(4)* %{{.+}} to i32 addrspace(1)*
+  auto gptr = (__global volatile unsigned int*)ptr;
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D59253: [AIX][libcxx] AIX system headers need stdint.h and inttypes.h to be re-enterable when macro _STD_TYPES_T is defined

2019-06-03 Thread Hubert Tong via Phabricator via cfe-commits
hubert.reinterpretcast accepted this revision.
hubert.reinterpretcast added a comment.

LGTM with minor comment.




Comment at: libcxx/test/std/depr/depr.c.headers/stdint_h.sh.cpp:21
+// Test that limits macros are available when  is included with
+// or without macro _XOPEN_SOUECE=700.
+

Typo:
s/_XOPEN_SOUECE/_XOPEN_SOURCE/;


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D59253



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


r362410 - Re-check in clang support gun asm goto after fixing tests.

2019-06-03 Thread Jennifer Yu via cfe-commits
Author: jyu2
Date: Mon Jun  3 08:57:25 2019
New Revision: 362410

URL: http://llvm.org/viewvc/llvm-project?rev=362410&view=rev
Log:
Re-check in clang support gun asm goto after fixing tests.

Added:
cfe/trunk/test/Analysis/asm-goto.cpp
cfe/trunk/test/CodeGen/asm-goto.c
cfe/trunk/test/Parser/asm-goto.c
cfe/trunk/test/Parser/asm-goto.cpp
cfe/trunk/test/Sema/asm-goto.cpp
Modified:
cfe/trunk/include/clang/AST/Stmt.h
cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/AST/ASTImporter.cpp
cfe/trunk/lib/AST/Stmt.cpp
cfe/trunk/lib/AST/StmtPrinter.cpp
cfe/trunk/lib/AST/StmtProfile.cpp
cfe/trunk/lib/Analysis/CFG.cpp
cfe/trunk/lib/CodeGen/CGStmt.cpp
cfe/trunk/lib/Parse/ParseStmtAsm.cpp
cfe/trunk/lib/Sema/JumpDiagnostics.cpp
cfe/trunk/lib/Sema/SemaStmtAsm.cpp
cfe/trunk/lib/Sema/TreeTransform.h
cfe/trunk/lib/Serialization/ASTReaderStmt.cpp
cfe/trunk/lib/Serialization/ASTWriterStmt.cpp
cfe/trunk/test/CodeGen/asm.c
cfe/trunk/test/CodeGen/inline-asm-mixed-style.c
cfe/trunk/test/Coverage/c-language-features.inc
cfe/trunk/test/PCH/asm.h
cfe/trunk/test/Sema/asm.c
cfe/trunk/test/Sema/inline-asm-validate-tmpl.cpp

Modified: cfe/trunk/include/clang/AST/Stmt.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Stmt.h?rev=362410&r1=362409&r2=362410&view=diff
==
--- cfe/trunk/include/clang/AST/Stmt.h (original)
+++ cfe/trunk/include/clang/AST/Stmt.h Mon Jun  3 08:57:25 2019
@@ -46,6 +46,7 @@ class Attr;
 class CapturedDecl;
 class Decl;
 class Expr;
+class AddrLabelExpr;
 class LabelDecl;
 class ODRHash;
 class PrinterHelper;
@@ -2816,13 +2817,15 @@ class GCCAsmStmt : public AsmStmt {
   StringLiteral **Constraints = nullptr;
   StringLiteral **Clobbers = nullptr;
   IdentifierInfo **Names = nullptr;
+  unsigned NumLabels = 0;
 
 public:
   GCCAsmStmt(const ASTContext &C, SourceLocation asmloc, bool issimple,
  bool isvolatile, unsigned numoutputs, unsigned numinputs,
  IdentifierInfo **names, StringLiteral **constraints, Expr **exprs,
  StringLiteral *asmstr, unsigned numclobbers,
- StringLiteral **clobbers, SourceLocation rparenloc);
+ StringLiteral **clobbers, unsigned numlabels,
+ SourceLocation rparenloc);
 
   /// Build an empty inline-assembly statement.
   explicit GCCAsmStmt(EmptyShell Empty) : AsmStmt(GCCAsmStmtClass, Empty) {}
@@ -2947,6 +2950,51 @@ public:
 return const_cast(this)->getInputExpr(i);
   }
 
+  //===--- Labels ---===//
+
+  bool isAsmGoto() const {
+return NumLabels > 0;
+  }
+
+  unsigned getNumLabels() const {
+return NumLabels;
+  }
+
+  IdentifierInfo *getLabelIdentifier(unsigned i) const {
+return Names[i + NumInputs];
+  }
+
+  AddrLabelExpr *getLabelExpr(unsigned i) const;
+  StringRef getLabelName(unsigned i) const;
+  using labels_iterator = CastIterator;
+  using const_labels_iterator = ConstCastIterator;
+  using labels_range = llvm::iterator_range;
+  using labels_const_range = llvm::iterator_range;
+
+  labels_iterator begin_labels() {
+return &Exprs[0] + NumInputs;
+  }
+
+  labels_iterator end_labels() {
+return &Exprs[0] + NumInputs + NumLabels;
+  }
+
+  labels_range labels() {
+return labels_range(begin_labels(), end_labels());
+  }
+
+  const_labels_iterator begin_labels() const {
+return &Exprs[0] + NumInputs;
+  }
+
+  const_labels_iterator end_labels() const {
+return &Exprs[0] + NumInputs + NumLabels;
+  }
+
+  labels_const_range labels() const {
+return labels_const_range(begin_labels(), end_labels());
+  }
+
 private:
   void setOutputsAndInputsAndClobbers(const ASTContext &C,
   IdentifierInfo **Names,
@@ -2954,6 +3002,7 @@ private:
   Stmt **Exprs,
   unsigned NumOutputs,
   unsigned NumInputs,
+  unsigned NumLabels,
   StringLiteral **Clobbers,
   unsigned NumClobbers);
 

Modified: cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td?rev=362410&r1=362409&r2=362410&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td Mon Jun  3 08:57:25 
2019
@@ -27,8 +27,8 @@ def err_msasm_unable_to_create_target :
   "MS-style inline assembly is not available: %0">;
 def err_gnu_inline_asm_disabled : Error<
   "GNU-style inline assembly is disabled">;
-def err_asm_goto_not_suppo

[PATCH] D59253: [AIX][libcxx] AIX system headers need stdint.h and inttypes.h to be re-enterable when macro _STD_TYPES_T is defined

2019-06-03 Thread Xing Xue via Phabricator via cfe-commits
xingxue marked 2 inline comments as done.
xingxue added inline comments.



Comment at: libcxx/test/std/depr/depr.c.headers/stdint_h.sh.cpp:21
+// Test that limits macros are available when  is included with
+// or without macro _XOPEN_SOUECE=700.
+

hubert.reinterpretcast wrote:
> Typo:
> s/_XOPEN_SOUECE/_XOPEN_SOURCE/;
Good catch!  Fixed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D59253



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


[PATCH] D59253: [AIX][libcxx] AIX system headers need stdint.h and inttypes.h to be re-enterable when macro _STD_TYPES_T is defined

2019-06-03 Thread Xing Xue via Phabricator via cfe-commits
xingxue updated this revision to Diff 202734.
xingxue added a comment.

Addressed comments:

- Fixed typo _XOPEN_SOUECE->_XOPEN_SOURCE


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D59253

Files:
  clang/lib/Headers/inttypes.h
  clang/lib/Headers/stdint.h
  libcxx/include/inttypes.h
  libcxx/include/stdint.h
  libcxx/test/std/depr/depr.c.headers/stdint_h.sh.cpp

Index: libcxx/test/std/depr/depr.c.headers/stdint_h.sh.cpp
===
--- /dev/null
+++ libcxx/test/std/depr/depr.c.headers/stdint_h.sh.cpp
@@ -0,0 +1,268 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+// AIX system headers need stdint.h to be re-enterable when macro _STD_TYPES_T
+// is defined. This test case tests that after including sys/types.h which
+// defines macro _STD_TYPES_T, includes stdint.h, and then undefines
+// _STD_TYPES_T, stdint.h can be entered to get to macros like UINT32_MAX.
+//
+// REQUIRES: aix
+// RUN: %compile -c
+// RUN: %compile -c -D_XOPEN_SOURCE=700
+
+// test 
+//
+// Test that limits macros are available when  is included with
+// or without macro _XOPEN_SOURCE=700.
+
+#include 
+#include 
+
+#ifndef INT8_MIN
+#error INT8_MIN not defined
+#endif
+
+#ifndef INT16_MIN
+#error INT16_MIN not defined
+#endif
+
+#ifndef INT32_MIN
+#error INT32_MIN not defined
+#endif
+
+#ifndef INT64_MIN
+#error INT64_MIN not defined
+#endif
+
+#ifndef INT8_MAX
+#error INT8_MAX not defined
+#endif
+
+#ifndef INT16_MAX
+#error INT16_MAX not defined
+#endif
+
+#ifndef INT32_MAX
+#error INT32_MAX not defined
+#endif
+
+#ifndef INT64_MAX
+#error INT64_MAX not defined
+#endif
+
+#ifndef UINT8_MAX
+#error UINT8_MAX not defined
+#endif
+
+#ifndef UINT16_MAX
+#error UINT16_MAX not defined
+#endif
+
+#ifndef UINT32_MAX
+#error UINT32_MAX not defined
+#endif
+
+#ifndef UINT64_MAX
+#error UINT64_MAX not defined
+#endif
+
+#ifndef INT_LEAST8_MIN
+#error INT_LEAST8_MIN not defined
+#endif
+
+#ifndef INT_LEAST16_MIN
+#error INT_LEAST16_MIN not defined
+#endif
+
+#ifndef INT_LEAST32_MIN
+#error INT_LEAST32_MIN not defined
+#endif
+
+#ifndef INT_LEAST64_MIN
+#error INT_LEAST64_MIN not defined
+#endif
+
+#ifndef INT_LEAST8_MAX
+#error INT_LEAST8_MAX not defined
+#endif
+
+#ifndef INT_LEAST16_MAX
+#error INT_LEAST16_MAX not defined
+#endif
+
+#ifndef INT_LEAST32_MAX
+#error INT_LEAST32_MAX not defined
+#endif
+
+#ifndef INT_LEAST64_MAX
+#error INT_LEAST64_MAX not defined
+#endif
+
+#ifndef UINT_LEAST8_MAX
+#error UINT_LEAST8_MAX not defined
+#endif
+
+#ifndef UINT_LEAST16_MAX
+#error UINT_LEAST16_MAX not defined
+#endif
+
+#ifndef UINT_LEAST32_MAX
+#error UINT_LEAST32_MAX not defined
+#endif
+
+#ifndef UINT_LEAST64_MAX
+#error UINT_LEAST64_MAX not defined
+#endif
+
+#ifndef INT_FAST8_MIN
+#error INT_FAST8_MIN not defined
+#endif
+
+#ifndef INT_FAST16_MIN
+#error INT_FAST16_MIN not defined
+#endif
+
+#ifndef INT_FAST32_MIN
+#error INT_FAST32_MIN not defined
+#endif
+
+#ifndef INT_FAST64_MIN
+#error INT_FAST64_MIN not defined
+#endif
+
+#ifndef INT_FAST8_MAX
+#error INT_FAST8_MAX not defined
+#endif
+
+#ifndef INT_FAST16_MAX
+#error INT_FAST16_MAX not defined
+#endif
+
+#ifndef INT_FAST32_MAX
+#error INT_FAST32_MAX not defined
+#endif
+
+#ifndef INT_FAST64_MAX
+#error INT_FAST64_MAX not defined
+#endif
+
+#ifndef UINT_FAST8_MAX
+#error UINT_FAST8_MAX not defined
+#endif
+
+#ifndef UINT_FAST16_MAX
+#error UINT_FAST16_MAX not defined
+#endif
+
+#ifndef UINT_FAST32_MAX
+#error UINT_FAST32_MAX not defined
+#endif
+
+#ifndef UINT_FAST64_MAX
+#error UINT_FAST64_MAX not defined
+#endif
+
+#ifndef INTPTR_MIN
+#error INTPTR_MIN not defined
+#endif
+
+#ifndef INTPTR_MAX
+#error INTPTR_MAX not defined
+#endif
+
+#ifndef UINTPTR_MAX
+#error UINTPTR_MAX not defined
+#endif
+
+#ifndef INTMAX_MIN
+#error INTMAX_MIN not defined
+#endif
+
+#ifndef INTMAX_MAX
+#error INTMAX_MAX not defined
+#endif
+
+#ifndef UINTMAX_MAX
+#error UINTMAX_MAX not defined
+#endif
+
+#ifndef PTRDIFF_MIN
+#error PTRDIFF_MIN not defined
+#endif
+
+#ifndef PTRDIFF_MAX
+#error PTRDIFF_MAX not defined
+#endif
+
+#ifndef SIG_ATOMIC_MIN
+#error SIG_ATOMIC_MIN not defined
+#endif
+
+#ifndef SIG_ATOMIC_MAX
+#error SIG_ATOMIC_MAX not defined
+#endif
+
+#ifndef SIZE_MAX
+#error SIZE_MAX not defined
+#endif
+
+#ifndef WCHAR_MIN
+#error WCHAR_MIN not defined
+#endif
+
+#ifndef WCHAR_MAX
+#error WCHAR_MAX not defined
+#endif
+
+#ifndef WINT_MIN
+#error WINT_MIN not defined
+#endif
+
+#ifndef WINT_MAX
+#error WINT_MAX not defined
+#endif
+
+#ifndef INT8_C
+#error INT8_C not defined
+#endif
+
+#ifndef INT16_C
+#error INT16_C not defined
+#endif

[PATCH] D62814: [clangd] Treat lambdas as functions when preparing hover response

2019-06-03 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet created this revision.
kadircet added reviewers: sammccall, ilya-biryukov.
Herald added subscribers: cfe-commits, arphaman, jkorous, MaskRay.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D62814

Files:
  clang-tools-extra/clangd/XRefs.cpp
  clang-tools-extra/clangd/unittests/XRefsTests.cpp

Index: clang-tools-extra/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -22,6 +22,7 @@
 #include "llvm/Support/ScopedPrinter.h"
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
+#include 
 
 namespace clang {
 namespace clangd {
@@ -765,6 +766,27 @@
  {std::string("bool"), std::string("T"), std::string("false")},
  };
}},
+  // Lambda parameter with decltype
+  {R"cpp(
+auto lamb = [](int T, bool B) -> bool { return T && B; };
+void foo(decltype(lamb) bar) {
+  [[ba^r]](0, false);
+}
+)cpp",
+   [](HoverInfo &HI) {
+ HI.NamespaceScope = "";
+ HI.LocalScope = "foo::";
+ HI.Name = "bar";
+ HI.Kind = SymbolKind::Variable;
+ HI.Definition = "decltype(lamb) bar";
+ HI.Type = "bool(int, bool)";
+ HI.ReturnType = "bool";
+ HI.Parameters = {
+ {std::string("int"), std::string("T"), llvm::None},
+ {std::string("bool"), std::string("B"), llvm::None},
+ };
+ return HI;
+   }},
   // Lambda variable
   {R"cpp(
 void foo() {
@@ -779,7 +801,12 @@
  HI.Name = "lamb";
  HI.Kind = SymbolKind::Variable;
  HI.Definition = "auto lamb = [&bar](int T, bool B) -> bool {}";
- HI.Type = std::string("class (lambda)");
+ HI.Type = "bool(int, bool)";
+ HI.ReturnType = "bool";
+ HI.Parameters = {
+ {std::string("int"), std::string("T"), llvm::None},
+ {std::string("bool"), std::string("B"), llvm::None},
+ };
  return HI;
}},
   // Local variable in lambda
Index: clang-tools-extra/clangd/XRefs.cpp
===
--- clang-tools-extra/clangd/XRefs.cpp
+++ clang-tools-extra/clangd/XRefs.cpp
@@ -18,7 +18,9 @@
 #include "index/SymbolLocation.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/Decl.h"
+#include "clang/AST/DeclCXX.h"
 #include "clang/AST/DeclTemplate.h"
+#include "clang/AST/ExprCXX.h"
 #include "clang/AST/PrettyPrinter.h"
 #include "clang/AST/RecursiveASTVisitor.h"
 #include "clang/AST/Type.h"
@@ -652,8 +654,32 @@
 }
   }
 
+  auto ToFunctionDecl = [](const Decl *D) -> const FunctionDecl * {
+// Extract lambda from variables.
+if (const VarDecl *VD = llvm::dyn_cast(D)) {
+  // It might be declared by a decltype.
+  if (const DecltypeType *DT =
+  llvm::dyn_cast(VD->getType().getTypePtr()))
+if (!DT->getUnderlyingType().isNull())
+  if (const auto *CD = DT->getUnderlyingType()->getAsCXXRecordDecl())
+return CD->getLambdaCallOperator();
+
+  // Or with an initializer.
+  if (const Expr *E = VD->getInit())
+if (const LambdaExpr *LE = llvm::dyn_cast(E))
+  return LE->getCallOperator();
+}
+
+// Handle classes with call operators.
+if (const CXXRecordDecl *CRD = llvm::dyn_cast(D))
+  return CRD->getLambdaCallOperator();
+
+// Non-lambda functions.
+return D->getAsFunction();
+  };
+
   // Fill in types and params.
-  if (const FunctionDecl *FD = D->getAsFunction()) {
+  if (const FunctionDecl *FD = ToFunctionDecl(D)) {
 HI.ReturnType.emplace();
 llvm::raw_string_ostream OS(*HI.ReturnType);
 FD->getReturnType().print(OS, Policy);
@@ -692,8 +718,6 @@
 TypeOS << ')';
 // FIXME: handle variadics.
   } else if (const auto *VD = dyn_cast(D)) {
-// FIXME: Currently lambdas are also handled as ValueDecls, they should be
-// more similar to functions.
 HI.Type.emplace();
 llvm::raw_string_ostream OS(*HI.Type);
 VD->getType().print(OS, Policy);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D62814: [clangd] Treat lambdas as functions when preparing hover response

2019-06-03 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet updated this revision to Diff 202739.
kadircet added a comment.

- Get rid of wrong check


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62814

Files:
  clang-tools-extra/clangd/XRefs.cpp
  clang-tools-extra/clangd/unittests/XRefsTests.cpp

Index: clang-tools-extra/clangd/unittests/XRefsTests.cpp
===
--- clang-tools-extra/clangd/unittests/XRefsTests.cpp
+++ clang-tools-extra/clangd/unittests/XRefsTests.cpp
@@ -22,6 +22,7 @@
 #include "llvm/Support/ScopedPrinter.h"
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
+#include 
 
 namespace clang {
 namespace clangd {
@@ -765,6 +766,27 @@
  {std::string("bool"), std::string("T"), std::string("false")},
  };
}},
+  // Lambda parameter with decltype
+  {R"cpp(
+auto lamb = [](int T, bool B) -> bool { return T && B; };
+void foo(decltype(lamb) bar) {
+  [[ba^r]](0, false);
+}
+)cpp",
+   [](HoverInfo &HI) {
+ HI.NamespaceScope = "";
+ HI.LocalScope = "foo::";
+ HI.Name = "bar";
+ HI.Kind = SymbolKind::Variable;
+ HI.Definition = "decltype(lamb) bar";
+ HI.Type = "bool(int, bool)";
+ HI.ReturnType = "bool";
+ HI.Parameters = {
+ {std::string("int"), std::string("T"), llvm::None},
+ {std::string("bool"), std::string("B"), llvm::None},
+ };
+ return HI;
+   }},
   // Lambda variable
   {R"cpp(
 void foo() {
@@ -779,7 +801,12 @@
  HI.Name = "lamb";
  HI.Kind = SymbolKind::Variable;
  HI.Definition = "auto lamb = [&bar](int T, bool B) -> bool {}";
- HI.Type = std::string("class (lambda)");
+ HI.Type = "bool(int, bool)";
+ HI.ReturnType = "bool";
+ HI.Parameters = {
+ {std::string("int"), std::string("T"), llvm::None},
+ {std::string("bool"), std::string("B"), llvm::None},
+ };
  return HI;
}},
   // Local variable in lambda
Index: clang-tools-extra/clangd/XRefs.cpp
===
--- clang-tools-extra/clangd/XRefs.cpp
+++ clang-tools-extra/clangd/XRefs.cpp
@@ -18,7 +18,9 @@
 #include "index/SymbolLocation.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/Decl.h"
+#include "clang/AST/DeclCXX.h"
 #include "clang/AST/DeclTemplate.h"
+#include "clang/AST/ExprCXX.h"
 #include "clang/AST/PrettyPrinter.h"
 #include "clang/AST/RecursiveASTVisitor.h"
 #include "clang/AST/Type.h"
@@ -652,8 +654,28 @@
 }
   }
 
+  auto ToFunctionDecl = [](const Decl *D) -> const FunctionDecl * {
+// Extract lambda from variables.
+if (const VarDecl *VD = llvm::dyn_cast(D)) {
+  // It might be declared by a decltype.
+  if (const DecltypeType *DT =
+  llvm::dyn_cast(VD->getType().getTypePtr()))
+if (!DT->getUnderlyingType().isNull())
+  if (const auto *CD = DT->getUnderlyingType()->getAsCXXRecordDecl())
+return CD->getLambdaCallOperator();
+
+  // Or with an initializer.
+  if (const Expr *E = VD->getInit())
+if (const LambdaExpr *LE = llvm::dyn_cast(E))
+  return LE->getCallOperator();
+}
+
+// Non-lambda functions.
+return D->getAsFunction();
+  };
+
   // Fill in types and params.
-  if (const FunctionDecl *FD = D->getAsFunction()) {
+  if (const FunctionDecl *FD = ToFunctionDecl(D)) {
 HI.ReturnType.emplace();
 llvm::raw_string_ostream OS(*HI.ReturnType);
 FD->getReturnType().print(OS, Policy);
@@ -692,8 +714,6 @@
 TypeOS << ')';
 // FIXME: handle variadics.
   } else if (const auto *VD = dyn_cast(D)) {
-// FIXME: Currently lambdas are also handled as ValueDecls, they should be
-// more similar to functions.
 HI.Type.emplace();
 llvm::raw_string_ostream OS(*HI.Type);
 VD->getType().print(OS, Policy);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D61637: [Syntax] Introduce syntax trees

2019-06-03 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov updated this revision to Diff 202745.
ilya-biryukov marked 24 inline comments as done.
ilya-biryukov added a comment.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.



- Address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61637

Files:
  clang/include/clang/Tooling/Syntax/BuildTree.h
  clang/include/clang/Tooling/Syntax/Nodes.h
  clang/include/clang/Tooling/Syntax/Tree.h
  clang/lib/Tooling/Syntax/BuildTree.cpp
  clang/lib/Tooling/Syntax/CMakeLists.txt
  clang/lib/Tooling/Syntax/Nodes.cpp
  clang/lib/Tooling/Syntax/Tree.cpp
  clang/unittests/Tooling/Syntax/CMakeLists.txt
  clang/unittests/Tooling/Syntax/TreeTest.cpp
  llvm/utils/gn/secondary/clang/lib/Tooling/Syntax/BUILD.gn

Index: llvm/utils/gn/secondary/clang/lib/Tooling/Syntax/BUILD.gn
===
--- llvm/utils/gn/secondary/clang/lib/Tooling/Syntax/BUILD.gn
+++ llvm/utils/gn/secondary/clang/lib/Tooling/Syntax/BUILD.gn
@@ -8,6 +8,10 @@
 "//llvm/lib/Support",
   ]
   sources = [
+"Arena.cpp",
+"BuildFromAST.cpp",
+"Cascade.cpp",
+"Nodes.cpp",
 "Tokens.cpp",
   ]
 }
Index: clang/unittests/Tooling/Syntax/TreeTest.cpp
===
--- /dev/null
+++ clang/unittests/Tooling/Syntax/TreeTest.cpp
@@ -0,0 +1,154 @@
+//===- TreeTest.cpp ---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "clang/Tooling/Syntax/Tree.h"
+#include "clang/AST/ASTConsumer.h"
+#include "clang/AST/Decl.h"
+#include "clang/Frontend/CompilerInstance.h"
+#include "clang/Frontend/FrontendAction.h"
+#include "clang/Lex/PreprocessorOptions.h"
+#include "clang/Tooling/Syntax/BuildTree.h"
+#include "clang/Tooling/Syntax/Nodes.h"
+#include "clang/Tooling/Tooling.h"
+#include "llvm/ADT/STLExtras.h"
+#include "llvm/ADT/StringRef.h"
+#include "gmock/gmock.h"
+#include "gtest/gtest.h"
+#include 
+
+using namespace clang;
+
+namespace {
+class SyntaxTreeTest : public ::testing::Test {
+protected:
+  // Build a syntax tree for the code.
+  syntax::TranslationUnit *buildTree(llvm::StringRef Code) {
+// FIXME: this code is almost the identical to the one in TokensTest. Share
+//it.
+class BuildSyntaxTree : public ASTConsumer {
+public:
+  BuildSyntaxTree(syntax::TranslationUnit *&Root,
+  std::unique_ptr &Arena,
+  std::unique_ptr Tokens)
+  : Root(Root), Arena(Arena), Tokens(std::move(Tokens)) {
+assert(this->Tokens);
+  }
+
+  void HandleTranslationUnit(ASTContext &Ctx) override {
+Arena = llvm::make_unique(Ctx.getSourceManager(),
+ Ctx.getLangOpts(),
+ std::move(*Tokens).consume());
+Tokens = nullptr; // make sure we fail if this gets called twice.
+Root = syntax::buildSyntaxTree(*Arena, *Ctx.getTranslationUnitDecl());
+  }
+
+private:
+  syntax::TranslationUnit *&Root;
+  std::unique_ptr &Arena;
+  std::unique_ptr Tokens;
+};
+
+class BuildSyntaxTreeAction : public ASTFrontendAction {
+public:
+  BuildSyntaxTreeAction(syntax::TranslationUnit *&Root,
+std::unique_ptr &Arena)
+  : Root(Root), Arena(Arena) {}
+
+  std::unique_ptr
+  CreateASTConsumer(CompilerInstance &CI, StringRef InFile) override {
+// We start recording the tokens, ast consumer will take on the result.
+auto Tokens =
+llvm::make_unique(CI.getPreprocessor());
+return llvm::make_unique(Root, Arena,
+  std::move(Tokens));
+  }
+
+private:
+  syntax::TranslationUnit *&Root;
+  std::unique_ptr &Arena;
+};
+
+constexpr const char *FileName = "./input.cpp";
+FS->addFile(FileName, time_t(), llvm::MemoryBuffer::getMemBufferCopy(""));
+// Prepare to run a compiler.
+std::vector Args = {"tok-test", "-std=c++03", "-fsyntax-only",
+  FileName};
+auto CI = createInvocationFromCommandLine(Args, Diags, FS);
+assert(CI);
+CI->getFrontendOpts().DisableFree = false;
+CI->getPreprocessorOpts().addRemappedFile(
+FileName, llvm::MemoryBuffer::getMemBufferCopy(Code).release());
+CompilerInstance Compiler;
+Compiler.setInvocation(std::move(CI));
+if (!Diags->getClient())
+  Diags->setClient(new IgnoringDiagConsumer);
+Compiler.setDiagnostics(Diags.get());
+Compiler.setFileManager(FileMgr.get());

[PATCH] D61637: [Syntax] Introduce syntax trees

2019-06-03 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov added a comment.

I've addressed most of the comments, except the naming ones.
We need a convention for naming the language nodes and names for composite and 
leaf structural nodes.

For "language" nodes, I suggest we use  `CompoundStatement`, `Recovery`, 
`TopLevelDeclaration`, `TemplateArgumentList`, `TypeTemplateArgument`, etc. 
That is, we spell out the words in full, no shorthands like `Stmt` or `Expr`. 
That would make things a bit more verbose, but hopefully that helps distinguish 
from clang AST.

For structural nodes, see the relevant comment threads.




Comment at: clang/include/clang/Tooling/Syntax/Arena.h:1
+//===- Arena.h - memory arena and bookkeeping for syntax trees --- C++ -*-===//
+//

sammccall wrote:
> From a user's point of view, this looks a lot like part of the tree structure 
> in some sense.
> 
> If you expect that users will need to keep the arena rather than the 
> TokenBuffer around (e.g. so nodes can be allocated), then it might make sense 
> to declare it at the bottom of `Cascade.h`
Now part of `Tree.h`



Comment at: clang/include/clang/Tooling/Syntax/Corpus.h:38
+  std::pair>
+  tokenizeBuffer(std::unique_ptr Buffer);
+

ilya-biryukov wrote:
> sammccall wrote:
> > ilya-biryukov wrote:
> > > sammccall wrote:
> > > > Are you planning to have a way to add tokens directly? Having to turn 
> > > > them into text and re-lex them seems like it might be inconvenient.
> > > The tokens have source locations and refer to a text in some buffer. 
> > > `tokenizeBuffer` makes is easier, not harder, to mock tokens.
> > Fair enough.
> > 
> > `lexBuffer` might be a slightly clearer name?
> > 
> > Who are the intended non-test users of this function? Are they better 
> > served by being able (and responsible) for constructing a MemoryBuffer with 
> > e.g. a sensible name and ownership, or would it be better to pass a 
> > StringRef and have the Arena come up with a sensible "anonymous" name?
> The only use-case in my prototype so far is creating token nodes for 
> punctuation nodes, e.g. say you want to create an expr of the form `+`, 
> where both `a` and `b` are existing expressions and you need to synthesize a 
> leaf node for `+`.
> We use this function to synthesize a buffer with the corresponding token.
> 
> All the use-cases I can imagine are around synthesizing syntax trees (as 
> opposed to constructing them from the AST).
Renamed to `lexBuffer`. This does not have usages (yet), we can also remove it 
from this patch if needed.



Comment at: clang/include/clang/Tooling/Syntax/Corpus.h:40
+
+  /// Construct a new syntax node of a specified kind. The memory for a node is
+  /// owned by the corpus and will be freed when the corpus is destroyed.

sammccall wrote:
> ilya-biryukov wrote:
> > sammccall wrote:
> > > Now there's two ways to do this: `new (C.allocator()) T(...)` or 
> > > `C.construct(...)`. Do we need both?
> > > 
> > > (If we do, is the syntax `new (C) T(...)` more natural?)
> > I think `C.construct()` read better than `new (C) T(...)`. Not a big fan 
> > of placement new exprs.
> They are fairly consistently used in llvm/clang for this sort of thing, 
> though.
> 
> I find it valuable because arena allocations look otherwise a lot like buggy 
> ownership patterns. The dedicated syntax calls out the unusual case: we're 
> creating a new thing, and someone else owns it, but won't do anything with it.
Removed in favour of placement new. I guess that also makes it a bit more 
natural to have separate storage for other nodes that have different lifetime 
(e.g. use a separate arena).



Comment at: clang/include/clang/Tooling/Syntax/Tree.h:11
+//
+// The code is divided in the following way:
+//   - 'Tree/Cascade.h' defines the basic structure of the syntax tree,

sammccall wrote:
> As discussed offline:
>  - I don't think (at this point) we need an umbrella header. Generic tree 
> structure, specific node semantics, and operations like "build a tree" are 
> distinct enough from a user POV that asking them to include headers is fine. 
>  - We may want an umbrella for the node types, if we end up splitting that, 
> but no need yet.
>  - Splitting generic tree stuff vs specific node stuff sounds good, but I 
> think having them be sibling headers in `Tooling/Syntax` is enough - not sure 
> about the `Tree/` subdirectory.
> 
> So I'd suggest something like:
>  - `Tree/Cascade.h` + `Arena.h` --> `Tree.h`
>  - `Tree.h` -> `BuildTree.h`
>  - `Tree/Nodes.h` + `NodeKind.h` --> `Nodes.h`
> (have comments on some of these throughout)
Changed to the proposed header structure, it looks good.
Had to move `Leaf::classof` and `TreeNode::classof` into a `.cpp`, they need a 
definition of `NodeKind`. Keeping those in a header file was a 
micro-optimization anyway, that's probably not too important.



Comment at: clang/include/clang/Tool

[PATCH] D61637: [Syntax] Introduce syntax trees

2019-06-03 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov added inline comments.



Comment at: clang/include/clang/Tooling/Syntax/BuildTree.h:11
+//
+// The code is divided in the following way:
+//   - 'Tree/Cascade.h' defines the basic structure of the syntax tree,

This needs an update, will do in the next round!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61637



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


[PATCH] D62814: [clangd] Treat lambdas as functions when preparing hover response

2019-06-03 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov added a comment.

Do we care about pointers or references to lambda types?




Comment at: clang-tools-extra/clangd/XRefs.cpp:662
+  if (const DecltypeType *DT =
+  llvm::dyn_cast(VD->getType().getTypePtr()))
+if (!DT->getUnderlyingType().isNull())

Variable types can be null (for C++17 deconstruction syntax), use 
`getTypePtrOrNull`.



Comment at: clang-tools-extra/clangd/XRefs.cpp:664
+if (!DT->getUnderlyingType().isNull())
+  if (const auto *CD = DT->getUnderlyingType()->getAsCXXRecordDecl())
+return CD->getLambdaCallOperator();

NIT: add extra braces to the inner `if` for more readable code



Comment at: clang-tools-extra/clangd/XRefs.cpp:669
+  if (const Expr *E = VD->getInit())
+if (const LambdaExpr *LE = llvm::dyn_cast(E))
+  return LE->getCallOperator();

NIT: add extra braces to the inner `if` for more readable code


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62814



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


[PATCH] D62584: [OpenCL][PR42033] Deducing addr space with template parameter types

2019-06-03 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia updated this revision to Diff 202753.
Anastasia retitled this revision from "[OpenCL][PR42033] Deducing addr space of 
pointer/reference with template parameter types" to "[OpenCL][PR42033] Deducing 
addr space with template parameter types".
Anastasia edited the summary of this revision.
Anastasia added a comment.

- Added more test cases
- Improved diagnostics to account for use of templates with addr spaces


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

https://reviews.llvm.org/D62584

Files:
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaType.cpp
  lib/Sema/TreeTransform.h
  test/SemaOpenCLCXX/address-space-deduction.cl


Index: test/SemaOpenCLCXX/address-space-deduction.cl
===
--- test/SemaOpenCLCXX/address-space-deduction.cl
+++ test/SemaOpenCLCXX/address-space-deduction.cl
@@ -10,3 +10,18 @@
   //CHECK: `-VarDecl {{.*}} foo2 'const __global int' static constexpr cinit
   static constexpr int foo2 = 0;
 };
+
+template 
+T xxx(T *in) {
+  // This pointer can't be deduced to generic because addr space
+  // will be taken from the template argument.
+  //CHECK: `-VarDecl {{.*}} i 'T *' cinit
+  T *i = in;
+  T ii;
+  return *i;
+}
+
+__kernel void test() {
+  int foo[10];
+  xxx(&foo[0]);
+}
Index: lib/Sema/TreeTransform.h
===
--- lib/Sema/TreeTransform.h
+++ lib/Sema/TreeTransform.h
@@ -5355,8 +5355,12 @@
 if (ResultType.isNull())
   return QualType();
 
-// Return type can not be qualified with an address space.
-if (ResultType.getAddressSpace() != LangAS::Default) {
+// Return type can not be qualified with an address space apart from when 
it
+// comes from a template argument in which case we can accept OpenCL 
private
+// address space because similar to Default it is used for an automatic
+// storage.
+if (ResultType.getAddressSpace() != LangAS::Default &&
+(ResultType.getAddressSpace() != LangAS::opencl_private)) {
   SemaRef.Diag(TL.getReturnLoc().getBeginLoc(),
diag::err_attribute_address_function_type);
   return QualType();
Index: lib/Sema/SemaType.cpp
===
--- lib/Sema/SemaType.cpp
+++ lib/Sema/SemaType.cpp
@@ -7360,7 +7360,9 @@
   (T->isVoidType() && !IsPointee) ||
   // Do not deduce addr spaces for dependent types because they might end
   // up instantiating to a type with an explicit address space qualifier.
-  T->isDependentType() ||
+  // Expect for pointer or reference types because the addr space in
+  // template argument can only belong to a pointee.
+  (T->isDependentType() && !T->isPointerType() && !T->isReferenceType()) ||
   // Do not deduce addr space of decltype because it will be taken from
   // its argument.
   T->isDecltypeType() ||
Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -7476,7 +7476,10 @@
 return;
   }
 }
-  } else if (T.getAddressSpace() != LangAS::opencl_private) {
+  } else if (T.getAddressSpace() != LangAS::opencl_private &&
+ // If we are parsing a template we didn't deduce an addr
+ // space yet.
+ T.getAddressSpace() != LangAS::Default) {
 // Do not allow other address spaces on automatic variable.
 Diag(NewVD->getLocation(), diag::err_as_qualified_auto_decl) << 1;
 NewVD->setInvalidDecl();


Index: test/SemaOpenCLCXX/address-space-deduction.cl
===
--- test/SemaOpenCLCXX/address-space-deduction.cl
+++ test/SemaOpenCLCXX/address-space-deduction.cl
@@ -10,3 +10,18 @@
   //CHECK: `-VarDecl {{.*}} foo2 'const __global int' static constexpr cinit
   static constexpr int foo2 = 0;
 };
+
+template 
+T xxx(T *in) {
+  // This pointer can't be deduced to generic because addr space
+  // will be taken from the template argument.
+  //CHECK: `-VarDecl {{.*}} i 'T *' cinit
+  T *i = in;
+  T ii;
+  return *i;
+}
+
+__kernel void test() {
+  int foo[10];
+  xxx(&foo[0]);
+}
Index: lib/Sema/TreeTransform.h
===
--- lib/Sema/TreeTransform.h
+++ lib/Sema/TreeTransform.h
@@ -5355,8 +5355,12 @@
 if (ResultType.isNull())
   return QualType();
 
-// Return type can not be qualified with an address space.
-if (ResultType.getAddressSpace() != LangAS::Default) {
+// Return type can not be qualified with an address space apart from when it
+// comes from a template argument in which case we can accept OpenCL private
+// address space because similar to Default it is used for an automatic
+// storage.
+if (ResultType.getAddressSpace() != LangAS::Default &&
+(ResultType.getAddressSp

[PATCH] D62584: [OpenCL][PR42033] Deducing addr space with template parameter types

2019-06-03 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added a comment.

In D62584#1522438 , @rjmccall wrote:

> I think the right approach here is probably to make sure you're applying 
> deduction during instantiation as well.


I agree I think we might need to extend the template instantiation logic to 
account for some corner cases. However, all local variables in OpenCL are to be 
deduced to `__private`, therefore would it be better to deduce them already as 
we parse the template definition instead of doing it multiple times on each 
instantiation? It doesn't seem the template argument should affect this rule...


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

https://reviews.llvm.org/D62584



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


[PATCH] D62584: [OpenCL][PR42033] Deducing addr space with template parameter types

2019-06-03 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia marked an inline comment as done.
Anastasia added inline comments.



Comment at: lib/Sema/TreeTransform.h:5363
+if (ResultType.getAddressSpace() != LangAS::Default &&
+(ResultType.getAddressSpace() != LangAS::opencl_private)) {
   SemaRef.Diag(TL.getReturnLoc().getBeginLoc(),

I am trying to be a bit more helpful here although I am not sure if we should 
instead require explicit template parameter and fail the template deduction 
instead.

Basically, do we want the following code to always require specifying template 
argument explicitly:


```
template 
T xxx(T *in) {
  T *i = in;
  return *i;
}

__kernel void test() {
  int foo[10];
  xxx(&foo[0]); // if we deduce type from foo, it ends up being qualified 
by __private that we currently diagnose. However private is default (implicit) 
address space for return type so technically there is no danger in just 
allowing xxx(&foo[0])
}
```


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

https://reviews.llvm.org/D62584



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


[PATCH] D62440: [analyzer] NFC: Change evalCall() to provide a CallEvent.

2019-06-03 Thread Kristóf Umann via Phabricator via cfe-commits
Szelethus accepted this revision.
Szelethus added a comment.

LGTM!


Repository:
  rC Clang

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

https://reviews.llvm.org/D62440



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


Re: r356569 - [NFC][clang][astdump] Some baseline tests for OpenMP

2019-06-03 Thread Richard Smith via cfe-commits
On Fri, 31 May 2019 at 16:20, Roman Lebedev via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Sat, Jun 1, 2019 at 2:00 AM Richard Smith 
> wrote:
> >
> > These are change detector tests (
> https://testing.googleblog.com/2015/01/testing-on-toilet-change-detector-tests.html)
> and create a significant maintenance burden that exceeds their value.
> >
> > Please either reduce these to tests that actually test specific salient
> properties (rather than just being assertions that the AST does not change)
> or remove them.
> Yep, lack of tooling indeed always makes things rather frustrating.
> I have recently highlighted that in yet another AST thread:
> https://lists.llvm.org/pipermail/cfe-dev/2019-April/061997.html
>
> I personally added those tests to highlight the openmp_structured_block
> changes, but there is also unit-test coverage for that.
>
> If maintaining test coverage turns out to be too problematic,
> feel free to degrade the test coverage as you see fit,
> but i stand by my opinion that it is a preexisting tooling issue.
> (same with clang codegen tests, diags, etc etc)
>

I disagree that this is a tooling issue. (I've added a script
utils/make-ast-dump-check.sh to improve the maintainability issue for these
tests for now, but they're still bad tests and should be fixed or removed.)

One major purpose of having tests is to allow us to change the code with
confidence: if all tests pass, then the code change is probably correct,
and if any test fails, the code change is probably wrong. For that to hold,
the goal of a test should be to never fail when given a correct change, and
to fail on some kinds of incorrect changes. (And then the coverage
criterion is that at least one test fails for any incorrect change: clearly
that's impossible as a goal, but it's an aspirational target.) With that in
mind, change-detector tests like this are simply bad tests: they fail if
the code is *changed*, regardless of whether the change is correct or not.

Note in particular that I'm pretty sure that no-one has validated that the
test expectations in these tests are actually correct, only that they
happen to match what Clang did at the point in time when they were created.
I've found bugs in our OpenMP AST representation, and these tests are
checking to make sure those bugs don't get fixed.

Also, now that we have a "regenerate the test expectations" script (which
is really the only way to keep this kind of test manageable), we have
another kind of problem: someone making an AST change that affects these
changes will be inundated with pages and pages of test failures from these
tests, and will likely use the script to make them go away after only
validating the first few. If there are also bugs being found by these
tests, those bugs will be hidden by the spam or generally ignored by people
frustrated by these bad tests.


> Roman.
>
> > On Wed, 20 Mar 2019 at 11:16, Roman Lebedev via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
> >>
> >> Author: lebedevri
> >> Date: Wed Mar 20 09:31:47 2019
> >> New Revision: 356569
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=356569&view=rev
> >> Log:
> >> [NFC][clang][astdump] Some baseline tests for OpenMP
> >>
> >> Summary:
> >> Split off from D59214.
> >> Not a fully exhaustive test coverage, but better than what there
> currently is.
> >>
> >> Differential Revision: https://reviews.llvm.org/D59306
> >>
> >> Added:
> >> cfe/trunk/test/AST/ast-dump-openmp-atomic.c
> >> cfe/trunk/test/AST/ast-dump-openmp-barrier.c
> >> cfe/trunk/test/AST/ast-dump-openmp-cancel.c
> >> cfe/trunk/test/AST/ast-dump-openmp-cancellation-point.c
> >> cfe/trunk/test/AST/ast-dump-openmp-critical.c
> >> cfe/trunk/test/AST/ast-dump-openmp-distribute-parallel-for-simd.c
> >> cfe/trunk/test/AST/ast-dump-openmp-distribute-parallel-for.c
> >> cfe/trunk/test/AST/ast-dump-openmp-distribute-simd.c
> >> cfe/trunk/test/AST/ast-dump-openmp-distribute.c
> >> cfe/trunk/test/AST/ast-dump-openmp-flush.c
> >> cfe/trunk/test/AST/ast-dump-openmp-for-simd.c
> >> cfe/trunk/test/AST/ast-dump-openmp-for.c
> >> cfe/trunk/test/AST/ast-dump-openmp-master.c
> >> cfe/trunk/test/AST/ast-dump-openmp-ordered.c
> >> cfe/trunk/test/AST/ast-dump-openmp-parallel-for-simd.c
> >> cfe/trunk/test/AST/ast-dump-openmp-parallel-for.c
> >> cfe/trunk/test/AST/ast-dump-openmp-parallel-master-XFAIL.c
> >> cfe/trunk/test/AST/ast-dump-openmp-parallel-sections.c
> >> cfe/trunk/test/AST/ast-dump-openmp-parallel.c
> >> cfe/trunk/test/AST/ast-dump-openmp-section.c
> >> cfe/trunk/test/AST/ast-dump-openmp-sections.c
> >> cfe/trunk/test/AST/ast-dump-openmp-simd.c
> >> cfe/trunk/test/AST/ast-dump-openmp-single.c
> >> cfe/trunk/test/AST/ast-dump-openmp-target-data.c
> >> cfe/trunk/test/AST/ast-dump-openmp-target-enter-data.c
> >> cfe/trunk/test/AST/ast-dump-openmp-target-exit-data.c
> >> cfe/trunk/test/AST/ast-dump-openmp-target-pa

[PATCH] D62730: [RFC] Alternate implementation of D53157 IRBuilder for Constrained FP using enumeration vs MDNode and add support for fp-model and fp-speculation language options

2019-06-03 Thread Melanie Blower via Phabricator via cfe-commits
mibintc abandoned this revision.
mibintc added a comment.

I'm abandoning this patch in deference to @kpn 's patch under review D53157 



Repository:
  rL LLVM

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

https://reviews.llvm.org/D62730



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


[PATCH] D60763: Prototype OpenCL BIFs using Tablegen

2019-06-03 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

From what I can tell, the only client of OpenCLBuiltins.td is currently 
lib/Sema. Do you expect that to change? If not, does it make more sense to move 
the .td file to there?

Do you expect OpenCLBuiltins.td to include other files in the future? At the 
moment, the `-I ${CMAKE_CURRENT_SOURCE_DIR}/../../` bit in the cmake file isn't 
needed for anything.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D60763



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


[PATCH] D62623: Reduce memory consumption of coverage dumps

2019-06-03 Thread Vedant Kumar via Phabricator via cfe-commits
vsk added inline comments.



Comment at: clang/lib/CodeGen/CoverageMappingGen.cpp:1393
+  size_t CoverageMappingSize = 0;
+  for (auto &S : CoverageMappings) {
+CoverageMappingSize += S.size();

It doesn't look like the CoverageMappings std::vector is needed at all. 
Consider moving `FilenamesAndCoverageMappings` into CoverageMappingModuleGen?

That should reduce the memory requirements a bit more.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D62623



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


[PATCH] D62574: Initial draft of target-configurable address spaces.

2019-06-03 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added a comment.

In D62574#1527126 , @ebevhan wrote:

> In D62574#1523835 , @Anastasia wrote:
>
> > > This patch does not address the issue with the accessors
> > >  on Qualifiers (isAddressSpaceSupersetOf, compatiblyIncludes),
> > >  because I don't know how to solve it without breaking a ton of
> > >  rather nice encapsulation. Either, every mention of compatiblyIncludes
> > >  must be replaced with a call to a corresponding ASTContext method,
> > >  Qualifiers must have a handle to ASTContext, or ASTContext must be
> > >  passed to every such call. This revision mentions the issue in a comment:
> > >  https://reviews.llvm.org/D49294
> >
> > I think using ASTContext helper is ok then.
>
>
> Alright. Just to clarify, you mean the first option (using a new accessor on 
> ASTContext and replacing all existing compatiblyIncludes with that)?


Yes, it seems ok to me. Not sure if @rjmccall has an opinion.

> I'll have to see if that's possible without breaking a few more interfaces, 
> since you can throw around Qualifiers and check for compatibility without an 
> ASTContext today.
> 
>> I was just thinking about testing the new logic. Should we add something 
>> like  `-ffake-address-space-map` 
>> (https://clang.llvm.org/docs/UsersManual.html#opencl-specific-options) that 
>> will force targets to use some implementation of fake address space 
>> conversions? It was quite useful in OpenCL before we added concrete targets 
>> with address spaces. Alternatively, we can try to use SPIR that is a generic 
>> Clang-only target that has address spaces.
> 
> Well, there are a couple targets which have target address spaces even today, 
> I think. AMDGPU should be one, right?

Yes, however I am not sure we will be able to test more than what we test with 
OpenCL. Also I am not sure AMD maintainer would be ok. Do you have any concrete 
idea of what to test?

> I forgot to mention; this patch also disables two "extensions" that Clang 
> has, namely that subtraction and comparison on pointers of different address 
> spaces is legal regardless of address space compatibility. I'm pretty sure 
> that these extensions only exist because Clang hasn't had support for targets 
> to express address space compatibility until now. According to the docs, x86 
> uses address spaces for certain types of segment access: 
> https://clang.llvm.org/docs/LanguageExtensions.html#memory-references-to-specified-segments
> 
> If x86 (or any target that uses target address spaces) wants to keep using 
> this and still keep such pointers implicitly compatible with each other, it 
> will need to configure this in its target hooks.

Ok, it seems logical to me. In OpenCL we don't allow those cases.




Comment at: lib/Sema/SemaOverload.cpp:3171
+  // qualification conversion for disjoint address spaces make address space
+  // casts *work*?
   Qualifiers FromQuals = FromType.getQualifiers();

ebevhan wrote:
> Anastasia wrote:
> > I guess if address spaces don't overlap we don't have a valid qualification 
> > conversion. This seems to align with the logic for cv. My guess is that 
> > none of the other conversions will be valid for non overlapping address 
> > spaces and the error will occur.
> > 
> > I think at this point we might not need to know if it's implicit or 
> > explicit? I believe we might have a separate check for this somewhere 
> > because it works for OpenCL. I don't know though if it might simplify the 
> > flow if we move this logic rather here.
> > 
> > The cv checks above seem to use `CStyle` flag. I am wondering if we could 
> > use it to detect implicit or explicit. Because we can only cast address 
> > space with C style cast at the moment.  Although after adding 
> > `addrspace_cast` operator that will no longer be the only way.
> > I guess if address spaces don't overlap we don't have a valid qualification 
> > conversion. This seems to align with the logic for cv. My guess is that 
> > none of the other conversions will be valid for non overlapping address 
> > spaces and the error will occur.
> 
> Right. So the reasoning is that if the address spaces are disjoint according 
> to the overlap rule, then it cannot be considered a qualification conversion.
> 
> But with the new hooks, it's possible for a target to allow explicit 
> conversion even if address spaces do not overlap according to the rules. So 
> even though there is no overlap, such a conversion could still be a 
> qualification conversion if it was explicit (either via a c-style cast or an 
> `addrspace_cast`). This is in fact the default for all targets (see the patch 
> in TargetInfo.h).
> 
> I think I need a refresher on how the casts were meant to work; were both 
> `static_cast` and `reinterpret_cast` supposed to be capable of implicit 
> conversion (say, private -> generic) but only `addrspace_cast` for the other 
> direction (ge

r362434 - Permit Exception Spec mismatch with NoThrow on inherited Virtual

2019-06-03 Thread Erich Keane via cfe-commits
Author: erichkeane
Date: Mon Jun  3 11:36:26 2019
New Revision: 362434

URL: http://llvm.org/viewvc/llvm-project?rev=362434&view=rev
Log:
Permit Exception Spec mismatch with NoThrow on inherited Virtual

As reported here: https://bugs.llvm.org/show_bug.cgi?id=42100

This fairly common pattern ends up being an error in MinGW, so relax it
in all cases to a warning.

Modified:
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Sema/SemaExceptionSpec.cpp
cfe/trunk/test/SemaCXX/nothrow-vs-exception-specs.cpp

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=362434&r1=362433&r2=362434&view=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Mon Jun  3 11:36:26 2019
@@ -1564,6 +1564,7 @@ public:
   bool CheckExceptionSpecSubset(const PartialDiagnostic &DiagID,
 const PartialDiagnostic &NestedDiagID,
 const PartialDiagnostic &NoteID,
+const PartialDiagnostic &NoThrowDiagID,
 const FunctionProtoType *Superset,
 SourceLocation SuperLoc,
 const FunctionProtoType *Subset,

Modified: cfe/trunk/lib/Sema/SemaExceptionSpec.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExceptionSpec.cpp?rev=362434&r1=362433&r2=362434&view=diff
==
--- cfe/trunk/lib/Sema/SemaExceptionSpec.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExceptionSpec.cpp Mon Jun  3 11:36:26 2019
@@ -744,6 +744,7 @@ bool Sema::handlerCanCatch(QualType Hand
 bool Sema::CheckExceptionSpecSubset(const PartialDiagnostic &DiagID,
 const PartialDiagnostic &NestedDiagID,
 const PartialDiagnostic &NoteID,
+const PartialDiagnostic &NoThrowDiagID,
 const FunctionProtoType *Superset,
 SourceLocation SuperLoc,
 const FunctionProtoType *Subset,
@@ -790,6 +791,16 @@ bool Sema::CheckExceptionSpecSubset(cons
 return CheckParamExceptionSpec(NestedDiagID, NoteID, Superset, SuperLoc,
Subset, SubLoc);
 
+  // Allow __declspec(nothrow) to be missing on redeclaration as an extension 
in
+  // some cases.
+  if (NoThrowDiagID.getDiagID() != 0 && SubCanThrow == CT_Can &&
+  SuperCanThrow == CT_Cannot && SuperEST == EST_NoThrow) {
+Diag(SubLoc, NoThrowDiagID);
+if (NoteID.getDiagID() != 0)
+  Diag(SuperLoc, NoteID);
+return true;
+  }
+
   // If the subset contains everything or the superset contains nothing, we've
   // failed.
   if ((SubCanThrow == CT_Can && SubEST != EST_Dynamic) ||
@@ -919,9 +930,9 @@ bool Sema::CheckExceptionSpecCompatibili
   // void (*q)(void (*) throw(int)) = p;
   //   }
   // ... because it might be instantiated with T=int.
-  return CheckExceptionSpecSubset(PDiag(DiagID), PDiag(NestedDiagID), PDiag(),
-  ToFunc, From->getSourceRange().getBegin(),
-  FromFunc, SourceLocation()) &&
+  return CheckExceptionSpecSubset(
+ PDiag(DiagID), PDiag(NestedDiagID), PDiag(), PDiag(), ToFunc,
+ From->getSourceRange().getBegin(), FromFunc, SourceLocation()) &&
  !getLangOpts().CPlusPlus17;
 }
 
@@ -953,6 +964,7 @@ bool Sema::CheckOverridingFunctionExcept
   return CheckExceptionSpecSubset(PDiag(DiagID),
   PDiag(diag::err_deep_exception_specs_differ),
   
PDiag(diag::note_overridden_virtual_function),
+  PDiag(diag::ext_override_exception_spec),
   Old->getType()->getAs(),
   Old->getLocation(),
   New->getType()->getAs(),

Modified: cfe/trunk/test/SemaCXX/nothrow-vs-exception-specs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/nothrow-vs-exception-specs.cpp?rev=362434&r1=362433&r2=362434&view=diff
==
--- cfe/trunk/test/SemaCXX/nothrow-vs-exception-specs.cpp (original)
+++ cfe/trunk/test/SemaCXX/nothrow-vs-exception-specs.cpp Mon Jun  3 11:36:26 
2019
@@ -69,3 +69,22 @@ struct S {
   __declspec(nothrow) void f4() noexcept(true);
   __declspec(nothrow) void f5() noexcept(false);
 };
+
+namespace PR42100 {
+class Base {
+public:
+  // expected-note@+1{{overridden virtual function is here}}
+  virtual __declspec(nothrow) void foo() = 0;
+  // expected-note@+1{{previous declaration is here}}
+  __declspec(nothrow) void bar();
+};
+
+

r362435 - Make NoThrow FunctionLike, make FunctionLike include references, fix

2019-06-03 Thread Erich Keane via cfe-commits
Author: erichkeane
Date: Mon Jun  3 11:36:33 2019
New Revision: 362435

URL: http://llvm.org/viewvc/llvm-project?rev=362435&view=rev
Log:
Make NoThrow FunctionLike, make FunctionLike include references, fix
prettyprint

__declspec(nothrow) should work on function pointers as well as function
references, so this changes it to FunctionLike.  Additionally,
FunctionLike needed to be modified to permit function references.

Finally, the TypePrinter didn't properly print the NoThrow exception
specifier, so make sure we get that right as well.

Modified:
cfe/trunk/include/clang/AST/Type.h
cfe/trunk/include/clang/Basic/Attr.td
cfe/trunk/lib/AST/DeclBase.cpp
cfe/trunk/lib/AST/TypePrinter.cpp
cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test
cfe/trunk/test/SemaCXX/nothrow-vs-exception-specs.cpp

Modified: cfe/trunk/include/clang/AST/Type.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Type.h?rev=362435&r1=362434&r2=362435&view=diff
==
--- cfe/trunk/include/clang/AST/Type.h (original)
+++ cfe/trunk/include/clang/AST/Type.h Mon Jun  3 11:36:33 2019
@@ -1962,6 +1962,7 @@ public:
   bool isLValueReferenceType() const;
   bool isRValueReferenceType() const;
   bool isFunctionPointerType() const;
+  bool isFunctionReferenceType() const;
   bool isMemberPointerType() const;
   bool isMemberFunctionPointerType() const;
   bool isMemberDataPointerType() const;
@@ -6372,6 +6373,13 @@ inline bool Type::isFunctionPointerType(
 return T->getPointeeType()->isFunctionType();
   else
 return false;
+}
+
+inline bool Type::isFunctionReferenceType() const {
+  if (const auto *T = getAs())
+return T->getPointeeType()->isFunctionType();
+  else
+return false;
 }
 
 inline bool Type::isMemberPointerType() const {

Modified: cfe/trunk/include/clang/Basic/Attr.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=362435&r1=362434&r2=362435&view=diff
==
--- cfe/trunk/include/clang/Basic/Attr.td (original)
+++ cfe/trunk/include/clang/Basic/Attr.td Mon Jun  3 11:36:33 2019
@@ -1657,7 +1657,7 @@ def NoStackProtector : InheritableAttr {
 
 def NoThrow : InheritableAttr {
   let Spellings = [GCC<"nothrow">, Declspec<"nothrow">];
-  let Subjects = SubjectList<[Function]>;
+  let Subjects = SubjectList<[FunctionLike]>;
   let Documentation = [NoThrowDocs];
 }
 

Modified: cfe/trunk/lib/AST/DeclBase.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/DeclBase.cpp?rev=362435&r1=362434&r2=362435&view=diff
==
--- cfe/trunk/lib/AST/DeclBase.cpp (original)
+++ cfe/trunk/lib/AST/DeclBase.cpp Mon Jun  3 11:36:33 2019
@@ -957,6 +957,8 @@ const FunctionType *Decl::getFunctionTyp
 
   if (Ty->isFunctionPointerType())
 Ty = Ty->getAs()->getPointeeType();
+  else if (Ty->isFunctionReferenceType())
+Ty = Ty->getAs()->getPointeeType();
   else if (BlocksToo && Ty->isBlockPointerType())
 Ty = Ty->getAs()->getPointeeType();
 

Modified: cfe/trunk/lib/AST/TypePrinter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/TypePrinter.cpp?rev=362435&r1=362434&r2=362435&view=diff
==
--- cfe/trunk/lib/AST/TypePrinter.cpp (original)
+++ cfe/trunk/lib/AST/TypePrinter.cpp Mon Jun  3 11:36:33 2019
@@ -734,6 +734,8 @@ FunctionProtoType::printExceptionSpecifi
 OS << getExceptionType(I).stream(Policy);
   }
 OS << ')';
+  } else if (EST_NoThrow == getExceptionSpecType()) {
+OS << " __attribute__((nothrow))";
   } else if (isNoexceptExceptionSpec(getExceptionSpecType())) {
 OS << " noexcept";
 // FIXME:Is it useful to print out the expression for a non-dependent

Modified: cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test?rev=362435&r1=362434&r2=362435&view=diff
==
--- cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test 
(original)
+++ cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test Mon Jun 
 3 11:36:33 2019
@@ -86,7 +86,7 @@
 // CHECK-NEXT: NoSplitStack (SubjectMatchRule_function)
 // CHECK-NEXT: NoStackProtector (SubjectMatchRule_function)
 // CHECK-NEXT: NoThreadSafetyAnalysis (SubjectMatchRule_function)
-// CHECK-NEXT: NoThrow (SubjectMatchRule_function)
+// CHECK-NEXT: NoThrow (SubjectMatchRule_hasType_functionType)
 // CHECK-NEXT: NotTailCalled (SubjectMatchRule_function)
 // CHECK-NEXT: OSConsumed (SubjectMatchRule_variable_is_parameter)
 // CHECK-NEXT: OSReturnsNotRetained (SubjectMatchRule_function, 
SubjectMatchRule_objc_method, SubjectMatchRule_objc_property,

[PATCH] D62780: msabi: Fix exponential mangling time for even more contrived inputs

2019-06-03 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added inline comments.



Comment at: clang/lib/AST/MicrosoftMangle.cpp:819-823
 ArgBackRefMap::iterator Found = TemplateArgBackReferences.find(ND);
 if (Found == TemplateArgBackReferences.end()) {
-  // Mangle full template name into temporary buffer.
-  llvm::SmallString<64> TemplateMangling;
-  llvm::raw_svector_ostream Stream(TemplateMangling);
-  MicrosoftCXXNameMangler Extra(Context, Stream);
-  Extra.mangleTemplateInstantiationName(TD, *TemplateArgs);
-
-  // Use the string backref vector to possibly get a back reference.
-  mangleSourceName(TemplateMangling);
-
-  // Memoize back reference for this type.
-  BackRefVec::iterator StringFound =
-  llvm::find(NameBackReferences, TemplateMangling);
-  if (StringFound != NameBackReferences.end()) {
-TemplateArgBackReferences[ND] =
-StringFound - NameBackReferences.begin();
+
+  TemplateArgStringMap::iterator Found = TemplateArgStrings.find(ND);
+  if (Found == TemplateArgStrings.end()) {

Here's a thought: could we get by with one map? I think we can be certain that 
nothing mangles to integer literals between 0 and 9, since otherwise the 
demangler couldn't distinguish those from back references. So, can we keep the 
string map, and insert the string "0", "1", etc for back referenced things?


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

https://reviews.llvm.org/D62780



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


Re: [PATCH] D62133: test/CodeGen/builtin-stackaddress.c duplicates test/CodeGen/2004-02-13-BuiltinFrameReturnAddress.c

2019-06-03 Thread Eric Christopher via cfe-commits
Will do.

On Sun, Jun 2, 2019 at 5:43 AM A. Skrobov via Phabricator
 wrote:
>
> t.yomitch added a comment.
>
> Thanks Eric!
> I don't have commit access; could someone please commit this for me?
>
>
> Repository:
>   rC Clang
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D62133/new/
>
> https://reviews.llvm.org/D62133
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D62648: [Sema][Typo] Fix assertion failure for expressions with multiple typos

2019-06-03 Thread David Goldman via Phabricator via cfe-commits
dgoldman updated this revision to Diff 202772.
dgoldman added a comment.

- Fix diagnostics for ignored TypoExprs


Repository:
  rC Clang

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

https://reviews.llvm.org/D62648

Files:
  lib/Sema/SemaExprCXX.cpp
  test/Sema/typo-correction-recursive.cpp

Index: test/Sema/typo-correction-recursive.cpp
===
--- /dev/null
+++ test/Sema/typo-correction-recursive.cpp
@@ -0,0 +1,65 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+// Check the following typo correction behavior:
+// - multiple typos in a single member call chain are all diagnosed
+// - no typos are diagnosed for multiple typos in an expression when not all
+//   typos can be corrected
+
+class DeepClass
+{
+public:
+  void trigger() const;  // expected-note {{'trigger' declared here}}
+};
+
+class Y
+{
+public:
+  const DeepClass& getX() const { return m_deepInstance; } // expected-note {{'getX' declared here}}
+  int getN() const { return m_n; }
+private:
+  DeepClass m_deepInstance;
+  int m_n;
+};
+
+class Z
+{
+public:
+  const Y& getY0() const { return m_y0; } // expected-note {{'getY0' declared here}}
+  const Y& getY1() const { return m_y1; }
+  const Y& getActiveY() const { return m_y0; }
+
+private:
+  Y m_y0;
+  Y m_y1;
+};
+
+Z z_obj;
+
+void testMultipleCorrections()
+{
+  z_obj.getY2(). // expected-error {{no member named 'getY2' in 'Z'; did you mean 'getY0'}}
+getM().  // expected-error {{no member named 'getM' in 'Y'; did you mean 'getX'}}
+triggee();   // expected-error {{no member named 'triggee' in 'DeepClass'; did you mean 'trigger'}}
+}
+
+void testNoCorrections()
+{
+  z_obj.getY2(). // expected-error {{no member named 'getY2' in 'Z'}}
+getM().
+thisDoesntSeemToMakeSense();
+}
+
+struct C {};
+struct D { int value; };
+struct A {
+  C get_me_a_C();
+};
+struct B {
+  D get_me_a_D();
+};
+A make_an_A();
+B make_an_B();
+int testDiscardedCorrections() {
+  return make_an_E().  // expected-error {{use of undeclared identifier 'make_an_E'}}
+get_me_a_Z().value;
+}
Index: lib/Sema/SemaExprCXX.cpp
===
--- lib/Sema/SemaExprCXX.cpp
+++ lib/Sema/SemaExprCXX.cpp
@@ -7680,6 +7680,60 @@
 return ExprFilter(Res.get());
   }
 
+  // Try to transform the given expression, looping through the correction
+  // candidates with `CheckAndAdvanceTypoExprCorrectionStreams`.
+  //
+  // Since correcting typos may intoduce new TypoExprs, this function
+  // checks for new TypoExprs and recurses if it finds any. Note that it will
+  // only succeed if it is able to correct all typos in the given expression.
+  ExprResult RecursiveTransformLoop(Expr *E) {
+ExprResult Res;
+while (true) {
+  Res = TryTransform(E);
+
+  // The transform was valid: check if there any new TypoExprs were created.
+  // If so, we need to recurse to check their validity.
+  if (!Res.isInvalid() && !TypoExprs.empty()) {
+Expr *FixedExpr = Res.get();
+auto SavedTypoExprs = TypoExprs;
+llvm::SmallSetVector RecursiveTypoExprs;
+TypoExprs = RecursiveTypoExprs;
+FindTypoExprs(TypoExprs).TraverseStmt(FixedExpr);
+
+// Recurse to handle newly created TypoExprs. If we're not able to
+// handle them, discard these TypoExprs.
+ExprResult RecurResult = RecursiveTransformLoop(FixedExpr);
+if (RecurResult.isInvalid()) {
+  Res = ExprError();
+  // Recursive corrections didn't work, wipe them away and don't add
+  // them to the TypoExprs set.
+  for (auto TE : TypoExprs) {
+auto &State = SemaRef.getTypoExprState(TE);
+TransformCache.erase(TE);
+SemaRef.clearDelayedTypo(TE);
+  }
+} else {
+  // TypoExpr is valid: add newly created TypoExprs since we were
+  // able to correct them.
+  Res = RecurResult;
+  SavedTypoExprs.set_union(TypoExprs);
+}
+
+TypoExprs = SavedTypoExprs;
+  }
+  // If the transform is still valid after checking for any new typos,
+  // it's good to go.
+  if (!Res.isInvalid())
+break;
+
+  // The transform was invalid, see if we have any TypoExprs with untried
+  // correction candidates.
+  if (!CheckAndAdvanceTypoExprCorrectionStreams())
+break;
+}
+return Res;
+  }
+
 public:
   TransformTypos(Sema &SemaRef, VarDecl *InitDecl, llvm::function_ref Filter)
   : BaseTransform(SemaRef), InitDecl(InitDecl), ExprFilter(Filter) {}
@@ -7707,16 +7761,7 @@
   ExprResult TransformBlockExpr(BlockExpr *E) { return Owned(E); }
 
   ExprResult Transform(Expr *E) {
-ExprResult Res;
-while (true) {
-  Res = TryTransform(E);
-
-  // Exit if either the transform was valid or if there were no TypoExprs
-  // to transform that still have any untried correction candidates..
-

[PATCH] D62648: [Sema][Typo] Fix assertion failure for expressions with multiple typos

2019-06-03 Thread David Goldman via Phabricator via cfe-commits
dgoldman marked 2 inline comments as done.
dgoldman added inline comments.



Comment at: lib/Sema/SemaExprCXX.cpp:7713-7714
+  // Add the newly created typos to the TypoExprs list, even if they
+  // failed to apply. This allows them to be reaped although they won't
+  // emit any diagnostic.
+  SavedTypoExprs.set_union(TypoExprs);

rsmith wrote:
> What prevents diagnostics from being emitted for `TypoExpr`s we create for an 
> outer transform that we end up discarding? Eg, in:
> 
> ```
> struct Y {};
> struct Z { int value; };
> struct A {
>   Y get_me_a_Y();
> };
> struct B {
>   Z get_me_a_Z();
> };
> A make_an_A();
> B make_a_B();
> int f() {
>   return make_an_E().get_me_a_Z().value;
> }
> ```
> 
> I'm concerned that we will:
>  * try correcting `make_me_an_E` (`TypoExpr` `T0`) to `make_me_an_A` (because 
> that correction has the minimum edit distance) and discover that there is no 
> `get_me_a_Z` member, creating a new `TypoExpr` `T1`, and recurse:
>* try correcting `get_me_a_Z` (`TypoExpr` `T1`) to `get_me_a_Y` and 
> discover that there is no `value` member
>* no correction works: bail out of recursive step
>  * try correcting `make_me_an_E` (`TypoExpr` `T0`) to `make_me_a_B` and 
> succeed
> 
> But now we still have `T1` in our list of `TypoExpr`s, and will presumably 
> diagnose it (and take action below if it turned out to be ambiguous etc).
> 
Fixed by discarding the failed `TypoExpr`s



Comment at: lib/Sema/SemaExprCXX.cpp:7762-7787
 // Ensure none of the TypoExprs have multiple typo correction candidates
 // with the same edit length that pass all the checks and filters.
 // TODO: Properly handle various permutations of possible corrections when
 // there is more than one potentially ambiguous typo correction.
 // Also, disable typo correction while attempting the transform when
 // handling potentially ambiguous typo corrections as any new TypoExprs 
will
 // have been introduced by the application of one of the correction

rsmith wrote:
> What happens if an ambiguous `TypoExpr` is created as a result of one of the 
> outer level transformations?
> 
> In that case, I think that we will try alternatives for that `TypoExpr` here, 
> but that `TypoExpr` is not in the expression we're transforming (it was 
> created within `RecursiveTransformLoop` and isn't part of `E`), so we're just 
> redoing the same transformation we already did but with typo-correction 
> disabled. This means that the transform will fail (because we hit a typo and 
> can't correct it), so we'll accept the original set of corrections despite 
> them being ambiguous.
So what do you recommend here? Checking for the non-ambiguity in 
`RecursiveTransformLoop` itself?


Repository:
  rC Clang

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

https://reviews.llvm.org/D62648



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


Re: r362005 - Fix an unused-variable error.

2019-06-03 Thread David Blaikie via cfe-commits
If this is the only use of 'S', might be better/good to roll the expression
into the assertion?

On Wed, May 29, 2019 at 11:33 AM Haojian Wu via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: hokein
> Date: Wed May 29 11:36:54 2019
> New Revision: 362005
>
> URL: http://llvm.org/viewvc/llvm-project?rev=362005&view=rev
> Log:
> Fix an unused-variable error.
>
> Modified:
> cfe/trunk/lib/StaticAnalyzer/Core/Environment.cpp
>
> Modified: cfe/trunk/lib/StaticAnalyzer/Core/Environment.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/Environment.cpp?rev=362005&r1=362004&r2=362005&view=diff
>
> ==
> --- cfe/trunk/lib/StaticAnalyzer/Core/Environment.cpp (original)
> +++ cfe/trunk/lib/StaticAnalyzer/Core/Environment.cpp Wed May 29 11:36:54
> 2019
> @@ -248,6 +248,7 @@ void Environment::printJson(raw_ostream
>}
>
>const Stmt *S = I->first.getStmt();
> +  (void)S;
>assert(S != nullptr && "Expected non-null Stmt");
>
>LastI = I;
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D59424: [OpenMP][NVPTX] Replace void** buffer by byte-wise buffer

2019-06-03 Thread Gheorghe-Teodor Bercea via Phabricator via cfe-commits
gtbercea added a comment.

Could you check if there is any change in the number of registers new scheme 
vs. old scheme?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D59424



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


[PATCH] D62648: [Sema][Typo] Fix assertion failure for expressions with multiple typos

2019-06-03 Thread David Goldman via Phabricator via cfe-commits
dgoldman updated this revision to Diff 202775.
dgoldman marked an inline comment as done.
dgoldman added a comment.

- Fix discarded correction test


Repository:
  rC Clang

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

https://reviews.llvm.org/D62648

Files:
  lib/Sema/SemaExprCXX.cpp
  test/Sema/typo-correction-recursive.cpp

Index: test/Sema/typo-correction-recursive.cpp
===
--- /dev/null
+++ test/Sema/typo-correction-recursive.cpp
@@ -0,0 +1,71 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+
+// Check the following typo correction behavior:
+// - multiple typos in a single member call chain are all diagnosed
+// - no typos are diagnosed for multiple typos in an expression when not all
+//   typos can be corrected
+
+class DeepClass
+{
+public:
+  void trigger() const;  // expected-note {{'trigger' declared here}}
+};
+
+class Y
+{
+public:
+  const DeepClass& getX() const { return m_deepInstance; } // expected-note {{'getX' declared here}}
+  int getN() const { return m_n; }
+private:
+  DeepClass m_deepInstance;
+  int m_n;
+};
+
+class Z
+{
+public:
+  const Y& getY0() const { return m_y0; } // expected-note {{'getY0' declared here}}
+  const Y& getY1() const { return m_y1; }
+  const Y& getActiveY() const { return m_y0; }
+
+private:
+  Y m_y0;
+  Y m_y1;
+};
+
+Z z_obj;
+
+void testMultipleCorrections()
+{
+  z_obj.getY2(). // expected-error {{no member named 'getY2' in 'Z'; did you mean 'getY0'}}
+getM().  // expected-error {{no member named 'getM' in 'Y'; did you mean 'getX'}}
+triggee();   // expected-error {{no member named 'triggee' in 'DeepClass'; did you mean 'trigger'}}
+}
+
+void testNoCorrections()
+{
+  z_obj.getY2(). // expected-error {{no member named 'getY2' in 'Z'}}
+getM().
+thisDoesntSeemToMakeSense();
+}
+
+struct C {};
+struct D { int value; };
+struct A {
+  C get_me_a_C();
+};
+struct B {
+  D get_me_a_D(); // expected-note {{'get_me_a_D' declared here}}
+};
+class Scope {
+public:
+  A make_an_A();
+  B make_a_B(); // expected-note {{'make_a_B' declared here}}
+};
+
+Scope scope_obj;
+
+int testDiscardedCorrections() {
+  return scope_obj.make_an_E(). // expected-error {{no member named 'make_an_E' in 'Scope'; did you mean 'make_a_B'}}
+get_me_a_Z().value; // expected-error {{no member named 'get_me_a_Z' in 'B'; did you mean 'get_me_a_D'}}
+}
Index: lib/Sema/SemaExprCXX.cpp
===
--- lib/Sema/SemaExprCXX.cpp
+++ lib/Sema/SemaExprCXX.cpp
@@ -7680,6 +7680,60 @@
 return ExprFilter(Res.get());
   }
 
+  // Try to transform the given expression, looping through the correction
+  // candidates with `CheckAndAdvanceTypoExprCorrectionStreams`.
+  //
+  // Since correcting typos may intoduce new TypoExprs, this function
+  // checks for new TypoExprs and recurses if it finds any. Note that it will
+  // only succeed if it is able to correct all typos in the given expression.
+  ExprResult RecursiveTransformLoop(Expr *E) {
+ExprResult Res;
+while (true) {
+  Res = TryTransform(E);
+
+  // The transform was valid: check if there any new TypoExprs were created.
+  // If so, we need to recurse to check their validity.
+  if (!Res.isInvalid() && !TypoExprs.empty()) {
+Expr *FixedExpr = Res.get();
+auto SavedTypoExprs = TypoExprs;
+llvm::SmallSetVector RecursiveTypoExprs;
+TypoExprs = RecursiveTypoExprs;
+FindTypoExprs(TypoExprs).TraverseStmt(FixedExpr);
+
+// Recurse to handle newly created TypoExprs. If we're not able to
+// handle them, discard these TypoExprs.
+ExprResult RecurResult = RecursiveTransformLoop(FixedExpr);
+if (RecurResult.isInvalid()) {
+  Res = ExprError();
+  // Recursive corrections didn't work, wipe them away and don't add
+  // them to the TypoExprs set.
+  for (auto TE : TypoExprs) {
+auto &State = SemaRef.getTypoExprState(TE);
+TransformCache.erase(TE);
+SemaRef.clearDelayedTypo(TE);
+  }
+} else {
+  // TypoExpr is valid: add newly created TypoExprs since we were
+  // able to correct them.
+  Res = RecurResult;
+  SavedTypoExprs.set_union(TypoExprs);
+}
+
+TypoExprs = SavedTypoExprs;
+  }
+  // If the transform is still valid after checking for any new typos,
+  // it's good to go.
+  if (!Res.isInvalid())
+break;
+
+  // The transform was invalid, see if we have any TypoExprs with untried
+  // correction candidates.
+  if (!CheckAndAdvanceTypoExprCorrectionStreams())
+break;
+}
+return Res;
+  }
+
 public:
   TransformTypos(Sema &SemaRef, VarDecl *InitDecl, llvm::function_ref Filter)
   : BaseTransform(SemaRef), InitDecl(InitDecl), ExprFilter(Filter) {}
@@ -7707,16 +7761,7 @@
   ExprResult TransformBlo

[PATCH] D59319: [OpenMP][Offloading][1/3] A generic and simple target region interface

2019-06-03 Thread Gheorghe-Teodor Bercea via Phabricator via cfe-commits
gtbercea added a comment.

Could you add some tests for this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D59319



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


r362443 - Fix test failure from r362435

2019-06-03 Thread Erich Keane via cfe-commits
Author: erichkeane
Date: Mon Jun  3 12:57:52 2019
New Revision: 362443

URL: http://llvm.org/viewvc/llvm-project?rev=362443&view=rev
Log:
Fix test failure from r362435

Apparently I forgot to do an open brace in a namespace, so we get an
error about an extra closing brace.

Modified:
cfe/trunk/test/SemaCXX/nothrow-vs-exception-specs.cpp

Modified: cfe/trunk/test/SemaCXX/nothrow-vs-exception-specs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/nothrow-vs-exception-specs.cpp?rev=362443&r1=362442&r2=362443&view=diff
==
--- cfe/trunk/test/SemaCXX/nothrow-vs-exception-specs.cpp (original)
+++ cfe/trunk/test/SemaCXX/nothrow-vs-exception-specs.cpp Mon Jun  3 12:57:52 
2019
@@ -89,7 +89,7 @@ public:
 };
 }
 
-namespace FuncPointerReferenceConverts
+namespace FuncPointerReferenceConverts {
 void FuncToBeRefed();
 
 #ifndef CPP17


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


[PATCH] D59319: [OpenMP][Offloading][1/3] A generic and simple target region interface

2019-06-03 Thread Gheorghe-Teodor Bercea via Phabricator via cfe-commits
gtbercea added a comment.

Could you check what the difference is between the same kernel in today's SPMD 
mode vs the SPMD mode produced via this method? Number of registers, 
instructions, checking everything gets optimized out as expected. The LLVM-IR 
should be almost identical.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D59319



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


[PATCH] D62648: [Sema][Typo] Fix assertion failure for expressions with multiple typos

2019-06-03 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added inline comments.



Comment at: lib/Sema/SemaExprCXX.cpp:7762-7787
 // Ensure none of the TypoExprs have multiple typo correction candidates
 // with the same edit length that pass all the checks and filters.
 // TODO: Properly handle various permutations of possible corrections when
 // there is more than one potentially ambiguous typo correction.
 // Also, disable typo correction while attempting the transform when
 // handling potentially ambiguous typo corrections as any new TypoExprs 
will
 // have been introduced by the application of one of the correction

dgoldman wrote:
> rsmith wrote:
> > What happens if an ambiguous `TypoExpr` is created as a result of one of 
> > the outer level transformations?
> > 
> > In that case, I think that we will try alternatives for that `TypoExpr` 
> > here, but that `TypoExpr` is not in the expression we're transforming (it 
> > was created within `RecursiveTransformLoop` and isn't part of `E`), so 
> > we're just redoing the same transformation we already did but with 
> > typo-correction disabled. This means that the transform will fail (because 
> > we hit a typo and can't correct it), so we'll accept the original set of 
> > corrections despite them being ambiguous.
> So what do you recommend here? Checking for the non-ambiguity in 
> `RecursiveTransformLoop` itself?
Suggestion: in the recursive transform, if we find a potential ambiguity, check 
whether it's actually ambiguous before returning. If it is ambiguous, fail out 
of the entire typo-correction process: one of our tied-for-best candidates was 
ambiguous, so we deem the overall typo-correction process to be ambiguous. And 
if not, then carry on as in your current patch.



Repository:
  rC Clang

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

https://reviews.llvm.org/D62648



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


[PATCH] D62638: [analyzer] A Python script to prettify the ExplodedGraph dumps.

2019-06-03 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a comment.

I disabled tests on Windows for now (rC362343 
 -> rC362347 
), but other than that the tests are working 
well, there was nothing to worry about.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D62638



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


[PATCH] D59474: [OpenMP 5.0] Codegen support for user-defined mappers

2019-06-03 Thread Lingda Li via Phabricator via cfe-commits
lildmh updated this revision to Diff 202790.
lildmh edited the summary of this revision.
lildmh added a comment.

Implement the new mapper codegen scheme


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

https://reviews.llvm.org/D59474

Files:
  include/clang/AST/GlobalDecl.h
  lib/AST/ASTContext.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/CodeGenModule.h
  lib/CodeGen/ModuleBuilder.cpp
  test/OpenMP/declare_mapper_codegen.cpp

Index: test/OpenMP/declare_mapper_codegen.cpp
===
--- test/OpenMP/declare_mapper_codegen.cpp
+++ test/OpenMP/declare_mapper_codegen.cpp
@@ -1,92 +1,418 @@
-///==///
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap %s
-
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -verify -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm %s -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp-simd -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck -allow-deprecated-dag-overlap  --check-prefix SIMD-ONLY0 %s
-
 // SIMD-ONLY0-NOT: {{__kmpc|__tgt}}
 
 // expected-no-diagnostics
 #ifndef HEADER
 #define HEADER
 
+///==///
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-64 %s
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -std=c++11 -triple i386-unknown-unknown -emit-pch -femit-all-decls -disable-llvm-passes -o %t %s
+// RUN: %clang_cc1 -DCK0 -fopenmp -fopenmp-targets=i386-pc-linux-gnu -x c++ -triple i386-unknown-unknown -std=c++11 -femit-all-decls -disable-llvm-passes -include-pch %t -verify %s -emit-llvm -o - | FileCheck --check-prefix CK0 --check-prefix CK0-32 %s
+
+// RUN: %clang_cc1 -DCK0 -verify -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -triple powerpc64le-unknown-unknown -emit-llvm -femit-all-decls -disable-llvm-passes %s -o - | FileCheck --check-prefix SIMD-ONLY0 %s
+// RUN: %clang_cc1 -DCK0 -fopenmp-simd -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -femit-all-decls -disable-l

[PATCH] D61446: Generalize the pass registration mechanism used by Polly to any third-party tool

2019-06-03 Thread serge via Phabricator via cfe-commits
serge-sans-paille updated this revision to Diff 202795.
serge-sans-paille added a comment.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

- provide minimal documentation
- fix testing configuration
- validate locally with both shared and static libraries, using monorepo or 
tool layout
- update sample https://sergesanspaille.fedorapeople.org/bye.tgz

@Meinersbur thanks a lot for the previous review! lld integration, as well as 
new PM integration, will be for another commit, in order to prevent this review 
from growing too large


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61446

Files:
  clang/tools/driver/CMakeLists.txt
  clang/tools/driver/cc1_main.cpp
  llvm/CMakeLists.txt
  llvm/cmake/modules/AddLLVM.cmake
  llvm/docs/WritingAnLLVMPass.rst
  llvm/include/llvm/Config/llvm-config.h.cmake
  llvm/tools/CMakeLists.txt
  llvm/tools/bugpoint/CMakeLists.txt
  llvm/tools/bugpoint/bugpoint.cpp
  llvm/tools/opt/CMakeLists.txt
  llvm/tools/opt/NewPMDriver.cpp
  llvm/tools/opt/opt.cpp
  llvm/utils/gn/secondary/llvm/include/llvm/Config/BUILD.gn
  polly/CMakeLists.txt

Index: polly/CMakeLists.txt
===
--- polly/CMakeLists.txt
+++ polly/CMakeLists.txt
@@ -208,3 +208,7 @@
 add_custom_target(polly-update-format DEPENDS ${update_format_depends})
 set_target_properties(polly-update-format PROPERTIES FOLDER "Polly")
 
+register_llvm_extension(polly)
+
+# Polly-ACC requires the NVPTX target to be present in the executable it is linked to
+set_property(TARGET bugpoint APPEND PROPERTY LLVM_COMPILER_EXTENSIONS LLVMTarget)
Index: llvm/utils/gn/secondary/llvm/include/llvm/Config/BUILD.gn
===
--- llvm/utils/gn/secondary/llvm/include/llvm/Config/BUILD.gn
+++ llvm/utils/gn/secondary/llvm/include/llvm/Config/BUILD.gn
@@ -321,7 +321,6 @@
   output = "$target_gen_dir/llvm-config.h"
   values = [
 "LLVM_ENABLE_DUMP=",
-"LINK_POLLY_INTO_TOOLS=",
 "LLVM_DEFAULT_TARGET_TRIPLE=$llvm_target_triple",
 "LLVM_HAS_ATOMICS=1",
 "LLVM_HOST_TRIPLE=$llvm_current_triple",
Index: llvm/tools/opt/opt.cpp
===
--- llvm/tools/opt/opt.cpp
+++ llvm/tools/opt/opt.cpp
@@ -470,11 +470,11 @@
 getCodeModel(), GetCodeGenOptLevel());
 }
 
-#ifdef LINK_POLLY_INTO_TOOLS
-namespace polly {
-void initializePollyPasses(llvm::PassRegistry &Registry);
-}
-#endif
+#define HANDLE_EXTENSION(Ns, Ext)  \
+  namespace Ns {   \
+  void initialize##Ext##Passes(llvm::PassRegistry &Registry);  \
+  }
+#include "llvm/Support/Extension.def"
 
 //===--===//
 // main for opt
@@ -529,9 +529,8 @@
   initializeWasmEHPreparePass(Registry);
   initializeWriteBitcodePassPass(Registry);
 
-#ifdef LINK_POLLY_INTO_TOOLS
-  polly::initializePollyPasses(Registry);
-#endif
+#define HANDLE_EXTENSION(Ns, Ext) Ns::initialize##Ext##Passes(Registry);
+#include "llvm/Support/Extension.def"
 
   cl::ParseCommandLineOptions(argc, argv,
 "llvm .bc -> .bc modular optimizer and analysis printer\n");
Index: llvm/tools/opt/NewPMDriver.cpp
===
--- llvm/tools/opt/NewPMDriver.cpp
+++ llvm/tools/opt/NewPMDriver.cpp
@@ -202,11 +202,11 @@
 });
 }
 
-#ifdef LINK_POLLY_INTO_TOOLS
-namespace polly {
-void RegisterPollyPasses(PassBuilder &);
-}
-#endif
+#define HANDLE_EXTENSION(Ns, Ext)  \
+  namespace Ns {   \
+  void Register##Ext##Passes(PassBuilder &);   \
+  }
+#include "llvm/Support/Extension.def"
 
 bool llvm::runPassPipeline(StringRef Arg0, Module &M, TargetMachine *TM,
ToolOutputFile *Out, ToolOutputFile *ThinLTOLinkOut,
@@ -290,9 +290,8 @@
 return false;
   });
 
-#ifdef LINK_POLLY_INTO_TOOLS
-  polly::RegisterPollyPasses(PB);
-#endif
+#define HANDLE_EXTENSION(Ns, Ext) Ns::Register##Ext##Passes(PB);
+#include "llvm/Support/Extension.def"
 
   // Specially handle the alias analysis manager so that we can register
   // a custom pipeline of AA passes with it.
Index: llvm/tools/opt/CMakeLists.txt
===
--- llvm/tools/opt/CMakeLists.txt
+++ llvm/tools/opt/CMakeLists.txt
@@ -37,7 +37,4 @@
   intrinsics_gen
   )
 export_executable_symbols(opt)
-
-if(WITH_POLLY AND LINK_POLLY_INTO_TOOLS)
-  target_link_libraries(opt PRIVATE Polly)
-endif(WITH_POLLY AND LINK_POLLY_INTO_TOOLS)
+target_link_libraries(opt PRIVATE $)
Index: llvm/tools/bugpoint/bugpoint.cpp
=

[PATCH] D60974: Clang IFSO driver action.

2019-06-03 Thread Alexander Shaposhnikov via Phabricator via cfe-commits
alexshap added inline comments.



Comment at: clang/lib/Frontend/InterfaceStubFunctionsConsumer.cpp:30
+uint8_t Binding;
+MangledSymbol() = delete;
+MangledSymbol(const std::string &Name, const std::string &ParentName,

would be nice to have a newline before the ctor


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60974



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


[PATCH] D61446: Generalize the pass registration mechanism used by Polly to any third-party tool

2019-06-03 Thread Philip Pfaffe via Phabricator via cfe-commits
philip.pfaffe added a subscriber: beanz.
philip.pfaffe added a comment.

I fear you'll need to plan at least for new pm right now. Otherwise your change 
will be obsolete in half a year. What is it really that LINK_X_INTO_TOOLS is 
supposed to do? Effectively bake in something that's consumable by -load or 
-load-plugin, right? So can we use that interface directly? Effectively, can we 
have statically built-in plugins, that prepopulate the plug-in loader 
mechanisms?

If the patch becomes too large then it should be split into separate functional 
units, e.g., one adding the cmake functionality, one updating the plugins and 
the tools.

You could also ask @beanz for a review of the cmake change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61446



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


[PATCH] D60691: [ARM] Replace fp-only-sp and d16 with fp64 and d32.

2019-06-03 Thread James Nagurne via Phabricator via cfe-commits
JamesNagurne added a comment.

Hi Simon et. al., I'm working on a downstream ARM toolchain and have 
downstreamed this change into our codebase.
We saw that you've fixed the -mfpu=none issue and have taken that as well, but 
are still running into some issues.

Prior to your change, the optionset "-mcpu=cortex-m4 -mfloat-abi=hard" created 
the following target features in the LLVM IR coming out of clang:
"target-features"="+armv7e-m,+d16,+dsp,+fp-only-sp,+hwdiv,+thumb-mode,+vfp4,-crc,-dotprod,-fp16fml,-hwdiv-arm,-ras"

In specific, note the +d16, +fp-only-sp.

After your changes, we're not seeing the associated -d32, -fp64 target features:
"target-cpu"="cortex-m4" 
"target-features"="+armv7e-m,+dsp,+hwdiv,+thumb-mode,+vfp4,-crc,-dotprod,-fp16fml,-hwdiv-arm,-ras"

As a result, we are getting linktime failures between our libraries, which use 
"-mcpu=cortex-m4 -mfloat-abi=hard", and our tests, which specifically call out 
the FPU version being used.
An interesting note is that the target machine table has the following:

  def : ProcessorModel<"cortex-m4", CortexM4Model,[ARMv7em,
   FeatureVFP4_D16_SP,
   
FeaturePrefLoopAlign32,
   FeatureHasSlowFPVMLx,
   FeatureUseMISched,
   FeatureUseAA,
   
FeatureHasNoBranchPredictor]>;

Would this not mean that we'd expect vfp4-d16-sp when not otherwise specified? 
If not, then what is the expected behavior of -mfloat-abi=hard in the absence 
of an -mfpu specification?

Thanks,
J.B. Nagurne
Texas Instruments
Code Generation


Repository:
  rC Clang

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

https://reviews.llvm.org/D60691



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


[PATCH] D62556: [analyzer] NFC: CallDescription: Implement describing C library functions.

2019-06-03 Thread Aleksei Sidorin via Phabricator via cfe-commits
a_sidorin added a comment.

Hi Artem,
Looks mostly good, but I have some comments inline.




Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h:1064
   // e.g. "{a, b}" represent the qualified names, like "a::b".
   std::vector QualifiedName;
   unsigned RequiredArgs;

Not for this review, but why do we have a vector of `const char *`, not 
StringRefs?



Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h:1066
   unsigned RequiredArgs;
+  int Flags;
 

Is it a good idea to make Flags a bitfield structure?



Comment at: clang/lib/StaticAnalyzer/Core/CallEvent.cpp:379
+
   if (!II || II != CD.II)
 return false;

`!II` is never false due to the newly-introduced early return.


Repository:
  rC Clang

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

https://reviews.llvm.org/D62556



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


[PATCH] D62557: [analyzer] Modernize CStringChecker to use CallDescriptions.

2019-06-03 Thread Aleksei Sidorin via Phabricator via cfe-commits
a_sidorin accepted this revision.
a_sidorin added a comment.
This revision is now accepted and ready to land.

LGTM!


Repository:
  rC Clang

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

https://reviews.llvm.org/D62557



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


[PATCH] D61446: Generalize the pass registration mechanism used by Polly to any third-party tool

2019-06-03 Thread Michael Kruse via Phabricator via cfe-commits
Meinersbur requested changes to this revision.
Meinersbur added a comment.
This revision now requires changes to proceed.

It still fails with the same error. `LINK_POLLY_INTO_TOOLS` is only set after 
the polly subdirectory is processed. Because it is an `option`, the ON value 
will be stored in the `CMakeCache.txt` and be available during the next run, it 
actually works after running the cmake configure step a second time. We should 
not expect users to do so. Because of this, any `option(...)` or `set(... 
CACHED)` should be done at the beginning of the file.




Comment at: llvm/CMakeLists.txt:497
 
-option(LLVM_POLLY_LINK_INTO_TOOLS "Statically link Polly into tools (if 
available)" ON)
-option(LLVM_POLLY_BUILD "Build LLVM with Polly" ON)

Note that there is `LLVM_POLLY_LINK_INTO_TOOLS` and `LINK_POLLY_INTO_TOOLS`. 
The former is the user-configurable option, the latter is for internal 
querying. At least, this is what is was meant for.



Comment at: llvm/CMakeLists.txt:928
 if( LLVM_INCLUDE_TOOLS )
   add_subdirectory(tools)
 endif()

Polly is included here. `LINK_POLLY_INTO_TOOLS` will not be visible in there if 
set only later.



Comment at: llvm/cmake/modules/AddLLVM.cmake:808
+
+option(LINK_${llvm_extension_upper}_INTO_TOOLS "Statically link 
${llvm_extension_project} into tools (if available)" ON)
+option(LLVM_${llvm_extension_upper}_BUILD "Build LLVM with 
${llvm_extension_project}" ON)

[remark] Use `LLVM_` prefix for LLVM-level options. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61446



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


[PATCH] D62825: [C++2a] Add __builtin_bit_cast, used to implement std::bit_cast

2019-06-03 Thread Erik Pilkington via Phabricator via cfe-commits
erik.pilkington created this revision.
erik.pilkington added reviewers: rsmith, jfb, rjmccall.
Herald added subscribers: llvm-commits, kristina, arphaman, dexonsmith, 
jkorous, hiraditya.
Herald added projects: clang, LLVM.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0476r2.html

This adds a new (pseudo) builtin, `__builtin_bit_cast(T, v)`, which performs a 
bit_cast from a value v to a type T. This expression can be evaluated at 
compile time under specific circumstances. The compile time evaluation 
currently doesn't support bit-fields, but I'm planning on fixing this in a 
follow up (some of the logic for figuring this out is in CodeGen).

rdar://44987528

Thanks for taking a look!


Repository:
  rC Clang

https://reviews.llvm.org/D62825

Files:
  clang/include/clang-c/Index.h
  clang/include/clang/AST/ExprCXX.h
  clang/include/clang/AST/OperationKinds.def
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/Basic/DiagnosticASTKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/Features.def
  clang/include/clang/Basic/StmtNodes.td
  clang/include/clang/Basic/TokenKinds.def
  clang/include/clang/Parse/Parser.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/Expr.cpp
  clang/lib/AST/ExprClassification.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/AST/StmtProfile.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CGExprAgg.cpp
  clang/lib/CodeGen/CGExprComplex.cpp
  clang/lib/CodeGen/CGExprConstant.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/Edit/RewriteObjCFoundationAPI.cpp
  clang/lib/Parse/ParseExpr.cpp
  clang/lib/Parse/ParseExprCXX.cpp
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaExceptionSpec.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriterStmt.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
  clang/test/CodeGenCXX/builtin-bit-cast.cpp
  clang/test/SemaCXX/builtin-bit-cast.cpp
  clang/test/SemaCXX/constexpr-builtin-bit-cast.cpp
  clang/tools/libclang/CIndex.cpp
  clang/tools/libclang/CXCursor.cpp
  llvm/include/llvm/ADT/APInt.h
  llvm/lib/ExecutionEngine/ExecutionEngine.cpp
  llvm/lib/Support/APInt.cpp

Index: llvm/lib/Support/APInt.cpp
===
--- llvm/lib/Support/APInt.cpp
+++ llvm/lib/Support/APInt.cpp
@@ -2929,3 +2929,56 @@
   LLVM_DEBUG(dbgs() << __func__ << ": solution (wrap): " << X << '\n');
   return X;
 }
+
+/// StoreIntToMemory - Fills the StoreBytes bytes of memory starting from Dst
+/// with the integer held in IntVal.
+void llvm::StoreIntToMemory(const APInt &IntVal, uint8_t *Dst,
+unsigned StoreBytes) {
+  assert((IntVal.getBitWidth()+7)/8 >= StoreBytes && "Integer too small!");
+  const uint8_t *Src = (const uint8_t *)IntVal.getRawData();
+
+  if (sys::IsLittleEndianHost) {
+// Little-endian host - the source is ordered from LSB to MSB.  Order the
+// destination from LSB to MSB: Do a straight copy.
+memcpy(Dst, Src, StoreBytes);
+  } else {
+// Big-endian host - the source is an array of 64 bit words ordered from
+// LSW to MSW.  Each word is ordered from MSB to LSB.  Order the destination
+// from MSB to LSB: Reverse the word order, but not the bytes in a word.
+while (StoreBytes > sizeof(uint64_t)) {
+  StoreBytes -= sizeof(uint64_t);
+  // May not be aligned so use memcpy.
+  memcpy(Dst + StoreBytes, Src, sizeof(uint64_t));
+  Src += sizeof(uint64_t);
+}
+
+memcpy(Dst, Src + sizeof(uint64_t) - StoreBytes, StoreBytes);
+  }
+}
+
+/// LoadIntFromMemory - Loads the integer stored in the LoadBytes bytes starting
+/// from Src into IntVal, which is assumed to be wide enough and to hold zero.
+void llvm::LoadIntFromMemory(APInt &IntVal, uint8_t *Src, unsigned LoadBytes) {
+  assert((IntVal.getBitWidth()+7)/8 >= LoadBytes && "Integer too small!");
+  uint8_t *Dst = reinterpret_cast(
+   const_cast(IntVal.getRawData()));
+
+  if (sys::IsLittleEndianHost)
+// Little-endian host - the destination must be ordered from LSB to MSB.
+// The source is ordered from LSB to MSB: Do a straight copy.
+memcpy(Dst, Src, LoadBytes);
+  else {
+// Big-endian - the destination is an array of 64 bit words ordered from
+// LSW to MSW.  Each word must be ordered from MSB to LSB.  The source is
+// ordered from MSB to LSB: Reverse the word order, but not the bytes in
+// a word.
+while (LoadBytes > sizeof(uint64_t)) {
+  LoadBytes -= sizeof(uint64_t);
+  // May not be aligned so use memcpy.
+  memcpy(Dst, Src + LoadBytes, sizeof(uint64_t));
+  Dst += sizeof(uint64_t);
+}
+
+memcpy(Dst + sizeof(uint64_t) - LoadBytes, Src, LoadBytes);
+  }
+}
Index: llvm/lib/ExecutionEngine/ExecutionEngine.cpp
==

[PATCH] D62780: msabi: Fix exponential mangling time for even more contrived inputs

2019-06-03 Thread Nico Weber via Phabricator via cfe-commits
thakis marked an inline comment as done.
thakis added inline comments.



Comment at: clang/lib/AST/MicrosoftMangle.cpp:819-823
 ArgBackRefMap::iterator Found = TemplateArgBackReferences.find(ND);
 if (Found == TemplateArgBackReferences.end()) {
-  // Mangle full template name into temporary buffer.
-  llvm::SmallString<64> TemplateMangling;
-  llvm::raw_svector_ostream Stream(TemplateMangling);
-  MicrosoftCXXNameMangler Extra(Context, Stream);
-  Extra.mangleTemplateInstantiationName(TD, *TemplateArgs);
-
-  // Use the string backref vector to possibly get a back reference.
-  mangleSourceName(TemplateMangling);
-
-  // Memoize back reference for this type.
-  BackRefVec::iterator StringFound =
-  llvm::find(NameBackReferences, TemplateMangling);
-  if (StringFound != NameBackReferences.end()) {
-TemplateArgBackReferences[ND] =
-StringFound - NameBackReferences.begin();
+
+  TemplateArgStringMap::iterator Found = TemplateArgStrings.find(ND);
+  if (Found == TemplateArgStrings.end()) {

rnk wrote:
> Here's a thought: could we get by with one map? I think we can be certain 
> that nothing mangles to integer literals between 0 and 9, since otherwise the 
> demangler couldn't distinguish those from back references. So, can we keep 
> the string map, and insert the string "0", "1", etc for back referenced 
> things?
I had wondered too. In the end, I figured the int map needs less memory and is 
almost always enough, so I went with this approach.


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

https://reviews.llvm.org/D62780



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


r362459 - Add clang source minimizer that reduces source to directives

2019-06-03 Thread Alex Lorenz via cfe-commits
Author: arphaman
Date: Mon Jun  3 15:59:17 2019
New Revision: 362459

URL: http://llvm.org/viewvc/llvm-project?rev=362459&view=rev
Log:
Add clang source minimizer that reduces source to directives
that might affect the dependency list for a compilation

This commit introduces a dependency directives source minimizer to clang
that minimizes header and source files to the minimum necessary preprocessor
directives for evaluating includes. It reduces the source down to #define, 
#include,

The source minimizer works by lexing the input with a custom fast lexer that 
recognizes
the preprocessor directives it cares about, and emitting those directives in 
the minimized source.
It ignores source code, comments, and normalizes whitespace. It gives up and 
fails if seems
any directives that it doesn't recognize as valid (e.g. #define 0).

In addition to the source minimizer this patch adds a
-print-dependency-directives-minimized-source CC1 option that allows you to 
invoke the minimizer
from clang directly.

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

Added:
cfe/trunk/include/clang/Lex/DependencyDirectivesSourceMinimizer.h
cfe/trunk/lib/Lex/DependencyDirectivesSourceMinimizer.cpp
cfe/trunk/test/Frontend/minimize_source_to_dependency_directives.c

cfe/trunk/test/Lexer/minimize_source_to_dependency_directives_at_import_extra_tokens.m

cfe/trunk/test/Lexer/minimize_source_to_dependency_directives_at_import_missing_semi.m

cfe/trunk/test/Lexer/minimize_source_to_dependency_directives_invalid_macro_name.c
cfe/trunk/unittests/Lex/DependencyDirectivesSourceMinimizerTest.cpp
Modified:
cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td
cfe/trunk/include/clang/Driver/CC1Options.td
cfe/trunk/include/clang/Frontend/FrontendActions.h
cfe/trunk/include/clang/Frontend/FrontendOptions.h
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/lib/Frontend/FrontendActions.cpp
cfe/trunk/lib/FrontendTool/ExecuteCompilerInvocation.cpp
cfe/trunk/lib/Lex/CMakeLists.txt
cfe/trunk/unittests/Lex/CMakeLists.txt

Modified: cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td?rev=362459&r1=362458&r2=362459&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td Mon Jun  3 15:59:17 2019
@@ -818,4 +818,13 @@ def err_pp_eof_in_assume_nonnull : Error
 
 }
 
+let CategoryName = "Dependency Directive Source Minimization Issue" in {
+
+def err_dep_source_minimizer_missing_sema_after_at_import : Error<
+  "could not find ';' after @import">;
+def err_dep_source_minimizer_unexpected_tokens_at_import : Error<
+  "unexpected extra tokens at end of @import declaration">;
+
+}
+
 }

Modified: cfe/trunk/include/clang/Driver/CC1Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CC1Options.td?rev=362459&r1=362458&r2=362459&view=diff
==
--- cfe/trunk/include/clang/Driver/CC1Options.td (original)
+++ cfe/trunk/include/clang/Driver/CC1Options.td Mon Jun  3 15:59:17 2019
@@ -612,6 +612,9 @@ def migrate : Flag<["-"], "migrate">,
   HelpText<"Migrate source code">;
 def compiler_options_dump : Flag<["-"], "compiler-options-dump">,
   HelpText<"Dump the compiler configuration options">;
+def print_dependency_directives_minimized_source : Flag<["-"],
+  "print-dependency-directives-minimized-source">,
+  HelpText<"Print the output of the dependency directives source minimizer">;
 }
 
 def emit_llvm_uselists : Flag<["-"], "emit-llvm-uselists">,

Modified: cfe/trunk/include/clang/Frontend/FrontendActions.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/FrontendActions.h?rev=362459&r1=362458&r2=362459&view=diff
==
--- cfe/trunk/include/clang/Frontend/FrontendActions.h (original)
+++ cfe/trunk/include/clang/Frontend/FrontendActions.h Mon Jun  3 15:59:17 2019
@@ -240,6 +240,17 @@ protected:
   bool usesPreprocessorOnly() const override { return true; }
 };
 
+class PrintDependencyDirectivesSourceMinimizerAction : public FrontendAction {
+protected:
+  void ExecuteAction() override;
+  std::unique_ptr CreateASTConsumer(CompilerInstance &,
+ StringRef) override {
+return nullptr;
+  }
+
+  bool usesPreprocessorOnly() const override { return true; }
+};
+
 
//===--===//
 // Preprocessor Actions
 
//===--===//

Modified: cfe/trunk/include/clang/Frontend/FrontendOptions.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/FrontendOptions.h

  1   2   >