[clang-tools-extra] r352953 - [Clangd] textDocument/definition and textDocument/declaration "bounce" between definition and declaration location when they are distinct.

2019-02-01 Thread Sam McCall via cfe-commits
Author: sammccall
Date: Fri Feb  1 21:56:00 2019
New Revision: 352953

URL: http://llvm.org/viewvc/llvm-project?rev=352953=rev
Log:
[Clangd] textDocument/definition and textDocument/declaration "bounce" between 
definition and declaration location when they are distinct.

Summary:
This helps minimize the disruption of not returning declarations as part of
a find-definition response (r352864).

Reviewers: hokein

Subscribers: ioeric, MaskRay, jkorous, arphaman, kadircet, ilya-biryukov

Tags: #clang

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

Modified:
clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
clang-tools-extra/trunk/test/clangd/xrefs.test

Modified: clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp?rev=352953=352952=352953=diff
==
--- clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp (original)
+++ clang-tools-extra/trunk/clangd/ClangdLSPServer.cpp Fri Feb  1 21:56:00 2019
@@ -726,18 +726,41 @@ void ClangdLSPServer::onSignatureHelp(co
 std::move(Reply));
 }
 
+// Go to definition has a toggle function: if def and decl are distinct, then
+// the first press gives you the def, the second gives you the matching def.
+// getToggle() returns the counterpart location that under the cursor.
+//
+// We return the toggled location alone (ignoring other symbols) to encourage
+// editors to "bounce" quickly between locations, without showing a menu.
+static Location *getToggle(const TextDocumentPositionParams ,
+   LocatedSymbol ) {
+  // Toggle only makes sense with two distinct locations.
+  if (!Sym.Definition || *Sym.Definition == Sym.PreferredDeclaration)
+return nullptr;
+  if (Sym.Definition->uri.file() == Point.textDocument.uri.file() &&
+  Sym.Definition->range.contains(Point.position))
+return 
+  if (Sym.PreferredDeclaration.uri.file() == Point.textDocument.uri.file() &&
+  Sym.PreferredDeclaration.range.contains(Point.position))
+return &*Sym.Definition;
+  return nullptr;
+}
+
 void ClangdLSPServer::onGoToDefinition(const TextDocumentPositionParams 
,
Callback> Reply) {
   Server->locateSymbolAt(
   Params.textDocument.uri.file(), Params.position,
   Bind(
-  [&](decltype(Reply) Reply,
-  llvm::Expected> Symbols) {
+  [&, Params](decltype(Reply) Reply,
+  llvm::Expected> Symbols) {
 if (!Symbols)
   return Reply(Symbols.takeError());
 std::vector Defs;
-for (const auto  : *Symbols)
+for (auto  : *Symbols) {
+  if (Location *Toggle = getToggle(Params, S))
+return Reply(std::vector{std::move(*Toggle)});
   Defs.push_back(S.Definition.getValueOr(S.PreferredDeclaration));
+}
 Reply(std::move(Defs));
   },
   std::move(Reply)));
@@ -749,13 +772,16 @@ void ClangdLSPServer::onGoToDeclaration(
   Server->locateSymbolAt(
   Params.textDocument.uri.file(), Params.position,
   Bind(
-  [&](decltype(Reply) Reply,
-  llvm::Expected> Symbols) {
+  [&, Params](decltype(Reply) Reply,
+  llvm::Expected> Symbols) {
 if (!Symbols)
   return Reply(Symbols.takeError());
 std::vector Decls;
-for (const auto  : *Symbols)
-  Decls.push_back(S.PreferredDeclaration);
+for (auto  : *Symbols) {
+  if (Location *Toggle = getToggle(Params, S))
+return Reply(std::vector{std::move(*Toggle)});
+  Decls.push_back(std::move(S.PreferredDeclaration));
+}
 Reply(std::move(Decls));
   },
   std::move(Reply)));

Modified: clang-tools-extra/trunk/test/clangd/xrefs.test
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clangd/xrefs.test?rev=352953=352952=352953=diff
==
--- clang-tools-extra/trunk/test/clangd/xrefs.test (original)
+++ clang-tools-extra/trunk/test/clangd/xrefs.test Fri Feb  1 21:56:00 2019
@@ -1,9 +1,9 @@
 # RUN: clangd -lit-test < %s | FileCheck -strict-whitespace %s
 
{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"processId":123,"rootPath":"clangd","capabilities":{},"trace":"off"}}
 ---
-{"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"uri":"test:///main.cpp","languageId":"cpp","version":1,"text":"int
 x = 0;\nint y = x;"}}}
+{"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"uri":"test:///main.cpp","languageId":"cpp","version":1,"text":"extern
 int x;\nint x = 0;\nint y = x;"}}}
 ---

[PATCH] D57553: [Fixed Point Arithmetic] Avoid resizing for types with the same width

2019-02-01 Thread Leonard Chan via Phabricator via cfe-commits
leonardchan added a comment.

In D57553#1380157 , @ebevhan wrote:

> This doesn't seem to address the particular case in the integer conversion 
> patch. In fact, I don't see those conversions at all.


I was initially planning on rebasing and updating the parent patch of this 
after you took a look at it, but I did not account for the min-max pattern. 
Incidentally, we can still get the same results without having to change a lot 
of other tests or existing code if we just add a check for if the source and 
target have the same width. The saturation test cases these affect are the same 
as in the previous revision without having to change the other operations and 
still uses the min-max pattern.

In regards to solving the problem of resizing for int conversions, I'm starting 
to think that we will need that initial resize since if we want to retain the 
min-max pattern for all conversions, then it would be necessary to extend and 
shift when converting from an int to fixed point. Otherwise, I think we'd have 
the initial pattern I proposed where we check against the source value, but not 
have this pattern.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57553



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


[PATCH] D57553: [Fixed Point Arithmetic] Avoid resizing for types with the same width

2019-02-01 Thread Leonard Chan via Phabricator via cfe-commits
leonardchan updated this revision to Diff 184888.
leonardchan retitled this revision from "[Fixed Point Arithmetic] Check against 
source value when converting during saturation" to "[Fixed Point Arithmetic] 
Avoid resizing for types with the same width".
leonardchan edited the summary of this revision.

Repository:
  rC Clang

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

https://reviews.llvm.org/D57553

Files:
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/test/Frontend/fixed_point_conversions.c


Index: clang/test/Frontend/fixed_point_conversions.c
===
--- clang/test/Frontend/fixed_point_conversions.c
+++ clang/test/Frontend/fixed_point_conversions.c
@@ -186,14 +186,12 @@
   // Accum to Fract, increasing scale
   sat_lf = sat_a;
   // DEFAULT:  [[OLD_ACCUM:%[0-9a-z]+]] = load i32, i32* %sat_a, align 4
-  // DEFAULT-NEXT: [[ACCUM:%[0-9a-z]+]] = sext i32 [[OLD_ACCUM]] to i48
-  // DEFAULT-NEXT: [[FRACT:%[0-9a-z]+]] = shl i48 [[ACCUM]], 16
-  // DEFAULT-NEXT: [[USE_MAX:%[0-9a-z]+]] = icmp sgt i48 [[FRACT]], 2147483647
-  // DEFAULT-NEXT: [[RESULT:%[0-9a-z]+]] = select i1 [[USE_MAX]], i48 
2147483647, i48 [[FRACT]]
-  // DEFAULT-NEXT: [[USE_MIN:%[0-9a-z]+]] = icmp slt i48 [[RESULT]], 
-2147483648
-  // DEFAULT-NEXT: [[RESULT2:%[0-9a-z]+]] = select i1 [[USE_MIN]], i48 
-2147483648, i48 [[RESULT]]
-  // DEFAULT-NEXT: [[RESULT_TRUNC:%[0-9a-z]+]] = trunc i48 [[RESULT2]] to i32
-  // DEFAULT-NEXT: store i32 [[RESULT_TRUNC]], i32* %sat_lf, align 4
+  // DEFAULT-NEXT: [[FRACT:%[0-9a-z]+]] = shl i32 [[OLD_ACCUM]], 16
+  // DEFAULT-NEXT: [[USE_MAX:%[0-9a-z]+]] = icmp sgt i32 [[FRACT]], 2147483647
+  // DEFAULT-NEXT: [[RESULT:%[0-9a-z]+]] = select i1 [[USE_MAX]], i32 
2147483647, i32 [[FRACT]]
+  // DEFAULT-NEXT: [[USE_MIN:%[0-9a-z]+]] = icmp slt i32 [[RESULT]], 
-2147483648
+  // DEFAULT-NEXT: [[RESULT2:%[0-9a-z]+]] = select i1 [[USE_MIN]], i32 
-2147483648, i32 [[RESULT]]
+  // DEFAULT-NEXT: store i32 [[RESULT2]], i32* %sat_lf, align 4
 
   // Signed to unsigned, decreasing scale
   _Sat _Accum sat_a2;
@@ -218,12 +216,10 @@
   // Signed to unsigned, increasing scale
   sat_ua = sat_a;
   // DEFAULT:  [[OLD_ACCUM:%[0-9a-z]+]] = load i32, i32* %sat_a, align 4
-  // DEFAULT-NEXT: [[ACCUM_EXT:%[0-9a-z]+]] = sext i32 [[OLD_ACCUM]] to i33
-  // DEFAULT-NEXT: [[ACCUM:%[0-9a-z]+]] = shl i33 [[ACCUM_EXT]], 1
-  // DEFAULT-NEXT: [[USE_MIN:%[0-9a-z]+]] = icmp slt i33 [[ACCUM]], 0
-  // DEFAULT-NEXT: [[RESULT2:%[0-9a-z]+]] = select i1 [[USE_MIN]], i33 0, i33 
[[ACCUM]]
-  // DEFAULT-NEXT: [[RESULT_TRUNC:%[0-9a-z]+]] = trunc i33 [[RESULT2]] to i32
-  // DEFAULT-NEXT: store i32 [[RESULT_TRUNC]], i32* %sat_ua, align 4
+  // DEFAULT-NEXT: [[ACCUM:%[0-9a-z]+]] = shl i32 [[OLD_ACCUM]], 1
+  // DEFAULT-NEXT: [[USE_MIN:%[0-9a-z]+]] = icmp slt i32 [[ACCUM]], 0
+  // DEFAULT-NEXT: [[RESULT2:%[0-9a-z]+]] = select i1 [[USE_MIN]], i32 0, i32 
[[ACCUM]]
+  // DEFAULT-NEXT: store i32 [[RESULT2]], i32* %sat_ua, align 4
   // SAME:  [[ACCUM:%[0-9a-z]+]] = load i32, i32* %sat_a, align 4
   // SAME-NEXT: [[USE_MIN:%[0-9a-z]+]] = icmp slt i32 [[ACCUM]], 0
   // SAME-NEXT: [[RESULT:%[0-9a-z]+]] = select i1 [[USE_MIN]], i32 0, i32 
[[ACCUM]]
Index: clang/lib/CodeGen/CGExprScalar.cpp
===
--- clang/lib/CodeGen/CGExprScalar.cpp
+++ clang/lib/CodeGen/CGExprScalar.cpp
@@ -1481,9 +1481,14 @@
 // Adjust the number of fractional bits.
 if (DstScale > SrcScale) {
   // Compare to DstWidth to prevent resizing twice.
-  ResultWidth = std::max(SrcWidth + DstScale - SrcScale, DstWidth);
-  llvm::Type *UpscaledTy = Builder.getIntNTy(ResultWidth);
-  Result = Builder.CreateIntCast(Result, UpscaledTy, SrcIsSigned, 
"resize");
+  if (ResultWidth != DstWidth) {
+// No rescaling is needed if both sides have the same resulting width.
+// This would end up with a needless int cast.
+ResultWidth = std::max(SrcWidth + DstScale - SrcScale, DstWidth);
+llvm::Type *UpscaledTy = Builder.getIntNTy(ResultWidth);
+Result =
+Builder.CreateIntCast(Result, UpscaledTy, SrcIsSigned, "resize");
+  }
   Result = Builder.CreateShl(Result, DstScale - SrcScale, "upscale");
 } else if (DstScale < SrcScale) {
   Result = SrcIsSigned ?


Index: clang/test/Frontend/fixed_point_conversions.c
===
--- clang/test/Frontend/fixed_point_conversions.c
+++ clang/test/Frontend/fixed_point_conversions.c
@@ -186,14 +186,12 @@
   // Accum to Fract, increasing scale
   sat_lf = sat_a;
   // DEFAULT:  [[OLD_ACCUM:%[0-9a-z]+]] = load i32, i32* %sat_a, align 4
-  // DEFAULT-NEXT: [[ACCUM:%[0-9a-z]+]] = sext i32 [[OLD_ACCUM]] to i48
-  // DEFAULT-NEXT: [[FRACT:%[0-9a-z]+]] = shl i48 [[ACCUM]], 16
-  // DEFAULT-NEXT: [[USE_MAX:%[0-9a-z]+]] = icmp sgt i48 [[FRACT]], 2147483647
-  // 

[PATCH] D57636: [COFF, ARM64] Fix types for _ReadStatusReg, _WriteStatusReg

2019-02-01 Thread Shoaib Meenai via Phabricator via cfe-commits
smeenai added subscribers: hans, smeenai.
smeenai added reviewers: rnk, efriedma.
smeenai added a comment.

+@hans for the release branch.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57636



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


[PATCH] D57219: [Fixed Point Arithmetic] Fixed Point Comparisons

2019-02-01 Thread Leonard Chan via Phabricator via cfe-commits
leonardchan added inline comments.



Comment at: clang/lib/CodeGen/CGExprScalar.cpp:3444
   case BO_NE:
+return Builder.CreateICmpNE(FullLHS, FullRHS);
+  case BO_Mul:

rjmccall wrote:
> leonardchan wrote:
> > rjmccall wrote:
> > > Are padding bits guaranteed zero or unspecified?  Or are we just not 
> > > really supporting padding bits all the way to IRGen at this time?
> > I believe the consensus was leaving them unspecified, so operations that 
> > can cause overflow into them would result in undefined behavior.
> If I'm understanding you correctly, you're saying that (1) we are assuming 
> that inputs are zero-padded and (2) we are taking advantage of the 
> non-saturating-overflow-is-UB rule to avoid clearing the padding bits after 
> arithmetic.  That's actually what I meant by "guaranteed zero", so we have 
> our labels reversed, but at least we understand each other now.
> 
> (I suppose you're thinking of this as "unspecified" because non-saturating 
> arithmetic can leave an unspecified value there.  I think of this as a 
> "guarantee" because it's basically a representational invariant: it's a 
> precondition for correctness that the bit is zero, and all operations 
> guarantee that the bit will be zero in their well-defined cases (but overflow 
> is not well-defined).  Just a difference in perspective, I guess.)
> 
> Is this written down somewhere?  Are there targets that use the opposite ABI 
> rule that we might need to support someday?
> 
> At any rate, I think it's worth adding a short comment here explaining why 
> it's okay to do a normal comparison despite the possibility of padding bits.  
> Along those lines, is there any value in communicating to the backend that 
> padded-unsigned comparisons could reasonably be done with either a signed or 
> unsigned comparison?  Are there interesting targets where one or the other is 
> cheaper?
Yes. We assume inputs are zero padded, and that non-saturating overflow is 
undefined so we do not need to clear the padding after writing a new value. 
Sorry for the misunderstanding. I see what you mean by guaranteed zero.

Overflow in general is controlled by the `FX_FRACT_OVERFLOW` and 
`FX_ACCUM_OVERFLOW` pragmas, where if these are set to `DEFAULT`, operations 
that can overflow with these types is undefined according to the standard 
(4.1.3). In terms of padding bits, clause 6.2.6.3 mentions that the values of 
padding bits are "unspecified". I imagine this means that we can assume the 
value to be whatever we want it to, so we can assume that these values are a 
guaranteed zero.

I believe @ebevhan requested this being added since his downstream 
implementation used padding to match the scales of signed and unsigned types, 
so he may be able to offer more information on targets with different ABIs. We 
don't plan to use any special hardware, so we're following the "typical desktop 
processor" layout that uses the whole underlying int and no padding (mentioned 
in Annex 3).

In the same section, the standard also mentions types for other targets that 
may have padding, so there could be some value in indicating to the backend 
that for these particular targets, this part of the operand is padding, so 
select an appropriate operation that performs a comparison on this size type. 
But I don't know much about these processors and would just be guessing at how 
they work.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57219



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


[PATCH] D57219: [Fixed Point Arithmetic] Fixed Point Comparisons

2019-02-01 Thread Leonard Chan via Phabricator via cfe-commits
leonardchan updated this revision to Diff 184886.
leonardchan marked an inline comment as done.

Repository:
  rC Clang

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

https://reviews.llvm.org/D57219

Files:
  clang/lib/AST/ExprConstant.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/test/Frontend/fixed_point_comparisons.c

Index: clang/test/Frontend/fixed_point_comparisons.c
===
--- /dev/null
+++ clang/test/Frontend/fixed_point_comparisons.c
@@ -0,0 +1,378 @@
+// RUN: %clang_cc1 -ffixed-point -triple x86_64-unknown-linux-gnu -S -emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK,UNPADDED
+// RUN: %clang_cc1 -ffixed-point -triple x86_64-unknown-linux-gnu -fpadding-on-unsigned-fixed-point -S -emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK,PADDED
+
+// Fixed point against other fixed point
+_Bool b_eq_true = 2.5hk == 2.5uhk;  // CHECK-DAG: @b_eq_true  = {{.*}}global i8 1, align 1
+_Bool b_eq_false = 2.5hk == 2.4uhk; // CHECK-DAG: @b_eq_false = {{.*}}global i8 0, align 1
+
+_Bool b_ne_true = 2.5hk != 2.4uhk;  // CHECK-DAG: @b_ne_true  = {{.*}}global i8 1, align 1
+_Bool b_ne_false = 2.5hk != 2.5uhk; // CHECK-DAG: @b_ne_false = {{.*}}global i8 0, align 1
+
+_Bool b_lt_true = 2.5hk < 2.75uhk; // CHECK-DAG: @b_lt_true  = {{.*}}global i8 1, align 1
+_Bool b_lt_false = 2.5hk < 2.5uhk; // CHECK-DAG: @b_lt_false = {{.*}}global i8 0, align 1
+
+_Bool b_le_true = 2.5hk <= 2.75uhk; // CHECK-DAG: @b_le_true  = {{.*}}global i8 1, align 1
+_Bool b_le_true2 = 2.5hk <= 2.5uhk; // CHECK-DAG: @b_le_true2 = {{.*}}global i8 1, align 1
+_Bool b_le_false = 2.5hk <= 2.4uhk; // CHECK-DAG: @b_le_false = {{.*}}global i8 0, align 1
+
+_Bool b_gt_true = 2.75hk > 2.5uhk;   // CHECK-DAG: @b_gt_true  = {{.*}}global i8 1, align 1
+_Bool b_gt_false = 2.75hk > 2.75uhk; // CHECK-DAG: @b_gt_false = {{.*}}global i8 0, align 1
+
+_Bool b_ge_true = 2.75hk >= 2.5uhk;   // CHECK-DAG: @b_ge_true  = {{.*}}global i8 1, align 1
+_Bool b_ge_true2 = 2.75hk >= 2.75uhk; // CHECK-DAG: @b_ge_true2 = {{.*}}global i8 1, align 1
+_Bool b_ge_false = 2.5hk >= 2.75uhk;  // CHECK-DAG: @b_ge_false = {{.*}}global i8 0, align 1
+
+// Fixed point against int
+_Bool b_ieq_true = 2.0hk == 2;  // CHECK-DAG: @b_ieq_true  = {{.*}}global i8 1, align 1
+_Bool b_ieq_false = 2.0hk == 3; // CHECK-DAG: @b_ieq_false = {{.*}}global i8 0, align 1
+
+_Bool b_ine_true = 2.0hk != 3;  // CHECK-DAG: @b_ine_true  = {{.*}}global i8 1, align 1
+_Bool b_ine_false = 2.0hk != 2; // CHECK-DAG: @b_ine_false = {{.*}}global i8 0, align 1
+
+_Bool b_ilt_true = 2.0hk < 3;  // CHECK-DAG: @b_ilt_true  = {{.*}}global i8 1, align 1
+_Bool b_ilt_false = 2.0hk < 2; // CHECK-DAG: @b_ilt_false = {{.*}}global i8 0, align 1
+
+_Bool b_ile_true = 2.0hk <= 3;  // CHECK-DAG: @b_ile_true  = {{.*}}global i8 1, align 1
+_Bool b_ile_true2 = 2.0hk <= 2; // CHECK-DAG: @b_ile_true2 = {{.*}}global i8 1, align 1
+_Bool b_ile_false = 2.0hk <= 1; // CHECK-DAG: @b_ile_false = {{.*}}global i8 0, align 1
+
+_Bool b_igt_true = 2.0hk > 1;  // CHECK-DAG: @b_igt_true  = {{.*}}global i8 1, align 1
+_Bool b_igt_false = 2.0hk > 2; // CHECK-DAG: @b_igt_false = {{.*}}global i8 0, align 1
+
+_Bool b_ige_true = 2.0hk >= 1;  // CHECK-DAG: @b_ige_true  = {{.*}}global i8 1, align 1
+_Bool b_ige_true2 = 2.0hk >= 2; // CHECK-DAG: @b_ige_true2 = {{.*}}global i8 1, align 1
+_Bool b_ige_false = 2.0hk >= 3; // CHECK-DAG: @b_ige_false = {{.*}}global i8 0, align 1
+
+// Different signage
+// Since we can have different precisions, non powers of 2 fractions may have
+// different actual values when being compared.
+_Bool b_sne_true = 2.6hk != 2.6uhk;
+// UNPADDED-DAG:   @b_sne_true = {{.*}}global i8 1, align 1
+// PADDED-DAG: @b_sne_true = {{.*}}global i8 0, align 1
+
+_Bool b_seq_true = 2.0hk == 2u;  // CHECK-DAG: @b_seq_true  = {{.*}}global i8 1, align 1
+_Bool b_seq_true2 = 2.0uhk == 2; // CHECK-DAG: @b_seq_true2 = {{.*}}global i8 1, align 1
+
+void TestComparisons() {
+  short _Accum sa;
+  _Accum a;
+  unsigned short _Accum usa;
+  unsigned _Accum ua;
+
+  // Each of these should be a fixed point conversion followed by the actual
+  // comparison operation.
+  sa == a;
+  // CHECK:  [[A:%[0-9]+]] = load i16, i16* %sa, align 2
+  // CHECK-NEXT: [[A2:%[0-9]+]] = load i32, i32* %a, align 4
+  // CHECK-NEXT: [[RESIZE_A:%[a-z0-9]+]] = sext i16 [[A]] to i32
+  // CHECK-NEXT: [[UPSCALE_A:%[a-z0-9]+]] = shl i32 [[RESIZE_A]], 8
+  // CHECK-NEXT: {{.*}} = icmp eq i32 [[UPSCALE_A]], [[A2]]
+
+  sa != a;
+  // CHECK:  [[A:%[0-9]+]] = load i16, i16* %sa, align 2
+  // CHECK-NEXT: [[A2:%[0-9]+]] = load i32, i32* %a, align 4
+  // CHECK-NEXT: [[RESIZE_A:%[a-z0-9]+]] = sext i16 [[A]] to i32
+  // CHECK-NEXT: [[UPSCALE_A:%[a-z0-9]+]] = shl i32 [[RESIZE_A]], 8
+  // CHECK-NEXT: {{.*}} = icmp ne i32 [[UPSCALE_A]], [[A2]]
+
+  sa > a;
+  // CHECK:  [[A:%[0-9]+]] = load i16, i16* %sa, align 2
+  // CHECK-NEXT: [[A2:%[0-9]+]] = load i32, i32* %a, align 4
+ 

[PATCH] D51204: [COFF, ARM64] Add MS intrinsics: __getReg, _ReadStatusReg, _WriteStatusReg

2019-02-01 Thread Mike Hommey via Phabricator via cfe-commits
glandium added a comment.

Opened D57636 


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

https://reviews.llvm.org/D51204



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


[PATCH] D57636: [COFF, ARM64] Fix types for _ReadStatusReg, _WriteStatusReg

2019-02-01 Thread Mike Hommey via Phabricator via cfe-commits
glandium created this revision.
Herald added subscribers: cfe-commits, kristof.beyls, javed.absar.
Herald added a project: clang.

r344765 added those intrinsics, but used the wrong types.

I /think/ the code in EmitAArch64BuiltinExpr does the right thing, though, but 
I'm not familiar with it.

This affects the release_80 branch.


Repository:
  rC Clang

https://reviews.llvm.org/D57636

Files:
  include/clang/Basic/BuiltinsAArch64.def
  lib/Headers/intrin.h


Index: lib/Headers/intrin.h
===
--- lib/Headers/intrin.h
+++ lib/Headers/intrin.h
@@ -564,8 +564,8 @@
 #if defined(__aarch64__)
 unsigned __int64 __getReg(int);
 long _InterlockedAdd(long volatile *Addend, long Value);
-int _ReadStatusReg(int);
-void _WriteStatusReg(int, int);
+__int64 _ReadStatusReg(int);
+void _WriteStatusReg(int, __int64);
 
 static inline unsigned short _byteswap_ushort (unsigned short val) {
   return __builtin_bswap16(val);
Index: include/clang/Basic/BuiltinsAArch64.def
===
--- include/clang/Basic/BuiltinsAArch64.def
+++ include/clang/Basic/BuiltinsAArch64.def
@@ -204,8 +204,8 @@
 
 TARGET_HEADER_BUILTIN(_ReadWriteBarrier, "v", "nh", "intrin.h", 
ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(__getReg, "ULLii", "nh", "intrin.h", ALL_MS_LANGUAGES, 
"")
-TARGET_HEADER_BUILTIN(_ReadStatusReg,  "ii",  "nh", "intrin.h", 
ALL_MS_LANGUAGES, "")
-TARGET_HEADER_BUILTIN(_WriteStatusReg, "vii", "nh", "intrin.h", 
ALL_MS_LANGUAGES, "")
+TARGET_HEADER_BUILTIN(_ReadStatusReg,  "LLii",  "nh", "intrin.h", 
ALL_MS_LANGUAGES, "")
+TARGET_HEADER_BUILTIN(_WriteStatusReg, "viLLi", "nh", "intrin.h", 
ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_AddressOfReturnAddress, "v*", "nh", "intrin.h", 
ALL_MS_LANGUAGES, "")
 
 #undef BUILTIN


Index: lib/Headers/intrin.h
===
--- lib/Headers/intrin.h
+++ lib/Headers/intrin.h
@@ -564,8 +564,8 @@
 #if defined(__aarch64__)
 unsigned __int64 __getReg(int);
 long _InterlockedAdd(long volatile *Addend, long Value);
-int _ReadStatusReg(int);
-void _WriteStatusReg(int, int);
+__int64 _ReadStatusReg(int);
+void _WriteStatusReg(int, __int64);
 
 static inline unsigned short _byteswap_ushort (unsigned short val) {
   return __builtin_bswap16(val);
Index: include/clang/Basic/BuiltinsAArch64.def
===
--- include/clang/Basic/BuiltinsAArch64.def
+++ include/clang/Basic/BuiltinsAArch64.def
@@ -204,8 +204,8 @@
 
 TARGET_HEADER_BUILTIN(_ReadWriteBarrier, "v", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(__getReg, "ULLii", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
-TARGET_HEADER_BUILTIN(_ReadStatusReg,  "ii",  "nh", "intrin.h", ALL_MS_LANGUAGES, "")
-TARGET_HEADER_BUILTIN(_WriteStatusReg, "vii", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
+TARGET_HEADER_BUILTIN(_ReadStatusReg,  "LLii",  "nh", "intrin.h", ALL_MS_LANGUAGES, "")
+TARGET_HEADER_BUILTIN(_WriteStatusReg, "viLLi", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
 TARGET_HEADER_BUILTIN(_AddressOfReturnAddress, "v*", "nh", "intrin.h", ALL_MS_LANGUAGES, "")
 
 #undef BUILTIN
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D57634: Support for GCC's `__builtin_va_arg_pack{,_len}`

2019-02-01 Thread Erik Pilkington via Phabricator via cfe-commits
erik.pilkington created this revision.
erik.pilkington added reviewers: rsmith, jfb, aaron.ballman.
Herald added subscribers: kristina, dexonsmith, jkorous.
Herald added a project: clang.

You can read more about these attributes here: 
https://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Constructing-Calls.html

These are needed to support C++-compatible `_FORTIFY_SOURCE` wrappers for libc 
function (these can't be done with macros). For instance, without these 
attributes, there isn't any way to write the following:

  extern inline __attribute__((gnu_inline))
  int sprintf(char *str, const char *fmt, ...) {
  return __builtin___sprintf_chk(str, 0, __builtin_object_size(str, 0), 
fmt, __builtin_va_arg_pack());
  }

Fixes llvm.org/PR7219 & rdar://11102669

Thanks for taking a look!
Erik


Repository:
  rC Clang

https://reviews.llvm.org/D57634

Files:
  clang/include/clang/AST/Expr.h
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/Expr.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/test/CodeGen/builtin-va-arg-pack.c
  clang/test/Sema/builtin-va-arg-pack.c

Index: clang/test/Sema/builtin-va-arg-pack.c
===
--- /dev/null
+++ clang/test/Sema/builtin-va-arg-pack.c
@@ -0,0 +1,129 @@
+// RUN: %clang_cc1 %s -verify
+// RUN: %clang_cc1 %s -fgnu89-inline -verify -DGNU89
+// RUN: %clang_cc1 -xc++ -fblocks %s -verify
+
+int printf_like(const char *, ...);
+
+extern inline __attribute__((gnu_inline))
+void correct(const char *msg, ...) {
+  printf_like(msg, __builtin_va_arg_pack());
+  __builtin_va_arg_pack_len();
+}
+
+void incorrect1(const char *msg, ...) {
+  printf_like(msg, __builtin_va_arg_pack()); // expected-error {{'__builtin_va_arg_pack' can't be used in a function that might be emitted}}
+  __builtin_va_arg_pack_len(); // expected-error {{'__builtin_va_arg_pack_len' can't be used in a function that might be emitted}}
+}
+
+extern inline
+void incorrect2(const char *msg, ...) {
+  printf_like(msg, __builtin_va_arg_pack());
+  __builtin_va_arg_pack_len();
+#ifndef GNU89
+  // expected-error@-3 {{'__builtin_va_arg_pack' can't be used in a function that might be emitted}}
+  // expected-error@-3 {{'__builtin_va_arg_pack_len' can't be used in a function that might be emitted}}
+#endif
+}
+
+static inline __attribute__((gnu_inline))
+void incorrect3(const char *msg, ...) {
+  printf_like(msg, __builtin_va_arg_pack()); // expected-error {{'__builtin_va_arg_pack' can't be used in a function that might be emitted}}
+  __builtin_va_arg_pack_len(); // expected-error {{'__builtin_va_arg_pack_len' can't be used in a function that might be emitted}}
+}
+
+extern inline __attribute__((gnu_inline))
+void bad_position(int c, ...) {
+  __builtin_va_arg_pack(); // expected-error {{'__builtin_va_arg_pack' must appear as the last argument to a variadic function}}
+}
+
+extern inline __attribute__((gnu_inline))
+void many_packs(int x, ...) {
+  // GCC accepts this, but the docs claim that its ill-formed. Whatever, it
+  // probably doesn't matter.
+  printf_like("", __builtin_va_arg_pack(), __builtin_va_arg_pack()); // expected-error {{'__builtin_va_arg_pack' must appear as the last argument to a variadic function}}
+}
+
+extern inline __attribute__((gnu_inline))
+void merge_packs(const char* x, ...) {
+  printf_like(x, 1, 2, 3, __builtin_va_arg_pack());
+}
+
+#ifdef __cplusplus
+int empty_varargs(...);
+
+extern inline __attribute__((gnu_inline))
+void call_empty(...) {
+  empty_varargs(__builtin_va_arg_pack());
+}
+
+struct S {
+  void member1(const char *, ...);
+  virtual void member2(const char *, ...);
+  static void member3(const char *, ...);
+
+  void call_em(const char *x, ...);
+};
+
+extern inline __attribute__((gnu_inline))
+void S::call_em(const char *x, ...){
+  member1(x, __builtin_va_arg_pack());
+  member2(x, __builtin_va_arg_pack());
+  member3(x, __builtin_va_arg_pack());
+}
+
+extern inline __attribute__((gnu_inline))
+void call_em(S , const char *x, ...) {
+  s.member1(x, __builtin_va_arg_pack());
+  s.member2(x, __builtin_va_arg_pack());
+  s.member3(x, __builtin_va_arg_pack());
+}
+
+template 
+extern inline __attribute__((gnu_inline))
+int call_em_dep(const char *x, ...) {
+  T s;
+  s.member1(x, __builtin_va_arg_pack());
+  s.member2(x, __builtin_va_arg_pack());
+  s.member3(x, __builtin_va_arg_pack());
+  __builtin_va_arg_pack(); // expected-error {{'__builtin_va_arg_pack' must appear as the last argument to a variadic function}}
+  return 0;
+}
+
+int p = call_em_dep("", 1, 2, 3); // expected-note {{in instantiation}}
+
+extern inline __attribute__((gnu_inline))
+void S::member1(const char *x, ...) {
+  printf_like(x, __builtin_va_arg_pack());
+}
+
+extern inline __attribute__((gnu_inline))
+void S::member2(const char *x, ...) {
+  printf_like(x, 

[PATCH] D57438: [Sema][ObjC] Allow declaring ObjC pointer members in C++ unions under ARC

2019-02-01 Thread Akira Hatanaka 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.
ahatanak marked an inline comment as done.
Closed by commit rC352949: [Sema][ObjC] Allow declaring ObjC pointer members 
with non-trivial (authored by ahatanak, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D57438?vs=184851=184879#toc

Repository:
  rC Clang

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

https://reviews.llvm.org/D57438

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/AST/DeclCXX.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaDeclCXX.cpp
  test/SemaObjCXX/arc-0x.mm
  test/SemaObjCXX/objc-weak.mm

Index: test/SemaObjCXX/arc-0x.mm
===
--- test/SemaObjCXX/arc-0x.mm
+++ test/SemaObjCXX/arc-0x.mm
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -std=c++11 -fsyntax-only -fobjc-arc -verify -fblocks -fobjc-exceptions %s
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -fobjc-arc -fobjc-runtime-has-weak -fobjc-weak -verify -fblocks -fobjc-exceptions %s
 
 // "Move" semantics, trivial version.
 void move_it(__strong id &) {
@@ -111,3 +111,160 @@
 func(^(A *a[]){}); // expected-error{{must explicitly describe intended ownership of an object array parameter}}
   }
 }
+
+namespace test_union {
+  // Implicitly-declared special functions of a union are deleted by default if
+  // ARC is enabled and the union has an ObjC pointer field.
+  union U0 {
+id f0; // expected-note 6 {{'U0' is implicitly deleted because variant field 'f0' is an ObjC pointer}}
+  };
+
+  union U1 {
+__weak id f0; // expected-note 12 {{'U1' is implicitly deleted because variant field 'f0' is an ObjC pointer}}
+U1() = default; // expected-warning {{explicitly defaulted default constructor is implicitly deleted}} expected-note {{explicitly defaulted function was implicitly deleted here}}
+~U1() = default; // expected-warning {{explicitly defaulted destructor is implicitly deleted}} expected-note {{explicitly defaulted function was implicitly deleted here}}
+U1(const U1 &) = default; // expected-warning {{explicitly defaulted copy constructor is implicitly deleted}} expected-note 2 {{explicitly defaulted function was implicitly deleted here}}
+U1(U1 &&) = default; // expected-warning {{explicitly defaulted move constructor is implicitly deleted}}
+U1 & operator=(const U1 &) = default; // expected-warning {{explicitly defaulted copy assignment operator is implicitly deleted}} expected-note 2 {{explicitly defaulted function was implicitly deleted here}}
+U1 & operator=(U1 &&) = default; // expected-warning {{explicitly defaulted move assignment operator is implicitly deleted}}
+  };
+
+  id getStrong();
+
+  // If the ObjC pointer field of a union has a default member initializer, the
+  // implicitly-declared default constructor of the union is not deleted by
+  // default.
+  union U2 {
+id f0 = getStrong(); // expected-note 4 {{'U2' is implicitly deleted because variant field 'f0' is an ObjC pointer}}
+~U2();
+  };
+
+  // It's fine if the user has explicitly defined the special functions.
+  union U3 {
+id f0;
+U3();
+~U3();
+U3(const U3 &);
+U3(U3 &&);
+U3 & operator=(const U3 &);
+U3 & operator=(U3 &&);
+  };
+
+  // ObjC pointer fields in anonymous union fields delete the defaulted special
+  // functions of the containing class.
+  struct S0 {
+union {
+  id f0; // expected-note 6 {{'' is implicitly deleted because variant field 'f0' is an ObjC pointer}}
+  char f1;
+};
+  };
+
+  struct S1 {
+union {
+  union { // expected-note 2 {{'S1' is implicitly deleted because variant field '' has a non-trivial}} expected-note 4 {{'S1' is implicitly deleted because field '' has a deleted}}
+id f0; // expected-note 2 {{'' is implicitly deleted because variant field 'f0' is an ObjC pointer}}
+char f1;
+  };
+  int f2;
+};
+  };
+
+  struct S2 {
+union {
+  // FIXME: the note should say 'f0' is causing the special functions to be deleted.
+  struct { // expected-note 6 {{'S2' is implicitly deleted because variant field '' has a non-trivial}}
+id f0;
+int f1;
+  };
+  int f2;
+};
+int f3;
+  };
+
+  U0 *x0;
+  U1 *x1;
+  U2 *x2;
+  U3 *x3;
+  S0 *x4;
+  S1 *x5;
+  S2 *x6;
+
+  static union { // expected-error {{call to implicitly-deleted default constructor of}}
+id g0; // expected-note {{default constructor of '' is implicitly deleted because variant field 'g0' is an ObjC pointer}}
+  };
+
+  static union { // expected-error {{call to implicitly-deleted default constructor of}}
+union { // expected-note {{default constructor of '' is implicitly deleted because field '' has a deleted default constructor}}
+  union { // expected-note {{default constructor of '' is implicitly deleted because field '' has a deleted 

r352949 - [Sema][ObjC] Allow declaring ObjC pointer members with non-trivial

2019-02-01 Thread Akira Hatanaka via cfe-commits
Author: ahatanak
Date: Fri Feb  1 18:23:40 2019
New Revision: 352949

URL: http://llvm.org/viewvc/llvm-project?rev=352949=rev
Log:
[Sema][ObjC] Allow declaring ObjC pointer members with non-trivial
ownership qualifications in C++ unions under ARC.

An ObjC pointer member with non-trivial ownership qualifications causes
all of the defaulted special functions of the enclosing union to be
defined as deleted, except when the member has an in-class initializer,
the default constructor isn't defined as deleted.

rdar://problem/34213306

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

Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/AST/DeclCXX.cpp
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/lib/Sema/SemaDeclCXX.cpp
cfe/trunk/test/SemaObjCXX/arc-0x.mm
cfe/trunk/test/SemaObjCXX/objc-weak.mm

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=352949=352948=352949=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Fri Feb  1 18:23:40 
2019
@@ -4649,13 +4649,15 @@ def note_deleted_special_member_class_su
   "copy assignment operator of|move assignment operator of|destructor of|"
   "constructor inherited by}0 "
   "%1 is implicitly deleted because "
-  "%select{base class %3|%select{variant }4field %3}2 has "
+  "%select{base class %3|%select{variant }4field %3}2 "
+  "%select{has "
   "%select{no|a deleted|multiple|an inaccessible|a non-trivial}4 "
   "%select{%select{default constructor|copy constructor|move constructor|copy "
   "assignment operator|move assignment operator|destructor|"
   "%select{default|corresponding|default|default|default}4 constructor}0|"
   "destructor}5"
-  "%select{||s||}4">;
+  "%select{||s||}4"
+  "|is an ObjC pointer}6">;
 def note_deleted_default_ctor_uninit_field : Note<
   "%select{default constructor of|constructor inherited by}0 "
   "%1 is implicitly deleted because field %2 of "

Modified: cfe/trunk/lib/AST/DeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/DeclCXX.cpp?rev=352949=352948=352949=diff
==
--- cfe/trunk/lib/AST/DeclCXX.cpp (original)
+++ cfe/trunk/lib/AST/DeclCXX.cpp Fri Feb  1 18:23:40 2019
@@ -991,6 +991,17 @@ void CXXRecordDecl::addedMember(Decl *D)
   setArgPassingRestrictions(RecordDecl::APK_CanNeverPassInRegs);
 
 Data.HasIrrelevantDestructor = false;
+
+if (isUnion()) {
+  data().DefaultedCopyConstructorIsDeleted = true;
+  data().DefaultedMoveConstructorIsDeleted = true;
+  data().DefaultedMoveAssignmentIsDeleted = true;
+  data().DefaultedDestructorIsDeleted = true;
+  data().NeedOverloadResolutionForCopyConstructor = true;
+  data().NeedOverloadResolutionForMoveConstructor = true;
+  data().NeedOverloadResolutionForMoveAssignment = true;
+  data().NeedOverloadResolutionForDestructor = true;
+}
   } else if (!Context.getLangOpts().ObjCAutoRefCount) {
 setHasObjectMember(true);
   }

Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=352949=352948=352949=diff
==
--- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDecl.cpp Fri Feb  1 18:23:40 2019
@@ -15923,7 +15923,8 @@ void Sema::ActOnFields(Scope *S, SourceL
   QualType T = Context.getObjCObjectPointerType(FD->getType());
   FD->setType(T);
 } else if (getLangOpts().allowsNonTrivialObjCLifetimeQualifiers() &&
-   Record && !ObjCFieldLifetimeErrReported && Record->isUnion()) {
+   Record && !ObjCFieldLifetimeErrReported && Record->isUnion() &&
+   !getLangOpts().CPlusPlus) {
   // It's an error in ARC or Weak if a field has lifetime.
   // We don't want to report this in a system header, though,
   // so we just make the field unavailable.

Modified: cfe/trunk/lib/Sema/SemaDeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclCXX.cpp?rev=352949=352948=352949=diff
==
--- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Fri Feb  1 18:23:40 2019
@@ -6891,6 +6891,8 @@ struct SpecialMemberDeletionInfo
 return ICI ? Sema::CXXInvalid : CSM;
   }
 
+  bool shouldDeleteForVariantObjCPtrMember(FieldDecl *FD, QualType FieldType);
+
   bool visitBase(CXXBaseSpecifier *Base) { return shouldDeleteForBase(Base); }
   bool visitField(FieldDecl *Field) { return shouldDeleteForField(Field); }
 
@@ -6962,13 +6964,14 @@ bool 

r352948 - [ASan] Do not instrument other runtime functions with `__asan_handle_no_return`

2019-02-01 Thread Julian Lettner via cfe-commits
Author: yln
Date: Fri Feb  1 18:05:16 2019
New Revision: 352948

URL: http://llvm.org/viewvc/llvm-project?rev=352948=rev
Log:
[ASan] Do not instrument other runtime functions with `__asan_handle_no_return`

Summary:
Currently, ASan inserts a call to `__asan_handle_no_return` before every
`noreturn` function call/invoke. This is unnecessary for calls to other
runtime funtions. This patch changes ASan to skip instrumentation for
functions calls marked with `!nosanitize` metadata.

Reviewers: TODO

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

Modified:
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/test/CodeGen/ubsan-asan-noreturn.c

Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=352948=352947=352948=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Fri Feb  1 18:05:16 2019
@@ -4394,8 +4394,8 @@ RValue CodeGenFunction::EmitCall(const C
 
 // Strip away the noreturn attribute to better diagnose unreachable UB.
 if (SanOpts.has(SanitizerKind::Unreachable)) {
-  // Also remove from function since CI->hasFnAttr(..) also checks 
attributes
-  // of the called function.
+  // Also remove from function since CallBase::hasFnAttr additionally 
checks
+  // attributes of the called function.
   if (auto *F = CI->getCalledFunction())
 F->removeFnAttr(llvm::Attribute::NoReturn);
   CI->removeAttribute(llvm::AttributeList::FunctionIndex,

Modified: cfe/trunk/test/CodeGen/ubsan-asan-noreturn.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/ubsan-asan-noreturn.c?rev=352948=352947=352948=diff
==
--- cfe/trunk/test/CodeGen/ubsan-asan-noreturn.c (original)
+++ cfe/trunk/test/CodeGen/ubsan-asan-noreturn.c Fri Feb  1 18:05:16 2019
@@ -9,8 +9,7 @@ void calls_noreturn() {
   my_longjmp();
   // CHECK:  @__asan_handle_no_return{{.*}} !nosanitize
   // CHECK-NEXT: @my_longjmp(){{[^#]*}}
-  // CHECK:  @__asan_handle_no_return()
-  // CHECK-NEXT: @__ubsan_handle_builtin_unreachable{{.*}} !nosanitize
+  // CHECK:  @__ubsan_handle_builtin_unreachable{{.*}} !nosanitize
   // CHECK-NEXT: unreachable
 }
 


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


[PATCH] D57489: [ASan] Do not instrument other runtime functions with `__asan_handle_no_return`

2019-02-01 Thread Julian Lettner via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rC352948: [ASan] Do not instrument other runtime functions 
with `__asan_handle_no_return` (authored by yln, committed by ).
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D57489?vs=184648=184878#toc

Repository:
  rC Clang

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

https://reviews.llvm.org/D57489

Files:
  lib/CodeGen/CGCall.cpp
  test/CodeGen/ubsan-asan-noreturn.c


Index: test/CodeGen/ubsan-asan-noreturn.c
===
--- test/CodeGen/ubsan-asan-noreturn.c
+++ test/CodeGen/ubsan-asan-noreturn.c
@@ -9,8 +9,7 @@
   my_longjmp();
   // CHECK:  @__asan_handle_no_return{{.*}} !nosanitize
   // CHECK-NEXT: @my_longjmp(){{[^#]*}}
-  // CHECK:  @__asan_handle_no_return()
-  // CHECK-NEXT: @__ubsan_handle_builtin_unreachable{{.*}} !nosanitize
+  // CHECK:  @__ubsan_handle_builtin_unreachable{{.*}} !nosanitize
   // CHECK-NEXT: unreachable
 }
 
Index: lib/CodeGen/CGCall.cpp
===
--- lib/CodeGen/CGCall.cpp
+++ lib/CodeGen/CGCall.cpp
@@ -4394,8 +4394,8 @@
 
 // Strip away the noreturn attribute to better diagnose unreachable UB.
 if (SanOpts.has(SanitizerKind::Unreachable)) {
-  // Also remove from function since CI->hasFnAttr(..) also checks 
attributes
-  // of the called function.
+  // Also remove from function since CallBase::hasFnAttr additionally 
checks
+  // attributes of the called function.
   if (auto *F = CI->getCalledFunction())
 F->removeFnAttr(llvm::Attribute::NoReturn);
   CI->removeAttribute(llvm::AttributeList::FunctionIndex,


Index: test/CodeGen/ubsan-asan-noreturn.c
===
--- test/CodeGen/ubsan-asan-noreturn.c
+++ test/CodeGen/ubsan-asan-noreturn.c
@@ -9,8 +9,7 @@
   my_longjmp();
   // CHECK:  @__asan_handle_no_return{{.*}} !nosanitize
   // CHECK-NEXT: @my_longjmp(){{[^#]*}}
-  // CHECK:  @__asan_handle_no_return()
-  // CHECK-NEXT: @__ubsan_handle_builtin_unreachable{{.*}} !nosanitize
+  // CHECK:  @__ubsan_handle_builtin_unreachable{{.*}} !nosanitize
   // CHECK-NEXT: unreachable
 }
 
Index: lib/CodeGen/CGCall.cpp
===
--- lib/CodeGen/CGCall.cpp
+++ lib/CodeGen/CGCall.cpp
@@ -4394,8 +4394,8 @@
 
 // Strip away the noreturn attribute to better diagnose unreachable UB.
 if (SanOpts.has(SanitizerKind::Unreachable)) {
-  // Also remove from function since CI->hasFnAttr(..) also checks attributes
-  // of the called function.
+  // Also remove from function since CallBase::hasFnAttr additionally checks
+  // attributes of the called function.
   if (auto *F = CI->getCalledFunction())
 F->removeFnAttr(llvm::Attribute::NoReturn);
   CI->removeAttribute(llvm::AttributeList::FunctionIndex,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r352946 - Remove redundant FunctionDecl argument from a couple functions.

2019-02-01 Thread James Y Knight via cfe-commits
Author: jyknight
Date: Fri Feb  1 17:48:23 2019
New Revision: 352946

URL: http://llvm.org/viewvc/llvm-project?rev=352946=rev
Log:
Remove redundant FunctionDecl argument from a couple functions.

This argument was added in r254554 in order to support the
pass_object_size attribute. However, in r296076, the attribute's
presence is now also represented in FunctionProtoType's
ExtParameterInfo, and thus it's unnecessary to pass along a separate
FunctionDecl.

The functions modified are:
 RequiredArgs::forPrototype{,Plus}, and
 CodeGenTypes::ConvertFunctionType.

After this, it's also (again) unnecessary to have a separate
ConvertFunctionType function ConvertType, so convert callers back to
the latter, leaving the former as an internal helper function.

Modified:
cfe/trunk/include/clang/CodeGen/CGFunctionInfo.h
cfe/trunk/include/clang/CodeGen/CodeGenABITypes.h
cfe/trunk/lib/CodeGen/CGCUDANV.cpp
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/lib/CodeGen/CGExprCXX.cpp
cfe/trunk/lib/CodeGen/CGVTables.cpp
cfe/trunk/lib/CodeGen/CodeGenABITypes.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/lib/CodeGen/CodeGenTypes.cpp
cfe/trunk/lib/CodeGen/CodeGenTypes.h

Modified: cfe/trunk/include/clang/CodeGen/CGFunctionInfo.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/CodeGen/CGFunctionInfo.h?rev=352946=352945=352946=diff
==
--- cfe/trunk/include/clang/CodeGen/CGFunctionInfo.h (original)
+++ cfe/trunk/include/clang/CodeGen/CGFunctionInfo.h Fri Feb  1 17:48:23 2019
@@ -440,31 +440,30 @@ public:
   ///
   /// If FD is not null, this will consider pass_object_size params in FD.
   static RequiredArgs forPrototypePlus(const FunctionProtoType *prototype,
-   unsigned additional,
-   const FunctionDecl *FD) {
+   unsigned additional) {
 if (!prototype->isVariadic()) return All;
-if (FD)
-  additional +=
-  llvm::count_if(FD->parameters(), [](const ParmVarDecl *PVD) {
-return PVD->hasAttr();
+
+if (prototype->hasExtParameterInfos())
+  additional += llvm::count_if(
+  prototype->getExtParameterInfos(),
+  [](const FunctionProtoType::ExtParameterInfo ) {
+return ExtInfo.hasPassObjectSize();
   });
+
 return RequiredArgs(prototype->getNumParams() + additional);
   }
 
-  static RequiredArgs forPrototype(const FunctionProtoType *prototype,
-   const FunctionDecl *FD) {
-return forPrototypePlus(prototype, 0, FD);
+  static RequiredArgs forPrototypePlus(CanQual prototype,
+   unsigned additional) {
+return forPrototypePlus(prototype.getTypePtr(), additional);
   }
 
-  static RequiredArgs forPrototype(CanQual prototype,
-   const FunctionDecl *FD) {
-return forPrototype(prototype.getTypePtr(), FD);
+  static RequiredArgs forPrototype(const FunctionProtoType *prototype) {
+return forPrototypePlus(prototype, 0);
   }
 
-  static RequiredArgs forPrototypePlus(CanQual prototype,
-   unsigned additional,
-   const FunctionDecl *FD) {
-return forPrototypePlus(prototype.getTypePtr(), additional, FD);
+  static RequiredArgs forPrototype(CanQual prototype) {
+return forPrototypePlus(prototype.getTypePtr(), 0);
   }
 
   bool allowsOptionalArgs() const { return NumRequired != ~0U; }

Modified: cfe/trunk/include/clang/CodeGen/CodeGenABITypes.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/CodeGen/CodeGenABITypes.h?rev=352946=352945=352946=diff
==
--- cfe/trunk/include/clang/CodeGen/CodeGenABITypes.h (original)
+++ cfe/trunk/include/clang/CodeGen/CodeGenABITypes.h Fri Feb  1 17:48:23 2019
@@ -54,8 +54,7 @@ const CGFunctionInfo 
   QualType receiverType);
 
 const CGFunctionInfo (CodeGenModule ,
-  CanQual Ty,
-  const FunctionDecl *FD);
+  CanQual Ty);
 
 const CGFunctionInfo (CodeGenModule ,
   CanQual Ty);

Modified: cfe/trunk/lib/CodeGen/CGCUDANV.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCUDANV.cpp?rev=352946=352945=352946=diff
==
--- cfe/trunk/lib/CodeGen/CGCUDANV.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCUDANV.cpp Fri Feb  1 17:48:23 2019
@@ -278,7 +278,7 @@ void CGNVCUDARuntime::emitDeviceStubBody
 
   QualType QT = cudaLaunchKernelFD->getType();
   QualType CQT = QT.getCanonicalType();
-  llvm::Type *Ty = 

Re: r352930 - [WebAssembly] Add an import_field function attribute

2019-02-01 Thread Dan Gohman via cfe-commits
On Fri, Feb 1, 2019 at 2:31 PM Aaron Ballman  wrote:

> On Fri, Feb 1, 2019 at 5:25 PM Dan Gohman via cfe-commits
>  wrote:
> >
> > Author: djg
> > Date: Fri Feb  1 14:25:23 2019
> > New Revision: 352930
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=352930=rev
> > Log:
> > [WebAssembly] Add an import_field function attribute
> >
> > This is similar to import_module, but sets the import field name
> > instead.
> >
> > By default, the import field name is the same as the C/asm/.o symbol
> > name. However, there are situations where it's useful to have it be
> > different. For example, suppose I have a wasm API with a module named
> > "pwsix" and a field named "read". There's no risk of namespace
> > collisions with user code at the wasm level because the generic name
> > "read" is qualified by the module name "pwsix". However in the C/asm/.o
> > namespaces, the module name is not used, so if I have a global function
> > named "read", it is intruding on the user's namespace.
> >
> > With the import_field module, I can declare my function (in libc) to be
> > "__read", and then set the wasm import module to be "pwsix" and the wasm
> > import field to be "read". So at the C/asm/.o levels, my symbol is
> > outside the user namespace.
> >
> > Differential Revision: https://reviews.llvm.org/D57602
>
> Btw, this review never went to cfe-commits, but it should have. :-)
>

Yes, my mistake.


>
> > Added:
> > cfe/trunk/test/CodeGen/wasm-import-name.c
> >   - copied, changed from r352781,
> cfe/trunk/test/CodeGen/wasm-import-module.c
> > Modified:
> > cfe/trunk/include/clang/Basic/Attr.td
> > cfe/trunk/include/clang/Basic/AttrDocs.td
> > cfe/trunk/lib/CodeGen/TargetInfo.cpp
> > cfe/trunk/lib/Sema/SemaDeclAttr.cpp
> > cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test
> >
> > Modified: cfe/trunk/include/clang/Basic/Attr.td
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=352930=352929=352930=diff
> >
> ==
> > --- cfe/trunk/include/clang/Basic/Attr.td (original)
> > +++ cfe/trunk/include/clang/Basic/Attr.td Fri Feb  1 14:25:23 2019
> > @@ -1514,11 +1514,19 @@ def AMDGPUNumVGPR : InheritableAttr {
> >  def WebAssemblyImportModule : InheritableAttr,
> >TargetSpecificAttr {
> >let Spellings = [Clang<"import_module">];
> > -  let Args = [StringArgument<"ImportModuleName">];
> > +  let Args = [StringArgument<"ImportModule">];
> >let Documentation = [WebAssemblyImportModuleDocs];
> >let Subjects = SubjectList<[Function], ErrorDiag>;
> >  }
> >
> > +def WebAssemblyImportName : InheritableAttr,
> > +TargetSpecificAttr {
> > +  let Spellings = [Clang<"import_name">];
> > +  let Args = [StringArgument<"ImportName">];
> > +  let Documentation = [WebAssemblyImportNameDocs];
> > +  let Subjects = SubjectList<[Function], ErrorDiag>;
> > +}
> > +
> >  def NoSplitStack : InheritableAttr {
> >let Spellings = [GCC<"no_split_stack">];
> >let Subjects = SubjectList<[Function], ErrorDiag>;
> >
> > Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttrDocs.td?rev=352930=352929=352930=diff
> >
> ==
> > --- cfe/trunk/include/clang/Basic/AttrDocs.td (original)
> > +++ cfe/trunk/include/clang/Basic/AttrDocs.td Fri Feb  1 14:25:23 2019
> > @@ -3730,6 +3730,23 @@ reuqest a specific module name be used i
> >}];
> >  }
> >
> > +def WebAssemblyImportNameDocs : Documentation {
> > +  let Category = DocCatFunction;
> > +  let Content = [{
> > +Clang supports the ``__attribute__((import_name()))``
> > +attribute for the WebAssembly target. This attribute may be attached to
> a
> > +function declaration, where it modifies how the symbol is to be imported
> > +within the WebAssembly linking environment.
> > +
> > +WebAssembly imports use a two-level namespace scheme, consisting of a
> module
> > +name, which typically identifies a module from which to import, and a
> field
> > +name, which typically identifies a field from that module to import. By
> > +default, field names for C/C++ symbols are the same as their C/C++
> symbol
> > +names. This attribute can be used to override the default behavior, and
> > +reuqest a specific field name be used instead.
> > +  }];
> > +}
> > +
> >  def ArtificialDocs : Documentation {
> >let Category = DocCatFunction;
> >let Content = [{
> >
> > Modified: cfe/trunk/lib/CodeGen/TargetInfo.cpp
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp?rev=352930=352929=352930=diff
> >
> ==
> > --- cfe/trunk/lib/CodeGen/TargetInfo.cpp (original)
> > +++ cfe/trunk/lib/CodeGen/TargetInfo.cpp Fri Feb  1 14:25:23 2019
> > 

[PATCH] D57631: [COFF, ARM64] Add ARM64 support for MS intrinsic _fastfail

2019-02-01 Thread Eli Friedman via Phabricator via cfe-commits
efriedma accepted this revision.
efriedma added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rC Clang

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

https://reviews.llvm.org/D57631



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


[PATCH] D57631: [COFF, ARM64] Add ARM64 support for MS intrinsic _fastfail

2019-02-01 Thread Tom Tan via Phabricator via cfe-commits
TomTan created this revision.
TomTan added reviewers: rnk, mstorsjo, efriedma.
Herald added subscribers: cfe-commits, kristof.beyls.
Herald added a project: clang.

The MSDN document was also updated to reflect this, but it probably will take a 
few days to show in below link.

https://docs.microsoft.com/en-us/cpp/intrinsics/fastfail


Repository:
  rC Clang

https://reviews.llvm.org/D57631

Files:
  lib/CodeGen/CGBuiltin.cpp
  test/CodeGen/ms-intrinsics.c


Index: test/CodeGen/ms-intrinsics.c
===
--- test/CodeGen/ms-intrinsics.c
+++ test/CodeGen/ms-intrinsics.c
@@ -9,7 +9,7 @@
 // RUN: | FileCheck %s --check-prefixes 
CHECK,CHECK-X64,CHECK-ARM-X64,CHECK-INTEL
 // RUN: %clang_cc1 -ffreestanding -fms-extensions -fms-compatibility 
-fms-compatibility-version=17.00 \
 // RUN: -triple aarch64-windows -Oz -emit-llvm %s -o - \
-// RUN: | FileCheck %s --check-prefixes CHECK-ARM-ARM64,CHECK-ARM-X64
+// RUN: | FileCheck %s --check-prefixes 
CHECK-ARM-ARM64,CHECK-ARM-X64,CHECK-ARM64
 
 // intrin.h needs size_t, but -ffreestanding prevents us from getting it from
 // stddef.h.  Work around it with this typedef.
@@ -1342,15 +1342,14 @@
 // CHECK-ARM-ARM64: }
 #endif
 
-#if !defined(__aarch64__)
 void test__fastfail() {
   __fastfail(42);
 }
 // CHECK-LABEL: define{{.*}} void @test__fastfail()
 // CHECK-ARM: call void asm sideeffect "udf #251", "{r0}"(i32 42) 
#[[NORETURN:[0-9]+]]
 // CHECK-INTEL: call void asm sideeffect "int $$0x29", "{cx}"(i32 42) 
#[[NORETURN]]
+// CHECK-ARM64: call void asm sideeffect "brk #0xF003", "{w0}"(i32 42) 
#[[NORETURN:[0-9]+]]
 
 // Attributes come last.
 
 // CHECK: attributes #[[NORETURN]] = { noreturn{{.*}} }
-#endif
Index: lib/CodeGen/CGBuiltin.cpp
===
--- lib/CodeGen/CGBuiltin.cpp
+++ lib/CodeGen/CGBuiltin.cpp
@@ -995,6 +995,9 @@
   Asm = "udf #251";
   Constraints = "{r0}";
   break;
+case llvm::Triple::aarch64:
+  Asm = "brk #0xF003";
+  Constraints = "{w0}";
 }
 llvm::FunctionType *FTy = llvm::FunctionType::get(VoidTy, {Int32Ty}, 
false);
 llvm::InlineAsm *IA =


Index: test/CodeGen/ms-intrinsics.c
===
--- test/CodeGen/ms-intrinsics.c
+++ test/CodeGen/ms-intrinsics.c
@@ -9,7 +9,7 @@
 // RUN: | FileCheck %s --check-prefixes CHECK,CHECK-X64,CHECK-ARM-X64,CHECK-INTEL
 // RUN: %clang_cc1 -ffreestanding -fms-extensions -fms-compatibility -fms-compatibility-version=17.00 \
 // RUN: -triple aarch64-windows -Oz -emit-llvm %s -o - \
-// RUN: | FileCheck %s --check-prefixes CHECK-ARM-ARM64,CHECK-ARM-X64
+// RUN: | FileCheck %s --check-prefixes CHECK-ARM-ARM64,CHECK-ARM-X64,CHECK-ARM64
 
 // intrin.h needs size_t, but -ffreestanding prevents us from getting it from
 // stddef.h.  Work around it with this typedef.
@@ -1342,15 +1342,14 @@
 // CHECK-ARM-ARM64: }
 #endif
 
-#if !defined(__aarch64__)
 void test__fastfail() {
   __fastfail(42);
 }
 // CHECK-LABEL: define{{.*}} void @test__fastfail()
 // CHECK-ARM: call void asm sideeffect "udf #251", "{r0}"(i32 42) #[[NORETURN:[0-9]+]]
 // CHECK-INTEL: call void asm sideeffect "int $$0x29", "{cx}"(i32 42) #[[NORETURN]]
+// CHECK-ARM64: call void asm sideeffect "brk #0xF003", "{w0}"(i32 42) #[[NORETURN:[0-9]+]]
 
 // Attributes come last.
 
 // CHECK: attributes #[[NORETURN]] = { noreturn{{.*}} }
-#endif
Index: lib/CodeGen/CGBuiltin.cpp
===
--- lib/CodeGen/CGBuiltin.cpp
+++ lib/CodeGen/CGBuiltin.cpp
@@ -995,6 +995,9 @@
   Asm = "udf #251";
   Constraints = "{r0}";
   break;
+case llvm::Triple::aarch64:
+  Asm = "brk #0xF003";
+  Constraints = "{w0}";
 }
 llvm::FunctionType *FTy = llvm::FunctionType::get(VoidTy, {Int32Ty}, false);
 llvm::InlineAsm *IA =
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D56571: [RFC prototype] Implementation of asm-goto support in clang

2019-02-01 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added a comment.

Forgot about protected scopes...

This patch is missing code and testcases for JumpScopeChecker.  (The behavior 
should be roughly equivalent to what we do for indirect goto.)


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

https://reviews.llvm.org/D56571



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


[PATCH] D56561: [Preprocessor] For missing file in framework add note about framework location.

2019-02-01 Thread Volodymyr Sapsai via Phabricator via cfe-commits
vsapsai updated this revision to Diff 184866.
vsapsai added a comment.

- Improve the diagnostic message wording.

Rebased the patch, so the diff between 2 revisions can be noisy.


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

https://reviews.llvm.org/D56561

Files:
  clang/include/clang/Basic/DiagnosticLexKinds.td
  clang/include/clang/Lex/DirectoryLookup.h
  clang/include/clang/Lex/HeaderSearch.h
  clang/include/clang/Lex/Preprocessor.h
  clang/lib/Frontend/FrontendActions.cpp
  clang/lib/Frontend/Rewrite/InclusionRewriter.cpp
  clang/lib/Frontend/VerifyDiagnosticConsumer.cpp
  clang/lib/Lex/HeaderSearch.cpp
  clang/lib/Lex/PPDirectives.cpp
  clang/lib/Lex/PPMacroExpansion.cpp
  clang/lib/Lex/Pragma.cpp
  clang/lib/Lex/Preprocessor.cpp
  clang/test/Preprocessor/include-header-missing-in-framework.c

Index: clang/test/Preprocessor/include-header-missing-in-framework.c
===
--- /dev/null
+++ clang/test/Preprocessor/include-header-missing-in-framework.c
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -fsyntax-only -F %S/Inputs -verify %s
+// RUN: %clang_cc1 -fsyntax-only -F %S/Inputs -DTYPO_CORRECTION -verify %s
+
+// After finding a requested framework, we don't look for the same framework in
+// a different location even if requested header is not found in the framework.
+// It can be confusing when there is a framework with required header later in
+// header search paths. Mention in diagnostics where the header lookup stopped.
+
+#ifndef TYPO_CORRECTION
+#include 
+// expected-error@-1 {{'TestFramework/NotExistingHeader.h' file not found}}
+// expected-note@-2 {{did not find header 'NotExistingHeader.h' in framework 'TestFramework' (loaded from}}
+
+#else
+// Don't emit extra note for unsuccessfully typo-corrected include.
+#include <#TestFramework/NotExistingHeader.h>
+// expected-error@-1 {{'#TestFramework/NotExistingHeader.h' file not found}}
+#endif // TYPO_CORRECTION
Index: clang/lib/Lex/Preprocessor.cpp
===
--- clang/lib/Lex/Preprocessor.cpp
+++ clang/lib/Lex/Preprocessor.cpp
@@ -566,7 +566,8 @@
 SourceLocation(), PPOpts->PCHThroughHeader,
 /*isAngled=*/false, /*FromDir=*/nullptr, /*FromFile=*/nullptr, CurDir,
 /*SearchPath=*/nullptr, /*RelativePath=*/nullptr,
-/*SuggestedModule=*/nullptr, /*IsMapped=*/nullptr);
+/*SuggestedModule=*/nullptr, /*IsMapped=*/nullptr,
+/*IsFrameworkFound=*/nullptr);
 if (!File) {
   Diag(SourceLocation(), diag::err_pp_through_header_not_found)
   << PPOpts->PCHThroughHeader;
Index: clang/lib/Lex/Pragma.cpp
===
--- clang/lib/Lex/Pragma.cpp
+++ clang/lib/Lex/Pragma.cpp
@@ -506,7 +506,7 @@
   const DirectoryLookup *CurDir;
   const FileEntry *File =
   LookupFile(FilenameTok.getLocation(), Filename, isAngled, nullptr,
- nullptr, CurDir, nullptr, nullptr, nullptr, nullptr);
+ nullptr, CurDir, nullptr, nullptr, nullptr, nullptr, nullptr);
   if (!File) {
 if (!SuppressIncludeNotFoundError)
   Diag(FilenameTok, diag::err_pp_file_not_found) << Filename;
Index: clang/lib/Lex/PPMacroExpansion.cpp
===
--- clang/lib/Lex/PPMacroExpansion.cpp
+++ clang/lib/Lex/PPMacroExpansion.cpp
@@ -1235,7 +1235,7 @@
   const DirectoryLookup *CurDir;
   const FileEntry *File =
   PP.LookupFile(FilenameLoc, Filename, isAngled, LookupFrom, LookupFromFile,
-CurDir, nullptr, nullptr, nullptr, nullptr);
+CurDir, nullptr, nullptr, nullptr, nullptr, nullptr);
 
   if (PPCallbacks *Callbacks = PP.getPPCallbacks()) {
 SrcMgr::CharacteristicKind FileType = SrcMgr::C_User;
Index: clang/lib/Lex/PPDirectives.cpp
===
--- clang/lib/Lex/PPDirectives.cpp
+++ clang/lib/Lex/PPDirectives.cpp
@@ -665,7 +665,8 @@
 const DirectoryLookup *FromDir, const FileEntry *FromFile,
 const DirectoryLookup *, SmallVectorImpl *SearchPath,
 SmallVectorImpl *RelativePath,
-ModuleMap::KnownHeader *SuggestedModule, bool *IsMapped, bool SkipCache) {
+ModuleMap::KnownHeader *SuggestedModule, bool *IsMapped,
+bool *IsFrameworkFound, bool SkipCache) {
   Module *RequestingModule = getModuleForLocation(FilenameLoc);
   bool RequestingModuleIsModuleInterface = !SourceMgr.isInMainFile(FilenameLoc);
 
@@ -723,7 +724,8 @@
 while (const FileEntry *FE = HeaderInfo.LookupFile(
Filename, FilenameLoc, isAngled, TmpFromDir, TmpCurDir,
Includers, SearchPath, RelativePath, RequestingModule,
-   SuggestedModule, /*IsMapped=*/nullptr, SkipCache)) {
+   SuggestedModule, /*IsMapped=*/nullptr,
+   /*IsFrameworkFound=*/nullptr, SkipCache)) {
   // Keep looking as if this file did a 

[PATCH] D56571: [RFC prototype] Implementation of asm-goto support in clang

2019-02-01 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added inline comments.



Comment at: lib/Analysis/CFG.cpp:3137
+
+  Block = createBlock(false);
+  Block->setTerminator(G);

Passing add_successor=false seems suspect; this could probably use more test 
coverage.



Comment at: lib/CodeGen/CGStmt.cpp:2182
+}
+  }
+

jyu2 wrote:
> nickdesaulniers wrote:
> > If this new block was moved closer to the new one on L2227, I assume they 
> > could be combined and possibly `IsGCCAsmGoto` be removed?  The code 
> > currently in between doesn't appear at first site to depend on info from 
> > this block, though maybe I may be missing it.
> The labels need be processed before Clobbers
Before the clobbers?  I don't see the relationship; the clobbers are just a 
string.

Granted, it does need to be before we compute the type, which is shared code.



Comment at: lib/CodeGen/CGStmt.cpp:1884
+template 
+void CodeGenFunction::UpdateCallInst(
+T , bool HasSideEffect, bool ReadOnly, bool ReadNone,

rsmith wrote:
> This is not a reasonable function name for a function that is specific to 
> `AsmStmt`s. Please also make this a (static) non-member function, since it 
> cannot be called outside this source file.
Does this really need to be a template function?  I think all the functions 
you're calling on "Result" are members of CallBase.



Comment at: lib/CodeGen/CGStmt.cpp:2188
+ std::to_string(NumGccAsmGotoStmts));
+  NumGccAsmGotoStmts++;
+}

The NumGccAsmGotoStmts variable is pointless; if names are enabled, 
createBasicBlock will automatically number all the blocks named "normal".



Comment at: test/Parser/asm-goto.c:1
+// RUN: %clang_cc1 %s
+

What is this testing?


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

https://reviews.llvm.org/D56571



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


[PATCH] D57626: Disallow trivial_abi on a class if all copy and move constructors are deleted

2019-02-01 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: lib/Sema/SemaDeclCXX.cpp:7886
+  if (!HasNonDeletedCopyOrMoveConstructor()) {
+PrintDiagAndRemoveAttr();
+return;

This is not a very useful diagnostic.  We have several different reasons why we 
reject the attribute, some of which are pretty subtle, and it's not reasonable 
to expect users to puzzle it out.  At the very least we can tell them the 
immediate cause for all of these rejections.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57626



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


[PATCH] D57438: [Sema][ObjC] Allow declaring ObjC pointer members in C++ unions under ARC

2019-02-01 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

Asking for a minor tweak, but feel free to commit with that.




Comment at: lib/Sema/SemaDeclCXX.cpp:7084
 
+  if (FD->getParent()->isUnion() &&
+  shouldDeleteForVariantObjCPtrMember(FD, FieldType))

ahatanak wrote:
> rjmccall wrote:
> > rjmccall wrote:
> > > I believe the right check for variant-ness is `inUnion()`, not 
> > > `FD->getParent()->isUnion()`, since the latter can miss cases with e.g. 
> > > anonymous `struct`s.
> > Can you try adding a test case here for an anonymous struct nested within 
> > an anonymous union?
> Added a test case for an anonymous struct nested within an anonymous union 
> (`struct S2` in arc-0x.mm).
> 
> I found out that the diagnostic messages clang prints for arc-0x.mm are the 
> same whether `inUnion()` or `FD->getParent()->isUnion()` is called. This is 
> what I discovered:
> 
> `SpecialMemberDeletionInfo` is used in two cases:
> 
> 1. To find the deletedness of the special functions in the AST after a class 
> is parsed.
> 
> 2. When a deleted special function is used, provide more details on why the 
> function is deleted and print note diagnostics.
> 
> Since the nested classes are parsed before the enclosing classes, we have all 
> the information we need about the members that are directly contained to 
> correctly infer the deletedness of a class' special functions. So the first 
> case should work fine regardless of which method is called.
> 
> It doesn't make a difference for the second case either because 
> `SpecialMemberDeletionInfo` doesn't try to find out which member of an 
> anonymous struct is causing the special function to be deleted; it only does 
> so for anonymous unions (which happens inside the if statement near comment 
> "// Some additional restrictions exist on the variant members." at line 7140).
Alright.  Another place where we could generally improve diagnostics, then.



Comment at: test/SemaObjCXX/arc-0x.mm:174
+union {
+  struct { // expected-note 6 {{'S2' is implicitly deleted because variant 
field '' has a non-trivial}}
+id f0;

Worth adding a FIXME saying that this note should go on `f1`?


Repository:
  rC Clang

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

https://reviews.llvm.org/D57438



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


[PATCH] D57628: [index] Improve indexing support for MSPropertyDecl.

2019-02-01 Thread Volodymyr Sapsai via Phabricator via cfe-commits
vsapsai created this revision.
vsapsai added reviewers: akyrtzi, benlangmuir.
Herald added subscribers: arphaman, dexonsmith, jkorous.

Currently the symbol for MSPropertyDecl has kind `SymbolKind::Unknown`
which can trip up various indexing tools.

rdar://problem/46764224


https://reviews.llvm.org/D57628

Files:
  clang/lib/Index/IndexDecl.cpp
  clang/lib/Index/IndexSymbol.cpp
  clang/test/Index/ms-property.cpp


Index: clang/test/Index/ms-property.cpp
===
--- /dev/null
+++ clang/test/Index/ms-property.cpp
@@ -0,0 +1,32 @@
+// RUN: c-index-test core -print-source-symbols -- -fms-extensions 
-fno-ms-compatibility %s | FileCheck %s
+
+// CHECK: [[@LINE+1]]:8 | struct/C++ | Simple | [[Simple_USR:.*]] | 
 | Def | rel: 0
+struct Simple {
+  int GetX() const;
+  // CHECK: [[@LINE-1]]:7 | instance-method/C++ | GetX | [[GetX_USR:.*]] | 
__ZNK6Simple4GetXEv | Decl,RelChild | rel: 1
+  // CHECK-NEXT: RelChild | Simple | [[Simple_USR]]
+
+  void PutX(int i);
+  // CHECK: [[@LINE-1]]:8 | instance-method/C++ | PutX | [[PutX_USR:.*]] | 
__ZN6Simple4PutXEi | Decl,RelChild | rel: 1
+  // CHECK-NEXT: RelChild | Simple | [[Simple_USR]]
+
+  __declspec(property(get=GetX, put=PutX)) int propX;
+  // CHECK: [[@LINE-1]]:48 | instance-property/C++ | propX | [[propX_USR:.*]] 
|  | Def,RelChild | rel: 1
+  // CHECK-NEXT: RelChild | Simple | [[Simple_USR]]
+};
+
+// CHECK: [[@LINE+1]]:5 | function/C | test | [[test_USR:.*]] | __Z4testv | 
Def | rel: 0
+int test() {
+  Simple s;
+  s.propX = 5;
+  // CHECK: [[@LINE-1]]:5 | instance-property/C++ | propX | [[propX_USR]] | 
 | Ref,RelCont | rel: 1
+  // CHECK-NEXT: RelCont | test | [[test_USR]]
+  // CHECK: [[@LINE-3]]:5 | instance-method/C++ | PutX | [[PutX_USR]] | 
__ZN6Simple4PutXEi | Ref,Call,RelCall,RelCont | rel: 1
+  // CHECK-NEXT: RelCall,RelCont | test | [[test_USR]]
+
+  return s.propX;
+  // CHECK: [[@LINE-1]]:12 | instance-property/C++ | propX | [[propX_USR]] | 
 | Ref,RelCont | rel: 1
+  // CHECK-NEXT: RelCont | test | [[test_USR]]
+  // CHECK: [[@LINE-3]]:12 | instance-method/C++ | GetX | [[GetX_USR]] | 
__ZNK6Simple4GetXEv | Ref,Call,RelCall,RelCont | rel: 1
+  // CHECK-NEXT: RelCall,RelCont | test | [[test_USR]]
+}
Index: clang/lib/Index/IndexSymbol.cpp
===
--- clang/lib/Index/IndexSymbol.cpp
+++ clang/lib/Index/IndexSymbol.cpp
@@ -323,6 +323,14 @@
   Info.Kind = SymbolKind::Variable;
   Info.Lang = SymbolLanguage::CXX;
   break;
+case Decl::MSProperty:
+  Info.Kind = SymbolKind::InstanceProperty;
+  if (const CXXRecordDecl *CXXRec =
+  dyn_cast(D->getDeclContext())) {
+if (!CXXRec->isCLike())
+  Info.Lang = SymbolLanguage::CXX;
+  }
+  break;
 default:
   break;
 }
Index: clang/lib/Index/IndexDecl.cpp
===
--- clang/lib/Index/IndexDecl.cpp
+++ clang/lib/Index/IndexDecl.cpp
@@ -324,6 +324,7 @@
   }
 
   bool VisitMSPropertyDecl(const MSPropertyDecl *D) {
+TRY_DECL(D, IndexCtx.handleDecl(D));
 handleDeclarator(D);
 return true;
   }


Index: clang/test/Index/ms-property.cpp
===
--- /dev/null
+++ clang/test/Index/ms-property.cpp
@@ -0,0 +1,32 @@
+// RUN: c-index-test core -print-source-symbols -- -fms-extensions -fno-ms-compatibility %s | FileCheck %s
+
+// CHECK: [[@LINE+1]]:8 | struct/C++ | Simple | [[Simple_USR:.*]] |  | Def | rel: 0
+struct Simple {
+  int GetX() const;
+  // CHECK: [[@LINE-1]]:7 | instance-method/C++ | GetX | [[GetX_USR:.*]] | __ZNK6Simple4GetXEv | Decl,RelChild | rel: 1
+  // CHECK-NEXT: RelChild | Simple | [[Simple_USR]]
+
+  void PutX(int i);
+  // CHECK: [[@LINE-1]]:8 | instance-method/C++ | PutX | [[PutX_USR:.*]] | __ZN6Simple4PutXEi | Decl,RelChild | rel: 1
+  // CHECK-NEXT: RelChild | Simple | [[Simple_USR]]
+
+  __declspec(property(get=GetX, put=PutX)) int propX;
+  // CHECK: [[@LINE-1]]:48 | instance-property/C++ | propX | [[propX_USR:.*]] |  | Def,RelChild | rel: 1
+  // CHECK-NEXT: RelChild | Simple | [[Simple_USR]]
+};
+
+// CHECK: [[@LINE+1]]:5 | function/C | test | [[test_USR:.*]] | __Z4testv | Def | rel: 0
+int test() {
+  Simple s;
+  s.propX = 5;
+  // CHECK: [[@LINE-1]]:5 | instance-property/C++ | propX | [[propX_USR]] |  | Ref,RelCont | rel: 1
+  // CHECK-NEXT: RelCont | test | [[test_USR]]
+  // CHECK: [[@LINE-3]]:5 | instance-method/C++ | PutX | [[PutX_USR]] | __ZN6Simple4PutXEi | Ref,Call,RelCall,RelCont | rel: 1
+  // CHECK-NEXT: RelCall,RelCont | test | [[test_USR]]
+
+  return s.propX;
+  // CHECK: [[@LINE-1]]:12 | instance-property/C++ | propX | [[propX_USR]] |  | Ref,RelCont | rel: 1
+  // CHECK-NEXT: RelCont | test | [[test_USR]]
+  // CHECK: [[@LINE-3]]:12 | instance-method/C++ | GetX | [[GetX_USR]] | __ZNK6Simple4GetXEv | Ref,Call,RelCall,RelCont | rel: 1
+  // CHECK-NEXT: 

[PATCH] D57619: [analyzer] Canonicalize variable declarations in VarRegion objects.

2019-02-01 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun accepted this revision.
xazax.hun added a comment.
This revision is now accepted and ready to land.
Herald added a subscriber: cfe-commits.

Looks good, nice catch. :)


Repository:
  rC Clang

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

https://reviews.llvm.org/D57619



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


[PATCH] D57626: Disallow trivial_abi on a class if all copy and move constructors are deleted

2019-02-01 Thread Akira Hatanaka via Phabricator via cfe-commits
ahatanak created this revision.
ahatanak added reviewers: rsmith, rjmccall, aaron.ballman.
ahatanak added a project: clang.
Herald added subscribers: dexonsmith, jkorous.

Instead of forcing the class to be passed in registers, which was what r350920 
did, issue a warning and inform the user that the attribute cannot be used.

For more background, see this discussion: 
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20190128/259907.html

This fixes PR39683.

rdar://problem/47308221


Repository:
  rC Clang

https://reviews.llvm.org/D57626

Files:
  include/clang/Basic/AttrDocs.td
  lib/Sema/SemaDeclCXX.cpp
  test/SemaObjCXX/attr-trivial-abi.mm


Index: test/SemaObjCXX/attr-trivial-abi.mm
===
--- test/SemaObjCXX/attr-trivial-abi.mm
+++ test/SemaObjCXX/attr-trivial-abi.mm
@@ -95,3 +95,36 @@
 };
 
 S17 s17;
+
+namespace deletedCopyMoveConstructor {
+  struct __attribute__((trivial_abi)) CopyMoveDeleted { // expected-warning 
{{'trivial_abi' cannot be applied to 'CopyMoveDeleted'}}
+CopyMoveDeleted(const CopyMoveDeleted &) = delete;
+CopyMoveDeleted(CopyMoveDeleted &&) = delete;
+  };
+
+  struct __attribute__((trivial_abi)) S18 { // expected-warning 
{{'trivial_abi' cannot be applied to 'S18'}}
+CopyMoveDeleted a;
+S18(const S18 &);
+S18(S18 &&);
+  };
+
+  struct __attribute__((trivial_abi)) CopyDeleted {
+CopyDeleted(const CopyDeleted &) = delete;
+CopyDeleted(CopyDeleted &&) = default;
+  };
+
+  struct __attribute__((trivial_abi)) MoveDeleted {
+MoveDeleted(const MoveDeleted &) = default;
+MoveDeleted(MoveDeleted &&) = delete;
+  };
+
+  struct __attribute__((trivial_abi)) S19 { // expected-warning 
{{'trivial_abi' cannot be applied to 'S19'}}
+CopyDeleted a;
+MoveDeleted b;
+  };
+
+  // This is fine since the move constructor isn't deleted.
+  struct __attribute__((trivial_abi)) S20 {
+int & // a member of rvalue reference type deletes the copy constructor.
+  };
+}
Index: lib/Sema/SemaDeclCXX.cpp
===
--- lib/Sema/SemaDeclCXX.cpp
+++ lib/Sema/SemaDeclCXX.cpp
@@ -7868,6 +7868,25 @@
 RD.dropAttr();
   };
 
+  // Ill-formed if the copy and move constructors are deleted.
+  auto HasNonDeletedCopyOrMoveConstructor = [&]() {
+if (RD.needsImplicitCopyConstructor() &&
+!RD.defaultedCopyConstructorIsDeleted())
+  return true;
+if (RD.needsImplicitMoveConstructor() &&
+!RD.defaultedMoveConstructorIsDeleted())
+  return true;
+for (const CXXConstructorDecl *CD : RD.ctors())
+  if (CD->isCopyOrMoveConstructor() && !CD->isDeleted())
+return true;
+return false;
+  };
+
+  if (!HasNonDeletedCopyOrMoveConstructor()) {
+PrintDiagAndRemoveAttr();
+return;
+  }
+
   // Ill-formed if the struct has virtual functions.
   if (RD.isPolymorphic()) {
 PrintDiagAndRemoveAttr();
Index: include/clang/Basic/AttrDocs.td
===
--- include/clang/Basic/AttrDocs.td
+++ include/clang/Basic/AttrDocs.td
@@ -2566,6 +2566,7 @@
 Attribute ``trivial_abi`` has no effect in the following cases:
 
 - The class directly declares a virtual base or virtual methods.
+- The class doesn't have a copy or move constructor that isn't deleted.
 - The class has a base class that is non-trivial for the purposes of calls.
 - The class has a non-static data member whose type is non-trivial for the 
purposes of calls, which includes:
 


Index: test/SemaObjCXX/attr-trivial-abi.mm
===
--- test/SemaObjCXX/attr-trivial-abi.mm
+++ test/SemaObjCXX/attr-trivial-abi.mm
@@ -95,3 +95,36 @@
 };
 
 S17 s17;
+
+namespace deletedCopyMoveConstructor {
+  struct __attribute__((trivial_abi)) CopyMoveDeleted { // expected-warning {{'trivial_abi' cannot be applied to 'CopyMoveDeleted'}}
+CopyMoveDeleted(const CopyMoveDeleted &) = delete;
+CopyMoveDeleted(CopyMoveDeleted &&) = delete;
+  };
+
+  struct __attribute__((trivial_abi)) S18 { // expected-warning {{'trivial_abi' cannot be applied to 'S18'}}
+CopyMoveDeleted a;
+S18(const S18 &);
+S18(S18 &&);
+  };
+
+  struct __attribute__((trivial_abi)) CopyDeleted {
+CopyDeleted(const CopyDeleted &) = delete;
+CopyDeleted(CopyDeleted &&) = default;
+  };
+
+  struct __attribute__((trivial_abi)) MoveDeleted {
+MoveDeleted(const MoveDeleted &) = default;
+MoveDeleted(MoveDeleted &&) = delete;
+  };
+
+  struct __attribute__((trivial_abi)) S19 { // expected-warning {{'trivial_abi' cannot be applied to 'S19'}}
+CopyDeleted a;
+MoveDeleted b;
+  };
+
+  // This is fine since the move constructor isn't deleted.
+  struct __attribute__((trivial_abi)) S20 {
+int & // a member of rvalue reference type deletes the copy constructor.
+  };
+}
Index: lib/Sema/SemaDeclCXX.cpp

r352938 - [analyzer] Hotfix for RetainCountChecker: assert was too strong.

2019-02-01 Thread George Karpenkov via cfe-commits
Author: george.karpenkov
Date: Fri Feb  1 15:06:44 2019
New Revision: 352938

URL: http://llvm.org/viewvc/llvm-project?rev=352938=rev
Log:
[analyzer] Hotfix for RetainCountChecker: assert was too strong.

Bridged casts can happen to non-CF objects as well.

Modified:

cfe/trunk/lib/StaticAnalyzer/Checkers/RetainCountChecker/RetainCountChecker.cpp
cfe/trunk/test/Analysis/objc-arc.m

Modified: 
cfe/trunk/lib/StaticAnalyzer/Checkers/RetainCountChecker/RetainCountChecker.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Checkers/RetainCountChecker/RetainCountChecker.cpp?rev=352938=352937=352938=diff
==
--- 
cfe/trunk/lib/StaticAnalyzer/Checkers/RetainCountChecker/RetainCountChecker.cpp 
(original)
+++ 
cfe/trunk/lib/StaticAnalyzer/Checkers/RetainCountChecker/RetainCountChecker.cpp 
Fri Feb  1 15:06:44 2019
@@ -187,11 +187,10 @@ void RetainCountChecker::checkPostStmt(c
 
   QualType QT = CE->getType();
   ObjKind K;
-  if (coreFoundation::isCFObjectRef(QT)) {
-K = ObjKind::CF;
-  } else {
-assert(cocoa::isCocoaObjectRef(QT));
+  if (QT->isObjCObjectPointerType()) {
 K = ObjKind::ObjC;
+  } else {
+K = ObjKind::CF;
   }
 
   ArgEffect AE = ArgEffect(IncRef, K);

Modified: cfe/trunk/test/Analysis/objc-arc.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/objc-arc.m?rev=352938=352937=352938=diff
==
--- cfe/trunk/test/Analysis/objc-arc.m (original)
+++ cfe/trunk/test/Analysis/objc-arc.m Fri Feb  1 15:06:44 2019
@@ -239,8 +239,23 @@ extern const CFAllocatorRef kCFAllocator
 extern CFTypeRef CFRetain(CFTypeRef cf);
 extern void CFRelease(CFTypeRef cf);
 
+
 void check_bridge_retained_cast() {
 NSString *nsStr = [[NSString alloc] init];
 CFStringRef cfStr = (__bridge_retained CFStringRef)nsStr;
 CFRelease(cfStr); // no-warning
 }
+
+@interface A;
+@end
+
+void check_bridge_to_non_cocoa(CFStringRef s) {
+  A *a = (__bridge_transfer A *) s; // no-crash
+}
+
+struct B;
+
+struct B * check_bridge_to_non_cf() {
+  NSString *s = [[NSString alloc] init];
+  return (__bridge struct B*) s;
+}


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


[PATCH] D57623: [please ignore, v2] Clang test revision for new Herald rules for Github monorepo

2019-02-01 Thread Ben Hamilton via Phabricator via cfe-commits
benhamilton created this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This is another test for the new Herald rules to subscribe cfe-commits
to revisions sent out from the Github monorepo under the "clang/" subdirectory.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D57623

Files:
  clang/README.txt


Index: clang/README.txt
===
--- clang/README.txt
+++ clang/README.txt
@@ -25,3 +25,4 @@
 If you find a bug in Clang, please file it in the LLVM bug tracker:
   http://llvm.org/bugs/
 
+This is another test for the new Herald rules for the Github monorepo, please 
ignore.


Index: clang/README.txt
===
--- clang/README.txt
+++ clang/README.txt
@@ -25,3 +25,4 @@
 If you find a bug in Clang, please file it in the LLVM bug tracker:
   http://llvm.org/bugs/
 
+This is another test for the new Herald rules for the Github monorepo, please ignore.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r352936 - [WebAssembly] Fix ImportName's position in this test.

2019-02-01 Thread Dan Gohman via cfe-commits
Author: djg
Date: Fri Feb  1 14:52:29 2019
New Revision: 352936

URL: http://llvm.org/viewvc/llvm-project?rev=352936=rev
Log:
[WebAssembly] Fix ImportName's position in this test.

This is a follow-up to r352930.


Modified:
cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test

Modified: cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test?rev=352936=352935=352936=diff
==
--- cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test 
(original)
+++ cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test Fri Feb 
 1 14:52:29 2019
@@ -138,8 +138,8 @@
 // CHECK-NEXT: WarnUnusedResult (SubjectMatchRule_objc_method, 
SubjectMatchRule_enum, SubjectMatchRule_record, 
SubjectMatchRule_hasType_functionType)
 // CHECK-NEXT: Weak (SubjectMatchRule_variable, SubjectMatchRule_function, 
SubjectMatchRule_record)
 // CHECK-NEXT: WeakRef (SubjectMatchRule_variable, SubjectMatchRule_function)
-// CHECK-NEXT: WebAssemblyImportName (SubjectMatchRule_function)
 // CHECK-NEXT: WebAssemblyImportModule (SubjectMatchRule_function)
+// CHECK-NEXT: WebAssemblyImportName (SubjectMatchRule_function)
 // CHECK-NEXT: WorkGroupSizeHint (SubjectMatchRule_function)
 // CHECK-NEXT: XRayInstrument (SubjectMatchRule_function, 
SubjectMatchRule_objc_method)
 // CHECK-NEXT: XRayLogArgs (SubjectMatchRule_function, 
SubjectMatchRule_objc_method)


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


[PATCH] D51204: [COFF, ARM64] Add MS intrinsics: __getReg, _ReadStatusReg, _WriteStatusReg

2019-02-01 Thread Mike Hommey via Phabricator via cfe-commits
glandium added a comment.

In D51204#1271564 , @dmajor wrote:

> In D51204#1253230 , @mgrang wrote:
>
> > Will abandon this patch since I have implementations of these which I will 
> > upstream soon.
>
>
> Just to link up the reviews: these landed in D52838 
>  and D53115 
> . (Thanks @mgrang!)


Except not really...  D53115  got the types 
wrong, and used int instead of __int64.


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

https://reviews.llvm.org/D51204



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


[PATCH] D57438: [Sema][ObjC] Allow declaring ObjC pointer members in C++ unions under ARC

2019-02-01 Thread Akira Hatanaka via Phabricator via cfe-commits
ahatanak updated this revision to Diff 184851.
ahatanak marked an inline comment as done.
ahatanak added a comment.

Add a test case for an anonymous struct nested inside an anonymous union.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57438

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/AST/DeclCXX.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaDeclCXX.cpp
  test/SemaObjCXX/arc-0x.mm
  test/SemaObjCXX/objc-weak.mm

Index: test/SemaObjCXX/objc-weak.mm
===
--- test/SemaObjCXX/objc-weak.mm
+++ test/SemaObjCXX/objc-weak.mm
@@ -13,7 +13,7 @@
 };
 
 union U {
-  __weak id a; // expected-error {{ARC forbids Objective-C objects in union}}
+  __weak id a;
   S b; // expected-error {{union member 'b' has a non-trivial copy constructor}}
 };
 
Index: test/SemaObjCXX/arc-0x.mm
===
--- test/SemaObjCXX/arc-0x.mm
+++ test/SemaObjCXX/arc-0x.mm
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -std=c++11 -fsyntax-only -fobjc-arc -verify -fblocks -fobjc-exceptions %s
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -fobjc-arc -fobjc-runtime-has-weak -fobjc-weak -verify -fblocks -fobjc-exceptions %s
 
 // "Move" semantics, trivial version.
 void move_it(__strong id &) {
@@ -111,3 +111,159 @@
 func(^(A *a[]){}); // expected-error{{must explicitly describe intended ownership of an object array parameter}}
   }
 }
+
+namespace test_union {
+  // Implicitly-declared special functions of a union are deleted by default if
+  // ARC is enabled and the union has an ObjC pointer field.
+  union U0 {
+id f0; // expected-note 6 {{'U0' is implicitly deleted because variant field 'f0' is an ObjC pointer}}
+  };
+
+  union U1 {
+__weak id f0; // expected-note 12 {{'U1' is implicitly deleted because variant field 'f0' is an ObjC pointer}}
+U1() = default; // expected-warning {{explicitly defaulted default constructor is implicitly deleted}} expected-note {{explicitly defaulted function was implicitly deleted here}}
+~U1() = default; // expected-warning {{explicitly defaulted destructor is implicitly deleted}} expected-note {{explicitly defaulted function was implicitly deleted here}}
+U1(const U1 &) = default; // expected-warning {{explicitly defaulted copy constructor is implicitly deleted}} expected-note 2 {{explicitly defaulted function was implicitly deleted here}}
+U1(U1 &&) = default; // expected-warning {{explicitly defaulted move constructor is implicitly deleted}}
+U1 & operator=(const U1 &) = default; // expected-warning {{explicitly defaulted copy assignment operator is implicitly deleted}} expected-note 2 {{explicitly defaulted function was implicitly deleted here}}
+U1 & operator=(U1 &&) = default; // expected-warning {{explicitly defaulted move assignment operator is implicitly deleted}}
+  };
+
+  id getStrong();
+
+  // If the ObjC pointer field of a union has a default member initializer, the
+  // implicitly-declared default constructor of the union is not deleted by
+  // default.
+  union U2 {
+id f0 = getStrong(); // expected-note 4 {{'U2' is implicitly deleted because variant field 'f0' is an ObjC pointer}}
+~U2();
+  };
+
+  // It's fine if the user has explicitly defined the special functions.
+  union U3 {
+id f0;
+U3();
+~U3();
+U3(const U3 &);
+U3(U3 &&);
+U3 & operator=(const U3 &);
+U3 & operator=(U3 &&);
+  };
+
+  // ObjC pointer fields in anonymous union fields delete the defaulted special
+  // functions of the containing class.
+  struct S0 {
+union {
+  id f0; // expected-note 6 {{'' is implicitly deleted because variant field 'f0' is an ObjC pointer}}
+  char f1;
+};
+  };
+
+  struct S1 {
+union {
+  union { // expected-note 2 {{'S1' is implicitly deleted because variant field '' has a non-trivial}} expected-note 4 {{'S1' is implicitly deleted because field '' has a deleted}}
+id f0; // expected-note 2 {{'' is implicitly deleted because variant field 'f0' is an ObjC pointer}}
+char f1;
+  };
+  int f2;
+};
+  };
+
+  struct S2 {
+union {
+  struct { // expected-note 6 {{'S2' is implicitly deleted because variant field '' has a non-trivial}}
+id f0;
+int f1;
+  };
+  int f2;
+};
+int f3;
+  };
+
+  U0 *x0;
+  U1 *x1;
+  U2 *x2;
+  U3 *x3;
+  S0 *x4;
+  S1 *x5;
+  S2 *x6;
+
+  static union { // expected-error {{call to implicitly-deleted default constructor of}}
+id g0; // expected-note {{default constructor of '' is implicitly deleted because variant field 'g0' is an ObjC pointer}}
+  };
+
+  static union { // expected-error {{call to implicitly-deleted default constructor of}}
+union { // expected-note {{default constructor of '' is implicitly deleted because field '' has a deleted default constructor}}
+  union { // expected-note 

[PATCH] D57438: [Sema][ObjC] Allow declaring ObjC pointer members in C++ unions under ARC

2019-02-01 Thread Akira Hatanaka via Phabricator via cfe-commits
ahatanak marked 2 inline comments as done.
ahatanak added inline comments.



Comment at: lib/Sema/SemaDeclCXX.cpp:7084
 
+  if (FD->getParent()->isUnion() &&
+  shouldDeleteForVariantObjCPtrMember(FD, FieldType))

rjmccall wrote:
> rjmccall wrote:
> > I believe the right check for variant-ness is `inUnion()`, not 
> > `FD->getParent()->isUnion()`, since the latter can miss cases with e.g. 
> > anonymous `struct`s.
> Can you try adding a test case here for an anonymous struct nested within an 
> anonymous union?
Added a test case for an anonymous struct nested within an anonymous union 
(`struct S2` in arc-0x.mm).

I found out that the diagnostic messages clang prints for arc-0x.mm are the 
same whether `inUnion()` or `FD->getParent()->isUnion()` is called. This is 
what I discovered:

`SpecialMemberDeletionInfo` is used in two cases:

1. To find the deletedness of the special functions in the AST after a class is 
parsed.

2. When a deleted special function is used, provide more details on why the 
function is deleted and print note diagnostics.

Since the nested classes are parsed before the enclosing classes, we have all 
the information we need about the members that are directly contained to 
correctly infer the deletedness of a class' special functions. So the first 
case should work fine regardless of which method is called.

It doesn't make a difference for the second case either because 
`SpecialMemberDeletionInfo` doesn't try to find out which member of an 
anonymous struct is causing the special function to be deleted; it only does so 
for anonymous unions (which happens inside the if statement near comment "// 
Some additional restrictions exist on the variant members." at line 7140).


Repository:
  rC Clang

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

https://reviews.llvm.org/D57438



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


r352933 - Revert "[AST][OpenMP] OpenMP Sections / Section constructs contain Structured blocks"

2019-02-01 Thread Roman Lebedev via cfe-commits
Author: lebedevri
Date: Fri Feb  1 14:43:08 2019
New Revision: 352933

URL: http://llvm.org/viewvc/llvm-project?rev=352933=rev
Log:
Revert "[AST][OpenMP] OpenMP Sections / Section constructs contain Structured 
blocks"

Further reviews (D57594, D57615) have revealed that this was not reviewed,
and that the differential's description was not read during the review,
thus rendering this commit invalid.

This reverts commit r352882.

Removed:
cfe/trunk/test/AST/ast-dump-openmp-sections.cpp
Modified:
cfe/trunk/lib/Sema/SemaOpenMP.cpp

Modified: cfe/trunk/lib/Sema/SemaOpenMP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOpenMP.cpp?rev=352933=352932=352933=diff
==
--- cfe/trunk/lib/Sema/SemaOpenMP.cpp (original)
+++ cfe/trunk/lib/Sema/SemaOpenMP.cpp Fri Feb  1 14:43:08 2019
@@ -5971,13 +5971,6 @@ StmtResult Sema::ActOnOpenMPSectionsDire
 return StmtError();
   }
 
-  // 1.2.2 OpenMP Language Terminology
-  // Structured block - An executable statement with a single entry at the
-  // top and a single exit at the bottom.
-  // The point of exit cannot be a branch out of the structured block.
-  // longjmp() and throw() must not violate the entry/exit criteria.
-  cast(AStmt)->getCapturedDecl()->setNothrow();
-
   setFunctionHasBranchProtectedScope();
 
   return OMPSectionsDirective::Create(Context, StartLoc, EndLoc, Clauses, 
AStmt,
@@ -5992,13 +5985,6 @@ StmtResult Sema::ActOnOpenMPSectionDirec
 
   assert(isa(AStmt) && "Captured statement expected");
 
-  // 1.2.2 OpenMP Language Terminology
-  // Structured block - An executable statement with a single entry at the
-  // top and a single exit at the bottom.
-  // The point of exit cannot be a branch out of the structured block.
-  // longjmp() and throw() must not violate the entry/exit criteria.
-  cast(AStmt)->getCapturedDecl()->setNothrow();
-
   setFunctionHasBranchProtectedScope();
   DSAStack->setParentCancelRegion(DSAStack->isCancelRegion());
 

Removed: cfe/trunk/test/AST/ast-dump-openmp-sections.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/AST/ast-dump-openmp-sections.cpp?rev=352932=auto
==
--- cfe/trunk/test/AST/ast-dump-openmp-sections.cpp (original)
+++ cfe/trunk/test/AST/ast-dump-openmp-sections.cpp (removed)
@@ -1,57 +0,0 @@
-// RUN: %clang_cc1 -verify -fopenmp -ast-dump %s | FileCheck %s
-// RUN: %clang_cc1 -verify -fopenmp-simd -ast-dump %s | FileCheck %s
-// expected-no-diagnostics
-
-void sections() {
-#pragma omp sections
-  {
-#pragma omp section
-{
-}
-#pragma omp section
-{
-}
-  }
-}
-
-// CHECK: `-FunctionDecl
-// CHECK-NEXT:   `-CompoundStmt
-// CHECK-NEXT: `-OMPSectionsDirective
-// CHECK-NEXT:   `-CapturedStmt
-// CHECK-NEXT: `-CapturedDecl {{.*}} nothrow
-// CHECK-NEXT:   |-CompoundStmt
-// CHECK-NEXT:   | |-OMPSectionDirective
-// CHECK-NEXT:   | | `-CapturedStmt
-// CHECK-NEXT:   | |   `-CapturedDecl {{.*}} nothrow
-// CHECK-NEXT:   | | |-CompoundStmt
-// CHECK-NEXT:   | | `-ImplicitParamDecl
-// CHECK-NEXT:   | `-OMPSectionDirective
-// CHECK-NEXT:   |   `-CapturedStmt
-// CHECK-NEXT:   | `-CapturedDecl {{.*}} nothrow
-// CHECK-NEXT:   |   |-CompoundStmt
-// CHECK-NEXT:   |   `-ImplicitParamDecl
-// CHECK-NEXT:   |-ImplicitParamDecl
-// CHECK-NEXT:   |-CXXRecordDecl
-// CHECK-NEXT:   | |-DefinitionData
-// CHECK-NEXT:   | | |-DefaultConstructor
-// CHECK-NEXT:   | | |-CopyConstructor
-// CHECK-NEXT:   | | |-MoveConstructor
-// CHECK-NEXT:   | | |-CopyAssignment
-// CHECK-NEXT:   | | |-MoveAssignment
-// CHECK-NEXT:   | | `-Destructor
-// CHECK-NEXT:   | `-CapturedRecordAttr
-// CHECK-NEXT:   |-CapturedDecl {{.*}} nothrow
-// CHECK-NEXT:   | |-CompoundStmt
-// CHECK-NEXT:   | `-ImplicitParamDecl
-// CHECK-NEXT:   |-CXXRecordDecl
-// CHECK-NEXT:   | |-DefinitionData
-// CHECK-NEXT:   | | |-DefaultConstructor
-// CHECK-NEXT:   | | |-CopyConstructor
-// CHECK-NEXT:   | | |-MoveConstructor
-// CHECK-NEXT:   | | |-CopyAssignment
-// CHECK-NEXT:   | | |-MoveAssignment
-// CHECK-NEXT:   | | `-Destructor
-// CHECK-NEXT:   | `-CapturedRecordAttr
-// CHECK-NEXT:   `-CapturedDecl {{.*}} nothrow
-// CHECK-NEXT: |-CompoundStmt
-// CHECK-NEXT: `-ImplicitParamDecl


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


[PATCH] D57464: Generalize method overloading on addr spaces to C++

2019-02-01 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: test/SemaCXX/address-space-method-overloading.cpp:28
+   //inas4.bar();
+   noas.bar(); // expected-error{{call to member function 'bar' is ambiguous}}
+}

ebevhan wrote:
> rjmccall wrote:
> > ebevhan wrote:
> > > Anastasia wrote:
> > > > ebevhan wrote:
> > > > > Just as an aside (I think I mentioned this on one of the earlier 
> > > > > patches as well); treating a non-AS-qualified object as being in a 
> > > > > 'generic' AS even for normal C++ isn't a great idea IMO. The object 
> > > > > initialization code should be checking if the ASes of the actual 
> > > > > object and the desired object type are compatible, and only if so, 
> > > > > permit the overload.
> > > > I think changing this would require changing AS compatibility rules in 
> > > > general, not just for overloading but for example for conversions too. 
> > > > This seems like a wider scope change that might affect backwards 
> > > > compatibility. We might need to start an RFC on this first. John has 
> > > > suggested adding a target setting  for this on the other review. I 
> > > > think that should work.  Another idea could be to add some compiler 
> > > > directives to specify what generic address space is (if any).
> > > > 
> > > > Using default (no address space) as generic has a lot of advantages 
> > > > since it doesn't need many parser changes. In OpenCL we weren't lucky 
> > > > that initial implementation was added that used default for private 
> > > > memory and therefore when generic was introduced we had to map it to a 
> > > > new lang addr space value. That required a lot of changes in the 
> > > > parser. But once we fix those actually, anyone should be able  to map 
> > > > generic to anything. I initially thought it has no other use cases than 
> > > > in OpenCL but now I feel there might be a value to map default case (no 
> > > > address space) for something specific and then use generic to specify a 
> > > > placeholder address space on pointers or references. We could just 
> > > > expose generic address space generically and also have a mode with no 
> > > > generic address space. The latter means that conversions between 
> > > > different address spaces is never valid. Would this make sense?
> > > The big problem with the address space support in Clang is that it isn't 
> > > really very well formalized unless you're on OpenCL. There's no real way 
> > > for a target to express the relations between its address spaces; most of 
> > > the relations that exist are hard-coded.
> > > 
> > > The support should probably be generalized for both targets and for 
> > > LangASes like OpenCL's. Maybe:
> > > 
> > > * the ASes would be defined in a TableGen file which specifies which ASes 
> > > exist, which ones are compatible/subsets/supersets, etc,
> > > * or, just have a target hook that lets a target express that a 
> > > conversion from AS A to AS B is prohibited/permitted explicitly/permitted 
> > > implicitly.
> > > 
> > > Just some loose ideas; an RFC for this is possibly the right way forward.
> > > 
> > > The reason I bring all of this up is primarily because in our target, the 
> > > 'default' AS is disjoint from our other ones, so there's no 'generic' AS 
> > > to be had. Both implicit and explicit conversion between these ASes is 
> > > prohibited.  Since Clang currently doesn't allow you to express that ASes 
> > > are truly incompatible, we have a flag that blocks such conversions 
> > > unconditionally. Ideally it would be target-expressible.
> > > 
> > > -
> > > 
> > > > I think changing this would require changing AS compatibility rules in 
> > > > general, not just for overloading but for example for conversions too. 
> > > > This seems like a wider scope change that might affect backwards 
> > > > compatibility. We might need to start an RFC on this first. John has 
> > > > suggested adding a target setting for this on the other review. I think 
> > > > that should work. Another idea could be to add some compiler directives 
> > > > to specify what generic address space is (if any).
> > > 
> > > I'm unsure whether any changes to the current semantics really need to be 
> > > done, at least for the overloading problem.
> > > 
> > > For example, explicit conversion from a non-address space qualified 
> > > pointer type to an address space qualified pointer type (and vice versa) 
> > > is permitted, but implicit conversion is an error in both C and C++: 
> > > https://godbolt.org/z/UhOC0g
> > > 
> > > For an overload candidate to be viable, there has to be an implicit 
> > > conversion sequence for the implicit object argument to the implicit 
> > > object parameter type. But no such implicit conversion sequence exists 
> > > for types in different ASes, even today, or the implicit example in the 
> > > godbolt would pass. So, an overload candidate with a different AS 
> > > qualification than the object should not be 

Re: r352930 - [WebAssembly] Add an import_field function attribute

2019-02-01 Thread Aaron Ballman via cfe-commits
On Fri, Feb 1, 2019 at 5:25 PM Dan Gohman via cfe-commits
 wrote:
>
> Author: djg
> Date: Fri Feb  1 14:25:23 2019
> New Revision: 352930
>
> URL: http://llvm.org/viewvc/llvm-project?rev=352930=rev
> Log:
> [WebAssembly] Add an import_field function attribute
>
> This is similar to import_module, but sets the import field name
> instead.
>
> By default, the import field name is the same as the C/asm/.o symbol
> name. However, there are situations where it's useful to have it be
> different. For example, suppose I have a wasm API with a module named
> "pwsix" and a field named "read". There's no risk of namespace
> collisions with user code at the wasm level because the generic name
> "read" is qualified by the module name "pwsix". However in the C/asm/.o
> namespaces, the module name is not used, so if I have a global function
> named "read", it is intruding on the user's namespace.
>
> With the import_field module, I can declare my function (in libc) to be
> "__read", and then set the wasm import module to be "pwsix" and the wasm
> import field to be "read". So at the C/asm/.o levels, my symbol is
> outside the user namespace.
>
> Differential Revision: https://reviews.llvm.org/D57602

Btw, this review never went to cfe-commits, but it should have. :-)

> Added:
> cfe/trunk/test/CodeGen/wasm-import-name.c
>   - copied, changed from r352781, 
> cfe/trunk/test/CodeGen/wasm-import-module.c
> Modified:
> cfe/trunk/include/clang/Basic/Attr.td
> cfe/trunk/include/clang/Basic/AttrDocs.td
> cfe/trunk/lib/CodeGen/TargetInfo.cpp
> cfe/trunk/lib/Sema/SemaDeclAttr.cpp
> cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test
>
> Modified: cfe/trunk/include/clang/Basic/Attr.td
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=352930=352929=352930=diff
> ==
> --- cfe/trunk/include/clang/Basic/Attr.td (original)
> +++ cfe/trunk/include/clang/Basic/Attr.td Fri Feb  1 14:25:23 2019
> @@ -1514,11 +1514,19 @@ def AMDGPUNumVGPR : InheritableAttr {
>  def WebAssemblyImportModule : InheritableAttr,
>TargetSpecificAttr {
>let Spellings = [Clang<"import_module">];
> -  let Args = [StringArgument<"ImportModuleName">];
> +  let Args = [StringArgument<"ImportModule">];
>let Documentation = [WebAssemblyImportModuleDocs];
>let Subjects = SubjectList<[Function], ErrorDiag>;
>  }
>
> +def WebAssemblyImportName : InheritableAttr,
> +TargetSpecificAttr {
> +  let Spellings = [Clang<"import_name">];
> +  let Args = [StringArgument<"ImportName">];
> +  let Documentation = [WebAssemblyImportNameDocs];
> +  let Subjects = SubjectList<[Function], ErrorDiag>;
> +}
> +
>  def NoSplitStack : InheritableAttr {
>let Spellings = [GCC<"no_split_stack">];
>let Subjects = SubjectList<[Function], ErrorDiag>;
>
> Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttrDocs.td?rev=352930=352929=352930=diff
> ==
> --- cfe/trunk/include/clang/Basic/AttrDocs.td (original)
> +++ cfe/trunk/include/clang/Basic/AttrDocs.td Fri Feb  1 14:25:23 2019
> @@ -3730,6 +3730,23 @@ reuqest a specific module name be used i
>}];
>  }
>
> +def WebAssemblyImportNameDocs : Documentation {
> +  let Category = DocCatFunction;
> +  let Content = [{
> +Clang supports the ``__attribute__((import_name()))``
> +attribute for the WebAssembly target. This attribute may be attached to a
> +function declaration, where it modifies how the symbol is to be imported
> +within the WebAssembly linking environment.
> +
> +WebAssembly imports use a two-level namespace scheme, consisting of a module
> +name, which typically identifies a module from which to import, and a field
> +name, which typically identifies a field from that module to import. By
> +default, field names for C/C++ symbols are the same as their C/C++ symbol
> +names. This attribute can be used to override the default behavior, and
> +reuqest a specific field name be used instead.
> +  }];
> +}
> +
>  def ArtificialDocs : Documentation {
>let Category = DocCatFunction;
>let Content = [{
>
> Modified: cfe/trunk/lib/CodeGen/TargetInfo.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp?rev=352930=352929=352930=diff
> ==
> --- cfe/trunk/lib/CodeGen/TargetInfo.cpp (original)
> +++ cfe/trunk/lib/CodeGen/TargetInfo.cpp Fri Feb  1 14:25:23 2019
> @@ -765,7 +765,13 @@ public:
>if (const auto *Attr = FD->getAttr()) {
>  llvm::Function *Fn = cast(GV);
>  llvm::AttrBuilder B;
> -B.addAttribute("wasm-import-module", Attr->getImportModuleName());
> +B.addAttribute("wasm-import-module", 

r352930 - [WebAssembly] Add an import_field function attribute

2019-02-01 Thread Dan Gohman via cfe-commits
Author: djg
Date: Fri Feb  1 14:25:23 2019
New Revision: 352930

URL: http://llvm.org/viewvc/llvm-project?rev=352930=rev
Log:
[WebAssembly] Add an import_field function attribute

This is similar to import_module, but sets the import field name
instead.

By default, the import field name is the same as the C/asm/.o symbol
name. However, there are situations where it's useful to have it be
different. For example, suppose I have a wasm API with a module named
"pwsix" and a field named "read". There's no risk of namespace
collisions with user code at the wasm level because the generic name
"read" is qualified by the module name "pwsix". However in the C/asm/.o
namespaces, the module name is not used, so if I have a global function
named "read", it is intruding on the user's namespace.

With the import_field module, I can declare my function (in libc) to be
"__read", and then set the wasm import module to be "pwsix" and the wasm
import field to be "read". So at the C/asm/.o levels, my symbol is
outside the user namespace.

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

Added:
cfe/trunk/test/CodeGen/wasm-import-name.c
  - copied, changed from r352781, 
cfe/trunk/test/CodeGen/wasm-import-module.c
Modified:
cfe/trunk/include/clang/Basic/Attr.td
cfe/trunk/include/clang/Basic/AttrDocs.td
cfe/trunk/lib/CodeGen/TargetInfo.cpp
cfe/trunk/lib/Sema/SemaDeclAttr.cpp
cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test

Modified: cfe/trunk/include/clang/Basic/Attr.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=352930=352929=352930=diff
==
--- cfe/trunk/include/clang/Basic/Attr.td (original)
+++ cfe/trunk/include/clang/Basic/Attr.td Fri Feb  1 14:25:23 2019
@@ -1514,11 +1514,19 @@ def AMDGPUNumVGPR : InheritableAttr {
 def WebAssemblyImportModule : InheritableAttr,
   TargetSpecificAttr {
   let Spellings = [Clang<"import_module">];
-  let Args = [StringArgument<"ImportModuleName">];
+  let Args = [StringArgument<"ImportModule">];
   let Documentation = [WebAssemblyImportModuleDocs];
   let Subjects = SubjectList<[Function], ErrorDiag>;
 }
 
+def WebAssemblyImportName : InheritableAttr,
+TargetSpecificAttr {
+  let Spellings = [Clang<"import_name">];
+  let Args = [StringArgument<"ImportName">];
+  let Documentation = [WebAssemblyImportNameDocs];
+  let Subjects = SubjectList<[Function], ErrorDiag>;
+}
+
 def NoSplitStack : InheritableAttr {
   let Spellings = [GCC<"no_split_stack">];
   let Subjects = SubjectList<[Function], ErrorDiag>;

Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttrDocs.td?rev=352930=352929=352930=diff
==
--- cfe/trunk/include/clang/Basic/AttrDocs.td (original)
+++ cfe/trunk/include/clang/Basic/AttrDocs.td Fri Feb  1 14:25:23 2019
@@ -3730,6 +3730,23 @@ reuqest a specific module name be used i
   }];
 }
 
+def WebAssemblyImportNameDocs : Documentation {
+  let Category = DocCatFunction;
+  let Content = [{
+Clang supports the ``__attribute__((import_name()))`` 
+attribute for the WebAssembly target. This attribute may be attached to a
+function declaration, where it modifies how the symbol is to be imported
+within the WebAssembly linking environment.
+
+WebAssembly imports use a two-level namespace scheme, consisting of a module
+name, which typically identifies a module from which to import, and a field
+name, which typically identifies a field from that module to import. By
+default, field names for C/C++ symbols are the same as their C/C++ symbol
+names. This attribute can be used to override the default behavior, and
+reuqest a specific field name be used instead.
+  }];
+}
+
 def ArtificialDocs : Documentation {
   let Category = DocCatFunction;
   let Content = [{

Modified: cfe/trunk/lib/CodeGen/TargetInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp?rev=352930=352929=352930=diff
==
--- cfe/trunk/lib/CodeGen/TargetInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/TargetInfo.cpp Fri Feb  1 14:25:23 2019
@@ -765,7 +765,13 @@ public:
   if (const auto *Attr = FD->getAttr()) {
 llvm::Function *Fn = cast(GV);
 llvm::AttrBuilder B;
-B.addAttribute("wasm-import-module", Attr->getImportModuleName());
+B.addAttribute("wasm-import-module", Attr->getImportModule());
+Fn->addAttributes(llvm::AttributeList::FunctionIndex, B);
+  }
+  if (const auto *Attr = FD->getAttr()) {
+llvm::Function *Fn = cast(GV);
+llvm::AttrBuilder B;
+B.addAttribute("wasm-import-name", Attr->getImportName());
 Fn->addAttributes(llvm::AttributeList::FunctionIndex, B);
  

[PATCH] D46421: [analyzer][CrossTU] Extend CTU to VarDecls with initializer

2019-02-01 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a comment.

Fxd the global variable problem in D57619 , 
thanks! I think you should change back to `getInit()` once D57619 
 lands.


Repository:
  rC Clang

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

https://reviews.llvm.org/D46421



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


[PATCH] D57464: Generalize method overloading on addr spaces to C++

2019-02-01 Thread Bevin Hansson via Phabricator via cfe-commits
ebevhan added inline comments.



Comment at: test/SemaCXX/address-space-method-overloading.cpp:28
+   //inas4.bar();
+   noas.bar(); // expected-error{{call to member function 'bar' is ambiguous}}
+}

rjmccall wrote:
> ebevhan wrote:
> > Anastasia wrote:
> > > ebevhan wrote:
> > > > Just as an aside (I think I mentioned this on one of the earlier 
> > > > patches as well); treating a non-AS-qualified object as being in a 
> > > > 'generic' AS even for normal C++ isn't a great idea IMO. The object 
> > > > initialization code should be checking if the ASes of the actual object 
> > > > and the desired object type are compatible, and only if so, permit the 
> > > > overload.
> > > I think changing this would require changing AS compatibility rules in 
> > > general, not just for overloading but for example for conversions too. 
> > > This seems like a wider scope change that might affect backwards 
> > > compatibility. We might need to start an RFC on this first. John has 
> > > suggested adding a target setting  for this on the other review. I think 
> > > that should work.  Another idea could be to add some compiler directives 
> > > to specify what generic address space is (if any).
> > > 
> > > Using default (no address space) as generic has a lot of advantages since 
> > > it doesn't need many parser changes. In OpenCL we weren't lucky that 
> > > initial implementation was added that used default for private memory and 
> > > therefore when generic was introduced we had to map it to a new lang addr 
> > > space value. That required a lot of changes in the parser. But once we 
> > > fix those actually, anyone should be able  to map generic to anything. I 
> > > initially thought it has no other use cases than in OpenCL but now I feel 
> > > there might be a value to map default case (no address space) for 
> > > something specific and then use generic to specify a placeholder address 
> > > space on pointers or references. We could just expose generic address 
> > > space generically and also have a mode with no generic address space. The 
> > > latter means that conversions between different address spaces is never 
> > > valid. Would this make sense?
> > The big problem with the address space support in Clang is that it isn't 
> > really very well formalized unless you're on OpenCL. There's no real way 
> > for a target to express the relations between its address spaces; most of 
> > the relations that exist are hard-coded.
> > 
> > The support should probably be generalized for both targets and for 
> > LangASes like OpenCL's. Maybe:
> > 
> > * the ASes would be defined in a TableGen file which specifies which ASes 
> > exist, which ones are compatible/subsets/supersets, etc,
> > * or, just have a target hook that lets a target express that a conversion 
> > from AS A to AS B is prohibited/permitted explicitly/permitted implicitly.
> > 
> > Just some loose ideas; an RFC for this is possibly the right way forward.
> > 
> > The reason I bring all of this up is primarily because in our target, the 
> > 'default' AS is disjoint from our other ones, so there's no 'generic' AS to 
> > be had. Both implicit and explicit conversion between these ASes is 
> > prohibited.  Since Clang currently doesn't allow you to express that ASes 
> > are truly incompatible, we have a flag that blocks such conversions 
> > unconditionally. Ideally it would be target-expressible.
> > 
> > -
> > 
> > > I think changing this would require changing AS compatibility rules in 
> > > general, not just for overloading but for example for conversions too. 
> > > This seems like a wider scope change that might affect backwards 
> > > compatibility. We might need to start an RFC on this first. John has 
> > > suggested adding a target setting for this on the other review. I think 
> > > that should work. Another idea could be to add some compiler directives 
> > > to specify what generic address space is (if any).
> > 
> > I'm unsure whether any changes to the current semantics really need to be 
> > done, at least for the overloading problem.
> > 
> > For example, explicit conversion from a non-address space qualified pointer 
> > type to an address space qualified pointer type (and vice versa) is 
> > permitted, but implicit conversion is an error in both C and C++: 
> > https://godbolt.org/z/UhOC0g
> > 
> > For an overload candidate to be viable, there has to be an implicit 
> > conversion sequence for the implicit object argument to the implicit object 
> > parameter type. But no such implicit conversion sequence exists for types 
> > in different ASes, even today, or the implicit example in the godbolt would 
> > pass. So, an overload candidate with a different AS qualification than the 
> > object should not be viable.
> > 
> > This is clearly not compatible with OpenCL's notion of the `__generic` AS, 
> > but OpenCL already has logic for `__generic` in Qualifiers to handle that 
> > case 

[PATCH] D56571: [RFC prototype] Implementation of asm-goto support in clang

2019-02-01 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added inline comments.



Comment at: include/clang/AST/Stmt.h:1008
+ (*iterator_adaptor_base::I)->getStmtClass() <= lastExprConstant);
+  return *reinterpret_cast(iterator_adaptor_base::I);
 }

Ugh. This cast violates strict aliasing, and even in the absence of strict 
aliasing won't work unless the `Stmt` base class is at offset 0 in `T`. The 
preceding assert is also wrong, as it's asserting that `*I` is an `Expr`, not 
that it's a `T`.

After r352925, you can use `CastIterator` instead; that should 
substantially reduce the churn in this patch.



Comment at: include/clang/AST/Stmt.h:2842
+
+  bool isGCCAsmGoto() const {
+return NumLabels > 0;

This is already inside a class `GCCAsmStmt`; the `GCC` here seems unnecessary.



Comment at: include/clang/AST/Stmt.h:2860
+  StringRef getLabelName(unsigned i) const;
+  Expr *getExpr(unsigned i) const;
+  using labels_iterator = ExprIterator;

Please give this a better name; `getExpr` is pretty meaningless.



Comment at: lib/Analysis/CFG.cpp:1466
+  LabelMapTy::iterator LI = LabelMap.find(E->getLabel());
+  if (LI == LabelMap.end()) continue;
+  JT = LI->second;

If this happens for every iteration of the loop, `VD` is used uninitialized 
after the loop.



Comment at: lib/Analysis/CFG.cpp:1472
+ JT.scopePosition);
+  VD = prependAutomaticObjScopeEndWithTerminator(B, I->scopePosition,
+ JT.scopePosition);

It is extremely suspicious to be overwriting the value of `VD` on each 
iteration of the loop like this. If you are assuming that the same value will 
be returned every time, please include an `assert` of that.



Comment at: lib/Analysis/CFG.cpp:2126
+  if (cast(S)->isGCCAsmGoto())
+return VisitGCCAsmStmt(cast(S));
+  return VisitStmt(S, asc);

This is not an appropriate function name for a function that is only called on 
`asm goto`. Given the convention here is to match the `Stmt` class hierarchy 
with the `Visit` functions, the branch on `asm goto` should be in the callee.



Comment at: lib/CodeGen/CGStmt.cpp:1884
+template 
+void CodeGenFunction::UpdateCallInst(
+T , bool HasSideEffect, bool ReadOnly, bool ReadNone,

This is not a reasonable function name for a function that is specific to 
`AsmStmt`s. Please also make this a (static) non-member function, since it 
cannot be called outside this source file.



Comment at: lib/CodeGen/CGStmt.cpp:2238-2245
+UpdateCallInst(*Result, HasSideEffect, ReadOnly,
+ ReadNone, S, ResultRegTypes, RegResults);
+EmitBlock(Fallthrough);
   } else {
-for (unsigned i = 0, e = ResultRegTypes.size(); i != e; ++i) {
-  llvm::Value *Tmp = Builder.CreateExtractValue(Result, i, "asmresult");
-  RegResults.push_back(Tmp);
-}
+llvm::CallInst *Result =
+Builder.CreateCall(IA, Args, getBundlesForFunclet(IA));
+UpdateCallInst(*Result, HasSideEffect, ReadOnly, ReadNone,

No need to explicitly specify the template argument here; it's deducible.



Comment at: lib/Parse/ParseStmtAsm.cpp:833-837
+if (Tok.isNot(tok::identifier)) {
+  Diag(Tok, diag::err_expected) << tok::identifier;
+  SkipUntil(tok::r_paren, StopAtSemi);
+  return StmtError();
+}

This should be inside the loop below.



Comment at: lib/Parse/ParseStmtAsm.cpp:839
+if (Tok.isNot(tok::r_paren)) {
+  while (1) {
+LabelDecl *LD = Actions.LookupOrCreateLabel(Tok.getIdentifierInfo(),

`while (true)`


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

https://reviews.llvm.org/D56571



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


[PATCH] D57615: [AST][OpenMP] OpenMP master Construct contains Structured block

2019-02-01 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

In D57615#1381461 , @ABataev wrote:

> In D57615#1381443 , @lebedev.ri 
> wrote:
>
> > Let's instead solve the problem of structured block not having an AST 
> > representation.
>
>
> Again, this is not a problem for the compiler. If you want this idiom for the 
> analyzer, you need to teach the analyzer to handle the AST nodes in 
> accordance with the OpenMP standard.


I'm sorry, but //to me// that just sounds completely wrong.

It sounds remotely like the gcc argument of keeping everything in
the least modular fashion just so no one does anything bad with it.

OpenMP spec gives a pretty good idea when something is an 'structured block'.
I'm specifically looking for these OpenMP structured blocks.
Are you telling me that i should forget everything i know about the 'goals' of 
clang AST,
(and i do believe it is reasonable to expect to have an `OMPStructuredBlock` 
opaque entry)
and reimplement the 'OpenMP structured blocks' finding in whatever code i'm 
writing,
instead of doing the right thing, and teaching the AST about it?

Obviously, said teaching should not have any negative impact on the existing 
clang OpenMP code.
Obviously, everyone's time is limited, and i won't be able to convince anyone 
to do that //for// me :)

I can see just how **quickly** i have derailed this disscussion, in less than 
12h.
I guess i should stop commenting, and follow "words are cheap, show the code".


Repository:
  rC Clang

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

https://reviews.llvm.org/D57615



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


r352927 - Improve diagnostic to tell you a type is incomplete.

2019-02-01 Thread Eric Fiselier via cfe-commits
Author: ericwf
Date: Fri Feb  1 14:06:02 2019
New Revision: 352927

URL: http://llvm.org/viewvc/llvm-project?rev=352927=rev
Log:
Improve diagnostic to tell you a type is incomplete.

I recently ran into this code:
```
\#include 
void foo(const std::string , const std::string& = "");
\#include 
void test() { foo(""); }
```

The diagnostic produced said it can't bind char[1] to std::string
const&. It didn't mention std::string is incomplete. The user had to
infer that.

This patch causes the diagnostic to now say "incomplete type".

Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Sema/SemaInit.cpp
cfe/trunk/test/SemaCXX/cxx0x-initializer-stdinitializerlist.cpp
cfe/trunk/test/SemaCXX/decl-init-ref.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=352927=352926=352927=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Fri Feb  1 14:06:02 
2019
@@ -1828,8 +1828,9 @@ def err_reference_bind_drops_quals : Err
   "'volatile'|'const' and 'volatile'|'restrict' and 'volatile'|"
   "'const', 'restrict', and 'volatile'}2 qualifier%plural{1:|2:|4:|:s}2">;
 def err_reference_bind_failed : Error<
-  "reference %diff{to type $ could not bind to an %select{rvalue|lvalue}1 of "
-  "type $|could not bind to %select{rvalue|lvalue}1 of incompatible type}0,2">;
+  "reference %diff{to %select{type|incomplete type}1 $ could not bind to an "
+  "%select{rvalue|lvalue}2 of type $|could not bind to %select{rvalue|lvalue}2 
of "
+  "incompatible type}0,3">;
 def err_reference_bind_init_list : Error<
   "reference to type %0 cannot bind to an initializer list">;
 def err_init_list_bad_dest_type : Error<

Modified: cfe/trunk/lib/Sema/SemaInit.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaInit.cpp?rev=352927=352926=352927=diff
==
--- cfe/trunk/lib/Sema/SemaInit.cpp (original)
+++ cfe/trunk/lib/Sema/SemaInit.cpp Fri Feb  1 14:06:02 2019
@@ -8450,6 +8450,7 @@ bool InitializationSequence::Diagnose(Se
   case FK_ReferenceInitFailed:
 S.Diag(Kind.getLocation(), diag::err_reference_bind_failed)
   << DestType.getNonReferenceType()
+  << DestType.getNonReferenceType()->isIncompleteType()
   << OnlyArg->isLValue()
   << OnlyArg->getType()
   << Args[0]->getSourceRange();

Modified: cfe/trunk/test/SemaCXX/cxx0x-initializer-stdinitializerlist.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/cxx0x-initializer-stdinitializerlist.cpp?rev=352927=352926=352927=diff
==
--- cfe/trunk/test/SemaCXX/cxx0x-initializer-stdinitializerlist.cpp (original)
+++ cfe/trunk/test/SemaCXX/cxx0x-initializer-stdinitializerlist.cpp Fri Feb  1 
14:06:02 2019
@@ -327,7 +327,7 @@ namespace update_rbrace_loc_crash {
   struct A {};
   template 
   std::initializer_list ExplodeImpl(F p1, A) {
-// expected-error@+1 {{reference to type 'const 
update_rbrace_loc_crash::Incomplete' could not bind to an rvalue of type 
'void'}}
+// expected-error@+1 {{reference to incomplete type 'const 
update_rbrace_loc_crash::Incomplete' could not bind to an rvalue of type 
'void'}}
 return {p1(I)...};
   }
   template 

Modified: cfe/trunk/test/SemaCXX/decl-init-ref.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/decl-init-ref.cpp?rev=352927=352926=352927=diff
==
--- cfe/trunk/test/SemaCXX/decl-init-ref.cpp (original)
+++ cfe/trunk/test/SemaCXX/decl-init-ref.cpp Fri Feb  1 14:06:02 2019
@@ -36,3 +36,12 @@ namespace PR16502 {
   int f();
   const A  = { 10, ++c.temporary };
 }
+
+namespace IncompleteTest {
+  struct String;
+  // expected-error@+1 {{reference to incomplete type 'const 
IncompleteTest::String' could not bind to an lvalue of type 'const char [1]'}}
+  void takeString(const String& = "") {} // expected-note {{passing argument 
to parameter here}} expected-note {{candidate function}}
+  void test() {
+takeString(); // expected-error {{no matching function for call}}
+  }
+}


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


[PATCH] D53153: [OpenCL] Mark kernel functions with default visibility

2019-02-01 Thread Scott Linder via Phabricator via cfe-commits
scott.linder abandoned this revision.
scott.linder added a comment.

See https://reviews.llvm.org/D56871


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

https://reviews.llvm.org/D53153



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


r352925 - Factor out duplication between ExprIterator and ConstExprIterator.

2019-02-01 Thread Richard Smith via cfe-commits
Author: rsmith
Date: Fri Feb  1 13:58:17 2019
New Revision: 352925

URL: http://llvm.org/viewvc/llvm-project?rev=352925=rev
Log:
Factor out duplication between ExprIterator and ConstExprIterator.

This also exposes a more general iterator cast mechanism suitable for
use in http://reviews.llvm.org/D56571.

Modified:
cfe/trunk/include/clang/AST/Stmt.h
cfe/trunk/lib/CodeGen/CGCoroutine.cpp

Modified: cfe/trunk/include/clang/AST/Stmt.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Stmt.h?rev=352925=352924=352925=diff
==
--- cfe/trunk/include/clang/AST/Stmt.h (original)
+++ cfe/trunk/include/clang/AST/Stmt.h Fri Feb  1 13:58:17 2019
@@ -986,38 +986,31 @@ public:
   struct EmptyShell {};
 
 protected:
-  /// Iterator for iterating over Stmt * arrays that contain only Expr *
+  /// Iterator for iterating over Stmt * arrays that contain only T *.
   ///
   /// This is needed because AST nodes use Stmt* arrays to store
   /// references to children (to be compatible with StmtIterator).
-  struct ExprIterator
-  : llvm::iterator_adaptor_base {
-ExprIterator() : iterator_adaptor_base(nullptr) {}
-ExprIterator(Stmt **I) : iterator_adaptor_base(I) {}
-
-reference operator*() const {
-  assert((*I)->getStmtClass() >= firstExprConstant &&
- (*I)->getStmtClass() <= lastExprConstant);
-  return *reinterpret_cast(I);
-}
-  };
+  template
+  struct CastIterator
+  : llvm::iterator_adaptor_base, StmtPtr *,
+std::random_access_iterator_tag, TPtr> {
+using Base = typename CastIterator::iterator_adaptor_base;
+
+CastIterator() : Base(nullptr) {}
+CastIterator(StmtPtr *I) : Base(I) {}
 
-  /// Const iterator for iterating over Stmt * arrays that contain only Expr *
-  struct ConstExprIterator
-  : llvm::iterator_adaptor_base {
-ConstExprIterator() : iterator_adaptor_base(nullptr) {}
-ConstExprIterator(const Stmt *const *I) : iterator_adaptor_base(I) {}
-
-reference operator*() const {
-  assert((*I)->getStmtClass() >= firstExprConstant &&
- (*I)->getStmtClass() <= lastExprConstant);
-  return *reinterpret_cast(I);
+typename Base::value_type operator*() const {
+  return cast(*this->I);
 }
   };
 
+  /// Const iterator for iterating over Stmt * arrays that contain only T *.
+  template 
+  using ConstCastIterator = CastIterator;
+
+  using ExprIterator = CastIterator;
+  using ConstExprIterator = ConstCastIterator;
+
 private:
   /// Whether statistic collection is enabled.
   static bool StatisticsEnabled;

Modified: cfe/trunk/lib/CodeGen/CGCoroutine.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCoroutine.cpp?rev=352925=352924=352925=diff
==
--- cfe/trunk/lib/CodeGen/CGCoroutine.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCoroutine.cpp Fri Feb  1 13:58:17 2019
@@ -732,7 +732,7 @@ RValue CodeGenFunction::EmitCoroutineInt
 Args.push_back(llvm::ConstantTokenNone::get(getLLVMContext()));
 break;
   }
-  for (auto  : E->arguments())
+  for (const Expr *Arg : E->arguments())
 Args.push_back(EmitScalarExpr(Arg));
 
   llvm::Value *F = CGM.getIntrinsic(IID);


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


[PATCH] D57615: [AST][OpenMP] OpenMP master Construct contains Structured block

2019-02-01 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

In D57615#1381467 , @lebedev.ri wrote:

> In D57615#1381447 , @ABataev wrote:
>
> > > Okay, enough is enough :)
> > >  I think a very important phrase was repeated a number of times, and it 
> > > highlights the **actual** problem here:
> > > 
> > >> is not the representation of the structured block
> >
> > It is not a problem! It is the internal implementation design! What do you 
> > want to get? Why do you need all these flags?
>
>
> Uhm, i did state that in the commit message of rL352882 
>  :
>
> >Summary:
> >   I'm working on a clang-tidy check, much like existing [[ 
> > http://clang.llvm.org/extra/clang-tidy/checks/bugprone-exception-escape.html
> >  | bugprone-exception-escape ]],
> >   to detect when an exception might escape out of an OpenMP construct it 
> > isn't supposed to escape from.
>
> and in https://bugs.llvm.org/show_bug.cgi?id=40563#c4 :
>
> > (In reply to Roman Lebedev from comment #4)
> >  > (In reply to Alexey Bataev from comment #3)
> >  > > (In reply to Roman Lebedev from comment #2)
> >  > > > (In reply to Alexey Bataev from comment #1)
> >  > > > CapturedDecl is not the representation of the structured block. It 
> > used just
> >  > > > to simplify the parsing/sema/codegen. The outlined function is not 
> > generated
> >  > > > for the loop, so there is no problem with the standard compatibility.
> >  > > 
> >  > > Exactly. Perhaps i have poorly titled the bug.
> >  > > 
> >  > > The real question was formulated in the last phrase:
> >  > > 
> >  > > > There needs to be some way to represent the fact that
> >  > > > only the body is nothrow.
> >  > 
> >  > What for? It does not help with anything. Standard does not require to
> >  > perform a thorough analysis of the structured blocks for the single
> >  > entry/single exit criteria. It just states that such OpenMP directives 
> > are
> >  > not compatible with the standard. What do you want to get with this?
> > 
> > Such syntactic sugar in AST potentially helps in the same way the very
> > existence
> >  of well-defined AST helps - it is much easier to further operate on an
> > well-defined
> >  AST, rather than on something less specified for that. (IR, asm, ...)
> > 
> > In this case, i'm going through the OP spec, through the every
> >  > A throw executed inside a ??? region must cause execution to resume 
> > within the
> >  > same iteration of the ??? region, and the same thread that threw the 
> > exception must
> >  > catch it.
> >  note, and trying to verify that it is what clang does, either via
> >  CapturedDecl's 'nothrow' tag,
> >  or, like in this case, by filing an issue.
> > 
> > I want this info, so i can use this finely-structured info to do at least
> > partial
> >  validation that these notes "no exception may escape" in the standard are
> >  not violated.
> > 
> > In my case, it will be a clang-tidy check, because there is existing infra
> >  for that.
> >  A clang static analyzer check may appear later, or it may not.
> >  (Though it would be especially interesting in the presence of cross-TU
> >  analysis.)
> > 
> > Therefore i *insist* that it would be //nice// to have this info in the AST
> >  :)
> > 
> > This is not a bug in a form "omg your implementation is so broken, fix it
> >  immediately",
> >  i'm simply using it to track the remaining issues. When i'm done with the
> >  easy cases,
> >  i'll try to cycle back here, and look how this could be solved.
>
> Does that answer the question?
>
> >> Then could you please revoke LG from D57594 
> >> .
> > 
> > Done!
>
> Thanks.


AST already has all the required information. You just need to teach your 
analyzer how to get it. The structured blocks are not represented by 
CapturedStmt/CapturedDecl, in many cases they are hidden inside of them.  You 
just need to get it. But it does not mean that this a compiler problem.
For some constructs, you may have 2,3 or 4 captured statements, but the 
structured block is just 1 and it is hidden somewhere inside for better codegen 
support.
And you need to teach the analyzer how to get this data from the existing AST 
nodes.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57615



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


[PATCH] D57615: [AST][OpenMP] OpenMP master Construct contains Structured block

2019-02-01 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

In D57615#1381447 , @ABataev wrote:

> > Okay, enough is enough :)
> >  I think a very important phrase was repeated a number of times, and it 
> > highlights the **actual** problem here:
> > 
> >> is not the representation of the structured block
>
> It is not a problem! It is the internal implementation design! What do you 
> want to get? Why do you need all these flags?


Uhm, i did state that in the commit message of rL352882 
 :

>Summary:
>   I'm working on a clang-tidy check, much like existing [[ 
> http://clang.llvm.org/extra/clang-tidy/checks/bugprone-exception-escape.html 
> | bugprone-exception-escape ]],
>   to detect when an exception might escape out of an OpenMP construct it 
> isn't supposed to escape from.

and in https://bugs.llvm.org/show_bug.cgi?id=40563#c4 :

> (In reply to Roman Lebedev from comment #4)
>  > (In reply to Alexey Bataev from comment #3)
>  > > (In reply to Roman Lebedev from comment #2)
>  > > > (In reply to Alexey Bataev from comment #1)
>  > > > CapturedDecl is not the representation of the structured block. It 
> used just
>  > > > to simplify the parsing/sema/codegen. The outlined function is not 
> generated
>  > > > for the loop, so there is no problem with the standard compatibility.
>  > > 
>  > > Exactly. Perhaps i have poorly titled the bug.
>  > > 
>  > > The real question was formulated in the last phrase:
>  > > 
>  > > > There needs to be some way to represent the fact that
>  > > > only the body is nothrow.
>  > 
>  > What for? It does not help with anything. Standard does not require to
>  > perform a thorough analysis of the structured blocks for the single
>  > entry/single exit criteria. It just states that such OpenMP directives are
>  > not compatible with the standard. What do you want to get with this?
> 
> Such syntactic sugar in AST potentially helps in the same way the very
> existence
>  of well-defined AST helps - it is much easier to further operate on an
> well-defined
>  AST, rather than on something less specified for that. (IR, asm, ...)
> 
> In this case, i'm going through the OP spec, through the every
>  > A throw executed inside a ??? region must cause execution to resume within 
> the
>  > same iteration of the ??? region, and the same thread that threw the 
> exception must
>  > catch it.
>  note, and trying to verify that it is what clang does, either via
>  CapturedDecl's 'nothrow' tag,
>  or, like in this case, by filing an issue.
> 
> I want this info, so i can use this finely-structured info to do at least
> partial
>  validation that these notes "no exception may escape" in the standard are
>  not violated.
> 
> In my case, it will be a clang-tidy check, because there is existing infra
>  for that.
>  A clang static analyzer check may appear later, or it may not.
>  (Though it would be especially interesting in the presence of cross-TU
>  analysis.)
> 
> Therefore i *insist* that it would be //nice// to have this info in the AST
>  :)
> 
> This is not a bug in a form "omg your implementation is so broken, fix it
>  immediately",
>  i'm simply using it to track the remaining issues. When i'm done with the
>  easy cases,
>  i'll try to cycle back here, and look how this could be solved.

Does that answer the question?

>> Then could you please revoke LG from D57594 
>> .
> 
> Done!

Thanks.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57615



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


[PATCH] D57615: [AST][OpenMP] OpenMP master Construct contains Structured block

2019-02-01 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

In D57615#1381443 , @lebedev.ri wrote:

> Let's instead solve the problem of structured block not having an AST 
> representation.


Again, this is not a problem for the compiler. If you want this idiom for the 
analyzer, you need to teach the analyzer to handle the AST nodes in accordance 
with the OpenMP standard.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57615



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


[PATCH] D57615: [AST][OpenMP] OpenMP master Construct contains Structured block

2019-02-01 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

> Okay, enough is enough :)
>  I think a very important phrase was repeated a number of times, and it 
> highlights the **actual** problem here:
> 
>> is not the representation of the structured block

It is not a problem! It is the internal implementation design! What do you want 
to get? Why do you need all these flags?

> Then could you please revoke LG from D57594 .

Done!


Repository:
  rC Clang

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

https://reviews.llvm.org/D57615



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


[PATCH] D57594: [AST][OpenMP] OpenMP single Construct contains Structured block

2019-02-01 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri abandoned this revision.
lebedev.ri added a comment.

Let's instead solve the problem of structured block not having an AST 
representation.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57594



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


[PATCH] D57615: [AST][OpenMP] OpenMP master Construct contains Structured block

2019-02-01 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri abandoned this revision.
lebedev.ri added a comment.

Let's instead solve the problem of structured block not having an AST 
representation.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57615



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


[PATCH] D57615: [AST][OpenMP] OpenMP master Construct contains Structured block

2019-02-01 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

In D57615#1381428 , @ABataev wrote:

> In D57615#1381427 , @lebedev.ri 
> wrote:
>
> > In D57615#1381418 , @ABataev wrote:
> >
> > > In D57615#1381416 , @lebedev.ri 
> > > wrote:
> > >
> > > > @ABataev i'm not sure i have fully followed the 
> > > > https://bugs.llvm.org/show_bug.cgi?id=40563#c1
> > > >
> > > > > The outlined function is not generated for the loop, so there is no 
> > > > > problem with the standard compatibility.
> > > >
> > > > Are you saying that in these cases of `master`, `critical`, `single` 
> > > > directives, `CapturedDecl` should **not** have `nothrow` bit set too?
> > >
> > >
> > > This flag just does not matter for them.
> >
> >
> > I'll rephrase:
> >  Are you opposed to providing the correct (as per the specification) 
> > knowledge that
> >  no exception will escape out of these `CapturedDecl`'s, because that 
> > knowledge
> >  does not matter for the existing sema/codegen, and does not affect 
> > produced IR?
>
>
> Again, CapturedDecl and CapturedStmt is not the representation of the 
> structured block. It is a helper structure for the codegen only. This flag 
> does not help with anything, because for such OpenMP constructs the codegen 
> bypasses CapturedStmt/CapturedDecl.


Okay, enough is enough :)
I think a very important phrase was repeated a number of times, and it 
highlights the **actual** problem here:

> is not the representation of the structured block



> I'm not opposed. I'm saying, that it is not required and not used. If it is 
> not used, why do you want to set it?

Then could you please revoke LG from D57594 .


Repository:
  rC Clang

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

https://reviews.llvm.org/D57615



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


[PATCH] D57615: [AST][OpenMP] OpenMP master Construct contains Structured block

2019-02-01 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

In D57615#1381427 , @lebedev.ri wrote:

> In D57615#1381418 , @ABataev wrote:
>
> > In D57615#1381416 , @lebedev.ri 
> > wrote:
> >
> > > @ABataev i'm not sure i have fully followed the 
> > > https://bugs.llvm.org/show_bug.cgi?id=40563#c1
> > >
> > > > The outlined function is not generated for the loop, so there is no 
> > > > problem with the standard compatibility.
> > >
> > > Are you saying that in these cases of `master`, `critical`, `single` 
> > > directives, `CapturedDecl` should **not** have `nothrow` bit set too?
> >
> >
> > This flag just does not matter for them.
>
>
> I'll rephrase:
>  Are you opposed to providing the correct (as per the specification) 
> knowledge that
>  no exception will escape out of these `CapturedDecl`'s, because that 
> knowledge
>  does not matter for the existing sema/codegen, and does not affect produced 
> IR?


Again, CapturedDecl and CapturedStmt is not the representation of the 
structured block. It is a helper structure for the codegen only. This flag does 
not help with anything, because for such OpenMP constructs the codegen bypasses 
CapturedStmt/CapturedDecl.
I'm not opposed. I'm saying, that it is not required and not used. If it is not 
used, why do you want to set it?


Repository:
  rC Clang

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

https://reviews.llvm.org/D57615



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


[PATCH] D57615: [AST][OpenMP] OpenMP master Construct contains Structured block

2019-02-01 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

In D57615#1381418 , @ABataev wrote:

> In D57615#1381416 , @lebedev.ri 
> wrote:
>
> > @ABataev i'm not sure i have fully followed the 
> > https://bugs.llvm.org/show_bug.cgi?id=40563#c1
> >
> > > The outlined function is not generated for the loop, so there is no 
> > > problem with the standard compatibility.
> >
> > Are you saying that in these cases of `master`, `critical`, `single` 
> > directives, `CapturedDecl` should **not** have `nothrow` bit set too?
>
>
> This flag just does not matter for them.


I'll rephrase:
Are you opposed to providing the correct (as per the specification) knowledge 
that
no exception will escape out of these `CapturedDecl`'s, because that knowledge
does not matter for the existing sema/codegen, and does not affect produced IR?


Repository:
  rC Clang

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

https://reviews.llvm.org/D57615



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


r352919 - Don't use ASTContext in DeclOpenMP.h because it's still incomplete.

2019-02-01 Thread Eric Fiselier via cfe-commits
Author: ericwf
Date: Fri Feb  1 13:19:20 2019
New Revision: 352919

URL: http://llvm.org/viewvc/llvm-project?rev=352919=rev
Log:
Don't use ASTContext in DeclOpenMP.h because it's still incomplete.

Modified:
cfe/trunk/include/clang/AST/DeclOpenMP.h
cfe/trunk/lib/AST/DeclOpenMP.cpp

Modified: cfe/trunk/include/clang/AST/DeclOpenMP.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclOpenMP.h?rev=352919=352918=352919=diff
==
--- cfe/trunk/include/clang/AST/DeclOpenMP.h (original)
+++ cfe/trunk/include/clang/AST/DeclOpenMP.h Fri Feb  1 13:19:20 2019
@@ -289,14 +289,8 @@ public:
 
   /// Get reference to previous declare mapper construct in the same
   /// scope with the same name.
-  OMPDeclareMapperDecl *getPrevDeclInScope() {
-return cast_or_null(
-PrevDeclInScope.get(getASTContext().getExternalSource()));
-  }
-  const OMPDeclareMapperDecl *getPrevDeclInScope() const {
-return cast_or_null(
-PrevDeclInScope.get(getASTContext().getExternalSource()));
-  }
+  OMPDeclareMapperDecl *getPrevDeclInScope();
+  const OMPDeclareMapperDecl *getPrevDeclInScope() const;
 
   static bool classof(const Decl *D) { return classofKind(D->getKind()); }
   static bool classofKind(Kind K) { return K == OMPDeclareMapper; }

Modified: cfe/trunk/lib/AST/DeclOpenMP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/DeclOpenMP.cpp?rev=352919=352918=352919=diff
==
--- cfe/trunk/lib/AST/DeclOpenMP.cpp (original)
+++ cfe/trunk/lib/AST/DeclOpenMP.cpp Fri Feb  1 13:19:20 2019
@@ -172,6 +172,16 @@ void OMPDeclareMapperDecl::setClauses(Ar
   std::uninitialized_copy(CL.begin(), CL.end(), Clauses.data());
 }
 
+OMPDeclareMapperDecl *OMPDeclareMapperDecl::getPrevDeclInScope() {
+  return cast_or_null(
+  PrevDeclInScope.get(getASTContext().getExternalSource()));
+}
+
+const OMPDeclareMapperDecl *OMPDeclareMapperDecl::getPrevDeclInScope() const {
+  return cast_or_null(
+  PrevDeclInScope.get(getASTContext().getExternalSource()));
+}
+
 
//===--===//
 // OMPCapturedExprDecl Implementation.
 
//===--===//


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


Re: r352906 - [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive.

2019-02-01 Thread Michael Kruse via cfe-commits
Hi,

I never used modules. Can you give me hint where it exactly breaks? Is
it line 294 and 298 where it calls getExternalSource of ASTContext?

Michael



Am Fr., 1. Feb. 2019 um 12:58 Uhr schrieb Eric Fiselier :
>
> This breaks my build (I have modules enabled).
>
> DeclOpenMP.h uses ASTContext while it's still incomplete.
> Could you please fix this?
>
> /Eric
>
> On Fri, Feb 1, 2019 at 3:24 PM Michael Kruse via cfe-commits 
>  wrote:
>>
>> Author: meinersbur
>> Date: Fri Feb  1 12:25:04 2019
>> New Revision: 352906
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=352906=rev
>> Log:
>> [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive.
>>
>> This patch implements parsing and sema for "omp declare mapper"
>> directive. User defined mapper, i.e., declare mapper directive, is a new
>> feature in OpenMP 5.0. It is introduced to extend existing map clauses
>> for the purpose of simplifying the copy of complex data structures
>> between host and device (i.e., deep copy). An example is shown below:
>>
>> struct S {  int len;  int *d; };
>> #pragma omp declare mapper(struct S s) map(s, s.d[0:s.len]) // Memory 
>> region that d points to is also mapped using this mapper.
>>
>> Contributed-by: Lingda Li 
>>
>> Differential Revision: https://reviews.llvm.org/D56326
>>
>> Added:
>> cfe/trunk/test/OpenMP/declare_mapper_ast_print.c
>> cfe/trunk/test/OpenMP/declare_mapper_ast_print.cpp
>> cfe/trunk/test/OpenMP/declare_mapper_messages.c
>> cfe/trunk/test/OpenMP/declare_mapper_messages.cpp
>> Modified:
>> cfe/trunk/include/clang/AST/DeclBase.h
>> cfe/trunk/include/clang/AST/DeclCXX.h
>> cfe/trunk/include/clang/AST/DeclOpenMP.h
>> cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
>> cfe/trunk/include/clang/Basic/DeclNodes.td
>> cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
>> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>> cfe/trunk/include/clang/Basic/OpenMPKinds.def
>> cfe/trunk/include/clang/Parse/Parser.h
>> cfe/trunk/include/clang/Sema/Sema.h
>> cfe/trunk/include/clang/Serialization/ASTBitCodes.h
>> cfe/trunk/lib/AST/ASTDumper.cpp
>> cfe/trunk/lib/AST/CXXInheritance.cpp
>> cfe/trunk/lib/AST/DeclBase.cpp
>> cfe/trunk/lib/AST/DeclOpenMP.cpp
>> cfe/trunk/lib/AST/DeclPrinter.cpp
>> cfe/trunk/lib/AST/ItaniumMangle.cpp
>> cfe/trunk/lib/AST/MicrosoftMangle.cpp
>> cfe/trunk/lib/Basic/OpenMPKinds.cpp
>> cfe/trunk/lib/CodeGen/CGDecl.cpp
>> cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
>> cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
>> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
>> cfe/trunk/lib/CodeGen/CodeGenModule.h
>> cfe/trunk/lib/Parse/ParseOpenMP.cpp
>> cfe/trunk/lib/Sema/SemaDecl.cpp
>> cfe/trunk/lib/Sema/SemaExpr.cpp
>> cfe/trunk/lib/Sema/SemaLookup.cpp
>> cfe/trunk/lib/Sema/SemaOpenMP.cpp
>> cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
>> cfe/trunk/lib/Serialization/ASTCommon.cpp
>> cfe/trunk/lib/Serialization/ASTReader.cpp
>> cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
>> cfe/trunk/lib/Serialization/ASTWriterDecl.cpp
>> cfe/trunk/tools/libclang/CIndex.cpp
>>
>> Modified: cfe/trunk/include/clang/AST/DeclBase.h
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclBase.h?rev=352906=352905=352906=diff
>> ==
>> --- cfe/trunk/include/clang/AST/DeclBase.h (original)
>> +++ cfe/trunk/include/clang/AST/DeclBase.h Fri Feb  1 12:25:04 2019
>> @@ -175,7 +175,10 @@ public:
>>  IDNS_LocalExtern = 0x0800,
>>
>>  /// This declaration is an OpenMP user defined reduction construction.
>> -IDNS_OMPReduction= 0x1000
>> +IDNS_OMPReduction= 0x1000,
>> +
>> +/// This declaration is an OpenMP user defined mapper.
>> +IDNS_OMPMapper   = 0x2000,
>>};
>>
>>/// ObjCDeclQualifier - 'Qualifiers' written next to the return and
>> @@ -323,7 +326,7 @@ protected:
>>unsigned FromASTFile : 1;
>>
>>/// IdentifierNamespace - This specifies what IDNS_* namespace this lives 
>> in.
>> -  unsigned IdentifierNamespace : 13;
>> +  unsigned IdentifierNamespace : 14;
>>
>>/// If 0, we have not computed the linkage of this declaration.
>>/// Otherwise, it is the linkage + 1.
>> @@ -1251,6 +1254,7 @@ public:
>>  ///   NamespaceDecl
>>  ///   TagDecl
>>  ///   OMPDeclareReductionDecl
>> +///   OMPDeclareMapperDecl
>>  ///   FunctionDecl
>>  ///   ObjCMethodDecl
>>  ///   ObjCContainerDecl
>>
>> Modified: cfe/trunk/include/clang/AST/DeclCXX.h
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclCXX.h?rev=352906=352905=352906=diff
>> ==
>> --- cfe/trunk/include/clang/AST/DeclCXX.h (original)
>> +++ cfe/trunk/include/clang/AST/DeclCXX.h Fri Feb  1 12:25:04 2019
>> @@ -1828,6 +1828,14 

[PATCH] D57615: [AST][OpenMP] OpenMP master Construct contains Structured block

2019-02-01 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

In D57615#1381416 , @lebedev.ri wrote:

> @ABataev i'm not sure i have fully followed the 
> https://bugs.llvm.org/show_bug.cgi?id=40563#c1
>
> > The outlined function is not generated for the loop, so there is no problem 
> > with the standard compatibility.
>
> Are you saying that in these cases of `master`, `critical`, `single` 
> directives, `CapturedDecl` should **not** have `nothrow` bit set too?


This flag just does not matter for them.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57615



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


[PATCH] D57615: [AST][OpenMP] OpenMP master Construct contains Structured block

2019-02-01 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

@ABataev i'm not sure i have fully followed the 
https://bugs.llvm.org/show_bug.cgi?id=40563#c1

> The outlined function is not generated for the loop, so there is no problem 
> with the standard compatibility.

Are you saying that in these cases of `master`, `critical`, `single` 
directives, `CapturedDecl` should **not** have `nothrow` bit set too?


Repository:
  rC Clang

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

https://reviews.llvm.org/D57615



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


[PATCH] D57615: [AST][OpenMP] OpenMP master Construct contains Structured block

2019-02-01 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added inline comments.



Comment at: lib/Sema/SemaOpenMP.cpp:6058
+  // longjmp() and throw() must not violate the entry/exit criteria.
+  cast(AStmt)->getCapturedDecl()->setNothrow();
+

Generally speaking, this is not required. It is required only for those 
constructs, that really needs an outlined function. Master construct does not 
create outlined function, so the "nothrow" flag is useless here.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57615



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


[PATCH] D57615: [AST][OpenMP] OpenMP master Construct contains Structured block

2019-02-01 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri created this revision.
lebedev.ri added reviewers: ABataev, OpenMP.
lebedev.ri added projects: clang, OpenMP.
Herald added subscribers: openmp-commits, guansong.

Much like `single` construct (D57594 ):

`OpenMP Application Programming Interface Version 5.0 November 2018` 
, 
`2.16 master Construct`, starting with page 221:

- The `master` construct specifies a **structured block** that is executed by 
the master thread of the team.
- Restrictions • A throw executed inside a `master` region must cause execution 
to resume within the same `master` region, and the same thread that threw the 
exception must catch it


Repository:
  rC Clang

https://reviews.llvm.org/D57615

Files:
  lib/Sema/SemaOpenMP.cpp
  test/AST/ast-dump-openmp-master.cpp


Index: test/AST/ast-dump-openmp-master.cpp
===
--- /dev/null
+++ test/AST/ast-dump-openmp-master.cpp
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -verify -fopenmp -ast-dump %s | FileCheck %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -ast-dump %s | FileCheck %s
+// expected-no-diagnostics
+
+void master() {
+#pragma omp master
+  {
+  }
+}
+
+// CHECK: `-FunctionDecl
+// CHECK-NEXT:   `-CompoundStmt
+// CHECK-NEXT: `-OMPMasterDirective
+// CHECK-NEXT:   `-CapturedStmt
+// CHECK-NEXT: `-CapturedDecl {{.*}} nothrow
+// CHECK-NEXT:   |-CompoundStmt
+// CHECK-NEXT:   `-ImplicitParamDecl
Index: lib/Sema/SemaOpenMP.cpp
===
--- lib/Sema/SemaOpenMP.cpp
+++ lib/Sema/SemaOpenMP.cpp
@@ -6050,6 +6050,13 @@
 
   assert(isa(AStmt) && "Captured statement expected");
 
+  // 1.2.2 OpenMP Language Terminology
+  // Structured block - An executable statement with a single entry at the
+  // top and a single exit at the bottom.
+  // The point of exit cannot be a branch out of the structured block.
+  // longjmp() and throw() must not violate the entry/exit criteria.
+  cast(AStmt)->getCapturedDecl()->setNothrow();
+
   setFunctionHasBranchProtectedScope();
 
   return OMPMasterDirective::Create(Context, StartLoc, EndLoc, AStmt);


Index: test/AST/ast-dump-openmp-master.cpp
===
--- /dev/null
+++ test/AST/ast-dump-openmp-master.cpp
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -verify -fopenmp -ast-dump %s | FileCheck %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -ast-dump %s | FileCheck %s
+// expected-no-diagnostics
+
+void master() {
+#pragma omp master
+  {
+  }
+}
+
+// CHECK: `-FunctionDecl
+// CHECK-NEXT:   `-CompoundStmt
+// CHECK-NEXT: `-OMPMasterDirective
+// CHECK-NEXT:   `-CapturedStmt
+// CHECK-NEXT: `-CapturedDecl {{.*}} nothrow
+// CHECK-NEXT:   |-CompoundStmt
+// CHECK-NEXT:   `-ImplicitParamDecl
Index: lib/Sema/SemaOpenMP.cpp
===
--- lib/Sema/SemaOpenMP.cpp
+++ lib/Sema/SemaOpenMP.cpp
@@ -6050,6 +6050,13 @@
 
   assert(isa(AStmt) && "Captured statement expected");
 
+  // 1.2.2 OpenMP Language Terminology
+  // Structured block - An executable statement with a single entry at the
+  // top and a single exit at the bottom.
+  // The point of exit cannot be a branch out of the structured block.
+  // longjmp() and throw() must not violate the entry/exit criteria.
+  cast(AStmt)->getCapturedDecl()->setNothrow();
+
   setFunctionHasBranchProtectedScope();
 
   return OMPMasterDirective::Create(Context, StartLoc, EndLoc, AStmt);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


LLVM buildmaster will be restarted tonight

2019-02-01 Thread Galina Kistanova via cfe-commits
 Hello everyone,

LLVM buildmaster will be updated and restarted after 6PM Pacific time today.

Thanks

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


[PATCH] D56326: [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive

2019-02-01 Thread Michael Kruse via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rC352906: [OpenMP 5.0] Parsing/sema support for omp 
declare mapper directive. (authored by Meinersbur, committed by ).
Herald added a project: clang.

Repository:
  rC Clang

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

https://reviews.llvm.org/D56326

Files:
  include/clang/AST/DeclBase.h
  include/clang/AST/DeclCXX.h
  include/clang/AST/DeclOpenMP.h
  include/clang/AST/RecursiveASTVisitor.h
  include/clang/Basic/DeclNodes.td
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/OpenMPKinds.def
  include/clang/Parse/Parser.h
  include/clang/Sema/Sema.h
  include/clang/Serialization/ASTBitCodes.h
  lib/AST/ASTDumper.cpp
  lib/AST/CXXInheritance.cpp
  lib/AST/DeclBase.cpp
  lib/AST/DeclOpenMP.cpp
  lib/AST/DeclPrinter.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/MicrosoftMangle.cpp
  lib/Basic/OpenMPKinds.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/CodeGen/CodeGenModule.h
  lib/Parse/ParseOpenMP.cpp
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaLookup.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  lib/Serialization/ASTCommon.cpp
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTReaderDecl.cpp
  lib/Serialization/ASTWriterDecl.cpp
  test/OpenMP/declare_mapper_ast_print.c
  test/OpenMP/declare_mapper_ast_print.cpp
  test/OpenMP/declare_mapper_messages.c
  test/OpenMP/declare_mapper_messages.cpp
  tools/libclang/CIndex.cpp

Index: include/clang/AST/DeclOpenMP.h
===
--- include/clang/AST/DeclOpenMP.h
+++ include/clang/AST/DeclOpenMP.h
@@ -206,6 +206,108 @@
   }
 };
 
+/// This represents '#pragma omp declare mapper ...' directive. Map clauses are
+/// allowed to use with this directive. The following example declares a user
+/// defined mapper for the type 'struct vec'. This example instructs the fields
+/// 'len' and 'data' should be mapped when mapping instances of 'struct vec'.
+///
+/// \code
+/// #pragma omp declare mapper(mid: struct vec v) map(v.len, v.data[0:N])
+/// \endcode
+class OMPDeclareMapperDecl final : public ValueDecl, public DeclContext {
+  friend class ASTDeclReader;
+
+  /// Clauses assoicated with this mapper declaration
+  MutableArrayRef Clauses;
+
+  /// Mapper variable, which is 'v' in the example above
+  Expr *MapperVarRef = nullptr;
+
+  /// Name of the mapper variable
+  DeclarationName VarName;
+
+  LazyDeclPtr PrevDeclInScope;
+
+  virtual void anchor();
+
+  OMPDeclareMapperDecl(Kind DK, DeclContext *DC, SourceLocation L,
+   DeclarationName Name, QualType Ty,
+   DeclarationName VarName,
+   OMPDeclareMapperDecl *PrevDeclInScope)
+  : ValueDecl(DK, DC, L, Name, Ty), DeclContext(DK), VarName(VarName),
+PrevDeclInScope(PrevDeclInScope) {}
+
+  void setPrevDeclInScope(OMPDeclareMapperDecl *Prev) {
+PrevDeclInScope = Prev;
+  }
+
+  /// Sets an array of clauses to this mapper declaration
+  void setClauses(ArrayRef CL);
+
+public:
+  /// Creates declare mapper node.
+  static OMPDeclareMapperDecl *Create(ASTContext , DeclContext *DC,
+  SourceLocation L, DeclarationName Name,
+  QualType T, DeclarationName VarName,
+  OMPDeclareMapperDecl *PrevDeclInScope);
+  /// Creates deserialized declare mapper node.
+  static OMPDeclareMapperDecl *CreateDeserialized(ASTContext , unsigned ID,
+  unsigned N);
+
+  /// Creates an array of clauses to this mapper declaration and intializes
+  /// them.
+  void CreateClauses(ASTContext , ArrayRef CL);
+
+  using clauselist_iterator = MutableArrayRef::iterator;
+  using clauselist_const_iterator = ArrayRef::iterator;
+  using clauselist_range = llvm::iterator_range;
+  using clauselist_const_range =
+  llvm::iterator_range;
+
+  unsigned clauselist_size() const { return Clauses.size(); }
+  bool clauselist_empty() const { return Clauses.empty(); }
+
+  clauselist_range clauselists() {
+return clauselist_range(clauselist_begin(), clauselist_end());
+  }
+  clauselist_const_range clauselists() const {
+return clauselist_const_range(clauselist_begin(), clauselist_end());
+  }
+  clauselist_iterator clauselist_begin() { return Clauses.begin(); }
+  clauselist_iterator clauselist_end() { return Clauses.end(); }
+  clauselist_const_iterator clauselist_begin() const { return Clauses.begin(); }
+  clauselist_const_iterator clauselist_end() const { return Clauses.end(); }
+
+  /// Get the variable declared in the mapper
+  Expr *getMapperVarRef() { return MapperVarRef; }
+  const Expr *getMapperVarRef() const { return MapperVarRef; }
+  /// 

r352906 - [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive.

2019-02-01 Thread Michael Kruse via cfe-commits
Author: meinersbur
Date: Fri Feb  1 12:25:04 2019
New Revision: 352906

URL: http://llvm.org/viewvc/llvm-project?rev=352906=rev
Log:
[OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive.

This patch implements parsing and sema for "omp declare mapper"
directive. User defined mapper, i.e., declare mapper directive, is a new
feature in OpenMP 5.0. It is introduced to extend existing map clauses
for the purpose of simplifying the copy of complex data structures
between host and device (i.e., deep copy). An example is shown below:

struct S {  int len;  int *d; };
#pragma omp declare mapper(struct S s) map(s, s.d[0:s.len]) // Memory 
region that d points to is also mapped using this mapper.

Contributed-by: Lingda Li 

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

Added:
cfe/trunk/test/OpenMP/declare_mapper_ast_print.c
cfe/trunk/test/OpenMP/declare_mapper_ast_print.cpp
cfe/trunk/test/OpenMP/declare_mapper_messages.c
cfe/trunk/test/OpenMP/declare_mapper_messages.cpp
Modified:
cfe/trunk/include/clang/AST/DeclBase.h
cfe/trunk/include/clang/AST/DeclCXX.h
cfe/trunk/include/clang/AST/DeclOpenMP.h
cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
cfe/trunk/include/clang/Basic/DeclNodes.td
cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/include/clang/Basic/OpenMPKinds.def
cfe/trunk/include/clang/Parse/Parser.h
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/include/clang/Serialization/ASTBitCodes.h
cfe/trunk/lib/AST/ASTDumper.cpp
cfe/trunk/lib/AST/CXXInheritance.cpp
cfe/trunk/lib/AST/DeclBase.cpp
cfe/trunk/lib/AST/DeclOpenMP.cpp
cfe/trunk/lib/AST/DeclPrinter.cpp
cfe/trunk/lib/AST/ItaniumMangle.cpp
cfe/trunk/lib/AST/MicrosoftMangle.cpp
cfe/trunk/lib/Basic/OpenMPKinds.cpp
cfe/trunk/lib/CodeGen/CGDecl.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.h
cfe/trunk/lib/Parse/ParseOpenMP.cpp
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/lib/Sema/SemaExpr.cpp
cfe/trunk/lib/Sema/SemaLookup.cpp
cfe/trunk/lib/Sema/SemaOpenMP.cpp
cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
cfe/trunk/lib/Serialization/ASTCommon.cpp
cfe/trunk/lib/Serialization/ASTReader.cpp
cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
cfe/trunk/lib/Serialization/ASTWriterDecl.cpp
cfe/trunk/tools/libclang/CIndex.cpp

Modified: cfe/trunk/include/clang/AST/DeclBase.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclBase.h?rev=352906=352905=352906=diff
==
--- cfe/trunk/include/clang/AST/DeclBase.h (original)
+++ cfe/trunk/include/clang/AST/DeclBase.h Fri Feb  1 12:25:04 2019
@@ -175,7 +175,10 @@ public:
 IDNS_LocalExtern = 0x0800,
 
 /// This declaration is an OpenMP user defined reduction construction.
-IDNS_OMPReduction= 0x1000
+IDNS_OMPReduction= 0x1000,
+
+/// This declaration is an OpenMP user defined mapper.
+IDNS_OMPMapper   = 0x2000,
   };
 
   /// ObjCDeclQualifier - 'Qualifiers' written next to the return and
@@ -323,7 +326,7 @@ protected:
   unsigned FromASTFile : 1;
 
   /// IdentifierNamespace - This specifies what IDNS_* namespace this lives in.
-  unsigned IdentifierNamespace : 13;
+  unsigned IdentifierNamespace : 14;
 
   /// If 0, we have not computed the linkage of this declaration.
   /// Otherwise, it is the linkage + 1.
@@ -1251,6 +1254,7 @@ public:
 ///   NamespaceDecl
 ///   TagDecl
 ///   OMPDeclareReductionDecl
+///   OMPDeclareMapperDecl
 ///   FunctionDecl
 ///   ObjCMethodDecl
 ///   ObjCContainerDecl

Modified: cfe/trunk/include/clang/AST/DeclCXX.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclCXX.h?rev=352906=352905=352906=diff
==
--- cfe/trunk/include/clang/AST/DeclCXX.h (original)
+++ cfe/trunk/include/clang/AST/DeclCXX.h Fri Feb  1 12:25:04 2019
@@ -1828,6 +1828,14 @@ public:
  CXXBasePath , DeclarationName Name);
 
   /// Base-class lookup callback that determines whether there exists
+  /// an OpenMP declare mapper member with the given name.
+  ///
+  /// This callback can be used with \c lookupInBases() to find members
+  /// of the given name within a C++ class hierarchy.
+  static bool FindOMPMapperMember(const CXXBaseSpecifier *Specifier,
+  CXXBasePath , DeclarationName Name);
+
+  /// Base-class lookup callback that determines whether there exists
   /// a member with the given name that can be used in a nested-name-specifier.
   ///
   /// This callback can be used with \c lookupInBases() to find members of

Modified: 

[PATCH] D56326: [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive

2019-02-01 Thread Lingda Li via Phabricator via cfe-commits
lildmh added a comment.

In D56326#1381229 , @Meinersbur wrote:

> @lildmh Thanks for the patch. I can commit this patch for you. The tests run 
> fine on my machine. However, for committing on other's behalf, we were asked 
> to make the contributor aware that the contribution will be published under a 
> new license 
> .
>  Are you OK with the new license?


Thanks a lot Michael! I'm fine with the license.


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

https://reviews.llvm.org/D56326



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


[PATCH] D56326: [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive

2019-02-01 Thread Michael Kruse via Phabricator via cfe-commits
Meinersbur added a comment.

@lildmh Thanks for the patch. I can commit this patch for you. The tests run 
fine on my machine. However, for committing on other's behalf, we were asked to 
make the contributor aware that the contribution will be published under a new 
license 
.
 Are you OK with the new license?


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

https://reviews.llvm.org/D56326



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


[PATCH] D57472: [AST] Extract ASTDumpTraverser class from ASTDumper

2019-02-01 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: include/clang/AST/ASTDumpTraverser.h:1
+//===--- ASTDumpTraverser.h - Traversal of AST nodes 
--===//
+//

steveire wrote:
> I think I'll rename this to `ASTNodeTraverser`. Any objections?
Nope, I think that's a good idea.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57472



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


[PATCH] D57472: [AST] Extract ASTDumpTraverser class from ASTDumper

2019-02-01 Thread Stephen Kelly via Phabricator via cfe-commits
steveire marked an inline comment as done.
steveire added inline comments.



Comment at: include/clang/AST/ASTDumpTraverser.h:1
+//===--- ASTDumpTraverser.h - Traversal of AST nodes 
--===//
+//

I think I'll rename this to `ASTNodeTraverser`. Any objections?


Repository:
  rC Clang

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

https://reviews.llvm.org/D57472



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


Re: r352055 - Fix failing buildbots

2019-02-01 Thread Gábor Márton via cfe-commits
Dave,

The idea to check explicitly the triple inside the test function is quite
convincing. Will you try to fix it that way? Or if it can wait a bit, this
will be my first thing to do on Monday.

Gábor

On Fri, 1 Feb 2019, 19:39 David Green  Hello
>
>
> I think, because this is a unit-test, the compile will happen for the host
> (x86_64 in this case). So the binary will still be x86_64.
>
>
> The compile that the test runs will pick up whatever the default target
> triple is (hexagon for the bot, aarch64 for us). I don't know a lot about
> these tests, but I presume that somewhere deep within testStructuralMatch
> or makeNamedDecls it will be picking this up and we can override it?
>
>
> ..
>
>
> Looking at it now, I think the Args to buildASTFromCodeWithArgs will
> allow specific targets to be used. I'm not sure the best way to get that
> information through to there, but something like this would work:
>
>
> diff --git a/unittests/AST/StructuralEquivalenceTest.cpp
> b/unittests/AST/StructuralEquivalenceTest.c
> index e6c289a..52dba5e 100644
> --- a/unittests/AST/StructuralEquivalenceTest.cpp
> +++ b/unittests/AST/StructuralEquivalenceTest.cpp
> @@ -28,6 +28,7 @@ struct StructuralEquivalenceTest : ::testing::Test {
>  this->Code0 = SrcCode0;
>  this->Code1 = SrcCode1;
>  ArgVector Args = getBasicRunOptionsForLanguage(Lang);
> +Args.push_back("--target=x86_64-unknown-linux-gnu");
>
>  const char *const InputFileName = "input.cc";
>
>
> I wouldn't recommend that, exactly, it would needlessly reduce the testing
> on other targets. And I think for the hexagon target the x86 backend will
> not even be registered I believe. Perhaps just something like this from
> another ASTMatchesNode test, to try and capture the same intent as the
> ifdefs:
>
> TEST_F(StructuralEquivalenceFunctionTest,
> FunctionsWithDifferentSavedRegsAttr) {
>
>   if (llvm::Triple(llvm::sys::getDefaultTargetTriple()).getArch() !=
> llvm::Triple::x86_64)
> return;
>   ...
>
>
> Dave
>
>
>
> > Hi,
> >
> > Thank you for catching this. I thought that the macros like __x86_64__
> are defined for the target. I just don't understand: If they are defined
> for the host, > that would mean we can't cross compile on the same host
> for different targets, wouldn't it?
> >
> > I couldn't find out which macros to use to get the target arch, so I
> see 2 possible solutions :
> > 1. Create a new test binary for these two small tests and specify
> explicitly the target. This seems overwhelming.
> > 2. Simply remove those two test cases. This seems to be the simplest
> solution.
> >
> > Gábor
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D57532: [Index] Make sure c-index-test finds libc++ on Mac

2019-02-01 Thread Alex Lorenz via Phabricator via cfe-commits
arphaman added a comment.

In D57532#1380383 , @ilya-biryukov 
wrote:

> @arphaman, thanks for pointing this out. It's definitely nice to change stuff 
> only in one place.
>  There are two issues still pending:
>
> - `index-file.cu` still fails, I haven't looked into it closely yet, any idea 
> why that might be happening?; repro is simple, just patch this in locally and 
> run the test.


No idea why it fails, I'll try to take a look.

> - I'm not sure it's safe to use temporary storage for `argv[0]` in 
> `clang_parseTranslationUnit2`. The resulting translation units probably holds 
> references to `argv` and is free to read the data later. A simple and safe 
> alternative would be to store this string in `CIndexer` and return a 
> reference here. Does that LG?

Yes, that would be better. Let's store the string in CIndexer like we do for 
toolchain path and the resource dir.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D57532



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


[PATCH] D35937: [clang-tidy] Add new readability non-idiomatic static access

2019-02-01 Thread Eugene Zelenko via Phabricator via cfe-commits
Eugene.Zelenko added a comment.
Herald added subscribers: dkrupp, rnkovacs.
Herald added a project: LLVM.

Please look at recently filed PR40544.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D35937



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


[PATCH] D57592: Replace uses of %T with %t in from previous frontend test differential

2019-02-01 Thread Justice Adams via Phabricator via cfe-commits
justice_adams added a comment.

@thakis thanks for the review. I don't have commit access, would you mind 
committing this for me?


Repository:
  rC Clang

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

https://reviews.llvm.org/D57592



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


Re: r352055 - Fix failing buildbots

2019-02-01 Thread David Green via cfe-commits
Hello


I think, because this is a unit-test, the compile will happen for the host 
(x86_64 in this case). So the binary will still be x86_64.


The compile that the test runs will pick up whatever the default target triple 
is (hexagon for the bot, aarch64 for us). I don't know a lot about these tests, 
but I presume that somewhere deep within testStructuralMatch or makeNamedDecls 
it will be picking this up and we can override it?


..


Looking at it now, I think the Args to buildASTFromCodeWithArgs will allow 
specific targets to be used. I'm not sure the best way to get that information 
through to there, but something like this would work:


diff --git a/unittests/AST/StructuralEquivalenceTest.cpp 
b/unittests/AST/StructuralEquivalenceTest.c
index e6c289a..52dba5e 100644
--- a/unittests/AST/StructuralEquivalenceTest.cpp
+++ b/unittests/AST/StructuralEquivalenceTest.cpp
@@ -28,6 +28,7 @@ struct StructuralEquivalenceTest : ::testing::Test {
 this->Code0 = SrcCode0;
 this->Code1 = SrcCode1;
 ArgVector Args = getBasicRunOptionsForLanguage(Lang);
+Args.push_back("--target=x86_64-unknown-linux-gnu");

 const char *const InputFileName = "input.cc";


I wouldn't recommend that, exactly, it would needlessly reduce the testing on 
other targets. And I think for the hexagon target the x86 backend will not even 
be registered I believe. Perhaps just something like this from another 
ASTMatchesNode test, to try and capture the same intent as the ifdefs:


TEST_F(StructuralEquivalenceFunctionTest, FunctionsWithDifferentSavedRegsAttr) {

  if (llvm::Triple(llvm::sys::getDefaultTargetTriple()).getArch() != 
llvm::Triple::x86_64)
return;
  ...


Dave



> Hi,
>
> Thank you for catching this. I thought that the macros like __x86_64__ are 
> defined for the target. I just don't understand: If they are defined for the 
> host, > that would mean we can't cross compile on the same host for different 
> targets, wouldn't it?
>
> I couldn't find out which macros to use to get the target arch, so I see 2 
> possible solutions :
> 1. Create a new test binary for these two small tests and specify explicitly 
> the target. This seems overwhelming.
> 2. Simply remove those two test cases. This seems to be the simplest solution.
>
> Gábor

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


[PATCH] D57265: [PM/CC1] Add -f[no-]split-cold-code CC1 options to toggle splitting

2019-02-01 Thread Vedant Kumar via Phabricator via cfe-commits
vsk added a comment.

Ping.


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

https://reviews.llvm.org/D57265



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


[PATCH] D46421: [analyzer][CrossTU] Extend CTU to VarDecls with initializer

2019-02-01 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.

> Previously this was not required since all VarDecls were canonical. Not sure 
> if this change was intended. I did some digging, but am not familiar enough 
> with the code base to figure out what changed. Does anyone have an idea about 
> this?

We changed the ASTImporter a few months ago to import the redecl chains 
properly. That means we do not squash ever decl into one decl. Also we link a 
newly imported decl to an already existing (found by the lookup). We allow only 
one definition of course. In case of variables we allow only one initializer. 
This way we can preserve the original structure of the AST in the most precise 
way.
I don't think this could be a problem, since we may have redecl chains of 
variables (and other kind of decls) in a single TU too.


Repository:
  rC Clang

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

https://reviews.llvm.org/D46421



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


[PATCH] D57594: [AST][OpenMP] OpenMP single Construct contains Structured block

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

LG


Repository:
  rC Clang

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

https://reviews.llvm.org/D57594



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


[PATCH] D16951: [MS ABI] dllimport'd class cannot have constexpr ctors

2019-02-01 Thread Nico Weber via Phabricator via cfe-commits
thakis closed this revision.
thakis added a comment.

David landed a better fix in r260388.


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

https://reviews.llvm.org/D16951



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


[PATCH] D57594: [AST][OpenMP] OpenMP single Construct contains Structured block

2019-02-01 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri created this revision.
lebedev.ri added reviewers: ABataev, OpenMP.
lebedev.ri added projects: clang, OpenMP.
Herald added subscribers: openmp-commits, guansong.

`OpenMP Application Programming Interface Version 5.0 November 2018` 
, 
`2.8.2 single Construct`, starting with page 89:

- The `single` construct specifies that the associated **structured block** is 
executed by only one of the threads in the team (not necessarily the master 
thread), in the context of its implicit task.
- Restrictions • A throw executed inside a `single` region must cause execution 
to resume within the same `single` region, and the same thread that threw the 
exception must catch it.


Repository:
  rC Clang

https://reviews.llvm.org/D57594

Files:
  lib/Sema/SemaOpenMP.cpp
  test/AST/ast-dump-openmp-single.cpp


Index: test/AST/ast-dump-openmp-single.cpp
===
--- /dev/null
+++ test/AST/ast-dump-openmp-single.cpp
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -verify -fopenmp -ast-dump %s | FileCheck %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -ast-dump %s | FileCheck %s
+// expected-no-diagnostics
+
+void single() {
+#pragma omp single
+  {
+  }
+}
+
+// CHECK:`-FunctionDecl
+// CHECK-NEXT:  `-CompoundStmt
+// CHECK-NEXT:`-OMPSingleDirective
+// CHECK-NEXT:  `-CapturedStmt
+// CHECK-NEXT:`-CapturedDecl {{.*}} nothrow
+// CHECK-NEXT:  |-CompoundStmt
+// CHECK-NEXT:  `-ImplicitParamDecl
Index: lib/Sema/SemaOpenMP.cpp
===
--- lib/Sema/SemaOpenMP.cpp
+++ lib/Sema/SemaOpenMP.cpp
@@ -6013,6 +6013,13 @@
 
   assert(isa(AStmt) && "Captured statement expected");
 
+  // 1.2.2 OpenMP Language Terminology
+  // Structured block - An executable statement with a single entry at the
+  // top and a single exit at the bottom.
+  // The point of exit cannot be a branch out of the structured block.
+  // longjmp() and throw() must not violate the entry/exit criteria.
+  cast(AStmt)->getCapturedDecl()->setNothrow();
+
   setFunctionHasBranchProtectedScope();
 
   // OpenMP [2.7.3, single Construct, Restrictions]


Index: test/AST/ast-dump-openmp-single.cpp
===
--- /dev/null
+++ test/AST/ast-dump-openmp-single.cpp
@@ -0,0 +1,17 @@
+// RUN: %clang_cc1 -verify -fopenmp -ast-dump %s | FileCheck %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -ast-dump %s | FileCheck %s
+// expected-no-diagnostics
+
+void single() {
+#pragma omp single
+  {
+  }
+}
+
+// CHECK:`-FunctionDecl
+// CHECK-NEXT:  `-CompoundStmt
+// CHECK-NEXT:`-OMPSingleDirective
+// CHECK-NEXT:  `-CapturedStmt
+// CHECK-NEXT:`-CapturedDecl {{.*}} nothrow
+// CHECK-NEXT:  |-CompoundStmt
+// CHECK-NEXT:  `-ImplicitParamDecl
Index: lib/Sema/SemaOpenMP.cpp
===
--- lib/Sema/SemaOpenMP.cpp
+++ lib/Sema/SemaOpenMP.cpp
@@ -6013,6 +6013,13 @@
 
   assert(isa(AStmt) && "Captured statement expected");
 
+  // 1.2.2 OpenMP Language Terminology
+  // Structured block - An executable statement with a single entry at the
+  // top and a single exit at the bottom.
+  // The point of exit cannot be a branch out of the structured block.
+  // longjmp() and throw() must not violate the entry/exit criteria.
+  cast(AStmt)->getCapturedDecl()->setNothrow();
+
   setFunctionHasBranchProtectedScope();
 
   // OpenMP [2.7.3, single Construct, Restrictions]
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D57592: Replace uses of %T with %t in from previous frontend test differential

2019-02-01 Thread Nico Weber via Phabricator via cfe-commits
thakis accepted this revision.
thakis added a comment.
This revision is now accepted and ready to land.

Normally when needing a directory you'd `mkdir %t.dir` before using it, but 
since you don't' want the directory to exist here this should be good as-is. 
Thanks!


Repository:
  rC Clang

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

https://reviews.llvm.org/D57592



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


[PATCH] D57464: Generalize method overloading on addr spaces to C++

2019-02-01 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: test/SemaCXX/address-space-method-overloading.cpp:28
+   //inas4.bar();
+   noas.bar(); // expected-error{{call to member function 'bar' is ambiguous}}
+}

ebevhan wrote:
> Anastasia wrote:
> > ebevhan wrote:
> > > Just as an aside (I think I mentioned this on one of the earlier patches 
> > > as well); treating a non-AS-qualified object as being in a 'generic' AS 
> > > even for normal C++ isn't a great idea IMO. The object initialization 
> > > code should be checking if the ASes of the actual object and the desired 
> > > object type are compatible, and only if so, permit the overload.
> > I think changing this would require changing AS compatibility rules in 
> > general, not just for overloading but for example for conversions too. This 
> > seems like a wider scope change that might affect backwards compatibility. 
> > We might need to start an RFC on this first. John has suggested adding a 
> > target setting  for this on the other review. I think that should work.  
> > Another idea could be to add some compiler directives to specify what 
> > generic address space is (if any).
> > 
> > Using default (no address space) as generic has a lot of advantages since 
> > it doesn't need many parser changes. In OpenCL we weren't lucky that 
> > initial implementation was added that used default for private memory and 
> > therefore when generic was introduced we had to map it to a new lang addr 
> > space value. That required a lot of changes in the parser. But once we fix 
> > those actually, anyone should be able  to map generic to anything. I 
> > initially thought it has no other use cases than in OpenCL but now I feel 
> > there might be a value to map default case (no address space) for something 
> > specific and then use generic to specify a placeholder address space on 
> > pointers or references. We could just expose generic address space 
> > generically and also have a mode with no generic address space. The latter 
> > means that conversions between different address spaces is never valid. 
> > Would this make sense?
> The big problem with the address space support in Clang is that it isn't 
> really very well formalized unless you're on OpenCL. There's no real way for 
> a target to express the relations between its address spaces; most of the 
> relations that exist are hard-coded.
> 
> The support should probably be generalized for both targets and for LangASes 
> like OpenCL's. Maybe:
> 
> * the ASes would be defined in a TableGen file which specifies which ASes 
> exist, which ones are compatible/subsets/supersets, etc,
> * or, just have a target hook that lets a target express that a conversion 
> from AS A to AS B is prohibited/permitted explicitly/permitted implicitly.
> 
> Just some loose ideas; an RFC for this is possibly the right way forward.
> 
> The reason I bring all of this up is primarily because in our target, the 
> 'default' AS is disjoint from our other ones, so there's no 'generic' AS to 
> be had. Both implicit and explicit conversion between these ASes is 
> prohibited.  Since Clang currently doesn't allow you to express that ASes are 
> truly incompatible, we have a flag that blocks such conversions 
> unconditionally. Ideally it would be target-expressible.
> 
> -
> 
> > I think changing this would require changing AS compatibility rules in 
> > general, not just for overloading but for example for conversions too. This 
> > seems like a wider scope change that might affect backwards compatibility. 
> > We might need to start an RFC on this first. John has suggested adding a 
> > target setting for this on the other review. I think that should work. 
> > Another idea could be to add some compiler directives to specify what 
> > generic address space is (if any).
> 
> I'm unsure whether any changes to the current semantics really need to be 
> done, at least for the overloading problem.
> 
> For example, explicit conversion from a non-address space qualified pointer 
> type to an address space qualified pointer type (and vice versa) is 
> permitted, but implicit conversion is an error in both C and C++: 
> https://godbolt.org/z/UhOC0g
> 
> For an overload candidate to be viable, there has to be an implicit 
> conversion sequence for the implicit object argument to the implicit object 
> parameter type. But no such implicit conversion sequence exists for types in 
> different ASes, even today, or the implicit example in the godbolt would 
> pass. So, an overload candidate with a different AS qualification than the 
> object should not be viable.
> 
> This is clearly not compatible with OpenCL's notion of the `__generic` AS, 
> but OpenCL already has logic for `__generic` in Qualifiers to handle that 
> case (`isAddressSpaceSupersetOf`). Arguably, that behavior should probably 
> not be hard coded, but that's how it is today.
> 
> (Also, just because an AS is a superset of another AS does 

[PATCH] D57592: Replace uses of %T with %t in from previous frontend test differential

2019-02-01 Thread Justice Adams via Phabricator via cfe-commits
justice_adams added a comment.

@stella.stamenova These are the changes from our previous discussion regarding 
the usage of %T


Repository:
  rC Clang

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

https://reviews.llvm.org/D57592



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


r352890 - Update SanitizerCoverage doc regarding the issue with pc-table and gc-sections.

2019-02-01 Thread Max Moroz via cfe-commits
Author: dor1s
Date: Fri Feb  1 09:12:35 2019
New Revision: 352890

URL: http://llvm.org/viewvc/llvm-project?rev=352890=rev
Log:
Update SanitizerCoverage doc regarding the issue with pc-table and gc-sections.

Summary:
There is a bug for this: https://bugs.llvm.org/show_bug.cgi?id=34636
But it would be also helpful to leave a note in the docs to prevent users from
running into issues, e.g. https://crbug.com/926588.

Reviewers: morehouse

Reviewed By: morehouse

Subscribers: cfe-commits, llvm-commits, kcc

Tags: #clang

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

Modified:
cfe/trunk/docs/SanitizerCoverage.rst

Modified: cfe/trunk/docs/SanitizerCoverage.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=352890=352889=352890=diff
==
--- cfe/trunk/docs/SanitizerCoverage.rst (original)
+++ cfe/trunk/docs/SanitizerCoverage.rst Fri Feb  1 09:12:35 2019
@@ -144,6 +144,11 @@ PC-Table
 
 **Experimental, may change or disappear in future**
 
+**Note:** this instrumentation might be incompatible with dead code stripping
+(``-Wl,-gc-sections``) for linkers other than LLD, thus resulting in a
+significant binary size overhead. For more information, see
+`Bug 34636 `_.
+
 With ``-fsanitize-coverage=pc-table`` the compiler will create a table of
 instrumented PCs. Requires either ``-fsanitize-coverage=inline-8bit-counters`` 
or
 ``-fsanitize-coverage=trace-pc-guard``.


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


Re: r352055 - Fix failing buildbots

2019-02-01 Thread Gábor Márton via cfe-commits
Hi,

Thank you for catching this. I thought that the macros like __x86_64__ are
defined for the target. I just don't understand: If they are defined for
the host, that would mean we can't cross compile on the same host for
different targets, wouldn't it?

I couldn't find out which macros to use to get the target arch, so I see 2
possible solutions :
1. Create a new test binary for these two small tests and specify
explicitly the target. This seems overwhelming.
2. Simply remove those two test cases. This seems to be the simplest
solution.

Gábor


On Fri, 1 Feb 2019, 17:23 David Green  Hello
>
> Sorry for the late reply. I'm not sure this ifdef is quite correct. It
> will be testing the _host_ architecture, presuming the default target is
> the same. If they are different (for example if the default target is
> aarch64 on an x86 machine), the test will presumably still fail.
>
> I went looking through the buildbots and I think this hexagon bot builds
> that way:
> http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/22699
>
> Got any good suggestions how to fix it?
>
> Thanks,
> Dave
>
>
>
>
>
> Author: martong
> Date: Thu Jan 24 07:42:20 2019
> New Revision: 352055
>
> URL: http://llvm.org/viewvc/llvm-project?rev=352055=rev
> Log:
> Fix failing buildbots
>
> Related commit which caused the buildbots to fail:
> rL352050
>
> Modified:
> cfe/trunk/unittests/AST/StructuralEquivalenceTest.cpp
>
> Modified: cfe/trunk/unittests/AST/StructuralEquivalenceTest.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/AST/StructuralEquivalenceTest.cpp?rev=352055=352054=352055=diff
>
> ==
> --- cfe/trunk/unittests/AST/StructuralEquivalenceTest.cpp (original)
> +++ cfe/trunk/unittests/AST/StructuralEquivalenceTest.cpp Thu Jan 24
> 07:42:20 2019
> @@ -378,14 +378,17 @@ TEST_F(StructuralEquivalenceFunctionTest
>EXPECT_TRUE(testStructuralMatch(t));
>  }
>
> +// These calling conventions may not be available on certain platforms.
> +#if defined(__x86_64__) && defined(__linux__)
>  TEST_F(StructuralEquivalenceFunctionTest,
>  FunctionsWithDifferentCallingConventions) {
>auto t = makeNamedDecls(
> -  "__attribute__((fastcall)) void foo();",
> +  "__attribute__((preserve_all)) void foo();",
>"__attribute__((ms_abi))   void foo();",
>Lang_C);
>EXPECT_FALSE(testStructuralMatch(t));
>  }
> +#endif
>
>  TEST_F(StructuralEquivalenceFunctionTest,
> FunctionsWithDifferentSavedRegsAttr) {
>auto t = makeNamedDecls(
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D57474: Update SanitizerCoverage doc regarding the issue with pc-table and gc-sections.

2019-02-01 Thread Max Moroz via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Dor1s marked an inline comment as done.
Closed by commit rC352890: Update SanitizerCoverage doc regarding the issue 
with pc-table and gc-sections. (authored by Dor1s, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D57474?vs=184766=184770#toc

Repository:
  rC Clang

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

https://reviews.llvm.org/D57474

Files:
  docs/SanitizerCoverage.rst


Index: docs/SanitizerCoverage.rst
===
--- docs/SanitizerCoverage.rst
+++ docs/SanitizerCoverage.rst
@@ -144,6 +144,11 @@
 
 **Experimental, may change or disappear in future**
 
+**Note:** this instrumentation might be incompatible with dead code stripping
+(``-Wl,-gc-sections``) for linkers other than LLD, thus resulting in a
+significant binary size overhead. For more information, see
+`Bug 34636 `_.
+
 With ``-fsanitize-coverage=pc-table`` the compiler will create a table of
 instrumented PCs. Requires either ``-fsanitize-coverage=inline-8bit-counters`` 
or
 ``-fsanitize-coverage=trace-pc-guard``.


Index: docs/SanitizerCoverage.rst
===
--- docs/SanitizerCoverage.rst
+++ docs/SanitizerCoverage.rst
@@ -144,6 +144,11 @@
 
 **Experimental, may change or disappear in future**
 
+**Note:** this instrumentation might be incompatible with dead code stripping
+(``-Wl,-gc-sections``) for linkers other than LLD, thus resulting in a
+significant binary size overhead. For more information, see
+`Bug 34636 `_.
+
 With ``-fsanitize-coverage=pc-table`` the compiler will create a table of
 instrumented PCs. Requires either ``-fsanitize-coverage=inline-8bit-counters`` or
 ``-fsanitize-coverage=trace-pc-guard``.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D57524: Fix ICE on attempt to add an addr space qual to a type qualified by an addr space

2019-02-01 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: lib/Sema/SemaInit.cpp:4693
+T2Quals.addAddressSpace(AS2);
+  QualType WithAScv1T4 = S.Context.getQualifiedType(IgnoreAScv2T2, 
T1Quals);
+  Sequence.AddQualificationConversionStep(WithAScv1T4, ValueKind);

Anastasia wrote:
> rjmccall wrote:
> > `Qualifiers::addQualifiers` should let you do this in a single step.  Also, 
> > you seem to be modifying `T2Quals` here after the last use of it.
> Ok, I will update to use Qualifies methods directly.
> 
> As for `T2Quals` I was thinking it might make sense to restore the original 
> value in case some code later will be added to use it (to prevent bugs)... 
> but may be it's too hypothetical. :)
> 
> Thanks!
That's not unreasonable, but if you're going to do that, you should do it 
unconditionally, not just in a `AS1 != AS2` block — or better yet, make new 
locals for `T1QualsWithoutAS`.


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

https://reviews.llvm.org/D57524



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


r352887 - Fix some sphinx doc errors.

2019-02-01 Thread James Y Knight via cfe-commits
Author: jyknight
Date: Fri Feb  1 09:06:41 2019
New Revision: 352887

URL: http://llvm.org/viewvc/llvm-project?rev=352887=rev
Log:
Fix some sphinx doc errors.

Modified:
cfe/trunk/docs/ClangTools.rst

Modified: cfe/trunk/docs/ClangTools.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ClangTools.rst?rev=352887=352886=352887=diff
==
--- cfe/trunk/docs/ClangTools.rst (original)
+++ cfe/trunk/docs/ClangTools.rst Fri Feb  1 09:06:41 2019
@@ -10,8 +10,8 @@ refactoring, etc.
 
 Only a couple of the most basic and fundamental tools are kept in the
 primary Clang tree. The rest of the tools are kept in a separate
-directory tree, ``clang-tools-extra
-``_.
+directory tree, `clang-tools-extra
+`_.
 
 This document describes a high-level overview of the organization of
 Clang Tools within the project as well as giving an introduction to some


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


[PATCH] D57581: Explicitly add language standard option to test cases that rely on the C++14 default

2019-02-01 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

I agree: if a test doesn't seem to require the GNU extensions, let's not use 
`-std=gnu++XX`.  Otherwise this LGTM.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57581



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


[PATCH] D57474: Update SanitizerCoverage doc regarding the issue with pc-table and gc-sections.

2019-02-01 Thread Matt Morehouse via Phabricator via cfe-commits
morehouse accepted this revision.
morehouse added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rC Clang

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

https://reviews.llvm.org/D57474



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


[PATCH] D57474: Update SanitizerCoverage doc regarding the issue with pc-table and gc-sections.

2019-02-01 Thread Max Moroz via Phabricator via cfe-commits
Dor1s marked 2 inline comments as done.
Dor1s added inline comments.



Comment at: docs/SanitizerCoverage.rst:149
+(``-Wl,-gc-sections``), thus resulting in a significant binary size overhead.
+See `Bug 34636 `_ for more info.
+

morehouse wrote:
> Maybe add "for linkers other than LLD".  Dead stripping should work 100% for 
> LLD now.
Thanks, Matt! Done.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57474



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


[PATCH] D57474: Update SanitizerCoverage doc regarding the issue with pc-table and gc-sections.

2019-02-01 Thread Max Moroz via Phabricator via cfe-commits
Dor1s updated this revision to Diff 184766.
Dor1s added a comment.
Herald added a project: clang.

Clarify that only linkers other than LLD are affected.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57474

Files:
  docs/SanitizerCoverage.rst


Index: docs/SanitizerCoverage.rst
===
--- docs/SanitizerCoverage.rst
+++ docs/SanitizerCoverage.rst
@@ -144,6 +144,11 @@
 
 **Experimental, may change or disappear in future**
 
+**Note:** this instrumentation might be incompatible with dead code stripping
+(``-Wl,-gc-sections``) for linkers other than LLD, thus resulting in a
+significant binary size overhead. For more information, see
+`Bug 34636 `_.
+
 With ``-fsanitize-coverage=pc-table`` the compiler will create a table of
 instrumented PCs. Requires either ``-fsanitize-coverage=inline-8bit-counters`` 
or
 ``-fsanitize-coverage=trace-pc-guard``.


Index: docs/SanitizerCoverage.rst
===
--- docs/SanitizerCoverage.rst
+++ docs/SanitizerCoverage.rst
@@ -144,6 +144,11 @@
 
 **Experimental, may change or disappear in future**
 
+**Note:** this instrumentation might be incompatible with dead code stripping
+(``-Wl,-gc-sections``) for linkers other than LLD, thus resulting in a
+significant binary size overhead. For more information, see
+`Bug 34636 `_.
+
 With ``-fsanitize-coverage=pc-table`` the compiler will create a table of
 instrumented PCs. Requires either ``-fsanitize-coverage=inline-8bit-counters`` or
 ``-fsanitize-coverage=trace-pc-guard``.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D57581: Explicitly add language standard option to test cases that rely on the C++14 default

2019-02-01 Thread Nemanja Ivanovic via Phabricator via cfe-commits
nemanjai added a comment.

In D57581#1380609 , @ilya-biryukov 
wrote:

> ...
>  Do have a comment, though. Any, reason to use `-std=gnu++14` and not 
> `-std=c++14`?
>  Most (all?) of the tests do not seem to have anything to do with the gnu 
> extensions, so why enable them?


I only used `gnu++14` in the test cases to match the current default in clang 
(i.e. not change how clang handles the test case). But I have no problem 
whatsoever with making these standard C++.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57581



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


[PATCH] D57162: [DEBUG_INFO][NVPTX] Generate correct data about variable address class.

2019-02-01 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

In D57162#1380795 , @probinson wrote:

> LGTM. I'll trust you on the actual address-class values.


Thanks, Paul! If you want, you can find those values in the table here 
https://docs.nvidia.com/cuda/archive/10.0/ptx-writers-guide-to-interoperability/index.html#cuda-specific-dwarf.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57162



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


[PATCH] D46421: [analyzer][CrossTU] Extend CTU to VarDecls with initializer

2019-02-01 Thread Rafael Stahl via Phabricator via cfe-commits
r.stahl added a comment.

Thanks for the comments! All good points. Nice idea with the constructor, but 
that can probably happen in a follow up patch.

In D46421#1380619 , @xazax.hun wrote:

> I know you probably tired of me making you split all the patches but I think 
> if it is independent of CTU we should submit this fix as a separate commit. 
> This way we could be more focused having one commit doing one thing.


No problem if I should do that. However I'm concerned whether this change is 
correct. Previously this was not required since all VarDecls were canonical. 
Not sure if this change was intended. I did some digging, but am not familiar 
enough with the code base to figure out what changed. Does anyone have an idea 
about this?

But I agree that if it wasn't a deliberate change, we could canonicalize in the 
DeclRegion constructor - or VarRegion since only those are redeclarable.


Repository:
  rC Clang

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

https://reviews.llvm.org/D46421



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


Re: r352055 - Fix failing buildbots

2019-02-01 Thread David Green via cfe-commits
Hello

Sorry for the late reply. I'm not sure this ifdef is quite correct. It will be 
testing the _host_ architecture, presuming the default target is the same. If 
they are different (for example if the default target is aarch64 on an x86 
machine), the test will presumably still fail.

I went looking through the buildbots and I think this hexagon bot builds that 
way:
http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/22699

Got any good suggestions how to fix it?

Thanks,
Dave





Author: martong
Date: Thu Jan 24 07:42:20 2019
New Revision: 352055

URL: http://llvm.org/viewvc/llvm-project?rev=352055=rev
Log:
Fix failing buildbots

Related commit which caused the buildbots to fail:
rL352050

Modified:
    cfe/trunk/unittests/AST/StructuralEquivalenceTest.cpp

Modified: cfe/trunk/unittests/AST/StructuralEquivalenceTest.cpp
URL:  
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/AST/StructuralEquivalenceTest.cpp?rev=352055=352054=352055=diff
==
--- cfe/trunk/unittests/AST/StructuralEquivalenceTest.cpp (original)
+++ cfe/trunk/unittests/AST/StructuralEquivalenceTest.cpp Thu Jan 24 07:42:20 
2019
@@ -378,14 +378,17 @@ TEST_F(StructuralEquivalenceFunctionTest
   EXPECT_TRUE(testStructuralMatch(t));
 }
 
+// These calling conventions may not be available on certain platforms.
+#if defined(__x86_64__) && defined(__linux__)
 TEST_F(StructuralEquivalenceFunctionTest,
 FunctionsWithDifferentCallingConventions) {
   auto t = makeNamedDecls(
-  "__attribute__((fastcall)) void foo();",
+  "__attribute__((preserve_all)) void foo();",
   "__attribute__((ms_abi))   void foo();",
   Lang_C);
   EXPECT_FALSE(testStructuralMatch(t));
 }
+#endif
 
 TEST_F(StructuralEquivalenceFunctionTest, FunctionsWithDifferentSavedRegsAttr) 
{
   auto t = makeNamedDecls(


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

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


[PATCH] D57464: Generalize method overloading on addr spaces to C++

2019-02-01 Thread Bevin Hansson via Phabricator via cfe-commits
ebevhan added inline comments.



Comment at: lib/Parse/ParseDeclCXX.cpp:2313
+}
+  }
 

Anastasia wrote:
> ebevhan wrote:
> > Anastasia wrote:
> > > Anastasia wrote:
> > > > ebevhan wrote:
> > > > > Is there a reason that the attributes are parsed here and not in 
> > > > > `ParseFunctionDeclarator` like the rest of the ref-qualifiers (and 
> > > > > the OpenCL++ ASes)?
> > > > > 
> > > > > That is possibly why the parser is getting confused with the trailing 
> > > > > return.
> > > > Good question! I have a feeling that this was done to unify parsing of 
> > > > all CXX members, not just methods. For collecting the method qualifiers 
> > > > it would certainly help making flow more coherent if this was moved to 
> > > > `ParseFunctionDeclarator`. I will try to experiment with this a bit 
> > > > more. What I found strange that the attributes here are attached to the 
> > > > function type itself instead of its  qualifiers. May be @rjmccall can 
> > > > shed some more light on the overall flow...
> > > I looked at this a bit more and it seems that all the GNU attributes 
> > > other than addr spaces belong to the function (not to be applied to 
> > > `this`) for example 
> > > https://blog.timac.org/2016/0716-constructor-and-destructor-attributes/. 
> > > It seems correct to parse them here and apply to the function type. 
> > > Although we could separate parsing of addr space attribute only and move 
> > > into `ParseFunctionDeclarator`.  However this will only be needed for the 
> > > function type not for the data members. So not sure whether it will make 
> > > the flow any cleaner.
> > > I looked at this a bit more and it seems that all the GNU attributes 
> > > other than addr spaces belong to the function (not to be applied to this) 
> > 
> > Hm, I know what you mean. It's why Clang usually complains when you try 
> > placing an AS attribute after a function declarator, because it's trying to 
> > apply it to the function rather than the method qualifiers.
> > 
> > > However this will only be needed for the function type not for the data 
> > > members. 
> > 
> > But we aren't really interested in data members, are we? Like struct 
> > fields, non-static data members cannot be qualified with ASes (they should 
> > 'inherit' the AS from the object type), and static ones should probably 
> > just accept ASes as part of the member type itself.
> > 
> > These patches are to enable AS-qualifiers on methods, so it only stands to 
> > reason that those ASes would be parsed along with the other method 
> > qualifiers.
> > 
> > ParseFunctionDeclarator calls ParseTypeQualifierListOpt to get the 
> > cv-qualifier-seq for the method qualifiers. Currently it's set to 
> > `AR_NoAttributesParsed`. If we enable parsing attributes there, then the 
> > qualifier parsing might 'eat' attributes that were possibly meant for the 
> > function.
> > 
> > This is just a guess, but what I think you could do is include attributes 
> > in the cv-qualifier parsing with `AR_GNUAttributesParsed`, look for any AS 
> > attributes, take their AS and mark them invalid, then move the attributes 
> > (somehow) from the qualifier-DeclSpec to the `FnAttrs` function attribute 
> > list.
> > 
> > (The reason I'm concerned about where/how the qualifiers are parsed is 
> > because this approach only works for custom ASes applied with the GNU 
> > attribute directly. It won't work if custom address spaces are given with a 
> > custom keyword qualifier, like in OpenCL. If the ASes are parsed into the 
> > DeclSpec used for the other ref-qualifiers, then both of these cases should 
> > 'just work'.)
> > But we aren't really interested in data members, are we? Like struct 
> > fields, non-static data members cannot be qualified with ASes (they should 
> > 'inherit' the AS from the object type), and static ones should probably 
> > just accept ASes as part of the member type itself.
>  
> Pointer data members can be qualified by and address space, but this should 
> be parsed before.
> 
> 
> > This is just a guess, but what I think you could do is include attributes 
> > in the cv-qualifier parsing with AR_GNUAttributesParsed, look for any AS 
> > attributes, take their AS and mark them invalid, then move the attributes 
> > (somehow) from the qualifier-DeclSpec to the FnAttrs function attribute 
> > list.
> 
> Ok, I will try that. Thanks for sharing your ideas!
> 
> Pointer data members can be qualified by and address space, but this should 
> be parsed before.

Right, pointer-to-member is a thing. I always forget about those.



Comment at: test/SemaCXX/address-space-method-overloading.cpp:28
+   //inas4.bar();
+   noas.bar(); // expected-error{{call to member function 'bar' is ambiguous}}
+}

Anastasia wrote:
> ebevhan wrote:
> > Just as an aside (I think I mentioned this on one of the earlier patches as 
> > well); treating a non-AS-qualified object as being in a 

[PATCH] D57220: Test fix for isViableInline remark message

2019-02-01 Thread Dávid Bolvanský via Phabricator via cfe-commits
xbolva00 added inline comments.
Herald added a project: clang.



Comment at: test/Frontend/optimization-remark-with-hotness.c:63
   // NO_PGO: '-fdiagnostics-hotness-threshold=' requires profile-guided 
optimization information
   // expected-remark@+1 {{foo inlined into bar with (cost=always): always 
inliner (hotness:}}
   sum += foo(x, x - 2);

What about this line?


Repository:
  rC Clang

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

https://reviews.llvm.org/D57220



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


[PATCH] D57162: [DEBUG_INFO][NVPTX] Generate correct data about variable address class.

2019-02-01 Thread Paul Robinson via Phabricator via cfe-commits
probinson accepted this revision.
probinson added a comment.
This revision is now accepted and ready to land.
Herald added a project: clang.

LGTM. I'll trust you on the actual address-class values.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57162



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


[PATCH] D57585: [AST][OpenMP] OpenMP Sections / Section constructs contain Structured blocks

2019-02-01 Thread Phabricator via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rC352882: [AST][OpenMP] OpenMP Sections / Section constructs 
contain Structured blocks (authored by lebedevri, committed by ).

Repository:
  rC Clang

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

https://reviews.llvm.org/D57585

Files:
  lib/Sema/SemaOpenMP.cpp
  test/AST/ast-dump-openmp-sections.cpp


Index: test/AST/ast-dump-openmp-sections.cpp
===
--- test/AST/ast-dump-openmp-sections.cpp
+++ test/AST/ast-dump-openmp-sections.cpp
@@ -0,0 +1,57 @@
+// RUN: %clang_cc1 -verify -fopenmp -ast-dump %s | FileCheck %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -ast-dump %s | FileCheck %s
+// expected-no-diagnostics
+
+void sections() {
+#pragma omp sections
+  {
+#pragma omp section
+{
+}
+#pragma omp section
+{
+}
+  }
+}
+
+// CHECK: `-FunctionDecl
+// CHECK-NEXT:   `-CompoundStmt
+// CHECK-NEXT: `-OMPSectionsDirective
+// CHECK-NEXT:   `-CapturedStmt
+// CHECK-NEXT: `-CapturedDecl {{.*}} nothrow
+// CHECK-NEXT:   |-CompoundStmt
+// CHECK-NEXT:   | |-OMPSectionDirective
+// CHECK-NEXT:   | | `-CapturedStmt
+// CHECK-NEXT:   | |   `-CapturedDecl {{.*}} nothrow
+// CHECK-NEXT:   | | |-CompoundStmt
+// CHECK-NEXT:   | | `-ImplicitParamDecl
+// CHECK-NEXT:   | `-OMPSectionDirective
+// CHECK-NEXT:   |   `-CapturedStmt
+// CHECK-NEXT:   | `-CapturedDecl {{.*}} nothrow
+// CHECK-NEXT:   |   |-CompoundStmt
+// CHECK-NEXT:   |   `-ImplicitParamDecl
+// CHECK-NEXT:   |-ImplicitParamDecl
+// CHECK-NEXT:   |-CXXRecordDecl
+// CHECK-NEXT:   | |-DefinitionData
+// CHECK-NEXT:   | | |-DefaultConstructor
+// CHECK-NEXT:   | | |-CopyConstructor
+// CHECK-NEXT:   | | |-MoveConstructor
+// CHECK-NEXT:   | | |-CopyAssignment
+// CHECK-NEXT:   | | |-MoveAssignment
+// CHECK-NEXT:   | | `-Destructor
+// CHECK-NEXT:   | `-CapturedRecordAttr
+// CHECK-NEXT:   |-CapturedDecl {{.*}} nothrow
+// CHECK-NEXT:   | |-CompoundStmt
+// CHECK-NEXT:   | `-ImplicitParamDecl
+// CHECK-NEXT:   |-CXXRecordDecl
+// CHECK-NEXT:   | |-DefinitionData
+// CHECK-NEXT:   | | |-DefaultConstructor
+// CHECK-NEXT:   | | |-CopyConstructor
+// CHECK-NEXT:   | | |-MoveConstructor
+// CHECK-NEXT:   | | |-CopyAssignment
+// CHECK-NEXT:   | | |-MoveAssignment
+// CHECK-NEXT:   | | `-Destructor
+// CHECK-NEXT:   | `-CapturedRecordAttr
+// CHECK-NEXT:   `-CapturedDecl {{.*}} nothrow
+// CHECK-NEXT: |-CompoundStmt
+// CHECK-NEXT: `-ImplicitParamDecl
Index: lib/Sema/SemaOpenMP.cpp
===
--- lib/Sema/SemaOpenMP.cpp
+++ lib/Sema/SemaOpenMP.cpp
@@ -5969,6 +5969,13 @@
 return StmtError();
   }
 
+  // 1.2.2 OpenMP Language Terminology
+  // Structured block - An executable statement with a single entry at the
+  // top and a single exit at the bottom.
+  // The point of exit cannot be a branch out of the structured block.
+  // longjmp() and throw() must not violate the entry/exit criteria.
+  cast(AStmt)->getCapturedDecl()->setNothrow();
+
   setFunctionHasBranchProtectedScope();
 
   return OMPSectionsDirective::Create(Context, StartLoc, EndLoc, Clauses, 
AStmt,
@@ -5983,6 +5990,13 @@
 
   assert(isa(AStmt) && "Captured statement expected");
 
+  // 1.2.2 OpenMP Language Terminology
+  // Structured block - An executable statement with a single entry at the
+  // top and a single exit at the bottom.
+  // The point of exit cannot be a branch out of the structured block.
+  // longjmp() and throw() must not violate the entry/exit criteria.
+  cast(AStmt)->getCapturedDecl()->setNothrow();
+
   setFunctionHasBranchProtectedScope();
   DSAStack->setParentCancelRegion(DSAStack->isCancelRegion());
 


Index: test/AST/ast-dump-openmp-sections.cpp
===
--- test/AST/ast-dump-openmp-sections.cpp
+++ test/AST/ast-dump-openmp-sections.cpp
@@ -0,0 +1,57 @@
+// RUN: %clang_cc1 -verify -fopenmp -ast-dump %s | FileCheck %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -ast-dump %s | FileCheck %s
+// expected-no-diagnostics
+
+void sections() {
+#pragma omp sections
+  {
+#pragma omp section
+{
+}
+#pragma omp section
+{
+}
+  }
+}
+
+// CHECK: `-FunctionDecl
+// CHECK-NEXT:   `-CompoundStmt
+// CHECK-NEXT: `-OMPSectionsDirective
+// CHECK-NEXT:   `-CapturedStmt
+// CHECK-NEXT: `-CapturedDecl {{.*}} nothrow
+// CHECK-NEXT:   |-CompoundStmt
+// CHECK-NEXT:   | |-OMPSectionDirective
+// CHECK-NEXT:   | | `-CapturedStmt
+// CHECK-NEXT:   | |   `-CapturedDecl {{.*}} nothrow
+// 

r352882 - [AST][OpenMP] OpenMP Sections / Section constructs contain Structured blocks

2019-02-01 Thread Roman Lebedev via cfe-commits
Author: lebedevri
Date: Fri Feb  1 07:41:54 2019
New Revision: 352882

URL: http://llvm.org/viewvc/llvm-project?rev=352882=rev
Log:
[AST][OpenMP] OpenMP Sections / Section constructs contain Structured blocks

Summary:
I'm working on a clang-tidy check, much like existing [[ 
http://clang.llvm.org/extra/clang-tidy/checks/bugprone-exception-escape.html | 
bugprone-exception-escape ]],
to detect when an exception might escape out of an OpenMP construct it isn't 
supposed to escape from.
For that i will be using the `nothrow` bit of `CapturedDecl`s.

While that bit is already correctly set for some constructs, e.g. `#pragma omp 
parallel`: https://godbolt.org/z/2La7pv
it isn't set for the `#pragma omp sections`, or `#pragma omp section`: 
https://godbolt.org/z/qZ-EbP

If i'm reading [[ 
https://www.openmp.org/wp-content/uploads/OpenMP-API-Specification-5.0.pdf | 
`OpenMP Application Programming Interface Version 5.0 November 2018` ]] 
correctly,
they should be, as per `2.8.1 sections Construct`, starting with page 86:
* The sections construct is a non-iterative worksharing construct that contains 
a set of **structured blocks**
  that are to be distributed among and executed by the threads in a team. Each 
**structured block** is executed
  once by one of the threads in the team in the context of its implicit task.
* The syntax of the sections construct is as follows:
  #pragma omp sections [clause[ [,] clause] ... ] new-line
{
  [#pragma omp section new-line]
**structured-block**
   ...
* Description
  Each **structured block** in the sections construct is preceded by a section 
directive except
  possibly **the first block**, for which a preceding section directive is 
optional.

* Restrictions
  • The code enclosed in a sections construct must be a **structured block**.
  * A throw executed inside a sections region must cause execution to resume 
within the same
section of the sections region, and the same thread that threw the 
exception must catch it.

Reviewers: ABataev, #openmp

Reviewed By: ABataev

Subscribers: guansong, openmp-commits, cfe-commits

Tags: #clang, #openmp

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

Added:
cfe/trunk/test/AST/ast-dump-openmp-sections.cpp
Modified:
cfe/trunk/lib/Sema/SemaOpenMP.cpp

Modified: cfe/trunk/lib/Sema/SemaOpenMP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOpenMP.cpp?rev=352882=352881=352882=diff
==
--- cfe/trunk/lib/Sema/SemaOpenMP.cpp (original)
+++ cfe/trunk/lib/Sema/SemaOpenMP.cpp Fri Feb  1 07:41:54 2019
@@ -5969,6 +5969,13 @@ StmtResult Sema::ActOnOpenMPSectionsDire
 return StmtError();
   }
 
+  // 1.2.2 OpenMP Language Terminology
+  // Structured block - An executable statement with a single entry at the
+  // top and a single exit at the bottom.
+  // The point of exit cannot be a branch out of the structured block.
+  // longjmp() and throw() must not violate the entry/exit criteria.
+  cast(AStmt)->getCapturedDecl()->setNothrow();
+
   setFunctionHasBranchProtectedScope();
 
   return OMPSectionsDirective::Create(Context, StartLoc, EndLoc, Clauses, 
AStmt,
@@ -5983,6 +5990,13 @@ StmtResult Sema::ActOnOpenMPSectionDirec
 
   assert(isa(AStmt) && "Captured statement expected");
 
+  // 1.2.2 OpenMP Language Terminology
+  // Structured block - An executable statement with a single entry at the
+  // top and a single exit at the bottom.
+  // The point of exit cannot be a branch out of the structured block.
+  // longjmp() and throw() must not violate the entry/exit criteria.
+  cast(AStmt)->getCapturedDecl()->setNothrow();
+
   setFunctionHasBranchProtectedScope();
   DSAStack->setParentCancelRegion(DSAStack->isCancelRegion());
 

Added: cfe/trunk/test/AST/ast-dump-openmp-sections.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/AST/ast-dump-openmp-sections.cpp?rev=352882=auto
==
--- cfe/trunk/test/AST/ast-dump-openmp-sections.cpp (added)
+++ cfe/trunk/test/AST/ast-dump-openmp-sections.cpp Fri Feb  1 07:41:54 2019
@@ -0,0 +1,57 @@
+// RUN: %clang_cc1 -verify -fopenmp -ast-dump %s | FileCheck %s
+// RUN: %clang_cc1 -verify -fopenmp-simd -ast-dump %s | FileCheck %s
+// expected-no-diagnostics
+
+void sections() {
+#pragma omp sections
+  {
+#pragma omp section
+{
+}
+#pragma omp section
+{
+}
+  }
+}
+
+// CHECK: `-FunctionDecl
+// CHECK-NEXT:   `-CompoundStmt
+// CHECK-NEXT: `-OMPSectionsDirective
+// CHECK-NEXT:   `-CapturedStmt
+// CHECK-NEXT: `-CapturedDecl {{.*}} nothrow
+// CHECK-NEXT:   |-CompoundStmt
+// CHECK-NEXT:   | |-OMPSectionDirective
+// CHECK-NEXT:   | | `-CapturedStmt
+// CHECK-NEXT:   | |   `-CapturedDecl {{.*}} nothrow
+// CHECK-NEXT:   | | |-CompoundStmt
+// CHECK-NEXT:   | | `-ImplicitParamDecl
+// CHECK-NEXT:   

r352881 - [CMake] External compiler-rt-configure requires LLVMTestingSupport when including tests

2019-02-01 Thread Stefan Granitz via cfe-commits
Author: stefan.graenitz
Date: Fri Feb  1 07:35:25 2019
New Revision: 352881

URL: http://llvm.org/viewvc/llvm-project?rev=352881=rev
Log:
[CMake] External compiler-rt-configure requires LLVMTestingSupport when 
including tests

Summary:
Apparently `LLVMTestingSupport` must be built before `llvm-config` can be asked 
for it. Symptom with `LLVM_INCLUDE_TESTS=ON` is:
```
$ ./path/to/llvm-build/bin/llvm-config --ldflags --libs testingsupport
-L/path/to/llvm-build/lib -Wl,-search_paths_first 
-Wl,-headerpad_max_install_names
llvm-config: error: component libraries and shared library

llvm-config: error: missing: /path/to/llvm-build/lib/libLLVMTestingSupport.a
```

With `LLVMTestingSupport` as dependency of `compiler-rt-configure` we get the 
expected behavior:
```
$ ./path/to/llvm-build/bin/llvm-config --ldflags --libs testingsupport
-L/path/to/llvm-build/lib -Wl,-search_paths_first 
-Wl,-headerpad_max_install_names
-lLLVMTestingSupport -lLLVMSupport -lLLVMDemangle
```

Reviewers: ab, beanz

Subscribers: dberris, mgorny, erik.pilkington, llvm-commits, cfe-commits

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

Modified:
cfe/trunk/runtime/CMakeLists.txt

Modified: cfe/trunk/runtime/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/runtime/CMakeLists.txt?rev=352881=352880=352881=diff
==
--- cfe/trunk/runtime/CMakeLists.txt (original)
+++ cfe/trunk/runtime/CMakeLists.txt Fri Feb  1 07:35:25 2019
@@ -58,12 +58,16 @@ if(LLVM_BUILD_EXTERNAL_COMPILER_RT AND E
 endif()
   endforeach()
 
+  set(compiler_rt_configure_deps)
   if(TARGET cxx-headers)
-set(COMPILER_RT_LIBCXX_DEPENDENCY "cxx-headers")
+list(APPEND compiler_rt_configure_deps "cxx-headers")
+  endif()
+  if(LLVM_INCLUDE_TESTS)
+list(APPEND compiler_rt_configure_deps LLVMTestingSupport)
   endif()
 
   ExternalProject_Add(compiler-rt
-DEPENDS llvm-config clang ${COMPILER_RT_LIBCXX_DEPENDENCY}
+DEPENDS llvm-config clang ${compiler_rt_configure_deps}
 PREFIX ${COMPILER_RT_PREFIX}
 SOURCE_DIR ${COMPILER_RT_SRC_ROOT}
 STAMP_DIR ${STAMP_DIR}


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


[PATCH] D57521: [CMake] External compiler-rt-configure requires LLVMTestingSupport when including tests

2019-02-01 Thread Phabricator via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL352881: [CMake] External compiler-rt-configure requires 
LLVMTestingSupport when… (authored by stefan.graenitz, committed by ).
Herald added a project: LLVM.

Repository:
  rL LLVM

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

https://reviews.llvm.org/D57521

Files:
  cfe/trunk/runtime/CMakeLists.txt


Index: cfe/trunk/runtime/CMakeLists.txt
===
--- cfe/trunk/runtime/CMakeLists.txt
+++ cfe/trunk/runtime/CMakeLists.txt
@@ -58,12 +58,16 @@
 endif()
   endforeach()
 
+  set(compiler_rt_configure_deps)
   if(TARGET cxx-headers)
-set(COMPILER_RT_LIBCXX_DEPENDENCY "cxx-headers")
+list(APPEND compiler_rt_configure_deps "cxx-headers")
+  endif()
+  if(LLVM_INCLUDE_TESTS)
+list(APPEND compiler_rt_configure_deps LLVMTestingSupport)
   endif()
 
   ExternalProject_Add(compiler-rt
-DEPENDS llvm-config clang ${COMPILER_RT_LIBCXX_DEPENDENCY}
+DEPENDS llvm-config clang ${compiler_rt_configure_deps}
 PREFIX ${COMPILER_RT_PREFIX}
 SOURCE_DIR ${COMPILER_RT_SRC_ROOT}
 STAMP_DIR ${STAMP_DIR}


Index: cfe/trunk/runtime/CMakeLists.txt
===
--- cfe/trunk/runtime/CMakeLists.txt
+++ cfe/trunk/runtime/CMakeLists.txt
@@ -58,12 +58,16 @@
 endif()
   endforeach()
 
+  set(compiler_rt_configure_deps)
   if(TARGET cxx-headers)
-set(COMPILER_RT_LIBCXX_DEPENDENCY "cxx-headers")
+list(APPEND compiler_rt_configure_deps "cxx-headers")
+  endif()
+  if(LLVM_INCLUDE_TESTS)
+list(APPEND compiler_rt_configure_deps LLVMTestingSupport)
   endif()
 
   ExternalProject_Add(compiler-rt
-DEPENDS llvm-config clang ${COMPILER_RT_LIBCXX_DEPENDENCY}
+DEPENDS llvm-config clang ${compiler_rt_configure_deps}
 PREFIX ${COMPILER_RT_PREFIX}
 SOURCE_DIR ${COMPILER_RT_SRC_ROOT}
 STAMP_DIR ${STAMP_DIR}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] r352876 - [clangd] Expose SelectionTree to code tweaks, and use it for swap if branches.

2019-02-01 Thread Sam McCall via cfe-commits
Author: sammccall
Date: Fri Feb  1 07:09:47 2019
New Revision: 352876

URL: http://llvm.org/viewvc/llvm-project?rev=352876=rev
Log:
[clangd] Expose SelectionTree to code tweaks, and use it for swap if branches.

Summary:
This reduces the per-check implementation burden and redundant work.
It also makes checks range-aware by default (treating the commonAncestor
as if it were a point selection should be good baseline behavior).

Reviewers: ilya-biryukov

Subscribers: ioeric, MaskRay, jkorous, arphaman, kadircet

Tags: #clang

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

Modified:
clang-tools-extra/trunk/clangd/ClangdServer.cpp
clang-tools-extra/trunk/clangd/Selection.cpp
clang-tools-extra/trunk/clangd/refactor/Tweak.cpp
clang-tools-extra/trunk/clangd/refactor/Tweak.h
clang-tools-extra/trunk/clangd/refactor/tweaks/SwapIfBranches.cpp
clang-tools-extra/trunk/unittests/clangd/TweakTests.cpp

Modified: clang-tools-extra/trunk/clangd/ClangdServer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdServer.cpp?rev=352876=352875=352876=diff
==
--- clang-tools-extra/trunk/clangd/ClangdServer.cpp (original)
+++ clang-tools-extra/trunk/clangd/ClangdServer.cpp Fri Feb  1 07:09:47 2019
@@ -328,23 +328,28 @@ void ClangdServer::rename(PathRef File,
   "Rename", File, Bind(Action, File.str(), NewName.str(), std::move(CB)));
 }
 
+static llvm::Expected
+tweakSelection(const Range , const InputsAndAST ) {
+  auto Begin = positionToOffset(AST.Inputs.Contents, Sel.start);
+  if (!Begin)
+return Begin.takeError();
+  auto End = positionToOffset(AST.Inputs.Contents, Sel.end);
+  if (!End)
+return End.takeError();
+  return Tweak::Selection(AST.AST, *Begin, *End);
+}
+
 void ClangdServer::enumerateTweaks(PathRef File, Range Sel,
Callback> CB) {
   auto Action = [Sel](decltype(CB) CB, std::string File,
   Expected InpAST) {
 if (!InpAST)
   return CB(InpAST.takeError());
-
-auto  = InpAST->AST;
-auto CursorLoc = sourceLocationInMainFile(
-AST.getASTContext().getSourceManager(), Sel.start);
-if (!CursorLoc)
-  return CB(CursorLoc.takeError());
-Tweak::Selection Inputs = {InpAST->Inputs.Contents, InpAST->AST,
-   *CursorLoc};
-
+auto Selection = tweakSelection(Sel, *InpAST);
+if (!Selection)
+  return CB(Selection.takeError());
 std::vector Res;
-for (auto  : prepareTweaks(Inputs))
+for (auto  : prepareTweaks(*Selection))
   Res.push_back({T->id(), T->title()});
 CB(std::move(Res));
   };
@@ -359,20 +364,14 @@ void ClangdServer::applyTweak(PathRef Fi
   Expected InpAST) {
 if (!InpAST)
   return CB(InpAST.takeError());
-
-auto  = InpAST->AST;
-auto CursorLoc = sourceLocationInMainFile(
-AST.getASTContext().getSourceManager(), Sel.start);
-if (!CursorLoc)
-  return CB(CursorLoc.takeError());
-Tweak::Selection Inputs = {InpAST->Inputs.Contents, InpAST->AST,
-   *CursorLoc};
-
-auto A = prepareTweak(TweakID, Inputs);
+auto Selection = tweakSelection(Sel, *InpAST);
+if (!Selection)
+  return CB(Selection.takeError());
+auto A = prepareTweak(TweakID, *Selection);
 if (!A)
   return CB(A.takeError());
 // FIXME: run formatter on top of resulting replacements.
-return CB((*A)->apply(Inputs));
+return CB((*A)->apply(*Selection));
   };
   WorkScheduler.runWithAST(
   "ApplyTweak", File,

Modified: clang-tools-extra/trunk/clangd/Selection.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/Selection.cpp?rev=352876=352875=352876=diff
==
--- clang-tools-extra/trunk/clangd/Selection.cpp (original)
+++ clang-tools-extra/trunk/clangd/Selection.cpp Fri Feb  1 07:09:47 2019
@@ -112,15 +112,9 @@ private:
   // An optimization for a common case: nodes outside macro expansions that
   // don't intersect the selection may be recursively skipped.
   bool canSafelySkipNode(SourceRange S) {
-<<< HEAD
 auto B = SM.getDecomposedLoc(S.getBegin());
 auto E = SM.getDecomposedLoc(S.getEnd());
 if (B.first != SelFile || E.first != SelFile)
-===
-auto B = SM.getDecomposedLoc(S.getBegin()),
- E = SM.getDecomposedLoc(S.getEnd());
-if (B.first != SM.getMainFileID() || E.first != SM.getMainFileID())
->>> [clangd] Lib to compute and represent selection under cursor.
   return false;
 return B.second >= SelEnd || E.second < SelBeginTokenStart;
   }
@@ -162,7 +156,6 @@ private:
 // LOOP_FOREVER( ++x; )
 //   }
 // Selecting "++x" or "x" will do the right thing.
-<<< HEAD
 auto B = SM.getDecomposedLoc(SM.getTopMacroCallerLoc(S.getBegin()));
 auto E = 

[PATCH] D56326: [OpenMP 5.0] Parsing/sema support for "omp declare mapper" directive

2019-02-01 Thread Lingda Li via Phabricator via cfe-commits
lildmh added a comment.

Thanks a lot Alexey!


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

https://reviews.llvm.org/D56326



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


[PATCH] D57577: Make predefined FLT16 macros conditional on support for the type

2019-02-01 Thread Dan Gohman via Phabricator via cfe-commits
sunfish added a comment.

I think WebAssembly is in the same situation as most other architectures, as 
discussed here:

http://llvm.org/viewvc/llvm-project?view=revision=352221

and should not enable _Float16 yet. The test/Preprocessor/init.c tests were 
semi-automatically generated, so it wasn't specifically intended to include 
tests for FLT16 macros for WebAssembly.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57577



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


  1   2   >