[PATCH] D64931: Change X86 datalayout for three address spaces that specify pointer sizes.

[Douglas Yung via Phabricator via cfe-commits]

dyung added a comment.

In D64931#1647880 , @dyung wrote:

> Hi, this is causing 3 test failures on the PS4 linux bot. The changes may not 
> have been initially flagged because a different issue was causing a build 
> failure which masked the problem. I have bisected the test failures to this 
> change though.
>
> http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/53916
>
> LLVM :: LTO/Resolution/X86/not-prevailing-weak-aliasee.ll
>  LLVM :: ThinLTO/X86/printer.ll
>  lld :: ELF/lto/drop-debug-info.ll


Actually it appears the llvm tests were fixed up in r370105 leaving only the 
LLD test failing.

> Can you take a look?




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64931



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

[PATCH] D64931: Change X86 datalayout for three address spaces that specify pointer sizes.

[Douglas Yung via Phabricator via cfe-commits]

dyung added a comment.

Hi, this is causing 3 test failures on the PS4 linux bot. The changes may not 
have been initially flagged because a different issue was causing a build 
failure which masked the problem. I have bisected the test failures to this 
change though.

http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/53916

LLVM :: LTO/Resolution/X86/not-prevailing-weak-aliasee.ll
LLVM :: ThinLTO/X86/printer.ll
lld :: ELF/lto/drop-debug-info.ll

Can you take a look?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64931



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

[PATCH] D64931: Change X86 datalayout for three address spaces that specify pointer sizes.

[Amy Huang via Phabricator via cfe-commits]

akhuang closed this revision.
akhuang added a comment.

Commited in r370083


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64931



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

[PATCH] D64931: Change X86 datalayout for three address spaces that specify pointer sizes.

[Amy Huang via Phabricator via cfe-commits]

akhuang added a comment.

Pinging reviewers -- are there any other concerns on this patch?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64931



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

[PATCH] D64931: Change X86 datalayout for three address spaces that specify pointer sizes.

[Reid Kleckner via Phabricator via cfe-commits]

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

I think we're ready to proceed here, lgtm. Shout if I've misrepresented 
anything. :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64931



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

[PATCH] D64931: Change X86 datalayout for three address spaces that specify pointer sizes.

[Matt Arsenault via Phabricator via cfe-commits]

arsenm added a comment.

In D64931#1633669 , @akhuang wrote:

> > Address space have backend defined semantics, and aren’t really reserved 
> > for front end use. I think the fact that non-0 address spaces on X86 
> > codegen the same as address space 0 and could be used for something by a 
> > front end is an accident of how SelectionDAG is implemented. If X86 wants 
> > to reserve address space ranges for frontend use, that would need to be 
> > decided and documented. You don’t necessarily get the current behavior for 
> > free in GlobalISel since pointer types are distinct, so this would 
> > specifically need to be implemented.
>
> By this do you mean that this would be an instance of address spaces being 
> used by the frontend? Or just that adding meaning to address spaces shouldn't 
> be breaking other frontends?


I mean if frontends are relying on current specific behavior for these address 
spaces, that’s not something that’s documented to work. It just happens to


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64931



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

[PATCH] D64931: Change X86 datalayout for three address spaces that specify pointer sizes.

[Amy Huang via Phabricator via cfe-commits]

akhuang added a comment.

> Address space have backend defined semantics, and aren’t really reserved for 
> front end use. I think the fact that non-0 address spaces on X86 codegen the 
> same as address space 0 and could be used for something by a front end is an 
> accident of how SelectionDAG is implemented. If X86 wants to reserve address 
> space ranges for frontend use, that would need to be decided and documented. 
> You don’t necessarily get the current behavior for free in GlobalISel since 
> pointer types are distinct, so this would specifically need to be implemented.

By this do you mean that this would be an instance of address spaces being used 
by the frontend? Or just that adding meaning to address spaces shouldn't be 
breaking other frontends?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64931



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

[PATCH] D64931: Change X86 datalayout for three address spaces that specify pointer sizes.

[Matt Arsenault via Phabricator via cfe-commits]

arsenm added a comment.

In D64931#1622039 , @lebedev.ri wrote:

> In D64931#1622038 , @akhuang wrote:
>
> > @lebedev.ri The test case datalayout strings were changed because somewhere 
> > llvm asserts that the string in the IR matches the backend datalayout. I 
> > don't know why I wasn't getting the assert error now, but I think they'll 
> > all have to be changed
>
>
> Can you post a reproducer?
>
> In D64931#1622038 , @akhuang wrote:
>
> > if we change the X86 datalayout?
>
>
> I think this is precisely what was discussed in replies to RFC - this 
> hardcodes these address spaces,
>  and thus either makes them unavaliable for other front-ends and/or forces 
> them to use them with Precisely Same Meaning.


Address space have backend defined semantics, and aren’t really reserved for 
front end use. I think the fact that non-0 address spaces on X86 codegen the 
same as address space 0 and could be used for something by a front end is an 
accident of how SelectionDAG is implemented. If X86 wants to reserve address 
space ranges for frontend use, that would need to be decided and documented. 
You don’t necessarily get the current behavior for free in GlobalISel since 
pointer types are distinct, so this would specifically need to be implemented.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64931



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

[PATCH] D64931: Change X86 datalayout for three address spaces that specify pointer sizes.

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

In D64931#1622144 , @akhuang wrote:

> > Can you post a reproducer?
>
> Turns out I just didn't have assertions enabled. With assertions the changed 
> test cases should fail.
>
> > I think this is precisely what was discussed in replies to RFC - this 
> > hardcodes these address spaces, and thus either makes them unavaliable for 
> > other front-ends and/or forces them to use them with Precisely Same Meaning.
>
> It seems like the RFC replies agreed that this should be implemented with 
> address spaces, and that the information for these is encoded in the data 
> layout.


Yes, *in front-end*.
`llvm/lib/Target/X86/X86TargetMachine.cpp` is *not* front-end, therefore

> In D64931#1622039 , @lebedev.ri 
> wrote:
> 
>> this hardcodes these address spaces, and thus either makes them unavaliable 
>> for other front-ends and/or forces them to use them with Precisely Same 
>> Meaning.



In D64931#1622144 , @akhuang wrote:

> I think there was some confusion as to whether there would be more changes in 
> addition to the data layout change?



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64931



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

[PATCH] D64931: Change X86 datalayout for three address spaces that specify pointer sizes.

[Amy Huang via Phabricator via cfe-commits]

akhuang added a comment.

> Can you post a reproducer?

Turns out I just didn't have assertions enabled. With assertions the changed 
test cases should fail.

> I think this is precisely what was discussed in replies to RFC - this 
> hardcodes these address spaces, and thus either makes them unavaliable for 
> other front-ends and/or forces them to use them with Precisely Same Meaning.

It seems like the RFC replies agreed that this should be implemented with 
address spaces, and that the information for these is encoded in the data 
layout. I think there was some confusion as to whether there would be more 
changes in addition to the data layout change?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64931



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

[PATCH] D64931: Change X86 datalayout for three address spaces that specify pointer sizes.

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

In D64931#1622038 , @akhuang wrote:

> @lebedev.ri The test case datalayout strings were changed because somewhere 
> llvm asserts that the string in the IR matches the backend datalayout. I 
> don't know why I wasn't getting the assert error now, but I think they'll all 
> have to be changed


Can you post a reproducer?

In D64931#1622038 , @akhuang wrote:

> if we change the X86 datalayout?


I think this is precisely what was discussed in replies to RFC - this hardcodes 
these address spaces,
and thus either makes them unavaliable for other front-ends and/or forces them 
to use them with Precisely Same Meaning.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64931



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

[PATCH] D64931: Change X86 datalayout for three address spaces that specify pointer sizes.

[Amy Huang via Phabricator via cfe-commits]

akhuang added a comment.

@lebedev.ri The test case datalayout strings were changed because somewhere 
llvm asserts that the string in the IR matches the backend datalayout. I don't 
know why I wasn't getting the assert error now, but I think they'll all have to 
be changed if we change the X86 datalayout?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64931



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

[PATCH] D64931: Change X86 datalayout for three address spaces that specify pointer sizes.

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a reviewer: reames.
lebedev.ri added inline comments.



Comment at: llvm/lib/Target/X86/X86TargetMachine.cpp:119-120
 
+  // Address spaces for 32 bit signed, 32 bit unsigned, and 64 bit pointers.
+  Ret += "-p253:32:32-p254:32:32-p255:64:64";
+

I may be wrong but this seems to not match what has been said in the responses 
to RFC.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64931



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

[PATCH] D64931: Change X86 datalayout for three address spaces that specify pointer sizes.

[Amy Huang via Phabricator via cfe-commits]

akhuang updated this revision to Diff 214202.
akhuang added a comment.

Remove test case changes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64931

Files:
  clang/lib/Basic/Targets/OSTargets.h
  clang/lib/Basic/Targets/X86.h
  clang/test/CodeGen/iamcu-abi.c
  clang/test/CodeGen/target-data.c
  llvm/lib/Target/X86/X86TargetMachine.cpp

Index: llvm/lib/Target/X86/X86TargetMachine.cpp
===
--- llvm/lib/Target/X86/X86TargetMachine.cpp
+++ llvm/lib/Target/X86/X86TargetMachine.cpp
@@ -116,6 +116,9 @@
   !TT.isArch64Bit())
 Ret += "-p:32:32";
 
+  // Address spaces for 32 bit signed, 32 bit unsigned, and 64 bit pointers.
+  Ret += "-p253:32:32-p254:32:32-p255:64:64";
+
   // Some ABIs align 64 bit integers and doubles to 64 bits, others to 32.
   if (TT.isArch64Bit() || TT.isOSWindows() || TT.isOSNaCl())
 Ret += "-i64:64";
Index: clang/test/CodeGen/target-data.c
===
--- clang/test/CodeGen/target-data.c
+++ clang/test/CodeGen/target-data.c
@@ -1,22 +1,22 @@
 // RUN: %clang_cc1 -triple i686-unknown-unknown -emit-llvm -o - %s | \
 // RUN: FileCheck --check-prefix=I686-UNKNOWN %s
-// I686-UNKNOWN: target datalayout = "e-m:e-p:32:32-f64:32:64-f80:32-n8:16:32-S128"
+// I686-UNKNOWN: target datalayout = "e-m:e-p:32:32-p253:32:32-p254:32:32-p255:64:64-f64:32:64-f80:32-n8:16:32-S128"
 
 // RUN: %clang_cc1 -triple i686-apple-darwin9 -emit-llvm -o - %s | \
 // RUN: FileCheck --check-prefix=I686-DARWIN %s
-// I686-DARWIN: target datalayout = "e-m:o-p:32:32-f64:32:64-f80:128-n8:16:32-S128"
+// I686-DARWIN: target datalayout = "e-m:o-p:32:32-p253:32:32-p254:32:32-p255:64:64-f64:32:64-f80:128-n8:16:32-S128"
 
 // RUN: %clang_cc1 -triple i686-unknown-win32 -emit-llvm -o - %s | \
 // RUN: FileCheck --check-prefix=I686-WIN32 %s
-// I686-WIN32: target datalayout = "e-m:x-p:32:32-i64:64-f80:32-n8:16:32-a:0:32-S32"
+// I686-WIN32: target datalayout = "e-m:x-p:32:32-p253:32:32-p254:32:32-p255:64:64-i64:64-f80:32-n8:16:32-a:0:32-S32"
 
 // RUN: %clang_cc1 -triple i686-unknown-cygwin -emit-llvm -o - %s | \
 // RUN: FileCheck --check-prefix=I686-CYGWIN %s
-// I686-CYGWIN: target datalayout = "e-m:x-p:32:32-i64:64-f80:32-n8:16:32-a:0:32-S32"
+// I686-CYGWIN: target datalayout = "e-m:x-p:32:32-p253:32:32-p254:32:32-p255:64:64-i64:64-f80:32-n8:16:32-a:0:32-S32"
 
 // RUN: %clang_cc1 -triple x86_64-unknown-unknown -emit-llvm -o - %s | \
 // RUN: FileCheck --check-prefix=X86_64 %s
-// X86_64: target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
+// X86_64: target datalayout = "e-m:e-p253:32:32-p254:32:32-p255:64:64-i64:64-f80:128-n8:16:32:64-S128"
 
 // RUN: %clang_cc1 -triple xcore-unknown-unknown -emit-llvm -o - %s | \
 // RUN: FileCheck --check-prefix=XCORE %s
@@ -88,11 +88,11 @@
 
 // RUN: %clang_cc1 -triple i686-nacl -o - -emit-llvm %s | \
 // RUN: FileCheck %s -check-prefix=I686-NACL
-// I686-NACL: target datalayout = "e-m:e-p:32:32-i64:64-n8:16:32-S128"
+// I686-NACL: target datalayout = "e-m:e-p:32:32-p253:32:32-p254:32:32-p255:64:64-i64:64-n8:16:32-S128"
 
 // RUN: %clang_cc1 -triple x86_64-nacl -o - -emit-llvm %s | \
 // RUN: FileCheck %s -check-prefix=X86_64-NACL
-// X86_64-NACL: target datalayout = "e-m:e-p:32:32-i64:64-n8:16:32:64-S128"
+// X86_64-NACL: target datalayout = "e-m:e-p:32:32-p253:32:32-p254:32:32-p255:64:64-i64:64-n8:16:32:64-S128"
 
 // RUN: %clang_cc1 -triple arm-nacl -o - -emit-llvm %s | \
 // RUN: FileCheck %s -check-prefix=ARM-NACL
Index: clang/test/CodeGen/iamcu-abi.c
===
--- clang/test/CodeGen/iamcu-abi.c
+++ clang/test/CodeGen/iamcu-abi.c
@@ -1,6 +1,6 @@
 // RUN: %clang_cc1 -triple i386-pc-elfiamcu -emit-llvm -o - %s | FileCheck %s
 
-// CHECK: target datalayout = "e-m:e-p:32:32-i64:32-f64:32-f128:32-n8:16:32-a:0:32-S32"
+// CHECK: target datalayout = "e-m:e-p:32:32-p253:32:32-p254:32:32-p255:64:64-i64:32-f64:32-f128:32-n8:16:32-a:0:32-S32"
 // CHECK: target triple = "i386-pc-elfiamcu"
 
 
Index: clang/lib/Basic/Targets/X86.h
===
--- clang/lib/Basic/Targets/X86.h
+++ clang/lib/Basic/Targets/X86.h
@@ -340,7 +340,7 @@
 LongDoubleWidth = 96;
 LongDoubleAlign = 32;
 SuitableAlign = 128;
-resetDataLayout("e-m:e-p:32:32-f64:32:64-f80:32-n8:16:32-S128");
+resetDataLayout("e-m:e-p:32:32-p253:32:32-p254:32:32-p255:64:64-f64:32:64-f80:32-n8:16:32-S128");
 SizeType = UnsignedInt;
 PtrDiffType = SignedInt;
 IntPtrType = SignedInt;
@@ -440,7 +440,7 @@
   UseSignedCharForObjCBool = false;
 SizeType = UnsignedLong;
 IntPtrType = SignedLong;
-resetDataLayout("e-m:o-p:32:32-f64:32:64-f80:128-n8:16:32-S128");
+

[PATCH] D64931: Change X86 datalayout for three address spaces that specify pointer sizes.

[Amy Huang via Phabricator via cfe-commits]

akhuang added a comment.

For some reason the tests were failing before without the datalayout change? 
I'm not sure why, but I changed them back and they're fine.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64931



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

[PATCH] D64931: Change X86 datalayout for three address spaces that specify pointer sizes.

[Reid Kleckner via Phabricator via cfe-commits]

rnk added inline comments.



Comment at: clang/lib/Basic/Targets/OSTargets.h:771-772
 } else if (Triple.getArch() == llvm::Triple::x86) {
-  this->resetDataLayout("e-m:e-p:32:32-i64:64-n8:16:32-S128");
+  this->resetDataLayout("e-m:e-p:32:32-p253:32:32-p254:32:32-p255:64:64-"
+"i64:64-n8:16:32-S128");
 } else if (Triple.getArch() == llvm::Triple::x86_64) {

lebedev.ri wrote:
> I'd expect that this should be guarded by whatever flag is used for ms 
> extensions.
> Put differently, i i'm not sure that when those extensions are not enabled, 
> the datalayout should be changed?
As discussed in the RFC, other people find these address spaces generally 
useful, and there is no need to limit them to just Windows or *-windows-msvc 
targets. Making it conditional would require mirroring the same conditional 
into LLVM, because LLVM and clang have to agree on data layout.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64931



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

[PATCH] D64931: Change X86 datalayout for three address spaces that specify pointer sizes.

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added inline comments.



Comment at: clang/lib/Basic/Targets/OSTargets.h:771-772
 } else if (Triple.getArch() == llvm::Triple::x86) {
-  this->resetDataLayout("e-m:e-p:32:32-i64:64-n8:16:32-S128");
+  this->resetDataLayout("e-m:e-p:32:32-p253:32:32-p254:32:32-p255:64:64-"
+"i64:64-n8:16:32-S128");
 } else if (Triple.getArch() == llvm::Triple::x86_64) {

I'd expect that this should be guarded by whatever flag is used for ms 
extensions.
Put differently, i i'm not sure that when those extensions are not enabled, the 
datalayout should be changed?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64931



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

[PATCH] D64931: Change X86 datalayout for three address spaces that specify pointer sizes.

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

Why do you need to change (update) the datalayout in every single test?
That looks extremely noisy and hides the actually-needed changes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64931



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

[PATCH] D64931: Change X86 datalayout for three address spaces that specify pointer sizes.

[Amy Huang via Phabricator via cfe-commits]

akhuang added a comment.

The llvm-dev discussion is here 
http://lists.llvm.org/pipermail/llvm-dev/2019-July/134035.html
I think the consensus is that it should be fine to change the data layout.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64931



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

[PATCH] D64931: Change X86 datalayout for three address spaces that specify pointer sizes.

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

I suggested to @akhuang offline that we should discuss this on llvm-dev. I'll 
add some other X86 reviewers.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64931



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