[PATCH] D47090: Implement C++17 .

[Eric Fiselier via Phabricator via cfe-commits]

EricWF added a comment.

In https://reviews.llvm.org/D47090#1105389, @Quuxplusone wrote:

> > I would prefer if we completed  (according to 
> > the current standard, not the LFTS spec), and then moved it.
> >  Would you be willing to do that instead?
>
> Let me see if I understand. libc++'s `` differs 
> from C++17 `` in at least these ways:
>  (A) It's missing `monotonic_buffer_resource` and 
> `{un,}synchronized_pool_resource`


Those were initially in the LFTS spec, I think they're in LFTS v2.

> (B) It's got different semantics around uses-allocator construction because 
> of https://wg21.link/lwg2969

Issue resolutions should probably be applied to the experimental versions as 
well.

> (C) It's got a different header name

I don't think this is relevant.

> This patch is basically proposing to fix things in the order C-A-B (and fix C 
> by making copies of everything); you're proposing to fix things in the order 
> A-B-C (and fix C by moving everything).
> 
> I have no objection to fixing A in `` if people 
> think that'd be useful. I didn't do that in this patch simply because I'd 
> observed other `` headers already getting replaced with 
> `#error` messages, and it seemed like any further work on the 
> `` headers would have been wasted.
> 
> I don't know who's using `` today, but in 
> theory I worry that fixing B in `` (before 
> doing C) might actually break someone's code.

I'm not concerned with it. We make no promises about ABI and API stability for 
 headers.  Do we implement the LFTS v1, v2, or in future, v3, 
API? I would rather follow the standard spec. I believe
it will actually make transitioning from `` to ``, since 
the behaviour is the same.


Repository:
  rCXX libc++

https://reviews.llvm.org/D47090



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

[PATCH] D47101: [Sema] Use %sub to cleanup overload diagnostics

[Eric Fiselier via Phabricator via cfe-commits]

EricWF created this revision.
EricWF added a reviewer: rsmith.

This patch adds the newly added `%sub` diagnostic modifier to cleanup 
repetition in the overload candidate diagnostics.

I think this should be good to go.

@rsmith: Some of the notes now emit `function template` where they only said 
`function` previously. It seems OK to me, but I would like your sign off on it.


Repository:
  rC Clang

https://reviews.llvm.org/D47101

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Sema/SemaOverload.cpp
  test/CXX/drs/dr4xx.cpp
  test/CXX/special/class.inhctor/p1.cpp
  test/SemaCXX/attr-noreturn.cpp
  test/SemaCXX/cxx1y-generic-lambdas.cpp
  test/SemaCXX/overload-call.cpp
  test/SemaCXX/overload-member-call.cpp

Index: test/SemaCXX/overload-member-call.cpp
===
--- test/SemaCXX/overload-member-call.cpp
+++ test/SemaCXX/overload-member-call.cpp
@@ -70,7 +70,8 @@
 // Tests the exact text used to note the candidates
 namespace test1 {
   class A {
-template  void foo(T t, unsigned N); // expected-note {{candidate function not viable: no known conversion from 'const char [6]' to 'unsigned int' for 2nd argument}}
+template 
+void foo(T t, unsigned N); // expected-note {{candidate function template not viable: no known conversion from 'const char [6]' to 'unsigned int' for 2nd argument}}
 void foo(int n, char N); // expected-note {{candidate function not viable: no known conversion from 'const char [6]' to 'char' for 2nd argument}} 
 void foo(int n, const char *s, int t); // expected-note {{candidate function not viable: requires 3 arguments, but 2 were provided}}
 void foo(int n, const char *s, int t, ...); // expected-note {{candidate function not viable: requires at least 3 arguments, but 2 were provided}}
Index: test/SemaCXX/overload-call.cpp
===
--- test/SemaCXX/overload-call.cpp
+++ test/SemaCXX/overload-call.cpp
@@ -338,22 +338,23 @@
 
 // Tests the exact text used to note the candidates
 namespace test1 {
-  template  void foo(T t, unsigned N); // expected-note {{candidate function not viable: no known conversion from 'const char [6]' to 'unsigned int' for 2nd argument}}
-  void foo(int n, char N); // expected-note {{candidate function not viable: no known conversion from 'const char [6]' to 'char' for 2nd argument}} 
-  void foo(int n, const char *s, int t); // expected-note {{candidate function not viable: requires 3 arguments, but 2 were provided}}
-  void foo(int n, const char *s, int t, ...); // expected-note {{candidate function not viable: requires at least 3 arguments, but 2 were provided}}
-  void foo(int n, const char *s, int t, int u = 0); // expected-note {{candidate function not viable: requires at least 3 arguments, but 2 were provided}}
-
-  // PR 11857
-  void foo(int n); // expected-note {{candidate function not viable: requires single argument 'n', but 2 arguments were provided}}
-  void foo(unsigned n = 10); // expected-note {{candidate function not viable: allows at most single argument 'n', but 2 arguments were provided}}
-  void bar(int n, int u = 0); // expected-note {{candidate function not viable: requires at least argument 'n', but no arguments were provided}}
-  void baz(int n = 0, int u = 0); // expected-note {{candidate function not viable: requires at most 2 arguments, but 3 were provided}}
-
-  void test() {
-foo(4, "hello"); //expected-error {{no matching function for call to 'foo'}}
-bar(); //expected-error {{no matching function for call to 'bar'}}
-baz(3, 4, 5); // expected-error {{no matching function for call to 'baz'}}
+template 
+void foo(T t, unsigned N);// expected-note {{candidate function template not viable: no known conversion from 'const char [6]' to 'unsigned int' for 2nd argument}}
+void foo(int n, char N);  // expected-note {{candidate function not viable: no known conversion from 'const char [6]' to 'char' for 2nd argument}}
+void foo(int n, const char *s, int t);// expected-note {{candidate function not viable: requires 3 arguments, but 2 were provided}}
+void foo(int n, const char *s, int t, ...);   // expected-note {{candidate function not viable: requires at least 3 arguments, but 2 were provided}}
+void foo(int n, const char *s, int t, int u = 0); // expected-note {{candidate function not viable: requires at least 3 arguments, but 2 were provided}}
+
+// PR 11857
+void foo(int n);// expected-note {{candidate function not viable: requires single argument 'n', but 2 arguments were provided}}
+void foo(unsigned n = 10);  // expected-note {{candidate function not viable: allows at most single argument 'n', but 2 arguments were provided}}
+void bar(int n, int u = 0); // expected-note {{candidate function not viable: requires at least argument 'n', but no arguments were provided}}
+void baz(int n = 0

[PATCH] D47096: CodeGen: block capture shouldn't ICE

[JF Bastien via Phabricator via cfe-commits]

jfb closed this revision.
jfb added a comment.

r332801


Repository:
  rC Clang

https://reviews.llvm.org/D47096



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

r332801 - CodeGen: block capture shouldn't ICE

[JF Bastien via cfe-commits]

Author: jfb
Date: Fri May 18 21:21:26 2018
New Revision: 332801

URL: http://llvm.org/viewvc/llvm-project?rev=332801&view=rev
Log:
CodeGen: block capture shouldn't ICE

When a lambda capture captures a __block in the same statement, the compiler 
asserts out because isCapturedBy assumes that an Expr can only be a BlockExpr, 
StmtExpr, or if it's a Stmt then all the statement's children are expressions. 
That's wrong, we need to visit all sub-statements even if they're not 
expressions to see if they also capture.

Fix this issue by pulling out the isCapturedBy logic to use RecursiveASTVisitor.



Added:
cfe/trunk/test/CodeGenCXX/block-capture.cpp
Modified:
cfe/trunk/lib/CodeGen/CGDecl.cpp

Modified: cfe/trunk/lib/CodeGen/CGDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDecl.cpp?rev=332801&r1=332800&r2=332801&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDecl.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDecl.cpp Fri May 18 21:21:26 2018
@@ -1244,17 +1244,30 @@ CodeGenFunction::EmitAutoVarAlloca(const
   return emission;
 }
 
+static bool isCapturedBy(const VarDecl &, const Expr *);
+
+/// Determines whether the given __block variable is potentially
+/// captured by the given statement.
+static bool isCapturedBy(const VarDecl &Var, const Stmt *S) {
+  if (const Expr *E = dyn_cast(S))
+return isCapturedBy(Var, E);
+  for (const Stmt *SubStmt : S->children())
+if (isCapturedBy(Var, SubStmt))
+  return true;
+  return false;
+}
+
 /// Determines whether the given __block variable is potentially
 /// captured by the given expression.
-static bool isCapturedBy(const VarDecl &var, const Expr *e) {
+static bool isCapturedBy(const VarDecl &Var, const Expr *E) {
   // Skip the most common kinds of expressions that make
   // hierarchy-walking expensive.
-  e = e->IgnoreParenCasts();
+  E = E->IgnoreParenCasts();
 
-  if (const BlockExpr *be = dyn_cast(e)) {
-const BlockDecl *block = be->getBlockDecl();
-for (const auto &I : block->captures()) {
-  if (I.getVariable() == &var)
+  if (const BlockExpr *BE = dyn_cast(E)) {
+const BlockDecl *Block = BE->getBlockDecl();
+for (const auto &I : Block->captures()) {
+  if (I.getVariable() == &Var)
 return true;
 }
 
@@ -1262,19 +1275,19 @@ static bool isCapturedBy(const VarDecl &
 return false;
   }
 
-  if (const StmtExpr *SE = dyn_cast(e)) {
+  if (const StmtExpr *SE = dyn_cast(E)) {
 const CompoundStmt *CS = SE->getSubStmt();
 for (const auto *BI : CS->body())
-  if (const auto *E = dyn_cast(BI)) {
-if (isCapturedBy(var, E))
-return true;
+  if (const auto *BIE = dyn_cast(BI)) {
+if (isCapturedBy(Var, BIE))
+  return true;
   }
   else if (const auto *DS = dyn_cast(BI)) {
   // special case declarations
   for (const auto *I : DS->decls()) {
   if (const auto *VD = dyn_cast((I))) {
 const Expr *Init = VD->getInit();
-if (Init && isCapturedBy(var, Init))
+if (Init && isCapturedBy(Var, Init))
   return true;
   }
   }
@@ -1286,8 +1299,8 @@ static bool isCapturedBy(const VarDecl &
 return false;
   }
 
-  for (const Stmt *SubStmt : e->children())
-if (isCapturedBy(var, cast(SubStmt)))
+  for (const Stmt *SubStmt : E->children())
+if (isCapturedBy(Var, SubStmt))
   return true;
 
   return false;

Added: cfe/trunk/test/CodeGenCXX/block-capture.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/block-capture.cpp?rev=332801&view=auto
==
--- cfe/trunk/test/CodeGenCXX/block-capture.cpp (added)
+++ cfe/trunk/test/CodeGenCXX/block-capture.cpp Fri May 18 21:21:26 2018
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -x c++ -std=c++11 -fblocks -emit-llvm %s -o - | FileCheck %s
+
+// CHECK: %struct.__block_byref_baz = type { i8*, %struct.__block_byref_baz*, 
i32, i32, i32 }
+// CHECK: [[baz:%[0-9a-z_]*]] = alloca %struct.__block_byref_baz
+// CHECK: [[bazref:%[0-9a-z_\.]*]] = getelementptr inbounds 
%struct.__block_byref_baz, %struct.__block_byref_baz* [[baz]], i32 0, i32 1
+// CHECK: store %struct.__block_byref_baz* [[baz]], 
%struct.__block_byref_baz** [[bazref]]
+// CHECK: [[disposable:%[0-9a-z_]*]] = bitcast %struct.__block_byref_baz* 
[[baz]] to i8*
+// CHECK: call void @_Block_object_dispose(i8* [[disposable]]
+
+int main() {
+  __block int baz = [&]() { return 0; }();
+  return 0;
+}


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

[PATCH] D47096: CodeGen: block capture shouldn't ICE

[JF Bastien via Phabricator via cfe-commits]

jfb added a comment.

In https://reviews.llvm.org/D47096#1105492, @rjmccall wrote:

> Test case should go in test/CodeGenCXX.  Also, there already is a 
> `blocks.cpp` there.


I moved it, but didn't merge with the existing block.cpp because it just checks 
for not crashing. I'd rather make sure that the checks don't inadvertently pick 
up the wrong test.


Repository:
  rC Clang

https://reviews.llvm.org/D47096



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

[PATCH] D47096: CodeGen: block capture shouldn't ICE

[John McCall via Phabricator via cfe-commits]

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

LGTM.


Repository:
  rC Clang

https://reviews.llvm.org/D47096



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

[PATCH] D47096: CodeGen: block capture shouldn't ICE

[JF Bastien via Phabricator via cfe-commits]

jfb updated this revision to Diff 147648.
jfb added a comment.

- move test


Repository:
  rC Clang

https://reviews.llvm.org/D47096

Files:
  lib/CodeGen/CGDecl.cpp
  test/CodeGenCXX/block-capture.cpp


Index: test/CodeGenCXX/block-capture.cpp
===
--- /dev/null
+++ test/CodeGenCXX/block-capture.cpp
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -x c++ -std=c++11 -fblocks -emit-llvm %s -o - | FileCheck %s
+
+// CHECK: %struct.__block_byref_baz = type { i8*, %struct.__block_byref_baz*, 
i32, i32, i32 }
+// CHECK: [[baz:%[0-9a-z_]*]] = alloca %struct.__block_byref_baz
+// CHECK: [[bazref:%[0-9a-z_\.]*]] = getelementptr inbounds 
%struct.__block_byref_baz, %struct.__block_byref_baz* [[baz]], i32 0, i32 1
+// CHECK: store %struct.__block_byref_baz* [[baz]], 
%struct.__block_byref_baz** [[bazref]]
+// CHECK: [[disposable:%[0-9a-z_]*]] = bitcast %struct.__block_byref_baz* 
[[baz]] to i8*
+// CHECK: call void @_Block_object_dispose(i8* [[disposable]]
+
+int main() {
+  __block int baz = [&]() { return 0; }();
+  return 0;
+}
Index: lib/CodeGen/CGDecl.cpp
===
--- lib/CodeGen/CGDecl.cpp
+++ lib/CodeGen/CGDecl.cpp
@@ -1244,37 +1244,50 @@
   return emission;
 }
 
+static bool isCapturedBy(const VarDecl &, const Expr *);
+
+/// Determines whether the given __block variable is potentially
+/// captured by the given statement.
+static bool isCapturedBy(const VarDecl &Var, const Stmt *S) {
+  if (const Expr *E = dyn_cast(S))
+return isCapturedBy(Var, E);
+  for (const Stmt *SubStmt : S->children())
+if (isCapturedBy(Var, SubStmt))
+  return true;
+  return false;
+}
+
 /// Determines whether the given __block variable is potentially
 /// captured by the given expression.
-static bool isCapturedBy(const VarDecl &var, const Expr *e) {
+static bool isCapturedBy(const VarDecl &Var, const Expr *E) {
   // Skip the most common kinds of expressions that make
   // hierarchy-walking expensive.
-  e = e->IgnoreParenCasts();
+  E = E->IgnoreParenCasts();
 
-  if (const BlockExpr *be = dyn_cast(e)) {
-const BlockDecl *block = be->getBlockDecl();
-for (const auto &I : block->captures()) {
-  if (I.getVariable() == &var)
+  if (const BlockExpr *BE = dyn_cast(E)) {
+const BlockDecl *Block = BE->getBlockDecl();
+for (const auto &I : Block->captures()) {
+  if (I.getVariable() == &Var)
 return true;
 }
 
 // No need to walk into the subexpressions.
 return false;
   }
 
-  if (const StmtExpr *SE = dyn_cast(e)) {
+  if (const StmtExpr *SE = dyn_cast(E)) {
 const CompoundStmt *CS = SE->getSubStmt();
 for (const auto *BI : CS->body())
-  if (const auto *E = dyn_cast(BI)) {
-if (isCapturedBy(var, E))
-return true;
+  if (const auto *BIE = dyn_cast(BI)) {
+if (isCapturedBy(Var, BIE))
+  return true;
   }
   else if (const auto *DS = dyn_cast(BI)) {
   // special case declarations
   for (const auto *I : DS->decls()) {
   if (const auto *VD = dyn_cast((I))) {
 const Expr *Init = VD->getInit();
-if (Init && isCapturedBy(var, Init))
+if (Init && isCapturedBy(Var, Init))
   return true;
   }
   }
@@ -1286,8 +1299,8 @@
 return false;
   }
 
-  for (const Stmt *SubStmt : e->children())
-if (isCapturedBy(var, cast(SubStmt)))
+  for (const Stmt *SubStmt : E->children())
+if (isCapturedBy(Var, SubStmt))
   return true;
 
   return false;


Index: test/CodeGenCXX/block-capture.cpp
===
--- /dev/null
+++ test/CodeGenCXX/block-capture.cpp
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -x c++ -std=c++11 -fblocks -emit-llvm %s -o - | FileCheck %s
+
+// CHECK: %struct.__block_byref_baz = type { i8*, %struct.__block_byref_baz*, i32, i32, i32 }
+// CHECK: [[baz:%[0-9a-z_]*]] = alloca %struct.__block_byref_baz
+// CHECK: [[bazref:%[0-9a-z_\.]*]] = getelementptr inbounds %struct.__block_byref_baz, %struct.__block_byref_baz* [[baz]], i32 0, i32 1
+// CHECK: store %struct.__block_byref_baz* [[baz]], %struct.__block_byref_baz** [[bazref]]
+// CHECK: [[disposable:%[0-9a-z_]*]] = bitcast %struct.__block_byref_baz* [[baz]] to i8*
+// CHECK: call void @_Block_object_dispose(i8* [[disposable]]
+
+int main() {
+  __block int baz = [&]() { return 0; }();
+  return 0;
+}
Index: lib/CodeGen/CGDecl.cpp
===
--- lib/CodeGen/CGDecl.cpp
+++ lib/CodeGen/CGDecl.cpp
@@ -1244,37 +1244,50 @@
   return emission;
 }
 
+static bool isCapturedBy(const VarDecl &, const Expr *);
+
+/// Determines whether the given __block variable is potentially
+/// captured by the given statement.
+static bool isCapturedBy(const VarDecl &Var, const Stmt *S) {
+  if (const Expr *E = dyn_cast(S))
+return isCapturedBy(Var, E);
+  

[PATCH] D47099: Disable casting of alloca for ActiveFlag

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Maybe there should just be a method that makes a primitive alloca without the 
casting, and then you can call that in CreateTempAlloca.


https://reviews.llvm.org/D47099



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

[PATCH] D47096: CodeGen: block capture shouldn't ICE

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Test case should go in test/CodeGenCXX.  Also, there already is a `blocks.cpp` 
there.


Repository:
  rC Clang

https://reviews.llvm.org/D47096



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

[PATCH] D47096: CodeGen: block capture shouldn't ICE

[JF Bastien via Phabricator via cfe-commits]

jfb added a comment.

In https://reviews.llvm.org/D47096#1105455, @rjmccall wrote:

> `children()` is actually defined at the `Stmt` level, and if you look at how 
> it's implemented on e.g. `IfStmt`, you can see that it visits all of the 
> child `Stmt`s, including the if-condition.  So it should be fine.


Thanks for pointing this out! I was reading the code but missed that, and 
visitor seemed like the only reliable way to do what I wanted. Here's an update 
patch.


Repository:
  rC Clang

https://reviews.llvm.org/D47096



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

[PATCH] D47096: CodeGen: block capture shouldn't ICE

[JF Bastien via Phabricator via cfe-commits]

jfb updated this revision to Diff 147647.
jfb added a comment.

- Follow John's suggestion.


Repository:
  rC Clang

https://reviews.llvm.org/D47096

Files:
  lib/CodeGen/CGDecl.cpp
  test/CodeGen/block-capture.cpp


Index: test/CodeGen/block-capture.cpp
===
--- /dev/null
+++ test/CodeGen/block-capture.cpp
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -x c++ -std=c++11 -fblocks -emit-llvm %s -o - | FileCheck %s
+
+// CHECK: %struct.__block_byref_baz = type { i8*, %struct.__block_byref_baz*, 
i32, i32, i32 }
+// CHECK: [[baz:%[0-9a-z_]*]] = alloca %struct.__block_byref_baz
+// CHECK: [[bazref:%[0-9a-z_\.]*]] = getelementptr inbounds 
%struct.__block_byref_baz, %struct.__block_byref_baz* [[baz]], i32 0, i32 1
+// CHECK: store %struct.__block_byref_baz* [[baz]], 
%struct.__block_byref_baz** [[bazref]]
+// CHECK: [[disposable:%[0-9a-z_]*]] = bitcast %struct.__block_byref_baz* 
[[baz]] to i8*
+// CHECK: call void @_Block_object_dispose(i8* [[disposable]]
+
+int main() {
+  __block int baz = [&]() { return 0; }();
+  return 0;
+}
Index: lib/CodeGen/CGDecl.cpp
===
--- lib/CodeGen/CGDecl.cpp
+++ lib/CodeGen/CGDecl.cpp
@@ -1244,37 +1244,50 @@
   return emission;
 }
 
+static bool isCapturedBy(const VarDecl &, const Expr *);
+
+/// Determines whether the given __block variable is potentially
+/// captured by the given statement.
+static bool isCapturedBy(const VarDecl &Var, const Stmt *S) {
+  if (const Expr *E = dyn_cast(S))
+return isCapturedBy(Var, E);
+  for (const Stmt *SubStmt : S->children())
+if (isCapturedBy(Var, SubStmt))
+  return true;
+  return false;
+}
+
 /// Determines whether the given __block variable is potentially
 /// captured by the given expression.
-static bool isCapturedBy(const VarDecl &var, const Expr *e) {
+static bool isCapturedBy(const VarDecl &Var, const Expr *E) {
   // Skip the most common kinds of expressions that make
   // hierarchy-walking expensive.
-  e = e->IgnoreParenCasts();
+  E = E->IgnoreParenCasts();
 
-  if (const BlockExpr *be = dyn_cast(e)) {
-const BlockDecl *block = be->getBlockDecl();
-for (const auto &I : block->captures()) {
-  if (I.getVariable() == &var)
+  if (const BlockExpr *BE = dyn_cast(E)) {
+const BlockDecl *Block = BE->getBlockDecl();
+for (const auto &I : Block->captures()) {
+  if (I.getVariable() == &Var)
 return true;
 }
 
 // No need to walk into the subexpressions.
 return false;
   }
 
-  if (const StmtExpr *SE = dyn_cast(e)) {
+  if (const StmtExpr *SE = dyn_cast(E)) {
 const CompoundStmt *CS = SE->getSubStmt();
 for (const auto *BI : CS->body())
-  if (const auto *E = dyn_cast(BI)) {
-if (isCapturedBy(var, E))
-return true;
+  if (const auto *BIE = dyn_cast(BI)) {
+if (isCapturedBy(Var, BIE))
+  return true;
   }
   else if (const auto *DS = dyn_cast(BI)) {
   // special case declarations
   for (const auto *I : DS->decls()) {
   if (const auto *VD = dyn_cast((I))) {
 const Expr *Init = VD->getInit();
-if (Init && isCapturedBy(var, Init))
+if (Init && isCapturedBy(Var, Init))
   return true;
   }
   }
@@ -1286,8 +1299,8 @@
 return false;
   }
 
-  for (const Stmt *SubStmt : e->children())
-if (isCapturedBy(var, cast(SubStmt)))
+  for (const Stmt *SubStmt : E->children())
+if (isCapturedBy(Var, SubStmt))
   return true;
 
   return false;


Index: test/CodeGen/block-capture.cpp
===
--- /dev/null
+++ test/CodeGen/block-capture.cpp
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -x c++ -std=c++11 -fblocks -emit-llvm %s -o - | FileCheck %s
+
+// CHECK: %struct.__block_byref_baz = type { i8*, %struct.__block_byref_baz*, i32, i32, i32 }
+// CHECK: [[baz:%[0-9a-z_]*]] = alloca %struct.__block_byref_baz
+// CHECK: [[bazref:%[0-9a-z_\.]*]] = getelementptr inbounds %struct.__block_byref_baz, %struct.__block_byref_baz* [[baz]], i32 0, i32 1
+// CHECK: store %struct.__block_byref_baz* [[baz]], %struct.__block_byref_baz** [[bazref]]
+// CHECK: [[disposable:%[0-9a-z_]*]] = bitcast %struct.__block_byref_baz* [[baz]] to i8*
+// CHECK: call void @_Block_object_dispose(i8* [[disposable]]
+
+int main() {
+  __block int baz = [&]() { return 0; }();
+  return 0;
+}
Index: lib/CodeGen/CGDecl.cpp
===
--- lib/CodeGen/CGDecl.cpp
+++ lib/CodeGen/CGDecl.cpp
@@ -1244,37 +1244,50 @@
   return emission;
 }
 
+static bool isCapturedBy(const VarDecl &, const Expr *);
+
+/// Determines whether the given __block variable is potentially
+/// captured by the given statement.
+static bool isCapturedBy(const VarDecl &Var, const Stmt *S) {
+  if (const Expr *E = dyn_cast(S))
+return isCapturedBy(Var, E);
+ 

r332800 - Adjust and fix failing CXX tests after r332799

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Fri May 18 20:33:56 2018
New Revision: 332800

URL: http://llvm.org/viewvc/llvm-project?rev=332800&view=rev
Log:
Adjust and fix failing CXX tests after r332799

Modified:
cfe/trunk/test/CXX/class/class.union/p1.cpp
cfe/trunk/test/CXX/drs/dr5xx.cpp

Modified: cfe/trunk/test/CXX/class/class.union/p1.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CXX/class/class.union/p1.cpp?rev=332800&r1=332799&r2=332800&view=diff
==
--- cfe/trunk/test/CXX/class/class.union/p1.cpp (original)
+++ cfe/trunk/test/CXX/class/class.union/p1.cpp Fri May 18 20:33:56 2018
@@ -38,9 +38,9 @@ class Dtor {
 union U1 {
   Virtual v; // expected-error {{union member 'v' has a non-trivial copy 
constructor}}
   VirtualBase vbase; // expected-error {{union member 'vbase' has a 
non-trivial copy constructor}}
-  Ctor ctor; // expected-error {{union member 'ctor' has a non-trivial 
constructor}}
-  Ctor2 ctor2; // expected-error {{union member 'ctor2' has a non-trivial 
constructor}}
-  CtorTmpl ctortmpl; // expected-error {{union member 'ctortmpl' has a 
non-trivial constructor}}
+  Ctor ctor; // expected-error {{union member 'ctor' has a non-trivial default 
constructor}}
+  Ctor2 ctor2; // expected-error {{union member 'ctor2' has a non-trivial 
default constructor}}
+  CtorTmpl ctortmpl; // expected-error {{union member 'ctortmpl' has a 
non-trivial default constructor}}
   CopyCtor copyctor; // expected-error {{union member 'copyctor' has a 
non-trivial copy constructor}}
   CopyAssign copyassign; // expected-error {{union member 'copyassign' has a 
non-trivial copy assignment operator}}
   Dtor dtor; // expected-error {{union member 'dtor' has a non-trivial 
destructor}}
@@ -56,10 +56,10 @@ union U2 {
   } m2; // expected-error {{union member 'm2' has a non-trivial copy 
constructor}}
   struct {
 Ctor ctor; // expected-note {{because field of type 'Ctor' has a 
user-provided default constructor}}
-  } m3; // expected-error {{union member 'm3' has a non-trivial constructor}}
+  } m3; // expected-error {{union member 'm3' has a non-trivial default 
constructor}}
   struct {
 Ctor2 ctor2; // expected-note {{because field of type 'Ctor2' has a 
user-provided default constructor}}
-  } m3a; // expected-error {{union member 'm3a' has a non-trivial constructor}}
+  } m3a; // expected-error {{union member 'm3a' has a non-trivial default 
constructor}}
   struct { // expected-note {{no constructor can be used to copy an object of 
type 'const}}
 CopyCtor copyctor;
   } m4; // expected-error {{union member 'm4' has a non-trivial copy 
constructor}}
@@ -80,9 +80,9 @@ union U3 {
   struct s2 : VirtualBase { // expected-note {{because the function selected 
to copy base class of type 'VirtualBase' is not trivial}}
   } m2; // expected-error {{union member 'm2' has a non-trivial copy 
constructor}}
   struct s3 : Ctor { // expected-note {{because base class of type 'Ctor' has 
a user-provided default constructor}}
-  } m3; // expected-error {{union member 'm3' has a non-trivial constructor}}
+  } m3; // expected-error {{union member 'm3' has a non-trivial default 
constructor}}
   struct s3a : Ctor2 { // expected-note {{because base class of type 'Ctor2' 
has a user-provided default constructor}}
-  } m3a; // expected-error {{union member 'm3a' has a non-trivial constructor}}
+  } m3a; // expected-error {{union member 'm3a' has a non-trivial default 
constructor}}
   struct s4 : CopyCtor { // expected-note {{because no constructor can be used 
to copy an object of type 'const U3::s4'}}
   } m4; // expected-error {{union member 'm4' has a non-trivial copy 
constructor}}
   struct s5 : CopyAssign { // expected-note {{because no assignment operator 
can be used to copy an object of type 'const U3::s5'}}
@@ -93,7 +93,7 @@ union U3 {
   } m7;
   struct s8 {
 s8(...) = delete; // expected-note {{because it is a variadic function}} 
expected-warning {{C++11}}
-  } m8; // expected-error {{union member 'm8' has a non-trivial constructor}}
+  } m8; // expected-error {{union member 'm8' has a non-trivial default 
constructor}}
 };
 
 union U4 {

Modified: cfe/trunk/test/CXX/drs/dr5xx.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CXX/drs/dr5xx.cpp?rev=332800&r1=332799&r2=332800&view=diff
==
--- cfe/trunk/test/CXX/drs/dr5xx.cpp (original)
+++ cfe/trunk/test/CXX/drs/dr5xx.cpp Fri May 18 20:33:56 2018
@@ -74,7 +74,7 @@ namespace dr512 { // dr512: yes
   };
   union U { A a; };
 #if __cplusplus < 201103L
-  // expected-error@-2 {{has a non-trivial constructor}}
+  // expected-error@-2 {{has a non-trivial default constructor}}
   // expected-note@-6 {{no default constructor}}
   // expected-note@-6 {{suppressed by user-declared constructor}}
 #endif


___
cfe-commits mailing list
cfe-commits@lists.llvm

r332799 - [Clang Tablegen][RFC] Allow Early Textual Substitutions in `Diagnostic` messages.

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Fri May 18 20:12:04 2018
New Revision: 332799

URL: http://llvm.org/viewvc/llvm-project?rev=332799&view=rev
Log:
[Clang Tablegen][RFC] Allow Early Textual Substitutions in `Diagnostic` 
messages.

Summary:
There are cases where the same string or select is repeated verbatim in a lot 
of diagnostics. This can be a pain to maintain and update. Tablegen provides no 
way stash the common text somewhere and reuse it in the diagnostics, until now!

This patch allows diagnostic texts to contain `%sub{}`, where 
`` names a Tablegen record of type `TextSubstitution`. These 
substitutions are done early, before the diagnostic string is otherwise 
processed. All `%sub` modifiers will be replaced before the diagnostic 
definitions are emitted.

The substitution must specify all arguments used by the substitution, and 
modifier indexes in the substitution are re-numbered accordingly. For example:

```
def select_ovl_candidate : 
TextSubstitution<"%select{function|constructor}0%select{| template| %2}1">;
```
when used as
```
"candidate `%sub{select_ovl_candidate}3,2,1 not viable"
```
will act as if we wrote:
```
"candidate %select{function|constructor}3%select{| template| %1}2 not viable"
```

Reviewers: rsmith, rjmccall, aaron.ballman, a.sidorin

Reviewed By: rjmccall

Subscribers: cfe-commits

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

Added:
cfe/trunk/test/TableGen/DiagnosticDocs.inc
cfe/trunk/test/TableGen/emit-diag-docs.td
cfe/trunk/test/TableGen/text-substitution.td
Modified:
cfe/trunk/docs/InternalsManual.rst
cfe/trunk/include/clang/Basic/Diagnostic.td
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/test/SemaCXX/anonymous-struct.cpp
cfe/trunk/test/SemaCXX/cxx98-compat.cpp
cfe/trunk/test/TableGen/DiagnosticBase.inc
cfe/trunk/test/lit.cfg.py
cfe/trunk/utils/TableGen/ClangDiagnosticsEmitter.cpp

Modified: cfe/trunk/docs/InternalsManual.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/InternalsManual.rst?rev=332799&r1=332798&r2=332799&view=diff
==
--- cfe/trunk/docs/InternalsManual.rst (original)
+++ cfe/trunk/docs/InternalsManual.rst Fri May 18 20:12:04 2018
@@ -319,6 +319,32 @@ they should be discussed before they are
 repetitive diagnostics and/or have an idea for a useful formatter, please bring
 it up on the cfe-dev mailing list.
 
+**"sub" format**
+
+Example:
+  Given the following record definition of type ``TextSubstitution``:
+
+  .. code-block:: text
+
+def select_ovl_candidate : TextSubstitution<
+  "%select{function|constructor}0%select{| template| %2}1">;
+
+  which can be used as
+
+  .. code-block:: text
+
+def note_ovl_candidate : Note<
+  "candidate %sub{select_ovl_candidate}3,2,1 not viable">;
+
+  and will act as if it was written
+  ``"candidate %select{function|constructor}3%select{| template| %1}2 not 
viable"``.
+Description:
+  This format specifier is used to avoid repeating strings verbatim in multiple
+  diagnostics. The argument to ``%sub`` must name a ``TextSubstitution`` tblgen
+  record. The substitution must specify all arguments used by the substitution,
+  and the modifier indexes in the substitution are re-numbered accordingly. The
+  substituted text must itself be a valid format string before substitution.
+
 .. _internals-producing-diag:
 
 Producing the Diagnostic

Modified: cfe/trunk/include/clang/Basic/Diagnostic.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Diagnostic.td?rev=332799&r1=332798&r2=332799&view=diff
==
--- cfe/trunk/include/clang/Basic/Diagnostic.td (original)
+++ cfe/trunk/include/clang/Basic/Diagnostic.td Fri May 18 20:12:04 2018
@@ -39,6 +39,15 @@ def SFINAE_Suppress: SFINAER
 def SFINAE_Report  : SFINAEResponse;
 def SFINAE_AccessControl   : SFINAEResponse;
 
+// Textual substitutions which may be performed on the text of diagnostics
+class TextSubstitution {
+  string Substitution = Text;
+  // TODO: These are only here to allow substitutions to be declared inline 
with
+  // diagnostics
+  string Component = "";
+  string CategoryName = "";
+}
+
 // Diagnostic Categories.  These can be applied to groups or individual
 // diagnostics to specify a category.
 class DiagCategory {

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=332799&r1=332798&r2=332799&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Fri May 18 20:12:04 
2018
@@ -1622,13 +1622,16 @@ def warn_call_to_pure_virtual_member_fun
   "overrides of %0 in subclasses are not available in the "
   "%select

[PATCH] D46740: [Clang Tablegen][RFC] Allow Early Textual Substitutions in `Diagnostic` messages.

[Eric Fiselier via Phabricator via cfe-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rC332799: [Clang Tablegen][RFC] Allow Early Textual 
Substitutions in `Diagnostic`… (authored by EricWF, committed by ).

Repository:
  rC Clang

https://reviews.llvm.org/D46740

Files:
  docs/InternalsManual.rst
  include/clang/Basic/Diagnostic.td
  include/clang/Basic/DiagnosticSemaKinds.td
  test/SemaCXX/anonymous-struct.cpp
  test/SemaCXX/cxx98-compat.cpp
  test/TableGen/DiagnosticBase.inc
  test/TableGen/DiagnosticDocs.inc
  test/TableGen/emit-diag-docs.td
  test/TableGen/text-substitution.td
  test/lit.cfg.py
  utils/TableGen/ClangDiagnosticsEmitter.cpp

Index: docs/InternalsManual.rst
===
--- docs/InternalsManual.rst
+++ docs/InternalsManual.rst
@@ -319,6 +319,32 @@
 repetitive diagnostics and/or have an idea for a useful formatter, please bring
 it up on the cfe-dev mailing list.
 
+**"sub" format**
+
+Example:
+  Given the following record definition of type ``TextSubstitution``:
+
+  .. code-block:: text
+
+def select_ovl_candidate : TextSubstitution<
+  "%select{function|constructor}0%select{| template| %2}1">;
+
+  which can be used as
+
+  .. code-block:: text
+
+def note_ovl_candidate : Note<
+  "candidate %sub{select_ovl_candidate}3,2,1 not viable">;
+
+  and will act as if it was written
+  ``"candidate %select{function|constructor}3%select{| template| %1}2 not viable"``.
+Description:
+  This format specifier is used to avoid repeating strings verbatim in multiple
+  diagnostics. The argument to ``%sub`` must name a ``TextSubstitution`` tblgen
+  record. The substitution must specify all arguments used by the substitution,
+  and the modifier indexes in the substitution are re-numbered accordingly. The
+  substituted text must itself be a valid format string before substitution.
+
 .. _internals-producing-diag:
 
 Producing the Diagnostic
Index: include/clang/Basic/DiagnosticSemaKinds.td
===
--- include/clang/Basic/DiagnosticSemaKinds.td
+++ include/clang/Basic/DiagnosticSemaKinds.td
@@ -1622,13 +1622,16 @@
   "overrides of %0 in subclasses are not available in the "
   "%select{constructor|destructor}1 of %2">;
 
+def select_special_member_kind : TextSubstitution<
+  "%select{default constructor|copy constructor|move constructor|"
+  "copy assignment operator|move assignment operator|destructor}0">;
+
 def note_member_declared_at : Note<"member is declared here">;
 def note_ivar_decl : Note<"instance variable is declared here">;
 def note_bitfield_decl : Note<"bit-field is declared here">;
 def note_implicit_param_decl : Note<"%0 is an implicit parameter">;
 def note_member_synthesized_at : Note<
-  "in implicit %select{default constructor|copy constructor|move constructor|"
-  "copy assignment operator|move assignment operator|destructor}0 for %1 "
+  "in implicit %sub{select_special_member_kind}0 for %1 "
   "first required here">;
 def err_missing_default_ctor : Error<
   "%select{constructor for %1 must explicitly initialize the|"
@@ -1641,12 +1644,10 @@
 
 def err_illegal_union_or_anon_struct_member : Error<
   "%select{anonymous struct|union}0 member %1 has a non-trivial "
-  "%select{constructor|copy constructor|move constructor|copy assignment "
-  "operator|move assignment operator|destructor}2">;
+  "%sub{select_special_member_kind}2">;
 def warn_cxx98_compat_nontrivial_union_or_anon_struct_member : Warning<
   "%select{anonymous struct|union}0 member %1 with a non-trivial "
-  "%select{constructor|copy constructor|move constructor|copy assignment "
-  "operator|move assignment operator|destructor}2 is incompatible with C++98">,
+  "%sub{select_special_member_kind}2 is incompatible with C++98">,
   InGroup, DefaultIgnore;
 
 def note_nontrivial_virtual_dtor : Note<
@@ -1665,8 +1666,7 @@
   "%select{base class|field|an object}0 of type %3">;
 def note_nontrivial_user_provided : Note<
   "because %select{base class of |field of |}0type %1 has a user-provided "
-  "%select{default constructor|copy constructor|move constructor|"
-  "copy assignment operator|move assignment operator|destructor}2">;
+  "%sub{select_special_member_kind}2">;
 def note_nontrivial_in_class_init : Note<
   "because field %0 has an initializer">;
 def note_nontrivial_param_type : Note<
@@ -1733,9 +1733,7 @@
 
 // C++ implicit special member functions
 def note_in_declaration_of_implicit_special_member : Note<
-  "while declaring the implicit "
-  "%select{default constructor|copy constructor|move constructor|"
-  "copy assignment operator|move assignment operator|destructor}1"
+  "while declaring the implicit %sub{select_special_member_kind}1"
   " for %0">;
 
 // C++ constructors
@@ -3837,13 +3835,7 @@
 "%select{__device__|__global__|__host__|__host__ __device__|invalid}1 function from"
   

[libcxx] r332797 - Remove expression '1L + INT_MAX', because it overflows on machines where int/long are the same size

[Marshall Clow via cfe-commits]

Author: marshall
Date: Fri May 18 20:09:05 2018
New Revision: 332797

URL: http://llvm.org/viewvc/llvm-project?rev=332797&view=rev
Log:
Remove expression '1L + INT_MAX', because it overflows on machines where 
int/long are the same size

Modified:
libcxx/trunk/test/std/containers/sequences/deque/deque.cons/deduct.pass.cpp

Modified: 
libcxx/trunk/test/std/containers/sequences/deque/deque.cons/deduct.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/sequences/deque/deque.cons/deduct.pass.cpp?rev=332797&r1=332796&r2=332797&view=diff
==
--- libcxx/trunk/test/std/containers/sequences/deque/deque.cons/deduct.pass.cpp 
(original)
+++ libcxx/trunk/test/std/containers/sequences/deque/deque.cons/deduct.pass.cpp 
Fri May 18 20:09:05 2018
@@ -43,12 +43,12 @@ int main()
 }
 
 {
-const long arr[] = {INT_MAX, 1L + INT_MAX, 2L, 3L };
+const long arr[] = {INT_MAX, 1L, 2L, 3L };
 std::deque deq(std::begin(arr), std::end(arr), std::allocator());
 static_assert(std::is_same_v, "");
 assert(deq.size() == 4);
 assert(deq[0] == INT_MAX);
-assert(deq[1] == 1L + INT_MAX);
+assert(deq[1] == 1L);
 assert(deq[2] == 2L);
 }
 


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

[PATCH] D46740: [Clang Tablegen][RFC] Allow Early Textual Substitutions in `Diagnostic` messages.

[Eric Fiselier via Phabricator via cfe-commits]

EricWF updated this revision to Diff 147640.
EricWF added a comment.

- Remove changes to Sema, and overload resolution diagnostics. Only change the 
special member function diagnostics as an example.

If there are no further comments, I'll commit this once I've run the test suite.


https://reviews.llvm.org/D46740

Files:
  docs/InternalsManual.rst
  include/clang/Basic/Diagnostic.td
  include/clang/Basic/DiagnosticSemaKinds.td
  test/SemaCXX/anonymous-struct.cpp
  test/SemaCXX/cxx98-compat.cpp
  test/TableGen/DiagnosticBase.inc
  test/TableGen/DiagnosticDocs.inc
  test/TableGen/emit-diag-docs.td
  test/TableGen/text-substitution.td
  test/lit.cfg.py
  utils/TableGen/ClangDiagnosticsEmitter.cpp

Index: utils/TableGen/ClangDiagnosticsEmitter.cpp
===
--- utils/TableGen/ClangDiagnosticsEmitter.cpp
+++ utils/TableGen/ClangDiagnosticsEmitter.cpp
@@ -14,12 +14,13 @@
 #include "llvm/ADT/DenseSet.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/PointerUnion.h"
+#include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SmallPtrSet.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/ADT/StringMap.h"
-#include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/Twine.h"
+#include "llvm/Support/Casting.h"
 #include "llvm/TableGen/Error.h"
 #include "llvm/TableGen/Record.h"
 #include "llvm/TableGen/StringToOffsetTable.h"
@@ -441,6 +442,733 @@
   }
 }
 
+namespace {
+enum PieceKind {
+  MultiPieceClass,
+  TextPieceClass,
+  PlaceholderPieceClass,
+  SelectPieceClass,
+  PluralPieceClass,
+  DiffPieceClass,
+  SubstitutionPieceClass,
+};
+
+enum ModifierType {
+  MT_Unknown,
+  MT_Placeholder,
+  MT_Select,
+  MT_Sub,
+  MT_Plural,
+  MT_Diff,
+  MT_Ordinal,
+  MT_S,
+  MT_Q,
+  MT_ObjCClass,
+  MT_ObjCInstance,
+};
+
+static StringRef getModifierName(ModifierType MT) {
+  switch (MT) {
+  case MT_Select:
+return "select";
+  case MT_Sub:
+return "sub";
+  case MT_Diff:
+return "diff";
+  case MT_Plural:
+return "plural";
+  case MT_Ordinal:
+return "ordinal";
+  case MT_S:
+return "s";
+  case MT_Q:
+return "q";
+  case MT_Placeholder:
+return "";
+  case MT_ObjCClass:
+return "objcclass";
+  case MT_ObjCInstance:
+return "objcinstance";
+  case MT_Unknown:
+llvm_unreachable("invalid modifier type");
+  }
+}
+
+struct Piece {
+  // This type and its derived classes are move-only.
+  Piece(PieceKind Kind) : ClassKind(Kind) {}
+  Piece(Piece const &O) = delete;
+  Piece &operator=(Piece const &) = delete;
+  virtual ~Piece() {}
+
+  PieceKind getPieceClass() const { return ClassKind; }
+  static bool classof(const Piece *) { return true; }
+
+private:
+  PieceKind ClassKind;
+};
+
+struct MultiPiece : Piece {
+  MultiPiece() : Piece(MultiPieceClass) {}
+  MultiPiece(std::vector Pieces)
+  : Piece(MultiPieceClass), Pieces(std::move(Pieces)) {}
+
+  std::vector Pieces;
+
+  static bool classof(const Piece *P) {
+return P->getPieceClass() == MultiPieceClass;
+  }
+};
+
+struct TextPiece : Piece {
+  StringRef Role;
+  std::string Text;
+  TextPiece(StringRef Text, StringRef Role = "")
+  : Piece(TextPieceClass), Role(Role), Text(Text.str()) {}
+
+  static bool classof(const Piece *P) {
+return P->getPieceClass() == TextPieceClass;
+  }
+};
+
+struct PlaceholderPiece : Piece {
+  ModifierType Kind;
+  int Index;
+  PlaceholderPiece(ModifierType Kind, int Index)
+  : Piece(PlaceholderPieceClass), Kind(Kind), Index(Index) {}
+
+  static bool classof(const Piece *P) {
+return P->getPieceClass() == PlaceholderPieceClass;
+  }
+};
+
+struct SelectPiece : Piece {
+protected:
+  SelectPiece(PieceKind Kind, ModifierType ModKind)
+  : Piece(Kind), ModKind(ModKind) {}
+
+public:
+  SelectPiece(ModifierType ModKind) : SelectPiece(SelectPieceClass, ModKind) {}
+
+  ModifierType ModKind;
+  std::vector Options;
+  int Index;
+
+  static bool classof(const Piece *P) {
+return P->getPieceClass() == SelectPieceClass ||
+   P->getPieceClass() == PluralPieceClass;
+  }
+};
+
+struct PluralPiece : SelectPiece {
+  PluralPiece() : SelectPiece(PluralPieceClass, MT_Plural) {}
+
+  std::vector OptionPrefixes;
+  int Index;
+
+  static bool classof(const Piece *P) {
+return P->getPieceClass() == PluralPieceClass;
+  }
+};
+
+struct DiffPiece : Piece {
+  DiffPiece() : Piece(DiffPieceClass) {}
+
+  Piece *Options[2] = {};
+  int Indexes[2] = {};
+
+  static bool classof(const Piece *P) {
+return P->getPieceClass() == DiffPieceClass;
+  }
+};
+
+struct SubstitutionPiece : Piece {
+  SubstitutionPiece() : Piece(SubstitutionPieceClass) {}
+
+  std::string Name;
+  std::vector Modifiers;
+
+  static bool classof(const Piece *P) {
+return P->getPieceClass() == SubstitutionPieceClass;
+  }
+};
+
+/// Diagnostic text, parsed into pieces.
+
+
+struct DiagnosticTextBuilder {
+  DiagnosticTextBuilder(DiagnosticTextBuilder const &) = delete;
+  DiagnosticTextBuilder &operato

[PATCH] D40218: [Clang] Add __builtin_launder

[Eric Fiselier via Phabricator via cfe-commits]

EricWF updated this revision to Diff 147639.
EricWF added a comment.

- Handle array types as requested.

- Attempt to handle incomplete class types. They are always considered in need 
of laundering. Including class templates who's instantiation hasn't been forced 
yet. @rsmith is this the correct thing to do?


https://reviews.llvm.org/D40218

Files:
  include/clang/Basic/Builtins.def
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/AST/ExprConstant.cpp
  lib/CodeGen/CGBuiltin.cpp
  lib/Sema/SemaChecking.cpp
  test/CodeGen/builtins.c
  test/CodeGenCXX/builtin-launder.cpp
  test/Preprocessor/feature_tests.c
  test/Sema/builtins.c
  test/SemaCXX/builtins.cpp

Index: test/SemaCXX/builtins.cpp
===
--- test/SemaCXX/builtins.cpp
+++ test/SemaCXX/builtins.cpp
@@ -53,3 +53,72 @@
 void synchronize_args() {
   __sync_synchronize(0); // expected-error {{too many arguments}}
 }
+
+namespace test_launder {
+
+struct Dummy {};
+
+using FnType = int(char);
+using MemFnType = int (Dummy::*)(char);
+using ConstMemFnType = int (Dummy::*)() const;
+
+void foo() {}
+
+void test_builtin_launder_diags(void *vp, const void *cvp, FnType *fnp,
+MemFnType mfp, ConstMemFnType cmfp, int (&Arr)[5]) {
+  __builtin_launder(vp);   // expected-error {{void pointer argument to '__builtin_launder' is not allowed}}
+  __builtin_launder(cvp);  // expected-error {{void pointer argument to '__builtin_launder' is not allowed}}
+  __builtin_launder(fnp);  // expected-error {{function pointer argument to '__builtin_launder' is not allowed}}
+  __builtin_launder(mfp);  // expected-error {{non-pointer argument to '__builtin_launder' is not allowed}}
+  __builtin_launder(cmfp); // expected-error {{non-pointer argument to '__builtin_launder' is not allowed}}
+  (void)__builtin_launder(&fnp);
+  __builtin_launder(42);  // expected-error {{non-pointer argument to '__builtin_launder' is not allowed}}
+  __builtin_launder(nullptr); // expected-error {{non-pointer argument to '__builtin_launder' is not allowed}}
+  __builtin_launder(foo); // expected-error {{function pointer argument to '__builtin_launder' is not allowed}}
+  (void)__builtin_launder(Arr);
+}
+
+void test_builtin_launder(char *p, const volatile int *ip, const float *&fp,
+  double *__restrict dp) {
+  int x;
+  __builtin_launder(x); // expected-error {{non-pointer argument to '__builtin_launder' is not allowed}}
+#define TEST_TYPE(Ptr, Type) \
+  static_assert(__is_same(decltype(__builtin_launder(Ptr)), Type), "expected same type")
+  TEST_TYPE(p, char*);
+  TEST_TYPE(ip, const volatile int*);
+  TEST_TYPE(fp, const float*);
+  TEST_TYPE(dp, double *__restrict);
+#undef TEST_TYPE
+  char *d = __builtin_launder(p);
+  const volatile int *id = __builtin_launder(ip);
+  int *id2 = __builtin_launder(ip); // expected-error {{cannot initialize a variable of type 'int *' with an rvalue of type 'const volatile int *'}}
+  const float* fd = __builtin_launder(fp);
+}
+
+template 
+constexpr Tp *test_constexpr_launder(Tp *tp) {
+  return __builtin_launder(tp);
+}
+constexpr int const_int = 42;
+constexpr int const_int2 = 101;
+constexpr const int *const_ptr = test_constexpr_launder(&const_int);
+static_assert(&const_int == const_ptr, "");
+static_assert(const_ptr != test_constexpr_launder(&const_int2), "");
+
+void test_non_constexpr() {
+  constexpr int i = 42;// expected-note {{declared here}}
+  constexpr const int *ip = __builtin_launder(&i); // expected-error {{constexpr variable 'ip' must be initialized by a constant expression}}
+  // expected-note@-1 {{pointer to 'i' is not a constant expression}}
+}
+
+constexpr bool test_in_constexpr(const int &i) {
+  return (__builtin_launder(&i) == &i);
+}
+static_assert(test_in_constexpr(const_int), "");
+void f() {
+  constexpr int i = 42;
+  // FIXME: Should this work? Since `&i` doesn't.
+  static_assert(test_in_constexpr(i), "");
+}
+
+} // end namespace test_launder
Index: test/Sema/builtins.c
===
--- test/Sema/builtins.c
+++ test/Sema/builtins.c
@@ -249,6 +249,24 @@
 return buf;
 }
 
+typedef void (fn_t)(int);
+
+void test_builtin_launder(char *p, void *vp, const void *cvp,
+  const volatile int *ip, float *restrict fp,
+  fn_t *fn) {
+  __builtin_launder(); // expected-error {{too few arguments to function call, expected 1, have 0}}
+  __builtin_launder(p, p); // expected-error {{too many arguments to function call, expected 1, have 2}}
+  int x;
+  __builtin_launder(x); // expected-error {{non-pointer argument to '__builtin_launder' is not allowed}}
+  char *d = __builtin_launder(p);
+  __builtin_launder(vp);  // expected-error {{void pointer argument to '__builtin_launder' is not allowed}}
+  __builtin_launder(cvp); // expected-error {{void pointer argument to '__builtin_lau

[PATCH] D47096: CodeGen: block capture shouldn't ICE

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In https://reviews.llvm.org/D47096#1105374, @jfb wrote:

> In https://reviews.llvm.org/D47096#1105368, @rjmccall wrote:
>
> > RecursiveASTVisitor instantiations are huge.  Can you just make the 
> > function take a Stmt and then do the first few checks if it happens to be 
> > an Expr?
>
>
> I'm not super-familiar with the code, so I might be doing something silly.
>
> I did something like this initially (leave the top of the function as-is, and 
> instead of cast do dyn_cast to Expr and if that fails to CompoundStmt, 
> recursively iterating all the children of the CompoundStmt). My worry was 
> that I wasn't traversing all actual children (just CompountStmt's children), 
> and AFAICT there's no easy way to say "take any Stmt, and visit its children 
> if it has such a method". I could hard-code more Stmt derivatives but that 
> seems brittle, I could use the "detection idiom" but that's silly if there's 
> already a visitor which does The Right Thing through tablegen magic.
>
> What I can do is what I did earlier, and conservatively say it was captured 
> if it's neither an Expr nor a CompoundStmt? Or should I special-case other 
> things as well?


`children()` is actually defined at the `Stmt` level, and if you look at how 
it's implemented on e.g. `IfStmt`, you can see that it visits all of the child 
`Stmt`s, including the if-condition.  So it should be fine.


Repository:
  rC Clang

https://reviews.llvm.org/D47096



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

[PATCH] D47099: Disable casting of alloca for ActiveFlag

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl created this revision.
yaxunl added a reviewer: rjmccall.

ActiveFlag is a temporary variable emitted for clean up. It is defined as 
AllocaInst* type and there is
a cast to AlllocaInst in SetActiveFlag. An alloca casted to generic pointer 
causes assertion in
SetActiveFlag.

Since there is only load/store of ActiveFlag, it is safe to use the original 
alloca, therefore disable
the cast.


https://reviews.llvm.org/D47099

Files:
  lib/CodeGen/CGCleanup.cpp
  test/CodeGenCXX/conditional-temporaries.cpp


Index: test/CodeGenCXX/conditional-temporaries.cpp
===
--- test/CodeGenCXX/conditional-temporaries.cpp
+++ test/CodeGenCXX/conditional-temporaries.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -emit-llvm %s -o - -triple=x86_64-apple-darwin9 -O3 | 
FileCheck %s
+// RUN: %clang_cc1 -emit-llvm %s -o - -triple=amdgcn-amd-amdhsa -O3 | 
FileCheck %s
 
 namespace {
 
Index: lib/CodeGen/CGCleanup.cpp
===
--- lib/CodeGen/CGCleanup.cpp
+++ lib/CodeGen/CGCleanup.cpp
@@ -284,7 +284,8 @@
 void CodeGenFunction::initFullExprCleanup() {
   // Create a variable to decide whether the cleanup needs to be run.
   Address active = CreateTempAlloca(Builder.getInt1Ty(), CharUnits::One(),
-"cleanup.cond");
+"cleanup.cond", /*ArraySize=*/nullptr,
+/*Alloca=*/nullptr, /*Cast=*/false);
 
   // Initialize it to false at a site that's guaranteed to be run
   // before each evaluation.


Index: test/CodeGenCXX/conditional-temporaries.cpp
===
--- test/CodeGenCXX/conditional-temporaries.cpp
+++ test/CodeGenCXX/conditional-temporaries.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -emit-llvm %s -o - -triple=x86_64-apple-darwin9 -O3 | FileCheck %s
+// RUN: %clang_cc1 -emit-llvm %s -o - -triple=amdgcn-amd-amdhsa -O3 | FileCheck %s
 
 namespace {
 
Index: lib/CodeGen/CGCleanup.cpp
===
--- lib/CodeGen/CGCleanup.cpp
+++ lib/CodeGen/CGCleanup.cpp
@@ -284,7 +284,8 @@
 void CodeGenFunction::initFullExprCleanup() {
   // Create a variable to decide whether the cleanup needs to be run.
   Address active = CreateTempAlloca(Builder.getInt1Ty(), CharUnits::One(),
-"cleanup.cond");
+"cleanup.cond", /*ArraySize=*/nullptr,
+/*Alloca=*/nullptr, /*Cast=*/false);
 
   // Initialize it to false at a site that's guaranteed to be run
   // before each evaluation.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47092: downgrade strong type info names to weak_odr linkage

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: test/CodeGenCXX/arm64.cpp:48
   void A::foo() {}
-  // CHECK-GLOBALS-DAG: @_ZTSN5test21AE = constant [11 x i8]
+  // CHECK-GLOBALS-DAG: @_ZTSN5test21AE = weak_odr constant [11 x i8]
   // CHECK-GLOBALS-DAG: @_ZTIN5test21AE = constant { {{.*}}, i8* getelementptr 
inbounds ([11 x i8], [11 x i8]* @_ZTSN5test21AE, i32 0, i32 0) }

rsmith wrote:
> rjmccall wrote:
> > The way the Darwin ARM64 ABI handles non-unique RTTI is by setting a flag 
> > indicating that clients should do string comparisons/hashes; it does not 
> > rely on the type name symbols being uniqued.  So this should stay external 
> > and the _ZTI definition should change to set the bit.
> OK. I was trying to avoid introducing more cases where we do string 
> comparisons, but if you prefer string comparisons over link-time 
> deduplication in all cases for that target, that seems easy enough to support.
> 
> (Out of curiosity, does the link-time deduplication not reliably work on that 
> platform? If so, how do you deal with the other cases that require 
> deduplication? If not, what's the motivation for using string comparisons?)
Static and dynamic linking work the same on ARM64 as on any other Mach-O 
platform.  As you say, there are language features that depend on symbols 
resolving to the same object; we haven't changed that.  The issue is that, 
while deduplication in the *static* linker is great, deduplication in the 
*dynamic* linker means extra, unavoidable work at load time — mostly, paging in 
a bunch of data from the symbol table.  For an implicitly-activated language 
feature like RTTI, that can add up to a lot of overhead, which hits you 
regardless of whether you actually ever use any of the language features that 
depend on it.  On Darwin we really like dynamic libraries, and we really like 
processes to launch quickly.  So the ARM64 ABI says that RTTI which would 
otherwise need to be potentially deduplicated across a dynamic-library boundary 
(because the type is external and not hidden) is instead hidden and must be 
compared using the string data — a classic load-time vs. execution-time 
trade-off, in this case easy to make because the features that depend on 
dynamic type matching are rarely used and generally slow anyway.

The GCC type_info ABI uses string comparisons for a completely different 
purpose: they assume that users can't be trusted to mark visibility correctly 
on types, so they use string comparisons as a fallback.  Darwin ARM64 is still 
as strict about type visibility as we are on every other platform, so if you 
use -fvisibility=hidden and forget to mark a type as visible, dynamic_cast and 
EH will fail across library boundaries.

It occurs to me that all this might be unnecessary, though:

1. It's never possible to ask for the `type_info` of an incomplete class type 
directly.
2. The features that use RTTI which can actually do pointer conversions don't 
allow pointers to incomplete class types, either — at best, you can have 
pointers-to-pointers.
3. As far as I know, none of those features would ever depend on the pointee 
type_info object of a pointer-to-pointer.  For example, you cannot do a 
`dynamic_cast` from a `Base**` to a `Derived**`.  They only care about the 
direct pointee type, which cannot be incomplete.
4. I think the only feature that allows a pointer to an incomplete class type 
is `typeid`.
5. None of the standard operations on a `type_info` actually cares about the 
pointee `type_info`.  They care about the name symbol for the pointer type, but 
that already has to be deduplicated (modulo the ARM64 trick) because we don't 
eagerly emit RTTI for pointer types.
6. You can get at the pointee `type_info` with the `cxxabi.h` interface, but I 
would argue that we should not make the ABI worse solely for the benefit of 
clients of the `cxxabi.h` interface, especially in a corner case of a corner 
case (a pointer to an incomplete type which would have turned out to be a 
dynamic class with a key function).
7. So I think we could actually get away with always using internal linkage for 
the ZTSes of incomplete class types, as long as we continue to use the standard 
rule for the ZTSes of *pointers* to incomplete class types, because the only 
thing that would break would be the `cxxabi.h` interface.
8. And if we find a way to convince LLVM / ASan to let us use weak linkage even 
if there might also be a strong definition out there, we don't even have that 
problem long-term.


Repository:
  rC Clang

https://reviews.llvm.org/D47092



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

[PATCH] D44239: [analyzer] Re-enable constructor inlining when lifetime extension through fields occurs.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ updated this revision to Diff 147637.
NoQ added a comment.
Herald added a subscriber: baloghadamsoftware.

Rebase.


https://reviews.llvm.org/D44239

Files:
  include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
  lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
  lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp
  test/Analysis/lifetime-extension.cpp

Index: test/Analysis/lifetime-extension.cpp
===
--- test/Analysis/lifetime-extension.cpp
+++ test/Analysis/lifetime-extension.cpp
@@ -46,10 +46,18 @@
   const int &y = A().j[1]; // no-crash
   const int &z = (A().j[1], A().j[0]); // no-crash
 
-  // FIXME: All of these should be TRUE, but constructors aren't inlined.
-  clang_analyzer_eval(x == 1); // expected-warning{{UNKNOWN}}
-  clang_analyzer_eval(y == 3); // expected-warning{{UNKNOWN}}
-  clang_analyzer_eval(z == 2); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(x == 1);
+  clang_analyzer_eval(y == 3);
+  clang_analyzer_eval(z == 2);
+#ifdef TEMPORARIES
+  // expected-warning@-4{{TRUE}}
+  // expected-warning@-4{{TRUE}}
+  // expected-warning@-4{{TRUE}}
+#else
+  // expected-warning@-8{{UNKNOWN}}
+  // expected-warning@-8{{UNKNOWN}}
+  // expected-warning@-8{{UNKNOWN}}
+#endif
 }
 } // end namespace pr19539_crash_on_destroying_an_integer
 
@@ -144,8 +152,12 @@
   {
 const bool &x = C(true, &after, &before).x; // no-crash
   }
-  // FIXME: Should be TRUE. Should not warn about garbage value.
-  clang_analyzer_eval(after == before); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval(after == before);
+#ifdef TEMPORARIES
+  // expected-warning@-2{{TRUE}}
+#else
+  // expected-warning@-4{{UNKNOWN}}
+#endif
 }
 
 struct A { // A is an aggregate.
Index: lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp
===
--- lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp
+++ lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp
@@ -695,12 +695,7 @@
   if (CallOpts.IsCtorOrDtorWithImproperlyModeledTargetRegion)
 return CIP_DisallowedOnce;
 
-  // If the temporary is lifetime-extended by binding a smaller object
-  // within it to a reference, automatic destructors don't work properly.
-  if (CallOpts.IsTemporaryLifetimeExtendedViaSubobject)
-return CIP_DisallowedOnce;
-
-  // If the temporary is lifetime-extended by binding it to a reference-typ
+  // If the temporary is lifetime-extended by binding it to a reference-type
   // field within an aggregate, automatic destructors don't work properly.
   if (CallOpts.IsTemporaryLifetimeExtendedViaAggregate)
 return CIP_DisallowedOnce;
Index: lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
===
--- lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
+++ lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
@@ -182,22 +182,13 @@
   const auto *TOCC = cast(CC);
   if (const auto *MTE = TOCC->getMaterializedTemporaryExpr()) {
 if (const ValueDecl *VD = MTE->getExtendingDecl()) {
-  // Pattern-match various forms of lifetime extension that aren't
-  // currently supported by the CFG.
-  // FIXME: Is there a better way to retrieve this information from
-  // the MaterializeTemporaryExpr?
   assert(MTE->getStorageDuration() != SD_FullExpression);
-  if (VD->getType()->isReferenceType()) {
-assert(VD->getType()->isReferenceType());
-if (VD->getType()->getPointeeType().getCanonicalType() !=
-MTE->GetTemporaryExpr()->getType().getCanonicalType()) {
-  // We're lifetime-extended via our field. Automatic destructors
-  // aren't quite working in this case.
-  CallOpts.IsTemporaryLifetimeExtendedViaSubobject = true;
-}
-  } else {
+  if (!VD->getType()->isReferenceType()) {
 // We're lifetime-extended by a surrounding aggregate.
-// Automatic destructors aren't quite working in this case.
+// Automatic destructors aren't quite working in this case
+// on the CFG side. We should warn the caller about that.
+// FIXME: Is there a better way to retrieve this information from
+// the MaterializeTemporaryExpr?
 CallOpts.IsTemporaryLifetimeExtendedViaAggregate = true;
   }
 }
Index: include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
===
--- include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
+++ include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
@@ -106,11 +106,6 @@
 bool IsTemporaryCtorOrDtor = false;
 
 /// This call is a constructor for a temporary that is lifetime-extended
-/// by binding a smaller object within it to a reference, for example
-/// 'const int &x = C().x;'.
-bool Is

[PATCH] D47007: [analyzer] CStringChecker fix for strlcpy when no bytes are copied to the dest buffer

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

@devnexen I think you should request commit access. You're already an active 
contributor :)


Repository:
  rC Clang

https://reviews.llvm.org/D47007



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

[PATCH] D44238: [CFG] Fix automatic destructors when a member is bound to a reference.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ updated this revision to Diff 147635.
NoQ added a comment.

Switch to `skipRValueSubobjectAdjustments`. Yup, that's much better.

Add FIXME tests for lifetime extension through non-references that are still 
not working - that correspond to a nearby FIXME in the code. I'm not planning 
to fix them immediately, but it's nice to know what else isn't working in this 
realm.


https://reviews.llvm.org/D44238

Files:
  lib/Analysis/CFG.cpp
  test/Analysis/auto-obj-dtors-cfg-output.cpp

Index: test/Analysis/auto-obj-dtors-cfg-output.cpp
===
--- test/Analysis/auto-obj-dtors-cfg-output.cpp
+++ test/Analysis/auto-obj-dtors-cfg-output.cpp
@@ -1,7 +1,11 @@
-// RUN: %clang_analyze_cc1 -fcxx-exceptions -fexceptions -analyzer-checker=debug.DumpCFG -analyzer-config cfg-rich-constructors=false %s > %t 2>&1
-// RUN: FileCheck --input-file=%t -check-prefixes=CHECK,WARNINGS %s
-// RUN: %clang_analyze_cc1 -fcxx-exceptions -fexceptions -analyzer-checker=debug.DumpCFG -analyzer-config cfg-rich-constructors=true %s > %t 2>&1
-// RUN: FileCheck --input-file=%t -check-prefixes=CHECK,ANALYZER %s
+// RUN: %clang_analyze_cc1 -std=c++98 -fcxx-exceptions -fexceptions -analyzer-checker=debug.DumpCFG -analyzer-config cfg-rich-constructors=false %s > %t 2>&1
+// RUN: FileCheck --input-file=%t -check-prefixes=CHECK,CXX98,WARNINGS,CXX98-WARNINGS %s
+// RUN: %clang_analyze_cc1 -std=c++98 -fcxx-exceptions -fexceptions -analyzer-checker=debug.DumpCFG -analyzer-config cfg-rich-constructors=true %s > %t 2>&1
+// RUN: FileCheck --input-file=%t -check-prefixes=CHECK,CXX98,ANALYZER,CXX98-ANALYZER %s
+// RUN: %clang_analyze_cc1 -std=c++11 -fcxx-exceptions -fexceptions -analyzer-checker=debug.DumpCFG -analyzer-config cfg-rich-constructors=false %s > %t 2>&1
+// RUN: FileCheck --input-file=%t -check-prefixes=CHECK,CXX11,WARNINGS,CXX11-WARNINGS %s
+// RUN: %clang_analyze_cc1 -std=c++11 -fcxx-exceptions -fexceptions -analyzer-checker=debug.DumpCFG -analyzer-config cfg-rich-constructors=true %s > %t 2>&1
+// RUN: FileCheck --input-file=%t -check-prefixes=CHECK,CXX11,ANALYZER,CXX11-ANALYZER %s
 
 // This file tests how we construct two different flavors of the Clang CFG -
 // the CFG used by the Sema analysis-based warnings and the CFG used by the
@@ -14,6 +18,8 @@
 
 class A {
 public:
+  int x;
+
 // CHECK:  [B1 (ENTRY)]
 // CHECK-NEXT:   Succs (1): B0
 // CHECK:  [B0 (EXIT)]
@@ -70,6 +76,287 @@
 // CHECK:  [B2 (ENTRY)]
 // CHECK-NEXT:   Succs (1): B1
 // CHECK:  [B1]
+// WARNINGS-NEXT:   1: A() (CXXConstructExpr, class A)
+// CXX98-ANALYZER-NEXT:   1: A() (CXXConstructExpr, [B1.2], class A)
+// CXX11-ANALYZER-NEXT:   1: A() (CXXConstructExpr, [B1.2], [B1.3], class A)
+// CHECK-NEXT:   2: [B1.1] (BindTemporary)
+// CXX98-NEXT:   3: [B1.2].x
+// CXX98-NEXT:   4: [B1.3]
+// CXX98-NEXT:   5: const int &x = A().x;
+// CXX98-NEXT:   6: [B1.5].~A() (Implicit destructor)
+// CXX11-NEXT:   3: [B1.2]
+// CXX11-NEXT:   4: [B1.3].x
+// CXX11-NEXT:   5: [B1.4] (ImplicitCastExpr, NoOp, const int)
+// CXX11-NEXT:   6: const int &x = A().x;
+// CXX11-NEXT:   7: [B1.6].~A() (Implicit destructor)
+// CHECK-NEXT:   Preds (1): B2
+// CHECK-NEXT:   Succs (1): B0
+// CHECK:  [B0 (EXIT)]
+// CHECK-NEXT:   Preds (1): B1
+void test_const_ref_to_field() {
+  const int &x = A().x;
+}
+
+// CHECK:[B2 (ENTRY)]
+// CHECK-NEXT: Succs (1): B1
+// CHECK:[B1]
+// WARNINGS-NEXT: 1: A() (CXXConstructExpr, class A)
+// CXX98-ANALYZER-NEXT: 1: A() (CXXConstructExpr, [B1.2], class A)
+// CXX11-ANALYZER-NEXT: 1: A() (CXXConstructExpr, [B1.2], [B1.3], class A)
+// CHECK-NEXT: 2: [B1.1] (BindTemporary)
+// CXX98-NEXT: 3: A::x
+// CXX98-NEXT: 4: &[B1.3]
+// CXX98-NEXT: 5: [B1.2] .* [B1.4]
+// CXX98-NEXT: 6: [B1.5]
+// CXX98-NEXT: 7: const int &x = A() .* &A::x;
+// CXX98-NEXT: 8: [B1.7].~A() (Implicit destructor)
+// CXX11-NEXT: 3: [B1.2]
+// CXX11-NEXT: 4: A::x
+// CXX11-NEXT: 5: &[B1.4]
+// CXX11-NEXT: 6: [B1.3] .* [B1.5]
+// CXX11-NEXT: 7: [B1.6] (ImplicitCastExpr, NoOp, const int)
+// CXX11-NEXT: 8: const int &x = A() .* &A::x;
+// CXX11-NEXT: 9: [B1.8].~A() (Implicit destructor)
+// CHECK-NEXT: Preds (1): B2
+// CHECK-NEXT: Succs (1): B0
+// CHECK:[B0 (EXIT)]
+// CHECK-NEXT: Preds (1): B1
+void test_pointer_to_member() {
+  const int &x = A().*&A::x;
+}
+
+// FIXME: There should be automatic destructors at the end of scope.
+// CHECK:[B2 (ENTRY)]
+// CHECK-NEXT: Succs (1): B1
+// CHECK:[B1]
+// WARNINGS-NEXT: 1: A() (CXXConstructExpr, class A)
+// ANALYZER-NEXT: 1: A() (CXXConstructExpr, [B1.2], [B1.4], class A)
+// CHECK-NEXT: 2: [B1.1] (BindTemporary)
+// CHECK-NEXT: 3: [B1.2] (ImplicitCastExpr, NoOp, const class A)
+// CHECK-NEXT: 4: [B1.3]
+// CHECK-NEXT: 5: {[B1.4]}
+// CHECK-NEXT: 6: B b = {A()};
+// WARNINGS-NEXT: 7: A() (CXXConstructExpr,

[PATCH] D47044: [analyzer] Ensure that we only visit a destructor for a reference if type information is available.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

Hmm, well, i guess it's not going to be a one-liner. You might have to iterate 
through all live variables in the scope, see if they are references, and add 
the trait. I think currently there's no way around scanning the current 
function body (i.e. `LCtx->getDecl()`, where `LCtx` is 
`Pred->getLocationContext()`) an AST visitor or an AST matcher. Once that's 
done, you can take `Pred->getState()->getLValue(VD, LCtx)` for every `const 
VarDecl *` `VD` you find and set the invalidation trait on that. It might be 
necessary to restrict your search to active variables (in the sense of 
`LCtx->getAnalysis()->isLive(S, VD)`), where `S` is... 
dunno, some statement that makes sense here.

Probably global/static references should also not be invalidated. It'd take 
even more effort to find those.

I still think it's worth it because widening is indeed at fault, not the common 
destructor handling code. The assertion you step upon (that the `cast<>` always 
succeeds) is a valuable assertion that helped us find that bug, we shouldn't 
suppress it.

Loop widening in its current form is an experiment that was never announced to 
work, and, well, yeah, it has this sort of bugs. There is work started by 
@szepet in https://reviews.llvm.org/D36690 to turn widening into a 
whitelist-like thing.


Repository:
  rC Clang

https://reviews.llvm.org/D47044



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

[PATCH] D46917: [Fixed Point Arithmetic] Comparison and Unary Operations for Fixed Point Types

[Leonard Chan via Phabricator via cfe-commits]

leonardchan updated this revision to Diff 147631.
leonardchan added a comment.

formatting


Repository:
  rC Clang

https://reviews.llvm.org/D46917

Files:
  lib/CodeGen/CGExprScalar.cpp
  lib/Sema/SemaExpr.cpp
  test/Frontend/fixed_point_declarations.c
  test/Frontend/fixed_point_validation.c

Index: test/Frontend/fixed_point_validation.c
===
--- test/Frontend/fixed_point_validation.c
+++ test/Frontend/fixed_point_validation.c
@@ -1,19 +1,170 @@
+// RUN: %clang -S -emit-llvm %s -o - | FileCheck %s
 // RUN: %clang_cc1 -S -emit-llvm -o - %s | lli
 
+// The first test checks the emitted llvm IR.
+// The second test checks the output.
+// Both these test require that the default bit widths for the fixed point types
+// are used since we check for bit shifted literals that were converted from
+// ints and floats.
+
+// Primary fixed point types
+signed short _Accum s_short_accum;// CHECK-DAG: @s_short_accum =  common dso_local global i16 0, align 2
+signed _Accum s_accum;// CHECK-DAG: @s_accum =common dso_local global i32 0, align 4
+signed long _Accum s_long_accum;  // CHECK-DAG: @s_long_accum =   common dso_local global i64 0, align 8
+unsigned short _Accum u_short_accum;  // CHECK-DAG: @u_short_accum =  common dso_local global i16 0, align 2
+unsigned _Accum u_accum;  // CHECK-DAG: @u_accum =common dso_local global i32 0, align 4
+unsigned long _Accum u_long_accum;// CHECK-DAG: @u_long_accum =   common dso_local global i64 0, align 8
+signed short _Fract s_short_fract;// CHECK-DAG: @s_short_fract =  common dso_local global i16 0, align 2
+signed _Fract s_fract;// CHECK-DAG: @s_fract =common dso_local global i32 0, align 4
+signed long _Fract s_long_fract;  // CHECK-DAG: @s_long_fract =   common dso_local global i64 0, align 8
+unsigned short _Fract u_short_fract;  // CHECK-DAG: @u_short_fract =  common dso_local global i16 0, align 2
+unsigned _Fract u_fract;  // CHECK-DAG: @u_fract =common dso_local global i32 0, align 4
+unsigned long _Fract u_long_fract;// CHECK-DAG: @u_long_fract =   common dso_local global i64 0, align 8
+
+// There are 7 bits allocated to the fractional part and 8
+// bits allocated to the integral part of a short _Accum by default.
+
+signed short _Accum s_short_accum2 = 2.5hk;  // CHECK-DAG: @s_short_accum2 = dso_local global i16 320, align 2
+short _Fract short_fract = 0.333hr;  // CHECK-DAG: @short_fract = dso_local global i16 42, align 2
+
 // Run simple validation tests
 
 #define assert(b) if (!(b)) { return 1; }
 
 int main(){
-  short _Accum s_accum;
+  short _Accum s_accum = 0.0hk;
   short _Accum s_accum2 = 2.0hk;
   short _Fract s_fract = 0.999hr;
   short _Fract s_fract2 = -0.999hr;
+  const _Fract fract_zero = 0.0r;
+  // CHECK:  %s_accum = alloca i16, align 2
+  // CHECK:  %s_accum2 = alloca i16, align 2
+  // CHECK:  %s_fract = alloca i16, align 2
+  // CHECK:  %s_fract2 = alloca i16, align 2
+  // CHECK:  %fract_zero = alloca i32, align 4
+  // CHECK:  store i16 0, i16* %s_accum, align 2
+  // CHECK:  store i16 256, i16* %s_accum2, align 2
+  // CHECK:  store i16 127, i16* %s_fract, align 2
+  // CHECK:  store i16 -127, i16* %s_fract2, align 2
+  // CHECK:  store i32 0, i32* %fract_zero, align 4
+
+  / Simple Comparisons ***/
 
   assert(s_accum == 0);
+  // CHECK:  {{.*}} = load i16, i16* %s_accum, align 2
+  // CHECK-NEXT: {{.*}} = icmp eq i16 {{.*}}, 0
 
   s_accum = s_accum2;
+  // CHECK:  {{.*}} = load i16, i16* %s_accum2, align 2
+  // CHECK-NEXT: store i16 %1, i16* %s_accum, align 2
 
   assert(s_accum == s_accum2);
+  // CHECK:  {{.*}} = load i16, i16* %s_accum, align 2
+  // CHECK-NEXT: {{.*}} = load i16, i16* %s_accum2, align 2
+  // CHECK-NEXT: {{.*}} = icmp eq i16 {{.*}}, {{.*}}
+
+  assert(s_accum2 == s_accum);
+  // CHECK:  {{.*}} = load i16, i16* %s_accum2, align 2
+  // CHECK-NEXT: {{.*}} = load i16, i16* %s_accum, align 2
+  // CHECK-NEXT: {{.*}} = icmp eq i16 {{.*}}, {{.*}}
+
   assert(s_accum == 2);
+  // CHECK:  {{.*}} = icmp eq i16 {{.*}}, 256
+
+  assert(2 == s_accum);
+  // CHECK:  {{.*}} = icmp eq i16 256, {{.*}}
+
+  int x = 2;
+  assert(s_accum == x);
+  // CHECK:  {{.*}} = load i32, i32* %x, align 4
+  // CHECK-NEXT: {{.*}} = trunc i32 {{.*}} to i16
+  // CHECK-NEXT: {{.*}} = shl i16 {{.*}}, 7
+  // CHECK-NEXT: {{.*}} = icmp eq i16 {{.*}}, {{.*}}
+
+  assert(x == s_accum);
+
+  assert(s_accum != -2);
+  // CHECK:  {{.*}} = icmp ne i16 {{.*}}, -256
+
+  assert(-2 != s_accum);
+  // CHECK:  {{.*}} = icmp ne i16 -256, {{.*}}
+
+  assert(s_accum != -x);
+  assert(-x != s_accum);
+
+  assert(s_fract != 1);
+  // CHECK:  {{.*}} = load i16, i16* %s_fract, align 2
+  // CHECK_NEXT: {{.*}} = icmp ne i16 {{.*}}, 128
+
+  assert(s_fract2 != -1);
+  // CHECK:  {

[PATCH] D46740: [Clang Tablegen][RFC] Allow Early Textual Substitutions in `Diagnostic` messages.

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

rsmith added a comment.

In https://reviews.llvm.org/D46740#1105063, @EricWF wrote:

> Any final comments on this?


I would ideally like to see one substitution added, and one set of diagnostics 
converted, as part of this patch, and for other diagnostics to be converted in 
separate changes after that. Please pick one that doesn't also require changes 
to Sema, so this patch is separate from the refactoring of the Sema diagnostic 
emission.


https://reviews.llvm.org/D46740



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

[PATCH] D47097: [WIP][DebugInfo] Preserve scope in auto generated StoreInst

[Anastasis via Phabricator via cfe-commits]

gramanas created this revision.
gramanas added a reviewer: vsk.
Herald added subscribers: JDevlieghere, aprantl.

In this test there is a store instruction generated by clang
for the function argument `int b` where the debug info is missing.

The goal of this patch is to instruct clang to add an artificial
location to auto generated store instructions using
ApplyDebugLocation::CreateArtificial() so that we can
preserve the scope information of the dbg metadata.


Repository:
  rC Clang

https://reviews.llvm.org/D47097

Files:
  test/CodeGen/debug-info-preserve-scope.c


Index: test/CodeGen/debug-info-preserve-scope.c
===
--- /dev/null
+++ test/CodeGen/debug-info-preserve-scope.c
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -O0 -debug-info-kind=limited -emit-llvm -o - %s | FileCheck 
%s
+
+static int a;
+
+// CHECK-LABEL: define void @f
+void f(int b) {
+  a = b;
+}
+
+// CHECK: store i32 %b, i32* %b.addr, align 4, !dbg ![[dbgLocForStore:[0-9]+]]
+


Index: test/CodeGen/debug-info-preserve-scope.c
===
--- /dev/null
+++ test/CodeGen/debug-info-preserve-scope.c
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -O0 -debug-info-kind=limited -emit-llvm -o - %s | FileCheck %s
+
+static int a;
+
+// CHECK-LABEL: define void @f
+void f(int b) {
+  a = b;
+}
+
+// CHECK: store i32 %b, i32* %b.addr, align 4, !dbg ![[dbgLocForStore:[0-9]+]]
+
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47090: Implement C++17 .

[Arthur O'Dwyer via Phabricator via cfe-commits]

Quuxplusone added a comment.

> I would prefer if we completed  (according to 
> the current standard, not the LFTS spec), and then moved it.
>  Would you be willing to do that instead?

Let me see if I understand. libc++'s `` differs 
from C++17 `` in at least these ways:
(A) It's missing `monotonic_buffer_resource` and 
`{un,}synchronized_pool_resource`
(B) It's got different semantics around uses-allocator construction because of 
https://wg21.link/lwg2969
(C) It's got a different header name

This patch is basically proposing to fix things in the order C-A-B (and fix C 
by making copies of everything); you're proposing to fix things in the order 
A-B-C (and fix C by moving everything).

I have no objection to fixing A in `` if people 
think that'd be useful. I didn't do that in this patch simply because I'd 
observed other `` headers already getting replaced with 
`#error` messages, and it seemed like any further work on the 
`` headers would have been wasted.

I don't know who's using `` today, but in theory 
I worry that fixing B in `` (before doing C) 
might actually break someone's code.

Philosophically as I understand it LWG2969 was a patch against C++17, not a 
patch against the TS. If LWG2969 (and incidentally I asked lwgchair to open a 
new issue for https://github.com/Quuxplusone/libcxx/commit/54e1a59a ) are 
actually supposed to be patches against *both* C++17 *and* the TS, then cool, 
yeah, we should fix B in ``. Thoughts?


Repository:
  rCXX libc++

https://reviews.llvm.org/D47090



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

[PATCH] D45015: [Preprocessor] Allow libc++ to detect when aligned allocation is unavailable.

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

rsmith added a comment.

In https://reviews.llvm.org/D45015#1105372, @vsapsai wrote:

> What when compiler has `__builtin_operator_new`, `__builtin_operator_delete`? 
> If I build libc++ tests with recent Clang which has these builtins and run 
> tests with libc++.dylib from old Darwin, there are no linkage errors. Should 
> we define `__cpp_aligned_allocation` in this case?


I don't see why that should make any difference -- those builtins call the same 
functions that the new and delete operator call. Perhaps libc++ isn't calling 
the forms of those builtins that take an alignment argument yet?


Repository:
  rC Clang

https://reviews.llvm.org/D45015



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

[PATCH] D47092: downgrade strong type info names to weak_odr linkage

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

rsmith added a comment.

In https://reviews.llvm.org/D47092#1105315, @efriedma wrote:

> I'm pretty sure this isn't actually a violation of LLVM's linkage rules as 
> they are described in LangRef... at least, my understanding is that 
> "equivalent" doesn't imply anything about linkage.  (If this should be a 
> violation, we need to clarify the rules.)


This is a fair point. (Though I would note that the LangRef doesn't even say 
that you can't have two external definitions of the same symbol, so it would 
clearly benefit from some clarification in this area.)

We could certainly teach ASan to just ignore "odr violations" on type info 
names, if we think that the IR generated here is in fact correct.

If we go down that path, do we still need changes for the Darwin ARM64 case? 
(That is, is it OK to emit some `weak_odr` definitions along with an `external` 
definition for the same `_ZTS` symbol, and not use the 'non-unique type info 
name' flag? Or should we still be treating that case -- and, as a consequence, 
//all// external-linkage `_ZTS` symbols for classes -- as non-unique?)




Comment at: test/CodeGenCXX/arm64.cpp:48
   void A::foo() {}
-  // CHECK-GLOBALS-DAG: @_ZTSN5test21AE = constant [11 x i8]
+  // CHECK-GLOBALS-DAG: @_ZTSN5test21AE = weak_odr constant [11 x i8]
   // CHECK-GLOBALS-DAG: @_ZTIN5test21AE = constant { {{.*}}, i8* getelementptr 
inbounds ([11 x i8], [11 x i8]* @_ZTSN5test21AE, i32 0, i32 0) }

rjmccall wrote:
> The way the Darwin ARM64 ABI handles non-unique RTTI is by setting a flag 
> indicating that clients should do string comparisons/hashes; it does not rely 
> on the type name symbols being uniqued.  So this should stay external and the 
> _ZTI definition should change to set the bit.
OK. I was trying to avoid introducing more cases where we do string 
comparisons, but if you prefer string comparisons over link-time deduplication 
in all cases for that target, that seems easy enough to support.

(Out of curiosity, does the link-time deduplication not reliably work on that 
platform? If so, how do you deal with the other cases that require 
deduplication? If not, what's the motivation for using string comparisons?)



Comment at: test/CodeGenCXX/windows-itanium-type-info.cpp:31
 // CHECK-DAG: @_ZTI7derived = dso_local dllexport constant
-// CHECK-DAG: @_ZTS7derived = dso_local dllexport constant
+// CHECK-DAG: @_ZTS7derived = weak_odr dso_local dllexport constant
 // CHECK-DAG: @_ZTV7derived = dso_local dllexport unnamed_addr constant

rjmccall wrote:
> Is this actually okay?  I didn't think dllexport supported weak symbols.
Good question, I don't know. Do we have some way to specify "weak_odr within 
this DSO but strong at the DSO boundary"? I suppose a COMDAT would give that 
effect.


Repository:
  rC Clang

https://reviews.llvm.org/D47092



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

[PATCH] D47096: CodeGen: block capture shouldn't ICE

[JF Bastien via Phabricator via cfe-commits]

jfb added a comment.

In https://reviews.llvm.org/D47096#1105368, @rjmccall wrote:

> RecursiveASTVisitor instantiations are huge.  Can you just make the function 
> take a Stmt and then do the first few checks if it happens to be an Expr?


I'm not super-familiar with the code, so I might be doing something silly.

I did something like this initially (leave the top of the function as-is, and 
instead of cast do dyn_cast to Expr and if that fails to CompoundStmt, 
recursively iterating all the children of the CompoundStmt). My worry was that 
I wasn't traversing all actual children (just CompountStmt's children), and 
AFAICT there's no easy way to say "take any Stmt, and visit its children if it 
has such a method". I could hard-code more Stmt derivatives but that seems 
brittle, I could use the "detection idiom" but that's silly if there's already 
a visitor which does The Right Thing through tablegen magic.

What I can do is what I did earlier, and conservatively say it was captured if 
it's neither an Expr nor a CompoundStmt? Or should I special-case other things 
as well?


Repository:
  rC Clang

https://reviews.llvm.org/D47096



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

[PATCH] D47090: Implement C++17 .

[Eric Fiselier via Phabricator via cfe-commits]

EricWF added a comment.

I would prefer if we completed `` (according to 
the current standard, not the LFTS spec), and then moved it.

Would you be willing to do that instead?


Repository:
  rCXX libc++

https://reviews.llvm.org/D47090



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

[libcxx] r332785 - Implement deduction guides for

[Marshall Clow via cfe-commits]

Author: marshall
Date: Fri May 18 16:44:13 2018
New Revision: 332785

URL: http://llvm.org/viewvc/llvm-project?rev=332785&view=rev
Log:
Implement deduction guides for 

Added:
libcxx/trunk/test/std/containers/sequences/deque/deque.cons/deduct.fail.cpp
libcxx/trunk/test/std/containers/sequences/deque/deque.cons/deduct.pass.cpp
Modified:
libcxx/trunk/include/deque

Modified: libcxx/trunk/include/deque
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/deque?rev=332785&r1=332784&r2=332785&view=diff
==
--- libcxx/trunk/include/deque (original)
+++ libcxx/trunk/include/deque Fri May 18 16:44:13 2018
@@ -128,6 +128,10 @@ public:
 void clear() noexcept;
 };
 
+template ::value_type>>
+   deque(InputIterator, InputIterator, Allocator = Allocator())
+   -> deque::value_type, Allocator>;
+
 template 
 bool operator==(const deque& x, const deque& y);
 template 
@@ -921,13 +925,14 @@ class __deque_base
 {
 __deque_base(const __deque_base& __c);
 __deque_base& operator=(const __deque_base& __c);
-protected:
-typedef _Tp  value_type;
+public:
 typedef _Allocator   allocator_type;
 typedef allocator_traits __alloc_traits;
+typedef typename __alloc_traits::size_type   size_type;
+protected:
+typedef _Tp  value_type;
 typedef value_type&  reference;
 typedef const value_type&const_reference;
-typedef typename __alloc_traits::size_type   size_type;
 typedef typename __alloc_traits::difference_type difference_type;
 typedef typename __alloc_traits::pointer pointer;
 typedef typename __alloc_traits::const_pointer   const_pointer;
@@ -946,6 +951,7 @@ protected:
 typedef __deque_iteratorconst_iterator;
 
+protected:
 __map __map_;
 size_type __start_;
 __compressed_pair __size_;
@@ -1461,6 +1467,23 @@ private:
 void __move_assign(deque& __c, false_type);
 };
 
+#ifndef _LIBCPP_HAS_NO_DEDUCTION_GUIDES
+template::value_type>,
+ class = typename enable_if<__is_allocator<_Alloc>::value, void>::type
+ >
+deque(_InputIterator, _InputIterator)
+  -> deque::value_type, _Alloc>;
+
+template::value, void>::type
+ >
+deque(_InputIterator, _InputIterator, _Alloc)
+  -> deque::value_type, _Alloc>;
+#endif
+
+
 template 
 deque<_Tp, _Allocator>::deque(size_type __n)
 {

Added: 
libcxx/trunk/test/std/containers/sequences/deque/deque.cons/deduct.fail.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/sequences/deque/deque.cons/deduct.fail.cpp?rev=332785&view=auto
==
--- libcxx/trunk/test/std/containers/sequences/deque/deque.cons/deduct.fail.cpp 
(added)
+++ libcxx/trunk/test/std/containers/sequences/deque/deque.cons/deduct.fail.cpp 
Fri May 18 16:44:13 2018
@@ -0,0 +1,42 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// 
+// UNSUPPORTED: c++98, c++03, c++11, c++14
+// UNSUPPORTED: libcpp-no-deduction-guides
+
+
+// template ::value_type>>
+//deque(InputIterator, InputIterator, Allocator = Allocator())
+//-> deque::value_type, Allocator>;
+//
+
+
+#include 
+#include 
+#include 
+#include 
+#include  // INT_MAX
+
+struct A {};
+
+int main()
+{  
+//  Test the explicit deduction guides
+
+//  Test the implicit deduction guides
+{
+//  deque (allocator &)
+std::deque deq((std::allocator()));  // expected-error {{no viable 
constructor or deduction guide for deduction of template arguments of 'deque'}}
+//  Note: The extra parens are necessary, since otherwise clang decides it is 
a function declaration.
+//  Also, we can't use {} instead of parens, because that constructs a
+//  deque, allocator>>
+}
+
+}

Added: 
libcxx/trunk/test/std/containers/sequences/deque/deque.cons/deduct.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/sequences/deque/deque.cons/deduct.pass.cpp?rev=332785&view=auto
==
--- libcxx/trunk/test/std/containers/sequences/deque/deque.cons/deduct.pass.cpp 
(added)
+++ libcxx/trunk/test/std/containers/sequences/deque/deque.cons/deduct.pass.cpp 
Fri May 18 16:44:13 2018
@@ -0,0 +1,98 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinoi

[PATCH] D45015: [Preprocessor] Allow libc++ to detect when aligned allocation is unavailable.

[Volodymyr Sapsai via Phabricator via cfe-commits]

vsapsai added a comment.

In https://reviews.llvm.org/D45015#1105314, @rsmith wrote:

> That is: on old Darwin, we should not define `__cpp_aligned_allocation` (even 
> in C++17), produce the "no aligned allocation support" warning in C++17 mode, 
> and then not try to call the aligned allocation function. But if 
> `-faligned-allocation` or `-fno-aligned-allocation` is specified explicitly, 
> then the user knows what they're doing and they get no warning.


What when compiler has `__builtin_operator_new`, `__builtin_operator_delete`? 
If I build libc++ tests with recent Clang which has these builtins and run 
tests with libc++.dylib from old Darwin, there are no linkage errors. Should we 
define `__cpp_aligned_allocation` in this case?


Repository:
  rC Clang

https://reviews.llvm.org/D45015



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

[PATCH] D47096: CodeGen: block capture shouldn't ICE

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

RecursiveASTVisitor instantiations are huge.  Can you just make the function 
take a Stmt and then do the first few checks if it happens to be an Expr?


Repository:
  rC Clang

https://reviews.llvm.org/D47096



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

[PATCH] D47044: [analyzer] Ensure that we only visit a destructor for a reference if type information is available.

[Matthew Voss via Phabricator via cfe-commits]

ormris added a comment.

This is my first static analyzer fix, so it may take me some time to figure 
this out.


Repository:
  rC Clang

https://reviews.llvm.org/D47044



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

[PATCH] D46472: [HIP] Support offloading by linker script

[Peter Collingbourne via Phabricator via cfe-commits]

pcc added inline comments.



Comment at: cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp:1371-1388
+  // machines.
+  LksStream << "/*\n";
+  LksStream << "   HIP Offload Linker Script\n";
+  LksStream << " *** Automatically generated by Clang ***\n";
+  LksStream << "*/\n";
+  LksStream << "TARGET(binary)\n";
+  LksStream << "INPUT(" << BundleFileName << ")\n";

tra wrote:
> Using this linker script may present a problem.
> 
> INSERT BEFORE is not going to work with ld.gold.
> https://sourceware.org/bugzilla/show_bug.cgi?id=15373
> 
> LLD also does not handle it particularly well -- INSERT BEFORE can only be 
> used to override explicitly specified external linker script and virtually 
> nobody uses linker scripts with LLD.
> See tests in https://reviews.llvm.org/D44380
> 
If you're just trying to embed a file it may be better to use MC to write an 
ELF with something like:
```
.section .hip_fatbin
.align 16
.globl __hip_fatbin
__hip_fatbin:
.incbin "BundleFileName"
```
and add that to the link.


Repository:
  rL LLVM

https://reviews.llvm.org/D46472



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

[PATCH] D46982: Do not enable RTTI with -fexceptions, for PS4

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL332784: Do not enable RTTI with -fexceptions, for PS4 
(authored by ssrivastava, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D46982?vs=147196&id=147616#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D46982

Files:
  cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
  cfe/trunk/include/clang/Driver/ToolChain.h
  cfe/trunk/lib/Driver/SanitizerArgs.cpp
  cfe/trunk/lib/Driver/ToolChain.cpp
  cfe/trunk/lib/Driver/ToolChains/Clang.cpp
  cfe/trunk/test/Driver/rtti-options.cpp

Index: cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
===
--- cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
+++ cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
@@ -266,9 +266,6 @@
   InGroup>;
 def warn_debug_compression_unavailable : Warning<"cannot compress debug sections (zlib not installed)">,
   InGroup>;
-def warn_drv_enabling_rtti_with_exceptions : Warning<
-  "implicitly enabling rtti for exception handling">,
-  InGroup>;
 def warn_drv_disabling_vptr_no_rtti_default : Warning<
   "implicitly disabling vptr sanitizer because rtti wasn't enabled">,
   InGroup;
Index: cfe/trunk/include/clang/Driver/ToolChain.h
===
--- cfe/trunk/include/clang/Driver/ToolChain.h
+++ cfe/trunk/include/clang/Driver/ToolChain.h
@@ -100,10 +100,8 @@
   };
 
   enum RTTIMode {
-RM_EnabledExplicitly,
-RM_EnabledImplicitly,
-RM_DisabledExplicitly,
-RM_DisabledImplicitly
+RM_Enabled,
+RM_Disabled,
   };
 
 private:
Index: cfe/trunk/test/Driver/rtti-options.cpp
===
--- cfe/trunk/test/Driver/rtti-options.cpp
+++ cfe/trunk/test/Driver/rtti-options.cpp
@@ -1,11 +1,11 @@
 // Check that we emit warnings/errors for different combinations of
-// exceptions, rtti, and vptr sanitizer flags when targeting the PS4.
+// exceptions, rtti, and vptr sanitizer flags for generic (unknown) x86 linux,
+// and for PS4 when its behaviour differs from the generic x86-linux.
 // No warnings/errors should be emitted for unknown, except if combining
 // the vptr sanitizer with -fno-rtti
 
 // Special cases: -fcxx-exceptions in C code should warn about unused arguments
 // We should also not have any rtti-related arguments
-// RUN: %clang -x c -### -target x86_64-scei-ps4 -c -fcxx-exceptions %s 2>&1 | FileCheck -check-prefix=CHECK-UNUSED -check-prefix=CHECK-RTTI %s
 // RUN: %clang -x c -### -target x86_64-unknown-unknown -c -fcxx-exceptions %s 2>&1 | FileCheck -check-prefix=CHECK-UNUSED -check-prefix=CHECK-RTTI %s
 
 // Make sure we keep the last -frtti/-fno-rtti argument
@@ -22,39 +22,26 @@
 // RUN: %clang -### -c -target x86_64-unknown-linux -fsanitize=undefined %s 2>&1 | FileCheck -check-prefix=CHECK-OK %s
 // RUN: %clang -### -c -target x86_64-unknown-linux -fsanitize=undefined -frtti %s 2>&1 | FileCheck -check-prefix=CHECK-OK %s
 // RUN: %clang -### -c -target x86_64-scei-ps4 -fsanitize=vptr %s 2>&1 | FileCheck -check-prefix=CHECK-SAN-WARN %s
-// RUN: %clang -### -c -target x86_64-scei-ps4 -fsanitize=vptr -frtti %s 2>&1 | FileCheck -check-prefix=CHECK-OK %s
-// RUN: %clang -### -c -target x86_64-scei-ps4 -fsanitize=vptr -fno-rtti %s 2>&1 | FileCheck -check-prefix=CHECK-SAN-ERROR %s
-// RUN: %clang -### -c -target x86_64-scei-ps4 -fsanitize=undefined -frtti %s 2>&1 | FileCheck -check-prefix=CHECK-OK %s
 
 // Exceptions + no/default rtti
-// RUN: %clang -### -c -target x86_64-scei-ps4 -fcxx-exceptions -fno-rtti %s 2>&1 | FileCheck -check-prefix=CHECK-EXC-ERROR-CXX %s
-// RUN: %clang -### -c -target x86_64-scei-ps4 -fcxx-exceptions %s 2>&1 | FileCheck -check-prefix=CHECK-EXC-WARN %s
 // RUN: %clang -### -c -target x86_64-unknown-unknown -fcxx-exceptions -fno-rtti %s 2>&1 | FileCheck -check-prefix=CHECK-OK %s
 // RUN: %clang -### -c -target x86_64-unknown-unknown -fcxx-exceptions %s 2>&1 | FileCheck -check-prefix=CHECK-OK %s
 // In C++, -fexceptions implies -fcxx-exceptions
-// RUN: %clang -x c++ -### -c -target x86_64-scei-ps4 -fexceptions -fno-rtti %s 2>&1 | FileCheck -check-prefix=CHECK-EXC-ERROR %s
-// RUN: %clang -x c++ -### -c -target x86_64-scei-ps4 -fexceptions %s 2>&1 | FileCheck -check-prefix=CHECK-EXC-WARN %s
 // RUN: %clang -x c++ -### -c -target x86_64-unknown-unknown -fexceptions -fno-rtti %s 2>&1 | FileCheck -check-prefix=CHECK-OK %s
 // RUN: %clang -x c++ -### -c -target x86_64-unknown-unknown -fexceptions %s 2>&1 | FileCheck -check-prefix=CHECK-OK %s
 
 // -frtti + exceptions
-// RUN: %clang -### -c -target x86_64-scei-ps4 -fcxx-exceptions -frtti %s 2>&1 | FileCheck -check-prefix=CHECK-OK %s
 // RUN: %clang -### -c -target x86_64-unknown-unknown -fcxx-exceptions -frtti %s 2>&1 | FileCheck -check-prefix=CHECK-OK %s
 
 // -f{no-,}rtti/default
-// RUN: %clang -### -c -ta

r332784 - Do not enable RTTI with -fexceptions, for PS4

[Sunil Srivastava via cfe-commits]

Author: ssrivastava
Date: Fri May 18 16:32:01 2018
New Revision: 332784

URL: http://llvm.org/viewvc/llvm-project?rev=332784&view=rev
Log:
Do not enable RTTI with -fexceptions, for PS4

NFC for targets other than PS4.

This patch is a change in behavior for PS4, in that PS4 will no longer enable
RTTI when -fexceptions is specified (RTTI and Exceptions are disabled by default
on PS4). RTTI will remain disabled except for types being thrown or caught.
Also, '-fexceptions -fno-rtti' (previously prohibited on PS4) is now accepted,
as it is for other targets.

This patch removes some PS4 specific code, making the code cleaner.

Also, in the test file rtti-options.cpp, PS4 tests where the behavior is the
same as the generic x86_64-linux are removed, making the test cleaner.

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

Modified:
cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
cfe/trunk/include/clang/Driver/ToolChain.h
cfe/trunk/lib/Driver/SanitizerArgs.cpp
cfe/trunk/lib/Driver/ToolChain.cpp
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/test/Driver/rtti-options.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td?rev=332784&r1=332783&r2=332784&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticDriverKinds.td Fri May 18 16:32:01 
2018
@@ -266,9 +266,6 @@ def warn_incompatible_sysroot : Warning<
   InGroup>;
 def warn_debug_compression_unavailable : Warning<"cannot compress debug 
sections (zlib not installed)">,
   InGroup>;
-def warn_drv_enabling_rtti_with_exceptions : Warning<
-  "implicitly enabling rtti for exception handling">,
-  InGroup>;
 def warn_drv_disabling_vptr_no_rtti_default : Warning<
   "implicitly disabling vptr sanitizer because rtti wasn't enabled">,
   InGroup;

Modified: cfe/trunk/include/clang/Driver/ToolChain.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/ToolChain.h?rev=332784&r1=332783&r2=332784&view=diff
==
--- cfe/trunk/include/clang/Driver/ToolChain.h (original)
+++ cfe/trunk/include/clang/Driver/ToolChain.h Fri May 18 16:32:01 2018
@@ -100,10 +100,8 @@ public:
   };
 
   enum RTTIMode {
-RM_EnabledExplicitly,
-RM_EnabledImplicitly,
-RM_DisabledExplicitly,
-RM_DisabledImplicitly
+RM_Enabled,
+RM_Disabled,
   };
 
 private:

Modified: cfe/trunk/lib/Driver/SanitizerArgs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/SanitizerArgs.cpp?rev=332784&r1=332783&r2=332784&view=diff
==
--- cfe/trunk/lib/Driver/SanitizerArgs.cpp (original)
+++ cfe/trunk/lib/Driver/SanitizerArgs.cpp Fri May 18 16:32:01 2018
@@ -288,19 +288,18 @@ SanitizerArgs::SanitizerArgs(const ToolC
   // Test for -fno-rtti + explicit -fsanitizer=vptr before expanding groups
   // so we don't error out if -fno-rtti and -fsanitize=undefined were
   // passed.
-  if (Add & Vptr &&
-  (RTTIMode == ToolChain::RM_DisabledImplicitly ||
-   RTTIMode == ToolChain::RM_DisabledExplicitly)) {
-if (RTTIMode == ToolChain::RM_DisabledImplicitly)
-  // Warn about not having rtti enabled if the vptr sanitizer is
-  // explicitly enabled
-  D.Diag(diag::warn_drv_disabling_vptr_no_rtti_default);
-else {
-  const llvm::opt::Arg *NoRTTIArg = TC.getRTTIArg();
-  assert(NoRTTIArg &&
- "RTTI disabled explicitly but we have no argument!");
+  if ((Add & Vptr) && (RTTIMode == ToolChain::RM_Disabled)) {
+if (const llvm::opt::Arg *NoRTTIArg = TC.getRTTIArg()) {
+  assert(NoRTTIArg->getOption().matches(options::OPT_fno_rtti) &&
+  "RTTI disabled without -fno-rtti option?");
+  // The user explicitly passed -fno-rtti with -fsanitize=vptr, but
+  // the vptr sanitizer requires RTTI, so this is a user error.
   D.Diag(diag::err_drv_argument_not_allowed_with)
   << "-fsanitize=vptr" << NoRTTIArg->getAsString(Args);
+} else {
+  // The vptr sanitizer requires RTTI, but RTTI is disabled (by 
+  // default). Warn that the vptr sanitizer is being disabled.
+  D.Diag(diag::warn_drv_disabling_vptr_no_rtti_default);
 }
 
 // Take out the Vptr sanitizer from the enabled sanitizers
@@ -372,9 +371,7 @@ SanitizerArgs::SanitizerArgs(const ToolC
 
   // We disable the vptr sanitizer if it was enabled by group expansion but 
RTTI
   // is disabled.
-  if ((Kinds & Vptr) &&
-  (RTTIMode == ToolChain::RM_DisabledImplicitly ||
-   RTTIMode == ToolChain::RM_DisabledExplicitly)) {
+  if ((Kinds & Vptr) && (RTTIMode == ToolC

[PATCH] D47092: downgrade strong type info names to weak_odr linkage

[Eric Fiselier via Phabricator via cfe-commits]

EricWF added a comment.

Sorry @rsmith, I was just about to tackle this.


Repository:
  rC Clang

https://reviews.llvm.org/D47092



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

[PATCH] D46485: Add python tool to dump and construct header maps

[Bruno Cardoso Lopes via Phabricator via cfe-commits]

bruno added inline comments.



Comment at: test/Preprocessor/headermap-rel.c:2-3
 
 // This uses a headermap with this entry:
 //   Foo.h -> Foo/Foo.h
 

dexonsmith wrote:
> Should we delete this comment now that the header map is human-readable?
Sure!



Comment at: test/Preprocessor/headermap-rel.c:6
+// RUN: rm -f %t.hmap
+// RUN: hmaptool write %S/Inputs/headermap-rel/foo.hmap.json %t.hmap
+// RUN: %clang_cc1 -E %s -o %t.i -I %t.hmap -F %S/Inputs/headermap-rel

dexonsmith wrote:
> Should there be some sort of `REQUIRES:` clause for using `hmaptool`?
Not really needed, `hmaptool` is setup to work just like `clang-rename` and 
others, it will always be available to be used by lit. Additionally, it's not 
importing any module that isn't in the python standard library.


https://reviews.llvm.org/D46485



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

[PATCH] D47092: downgrade strong type info names to weak_odr linkage

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In https://reviews.llvm.org/D47092#1105317, @rjmccall wrote:

> Incomplete classes are a curse.  I don't suppose we can just modify the 
> language specification to make it illegal to use `typeid(Incomplete*)`?  Or 
> make equality/hashing undefined in these cases?


Honestly, I'm somewhat inclined to just declare this for Darwin and make us 
non-conformant.  It's not like this has ever previously worked, and this patch 
is going to be disruptive for our internal C++ developers by introducing new 
global weak symbols that they can't get rid of except by disabling RTTI.  (It 
would always have been a problem if they were actually using RTTI, of course, 
but one of the whole problems with RTTI is that you live with the consequences 
whether you use it or not.)


Repository:
  rC Clang

https://reviews.llvm.org/D47092



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

[PATCH] D47096: CodeGen: block capture shouldn't ICE

[JF Bastien via Phabricator via cfe-commits]

jfb created this revision.
jfb added a reviewer: rjmccall.
Herald added subscribers: cfe-commits, aheejin.

When a lambda capture captures a __block in the same statement, the compiler 
asserts out because isCapturedBy assumes that an Expr can only be a BlockExpr, 
StmtExpr, or if it's a Stmt then all the statement's children are expressions. 
That's wrong, we need to visit all sub-statements even if they're not 
expressions to see if they also capture.

Fix this issue by pulling out the isCapturedBy logic to use RecursiveASTVisitor.

rdar://problem/39926584


Repository:
  rC Clang

https://reviews.llvm.org/D47096

Files:
  lib/CodeGen/CGDecl.cpp
  test/CodeGen/block-capture.cpp

Index: test/CodeGen/block-capture.cpp
===
--- /dev/null
+++ test/CodeGen/block-capture.cpp
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 -x c++ -std=c++11 -fblocks -emit-llvm %s -o - | FileCheck %s
+
+// CHECK: %struct.__block_byref_baz = type { i8*, %struct.__block_byref_baz*, i32, i32, i32 }
+// CHECK: [[baz:%[0-9a-z_]*]] = alloca %struct.__block_byref_baz
+// CHECK: [[bazref:%[0-9a-z_\.]*]] = getelementptr inbounds %struct.__block_byref_baz, %struct.__block_byref_baz* [[baz]], i32 0, i32 1
+// CHECK: store %struct.__block_byref_baz* [[baz]], %struct.__block_byref_baz** [[bazref]]
+// CHECK: [[disposable:%[0-9a-z_]*]] = bitcast %struct.__block_byref_baz* [[baz]] to i8*
+// CHECK: call void @_Block_object_dispose(i8* [[disposable]]
+
+int main() {
+  __block int baz = [&]() { return 0; }();
+  return 0;
+}
Index: lib/CodeGen/CGDecl.cpp
===
--- lib/CodeGen/CGDecl.cpp
+++ lib/CodeGen/CGDecl.cpp
@@ -26,6 +26,7 @@
 #include "clang/AST/Decl.h"
 #include "clang/AST/DeclObjC.h"
 #include "clang/AST/DeclOpenMP.h"
+#include "clang/AST/RecursiveASTVisitor.h"
 #include "clang/Basic/SourceManager.h"
 #include "clang/Basic/TargetInfo.h"
 #include "clang/CodeGen/CGFunctionInfo.h"
@@ -1244,53 +1245,65 @@
   return emission;
 }
 
-/// Determines whether the given __block variable is potentially
-/// captured by the given expression.
-static bool isCapturedBy(const VarDecl &var, const Expr *e) {
-  // Skip the most common kinds of expressions that make
-  // hierarchy-walking expensive.
-  e = e->IgnoreParenCasts();
+static bool isCapturedBy(const VarDecl &, const Expr *);
 
-  if (const BlockExpr *be = dyn_cast(e)) {
-const BlockDecl *block = be->getBlockDecl();
-for (const auto &I : block->captures()) {
-  if (I.getVariable() == &var)
-return true;
-}
+class IsCapturedBy : public RecursiveASTVisitor {
+  bool IsCaptured = false;
+  const VarDecl &Var;
+  bool setCaptured() {
+IsCaptured = true;
+// End visitation early, we know it's captured.
+return false;
+  }
 
+public:
+  IsCapturedBy(const VarDecl &Var) : Var(Var) {}
+  bool isCaptured() const { return IsCaptured; }
+
+  bool TraverseBlockExpr(BlockExpr *BE) {
+const BlockDecl *Block = BE->getBlockDecl();
+for (const auto &I : Block->captures())
+  if (I.getVariable() == &Var)
+return setCaptured();
 // No need to walk into the subexpressions.
 return false;
   }
 
-  if (const StmtExpr *SE = dyn_cast(e)) {
+  bool TraverseStmtExpr(StmtExpr *SE) {
 const CompoundStmt *CS = SE->getSubStmt();
 for (const auto *BI : CS->body())
   if (const auto *E = dyn_cast(BI)) {
-if (isCapturedBy(var, E))
-return true;
-  }
-  else if (const auto *DS = dyn_cast(BI)) {
-  // special case declarations
-  for (const auto *I : DS->decls()) {
-  if (const auto *VD = dyn_cast((I))) {
-const Expr *Init = VD->getInit();
-if (Init && isCapturedBy(var, Init))
-  return true;
-  }
+if (isCapturedBy(Var, E))
+  return setCaptured();
+  } else if (const auto *DS = dyn_cast(BI)) {
+// special case declarations
+for (const auto *I : DS->decls()) {
+  if (const auto *VD = dyn_cast((I))) {
+const Expr *Init = VD->getInit();
+if (Init && isCapturedBy(Var, Init))
+  return setCaptured();
   }
+}
   }
   else
-// FIXME. Make safe assumption assuming arbitrary statements cause capturing.
-// Later, provide code to poke into statements for capture analysis.
-return true;
-return false;
+// FIXME. Make safe assumption assuming arbitrary statements cause
+// capturing. Later, provide code to poke into statements for capture
+// analysis.
+return setCaptured();
+return true;
   }
+};
 
-  for (const Stmt *SubStmt : e->children())
-if (isCapturedBy(var, cast(SubStmt)))
-  return true;
+/// Determines whether the given __block variable is potentially
+/// captured by the given expression.
+static bool isCapturedBy(const VarDecl &Var, const Expr *E) {
+ 

[PATCH] D46472: [HIP] Support offloading by linker script

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp:1371-1388
+  // machines.
+  LksStream << "/*\n";
+  LksStream << "   HIP Offload Linker Script\n";
+  LksStream << " *** Automatically generated by Clang ***\n";
+  LksStream << "*/\n";
+  LksStream << "TARGET(binary)\n";
+  LksStream << "INPUT(" << BundleFileName << ")\n";

Using this linker script may present a problem.

INSERT BEFORE is not going to work with ld.gold.
https://sourceware.org/bugzilla/show_bug.cgi?id=15373

LLD also does not handle it particularly well -- INSERT BEFORE can only be used 
to override explicitly specified external linker script and virtually nobody 
uses linker scripts with LLD.
See tests in https://reviews.llvm.org/D44380



Repository:
  rL LLVM

https://reviews.llvm.org/D46472



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

[PATCH] D46740: [Clang Tablegen][RFC] Allow Early Textual Substitutions in `Diagnostic` messages.

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: utils/TableGen/ClangDiagnosticsEmitter.cpp:514
+  std::vector Diags = Records.getAllDerivedDefinitions("Diagnostic");
+  llvm::for_each(Diags, [&](Record *R) { substituteDiagText(R, SubsMap); });
 

EricWF wrote:
> rjmccall wrote:
> > I see why this has to be done separately, I think, but it should at least 
> > go in a helper function.
> > 
> > Also, please check for substitution-name conflicts.
> @rjmccall By substitution name conflicts do you mean substitution names which 
> conflict with diagnostic names?
I meant between substitutions, but I guess that's probably handled 
automatically by the base TableGen parser, sorry.


https://reviews.llvm.org/D46740



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

[PATCH] D47092: downgrade strong type info names to weak_odr linkage

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Incomplete classes are a curse.  I don't suppose we can just modify the 
language specification to make it illegal to use `typeid(Incomplete*)`?  Or 
make equality/hashing undefined in these cases?




Comment at: test/CodeGenCXX/arm64.cpp:48
   void A::foo() {}
-  // CHECK-GLOBALS-DAG: @_ZTSN5test21AE = constant [11 x i8]
+  // CHECK-GLOBALS-DAG: @_ZTSN5test21AE = weak_odr constant [11 x i8]
   // CHECK-GLOBALS-DAG: @_ZTIN5test21AE = constant { {{.*}}, i8* getelementptr 
inbounds ([11 x i8], [11 x i8]* @_ZTSN5test21AE, i32 0, i32 0) }

The way the Darwin ARM64 ABI handles non-unique RTTI is by setting a flag 
indicating that clients should do string comparisons/hashes; it does not rely 
on the type name symbols being uniqued.  So this should stay external and the 
_ZTI definition should change to set the bit.



Comment at: test/CodeGenCXX/windows-itanium-type-info.cpp:31
 // CHECK-DAG: @_ZTI7derived = dso_local dllexport constant
-// CHECK-DAG: @_ZTS7derived = dso_local dllexport constant
+// CHECK-DAG: @_ZTS7derived = weak_odr dso_local dllexport constant
 // CHECK-DAG: @_ZTV7derived = dso_local dllexport unnamed_addr constant

Is this actually okay?  I didn't think dllexport supported weak symbols.


Repository:
  rC Clang

https://reviews.llvm.org/D47092



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

[PATCH] D47092: downgrade strong type info names to weak_odr linkage

[Eli Friedman via Phabricator via cfe-commits]

efriedma added a comment.

> This results in formal violations of LLVM's linkage rules

I'm pretty sure this isn't actually a violation of LLVM's linkage rules as they 
are described in LangRef... at least, my understanding is that "equivalent" 
doesn't imply anything about linkage.  (If this should be a violation, we need 
to clarify the rules.)


Repository:
  rC Clang

https://reviews.llvm.org/D47092



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

[PATCH] D45015: [Preprocessor] Allow libc++ to detect when aligned allocation is unavailable.

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

rsmith added a comment.

Hmm, perhaps our strategy for handling aligned allocation on Darwin should be 
revisited. We shouldn't be defining `__cpp_aligned_allocation` if we believe it 
doesn't work -- that will break code that uses aligned allocation where 
available and falls back to something else where it's unavailable.

@ahatanak: how about this:

- Change the driver to not pass `-faligned-alloc-unavailable` if an explicit 
`-faligned-allocation` or `-fno-aligned-allocation` flag is given; update 
Clang's note to suggest explicitly passing `-faligned-allocation` rather than 
`-Wno-aligned-alloc-unavailable` if the user provides their own aligned 
allocation function.
- Change `-faligned-alloc-unavailable` so that it does not define 
`__cpp_aligned_allocation`.
- Change Sema's handling of the "aligned allocation unavailable" case so that, 
after warning on selecting an aligned allocation function, it then removes 
those functions from the candidate set and tries again.

That is: on old Darwin, we should not define `__cpp_aligned_allocation` (even 
in C++17), produce the "no aligned allocation support" warning in C++17 mode, 
and then not try to call the aligned allocation function. But if 
`-faligned-allocation` or `-fno-aligned-allocation` is specified explicitly, 
then the user knows what they're doing and they get no warning.


Repository:
  rC Clang

https://reviews.llvm.org/D45015



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

[PATCH] D47095: [clang-format/ObjC] Correctly parse Objective-C methods with 'class' in name

[Ben Hamilton via Phabricator via cfe-commits]

benhamilton updated this revision to Diff 147611.
benhamilton added a comment.

Format


Repository:
  rC Clang

https://reviews.llvm.org/D47095

Files:
  lib/Format/UnwrappedLineParser.cpp
  lib/Format/UnwrappedLineParser.h
  unittests/Format/FormatTestObjC.cpp

Index: unittests/Format/FormatTestObjC.cpp
===
--- unittests/Format/FormatTestObjC.cpp
+++ unittests/Format/FormatTestObjC.cpp
@@ -998,6 +998,59 @@
   verifyFormat("MACRO(new:)\n");
   verifyFormat("MACRO(delete:)\n");
   verifyFormat("foo = @{MACRO(new:) : MACRO(delete:)}\n");
+  verifyFormat("@implementation Foo\n"
+   "// Testing\n"
+   "- (Class)class {\n"
+   "}\n"
+   "- (void)foo {\n"
+   "}\n"
+   "@end\n");
+  verifyFormat("@implementation Foo\n"
+   "- (Class)class {\n"
+   "}\n"
+   "- (void)foo {\n"
+   "}\n"
+   "@end");
+  verifyFormat("@implementation Foo\n"
+   "+ (Class)class {\n"
+   "}\n"
+   "- (void)foo {\n"
+   "}\n"
+   "@end");
+  verifyFormat("@implementation Foo\n"
+   "- (Class)class:(Class)klass {\n"
+   "}\n"
+   "- (void)foo {\n"
+   "}\n"
+   "@end");
+  verifyFormat("@implementation Foo\n"
+   "+ (Class)class:(Class)klass {\n"
+   "}\n"
+   "- (void)foo {\n"
+   "}\n"
+   "@end");
+
+  verifyFormat("@interface Foo\n"
+   "// Testing\n"
+   "- (Class)class;\n"
+   "- (void)foo;\n"
+   "@end\n");
+  verifyFormat("@interface Foo\n"
+   "- (Class)class;\n"
+   "- (void)foo;\n"
+   "@end");
+  verifyFormat("@interface Foo\n"
+   "+ (Class)class;\n"
+   "- (void)foo;\n"
+   "@end");
+  verifyFormat("@interface Foo\n"
+   "- (Class)class:(Class)klass;\n"
+   "- (void)foo;\n"
+   "@end");
+  verifyFormat("@interface Foo\n"
+   "+ (Class)class:(Class)klass;\n"
+   "- (void)foo;\n"
+   "@end");
 }
 
 TEST_F(FormatTestObjC, ObjCLiterals) {
Index: lib/Format/UnwrappedLineParser.h
===
--- lib/Format/UnwrappedLineParser.h
+++ lib/Format/UnwrappedLineParser.h
@@ -120,6 +120,7 @@
   // parses the record as a child block, i.e. if the class declaration is an
   // expression.
   void parseRecord(bool ParseAsExpr = false);
+  void parseObjCMethod();
   void parseObjCProtocolList();
   void parseObjCUntilAtEnd();
   void parseObjCInterfaceOrImplementation();
Index: lib/Format/UnwrappedLineParser.cpp
===
--- lib/Format/UnwrappedLineParser.cpp
+++ lib/Format/UnwrappedLineParser.cpp
@@ -2130,6 +2130,23 @@
   // "} n, m;" will end up in one unwrapped line.
 }
 
+void UnwrappedLineParser::parseObjCMethod() {
+  assert(FormatTok->Tok.isOneOf(tok::l_paren, tok::identifier) &&
+ "'(' or identifier expected.");
+  do {
+if (FormatTok->Tok.isOneOf(tok::semi, tok::r_brace)) {
+  nextToken();
+  addUnwrappedLine();
+  return;
+} else if (FormatTok->Tok.is(tok::l_brace)) {
+  parseBlock(/*MustBeDeclaration=*/false);
+  addUnwrappedLine();
+} else {
+  nextToken();
+}
+  } while (!eof());
+}
+
 void UnwrappedLineParser::parseObjCProtocolList() {
   assert(FormatTok->Tok.is(tok::less) && "'<' expected.");
   do {
@@ -2157,6 +2174,9 @@
   // Ignore stray "}". parseStructuralElement doesn't consume them.
   nextToken();
   addUnwrappedLine();
+} else if (FormatTok->isOneOf(tok::minus, tok::plus)) {
+  nextToken();
+  parseObjCMethod();
 } else {
   parseStructuralElement();
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47095: [clang-format/ObjC] Correctly parse Objective-C methods with 'class' in name

[Ben Hamilton via Phabricator via cfe-commits]

benhamilton created this revision.
benhamilton added reviewers: djasper, jolesiak.
Herald added subscribers: cfe-commits, klimek.

Please take a close look at this CL. I haven't touched much of
`UnwrappedLineParser` before, so I may have gotten things wrong.

Previously, clang-format would incorrectly format the following:

  @implementation Foo
  
  - (Class)class {
  }
  
  - (void)foo {
  }
  
  @end

as:

  @implementation Foo
  
  - (Class)class {
  }
  
  - (void)foo {
  }
  
  @end

The problem is whenever `UnwrappedLineParser::parseStructuralElement()`
sees any of the keywords `class`, `struct`, or `enum`, it calls
`parseRecord()` to parse them as a C/C++ record.

This causes subsequent lines to be parsed incorrectly, which
causes them to be indented incorrectly.

In Objective-C/Objective-C++, these keywords are valid selector
components.

This diff fixes the issue by explicitly handling `+` and `-` lines
inside `@implementation` / `@interface` / `@protocol` blocks
and parsing them as Objective-C methods.

Test Plan: New tests added. Ran tests with:

  make -j16 FormatTests && ./tools/clang/unittests/Format/FormatTests


Repository:
  rC Clang

https://reviews.llvm.org/D47095

Files:
  lib/Format/UnwrappedLineParser.cpp
  lib/Format/UnwrappedLineParser.h
  unittests/Format/FormatTestObjC.cpp

Index: unittests/Format/FormatTestObjC.cpp
===
--- unittests/Format/FormatTestObjC.cpp
+++ unittests/Format/FormatTestObjC.cpp
@@ -998,6 +998,59 @@
   verifyFormat("MACRO(new:)\n");
   verifyFormat("MACRO(delete:)\n");
   verifyFormat("foo = @{MACRO(new:) : MACRO(delete:)}\n");
+  verifyFormat("@implementation Foo\n"
+   "// Testing\n"
+   "- (Class)class {\n"
+   "}\n"
+   "- (void)foo {\n"
+   "}\n"
+   "@end\n");
+  verifyFormat("@implementation Foo\n"
+   "- (Class)class {\n"
+   "}\n"
+   "- (void)foo {\n"
+   "}\n"
+   "@end");
+  verifyFormat("@implementation Foo\n"
+   "+ (Class)class {\n"
+   "}\n"
+   "- (void)foo {\n"
+   "}\n"
+   "@end");
+  verifyFormat("@implementation Foo\n"
+   "- (Class)class:(Class)klass {\n"
+   "}\n"
+   "- (void)foo {\n"
+   "}\n"
+   "@end");
+  verifyFormat("@implementation Foo\n"
+   "+ (Class)class:(Class)klass {\n"
+   "}\n"
+   "- (void)foo {\n"
+   "}\n"
+   "@end");
+
+  verifyFormat("@interface Foo\n"
+   "// Testing\n"
+   "- (Class)class;\n"
+   "- (void)foo;\n"
+   "@end\n");
+  verifyFormat("@interface Foo\n"
+   "- (Class)class;\n"
+   "- (void)foo;\n"
+   "@end");
+  verifyFormat("@interface Foo\n"
+   "+ (Class)class;\n"
+   "- (void)foo;\n"
+   "@end");
+  verifyFormat("@interface Foo\n"
+   "- (Class)class:(Class)klass;\n"
+   "- (void)foo;\n"
+   "@end");
+  verifyFormat("@interface Foo\n"
+   "+ (Class)class:(Class)klass;\n"
+   "- (void)foo;\n"
+   "@end");
 }
 
 TEST_F(FormatTestObjC, ObjCLiterals) {
Index: lib/Format/UnwrappedLineParser.h
===
--- lib/Format/UnwrappedLineParser.h
+++ lib/Format/UnwrappedLineParser.h
@@ -120,6 +120,7 @@
   // parses the record as a child block, i.e. if the class declaration is an
   // expression.
   void parseRecord(bool ParseAsExpr = false);
+  void parseObjCMethod();
   void parseObjCProtocolList();
   void parseObjCUntilAtEnd();
   void parseObjCInterfaceOrImplementation();
Index: lib/Format/UnwrappedLineParser.cpp
===
--- lib/Format/UnwrappedLineParser.cpp
+++ lib/Format/UnwrappedLineParser.cpp
@@ -2130,6 +2130,22 @@
   // "} n, m;" will end up in one unwrapped line.
 }
 
+void UnwrappedLineParser::parseObjCMethod() {
+  assert(FormatTok->Tok.isOneOf(tok::l_paren, tok::identifier) && "'(' or identifier expected.");
+  do {
+if (FormatTok->Tok.isOneOf(tok::semi, tok::r_brace)) {
+  nextToken();
+  addUnwrappedLine();
+  return;
+} else if (FormatTok->Tok.is(tok::l_brace)) {
+  parseBlock(/*MustBeDeclaration=*/false);
+  addUnwrappedLine();
+} else {
+  nextToken();
+}
+  } while (!eof());
+}
+
 void UnwrappedLineParser::parseObjCProtocolList() {
   assert(FormatTok->Tok.is(tok::less) && "'<' expected.");
   do {
@@ -2157,6 +2173,9 @@
   // Ignore stray "}". parseStructuralElement doesn't consume them.
   nextToken();
   addUnwrappedLine();
+} else if (FormatTok->isOneOf(tok::minus, tok::plus)) {
+  nextToken();
+  parseObjCMethod();
 } else {
   parseStruct

[PATCH] D47093: CodeGen, Driver: Start using direct split dwarf emission in clang.

[Peter Collingbourne via Phabricator via cfe-commits]

pcc created this revision.
pcc added reviewers: dblaikie, echristo.
Herald added a subscriber: JDevlieghere.

Fixes PR37466.

Depends on https://reviews.llvm.org/D47091


https://reviews.llvm.org/D47093

Files:
  clang/include/clang/Driver/CC1Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/split-debug-filename.c
  clang/test/Driver/split-debug.c
  clang/test/Driver/split-debug.s
  clang/test/Misc/cc1as-split-dwarf.s
  clang/tools/driver/cc1as_main.cpp

Index: clang/tools/driver/cc1as_main.cpp
===
--- clang/tools/driver/cc1as_main.cpp
+++ clang/tools/driver/cc1as_main.cpp
@@ -97,6 +97,7 @@
   llvm::DebugCompressionType CompressDebugSections =
   llvm::DebugCompressionType::None;
   std::string MainFileName;
+  std::string SplitDwarfFile;
 
   /// @}
   /// @name Frontend Options
@@ -247,6 +248,7 @@
   }
   Opts.LLVMArgs = Args.getAllArgValues(OPT_mllvm);
   Opts.OutputPath = Args.getLastArgValue(OPT_o);
+  Opts.SplitDwarfFile = Args.getLastArgValue(OPT_split_dwarf_file);
   if (Arg *A = Args.getLastArg(OPT_filetype)) {
 StringRef Name = A->getValue();
 unsigned OutputType = StringSwitch(Name)
@@ -282,22 +284,17 @@
 }
 
 static std::unique_ptr
-getOutputStream(AssemblerInvocation &Opts, DiagnosticsEngine &Diags,
-bool Binary) {
-  if (Opts.OutputPath.empty())
-Opts.OutputPath = "-";
-
+getOutputStream(StringRef Path, DiagnosticsEngine &Diags, bool Binary) {
   // Make sure that the Out file gets unlinked from the disk if we get a
   // SIGINT.
-  if (Opts.OutputPath != "-")
-sys::RemoveFileOnSignal(Opts.OutputPath);
+  if (Path != "-")
+sys::RemoveFileOnSignal(Path);
 
   std::error_code EC;
   auto Out = llvm::make_unique(
-  Opts.OutputPath, EC, (Binary ? sys::fs::F_None : sys::fs::F_Text));
+  Path, EC, (Binary ? sys::fs::F_None : sys::fs::F_Text));
   if (EC) {
-Diags.Report(diag::err_fe_unable_to_open_output) << Opts.OutputPath
- << EC.message();
+Diags.Report(diag::err_fe_unable_to_open_output) << Path << EC.message();
 return nullptr;
   }
 
@@ -342,9 +339,15 @@
   MAI->setRelaxELFRelocations(Opts.RelaxELFRelocations);
 
   bool IsBinary = Opts.OutputType == AssemblerInvocation::FT_Obj;
-  std::unique_ptr FDOS = getOutputStream(Opts, Diags, IsBinary);
+  if (Opts.OutputPath.empty())
+Opts.OutputPath = "-";
+  std::unique_ptr FDOS =
+  getOutputStream(Opts.OutputPath, Diags, IsBinary);
   if (!FDOS)
 return true;
+  std::unique_ptr DwoOS;
+  if (!Opts.SplitDwarfFile.empty())
+DwoOS = getOutputStream(Opts.SplitDwarfFile, Diags, IsBinary);
 
   // FIXME: This is not pretty. MCContext has a ptr to MCObjectFileInfo and
   // MCObjectFileInfo needs a MCContext reference in order to initialize itself.
@@ -427,7 +430,9 @@
 MCTargetOptions MCOptions;
 std::unique_ptr MAB(
 TheTarget->createMCAsmBackend(*STI, *MRI, MCOptions));
-std::unique_ptr OW = MAB->createObjectWriter(*Out);
+std::unique_ptr OW =
+DwoOS ? MAB->createDwoObjectWriter(*Out, *DwoOS)
+  : MAB->createObjectWriter(*Out);
 
 Triple T(Opts.Triple);
 Str.reset(TheTarget->createMCObjectStreamer(
@@ -476,8 +481,12 @@
   FDOS.reset();
 
   // Delete output file if there were errors.
-  if (Failed && Opts.OutputPath != "-")
-sys::fs::remove(Opts.OutputPath);
+  if (Failed) {
+if (Opts.OutputPath != "-")
+  sys::fs::remove(Opts.OutputPath);
+if (!Opts.SplitDwarfFile.empty() && Opts.SplitDwarfFile != "-")
+  sys::fs::remove(Opts.SplitDwarfFile);
+  }
 
   return Failed;
 }
Index: clang/test/Misc/cc1as-split-dwarf.s
===
--- /dev/null
+++ clang/test/Misc/cc1as-split-dwarf.s
@@ -0,0 +1,25 @@
+// RUN: %clang -cc1as -triple x86_64-pc-linux-gnu %s -filetype obj -o %t1 -split-dwarf-file %t2
+// RUN: llvm-objdump -s %t1 | FileCheck --check-prefix=O %s
+// RUN: llvm-objdump -s %t2 | FileCheck --check-prefix=DWO %s
+
+// O-NOT: Contents of section
+// O: Contents of section .strtab:
+// O-NOT: Contents of section
+// O: Contents of section .text:
+// O-NEXT:  c3
+// O-NEXT: Contents of section .symtab:
+// O-NOT: Contents of section
+.globl main
+main:
+.Ltmp1:
+ret
+.Ltmp2:
+
+// DWO-NOT: Contents of section
+// DWO: Contents of section .strtab:
+// DWO-NOT: Contents of section
+// DWO: Contents of section .foo.dwo:
+// DWO-NEXT:  0100
+// DWO-NOT: Contents of section
+.section .foo.dwo
+.long .Ltmp2-.Ltmp1
Index: clang/test/Driver/split-debug.s
===
--- clang/test/Driver/split-debug.s
+++ clang/test/Driver/split-debug.s
@@ -3,8 +3,7 @@
 // RUN: %clang -target x86_64-unknown-linux-gnu -gsplit-dwarf -c -### %s 2> %t
 // RUN: FileCheck -check-prefix=CHECK-ACTIONS < %t %s
 //
-// CHECK-ACTIONS: objcopy{{.*}}--ext

[PATCH] D45212: [HIP] Let CUDA toolchain support HIP language mode and amdgpu

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

One more thing -- it would be really good to add some tests to make sure your 
commands are constructed the way you want.


https://reviews.llvm.org/D45212



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

[PATCH] D43667: [clang-doc] Implement a YAML generator

[Julie Hockett via Phabricator via cfe-commits]

juliehockett added inline comments.



Comment at: clang-doc/generators/Generators.h:49
+
+class GeneratorFactory {
+public:

ioeric wrote:
> ioeric wrote:
> > Please add documentation and explain why this is needed. 
> If you plan to plugin in more generators (e.g. in your customized build of 
> clang-doc), consider using `llvm::Registry` which allows you to link in new 
> generators without having to modify code. See 
> `clang::clangd::URISchemeRegistry` for sample usage.
Oh cool -- didn't know about that. Thanks!



Comment at: clang-doc/generators/YAMLGenerator.cpp:223
+
+template <> struct MappingTraits> {
+  static void mapping(IO &IO, std::unique_ptr &I) {

ioeric wrote:
> YAML mapping for `unique_ptr` is a bit unusual. I wonder whether this would 
> work all the time e.g. if the unique_ptr has not been allocated. 
Mmm yes it's a little weird -- that said, is there a better way emit the info 
given a pointer?


https://reviews.llvm.org/D43667



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

[PATCH] D43667: [clang-doc] Implement a YAML generator

[Julie Hockett via Phabricator via cfe-commits]

juliehockett updated this revision to Diff 147606.
juliehockett marked 11 inline comments as done.
juliehockett edited the summary of this revision.
juliehockett added a comment.

Updating for better integration with MR framework, the generator now takes in 
an info and an output stream and emits the YAML to that stream. Each info is 
emitted to its own YAML file.


https://reviews.llvm.org/D43667

Files:
  clang-doc/CMakeLists.txt
  clang-doc/Representation.h
  clang-doc/generators/CMakeLists.txt
  clang-doc/generators/Generators.h
  clang-doc/generators/YAMLGenerator.cpp
  clang-doc/tool/CMakeLists.txt
  clang-doc/tool/ClangDocMain.cpp
  test/clang-doc/yaml-comments.cpp
  test/clang-doc/yaml-namespace.cpp
  test/clang-doc/yaml-record.cpp

Index: test/clang-doc/yaml-record.cpp
===
--- /dev/null
+++ test/clang-doc/yaml-record.cpp
@@ -0,0 +1,212 @@
+// RUN: rm -rf %t
+// RUN: mkdir %t
+// RUN: echo "" > %t/compile_flags.txt
+// RUN: cp "%s" "%t/test.cpp"
+// RUN: clang-doc -doxygen -p %t %t/test.cpp -output=%t/docs
+// RUN: cat %t/docs/yaml/docs.yaml | FileCheck %s
+
+union A { int X; int Y; };
+
+enum B { X, Y };
+
+enum class Bc { A, B };
+
+struct C { int i; };
+
+class D {};
+
+class E {
+public:
+  E() {}
+  ~E() {}
+
+protected:
+  void ProtectedMethod();
+};
+
+void E::ProtectedMethod() {}
+
+class F : virtual private D, public E {};
+
+class X {
+  class Y {};
+};
+
+void H() {
+  class I {};
+}
+
+// CHECK: ---
+// CHECK-NEXT: Records: 
+// CHECK-NEXT:   - USR: 'ACE81AFA6627B4CEF2B456FB6E1252925674AF7E'
+// CHECK-NEXT: Name:'A'
+// CHECK-NEXT: DefLocation: 
+// CHECK-NEXT:   LineNumber:  8
+// CHECK-NEXT:   Filename:'{{.*}}'
+// CHECK-NEXT: TagType: Union
+// CHECK-NEXT: Members: 
+// CHECK-NEXT:   - Type:
+// CHECK-NEXT:   UnresolvedName:  'int'
+// CHECK-NEXT: Name:'A::X'
+// CHECK-NEXT:   - Type:
+// CHECK-NEXT:   UnresolvedName:  'int'
+// CHECK-NEXT: Name:'A::Y'
+// CHECK-NEXT:   - USR: '06B5F6A19BA9F6A832E127C9968282B94619B210'
+// CHECK-NEXT: Name:'C'
+// CHECK-NEXT: DefLocation: 
+// CHECK-NEXT:   LineNumber:  14
+// CHECK-NEXT:   Filename:'{{.*}}'
+// CHECK-NEXT: Members: 
+// CHECK-NEXT:   - Type:
+// CHECK-NEXT:   UnresolvedName:  'int'
+// CHECK-NEXT: Name:'C::i'
+// CHECK-NEXT:   - USR: '0921737541208B8FA9BB42B60F78AC1D779AA054'
+// CHECK-NEXT: Name:'D'
+// CHECK-NEXT: Records: 
+// CHECK-NEXT:   - Type:Record
+// CHECK-NEXT: USR: 'E3B54702FABFF4037025BA194FC27C47006330B5'
+// CHECK-NEXT: DefLocation: 
+// CHECK-NEXT:   LineNumber:  16
+// CHECK-NEXT:   Filename:'{{.*}}'
+// CHECK-NEXT: TagType: Class
+// CHECK-NEXT:   - USR: '289584A8E0FF4178A794622A547AA622503967A1'
+// CHECK-NEXT: Name:'E'
+// CHECK-NEXT: Records: 
+// CHECK-NEXT:   - Type:Record
+// CHECK-NEXT: USR: 'E3B54702FABFF4037025BA194FC27C47006330B5'
+// CHECK-NEXT: Functions:   
+// CHECK-NEXT:   - Type:Function
+// CHECK-NEXT: USR: 'DEB4AC1CD9253CD9EF7FBE6BCAC506D77984ABD4'
+// CHECK-NEXT:   - Type:Function
+// CHECK-NEXT: USR: 'DEB4AC1CD9253CD9EF7FBE6BCAC506D77984ABD4'
+// CHECK-NEXT:   - Type:Function
+// CHECK-NEXT: USR: 'BD2BDEBD423F80BACCEA75DE6D6622D355FC2D17'
+// CHECK-NEXT:   - Type:Function
+// CHECK-NEXT: USR: 'BD2BDEBD423F80BACCEA75DE6D6622D355FC2D17'
+// CHECK-NEXT:   - Type:Function
+// CHECK-NEXT: USR: '5093D428CDC62096A67547BA52566E4FB9404EEE'
+// CHECK-NEXT:   - Type:Function
+// CHECK-NEXT: USR: '5093D428CDC62096A67547BA52566E4FB9404EEE'
+// CHECK-NEXT: DefLocation: 
+// CHECK-NEXT:   LineNumber:  18
+// CHECK-NEXT:   Filename:'{{.*}}'
+// CHECK-NEXT: TagType: Class
+// CHECK-NEXT:   - USR: 'E3B54702FABFF4037025BA194FC27C47006330B5'
+// CHECK-NEXT: Name:'F'
+// CHECK-NEXT: DefLocation: 
+// CHECK-NEXT:   LineNumber:  29
+// CHECK-NEXT:   Filename:'{{.*}}'
+// CHECK-NEXT: TagType: Class
+// CHECK-NEXT: Parents: 
+// CHECK-NEXT:   - Type:Record
+// CHECK-NEXT: USR: '289584A8E0FF4178A794622A547AA622503967A1'
+// CHECK-NEXT: VirtualParents:  
+// CHECK-NEXT:   - Type:Record
+// CHECK-NEXT: USR: '0921737541208B8FA9BB42B60F78AC1D779AA054'
+// CHECK-NEXT:   - USR:   

[PATCH] D46476: [HIP] Add action builder for HIP

[Artem Belevich via Phabricator via cfe-commits]

tra added inline comments.



Comment at: lib/Driver/Driver.cpp:2221
+CudaDeviceActions.clear();
+for (unsigned I = 0, E = GpuArchList.size(); I != E; ++I) {
+  CudaDeviceActions.push_back(UA);

`for(auto Arch: GpuArchList)`



Comment at: lib/Driver/Driver.cpp:2265-2272
+  assert(AssociatedOffloadKind == Action::OFK_Cuda || 
AssociatedOffloadKind == Action::OFK_HIP);
+
   // We don't need to support CUDA.
-  if (!C.hasOffloadToolChain())
+  if (AssociatedOffloadKind == Action::OFK_Cuda && 
!C.hasOffloadToolChain())
+return false;
+
+  // We don't need to support HIP.

Please reformat.



Comment at: lib/Driver/Driver.cpp:2330-2332
+  for (CudaArch Arch : GpuArchs) {
 GpuArchList.push_back(Arch);
+  }

Single-statement for does not need braces.



Comment at: lib/Driver/Driver.cpp:2485-2493
+  // The host only depends on device action in the linking phase, when all
+  // the device images have to be embedded in the host image.
+  if (CurPhase == phases::Link) {
+DeviceLinkerInputs.resize(CudaDeviceActions.size());
+auto LI = DeviceLinkerInputs.begin();
+for (auto *A : CudaDeviceActions) {
+  LI->push_back(A);

I'm not sure I understand what happens here and the comment does not help.
We appear to add each element of CudaDeviceActions to the action list of each 
linker input.

Does the comment mean that *only in linking mode* do we need to add dependency 
on device actions?



https://reviews.llvm.org/D46476



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

[PATCH] D46665: [Itanium] Emit type info names with external linkage.

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

rsmith added a comment.

Please see https://reviews.llvm.org/D47092 for the `external` -> `weak_odr` 
change.


Repository:
  rC Clang

https://reviews.llvm.org/D46665



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

[PATCH] D47092: downgrade strong type info names to weak_odr linkage

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

rsmith created this revision.
rsmith added reviewers: EricWF, rjmccall, eli.friedman, jgorbe.
Herald added a reviewer: javed.absar.

After https://reviews.llvm.org/D46665 / https://reviews.llvm.org/rC332028, we 
now emit `linkonce_odr` definitions of type info names for incomplete class 
types. This results in formal violations of LLVM's linkage rules (which, for 
example, cause ASan's ODR violation checker to complain) if the type info name 
is declared with `external` linkage in another IR module. To solve this, 
downgrade any type info names that we would give `external` linkage to instead 
have `weak_odr` linkage. Exception: if we would emit a non-unique `type_info` 
name anyway, leave the linkage alone.

This required a bit of rearrangement: the uniqueness of the name can no longer 
depend on the linkage of the name, because the linkage of the name now depends 
on the uniqueness of the name! Fortunately, the uniqueness doesn't *really* 
depend on the linkage of the name, it only depends on the uniqueness of the 
type. I've split out the type uniqueness / name uniqueness / type_info 
uniqueness calculations to try to make this a bit clearer.


Repository:
  rC Clang

https://reviews.llvm.org/D47092

Files:
  lib/CodeGen/ItaniumCXXABI.cpp
  test/CodeGenCXX/arm64.cpp
  test/CodeGenCXX/rtti-linkage.cpp
  test/CodeGenCXX/type_visibility.cpp
  test/CodeGenCXX/vtable-available-externally.cpp
  test/CodeGenCXX/vtable-key-function-arm.cpp
  test/CodeGenCXX/vtable-linkage.cpp
  test/CodeGenCXX/windows-itanium-type-info.cpp

Index: test/CodeGenCXX/windows-itanium-type-info.cpp
===
--- test/CodeGenCXX/windows-itanium-type-info.cpp
+++ test/CodeGenCXX/windows-itanium-type-info.cpp
@@ -28,7 +28,7 @@
 // CHECK-DAG: @_ZTSi = dso_local dllexport constant
 
 // CHECK-DAG: @_ZTI7derived = dso_local dllexport constant
-// CHECK-DAG: @_ZTS7derived = dso_local dllexport constant
+// CHECK-DAG: @_ZTS7derived = weak_odr dso_local dllexport constant
 // CHECK-DAG: @_ZTV7derived = dso_local dllexport unnamed_addr constant
 
 // CHECK-DAG: @_ZTI4base = external dllimport constant
Index: test/CodeGenCXX/vtable-linkage.cpp
===
--- test/CodeGenCXX/vtable-linkage.cpp
+++ test/CodeGenCXX/vtable-linkage.cpp
@@ -106,14 +106,14 @@
 // D has a key function that is defined in this translation unit so its vtable is
 // defined in the translation unit.
 // CHECK-DAG: @_ZTV1D = unnamed_addr constant
-// CHECK-DAG: @_ZTS1D = constant
+// CHECK-DAG: @_ZTS1D = weak_odr constant
 // CHECK-DAG: @_ZTI1D = constant
 
 // E is an explicit specialization with a key function defined
 // in this translation unit, so its vtable should have external
 // linkage.
 // CHECK-DAG: @_ZTV1EIcE = unnamed_addr constant
-// CHECK-DAG: @_ZTS1EIcE = constant
+// CHECK-DAG: @_ZTS1EIcE = weak_odr constant
 // CHECK-DAG: @_ZTI1EIcE = constant
 
 // E is an explicit template instantiation with a key function
@@ -201,6 +201,18 @@
   H h;
 }
 
+// local_class()::J is local to this translation unit, so is given internal
+// linkage.
+// CHECK-DAG: @_ZTVZ11local_classvE1J = internal unnamed_addr constant
+// CHECK-DAG: @_ZTSZ11local_classvE1J = internal constant
+// CHECK-DAG: @_ZTIZ11local_classvE1J = internal constant
+void local_class() {
+  struct J {
+virtual void f() {}
+  };
+  J().f();
+}
+
 // I has an explicit instantiation declaration and needs a VTT and
 // construction vtables.
 
Index: test/CodeGenCXX/vtable-key-function-arm.cpp
===
--- test/CodeGenCXX/vtable-key-function-arm.cpp
+++ test/CodeGenCXX/vtable-key-function-arm.cpp
@@ -90,7 +90,7 @@
 // V-table should be defined with strong linkage.
 Test2a::Test2a() { use(typeid(Test2a)); }
 // CHECK:  @_ZTV6Test2a = unnamed_addr constant
-// CHECK-LATE: @_ZTS6Test2a = constant
+// CHECK-LATE: @_ZTS6Test2a = weak_odr constant
 // CHECK-LATE: @_ZTI6Test2a = constant
 
 // 'bar' becomes the key function when 'foo' is defined inline.
@@ -111,7 +111,7 @@
 // V-table should be defined with strong linkage.
 Test2b::Test2b() { use(typeid(Test2b)); }
 // CHECK:  @_ZTV6Test2b = unnamed_addr constant
-// CHECK-LATE: @_ZTS6Test2b = constant
+// CHECK-LATE: @_ZTS6Test2b = weak_odr constant
 // CHECK-LATE: @_ZTI6Test2b = constant
 
 inline void Test2b::foo() {}
@@ -131,7 +131,7 @@
 // V-table should be defined with strong linkage.
 Test2c::Test2c() { use(typeid(Test2c)); }
 // CHECK: @_ZTV6Test2c = unnamed_addr constant
-// CHECK: @_ZTS6Test2c = constant
+// CHECK: @_ZTS6Test2c = weak_odr constant
 // CHECK: @_ZTI6Test2c = constant
 
 /*** Test3a **/
Index: test/CodeGenCXX/vtable-available-externally.cpp
===
--- test/CodeGenCXX/vtable-available-externally.cpp
+++ test/CodeGenCXX/vtable-available-ext

[libcxx] r332779 - Disable 'missing-braces' warning

[Marshall Clow via cfe-commits]

Author: marshall
Date: Fri May 18 15:21:33 2018
New Revision: 332779

URL: http://llvm.org/viewvc/llvm-project?rev=332779&view=rev
Log:
Disable 'missing-braces' warning

Modified:
libcxx/trunk/test/std/containers/sequences/array/array.cons/deduct.fail.cpp
libcxx/trunk/test/std/containers/sequences/array/array.cons/deduct.pass.cpp

Modified: 
libcxx/trunk/test/std/containers/sequences/array/array.cons/deduct.fail.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/sequences/array/array.cons/deduct.fail.cpp?rev=332779&r1=332778&r2=332779&view=diff
==
--- libcxx/trunk/test/std/containers/sequences/array/array.cons/deduct.fail.cpp 
(original)
+++ libcxx/trunk/test/std/containers/sequences/array/array.cons/deduct.fail.cpp 
Fri May 18 15:21:33 2018
@@ -22,6 +22,11 @@
 #include 
 #include 
 
+// std::array is explicitly allowed to be initialized with A a = { init-list 
};.
+// Disable the missing braces warning for this reason.
+#include "disable_missing_braces_warning.h"
+
+
 #include "test_macros.h"
 
 int main()

Modified: 
libcxx/trunk/test/std/containers/sequences/array/array.cons/deduct.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/sequences/array/array.cons/deduct.pass.cpp?rev=332779&r1=332778&r2=332779&view=diff
==
--- libcxx/trunk/test/std/containers/sequences/array/array.cons/deduct.pass.cpp 
(original)
+++ libcxx/trunk/test/std/containers/sequences/array/array.cons/deduct.pass.cpp 
Fri May 18 15:21:33 2018
@@ -22,6 +22,10 @@
 #include 
 #include 
 
+// std::array is explicitly allowed to be initialized with A a = { init-list 
};.
+// Disable the missing braces warning for this reason.
+#include "disable_missing_braces_warning.h"
+
 #include "test_macros.h"
 
 int main()


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

[PATCH] D44539: [Sema][Objective-C] Add check to warn when property of objc type has assign attribute

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

This isn't really an Objective-C user forum, but I'll try to summarize briefly. 
 `unsafe_unretained` is an unsafe version of `weak` — it's unsafe because it 
can be left dangling if the object is deallocated.  It's necessary for a small 
(and getting smaller every year) set of classes that don't support true weak 
references, and it can be useful as an optimization to avoid the performance 
overhead of reference counting.


Repository:
  rC Clang

https://reviews.llvm.org/D44539



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

[PATCH] D45212: [HIP] Let CUDA toolchain support HIP language mode and amdgpu

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

Hi,

Sorry about the long silence. I'm back to continue the reviews. I'll handle 
what I can today and will continue with the rest on Tuesday.

It looks like patch description needs to be updated:

> Use clang-offload-bindler to create binary for device ISA.

I don't see anything related to offload-bundler in this patch any more.




Comment at: include/clang/Driver/Options.td:582
 def fno_cuda_rdc : Flag<["-"], "fno-cuda-rdc">;
+def hip_device_lib_path_EQ : Joined<["--"], "hip-device-lib-path=">, 
Group,
+  HelpText<"HIP device library path">;

I'm not sure about `i_Group`? This will cause this option to be passed to all 
preprocessor jobs. It will also be passed to host and device side compilations, 
while you probably only want/need it on device side only.



Comment at: lib/Driver/ToolChains/Cuda.cpp:323
+C.getDriver().Diag(diag::err_drv_no_such_file) << BCName;
+  CmdArgs.push_back(Args.MakeArgString(FullName));
+  return FoundLibDevice;

FullName is already result of Args.MakeArgString. You only need to do it once.



Comment at: lib/Driver/ToolChains/Cuda.cpp:329
+// object file. It calls llvm-link, opt, llc, then lld steps.
+void AMDGCN::Linker::ConstructJob(Compilation &C, const JobAction &JA,
+  const InputInfo &Output,

This function is too large to easily see that we're actually constructing 
sequence of commands.
I'd probably split construction of individual tool's command line into its own 
function.



Comment at: lib/Driver/ToolChains/Cuda.cpp:336
+  assert(StringRef(JA.getOffloadingArch()).startswith("gfx") &&
+ " unless gfx processor, backend should be clang");
+  const auto &TC =

No need for the leading space in the message.



Comment at: lib/Driver/ToolChains/Cuda.cpp:344-345
+  // Add the input bc's created by compile step.
+  for (InputInfoList::const_iterator it = Inputs.begin(), ie = Inputs.end();
+   it != ie; ++it) {
+const InputInfo &II = *it;

`for (const InputInfo &it : Inputs)` ?



Comment at: lib/Driver/ToolChains/Cuda.cpp:350
+
+  std::string GFXNAME = JA.getOffloadingArch();
+

All-caps name looks like a macro. Rename to `GfxName` ?



Comment at: lib/Driver/ToolChains/Cuda.cpp:354-359
+  // Find in --hip-device-lib-path and HIP_LIBRARY_PATH.
+  for (auto Arg : Args) {
+if (Arg->getSpelling() == "--hip-device-lib-path=") {
+  LibraryPaths.push_back(Args.MakeArgString(Arg->getValue()));
+}
+  }

```
for (path : Args.getAllArgValues(...)) {
   LibraryPaths.push_back(Args.MakeArgString(path));
}

```



Comment at: lib/Driver/ToolChains/Cuda.cpp:375-378
+  addBCLib(C, Args, CmdArgs, LibraryPaths,
+   (Twine("oclc_isa_version_") + StringRef(GFXNAME).drop_front(3) +
+".amdgcn.bc")
+   .str());

This is somewhat unreadable. Perhaps you could construct the name in a temp 
variable.



Comment at: lib/Driver/ToolChains/Cuda.cpp:384
+  const char *ResultingBitcodeF =
+  C.addTempFile(C.getArgs().MakeArgString(TmpName.c_str()));
+  CmdArgs.push_back(ResultingBitcodeF);

You don't need to use c_str() for MakeArgString. It will happily accept 
std::string.



Comment at: lib/Driver/ToolChains/Cuda.cpp:394
+  // The input to opt is the output from llvm-link.
+  OptArgs.push_back(ResultingBitcodeF);
+  // Pass optimization arg to opt.

`BitcodeOutputFile`?



Comment at: lib/Driver/ToolChains/Cuda.cpp:417
+  const char *mcpustr = Args.MakeArgString("-mcpu=" + GFXNAME);
+  OptArgs.push_back(mcpustr);
+  OptArgs.push_back("-o");

I think you can get rid of the temp var here without hurting readability.



Comment at: lib/Driver/ToolChains/Cuda.cpp:420
+  std::string OptOutputFileName =
+  C.getDriver().GetTemporaryPath("OPT_OUTPUT", "bc");
+  const char *OptOutputFile =

I wonder if we could derive temp file name from the input's name. This may make 
it easier to find relevant temp files if/when we need to debug the compilation 
process.



Comment at: lib/Driver/ToolChains/Cuda.cpp:422
+  const char *OptOutputFile =
+  C.addTempFile(C.getArgs().MakeArgString(OptOutputFileName.c_str()));
+  OptArgs.push_back(OptOutputFile);

No need for c_str() here.



Comment at: lib/Driver/ToolChains/Cuda.cpp:439
+  const char *LlcOutputFile =
+  C.addTempFile(C.getArgs().MakeArgString(LlcOutputFileName.c_str()));
+  LlcArgs.push_back(LlcOutputFile);

c_str(), again.



Comment at: lib/Driver/ToolChains/Cuda.cpp:764
+  if (DriverArgs.hasArg(options::OPT_nocudalib) ||
+  DeviceOffloadingKind == Action::OFK_HIP)

r332777 - [test] Fix run line to use correct triple

[Shoaib Meenai via cfe-commits]

Author: smeenai
Date: Fri May 18 14:59:29 2018
New Revision: 332777

URL: http://llvm.org/viewvc/llvm-project?rev=332777&view=rev
Log:
[test] Fix run line to use correct triple

objc_begin_catch/objc_end_catch are specific to the Itanium ABI, so we
should be using an Itanium triple for this test.

Additionally, while I'm here, convert the run line to invoke the
compiler directly rather than going through the driver.

Modified:
cfe/trunk/test/CodeGenObjC/runtime-abi-match.m

Modified: cfe/trunk/test/CodeGenObjC/runtime-abi-match.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenObjC/runtime-abi-match.m?rev=332777&r1=332776&r2=332777&view=diff
==
--- cfe/trunk/test/CodeGenObjC/runtime-abi-match.m (original)
+++ cfe/trunk/test/CodeGenObjC/runtime-abi-match.m Fri May 18 14:59:29 2018
@@ -1,4 +1,4 @@
-// RUN: %clang -target armv7-windows -fobjc-runtime=ios -O1 -fexceptions -S 
-emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -triple thumbv7--windows-itanium -fobjc-runtime=ios -O1 
-fexceptions -fobjc-exceptions -emit-llvm %s -o - | FileCheck %s
 // REQUIRES: arm-registered-target
 
 void (*f)(id);


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

[PATCH] D46915: [Fixed Point Arithmetic] Set Fixed Point Precision Bits and Create Fixed Point Literals

[Leonard Chan via Phabricator via cfe-commits]

leonardchan updated this revision to Diff 147595.
leonardchan added a comment.

formatting


Repository:
  rC Clang

https://reviews.llvm.org/D46915

Files:
  CMakeLists.txt
  cmake/modules/InitFixedPointBits.cmake
  include/clang/AST/Expr.h
  include/clang/AST/OperationKinds.def
  include/clang/AST/RecursiveASTVisitor.h
  include/clang/AST/Type.h
  include/clang/Basic/DiagnosticCommonKinds.td
  include/clang/Basic/FixedPoint.h.in
  include/clang/Basic/StmtNodes.td
  include/clang/Lex/LiteralSupport.h
  lib/AST/ASTContext.cpp
  lib/AST/ASTDumper.cpp
  lib/AST/Expr.cpp
  lib/AST/ExprClassification.cpp
  lib/AST/ExprConstant.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/StmtPrinter.cpp
  lib/AST/StmtProfile.cpp
  lib/AST/Type.cpp
  lib/CodeGen/CGExpr.cpp
  lib/CodeGen/CGExprAgg.cpp
  lib/CodeGen/CGExprComplex.cpp
  lib/CodeGen/CGExprConstant.cpp
  lib/CodeGen/CGExprScalar.cpp
  lib/Edit/RewriteObjCFoundationAPI.cpp
  lib/Lex/LiteralSupport.cpp
  lib/Sema/Sema.cpp
  lib/Sema/SemaExceptionSpec.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReaderStmt.cpp
  lib/Serialization/ASTWriterStmt.cpp
  lib/StaticAnalyzer/Core/ExprEngine.cpp
  lib/StaticAnalyzer/Core/ExprEngineC.cpp
  test/Frontend/fixed_point.c
  test/Frontend/fixed_point_declarations.c
  test/Frontend/fixed_point_errors.c
  test/Frontend/fixed_point_validation.c
  tools/libclang/CXCursor.cpp

Index: tools/libclang/CXCursor.cpp
===
--- tools/libclang/CXCursor.cpp
+++ tools/libclang/CXCursor.cpp
@@ -305,6 +305,10 @@
 K = CXCursor_IntegerLiteral;
 break;
 
+  case Stmt::FixedPointLiteralClass:
+llvm_unreachable("No cursor for FixedPointLiteralClass");
+break;
+
   case Stmt::FloatingLiteralClass:
 K = CXCursor_FloatingLiteral;
 break;
Index: test/Frontend/fixed_point_validation.c
===
--- /dev/null
+++ test/Frontend/fixed_point_validation.c
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 -S -emit-llvm -o - %s | lli
+
+// Run simple validation tests
+
+#define assert(b) if (!(b)) { return 1; }
+
+int main(){
+  short _Accum s_accum;
+  short _Accum s_accum2 = 2.0hk;
+  short _Fract s_fract = 0.999hr;
+  short _Fract s_fract2 = -0.999hr;
+
+  assert(s_accum == 0);
+
+  s_accum = s_accum2;
+
+  assert(s_accum == s_accum2);
+  assert(s_accum == 2);
+}
Index: test/Frontend/fixed_point_errors.c
===
--- test/Frontend/fixed_point_errors.c
+++ test/Frontend/fixed_point_errors.c
@@ -1,14 +1,23 @@
 // RUN: %clang_cc1 -x c -fsyntax-only -verify -pedantic %s
 
-long long _Accum longlong_accum;  // expected-error{{'long long _Accum' is invalid}}
-unsigned long long _Accum u_longlong_accum;  // expected-error{{'long long _Accum' is invalid}}
-long long _Fract longlong_fract;  // expected-error{{'long long _Fract' is invalid}}
-unsigned long long _Fract u_longlong_fract;  // expected-error{{'long long _Fract' is invalid}}
+long long _Accum longlong_accum;  // expected-error{{'long long _Accum' is invalid}}
+unsigned long long _Accum u_longlong_accum;   // expected-error{{'long long _Accum' is invalid}}
+long long _Fract longlong_fract;  // expected-error{{'long long _Fract' is invalid}}
+unsigned long long _Fract u_longlong_fract;   // expected-error{{'long long _Fract' is invalid}}
 
 _Sat int i;  // expected-error{{'int' cannot be saturated. Only _Fract and _Accum can.}}
 _Sat _Sat _Fract fract;  // expected-warning{{duplicate '_Sat' declaration specifier}}
 
-_Sat long long _Accum sat_longlong_accum;  // expected-error{{'long long _Accum' is invalid}}
+_Sat long long _Accum sat_longlong_accum; // expected-error{{'long long _Accum' is invalid}}
 _Sat unsigned long long _Accum sat_u_longlong_accum;  // expected-error{{'long long _Accum' is invalid}}
-_Sat long long _Fract sat_longlong_fract;  // expected-error{{'long long _Fract' is invalid}}
+_Sat long long _Fract sat_longlong_fract; // expected-error{{'long long _Fract' is invalid}}
 _Sat unsigned long long _Fract sat_u_longlong_fract;  // expected-error{{'long long _Fract' is invalid}}
+
+short _Fract fract2 = 1.2hr;  // expected-error{{a _Fract type cannot have an integral part}}
+
+signed short _Accum s_short_accum = 129.0hk;  // expected-error{{the integral part of this literal is too large for this signed _Accum type}}
+unsigned short _Accum u_short_accum = 256.0uhk;   // expected-error{{the integral part of this literal is too large for this unsigned _Accum type}}
+signed _Accum s_accum = 32770.0k; // expected-error{{the integral part of this literal is too large for this signed _Accum type}}
+unsigned _Accum u_accum = 65536.0uk;  // expected-error{{the integral part of this literal is too large for this unsigned _Accum type}}
+short _Accum short_accum = 129.0hk;   // expected-error{{the integr

[PATCH] D47084: Maintain PS4 ABI compatibility

[Douglas Yung via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL332773: Maintain PS4 ABI compatibility by making the fix 
made in r331136 not apply when… (authored by dyung, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D47084?vs=147571&id=147596#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D47084

Files:
  cfe/trunk/lib/AST/RecordLayoutBuilder.cpp
  cfe/trunk/test/CodeGenCXX/alignment.cpp


Index: cfe/trunk/test/CodeGenCXX/alignment.cpp
===
--- cfe/trunk/test/CodeGenCXX/alignment.cpp
+++ cfe/trunk/test/CodeGenCXX/alignment.cpp
@@ -1,5 +1,6 @@
 // RUN: %clang_cc1 %s -emit-llvm -o - -triple=x86_64-apple-darwin10 | 
FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-NOCOMPAT
 // RUN: %clang_cc1 %s -emit-llvm -o - -triple=x86_64-apple-darwin10 
-fclang-abi-compat=6.0 | FileCheck %s --check-prefix=CHECK 
--check-prefix=CHECK-V6COMPAT
+// RUN: %clang_cc1 %s -emit-llvm -o - -triple=x86_64-scei-ps4 | FileCheck %s 
--check-prefix=CHECK --check-prefix=CHECK-V6COMPAT
 
 extern int int_source();
 extern void int_sink(int x);
Index: cfe/trunk/lib/AST/RecordLayoutBuilder.cpp
===
--- cfe/trunk/lib/AST/RecordLayoutBuilder.cpp
+++ cfe/trunk/lib/AST/RecordLayoutBuilder.cpp
@@ -1178,10 +1178,12 @@
   // Clang <= 6 incorrectly applied the 'packed' attribute to base classes.
   // Per GCC's documentation, it only applies to non-static data members.
   CharUnits UnpackedBaseAlign = Layout.getNonVirtualAlignment();
-  CharUnits BaseAlign = (Packed && Context.getLangOpts().getClangABICompat() <=
-   LangOptions::ClangABI::Ver6)
-? CharUnits::One()
-: UnpackedBaseAlign;
+  CharUnits BaseAlign =
+  (Packed && ((Context.getLangOpts().getClangABICompat() <=
+   LangOptions::ClangABI::Ver6) ||
+  Context.getTargetInfo().getTriple().isPS4()))
+  ? CharUnits::One()
+  : UnpackedBaseAlign;
 
   // If we have an empty base class, try to place it at offset 0.
   if (Base->Class->isEmpty() &&


Index: cfe/trunk/test/CodeGenCXX/alignment.cpp
===
--- cfe/trunk/test/CodeGenCXX/alignment.cpp
+++ cfe/trunk/test/CodeGenCXX/alignment.cpp
@@ -1,5 +1,6 @@
 // RUN: %clang_cc1 %s -emit-llvm -o - -triple=x86_64-apple-darwin10 | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-NOCOMPAT
 // RUN: %clang_cc1 %s -emit-llvm -o - -triple=x86_64-apple-darwin10 -fclang-abi-compat=6.0 | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-V6COMPAT
+// RUN: %clang_cc1 %s -emit-llvm -o - -triple=x86_64-scei-ps4 | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-V6COMPAT
 
 extern int int_source();
 extern void int_sink(int x);
Index: cfe/trunk/lib/AST/RecordLayoutBuilder.cpp
===
--- cfe/trunk/lib/AST/RecordLayoutBuilder.cpp
+++ cfe/trunk/lib/AST/RecordLayoutBuilder.cpp
@@ -1178,10 +1178,12 @@
   // Clang <= 6 incorrectly applied the 'packed' attribute to base classes.
   // Per GCC's documentation, it only applies to non-static data members.
   CharUnits UnpackedBaseAlign = Layout.getNonVirtualAlignment();
-  CharUnits BaseAlign = (Packed && Context.getLangOpts().getClangABICompat() <=
-   LangOptions::ClangABI::Ver6)
-? CharUnits::One()
-: UnpackedBaseAlign;
+  CharUnits BaseAlign =
+  (Packed && ((Context.getLangOpts().getClangABICompat() <=
+   LangOptions::ClangABI::Ver6) ||
+  Context.getTargetInfo().getTriple().isPS4()))
+  ? CharUnits::One()
+  : UnpackedBaseAlign;
 
   // If we have an empty base class, try to place it at offset 0.
   if (Base->Class->isEmpty() &&
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r332773 - Maintain PS4 ABI compatibility by making the fix made in r331136 not apply when the target is the PS4.

[Douglas Yung via cfe-commits]

Author: dyung
Date: Fri May 18 14:51:46 2018
New Revision: 332773

URL: http://llvm.org/viewvc/llvm-project?rev=332773&view=rev
Log:
Maintain PS4 ABI compatibility by making the fix made in r331136 not apply when 
the target is the PS4.

Reviewers: rsmith

Subscribers: cfe-commits

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


Modified:
cfe/trunk/lib/AST/RecordLayoutBuilder.cpp
cfe/trunk/test/CodeGenCXX/alignment.cpp

Modified: cfe/trunk/lib/AST/RecordLayoutBuilder.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/RecordLayoutBuilder.cpp?rev=332773&r1=332772&r2=332773&view=diff
==
--- cfe/trunk/lib/AST/RecordLayoutBuilder.cpp (original)
+++ cfe/trunk/lib/AST/RecordLayoutBuilder.cpp Fri May 18 14:51:46 2018
@@ -1178,10 +1178,12 @@ ItaniumRecordLayoutBuilder::LayoutBase(c
   // Clang <= 6 incorrectly applied the 'packed' attribute to base classes.
   // Per GCC's documentation, it only applies to non-static data members.
   CharUnits UnpackedBaseAlign = Layout.getNonVirtualAlignment();
-  CharUnits BaseAlign = (Packed && Context.getLangOpts().getClangABICompat() <=
-   LangOptions::ClangABI::Ver6)
-? CharUnits::One()
-: UnpackedBaseAlign;
+  CharUnits BaseAlign =
+  (Packed && ((Context.getLangOpts().getClangABICompat() <=
+   LangOptions::ClangABI::Ver6) ||
+  Context.getTargetInfo().getTriple().isPS4()))
+  ? CharUnits::One()
+  : UnpackedBaseAlign;
 
   // If we have an empty base class, try to place it at offset 0.
   if (Base->Class->isEmpty() &&

Modified: cfe/trunk/test/CodeGenCXX/alignment.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/alignment.cpp?rev=332773&r1=332772&r2=332773&view=diff
==
--- cfe/trunk/test/CodeGenCXX/alignment.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/alignment.cpp Fri May 18 14:51:46 2018
@@ -1,5 +1,6 @@
 // RUN: %clang_cc1 %s -emit-llvm -o - -triple=x86_64-apple-darwin10 | 
FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-NOCOMPAT
 // RUN: %clang_cc1 %s -emit-llvm -o - -triple=x86_64-apple-darwin10 
-fclang-abi-compat=6.0 | FileCheck %s --check-prefix=CHECK 
--check-prefix=CHECK-V6COMPAT
+// RUN: %clang_cc1 %s -emit-llvm -o - -triple=x86_64-scei-ps4 | FileCheck %s 
--check-prefix=CHECK --check-prefix=CHECK-V6COMPAT
 
 extern int int_source();
 extern void int_sink(int x);


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

[PATCH] D47029: [X86] Remove some preprocessor feature checks from intrinsic headers

[David Kreitzer via Phabricator via cfe-commits]

DavidKreitzer added a comment.

Looks right to me, Craig.


https://reviews.llvm.org/D47029



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

Re: r332720 - Move #include manipulation code to new lib/Tooling/Inclusions.

[Eric Liu via cfe-commits]

Sorry about the bad naming... I hope I could come up with something less
confusing. Thanks for the clarification!

On Fri, May 18, 2018 at 11:25 PM David Blaikie  wrote:

>
>
> On Fri, May 18, 2018 at 2:22 PM Eric Liu  wrote:
>
>> Thanks a lot for looking into this Bruno! The fix looks promising; I'll
>> give it a try next week :D
>>
>> On Fri, May 18, 2018 at 10:33 PM David Blaikie via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> I haven't looked in detail here, but in general: Don't split an
>>> implementation and its headers into different notional libraries, as that
>>> breaks modular code generation (an implementation and its headers usually
>>> have circular dependencies - inline functions that call non-inline
>>> functions, and the other way around & so if they're in two different
>>> libraries they won't be able to link (due to the way unix linkers
>>> work/dependencies are resolved in a single pass, never looping back around).
>>>
>> David, I'm not exactly sure if I understand... This change pulls both
>> declarations and implementations into a self-contained library which could
>> be shared by clang-format and other tools that manipulate #includes. This
>> seems to be a normal refactoring, and I hope this doesn't break modular
>> code generation.
>>
>
> Sounds OK - so long as both header and implementation go together is all.
>
> (by the name "Inclusions" I was worried maybe just the headers had been
> pulled out, but not their implementation)
>
>
>>
>>> On Fri, May 18, 2018 at 1:10 PM Bruno Cardoso Lopes via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>


 On Fri, May 18, 2018 at 12:46 PM Bruno Cardoso Lopes <
 bruno.card...@gmail.com> wrote:

>
>
> On Fri, May 18, 2018 at 11:54 AM Vedant Kumar via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On May 18, 2018, at 11:48 AM, Eric Liu  wrote:
>>
>>
>> So I have reverted this with r332751.
>>
>>
>> Thanks!
>>
>>
>> I can't see how this introduced cyclic dependencies in module build,
>> as the dependencies should be clangTooling -> clangFormat ->
>> clangToolingInclusions. I'm wondering if there is any module 
>> configurations
>> that I need to update to make this work. Right now, module doesn't seem 
>> to
>> make any difference between clangTooling and clangToolingInclusions...
>> I'd appreciate it if someone who knows how clang module build is set up
>> could help take a look.
>>
>>
>> + Bruno & David who have more experience in this area than I do.
>>
>
> Gonna try to reproduce and take a look!
>

 I could reproduce it. You should be good to go if you add another top
 level module for Inclusions (and break the dep):

 --- a/include/clang/module.modulemap
 +++ b/include/clang/module.modulemap
 @@ -153,3 +153,8 @@ module Clang_ToolingCore {
requires cplusplus
umbrella "Tooling/Core" module * { export * }
  }
 +
 +module Clang_ToolingInclusions {
 +  requires cplusplus
 +  umbrella "Tooling/Inclusions" module * { export * }
 +}

 --
 Bruno Cardoso Lopes
 http://www.brunocardoso.cc
 ___
 cfe-commits mailing list
 cfe-commits@lists.llvm.org
 http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

Re: r332720 - Move #include manipulation code to new lib/Tooling/Inclusions.

[David Blaikie via cfe-commits]

On Fri, May 18, 2018 at 2:22 PM Eric Liu  wrote:

> Thanks a lot for looking into this Bruno! The fix looks promising; I'll
> give it a try next week :D
>
> On Fri, May 18, 2018 at 10:33 PM David Blaikie via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> I haven't looked in detail here, but in general: Don't split an
>> implementation and its headers into different notional libraries, as that
>> breaks modular code generation (an implementation and its headers usually
>> have circular dependencies - inline functions that call non-inline
>> functions, and the other way around & so if they're in two different
>> libraries they won't be able to link (due to the way unix linkers
>> work/dependencies are resolved in a single pass, never looping back around).
>>
> David, I'm not exactly sure if I understand... This change pulls both
> declarations and implementations into a self-contained library which could
> be shared by clang-format and other tools that manipulate #includes. This
> seems to be a normal refactoring, and I hope this doesn't break modular
> code generation.
>

Sounds OK - so long as both header and implementation go together is all.

(by the name "Inclusions" I was worried maybe just the headers had been
pulled out, but not their implementation)


>
>> On Fri, May 18, 2018 at 1:10 PM Bruno Cardoso Lopes via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>>
>>>
>>> On Fri, May 18, 2018 at 12:46 PM Bruno Cardoso Lopes <
>>> bruno.card...@gmail.com> wrote:
>>>


 On Fri, May 18, 2018 at 11:54 AM Vedant Kumar via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> On May 18, 2018, at 11:48 AM, Eric Liu  wrote:
>
>
> So I have reverted this with r332751.
>
>
> Thanks!
>
>
> I can't see how this introduced cyclic dependencies in module build,
> as the dependencies should be clangTooling -> clangFormat ->
> clangToolingInclusions. I'm wondering if there is any module 
> configurations
> that I need to update to make this work. Right now, module doesn't seem to
> make any difference between clangTooling and clangToolingInclusions...
> I'd appreciate it if someone who knows how clang module build is set up
> could help take a look.
>
>
> + Bruno & David who have more experience in this area than I do.
>

 Gonna try to reproduce and take a look!

>>>
>>> I could reproduce it. You should be good to go if you add another top
>>> level module for Inclusions (and break the dep):
>>>
>>> --- a/include/clang/module.modulemap
>>> +++ b/include/clang/module.modulemap
>>> @@ -153,3 +153,8 @@ module Clang_ToolingCore {
>>>requires cplusplus
>>>umbrella "Tooling/Core" module * { export * }
>>>  }
>>> +
>>> +module Clang_ToolingInclusions {
>>> +  requires cplusplus
>>> +  umbrella "Tooling/Inclusions" module * { export * }
>>> +}
>>>
>>> --
>>> Bruno Cardoso Lopes
>>> http://www.brunocardoso.cc
>>> ___
>>> cfe-commits mailing list
>>> cfe-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r332720 - Move #include manipulation code to new lib/Tooling/Inclusions.

[Eric Liu via cfe-commits]

Thanks a lot for looking into this Bruno! The fix looks promising; I'll
give it a try next week :D

On Fri, May 18, 2018 at 10:33 PM David Blaikie via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> I haven't looked in detail here, but in general: Don't split an
> implementation and its headers into different notional libraries, as that
> breaks modular code generation (an implementation and its headers usually
> have circular dependencies - inline functions that call non-inline
> functions, and the other way around & so if they're in two different
> libraries they won't be able to link (due to the way unix linkers
> work/dependencies are resolved in a single pass, never looping back around).
>
David, I'm not exactly sure if I understand... This change pulls both
declarations and implementations into a self-contained library which could
be shared by clang-format and other tools that manipulate #includes. This
seems to be a normal refactoring, and I hope this doesn't break modular
code generation.

>
> On Fri, May 18, 2018 at 1:10 PM Bruno Cardoso Lopes via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>>
>>
>> On Fri, May 18, 2018 at 12:46 PM Bruno Cardoso Lopes <
>> bruno.card...@gmail.com> wrote:
>>
>>>
>>>
>>> On Fri, May 18, 2018 at 11:54 AM Vedant Kumar via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 On May 18, 2018, at 11:48 AM, Eric Liu  wrote:


 So I have reverted this with r332751.


 Thanks!


 I can't see how this introduced cyclic dependencies in module build, as
 the dependencies should be clangTooling -> clangFormat ->
 clangToolingInclusions. I'm wondering if there is any module configurations
 that I need to update to make this work. Right now, module doesn't seem to
 make any difference between clangTooling and clangToolingInclusions...
 I'd appreciate it if someone who knows how clang module build is set up
 could help take a look.


 + Bruno & David who have more experience in this area than I do.

>>>
>>> Gonna try to reproduce and take a look!
>>>
>>
>> I could reproduce it. You should be good to go if you add another top
>> level module for Inclusions (and break the dep):
>>
>> --- a/include/clang/module.modulemap
>> +++ b/include/clang/module.modulemap
>> @@ -153,3 +153,8 @@ module Clang_ToolingCore {
>>requires cplusplus
>>umbrella "Tooling/Core" module * { export * }
>>  }
>> +
>> +module Clang_ToolingInclusions {
>> +  requires cplusplus
>> +  umbrella "Tooling/Inclusions" module * { export * }
>> +}
>>
>> --
>> Bruno Cardoso Lopes
>> http://www.brunocardoso.cc
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D47070: [CUDA] Upgrade linked bitcode to enable inlining

[Jonas Hahnfeld via Phabricator via cfe-commits]

Hahnfeld added a comment.

I think that's intended because the generated code might use instructions based 
on that feature. If we want to ignore that, we could override 
`TargetTransformInfo::areInlineCompatible` for NVPTX to only compare 
`target-cpu`


Repository:
  rC Clang

https://reviews.llvm.org/D47070



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

[PATCH] D44539: [Sema][Objective-C] Add check to warn when property of objc type has assign attribute

[Yan Zhang via Phabricator via cfe-commits]

Wizard added a comment.

Is there any case for property of ObjC types that we should use 
`unsafe_unretained` or `assign` rather than `weak`? In my understanding, `weak` 
is for properties of ObjC types as the replacement of `unsafe_unretained` and 
`assign` is for properties of primitive types.


Repository:
  rC Clang

https://reviews.llvm.org/D44539



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

[PATCH] D46740: [Clang Tablegen][RFC] Allow Early Textual Substitutions in `Diagnostic` messages.

[Eric Fiselier via Phabricator via cfe-commits]

EricWF updated this revision to Diff 147581.
EricWF marked an inline comment as done.
EricWF added a comment.

- Add error if a substitution and a diagnostic share the same name.

Any final comments on this?


https://reviews.llvm.org/D46740

Files:
  docs/InternalsManual.rst
  include/clang/Basic/Diagnostic.td
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Basic/Diagnostic.cpp
  lib/Sema/SemaOverload.cpp
  test/SemaCXX/anonymous-struct.cpp
  test/SemaCXX/cxx1y-generic-lambdas.cpp
  test/SemaCXX/cxx98-compat.cpp
  test/TableGen/DiagnosticBase.inc
  test/TableGen/DiagnosticDocs.inc
  test/TableGen/emit-diag-docs.td
  test/TableGen/text-substitution.td
  test/lit.cfg.py
  utils/TableGen/ClangDiagnosticsEmitter.cpp

Index: utils/TableGen/ClangDiagnosticsEmitter.cpp
===
--- utils/TableGen/ClangDiagnosticsEmitter.cpp
+++ utils/TableGen/ClangDiagnosticsEmitter.cpp
@@ -14,12 +14,13 @@
 #include "llvm/ADT/DenseSet.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/PointerUnion.h"
+#include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/SmallPtrSet.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/ADT/StringMap.h"
-#include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/Twine.h"
+#include "llvm/Support/Casting.h"
 #include "llvm/TableGen/Error.h"
 #include "llvm/TableGen/Record.h"
 #include "llvm/TableGen/StringToOffsetTable.h"
@@ -441,6 +442,733 @@
   }
 }
 
+namespace {
+enum PieceKind {
+  MultiPieceClass,
+  TextPieceClass,
+  PlaceholderPieceClass,
+  SelectPieceClass,
+  PluralPieceClass,
+  DiffPieceClass,
+  SubstitutionPieceClass,
+};
+
+enum ModifierType {
+  MT_Unknown,
+  MT_Placeholder,
+  MT_Select,
+  MT_Sub,
+  MT_Plural,
+  MT_Diff,
+  MT_Ordinal,
+  MT_S,
+  MT_Q,
+  MT_ObjCClass,
+  MT_ObjCInstance,
+};
+
+static StringRef getModifierName(ModifierType MT) {
+  switch (MT) {
+  case MT_Select:
+return "select";
+  case MT_Sub:
+return "sub";
+  case MT_Diff:
+return "diff";
+  case MT_Plural:
+return "plural";
+  case MT_Ordinal:
+return "ordinal";
+  case MT_S:
+return "s";
+  case MT_Q:
+return "q";
+  case MT_Placeholder:
+return "";
+  case MT_ObjCClass:
+return "objcclass";
+  case MT_ObjCInstance:
+return "objcinstance";
+  case MT_Unknown:
+llvm_unreachable("invalid modifier type");
+  }
+}
+
+struct Piece {
+  // This type and its derived classes are move-only.
+  Piece(PieceKind Kind) : ClassKind(Kind) {}
+  Piece(Piece const &O) = delete;
+  Piece &operator=(Piece const &) = delete;
+  virtual ~Piece() {}
+
+  PieceKind getPieceClass() const { return ClassKind; }
+  static bool classof(const Piece *) { return true; }
+
+private:
+  PieceKind ClassKind;
+};
+
+struct MultiPiece : Piece {
+  MultiPiece() : Piece(MultiPieceClass) {}
+  MultiPiece(std::vector Pieces)
+  : Piece(MultiPieceClass), Pieces(std::move(Pieces)) {}
+
+  std::vector Pieces;
+
+  static bool classof(const Piece *P) {
+return P->getPieceClass() == MultiPieceClass;
+  }
+};
+
+struct TextPiece : Piece {
+  StringRef Role;
+  std::string Text;
+  TextPiece(StringRef Text, StringRef Role = "")
+  : Piece(TextPieceClass), Role(Role), Text(Text.str()) {}
+
+  static bool classof(const Piece *P) {
+return P->getPieceClass() == TextPieceClass;
+  }
+};
+
+struct PlaceholderPiece : Piece {
+  ModifierType Kind;
+  int Index;
+  PlaceholderPiece(ModifierType Kind, int Index)
+  : Piece(PlaceholderPieceClass), Kind(Kind), Index(Index) {}
+
+  static bool classof(const Piece *P) {
+return P->getPieceClass() == PlaceholderPieceClass;
+  }
+};
+
+struct SelectPiece : Piece {
+protected:
+  SelectPiece(PieceKind Kind, ModifierType ModKind)
+  : Piece(Kind), ModKind(ModKind) {}
+
+public:
+  SelectPiece(ModifierType ModKind) : SelectPiece(SelectPieceClass, ModKind) {}
+
+  ModifierType ModKind;
+  std::vector Options;
+  int Index;
+
+  static bool classof(const Piece *P) {
+return P->getPieceClass() == SelectPieceClass ||
+   P->getPieceClass() == PluralPieceClass;
+  }
+};
+
+struct PluralPiece : SelectPiece {
+  PluralPiece() : SelectPiece(PluralPieceClass, MT_Plural) {}
+
+  std::vector OptionPrefixes;
+  int Index;
+
+  static bool classof(const Piece *P) {
+return P->getPieceClass() == PluralPieceClass;
+  }
+};
+
+struct DiffPiece : Piece {
+  DiffPiece() : Piece(DiffPieceClass) {}
+
+  Piece *Options[2] = {};
+  int Indexes[2] = {};
+
+  static bool classof(const Piece *P) {
+return P->getPieceClass() == DiffPieceClass;
+  }
+};
+
+struct SubstitutionPiece : Piece {
+  SubstitutionPiece() : Piece(SubstitutionPieceClass) {}
+
+  std::string Name;
+  std::vector Modifiers;
+
+  static bool classof(const Piece *P) {
+return P->getPieceClass() == SubstitutionPieceClass;
+  }
+};
+
+/// Diagnostic text, parsed into pieces.
+
+
+struct DiagnosticTextBuilder {
+  DiagnosticTextBuilder(DiagnosticTextBuilder const &) = delete;
+  Diagnosti

[PATCH] D46740: [Clang Tablegen][RFC] Allow Early Textual Substitutions in `Diagnostic` messages.

[Eric Fiselier via Phabricator via cfe-commits]

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



Comment at: utils/TableGen/ClangDiagnosticsEmitter.cpp:514
+  std::vector Diags = Records.getAllDerivedDefinitions("Diagnostic");
+  llvm::for_each(Diags, [&](Record *R) { substituteDiagText(R, SubsMap); });
 

rjmccall wrote:
> I see why this has to be done separately, I think, but it should at least go 
> in a helper function.
> 
> Also, please check for substitution-name conflicts.
@rjmccall By substitution name conflicts do you mean substitution names which 
conflict with diagnostic names?


https://reviews.llvm.org/D46740



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

[PATCH] D46964: Implement class deduction guides for `std::array`

[Marshall Clow via Phabricator via cfe-commits]

mclow.lists closed this revision.
mclow.lists added a comment.

Committed as revision 332768


https://reviews.llvm.org/D46964



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

[libcxx] r332768 - Implement deduction guides for ; Reviewed as https://reviews.llvm.org/D46964

[Marshall Clow via cfe-commits]

Author: marshall
Date: Fri May 18 14:01:04 2018
New Revision: 332768

URL: http://llvm.org/viewvc/llvm-project?rev=332768&view=rev
Log:
Implement deduction guides for ; Reviewed as 
https://reviews.llvm.org/D46964

Added:
libcxx/trunk/test/std/containers/sequences/array/array.cons/deduct.fail.cpp
libcxx/trunk/test/std/containers/sequences/array/array.cons/deduct.pass.cpp
Modified:
libcxx/trunk/include/array

Modified: libcxx/trunk/include/array
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/array?rev=332768&r1=332767&r2=332768&view=diff
==
--- libcxx/trunk/include/array (original)
+++ libcxx/trunk/include/array Fri May 18 14:01:04 2018
@@ -72,6 +72,9 @@ struct array
 const T* data() const noexcept;
 };
 
+  template 
+array(T, U...) -> array;
+
 template 
   bool operator==(const array& x, const array& y);
 template 
@@ -86,7 +89,7 @@ template 
   bool operator>=(const array& x, const array& y);
 
 template 
-  void swap(array& x, array& y) noexcept(noexcept(x.swap(y)));
+  void swap(array& x, array& y) noexcept(noexcept(x.swap(y))); // 
C++17
 
 template  class tuple_size;
 template  class tuple_element;
@@ -354,6 +357,14 @@ struct _LIBCPP_TEMPLATE_VIS array<_Tp, 0
 };
 
 
+#ifndef _LIBCPP_HAS_NO_DEDUCTION_GUIDES
+template && ...), void>::type
+ >
+array(_Tp, _Args...)
+  -> array<_Tp, 1 + sizeof...(_Args)>;
+#endif
+
 template 
 inline _LIBCPP_INLINE_VISIBILITY
 bool

Added: 
libcxx/trunk/test/std/containers/sequences/array/array.cons/deduct.fail.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/sequences/array/array.cons/deduct.fail.cpp?rev=332768&view=auto
==
--- libcxx/trunk/test/std/containers/sequences/array/array.cons/deduct.fail.cpp 
(added)
+++ libcxx/trunk/test/std/containers/sequences/array/array.cons/deduct.fail.cpp 
Fri May 18 14:01:04 2018
@@ -0,0 +1,32 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// 
+// UNSUPPORTED: c++98, c++03, c++11, c++14
+// UNSUPPORTED: libcpp-no-deduction-guides
+
+
+// template 
+//   array(T, U...) -> array;
+//
+//  Requires: (is_same_v && ...) is true. Otherwise the program is 
ill-formed.
+
+
+#include 
+#include 
+#include 
+
+#include "test_macros.h"
+
+int main()
+{
+{
+std::array arr{1,2,3L}; // expected-error {{no viable constructor or 
deduction guide for deduction of template arguments of 'array'}}
+}
+}

Added: 
libcxx/trunk/test/std/containers/sequences/array/array.cons/deduct.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/containers/sequences/array/array.cons/deduct.pass.cpp?rev=332768&view=auto
==
--- libcxx/trunk/test/std/containers/sequences/array/array.cons/deduct.pass.cpp 
(added)
+++ libcxx/trunk/test/std/containers/sequences/array/array.cons/deduct.pass.cpp 
Fri May 18 14:01:04 2018
@@ -0,0 +1,58 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// 
+// UNSUPPORTED: c++98, c++03, c++11, c++14
+// UNSUPPORTED: libcpp-no-deduction-guides
+
+
+// template 
+//   array(T, U...) -> array;
+//
+//  Requires: (is_same_v && ...) is true. Otherwise the program is 
ill-formed.
+
+
+#include 
+#include 
+#include 
+
+#include "test_macros.h"
+
+int main()
+{
+//  Test the explicit deduction guides
+{
+std::array arr{1,2,3};  // array(T, U...)
+static_assert(std::is_same_v>, "");
+assert(arr[0] == 1);
+assert(arr[1] == 2);
+assert(arr[2] == 3);
+}
+
+{
+const long l1 = 42;
+std::array arr{1L, 4L, 9L, l1}; // array(T, U...)
+static_assert(std::is_same_v, "");
+static_assert(arr.size() == 4, "");
+assert(arr[0] == 1);
+assert(arr[1] == 4);
+assert(arr[2] == 9);
+assert(arr[3] == l1);
+}
+
+//  Test the implicit deduction guides
+  {
+  std::array source = {4.0, 5.0};
+  std::array arr(source);   // array(array)
+static_assert(std::is_same_v, "");
+static_assert(std::is_same_v>, "");
+assert(arr[0] == 4.0);
+assert(arr[1] == 5.0);
+  }
+}


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

[PATCH] D46964: Implement class deduction guides for `std::array`

[Marshall Clow via Phabricator via cfe-commits]

mclow.lists added inline comments.



Comment at: include/array:75
 
+  template 
+array(T, U...) -> array;

EricWF wrote:
> Don't we normally comment `// C++17` or similar for new features in the 
> synopsis?
we do.



Comment at: include/array:361
+#ifndef _LIBCPP_HAS_NO_DEDUCTION_GUIDES
+template && ...), void>::type

EricWF wrote:
> The `is same` clause is a requirement, not a SFINAE constraint. Should this 
> be a hard error? Should we really SFINAE it?
If we SFINAE it, then we'll get a hard error; because there are no other 
deduction guides.



Comment at: test/std/containers/sequences/array/array.cons/deduct.fail.cpp:12
+// UNSUPPORTED: c++98, c++03, c++11, c++14
+// XFAIL: libcpp-no-deduction-guides
+

EricWF wrote:
> This should be `UNSUPPORTED`. We don't expect this test to ever pass without 
> deduction guides.
OK


https://reviews.llvm.org/D46964



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

[PATCH] D46940: [ASTImporter] make sure that ACtx::getParents still works

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a reviewer: rsmith.
aaron.ballman added a comment.

Adding Richard as he has more background in this area. In general, I think it's 
okay - if we invalidate too often, we do lose some performance, but the 
correctness should still be there. I'll let Richard provide the final sign-off, 
however.


https://reviews.llvm.org/D46940



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

[libcxxabi] r332767 - private_typeinfo: limit is_dst_type_derived_from_static_type optimization

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Fri May 18 13:51:38 2018
New Revision: 332767

URL: http://llvm.org/viewvc/llvm-project?rev=332767&view=rev
Log:
private_typeinfo: limit is_dst_type_derived_from_static_type optimization

Patch by Ryan Prichard

If the destination type does not derive from the static type, we can skip
the search_above_dst call, but we still need to run the
!does_dst_type_point_to_our_static_type block of code. That block of code
will increment info->number_to_dst_ptr to 2, and because dest isn't derived
from static, the cast will ultimately fail.

Fixes PR33439

Reviewed as https://reviews.llvm.org/D36447

Modified:
libcxxabi/trunk/src/private_typeinfo.cpp
libcxxabi/trunk/test/dynamic_cast.pass.cpp

Modified: libcxxabi/trunk/src/private_typeinfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/src/private_typeinfo.cpp?rev=332767&r1=332766&r2=332767&view=diff
==
--- libcxxabi/trunk/src/private_typeinfo.cpp (original)
+++ libcxxabi/trunk/src/private_typeinfo.cpp Fri May 18 13:51:38 2018
@@ -859,13 +859,14 @@ __vmi_class_type_info::search_below_dst(
 // Record the access path that got us here
 //   If there is more than one dst_type this path doesn't matter.
 info->path_dynamic_ptr_to_dst_ptr = path_below;
+bool does_dst_type_point_to_our_static_type = false;
 // Only search above here if dst_type derives from static_type, or
 //if it is unknown if dst_type derives from static_type.
 if (info->is_dst_type_derived_from_static_type != no)
 {
 // Set up flags to record results from all base classes
 bool is_dst_type_derived_from_static_type = false;
-bool does_dst_type_point_to_our_static_type = false;
+
 // We've found a dst_type with a potentially public path to 
here.
 // We have to assume the path is public because it may become
 //   public later (if we get back to here with a public path).
@@ -909,21 +910,6 @@ __vmi_class_type_info::search_below_dst(
 }
 }
 }
-if (!does_dst_type_point_to_our_static_type)
-{
-// We found a dst_type that doesn't point to (static_ptr, 
static_type)
-// So record the address of this dst_ptr and increment the
-// count of the number of such dst_types found in the tree.
-info->dst_ptr_not_leading_to_static_ptr = current_ptr;
-info->number_to_dst_ptr += 1;
-// If there exists another dst with a private path to
-//(static_ptr, static_type), then the cast from 
-// (dynamic_ptr, dynamic_type) to dst_type is now 
ambiguous,
-//  so stop search.
-if (info->number_to_static_ptr == 1 &&
-info->path_dst_ptr_to_static_ptr == 
not_public_path)
-info->search_done = true;
-}
 // If we found no static_type,s then dst_type doesn't derive
 //   from static_type, else it does.  Record this result so 
that
 //   next time we hit a dst_type we will know not to search 
above
@@ -932,7 +918,22 @@ __vmi_class_type_info::search_below_dst(
 info->is_dst_type_derived_from_static_type = yes;
 else
 info->is_dst_type_derived_from_static_type = no;
-}
+  }
+  if (!does_dst_type_point_to_our_static_type)
+  {
+  // We found a dst_type that doesn't point to (static_ptr, 
static_type)
+  // So record the address of this dst_ptr and increment the
+  // count of the number of such dst_types found in the tree.
+  info->dst_ptr_not_leading_to_static_ptr = current_ptr;
+  info->number_to_dst_ptr += 1;
+  // If there exists another dst with a private path to
+  //(static_ptr, static_type), then the cast from
+  // (dynamic_ptr, dynamic_type) to dst_type is now 
ambiguous,
+  //  so stop search.
+  if (info->number_to_static_ptr == 1 &&
+  info->path_dst_ptr_to_static_ptr == not_public_path)
+  info->search_done = true;
+  }
 }
 }
 else
@@ -1030,13 +1031,13 @@ __si_class_type_info::search_below_dst(_
 // Record the access path that got us here
 //   If there is more than one dst_type this path doesn't matter.
 info->path_dynamic_ptr_to_dst_ptr = path_below;
+bool does_dst_type_point_to_our_static_type = false;
 

[libcxxabi] r332764 - private_typeinfo: propagate static flags in vmi search_above_dst method

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Fri May 18 13:42:53 2018
New Revision: 332764

URL: http://llvm.org/viewvc/llvm-project?rev=332764&view=rev
Log:
private_typeinfo: propagate static flags in vmi search_above_dst method

This adds the test which was mistakenly not committed in r332763.

Patch by Ryan Prichard

Propagate the found_our_static_ptr and found_any_static_type flags from
__vmi_class_type_info::search_above_dst to its caller.

Fixes PR33425 and PR33487

Reviewed as https://reviews.llvm.org/D36446


Added:
libcxxabi/trunk/test/dynamic_cast.pass.cpp

Added: libcxxabi/trunk/test/dynamic_cast.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/test/dynamic_cast.pass.cpp?rev=332764&view=auto
==
--- libcxxabi/trunk/test/dynamic_cast.pass.cpp (added)
+++ libcxxabi/trunk/test/dynamic_cast.pass.cpp Fri May 18 13:42:53 2018
@@ -0,0 +1,103 @@
+//===- dynamic_cast.pass.cpp 
--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include 
+
+// This test explicitly tests dynamic cast with types that have inaccessible
+// bases.
+#if defined(__clang__)
+#pragma clang diagnostic ignored "-Winaccessible-base"
+#endif
+
+typedef char Pad1[43981];
+typedef char Pad2[34981];
+typedef char Pad3[93481];
+typedef char Pad4[13489];
+typedef char Pad5[81349];
+typedef char Pad6[34819];
+typedef char Pad7[3489];
+
+namespace t1
+{
+
+// PR33425
+struct C3 { virtual ~C3() {} Pad1 _; };
+struct C5 : protected virtual C3 { Pad2 _; };
+struct C6 : virtual C5 { Pad3 _; };
+struct C7 : virtual C3 { Pad4 _; };
+struct C9 : C6, C7 { Pad5 _; };
+
+C9 c9;
+C3 *c3 = &c9;
+
+void test()
+{
+assert(dynamic_cast(c3) == static_cast(&c9));
+assert(dynamic_cast(c3) == static_cast(&c9));
+assert(dynamic_cast(c3) == static_cast(&c9));
+assert(dynamic_cast(c3) == static_cast(&c9));
+assert(dynamic_cast(c3) == static_cast(&c9));
+}
+
+}  // t1
+
+namespace t2
+{
+
+// PR33425
+struct Src { virtual ~Src() {} Pad1 _; };
+struct Mask : protected virtual Src { Pad2 _; };
+struct Dest : Mask { Pad3 _; };
+struct Root : Dest, virtual Src { Pad4 _; };
+
+Root root;
+Src *src = &root;
+
+void test()
+{
+assert(dynamic_cast(src) == static_cast(&root));
+assert(dynamic_cast(src) == static_cast(&root));
+assert(dynamic_cast(src) == static_cast(&root));
+assert(dynamic_cast(src) == static_cast(&root));
+}
+
+}  // t2
+
+namespace t3
+{
+
+// PR33487
+struct Class1 { virtual ~Class1() {} Pad1 _; };
+struct Shared : virtual Class1 { Pad2 _; };
+struct Class6 : virtual Shared { Pad3 _; };
+struct Left : Class6 { Pad4 _; };
+struct Right : Class6 { Pad5 _; };
+struct Main : Left, Right { Pad6 _; };
+
+Main m;
+Class1 *c1 = &m;
+
+void test()
+{
+assert(dynamic_cast(c1) == static_cast(&m));
+assert(dynamic_cast(c1) == static_cast(&m));
+assert(dynamic_cast(c1) == 0);
+assert(dynamic_cast(c1) == static_cast(&m));
+assert(dynamic_cast(c1) == static_cast(&m));
+assert(dynamic_cast(c1) == static_cast(&m));
+}
+
+}  // t3
+
+int main()
+{
+t1::test();
+t2::test();
+t3::test();
+}


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

[libcxxabi] r332763 - private_typeinfo: propagate static flags in vmi search_above_dst method

[Eric Fiselier via cfe-commits]

Author: ericwf
Date: Fri May 18 13:39:57 2018
New Revision: 332763

URL: http://llvm.org/viewvc/llvm-project?rev=332763&view=rev
Log:
private_typeinfo: propagate static flags in vmi search_above_dst method

Patch by Ryan Prichard

Propagate the found_our_static_ptr and found_any_static_type flags from
__vmi_class_type_info::search_above_dst to its caller.

Fixes PR33425 and PR33487

Reviewed as https://reviews.llvm.org/D36446


Modified:
libcxxabi/trunk/src/private_typeinfo.cpp

Modified: libcxxabi/trunk/src/private_typeinfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/src/private_typeinfo.cpp?rev=332763&r1=332762&r2=332763&view=diff
==
--- libcxxabi/trunk/src/private_typeinfo.cpp (original)
+++ libcxxabi/trunk/src/private_typeinfo.cpp Fri May 18 13:39:57 2018
@@ -1181,6 +1181,8 @@ __vmi_class_type_info::search_above_dst(
 info->found_our_static_ptr = false;
 info->found_any_static_type = false;
 p->search_above_dst(info, dst_ptr, current_ptr, path_below, 
use_strcmp);
+found_our_static_ptr |= info->found_our_static_ptr;
+found_any_static_type |= info->found_any_static_type;
 if (++p < e)
 {
 do
@@ -1210,6 +1212,8 @@ __vmi_class_type_info::search_above_dst(
 info->found_our_static_ptr = false;
 info->found_any_static_type = false;
 p->search_above_dst(info, dst_ptr, current_ptr, path_below, 
use_strcmp);
+found_our_static_ptr |= info->found_our_static_ptr;
+found_any_static_type |= info->found_any_static_type;
 } while (++p < e);
 }
 // Restore flags


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

[PATCH] D46964: Implement class deduction guides for `std::array`

[Eric Fiselier via Phabricator via cfe-commits]

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



Comment at: include/array:75
 
+  template 
+array(T, U...) -> array;

Don't we normally comment `// C++17` or similar for new features in the 
synopsis?



Comment at: include/array:361
+#ifndef _LIBCPP_HAS_NO_DEDUCTION_GUIDES
+template && ...), void>::type

The `is same` clause is a requirement, not a SFINAE constraint. Should this be 
a hard error? Should we really SFINAE it?



Comment at: test/std/containers/sequences/array/array.cons/deduct.fail.cpp:12
+// UNSUPPORTED: c++98, c++03, c++11, c++14
+// XFAIL: libcpp-no-deduction-guides
+

This should be `UNSUPPORTED`. We don't expect this test to ever pass without 
deduction guides.



Comment at: test/std/containers/sequences/array/array.cons/deduct.pass.cpp:12
+// UNSUPPORTED: c++98, c++03, c++11, c++14
+// XFAIL: libcpp-no-deduction-guides
+

`UNSUPPORTED`


https://reviews.llvm.org/D46964



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

Re: r332720 - Move #include manipulation code to new lib/Tooling/Inclusions.

[David Blaikie via cfe-commits]

I haven't looked in detail here, but in general: Don't split an
implementation and its headers into different notional libraries, as that
breaks modular code generation (an implementation and its headers usually
have circular dependencies - inline functions that call non-inline
functions, and the other way around & so if they're in two different
libraries they won't be able to link (due to the way unix linkers
work/dependencies are resolved in a single pass, never looping back around).

On Fri, May 18, 2018 at 1:10 PM Bruno Cardoso Lopes via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
>
> On Fri, May 18, 2018 at 12:46 PM Bruno Cardoso Lopes <
> bruno.card...@gmail.com> wrote:
>
>>
>>
>> On Fri, May 18, 2018 at 11:54 AM Vedant Kumar via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> On May 18, 2018, at 11:48 AM, Eric Liu  wrote:
>>>
>>>
>>> So I have reverted this with r332751.
>>>
>>>
>>> Thanks!
>>>
>>>
>>> I can't see how this introduced cyclic dependencies in module build, as
>>> the dependencies should be clangTooling -> clangFormat ->
>>> clangToolingInclusions. I'm wondering if there is any module configurations
>>> that I need to update to make this work. Right now, module doesn't seem to
>>> make any difference between clangTooling and clangToolingInclusions...
>>> I'd appreciate it if someone who knows how clang module build is set up
>>> could help take a look.
>>>
>>>
>>> + Bruno & David who have more experience in this area than I do.
>>>
>>
>> Gonna try to reproduce and take a look!
>>
>
> I could reproduce it. You should be good to go if you add another top
> level module for Inclusions (and break the dep):
>
> --- a/include/clang/module.modulemap
> +++ b/include/clang/module.modulemap
> @@ -153,3 +153,8 @@ module Clang_ToolingCore {
>requires cplusplus
>umbrella "Tooling/Core" module * { export * }
>  }
> +
> +module Clang_ToolingInclusions {
> +  requires cplusplus
> +  umbrella "Tooling/Inclusions" module * { export * }
> +}
>
> --
> Bruno Cardoso Lopes
> http://www.brunocardoso.cc
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: r332470 - Add support for __declspec(code_seg("segname"))

[Keane, Erich via cfe-commits]

Hi Richard-
Thanks for the feedback.  I’m copying the author of this patch on this email 
for further discussion if you care to.

We’ll have her take another look at it.  Thanks for the revert. 
(https://github.com/llvm-mirror/clang/commit/746b78de7812bc785fbb5207b788348040b23fa7).

-Erich

From: Richard Smith [mailto:rich...@metafoo.co.uk]
Sent: Friday, May 18, 2018 1:14 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r332470 - Add support for __declspec(code_seg("segname"))

Here's an example regression:

https://godbolt.org/g/S72Nki

I'll check that into the test suite alongside the revert once my testing 
finishes.

On 18 May 2018 at 13:03, Richard Smith 
mailto:rich...@metafoo.co.uk>> wrote:
On 16 May 2018 at 06:57, Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Wed May 16 06:57:17 2018
New Revision: 332470

URL: http://llvm.org/viewvc/llvm-project?rev=332470&view=rev
Log:
Add support for __declspec(code_seg("segname"))

Add support for __declspec(code_seg("segname"))

This patch is built on the existing support for #pragma code_seg. The code_seg
declspec is allowed on functions and classes. The attribute enables the
placement of code into separate named segments, including compiler-generated
members and template instantiations.

For more information, please see the following:
https://msdn.microsoft.com/en-us/library/dn636922.aspx

A new CodeSeg attribute is used instead of adding a new spelling to the existing
Section attribute since they don’t apply to the same Subjects. Section
attributes are also added for the code_seg declspec since they are used for
#pragma code_seg. No CodeSeg attributes are added to the AST.

This approach really doesn't work. You're incorrectly applying the 
__declspec(code_seg) restrictions to __attribute__((section)), regressing our 
support for the latter. Also, code_seg has fundamentally different semantics 
from the section attribute -- the former exists in part to support paged 
addressing (which is why it has the virtual function restriction) and the 
latter exists merely to control properties of the object file. This approach 
also violates our policy of maintaining source fidelity.

I'm going to revert this for now to fix the regression; when it comes back, I 
think you should just use CodeSegAttr to represent __declspec(code_seg) rather 
than trying to treat it as -- effectively -- a different spelling of 
SectionAttr.

The patch is written to match with the Microsoft compiler’s behavior even where
that behavior is a little complicated (see https://reviews.llvm.org/D22931, the
Microsoft feedback page is no longer available since MS has removed the page).
That code is in getImplicitSectionAttrFromClass routine.

Diagnostics messages are added to match with the Microsoft compiler for code-seg
attribute mismatches on base and derived classes and virtual overrides.


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

Modified:
cfe/trunk/include/clang/Basic/Attr.td
cfe/trunk/include/clang/Basic/AttrDocs.td
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/lib/Sema/SemaDeclAttr.cpp
cfe/trunk/lib/Sema/SemaDeclCXX.cpp
cfe/trunk/lib/Sema/SemaLambda.cpp

Modified: cfe/trunk/include/clang/Basic/Attr.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=332470&r1=332469&r2=332470&view=diff
==
--- cfe/trunk/include/clang/Basic/Attr.td (original)
+++ cfe/trunk/include/clang/Basic/Attr.td Wed May 16 06:57:17 2018
@@ -1769,6 +1769,13 @@ def Section : InheritableAttr {
   let Documentation = [SectionDocs];
 }

+def CodeSeg : InheritableAttr {
+  let Spellings = [Declspec<"code_seg">];
+  let Args = [StringArgument<"Name">];
+  let Subjects = SubjectList<[Function, CXXRecord], ErrorDiag>;
+  let Documentation = [CodeSegDocs];
+}
+
 def PragmaClangBSSSection : InheritableAttr {
   // This attribute has no spellings as it is only ever created implicitly.
   let Spellings = [];

Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttrDocs.td?rev=332470&r1=332469&r2=332470&view=diff
==
--- cfe/trunk/include/clang/Basic/AttrDocs.td (original)
+++ cfe/trunk/include/clang/Basic/AttrDocs.td Wed May 16 06:57:17 2018
@@ -306,6 +306,18 @@ An example of how to use ``alloc_size``
   }];
 }

+def CodeSegDocs : Documentation {
+  let Category = DocCatFunction;
+  let Content = [{
+The ``__declspec(code_seg)`` attribute enables the placement of code into 
separate
+named segments that can be paged or locked in memory individually. This 
attribute
+is used to control the placement of instantiated templates and 
compiler-generated
+code. See the documentation for `__declspec(code_s

r332760 - Revert r332470 (and corresponding tests in r332492).

[Richard Smith via cfe-commits]

Author: rsmith
Date: Fri May 18 13:18:17 2018
New Revision: 332760

URL: http://llvm.org/viewvc/llvm-project?rev=332760&view=rev
Log:
Revert r332470 (and corresponding tests in r332492).

This regressed our support for __attribute__((section)). See added test file
for example of code broken by this.

Added:
cfe/trunk/test/SemaCXX/attr-section.cpp
  - copied, changed from r332757, cfe/trunk/test/Sema/attr-section.c
Removed:
cfe/trunk/test/CodeGenCXX/code_seg1.cpp
cfe/trunk/test/CodeGenCXX/code_seg2.cpp
cfe/trunk/test/CodeGenCXX/code_seg3.cpp
cfe/trunk/test/CodeGenCXX/code_seg4.cpp
cfe/trunk/test/SemaCXX/code_seg.cpp
cfe/trunk/test/SemaCXX/code_seg1.cpp
Modified:
cfe/trunk/include/clang/Basic/Attr.td
cfe/trunk/include/clang/Basic/AttrDocs.td
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/lib/Sema/SemaDeclAttr.cpp
cfe/trunk/lib/Sema/SemaDeclCXX.cpp
cfe/trunk/lib/Sema/SemaLambda.cpp

Modified: cfe/trunk/include/clang/Basic/Attr.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=332760&r1=332759&r2=332760&view=diff
==
--- cfe/trunk/include/clang/Basic/Attr.td (original)
+++ cfe/trunk/include/clang/Basic/Attr.td Fri May 18 13:18:17 2018
@@ -1770,13 +1770,6 @@ def Section : InheritableAttr {
   let Documentation = [SectionDocs];
 }
 
-def CodeSeg : InheritableAttr {
-  let Spellings = [Declspec<"code_seg">];
-  let Args = [StringArgument<"Name">];
-  let Subjects = SubjectList<[Function, CXXRecord], ErrorDiag>;
-  let Documentation = [CodeSegDocs];
-}
-
 def PragmaClangBSSSection : InheritableAttr {
   // This attribute has no spellings as it is only ever created implicitly.
   let Spellings = [];

Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttrDocs.td?rev=332760&r1=332759&r2=332760&view=diff
==
--- cfe/trunk/include/clang/Basic/AttrDocs.td (original)
+++ cfe/trunk/include/clang/Basic/AttrDocs.td Fri May 18 13:18:17 2018
@@ -306,18 +306,6 @@ An example of how to use ``alloc_size``
   }];
 }
 
-def CodeSegDocs : Documentation {
-  let Category = DocCatFunction;
-  let Content = [{
-The ``__declspec(code_seg)`` attribute enables the placement of code into 
separate
-named segments that can be paged or locked in memory individually. This 
attribute
-is used to control the placement of instantiated templates and 
compiler-generated
-code. See the documentation for `__declspec(code_seg)`_ on MSDN.
-
-.. _`__declspec(code_seg)`: 
http://msdn.microsoft.com/en-us/library/dn636922.aspx
-  }];
-}
-
 def AllocAlignDocs : Documentation {
   let Category = DocCatFunction;
   let Content = [{

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=332760&r1=332759&r2=332760&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Fri May 18 13:18:17 
2018
@@ -2668,14 +2668,6 @@ def warn_mismatched_section : Warning<
 def warn_attribute_section_on_redeclaration : Warning<
   "section attribute is specified on redeclared variable">, InGroup;
 
-def err_mismatched_code_seg_base : Error<
-  "derived class must specify the same code segment as its base classes">;
-def err_mismatched_code_seg_override : Error<
-  "overriding virtual function must specify the same code segment as its 
overridden function">;
-def err_conflicting_codeseg_attribute : Error<
-  "conflicting code segment specifiers">;
-def warn_duplicate_codeseg_attribute : Warning<
-  "duplicate code segment specifiers">, InGroup;
 def err_anonymous_property: Error<
   "anonymous property is not supported">;
 def err_property_is_variably_modified : Error<

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=332760&r1=332759&r2=332760&view=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Fri May 18 13:18:17 2018
@@ -1934,7 +1934,6 @@ public:
   bool shouldLinkDependentDeclWithPrevious(Decl *D, Decl *OldDecl);
   void CheckMain(FunctionDecl *FD, const DeclSpec &D);
   void CheckMSVCRTEntryPoint(FunctionDecl *FD);
-  Attr *getImplicitSectionAttrForFunction(const FunctionDecl *FD, bool 
IsDefinition = true);
   Decl *ActOnParamDeclarator(Scope *S, Declarator &D);
   ParmVarDecl *BuildParmVarDeclForTypedef(DeclContext *DC,
   SourceLocation Loc,
@@ -5837,7 +5836,6 @@ pub

[PATCH] D44539: [Sema][Objective-C] Add check to warn when property of objc type has assign attribute

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

It's waiting on a discussion that's happening pretty slowly, sorry.  I know 
this is frustrating.


Repository:
  rC Clang

https://reviews.llvm.org/D44539



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

Re: r332470 - Add support for __declspec(code_seg("segname"))

[Richard Smith via cfe-commits]

Here's an example regression:

https://godbolt.org/g/S72Nki

I'll check that into the test suite alongside the revert once my testing
finishes.

On 18 May 2018 at 13:03, Richard Smith  wrote:

> On 16 May 2018 at 06:57, Erich Keane via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: erichkeane
>> Date: Wed May 16 06:57:17 2018
>> New Revision: 332470
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=332470&view=rev
>> Log:
>> Add support for __declspec(code_seg("segname"))
>>
>> Add support for __declspec(code_seg("segname"))
>>
>> This patch is built on the existing support for #pragma code_seg. The
>> code_seg
>> declspec is allowed on functions and classes. The attribute enables the
>> placement of code into separate named segments, including
>> compiler-generated
>> members and template instantiations.
>>
>> For more information, please see the following:
>> https://msdn.microsoft.com/en-us/library/dn636922.aspx
>>
>> A new CodeSeg attribute is used instead of adding a new spelling to the
>> existing
>> Section attribute since they don’t apply to the same Subjects. Section
>> attributes are also added for the code_seg declspec since they are used
>> for
>> #pragma code_seg. No CodeSeg attributes are added to the AST.
>>
>
> This approach really doesn't work. You're incorrectly applying the
> __declspec(code_seg) restrictions to __attribute__((section)), regressing
> our support for the latter. Also, code_seg has fundamentally different
> semantics from the section attribute -- the former exists in part to
> support paged addressing (which is why it has the virtual function
> restriction) and the latter exists merely to control properties of the
> object file. This approach also violates our policy of maintaining source
> fidelity.
>
> I'm going to revert this for now to fix the regression; when it comes
> back, I think you should just use CodeSegAttr to represent
> __declspec(code_seg) rather than trying to treat it as -- effectively -- a
> different spelling of SectionAttr.
>
>
>> The patch is written to match with the Microsoft compiler’s behavior even
>> where
>> that behavior is a little complicated (see https://reviews.llvm.org/D2293
>> 1, the
>> Microsoft feedback page is no longer available since MS has removed the
>> page).
>> That code is in getImplicitSectionAttrFromClass routine.
>>
>> Diagnostics messages are added to match with the Microsoft compiler for
>> code-seg
>> attribute mismatches on base and derived classes and virtual overrides.
>>
>>
>> Differential Revision: https://reviews.llvm.org/D43352
>>
>> Modified:
>> cfe/trunk/include/clang/Basic/Attr.td
>> cfe/trunk/include/clang/Basic/AttrDocs.td
>> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>> cfe/trunk/include/clang/Sema/Sema.h
>> cfe/trunk/lib/Sema/SemaDecl.cpp
>> cfe/trunk/lib/Sema/SemaDeclAttr.cpp
>> cfe/trunk/lib/Sema/SemaDeclCXX.cpp
>> cfe/trunk/lib/Sema/SemaLambda.cpp
>>
>> Modified: cfe/trunk/include/clang/Basic/Attr.td
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
>> Basic/Attr.td?rev=332470&r1=332469&r2=332470&view=diff
>> 
>> ==
>> --- cfe/trunk/include/clang/Basic/Attr.td (original)
>> +++ cfe/trunk/include/clang/Basic/Attr.td Wed May 16 06:57:17 2018
>> @@ -1769,6 +1769,13 @@ def Section : InheritableAttr {
>>let Documentation = [SectionDocs];
>>  }
>>
>> +def CodeSeg : InheritableAttr {
>> +  let Spellings = [Declspec<"code_seg">];
>> +  let Args = [StringArgument<"Name">];
>> +  let Subjects = SubjectList<[Function, CXXRecord], ErrorDiag>;
>> +  let Documentation = [CodeSegDocs];
>> +}
>> +
>>  def PragmaClangBSSSection : InheritableAttr {
>>// This attribute has no spellings as it is only ever created
>> implicitly.
>>let Spellings = [];
>>
>> Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/
>> Basic/AttrDocs.td?rev=332470&r1=332469&r2=332470&view=diff
>> 
>> ==
>> --- cfe/trunk/include/clang/Basic/AttrDocs.td (original)
>> +++ cfe/trunk/include/clang/Basic/AttrDocs.td Wed May 16 06:57:17 2018
>> @@ -306,6 +306,18 @@ An example of how to use ``alloc_size``
>>}];
>>  }
>>
>> +def CodeSegDocs : Documentation {
>> +  let Category = DocCatFunction;
>> +  let Content = [{
>> +The ``__declspec(code_seg)`` attribute enables the placement of code
>> into separate
>> +named segments that can be paged or locked in memory individually. This
>> attribute
>> +is used to control the placement of instantiated templates and
>> compiler-generated
>> +code. See the documentation for `__declspec(code_seg)`_ on MSDN.
>> +
>> +.. _`__declspec(code_seg)`: http://msdn.microsoft.com/en-u
>> s/library/dn636922.aspx
>> +  }];
>> +}
>> +
>>  def AllocAlignDocs : Documentation {
>>let Category = DocCatFunction;
>>let Con

Re: r332720 - Move #include manipulation code to new lib/Tooling/Inclusions.

[Bruno Cardoso Lopes via cfe-commits]

On Fri, May 18, 2018 at 12:46 PM Bruno Cardoso Lopes <
bruno.card...@gmail.com> wrote:

>
>
> On Fri, May 18, 2018 at 11:54 AM Vedant Kumar via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On May 18, 2018, at 11:48 AM, Eric Liu  wrote:
>>
>>
>> So I have reverted this with r332751.
>>
>>
>> Thanks!
>>
>>
>> I can't see how this introduced cyclic dependencies in module build, as
>> the dependencies should be clangTooling -> clangFormat ->
>> clangToolingInclusions. I'm wondering if there is any module configurations
>> that I need to update to make this work. Right now, module doesn't seem to
>> make any difference between clangTooling and clangToolingInclusions...
>> I'd appreciate it if someone who knows how clang module build is set up
>> could help take a look.
>>
>>
>> + Bruno & David who have more experience in this area than I do.
>>
>
> Gonna try to reproduce and take a look!
>

I could reproduce it. You should be good to go if you add another top level
module for Inclusions (and break the dep):

--- a/include/clang/module.modulemap
+++ b/include/clang/module.modulemap
@@ -153,3 +153,8 @@ module Clang_ToolingCore {
   requires cplusplus
   umbrella "Tooling/Core" module * { export * }
 }
+
+module Clang_ToolingInclusions {
+  requires cplusplus
+  umbrella "Tooling/Inclusions" module * { export * }
+}

-- 
Bruno Cardoso Lopes
http://www.brunocardoso.cc
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r332470 - Add support for __declspec(code_seg("segname"))

[Richard Smith via cfe-commits]

On 16 May 2018 at 06:57, Erich Keane via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: erichkeane
> Date: Wed May 16 06:57:17 2018
> New Revision: 332470
>
> URL: http://llvm.org/viewvc/llvm-project?rev=332470&view=rev
> Log:
> Add support for __declspec(code_seg("segname"))
>
> Add support for __declspec(code_seg("segname"))
>
> This patch is built on the existing support for #pragma code_seg. The
> code_seg
> declspec is allowed on functions and classes. The attribute enables the
> placement of code into separate named segments, including
> compiler-generated
> members and template instantiations.
>
> For more information, please see the following:
> https://msdn.microsoft.com/en-us/library/dn636922.aspx
>
> A new CodeSeg attribute is used instead of adding a new spelling to the
> existing
> Section attribute since they don’t apply to the same Subjects. Section
> attributes are also added for the code_seg declspec since they are used for
> #pragma code_seg. No CodeSeg attributes are added to the AST.
>

This approach really doesn't work. You're incorrectly applying the
__declspec(code_seg) restrictions to __attribute__((section)), regressing
our support for the latter. Also, code_seg has fundamentally different
semantics from the section attribute -- the former exists in part to
support paged addressing (which is why it has the virtual function
restriction) and the latter exists merely to control properties of the
object file. This approach also violates our policy of maintaining source
fidelity.

I'm going to revert this for now to fix the regression; when it comes back,
I think you should just use CodeSegAttr to represent __declspec(code_seg)
rather than trying to treat it as -- effectively -- a different spelling of
SectionAttr.


> The patch is written to match with the Microsoft compiler’s behavior even
> where
> that behavior is a little complicated (see https://reviews.llvm.org/D22931,
> the
> Microsoft feedback page is no longer available since MS has removed the
> page).
> That code is in getImplicitSectionAttrFromClass routine.
>
> Diagnostics messages are added to match with the Microsoft compiler for
> code-seg
> attribute mismatches on base and derived classes and virtual overrides.
>
>
> Differential Revision: https://reviews.llvm.org/D43352
>
> Modified:
> cfe/trunk/include/clang/Basic/Attr.td
> cfe/trunk/include/clang/Basic/AttrDocs.td
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> cfe/trunk/include/clang/Sema/Sema.h
> cfe/trunk/lib/Sema/SemaDecl.cpp
> cfe/trunk/lib/Sema/SemaDeclAttr.cpp
> cfe/trunk/lib/Sema/SemaDeclCXX.cpp
> cfe/trunk/lib/Sema/SemaLambda.cpp
>
> Modified: cfe/trunk/include/clang/Basic/Attr.td
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Basic/Attr.td?rev=332470&r1=332469&r2=332470&view=diff
> 
> ==
> --- cfe/trunk/include/clang/Basic/Attr.td (original)
> +++ cfe/trunk/include/clang/Basic/Attr.td Wed May 16 06:57:17 2018
> @@ -1769,6 +1769,13 @@ def Section : InheritableAttr {
>let Documentation = [SectionDocs];
>  }
>
> +def CodeSeg : InheritableAttr {
> +  let Spellings = [Declspec<"code_seg">];
> +  let Args = [StringArgument<"Name">];
> +  let Subjects = SubjectList<[Function, CXXRecord], ErrorDiag>;
> +  let Documentation = [CodeSegDocs];
> +}
> +
>  def PragmaClangBSSSection : InheritableAttr {
>// This attribute has no spellings as it is only ever created
> implicitly.
>let Spellings = [];
>
> Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Basic/AttrDocs.td?rev=332470&r1=332469&r2=332470&view=diff
> 
> ==
> --- cfe/trunk/include/clang/Basic/AttrDocs.td (original)
> +++ cfe/trunk/include/clang/Basic/AttrDocs.td Wed May 16 06:57:17 2018
> @@ -306,6 +306,18 @@ An example of how to use ``alloc_size``
>}];
>  }
>
> +def CodeSegDocs : Documentation {
> +  let Category = DocCatFunction;
> +  let Content = [{
> +The ``__declspec(code_seg)`` attribute enables the placement of code into
> separate
> +named segments that can be paged or locked in memory individually. This
> attribute
> +is used to control the placement of instantiated templates and
> compiler-generated
> +code. See the documentation for `__declspec(code_seg)`_ on MSDN.
> +
> +.. _`__declspec(code_seg)`: http://msdn.microsoft.com/en-
> us/library/dn636922.aspx
> +  }];
> +}
> +
>  def AllocAlignDocs : Documentation {
>let Category = DocCatFunction;
>let Content = [{
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/
> DiagnosticSemaKinds.td?rev=332470&r1=332469&r2=332470&view=diff
> 
> ==
> --- cfe/trunk/include/clang/Bas

r332757 - Support: Simplify endian stream interface. NFCI.

[Peter Collingbourne via cfe-commits]

Author: pcc
Date: Fri May 18 12:46:24 2018
New Revision: 332757

URL: http://llvm.org/viewvc/llvm-project?rev=332757&view=rev
Log:
Support: Simplify endian stream interface. NFCI.

Provide some free functions to reduce verbosity of endian-writing
a single value, and replace the endianness template parameter with
a field.

Part of PR37466.

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

Modified:
cfe/trunk/lib/Frontend/CacheTokens.cpp
cfe/trunk/lib/Serialization/ASTWriter.cpp
cfe/trunk/lib/Serialization/GlobalModuleIndex.cpp
cfe/trunk/lib/Serialization/MultiOnDiskHashTable.h

Modified: cfe/trunk/lib/Frontend/CacheTokens.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CacheTokens.cpp?rev=332757&r1=332756&r2=332757&view=diff
==
--- cfe/trunk/lib/Frontend/CacheTokens.cpp (original)
+++ cfe/trunk/lib/Frontend/CacheTokens.cpp Fri May 18 12:46:24 2018
@@ -88,7 +88,7 @@ public:
 
   void EmitData(raw_ostream& Out) {
 using namespace llvm::support;
-endian::Writer LE(Out);
+endian::Writer LE(Out, little);
 switch (Kind) {
 case IsFE: {
   // Emit stat information.
@@ -135,7 +135,7 @@ public:
   EmitKeyDataLength(raw_ostream& Out, PTHEntryKeyVariant V,
 const PTHEntry& E) {
 using namespace llvm::support;
-endian::Writer LE(Out);
+endian::Writer LE(Out, little);
 
 unsigned n = V.getString().size() + 1 + 1;
 LE.write(n);
@@ -149,7 +149,7 @@ public:
   static void EmitKey(raw_ostream& Out, PTHEntryKeyVariant V, unsigned n){
 using namespace llvm::support;
 // Emit the entry kind.
-endian::Writer(Out).write((unsigned)V.getKind());
+Out << char(V.getKind());
 // Emit the string.
 Out.write(V.getString().data(), n - 1);
   }
@@ -157,7 +157,7 @@ public:
   static void EmitData(raw_ostream& Out, PTHEntryKeyVariant V,
const PTHEntry& E, unsigned) {
 using namespace llvm::support;
-endian::Writer LE(Out);
+endian::Writer LE(Out, little);
 
 // For file entries emit the offsets into the PTH file for token data
 // and the preprocessor blocks table.
@@ -205,18 +205,17 @@ class PTHWriter {
   void EmitToken(const Token& T);
 
   void Emit8(uint32_t V) {
-using namespace llvm::support;
-endian::Writer(Out).write(V);
+Out << char(V);
   }
 
   void Emit16(uint32_t V) {
 using namespace llvm::support;
-endian::Writer(Out).write(V);
+endian::write(Out, V, little);
   }
 
   void Emit32(uint32_t V) {
 using namespace llvm::support;
-endian::Writer(Out).write(V);
+endian::write(Out, V, little);
   }
 
   void EmitBuf(const char *Ptr, unsigned NumBytes) {
@@ -225,7 +224,7 @@ class PTHWriter {
 
   void EmitString(StringRef V) {
 using namespace llvm::support;
-endian::Writer(Out).write(V.size());
+endian::write(Out, V.size(), little);
 EmitBuf(V.data(), V.size());
   }
 
@@ -299,7 +298,7 @@ PTHEntry PTHWriter::LexTokens(Lexer& L)
   // Pad 0's so that we emit tokens to a 4-byte alignment.
   // This speed up reading them back in.
   using namespace llvm::support;
-  endian::Writer LE(Out);
+  endian::Writer LE(Out, little);
   uint32_t TokenOff = Out.tell();
   for (uint64_t N = llvm::OffsetToAlignment(TokenOff, 4); N; --N, ++TokenOff)
 LE.write(0);
@@ -632,7 +631,7 @@ public:
   EmitKeyDataLength(raw_ostream& Out, const PTHIdKey* key, uint32_t) {
 using namespace llvm::support;
 unsigned n = key->II->getLength() + 1;
-endian::Writer(Out).write(n);
+endian::write(Out, n, little);
 return std::make_pair(n, sizeof(uint32_t));
   }
 
@@ -646,7 +645,7 @@ public:
   static void EmitData(raw_ostream& Out, PTHIdKey*, uint32_t pID,
unsigned) {
 using namespace llvm::support;
-endian::Writer(Out).write(pID);
+endian::write(Out, pID, little);
   }
 };
 } // end anonymous namespace

Modified: cfe/trunk/lib/Serialization/ASTWriter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTWriter.cpp?rev=332757&r1=332756&r2=332757&view=diff
==
--- cfe/trunk/lib/Serialization/ASTWriter.cpp (original)
+++ cfe/trunk/lib/Serialization/ASTWriter.cpp Fri May 18 12:46:24 2018
@@ -1955,7 +1955,7 @@ namespace {
 EmitKeyDataLength(raw_ostream& Out, key_type_ref key, data_type_ref Data) {
   using namespace llvm::support;
 
-  endian::Writer LE(Out);
+  endian::Writer LE(Out, little);
   unsigned KeyLen = key.Filename.size() + 1 + 8 + 8;
   LE.write(KeyLen);
   unsigned DataLen = 1 + 2 + 4 + 4;
@@ -1971,7 +1971,7 @@ namespace {
 void EmitKey(raw_ostream& Out, key_type_ref key, unsigned KeyLen) {
   using namespace llvm::support;
 
-  endian::Writer LE(Out);
+  endian::Writer LE(Out, little);
   LE.write(key.Size);
   KeyLen -= 8;
   LE.write(key.ModTi

Re: r332720 - Move #include manipulation code to new lib/Tooling/Inclusions.

[Bruno Cardoso Lopes via cfe-commits]

On Fri, May 18, 2018 at 11:54 AM Vedant Kumar via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On May 18, 2018, at 11:48 AM, Eric Liu  wrote:
>
>
> So I have reverted this with r332751.
>
>
> Thanks!
>
>
> I can't see how this introduced cyclic dependencies in module build, as
> the dependencies should be clangTooling -> clangFormat ->
> clangToolingInclusions. I'm wondering if there is any module configurations
> that I need to update to make this work. Right now, module doesn't seem to
> make any difference between clangTooling and clangToolingInclusions...
> I'd appreciate it if someone who knows how clang module build is set up
> could help take a look.
>
>
> + Bruno & David who have more experience in this area than I do.
>

Gonna try to reproduce and take a look!


>
>
> Unfortunately, I couldn't reproduce this on my workstation as the module
> build seemed to be broken due to other errors.
>
>
> The build is dependent on having a set of modularized system headers --
> perhaps that's the issue.
>
>
> I was seeing a lot of warnings; the clang I used to build llvm was built
> near HEAD. Maybe my clang is too new?
>
>
> This sounds a bit suspicious. Can new clang diagnostics land without clean
> stage2 builds? If so, we can look into enabling -Werror on our stage2 bots
> to catch this sort of thing earlier.
>
> vedant
>
>
> Thanks,
> Eric
>
> On Fri, May 18, 2018 at 7:52 PM Eric Liu  wrote:
>
>> Sorry, I'll look into it right now. Will revert it if I can't find a
>> quick fix.
>>
>> On Fri, May 18, 2018, 19:49 Amara Emerson  wrote:
>>
>>> Hi Eric,
>>>
>>> Green dragon buildbots have started failing too, e.g.:
>>> http://green.lab.llvm.org/green/job/clang-stage2-Rthinlto/10222/
>>>
>>> If you don’t have a quick fix can you please revert it.
>>>
>>> Thanks,
>>> Amara
>>>
>>>
>>> On May 18, 2018, at 7:46 PM, Eric Liu  wrote:
>>>
>>> Hi Vedant,
>>>
>>> It seems that your build was not using cmake files in the source tree?
>>> lib/Tooling/Inclusions/ is a (new) standalone library
>>> (clangToolingInclusions, similar to clangToolingCore). You might need
>>> update your build to reflect this change. Let me know if you have any
>>> further question.
>>>
>>> Thanks,
>>> Eric
>>>
>>> On Fri, May 18, 2018 at 6:41 PM Vedant Kumar  wrote:
>>>
 Hi Eric,

 I think there might be a cyclic dependency issue here, possibly one
 that's only visible with LLVM_ENABLE_MODULES=On. I see:

 While building module 'Clang_Tooling' imported from /Users/vsk/src/
 llvm.org-master/llvm/tools/clang/lib/Tooling/Execution.cpp:10:

 While building module 'Clang_Format' imported from /Users/vsk/src/
 llvm.org-master/llvm/tools/clang/include/clang/Tooling/Refactoring/AtomicChange.h:19:

 In file included from :1:


 /Users/vsk/src/llvm.org-master/llvm/tools/clang/include/clang/Format/Format.h:20:10:
 fatal error: cyclic dependency in module 'Clang_Tooling': Clang_Tooling $>
 Clang_Format -> Clang_Tooling

 #include "clang/Tooling/Inclusions/IncludeStyle.h"
  ^
 While building module 'Clang_Tooling' imported from /Users/vsk/src/
 llvm.org-master/llvm/tools/clang/lib/Tooling/Execution.cpp:10:
 In file included from :22:

 In file included from /Users/vsk/src/llvm.org
 -master/llvm/tools/clang/include/clang/Tooling/Refactoring/RefactoringAction.h:14:
 In file included from /Users/vsk/src/llvm.org
 -master/llvm/tools/clang/include/clang/Tooling/Refactoring/RefactoringActionRules.h:14:
 In file included from /Users/vsk/src/llvm.org
 -master/llvm/tools/clang/include/clang/Tooling/Refactoring/RefactoringActionRulesInternal.h:16:
 In file included from /Users/vsk/src/llvm.org
 -master/llvm/tools/clang/include/clang/Tooling/Refactoring/RefactoringResultConsumer.h:14:
 /Users/vsk/src/llvm.org-master/llvm/tools/clang/include/clang/Tooling/Refactoring/AtomicChange.h:19:10:
 fatal error: could not build module 'Clang_Format'
 #include "clang/Format/Format.h"
  ^~~
 /Users/vsk/src/llvm.org-master/llvm/tools/clang/lib/Tooling/Execution.cpp:10:10:
 fatal error: could not build module 'Clang_Tooling'
 #include "clang/Tooling/Execution.h"

  ^~~
 3 errors generated.

 Could you take a look?

 thanks,
 vedant

 > On May 18, 2018, at 7:16 AM, Eric Liu via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:
 >
 > Author: ioeric
 > Date: Fri May 18 07:16:37 2018
 > New Revision: 332720
 >
 > URL: http://llvm.org/viewvc/llvm-project?rev=332720&view=rev
 > Log:
 > Move #include manipulation code to new lib/Tooling/Inclusions.
 >
 > Summary:
 > clangToolingCore is linked into almost everything (incl. clang), but
 > not few tools need #include manipulation at this point. So pull this
 into a
 > separate library in Tooling.
 >
 > Review

[PATCH] D43281: [AMDGPU] fixes for lds f32 builtins

[Matt Arsenault via Phabricator via cfe-commits]

arsenm added a comment.

I think the intent of the current code is for the address space to correspond 
to a "target address space" as if the user code used 
__attribute__((address_space(n))) to specify a pointer value. This is 
confusingly named, and different from the target address space selected for a 
LangAS. I think we need to add some mechanism for specifying the builtin is a 
LangAS ID. Since Ideally this would also work for multiple languages (e.g. 
cuda_constant or opencl_constant for the same builtin) I think there needs to 
be some callback triggered for the address space value. This possibly needs to 
be distinct from the current pointer descriptor to avoid breaking the 
possibility of user defined address spaces. There aren't really any other users 
of builtins with address spaces. NVPTX has some, but the tests seem to not 
actually try to use the declared address space and pass generic pointers to 
them.


Repository:
  rC Clang

https://reviews.llvm.org/D43281



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

[PATCH] D47084: Maintain PS4 ABI compatibility

[Douglas Yung via Phabricator via cfe-commits]

dyung created this revision.
dyung added a reviewer: probinson.

In r331136, a change was made to the compiler to fix a problem with how clang 
applied the packed attribute to classes. This is an ABI breaking change for the 
PS4 target, so this change maintains the broken behavior for the PS4 target.


Repository:
  rC Clang

https://reviews.llvm.org/D47084

Files:
  lib/AST/RecordLayoutBuilder.cpp
  test/CodeGenCXX/alignment.cpp


Index: test/CodeGenCXX/alignment.cpp
===
--- test/CodeGenCXX/alignment.cpp
+++ test/CodeGenCXX/alignment.cpp
@@ -1,5 +1,6 @@
 // RUN: %clang_cc1 %s -emit-llvm -o - -triple=x86_64-apple-darwin10 | 
FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-NOCOMPAT
 // RUN: %clang_cc1 %s -emit-llvm -o - -triple=x86_64-apple-darwin10 
-fclang-abi-compat=6.0 | FileCheck %s --check-prefix=CHECK 
--check-prefix=CHECK-V6COMPAT
+// RUN: %clang_cc1 %s -emit-llvm -o - -triple=x86_64-scei-ps4 | FileCheck %s 
--check-prefix=CHECK --check-prefix=CHECK-V6COMPAT
 
 extern int int_source();
 extern void int_sink(int x);
Index: lib/AST/RecordLayoutBuilder.cpp
===
--- lib/AST/RecordLayoutBuilder.cpp
+++ lib/AST/RecordLayoutBuilder.cpp
@@ -1178,10 +1178,12 @@
   // Clang <= 6 incorrectly applied the 'packed' attribute to base classes.
   // Per GCC's documentation, it only applies to non-static data members.
   CharUnits UnpackedBaseAlign = Layout.getNonVirtualAlignment();
-  CharUnits BaseAlign = (Packed && Context.getLangOpts().getClangABICompat() <=
-   LangOptions::ClangABI::Ver6)
-? CharUnits::One()
-: UnpackedBaseAlign;
+  CharUnits BaseAlign =
+  (Packed && ((Context.getLangOpts().getClangABICompat() <=
+   LangOptions::ClangABI::Ver6) ||
+  Context.getTargetInfo().getTriple().isPS4()))
+  ? CharUnits::One()
+  : UnpackedBaseAlign;
 
   // If we have an empty base class, try to place it at offset 0.
   if (Base->Class->isEmpty() &&


Index: test/CodeGenCXX/alignment.cpp
===
--- test/CodeGenCXX/alignment.cpp
+++ test/CodeGenCXX/alignment.cpp
@@ -1,5 +1,6 @@
 // RUN: %clang_cc1 %s -emit-llvm -o - -triple=x86_64-apple-darwin10 | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-NOCOMPAT
 // RUN: %clang_cc1 %s -emit-llvm -o - -triple=x86_64-apple-darwin10 -fclang-abi-compat=6.0 | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-V6COMPAT
+// RUN: %clang_cc1 %s -emit-llvm -o - -triple=x86_64-scei-ps4 | FileCheck %s --check-prefix=CHECK --check-prefix=CHECK-V6COMPAT
 
 extern int int_source();
 extern void int_sink(int x);
Index: lib/AST/RecordLayoutBuilder.cpp
===
--- lib/AST/RecordLayoutBuilder.cpp
+++ lib/AST/RecordLayoutBuilder.cpp
@@ -1178,10 +1178,12 @@
   // Clang <= 6 incorrectly applied the 'packed' attribute to base classes.
   // Per GCC's documentation, it only applies to non-static data members.
   CharUnits UnpackedBaseAlign = Layout.getNonVirtualAlignment();
-  CharUnits BaseAlign = (Packed && Context.getLangOpts().getClangABICompat() <=
-   LangOptions::ClangABI::Ver6)
-? CharUnits::One()
-: UnpackedBaseAlign;
+  CharUnits BaseAlign =
+  (Packed && ((Context.getLangOpts().getClangABICompat() <=
+   LangOptions::ClangABI::Ver6) ||
+  Context.getTargetInfo().getTriple().isPS4()))
+  ? CharUnits::One()
+  : UnpackedBaseAlign;
 
   // If we have an empty base class, try to place it at offset 0.
   if (Base->Class->isEmpty() &&
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r332720 - Move #include manipulation code to new lib/Tooling/Inclusions.

[Vedant Kumar via cfe-commits]

> On May 18, 2018, at 11:48 AM, Eric Liu  wrote:
> 
> So I have reverted this with r332751.

Thanks!


> I can't see how this introduced cyclic dependencies in module build, as the 
> dependencies should be clangTooling -> clangFormat -> clangToolingInclusions. 
> I'm wondering if there is any module configurations that I need to update to 
> make this work. Right now, module doesn't seem to make any difference between 
> clangTooling and clangToolingInclusions... I'd appreciate it if someone who 
> knows how clang module build is set up could help take a look.

+ Bruno & David who have more experience in this area than I do.


> Unfortunately, I couldn't reproduce this on my workstation as the module 
> build seemed to be broken due to other errors.

The build is dependent on having a set of modularized system headers -- perhaps 
that's the issue.


> I was seeing a lot of warnings; the clang I used to build llvm was built near 
> HEAD. Maybe my clang is too new?

This sounds a bit suspicious. Can new clang diagnostics land without clean 
stage2 builds? If so, we can look into enabling -Werror on our stage2 bots to 
catch this sort of thing earlier.

vedant

> 
> Thanks,
> Eric
> 
> On Fri, May 18, 2018 at 7:52 PM Eric Liu  > wrote:
> Sorry, I'll look into it right now. Will revert it if I can't find a quick 
> fix.
> 
> On Fri, May 18, 2018, 19:49 Amara Emerson  > wrote:
> Hi Eric,
> 
> Green dragon buildbots have started failing too, e.g.: 
> http://green.lab.llvm.org/green/job/clang-stage2-Rthinlto/10222/ 
> 
> 
> If you don’t have a quick fix can you please revert it.
> 
> Thanks,
> Amara
> 
> 
>> On May 18, 2018, at 7:46 PM, Eric Liu > > wrote:
>> 
>> Hi Vedant,
>> 
>> It seems that your build was not using cmake files in the source tree? 
>> lib/Tooling/Inclusions/ is a (new) standalone library 
>> (clangToolingInclusions, similar to clangToolingCore). You might need update 
>> your build to reflect this change. Let me know if you have any further 
>> question.
>> 
>> Thanks,
>> Eric
>> 
>> On Fri, May 18, 2018 at 6:41 PM Vedant Kumar > > wrote:
>> Hi Eric,
>> 
>> I think there might be a cyclic dependency issue here, possibly one that's 
>> only visible with LLVM_ENABLE_MODULES=On. I see:
>> 
>> While building module 'Clang_Tooling' imported from /Users/vsk/src/llvm.org 
>> -master/llvm/tools/clang/lib/Tooling/Execution.cpp:10: 
>> 
>> While building module 'Clang_Format' imported from /Users/vsk/src/llvm.org 
>> -master/llvm/tools/clang/include/clang/Tooling/Refactoring/AtomicChange.h:19:
>>
>> In file included from :1:   
>>  
>>
>> /Users/vsk/src/llvm.org 
>> -master/llvm/tools/clang/include/clang/Format/Format.h:20:10:
>>  fatal error: cyclic dependency in module 'Clang_Tooling': Clang_Tooling $> 
>> Clang_Format -> Clang_Tooling
>> 
>> #include "clang/Tooling/Inclusions/IncludeStyle.h"
>>  ^  
>> While building module 'Clang_Tooling' imported from /Users/vsk/src/llvm.org 
>> -master/llvm/tools/clang/lib/Tooling/Execution.cpp:10:
>> In file included from :22:  
>> 
>> In file included from /Users/vsk/src/llvm.org 
>> -master/llvm/tools/clang/include/clang/Tooling/Refactoring/RefactoringAction.h:14:
>> In file included from /Users/vsk/src/llvm.org 
>> -master/llvm/tools/clang/include/clang/Tooling/Refactoring/RefactoringActionRules.h:14:
>> In file included from /Users/vsk/src/llvm.org 
>> -master/llvm/tools/clang/include/clang/Tooling/Refactoring/RefactoringActionRulesInternal.h:16:
>> In file included from /Users/vsk/src/llvm.org 
>> -master/llvm/tools/clang/include/clang/Tooling/Refactoring/RefactoringResultConsumer.h:14:
>> /Users/vsk/src/llvm.org 
>> -master/llvm/tools/clang/include/clang/Tooling/Refactoring/AtomicChange.h:19:10:
>>  fatal error: could not build module 'Clang_Format'
>> #include "clang/Format/Format.h"
>>  ^~~
>> /Users/vsk/src/llvm.org 
>> -master/llvm/tools/clang/lib/Tooling/Execution.cpp:10:10: 
>> fatal error: could not build module 'Clang_Tooling'
>> #include "clang/Tooling/Execution.h" 
>>
>>  ^~~
>> 3 errors generated.
>> 
>> Could you take a look?
>> 
>> thanks,
>> vedant
>> 
>> > On May 18, 2018, at 7:16 AM, Eric Liu via cfe-commits 
>> > mailto:cfe-commits@lists.l

[PATCH] D46911: [Fixed Point Arithmetic] Addition of the remaining fixed point types and their saturated equivalents

[Leonard Chan via Phabricator via cfe-commits]

leonardchan updated this revision to Diff 147568.

Repository:
  rC Clang

https://reviews.llvm.org/D46911

Files:
  include/clang/AST/ASTContext.h
  include/clang/AST/BuiltinTypes.def
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/Specifiers.h
  include/clang/Basic/TokenKinds.def
  include/clang/Sema/DeclSpec.h
  include/clang/Serialization/ASTBitCodes.h
  lib/AST/ASTContext.cpp
  lib/AST/ExprConstant.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/MicrosoftMangle.cpp
  lib/AST/NSAPI.cpp
  lib/AST/Type.cpp
  lib/AST/TypeLoc.cpp
  lib/Analysis/PrintfFormatString.cpp
  lib/CodeGen/CGDebugInfo.cpp
  lib/CodeGen/CodeGenTypes.cpp
  lib/CodeGen/ItaniumCXXABI.cpp
  lib/Index/USRGeneration.cpp
  lib/Parse/ParseDecl.cpp
  lib/Sema/DeclSpec.cpp
  lib/Sema/SemaTemplateVariadic.cpp
  lib/Sema/SemaType.cpp
  lib/Serialization/ASTCommon.cpp
  lib/Serialization/ASTReader.cpp
  test/Frontend/accum.c
  test/Frontend/accum_errors.c
  test/Frontend/accum_errors.cpp
  test/Frontend/fixed_point.c
  test/Frontend/fixed_point_errors.c
  test/Frontend/fixed_point_errors.cpp

Index: test/Frontend/fixed_point_errors.cpp
===
--- /dev/null
+++ test/Frontend/fixed_point_errors.cpp
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -x c++ %s -verify
+
+// Name namgling is not provided for fixed point types in c++
+
+signed short _Accum s_short_accum;  // expected-error{{Fixed point types are only allowed in C}}
+signed _Accum s_accum;  // expected-error{{Fixed point types are only allowed in C}}
+signed long _Accum s_long_accum;// expected-error{{Fixed point types are only allowed in C}}
+unsigned short _Accum u_short_accum;// expected-error{{Fixed point types are only allowed in C}}
+unsigned _Accum u_accum;// expected-error{{Fixed point types are only allowed in C}}
+unsigned long _Accum u_long_accum;  // expected-error{{Fixed point types are only allowed in C}}
+
+short _Accum short_accum;   // expected-error{{Fixed point types are only allowed in C}}
+_Accum accum;   // expected-error{{Fixed point types are only allowed in C}}
+long _Accum long_accum; // expected-error{{Fixed point types are only allowed in C}}
Index: test/Frontend/fixed_point_errors.c
===
--- /dev/null
+++ test/Frontend/fixed_point_errors.c
@@ -0,0 +1,14 @@
+// RUN: %clang_cc1 -x c -fsyntax-only -verify -pedantic %s
+
+long long _Accum longlong_accum;  // expected-error{{'long long _Accum' is invalid}}
+unsigned long long _Accum u_longlong_accum;  // expected-error{{'long long _Accum' is invalid}}
+long long _Fract longlong_fract;  // expected-error{{'long long _Fract' is invalid}}
+unsigned long long _Fract u_longlong_fract;  // expected-error{{'long long _Fract' is invalid}}
+
+_Sat int i;  // expected-error{{'int' cannot be saturated. Only _Fract and _Accum can.}}
+_Sat _Sat _Fract fract;  // expected-warning{{duplicate '_Sat' declaration specifier}}
+
+_Sat long long _Accum sat_longlong_accum;  // expected-error{{'long long _Accum' is invalid}}
+_Sat unsigned long long _Accum sat_u_longlong_accum;  // expected-error{{'long long _Accum' is invalid}}
+_Sat long long _Fract sat_longlong_fract;  // expected-error{{'long long _Fract' is invalid}}
+_Sat unsigned long long _Fract sat_u_longlong_fract;  // expected-error{{'long long _Fract' is invalid}}
Index: test/Frontend/fixed_point.c
===
--- /dev/null
+++ test/Frontend/fixed_point.c
@@ -0,0 +1,82 @@
+// RUN: %clang -cc1 -x c -ast-dump %s | FileCheck %s --strict-whitespace
+
+// Primary fixed point types
+signed short _Accum s_short_accum;
+signed _Accum s_accum;
+signed long _Accum s_long_accum;
+unsigned short _Accum u_short_accum;
+unsigned _Accum u_accum;
+unsigned long _Accum u_long_accum;
+signed short _Fract s_short_fract;
+signed _Fract s_fract;
+signed long _Fract s_long_fract;
+unsigned short _Fract u_short_fract;
+unsigned _Fract u_fract;
+unsigned long _Fract u_long_fract;
+
+// Aliased fixed point types
+short _Accum short_accum;
+_Accum accum;
+long _Accum long_accum;
+short _Fract short_fract;
+_Fract fract;
+long _Fract long_fract;
+
+// Saturated fixed point types
+_Sat signed short _Accum sat_s_short_accum;
+_Sat signed _Accum sat_s_accum;
+_Sat signed long _Accum sat_s_long_accum;
+_Sat unsigned short _Accum sat_u_short_accum;
+_Sat unsigned _Accum sat_u_accum;
+_Sat unsigned long _Accum sat_u_long_accum;
+_Sat signed short _Fract sat_s_short_fract;
+_Sat signed _Fract sat_s_fract;
+_Sat signed long _Fract sat_s_long_fract;
+_Sat unsigned short _Fract sat_u_short_fract;
+_Sat unsigned _Fract sat_u_fract;
+_Sat unsigned long _Fract sat_u_long_fract;
+
+// Aliased saturated fixed point types
+_Sat short _Accum sat_short_accum;
+_Sat _Accum sat_accum;
+_Sat long _Accum sat_long_accum;
+_Sat short _Fract sat_

Re: r332720 - Move #include manipulation code to new lib/Tooling/Inclusions.

[Eric Liu via cfe-commits]

So I have reverted this with r332751.

I can't see how this introduced cyclic dependencies in module build, as the
dependencies should be clangTooling -> clangFormat ->
clangToolingInclusions. I'm wondering if there is any module configurations
that I need to update to make this work. Right now, module doesn't seem to
make any difference between clangTooling and clangToolingInclusions... I'd
appreciate it if someone who knows how clang module build is set up could
help take a look.

Unfortunately, I couldn't reproduce this on my workstation as the module
build seemed to be broken due to other errors. I was seeing a lot of
warnings; the clang I used to build llvm was built near HEAD. Maybe my
clang is too new?

Thanks,
Eric

On Fri, May 18, 2018 at 7:52 PM Eric Liu  wrote:

> Sorry, I'll look into it right now. Will revert it if I can't find a quick
> fix.
>
> On Fri, May 18, 2018, 19:49 Amara Emerson  wrote:
>
>> Hi Eric,
>>
>> Green dragon buildbots have started failing too, e.g.:
>> http://green.lab.llvm.org/green/job/clang-stage2-Rthinlto/10222/
>>
>> If you don’t have a quick fix can you please revert it.
>>
>> Thanks,
>> Amara
>>
>>
>> On May 18, 2018, at 7:46 PM, Eric Liu  wrote:
>>
>> Hi Vedant,
>>
>> It seems that your build was not using cmake files in the source tree? 
>> lib/Tooling/Inclusions/
>> is a (new) standalone library (clangToolingInclusions, similar to
>> clangToolingCore). You might need update your build to reflect this change.
>> Let me know if you have any further question.
>>
>> Thanks,
>> Eric
>>
>> On Fri, May 18, 2018 at 6:41 PM Vedant Kumar  wrote:
>>
>>> Hi Eric,
>>>
>>> I think there might be a cyclic dependency issue here, possibly one
>>> that's only visible with LLVM_ENABLE_MODULES=On. I see:
>>>
>>> While building module 'Clang_Tooling' imported from /Users/vsk/src/
>>> llvm.org-master/llvm/tools/clang/lib/Tooling/Execution.cpp:10:
>>>
>>> While building module 'Clang_Format' imported from /Users/vsk/src/
>>> llvm.org-master/llvm/tools/clang/include/clang/Tooling/Refactoring/AtomicChange.h:19:
>>>
>>> In file included from :1:
>>>
>>>
>>> /Users/vsk/src/llvm.org-master/llvm/tools/clang/include/clang/Format/Format.h:20:10:
>>> fatal error: cyclic dependency in module 'Clang_Tooling': Clang_Tooling $>
>>> Clang_Format -> Clang_Tooling
>>>
>>> #include "clang/Tooling/Inclusions/IncludeStyle.h"
>>>  ^
>>> While building module 'Clang_Tooling' imported from /Users/vsk/src/
>>> llvm.org-master/llvm/tools/clang/lib/Tooling/Execution.cpp:10:
>>> In file included from :22:
>>>
>>> In file included from /Users/vsk/src/llvm.org
>>> -master/llvm/tools/clang/include/clang/Tooling/Refactoring/RefactoringAction.h:14:
>>> In file included from /Users/vsk/src/llvm.org
>>> -master/llvm/tools/clang/include/clang/Tooling/Refactoring/RefactoringActionRules.h:14:
>>> In file included from /Users/vsk/src/llvm.org
>>> -master/llvm/tools/clang/include/clang/Tooling/Refactoring/RefactoringActionRulesInternal.h:16:
>>> In file included from /Users/vsk/src/llvm.org
>>> -master/llvm/tools/clang/include/clang/Tooling/Refactoring/RefactoringResultConsumer.h:14:
>>> /Users/vsk/src/llvm.org-master/llvm/tools/clang/include/clang/Tooling/Refactoring/AtomicChange.h:19:10:
>>> fatal error: could not build module 'Clang_Format'
>>> #include "clang/Format/Format.h"
>>>  ^~~
>>> /Users/vsk/src/llvm.org-master/llvm/tools/clang/lib/Tooling/Execution.cpp:10:10:
>>> fatal error: could not build module 'Clang_Tooling'
>>> #include "clang/Tooling/Execution.h"
>>>
>>>  ^~~
>>> 3 errors generated.
>>>
>>> Could you take a look?
>>>
>>> thanks,
>>> vedant
>>>
>>> > On May 18, 2018, at 7:16 AM, Eric Liu via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>> >
>>> > Author: ioeric
>>> > Date: Fri May 18 07:16:37 2018
>>> > New Revision: 332720
>>> >
>>> > URL: http://llvm.org/viewvc/llvm-project?rev=332720&view=rev
>>> > Log:
>>> > Move #include manipulation code to new lib/Tooling/Inclusions.
>>> >
>>> > Summary:
>>> > clangToolingCore is linked into almost everything (incl. clang), but
>>> > not few tools need #include manipulation at this point. So pull this
>>> into a
>>> > separate library in Tooling.
>>> >
>>> > Reviewers: ilya-biryukov
>>> >
>>> > Subscribers: klimek, mgorny, cfe-commits, thakis
>>> >
>>> > Differential Revision: https://reviews.llvm.org/D47068
>>> >
>>> > Added:
>>> >cfe/trunk/include/clang/Tooling/Inclusions/
>>> >cfe/trunk/include/clang/Tooling/Inclusions/HeaderIncludes.h
>>> >  - copied, changed from r332717,
>>> cfe/trunk/include/clang/Tooling/Core/HeaderIncludes.h
>>> >cfe/trunk/include/clang/Tooling/Inclusions/IncludeStyle.h
>>> >  - copied, changed from r332717,
>>> cfe/trunk/include/clang/Tooling/Core/IncludeStyle.h
>>> >cfe/trunk/lib/Tooling/Inclusions/
>>> >cfe/trunk/lib/Tooling/Inclusions/CMakeLists.txt
>>> >  - copied, changed from r332717,
>>> cfe/trunk/lib/Tooling/Core/CMakeList

[PATCH] D47068: Move #include manipulation code to new lib/Tooling/Inclusions.

[Eric Liu via Phabricator via cfe-commits]

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

This was reverted in r332751 due to build bot failure with module config. I 
don't see how this failed as the directory setup is very similar to 
Tooling/Core/. Will investigate further next week.


Repository:
  rL LLVM

https://reviews.llvm.org/D47068



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

[PATCH] D46910: [Support] Avoid normalization in sys::getDefaultTargetTriple

[Petr Hosek via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC332750: [Support] Avoid normalization in 
sys::getDefaultTargetTriple (authored by phosek, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D46910?vs=147431&id=147567#toc

Repository:
  rC Clang

https://reviews.llvm.org/D46910

Files:
  lib/Frontend/CompilerInvocation.cpp


Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -2927,10 +2927,11 @@
   Opts.FPMath = Args.getLastArgValue(OPT_mfpmath);
   Opts.FeaturesAsWritten = Args.getAllArgValues(OPT_target_feature);
   Opts.LinkerVersion = Args.getLastArgValue(OPT_target_linker_version);
-  Opts.Triple = llvm::Triple::normalize(Args.getLastArgValue(OPT_triple));
+  Opts.Triple = Args.getLastArgValue(OPT_triple);
   // Use the default target triple if unspecified.
   if (Opts.Triple.empty())
 Opts.Triple = llvm::sys::getDefaultTargetTriple();
+  Opts.Triple = llvm::Triple::normalize(Opts.Triple);
   Opts.OpenCLExtensionsAsWritten = Args.getAllArgValues(OPT_cl_ext_EQ);
   Opts.ForceEnableInt128 = Args.hasArg(OPT_fforce_enable_int128);
   Opts.NVPTXUseShortPointers = Args.hasFlag(


Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -2927,10 +2927,11 @@
   Opts.FPMath = Args.getLastArgValue(OPT_mfpmath);
   Opts.FeaturesAsWritten = Args.getAllArgValues(OPT_target_feature);
   Opts.LinkerVersion = Args.getLastArgValue(OPT_target_linker_version);
-  Opts.Triple = llvm::Triple::normalize(Args.getLastArgValue(OPT_triple));
+  Opts.Triple = Args.getLastArgValue(OPT_triple);
   // Use the default target triple if unspecified.
   if (Opts.Triple.empty())
 Opts.Triple = llvm::sys::getDefaultTargetTriple();
+  Opts.Triple = llvm::Triple::normalize(Opts.Triple);
   Opts.OpenCLExtensionsAsWritten = Args.getAllArgValues(OPT_cl_ext_EQ);
   Opts.ForceEnableInt128 = Args.hasArg(OPT_fforce_enable_int128);
   Opts.NVPTXUseShortPointers = Args.hasFlag(
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] r332752 - Revert "[clangd] Adapt file migration in r332720"

[Eric Liu via cfe-commits]

Author: ioeric
Date: Fri May 18 11:33:21 2018
New Revision: 332752

URL: http://llvm.org/viewvc/llvm-project?rev=332752&view=rev
Log:
Revert "[clangd] Adapt file migration in r332720"

This reverts commit r332721 because the dependency r33270 will be reverted.

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

Modified: clang-tools-extra/trunk/clangd/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/CMakeLists.txt?rev=332752&r1=332751&r2=332752&view=diff
==
--- clang-tools-extra/trunk/clangd/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clangd/CMakeLists.txt Fri May 18 11:33:21 2018
@@ -55,7 +55,6 @@ add_clang_library(clangDaemon
   clangSerialization
   clangTooling
   clangToolingCore
-  clangToolingInclusions
   clangToolingRefactor
   ${LLVM_PTHREAD_LIB}
   ${CLANGD_ATOMIC_LIB}

Modified: clang-tools-extra/trunk/clangd/Headers.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/Headers.h?rev=332752&r1=332751&r2=332752&view=diff
==
--- clang-tools-extra/trunk/clangd/Headers.h (original)
+++ clang-tools-extra/trunk/clangd/Headers.h Fri May 18 11:33:21 2018
@@ -17,7 +17,7 @@
 #include "clang/Format/Format.h"
 #include "clang/Lex/HeaderSearch.h"
 #include "clang/Lex/PPCallbacks.h"
-#include "clang/Tooling/Inclusions/HeaderIncludes.h"
+#include "clang/Tooling/Core/HeaderIncludes.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/StringSet.h"
 #include "llvm/Support/Error.h"


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

[PATCH] D47057: [ASTImporter] Fix missing implict CXXRecordDecl in ClassTemplateSpecializationDecl

[Aleksei Sidorin via Phabricator via cfe-commits]

a.sidorin added inline comments.



Comment at: lib/AST/ASTImporter.cpp:1962
   TagDecl *Definition = D->getDefinition();
-  if (Definition && Definition != D) {
+  if (!D->isImplicit() && Definition && Definition != D) {
 Decl *ImportedDef = Importer.Import(Definition);

We are changing import if RecordDecl. Is it possible to add a test that doesn't 
require templates?
I tried and found that the implicit CXXRecordDecl of 
ClassTemplateSpecializationDecl is its redeclaration. That's not true for 
normal CXXRecordDecls, as I see, so this deserves a comment.


Repository:
  rC Clang

https://reviews.llvm.org/D47057



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

r332751 - Revert "Move #include manipulation code to new lib/Tooling/Inclusions."

[Eric Liu via cfe-commits]

Author: ioeric
Date: Fri May 18 11:33:08 2018
New Revision: 332751

URL: http://llvm.org/viewvc/llvm-project?rev=332751&view=rev
Log:
Revert "Move #include manipulation code to new lib/Tooling/Inclusions."

This reverts commit r332720. This break build bot with modules. Need to
investigate. Revert the change to unbreak bots.

Added:
cfe/trunk/include/clang/Tooling/Core/HeaderIncludes.h
  - copied, changed from r332738, 
cfe/trunk/include/clang/Tooling/Inclusions/HeaderIncludes.h
cfe/trunk/include/clang/Tooling/Core/IncludeStyle.h
  - copied, changed from r332738, 
cfe/trunk/include/clang/Tooling/Inclusions/IncludeStyle.h
cfe/trunk/lib/Tooling/Core/HeaderIncludes.cpp
  - copied, changed from r332738, 
cfe/trunk/lib/Tooling/Inclusions/HeaderIncludes.cpp
cfe/trunk/lib/Tooling/Core/IncludeStyle.cpp
  - copied, changed from r332738, 
cfe/trunk/lib/Tooling/Inclusions/IncludeStyle.cpp
Removed:
cfe/trunk/include/clang/Tooling/Inclusions/HeaderIncludes.h
cfe/trunk/include/clang/Tooling/Inclusions/IncludeStyle.h
cfe/trunk/lib/Tooling/Inclusions/CMakeLists.txt
cfe/trunk/lib/Tooling/Inclusions/HeaderIncludes.cpp
cfe/trunk/lib/Tooling/Inclusions/IncludeStyle.cpp
Modified:
cfe/trunk/include/clang/Format/Format.h
cfe/trunk/lib/Format/CMakeLists.txt
cfe/trunk/lib/Format/Format.cpp
cfe/trunk/lib/Tooling/CMakeLists.txt
cfe/trunk/lib/Tooling/Core/CMakeLists.txt
cfe/trunk/unittests/Tooling/HeaderIncludesTest.cpp

Modified: cfe/trunk/include/clang/Format/Format.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Format/Format.h?rev=332751&r1=332750&r2=332751&view=diff
==
--- cfe/trunk/include/clang/Format/Format.h (original)
+++ cfe/trunk/include/clang/Format/Format.h Fri May 18 11:33:08 2018
@@ -16,8 +16,8 @@
 #define LLVM_CLANG_FORMAT_FORMAT_H
 
 #include "clang/Basic/LangOptions.h"
+#include "clang/Tooling/Core/IncludeStyle.h"
 #include "clang/Tooling/Core/Replacement.h"
-#include "clang/Tooling/Inclusions/IncludeStyle.h"
 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/Support/Regex.h"
 #include 

Copied: cfe/trunk/include/clang/Tooling/Core/HeaderIncludes.h (from r332738, 
cfe/trunk/include/clang/Tooling/Inclusions/HeaderIncludes.h)
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Tooling/Core/HeaderIncludes.h?p2=cfe/trunk/include/clang/Tooling/Core/HeaderIncludes.h&p1=cfe/trunk/include/clang/Tooling/Inclusions/HeaderIncludes.h&r1=332738&r2=332751&rev=332751&view=diff
==
--- cfe/trunk/include/clang/Tooling/Inclusions/HeaderIncludes.h (original)
+++ cfe/trunk/include/clang/Tooling/Core/HeaderIncludes.h Fri May 18 11:33:08 
2018
@@ -7,12 +7,12 @@
 //
 
//===--===//
 
-#ifndef LLVM_CLANG_TOOLING_INCLUSIONS_HEADERINCLUDES_H
-#define LLVM_CLANG_TOOLING_INCLUSIONS_HEADERINCLUDES_H
+#ifndef LLVM_CLANG_TOOLING_CORE_HEADERINCLUDES_H
+#define LLVM_CLANG_TOOLING_CORE_HEADERINCLUDES_H
 
 #include "clang/Basic/SourceManager.h"
 #include "clang/Tooling/Core/Replacement.h"
-#include "clang/Tooling/Inclusions/IncludeStyle.h"
+#include "clang/Tooling/Core/IncludeStyle.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/Regex.h"
 #include 
@@ -134,4 +134,4 @@ private:
 } // namespace tooling
 } // namespace clang
 
-#endif // LLVM_CLANG_TOOLING_INCLUSIONS_HEADERINCLUDES_H
+#endif // LLVM_CLANG_TOOLING_CORE_HEADERINCLUDES_H

Copied: cfe/trunk/include/clang/Tooling/Core/IncludeStyle.h (from r332738, 
cfe/trunk/include/clang/Tooling/Inclusions/IncludeStyle.h)
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Tooling/Core/IncludeStyle.h?p2=cfe/trunk/include/clang/Tooling/Core/IncludeStyle.h&p1=cfe/trunk/include/clang/Tooling/Inclusions/IncludeStyle.h&r1=332738&r2=332751&rev=332751&view=diff
==
--- cfe/trunk/include/clang/Tooling/Inclusions/IncludeStyle.h (original)
+++ cfe/trunk/include/clang/Tooling/Core/IncludeStyle.h Fri May 18 11:33:08 2018
@@ -7,8 +7,8 @@
 //
 
//===--===//
 
-#ifndef LLVM_CLANG_TOOLING_INCLUSIONS_INCLUDESTYLE_H
-#define LLVM_CLANG_TOOLING_INCLUSIONS_INCLUDESTYLE_H
+#ifndef LLVM_CLANG_TOOLING_CORE_INCLUDESTYLE_H
+#define LLVM_CLANG_TOOLING_CORE_INCLUDESTYLE_H
 
 #include "llvm/Support/YAMLTraits.h"
 #include 
@@ -130,4 +130,4 @@ struct ScalarEnumerationTraits<
 } // namespace yaml
 } // namespace llvm
 
-#endif // LLVM_CLANG_TOOLING_INCLUSIONS_INCLUDESTYLE_H
+#endif // LLVM_CLANG_TOOLING_CORE_INCLUDESTYLE_H

Removed: cfe/trunk/include/clang/Tooling/Inclusions/HeaderIncludes.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Tooling/Inclusions/HeaderIncludes.h?rev=332750&view=auto

r332750 - [Support] Avoid normalization in sys::getDefaultTargetTriple

[Petr Hosek via cfe-commits]

Author: phosek
Date: Fri May 18 11:33:07 2018
New Revision: 332750

URL: http://llvm.org/viewvc/llvm-project?rev=332750&view=rev
Log:
[Support] Avoid normalization in sys::getDefaultTargetTriple

The return value of sys::getDefaultTargetTriple, which is derived from
-DLLVM_DEFAULT_TRIPLE, is used to construct tool names, default target,
and in the future also to control the search path directly; as such it
should be used textually, without interpretation by LLVM.

Normalization of this value may lead to unexpected results, for example
if we configure LLVM with -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-linux-gnu,
normalization will transform that value to x86_64--linux-gnu. Driver will
use that value to search for tools prefixed with x86_64--linux-gnu- which
may be confusing. This is also inconsistent with the behavior of the
--target flag which is taken as-is without any normalization and overrides
the value of LLVM_DEFAULT_TARGET_TRIPLE.

Users of sys::getDefaultTargetTriple already perform their own
normalization as needed, so this change shouldn't impact existing logic.

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

Modified:
cfe/trunk/lib/Frontend/CompilerInvocation.cpp

Modified: cfe/trunk/lib/Frontend/CompilerInvocation.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInvocation.cpp?rev=332750&r1=332749&r2=332750&view=diff
==
--- cfe/trunk/lib/Frontend/CompilerInvocation.cpp (original)
+++ cfe/trunk/lib/Frontend/CompilerInvocation.cpp Fri May 18 11:33:07 2018
@@ -2927,10 +2927,11 @@ static void ParseTargetArgs(TargetOption
   Opts.FPMath = Args.getLastArgValue(OPT_mfpmath);
   Opts.FeaturesAsWritten = Args.getAllArgValues(OPT_target_feature);
   Opts.LinkerVersion = Args.getLastArgValue(OPT_target_linker_version);
-  Opts.Triple = llvm::Triple::normalize(Args.getLastArgValue(OPT_triple));
+  Opts.Triple = Args.getLastArgValue(OPT_triple);
   // Use the default target triple if unspecified.
   if (Opts.Triple.empty())
 Opts.Triple = llvm::sys::getDefaultTargetTriple();
+  Opts.Triple = llvm::Triple::normalize(Opts.Triple);
   Opts.OpenCLExtensionsAsWritten = Args.getAllArgValues(OPT_cl_ext_EQ);
   Opts.ForceEnableInt128 = Args.hasArg(OPT_fforce_enable_int128);
   Opts.NVPTXUseShortPointers = Args.hasFlag(


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