[PATCH] D56585: [clang-tidy] Treat references to smart pointers correctly in use-after-move.

2019-01-15 Thread Martin Böhme via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL351303: [clang-tidy] Treat references to smart pointers 
correctly in use-after-move. (authored by mboehme, committed by ).
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

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

https://reviews.llvm.org/D56585

Files:
  clang-tools-extra/trunk/clang-tidy/bugprone/UseAfterMoveCheck.cpp
  clang-tools-extra/trunk/test/clang-tidy/bugprone-use-after-move.cpp


Index: clang-tools-extra/trunk/clang-tidy/bugprone/UseAfterMoveCheck.cpp
===
--- clang-tools-extra/trunk/clang-tidy/bugprone/UseAfterMoveCheck.cpp
+++ clang-tools-extra/trunk/clang-tidy/bugprone/UseAfterMoveCheck.cpp
@@ -207,7 +207,7 @@
 }
 
 bool isStandardSmartPointer(const ValueDecl *VD) {
-  const Type *TheType = VD->getType().getTypePtrOrNull();
+  const Type *TheType = VD->getType().getNonReferenceType().getTypePtrOrNull();
   if (!TheType)
 return false;
 
Index: clang-tools-extra/trunk/test/clang-tidy/bugprone-use-after-move.cpp
===
--- clang-tools-extra/trunk/test/clang-tidy/bugprone-use-after-move.cpp
+++ clang-tools-extra/trunk/test/clang-tidy/bugprone-use-after-move.cpp
@@ -244,6 +244,19 @@
 std::move(ptr);
 ptr.get();
   }
+  // Make sure we treat references to smart pointers correctly.
+  {
+std::unique_ptr ptr;
+std::unique_ptr& ref_to_ptr = ptr;
+std::move(ref_to_ptr);
+ref_to_ptr.get();
+  }
+  {
+std::unique_ptr ptr;
+std::unique_ptr&& rvalue_ref_to_ptr = std::move(ptr);
+std::move(rvalue_ref_to_ptr);
+rvalue_ref_to_ptr.get();
+  }
   // We don't give any special treatment to types that are called "unique_ptr"
   // or "shared_ptr" but are not in the "::std" namespace.
   {


Index: clang-tools-extra/trunk/clang-tidy/bugprone/UseAfterMoveCheck.cpp
===
--- clang-tools-extra/trunk/clang-tidy/bugprone/UseAfterMoveCheck.cpp
+++ clang-tools-extra/trunk/clang-tidy/bugprone/UseAfterMoveCheck.cpp
@@ -207,7 +207,7 @@
 }
 
 bool isStandardSmartPointer(const ValueDecl *VD) {
-  const Type *TheType = VD->getType().getTypePtrOrNull();
+  const Type *TheType = VD->getType().getNonReferenceType().getTypePtrOrNull();
   if (!TheType)
 return false;
 
Index: clang-tools-extra/trunk/test/clang-tidy/bugprone-use-after-move.cpp
===
--- clang-tools-extra/trunk/test/clang-tidy/bugprone-use-after-move.cpp
+++ clang-tools-extra/trunk/test/clang-tidy/bugprone-use-after-move.cpp
@@ -244,6 +244,19 @@
 std::move(ptr);
 ptr.get();
   }
+  // Make sure we treat references to smart pointers correctly.
+  {
+std::unique_ptr ptr;
+std::unique_ptr& ref_to_ptr = ptr;
+std::move(ref_to_ptr);
+ref_to_ptr.get();
+  }
+  {
+std::unique_ptr ptr;
+std::unique_ptr&& rvalue_ref_to_ptr = std::move(ptr);
+std::move(rvalue_ref_to_ptr);
+rvalue_ref_to_ptr.get();
+  }
   // We don't give any special treatment to types that are called "unique_ptr"
   // or "shared_ptr" but are not in the "::std" namespace.
   {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] r351303 - [clang-tidy] Treat references to smart pointers correctly in use-after-move.

2019-01-15 Thread Martin Bohme via cfe-commits
Author: mboehme
Date: Tue Jan 15 23:53:25 2019
New Revision: 351303

URL: http://llvm.org/viewvc/llvm-project?rev=351303=rev
Log:
[clang-tidy] Treat references to smart pointers correctly in use-after-move.

Summary:
Previously, we weren't recognizing these as smart pointers and thus
weren't allowing non-dereference accesses as we should -- see new test
cases which fail without the fix.

Reviewers: alexfh, hokein, aaron.ballman, JonasToth

Reviewed By: JonasToth

Subscribers: xazax.hun, cfe-commits

Tags: #clang-tools-extra

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

Modified:
clang-tools-extra/trunk/clang-tidy/bugprone/UseAfterMoveCheck.cpp
clang-tools-extra/trunk/test/clang-tidy/bugprone-use-after-move.cpp

Modified: clang-tools-extra/trunk/clang-tidy/bugprone/UseAfterMoveCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/bugprone/UseAfterMoveCheck.cpp?rev=351303=351302=351303=diff
==
--- clang-tools-extra/trunk/clang-tidy/bugprone/UseAfterMoveCheck.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/bugprone/UseAfterMoveCheck.cpp Tue Jan 
15 23:53:25 2019
@@ -207,7 +207,7 @@ void UseAfterMoveFinder::getUsesAndReini
 }
 
 bool isStandardSmartPointer(const ValueDecl *VD) {
-  const Type *TheType = VD->getType().getTypePtrOrNull();
+  const Type *TheType = VD->getType().getNonReferenceType().getTypePtrOrNull();
   if (!TheType)
 return false;
 

Modified: clang-tools-extra/trunk/test/clang-tidy/bugprone-use-after-move.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/bugprone-use-after-move.cpp?rev=351303=351302=351303=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/bugprone-use-after-move.cpp 
(original)
+++ clang-tools-extra/trunk/test/clang-tidy/bugprone-use-after-move.cpp Tue Jan 
15 23:53:25 2019
@@ -244,6 +244,19 @@ void standardSmartPtr() {
 std::move(ptr);
 ptr.get();
   }
+  // Make sure we treat references to smart pointers correctly.
+  {
+std::unique_ptr ptr;
+std::unique_ptr& ref_to_ptr = ptr;
+std::move(ref_to_ptr);
+ref_to_ptr.get();
+  }
+  {
+std::unique_ptr ptr;
+std::unique_ptr&& rvalue_ref_to_ptr = std::move(ptr);
+std::move(rvalue_ref_to_ptr);
+rvalue_ref_to_ptr.get();
+  }
   // We don't give any special treatment to types that are called "unique_ptr"
   // or "shared_ptr" but are not in the "::std" namespace.
   {


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


[PATCH] D56463: [SEH] Pass the frame pointer from SEH finally to finally functions

2019-01-15 Thread Sanjin Sijaric via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rC351302: [SEH] Pass the frame pointer from SEH finally to 
finally functions (authored by ssijaric, committed by ).

Repository:
  rC Clang

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

https://reviews.llvm.org/D56463

Files:
  lib/CodeGen/CGException.cpp
  test/CodeGen/exceptions-seh-nested-finally.c


Index: test/CodeGen/exceptions-seh-nested-finally.c
===
--- test/CodeGen/exceptions-seh-nested-finally.c
+++ test/CodeGen/exceptions-seh-nested-finally.c
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 %s -triple x86_64-pc-win32 -fms-extensions -emit-llvm -o - \
+// RUN: | FileCheck %s
+// RUN: %clang_cc1 %s -triple i686-pc-win32 -fms-extensions -emit-llvm -o - \
+// RUN: | FileCheck %s
+// RUN: %clang_cc1 %s -triple aarch64-windows -fms-extensions -emit-llvm -o - \
+// RUN: | FileCheck %s
+
+// Check that the first finally block passes the enclosing function's frame
+// pointer to the second finally block, instead of generating it via localaddr.
+
+// CHECK-LABEL: define internal void @"?fin$0@0@main@@"({{i8( zeroext)?}} 
%abnormal_termination, i8* %frame_pointer)
+// CHECK: call void @"?fin$1@0@main@@"({{i8( zeroext)?}} 0, i8* %frame_pointer)
+int
+main() {
+  int Check = 0;
+  __try {
+Check = 3;
+  } __finally {
+__try {
+  Check += 2;
+} __finally {
+  Check += 4;
+}
+  }
+  return Check;
+}
Index: lib/CodeGen/CGException.cpp
===
--- lib/CodeGen/CGException.cpp
+++ lib/CodeGen/CGException.cpp
@@ -1627,8 +1627,16 @@
 
 // Compute the two argument values.
 QualType ArgTys[2] = {Context.UnsignedCharTy, Context.VoidPtrTy};
-llvm::Value *LocalAddrFn = CGM.getIntrinsic(llvm::Intrinsic::localaddress);
-llvm::Value *FP = CGF.Builder.CreateCall(LocalAddrFn);
+llvm::Value *FP = nullptr;
+// If CFG.IsOutlinedSEHHelper is true, then we are within a finally block.
+if (CGF.IsOutlinedSEHHelper) {
+  FP = >arg_begin()[1];
+} else {
+  llvm::Value *LocalAddrFn =
+  CGM.getIntrinsic(llvm::Intrinsic::localaddress);
+  FP = CGF.Builder.CreateCall(LocalAddrFn);
+}
+
 llvm::Value *IsForEH =
 llvm::ConstantInt::get(CGF.ConvertType(ArgTys[0]), F.isForEHCleanup());
 Args.add(RValue::get(IsForEH), ArgTys[0]);


Index: test/CodeGen/exceptions-seh-nested-finally.c
===
--- test/CodeGen/exceptions-seh-nested-finally.c
+++ test/CodeGen/exceptions-seh-nested-finally.c
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 %s -triple x86_64-pc-win32 -fms-extensions -emit-llvm -o - \
+// RUN: | FileCheck %s
+// RUN: %clang_cc1 %s -triple i686-pc-win32 -fms-extensions -emit-llvm -o - \
+// RUN: | FileCheck %s
+// RUN: %clang_cc1 %s -triple aarch64-windows -fms-extensions -emit-llvm -o - \
+// RUN: | FileCheck %s
+
+// Check that the first finally block passes the enclosing function's frame
+// pointer to the second finally block, instead of generating it via localaddr.
+
+// CHECK-LABEL: define internal void @"?fin$0@0@main@@"({{i8( zeroext)?}} %abnormal_termination, i8* %frame_pointer)
+// CHECK: call void @"?fin$1@0@main@@"({{i8( zeroext)?}} 0, i8* %frame_pointer)
+int
+main() {
+  int Check = 0;
+  __try {
+Check = 3;
+  } __finally {
+__try {
+  Check += 2;
+} __finally {
+  Check += 4;
+}
+  }
+  return Check;
+}
Index: lib/CodeGen/CGException.cpp
===
--- lib/CodeGen/CGException.cpp
+++ lib/CodeGen/CGException.cpp
@@ -1627,8 +1627,16 @@
 
 // Compute the two argument values.
 QualType ArgTys[2] = {Context.UnsignedCharTy, Context.VoidPtrTy};
-llvm::Value *LocalAddrFn = CGM.getIntrinsic(llvm::Intrinsic::localaddress);
-llvm::Value *FP = CGF.Builder.CreateCall(LocalAddrFn);
+llvm::Value *FP = nullptr;
+// If CFG.IsOutlinedSEHHelper is true, then we are within a finally block.
+if (CGF.IsOutlinedSEHHelper) {
+  FP = >arg_begin()[1];
+} else {
+  llvm::Value *LocalAddrFn =
+  CGM.getIntrinsic(llvm::Intrinsic::localaddress);
+  FP = CGF.Builder.CreateCall(LocalAddrFn);
+}
+
 llvm::Value *IsForEH =
 llvm::ConstantInt::get(CGF.ConvertType(ArgTys[0]), F.isForEHCleanup());
 Args.add(RValue::get(IsForEH), ArgTys[0]);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r351302 - [SEH] Pass the frame pointer from SEH finally to finally functions

2019-01-15 Thread Sanjin Sijaric via cfe-commits
Author: ssijaric
Date: Tue Jan 15 23:39:44 2019
New Revision: 351302

URL: http://llvm.org/viewvc/llvm-project?rev=351302=rev
Log:
[SEH] Pass the frame pointer from SEH finally to finally functions

Pass the frame pointer that the first finally block receives onto the nested
finally block, instead of generating it using localaddr.

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

Added:
cfe/trunk/test/CodeGen/exceptions-seh-nested-finally.c
Modified:
cfe/trunk/lib/CodeGen/CGException.cpp

Modified: cfe/trunk/lib/CodeGen/CGException.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGException.cpp?rev=351302=351301=351302=diff
==
--- cfe/trunk/lib/CodeGen/CGException.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGException.cpp Tue Jan 15 23:39:44 2019
@@ -1627,8 +1627,16 @@ struct PerformSEHFinally final : EHScope
 
 // Compute the two argument values.
 QualType ArgTys[2] = {Context.UnsignedCharTy, Context.VoidPtrTy};
-llvm::Value *LocalAddrFn = CGM.getIntrinsic(llvm::Intrinsic::localaddress);
-llvm::Value *FP = CGF.Builder.CreateCall(LocalAddrFn);
+llvm::Value *FP = nullptr;
+// If CFG.IsOutlinedSEHHelper is true, then we are within a finally block.
+if (CGF.IsOutlinedSEHHelper) {
+  FP = >arg_begin()[1];
+} else {
+  llvm::Value *LocalAddrFn =
+  CGM.getIntrinsic(llvm::Intrinsic::localaddress);
+  FP = CGF.Builder.CreateCall(LocalAddrFn);
+}
+
 llvm::Value *IsForEH =
 llvm::ConstantInt::get(CGF.ConvertType(ArgTys[0]), F.isForEHCleanup());
 Args.add(RValue::get(IsForEH), ArgTys[0]);

Added: cfe/trunk/test/CodeGen/exceptions-seh-nested-finally.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/exceptions-seh-nested-finally.c?rev=351302=auto
==
--- cfe/trunk/test/CodeGen/exceptions-seh-nested-finally.c (added)
+++ cfe/trunk/test/CodeGen/exceptions-seh-nested-finally.c Tue Jan 15 23:39:44 
2019
@@ -0,0 +1,26 @@
+// RUN: %clang_cc1 %s -triple x86_64-pc-win32 -fms-extensions -emit-llvm -o - \
+// RUN: | FileCheck %s
+// RUN: %clang_cc1 %s -triple i686-pc-win32 -fms-extensions -emit-llvm -o - \
+// RUN: | FileCheck %s
+// RUN: %clang_cc1 %s -triple aarch64-windows -fms-extensions -emit-llvm -o - \
+// RUN: | FileCheck %s
+
+// Check that the first finally block passes the enclosing function's frame
+// pointer to the second finally block, instead of generating it via localaddr.
+
+// CHECK-LABEL: define internal void @"?fin$0@0@main@@"({{i8( zeroext)?}} 
%abnormal_termination, i8* %frame_pointer)
+// CHECK: call void @"?fin$1@0@main@@"({{i8( zeroext)?}} 0, i8* %frame_pointer)
+int
+main() {
+  int Check = 0;
+  __try {
+Check = 3;
+  } __finally {
+__try {
+  Check += 2;
+} __finally {
+  Check += 4;
+}
+  }
+  return Check;
+}


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


[PATCH] D56585: [clang-tidy] Treat references to smart pointers correctly in use-after-move.

2019-01-15 Thread Martin Böhme via Phabricator via cfe-commits
mboehme added a comment.

In D56585#1358477 , @JonasToth wrote:

> LGTM, is there a bug report for this issue? If yes please close that too :)


Thanks for the reminder!

This was a bug that was reported internally, so there is no LLVM bug for this.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D56585



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


r351301 - [X86] Correct the type string for __builtin_ia32_gathersiv16sf to make the indices an integer type not an FP type.

2019-01-15 Thread Craig Topper via cfe-commits
Author: ctopper
Date: Tue Jan 15 23:17:14 2019
New Revision: 351301

URL: http://llvm.org/viewvc/llvm-project?rev=351301=rev
Log:
[X86] Correct the type string for __builtin_ia32_gathersiv16sf to make the 
indices an integer type not an FP type.

The element count and width remain the same. This went unnoticed because 
default conversion from builtin to intrinsic will generate a bitcast if the 
types don't match.

Modified:
cfe/trunk/include/clang/Basic/BuiltinsX86.def

Modified: cfe/trunk/include/clang/Basic/BuiltinsX86.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsX86.def?rev=351301=351300=351301=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsX86.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsX86.def Tue Jan 15 23:17:14 2019
@@ -985,7 +985,7 @@ TARGET_BUILTIN(__builtin_ia32_gather3siv
 TARGET_BUILTIN(__builtin_ia32_gather3siv8sf, "V8fV8fvC*V8iUcIi", "nV:256:", 
"avx512vl")
 TARGET_BUILTIN(__builtin_ia32_gather3siv8si, "V8iV8ivC*V8iUcIi", "nV:256:", 
"avx512vl")
 TARGET_BUILTIN(__builtin_ia32_gathersiv8df, "V8dV8dvC*V8iUcIi", "nV:512:", 
"avx512f")
-TARGET_BUILTIN(__builtin_ia32_gathersiv16sf, "V16fV16fvC*V16fUsIi", "nV:512:", 
"avx512f")
+TARGET_BUILTIN(__builtin_ia32_gathersiv16sf, "V16fV16fvC*V16iUsIi", "nV:512:", 
"avx512f")
 TARGET_BUILTIN(__builtin_ia32_gatherdiv8df, "V8dV8dvC*V8LLiUcIi", "nV:512:", 
"avx512f")
 TARGET_BUILTIN(__builtin_ia32_gatherdiv16sf, "V8fV8fvC*V8LLiUcIi", "nV:512:", 
"avx512f")
 TARGET_BUILTIN(__builtin_ia32_gathersiv8di, "V8LLiV8LLivC*V8iUcIi", "nV:512:", 
"avx512f")


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


[PATCH] D56731: Add -Wimplicit-ctad warning to diagnose CTAD on types with no user defined deduction guides.

2019-01-15 Thread Arthur O'Dwyer via Phabricator via cfe-commits
Quuxplusone added a comment.

In D56731#1359190 , @rsmith wrote:

> we need to keep in mind while making that decision that a warning that is 
> either off-by-default or turned off by nearly everyone delivers much less 
> value


Agreed. I would expect the D54565  version of 
`-Wctad` to be off-by-default, but turned **on** by nearly everyone, so it'd be 
a middle road. We'd have to try it and see. :)

> Are there open-source projects making use of CTAD on which we could perform 
> an analysis?

I think that's the same question as "Are there open-source projects making use 
of C++17?" If C++17 projects exist, then either they're making use of CTAD on 
purpose, or they're making use of it accidentally (in which case `-Wctad` would 
be able to count the number of accidents).  I just went and did an analysis of 
yomm2, Yato, and nytl: 
https://quuxplusone.github.io/blog/2019/01/16/counting-ctad/
yomm2 and Yato do not use CTAD. nytl uses CTAD heavily and intentionally, and 5 
of its 30 instances are on a single class which has no deduction guides. (I 
//think// there's no bug. If it is a subtle bug, then that would be amazingly 
strong evidence in favor of Eric's heuristic!)



> Hmm, I think I was actually thinking of cases more like:
> 
>   vector s = {{"foo", "bar"}};
>
> 
> ... which I have seen come up quite a lot.

Yikes! That's a new one to me. But not CTAD-related, I agree. :)


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

https://reviews.llvm.org/D56731



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


Re: r350920 - [Sema] Make canPassInRegisters return true if the CXXRecordDecl passed

2019-01-15 Thread Akira Hatanaka via cfe-commits
Yes, the behavior of the compiler doesn’t match what’s explained in the documentation anymore.Please take a look at the attached patch, which updates the documentation.

trivial-abi-docs.patch
Description: Binary data
CC’ing a couple more people who commented on the original patch.On Jan 10, 2019, at 11:30 PM, Richard Smith  wrote:This is an ABI break (theoretically), but due to its nature I'm not too concerned.Please update the documentation for the attribute to describe these new semantics, though: the documentation currently says that we're just treating certain special members as if they were trivial when determining whether we can pass in registers, and that's not true any more, because the ABI says that classes with only deleted copy and move ctors is never passed in registers regardless of triviality.On Thu, 10 Jan 2019, 23:10 Akira Hatanaka via cfe-commits isDependentType() || D->isInvalidDecl())
     return false;

+  if (D->hasAttr())
+    return true;
+
   // Clang <= 4 used the pre-C++11 rule, which ignores move operations.
   // The PS4 platform ABI follows the behavior of Clang 3.2.
   if (CCK == TargetInfo::CCK_ClangABI4OrPS4)

Modified: cfe/trunk/test/CodeGenCXX/trivial_abi.cpp
URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/trivial_abi.cpp?rev=350920=350919=350920=diff
==
--- cfe/trunk/test/CodeGenCXX/trivial_abi.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/trivial_abi.cpp Thu Jan 10 23:06:38 2019
@@ -1,5 +1,5 @@
-// RUN: %clang_cc1 -triple arm64-apple-ios11 -std=c++11 -fcxx-exceptions -fexceptions -emit-llvm -o - %s | FileCheck %s
-// RUN: %clang_cc1 -triple arm64-apple-ios11 -std=c++11 -fcxx-exceptions -fexceptions -fclang-abi-compat=4.0 -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple arm64-apple-ios11 -std=c++17 -fcxx-exceptions -fexceptions -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple arm64-apple-ios11 -std=c++17 -fcxx-exceptions -fexceptions -fclang-abi-compat=4.0 -emit-llvm -o - %s | FileCheck %s

 // CHECK: %[[STRUCT_SMALL:.*]] = type { i32* }
 // CHECK: %[[STRUCT_LARGE:.*]] = type { i32*, [128 x i32] }
@@ -43,6 +43,13 @@ struct HasNonTrivial {
   NonTrivial m;
 };

+struct __attribute__((trivial_abi)) CopyMoveDeleted {
+  CopyMoveDeleted(int);
+  CopyMoveDeleted(const CopyMoveDeleted &) = delete;
+  CopyMoveDeleted(CopyMoveDeleted &&) = delete;
+  int a;
+};
+
 // CHECK: define void @_Z14testParamSmall5Small(i64 %[[A_COERCE:.*]])
 // CHECK: %[[A:.*]] = alloca %[[STRUCT_SMALL]], align 8
 // CHECK: %[[COERCE_DIVE:.*]] = getelementptr inbounds %[[STRUCT_SMALL]], %[[STRUCT_SMALL]]* %[[A]], i32 0, i32 0
@@ -237,3 +244,11 @@ void calleeExceptionLarge(Large, Large);
 void testExceptionLarge() {
   calleeExceptionLarge(Large(), Large());
 }
+
+// A class with deleted copy and move constructors can still be passed or
+// returned in registers if the class is annotated with trivial_abi.
+
+// CHECK: define i64 @_Z19testCopyMoveDeletedi(i32 %
+CopyMoveDeleted testCopyMoveDeleted(int a) {
+  return a;
+}


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

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


[PATCH] D54428: [clangd] XPC transport layer, framework, test-client

2019-01-15 Thread Ali Tamur via Phabricator via cfe-commits
tamur added a comment.

This patch seems to have broken the compilation. I get the following error on a 
linux platform:
[12/14] Linking CXX executable bin/clangd
FAILED: bin/clangd 
: && /usr/local/google/home/tamur/src/llvm/2018_nov_12/llvm/Stable/bin/clang++  
-fPIC -fvisibility-inlines-hidden -Werror=date-time 
-Werror=unguarded-availability-new -std=c++11 -Wall -Wextra 
-Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers 
-pedantic -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default 
-Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor 
-Wstring-conversion -fdiagnostics-color -ffunction-sections -fdata-sections 
-fno-common -Woverloaded-virtual -Wno-nested-anon-types  -fuse-ld=lld 
-Wl,--color-diagnostics -Wl,-allow-shlib-undefined -Wl,-O3 
-Wl,--gc-sections 
tools/clang/tools/extra/clangd/tool/CMakeFiles/clangd.dir/ClangdMain.cpp.o  -o 
bin/clangd  -Wl,-rpath,"\$ORIGIN/../lib" lib/libLLVMSupport.so.8svn -lpthread 
lib/libclangBasic.so.8svn lib/libclangDaemon.so.8svn lib/libclangFormat.so.8svn 
lib/libclangFrontend.so.8svn lib/libclangSema.so.8svn 
lib/libclangTooling.so.8svn lib/libclangToolingCore.so.8svn && :
ld.lld: error: undefined symbol: clang::clangd::newXPCTransport()


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D54428



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


[PATCH] D55500: [Builtins] Implement __builtin_is_constant_evaluated for use in C++2a

2019-01-15 Thread Eric Fiselier via Phabricator via cfe-commits
EricWF updated this revision to Diff 181974.
EricWF added a comment.

Add the requested tests.


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

https://reviews.llvm.org/D55500

Files:
  include/clang/Basic/Builtins.def
  lib/AST/ExprConstant.cpp
  lib/Basic/Builtins.cpp
  test/CodeGenCXX/builtin-is-constant-evaluated.cpp
  test/Sema/builtins.c
  test/SemaCXX/builtin-is-constant-evaluated.cpp

Index: test/SemaCXX/builtin-is-constant-evaluated.cpp
===
--- /dev/null
+++ test/SemaCXX/builtin-is-constant-evaluated.cpp
@@ -0,0 +1,121 @@
+// RUN: %clang_cc1 -std=c++2a -verify %s -fcxx-exceptions -triple=x86_64-linux-gnu
+
+using size_t = decltype(sizeof(int));
+
+namespace std {
+inline constexpr bool is_constant_evaluated() noexcept {
+  return __builtin_is_constant_evaluated();
+}
+} // namespace std
+
+extern int dummy; // expected-note 1+ {{declared here}}
+
+static_assert(__builtin_is_constant_evaluated());
+static_assert(noexcept(__builtin_is_constant_evaluated()));
+
+constexpr bool b = __builtin_is_constant_evaluated();
+static_assert(b);
+
+const int n = __builtin_is_constant_evaluated() ? 4 : dummy;
+static_assert(n == 4);
+constexpr int cn = __builtin_is_constant_evaluated() ? 11 : dummy;
+static_assert(cn == 11);
+// expected-error@+1 {{'bn' must be initialized by a constant expression}}
+constexpr int bn = __builtin_is_constant_evaluated() ? dummy : 42; // expected-note {{non-const variable 'dummy' is not allowed}}
+
+const int n2 = __builtin_is_constant_evaluated() ? dummy : 42; // expected-note {{declared here}}
+static_assert(n2 == 42);   // expected-error {{static_assert expression is not an integral constant}}
+// expected-note@-1 {{initializer of 'n2' is not a constant expression}}
+
+template 
+struct Templ { static_assert(V); static_assert(Default); };
+Templ<__builtin_is_constant_evaluated()> x; // type X
+
+template 
+void test_if_constexpr() {
+  if constexpr (__builtin_is_constant_evaluated()) {
+static_assert(__is_same(T, int));
+  } else {
+using Test = typename T::DOES_NOT_EXIST;
+  }
+}
+template void test_if_constexpr();
+
+void test_array_decl() {
+  char x[__builtin_is_constant_evaluated() + std::is_constant_evaluated()];
+  static_assert(sizeof(x) == 2, "");
+}
+
+void test_case_stmt(int x) {
+  switch (x) {
+  case 0:// OK
+  case __builtin_is_constant_evaluated():// expected-note {{previous case}}
+  case std::is_constant_evaluated() + __builtin_is_constant_evaluated(): // expected-note {{previous case}}
+  case 1:// expected-error {{duplicate case value '1'}}
+  case 2:// expected-error {{duplicate case value '2'}}
+break;
+  }
+}
+
+constexpr size_t good_array_size() {
+  return std::is_constant_evaluated() ? 42 : static_cast(-1);
+}
+
+constexpr size_t bad_array_size() {
+  return std::is_constant_evaluated() ? static_cast(-1) : 13;
+}
+
+template 
+constexpr T require_constexpr(T v) {
+  if (!std::is_constant_evaluated())
+throw "BOOM";
+  return v;
+}
+
+void test_new_expr() {
+  constexpr size_t TooLarge = -1;
+  auto *x = new int[std::is_constant_evaluated() ? 1 : TooLarge];  // expected-error {{array is too large}}
+  auto *x2 = new int[std::is_constant_evaluated() ? TooLarge : 1]; // OK
+  auto *y = new int[1][std::is_constant_evaluated() ? TooLarge : 1]{}; // expected-error {{array is too large}}
+  auto *y2 = new int[1][require_constexpr(42)];
+}
+
+void test_alignas_operand() {
+  alignas(std::is_constant_evaluated() ? 8 : 2) char dummy;
+  static_assert(__alignof(dummy) == 8);
+}
+
+void test_static_assert_operand() {
+  static_assert(std::is_constant_evaluated(), "");
+}
+
+void test_enumerator() {
+  enum MyEnum {
+ZERO = 0,
+ONE = std::is_constant_evaluated()
+  };
+  static_assert(ONE == 1, "");
+}
+
+struct TestBitfieldWidth {
+  unsigned Bits : std::is_constant_evaluated();
+};
+
+void test_operand_of_noexcept_fn() noexcept(std::is_constant_evaluated());
+static_assert(noexcept(test_operand_of_noexcept_fn()), "");
+
+
+namespace test_ref_initialization {
+int x;
+int y;
+int  = __builtin_is_constant_evaluated() ? x : y;
+static_assert( == );
+
+} // namespace test_ref_initialization
+
+#if defined(__cpp_conditional_explicit)
+struct TestConditionalExplicit {
+  explicit(__builtin_is_constant_evaluated()) TestConditionalExplicit(int) {}
+};
+TestConditionalExplicit e = 42;
+#endif
Index: test/Sema/builtins.c
===
--- test/Sema/builtins.c
+++ test/Sema/builtins.c
@@ -314,3 +314,9 @@
   memcpy(buf, src, 11); // expected-warning{{'memcpy' will always overflow; destination buffer has size 10, but size argument is 11}}
   

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

2019-01-15 Thread Jennifer Yu via Phabricator via cfe-commits
jyu2 updated this revision to Diff 181973.
jyu2 marked an inline comment as done.
jyu2 added a comment.

Change error message.


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

https://reviews.llvm.org/D56571

Files:
  include/clang/AST/Expr.h
  include/clang/AST/ExprCXX.h
  include/clang/AST/ExprObjC.h
  include/clang/AST/Stmt.h
  include/clang/Basic/DiagnosticASTKinds.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Sema/Sema.h
  lib/AST/ASTImporter.cpp
  lib/AST/Stmt.cpp
  lib/AST/StmtPrinter.cpp
  lib/AST/StmtProfile.cpp
  lib/Analysis/CFG.cpp
  lib/CodeGen/CGStmt.cpp
  lib/CodeGen/CodeGenFunction.h
  lib/Parse/ParseStmtAsm.cpp
  lib/Sema/SemaStmtAsm.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReaderStmt.cpp
  lib/Serialization/ASTWriterStmt.cpp
  test/Analysis/asm-goto.cpp
  test/CodeGen/asm-goto.c
  test/CodeGen/asm.c
  test/CodeGen/inline-asm-mixed-style.c
  test/Coverage/c-language-features.inc
  test/PCH/asm.h
  test/Parser/asm-goto.c
  test/Parser/asm-goto.cpp
  test/Parser/asm.c
  test/Parser/asm.cpp
  test/Sema/asm.c
  test/Sema/inline-asm-validate-tmpl.cpp

Index: test/Sema/inline-asm-validate-tmpl.cpp
===
--- test/Sema/inline-asm-validate-tmpl.cpp
+++ test/Sema/inline-asm-validate-tmpl.cpp
@@ -23,3 +23,13 @@
 	asm("rol %1, %0" :"=r"(value): "I"(N + 1));
 }
 int	foo() { testc<2>(10); }
+
+// these should compile without error
+template  bool testd()
+{
+  __asm goto ("" : : : : lab);
+  return true;
+lab:
+  return false;
+}
+bool foox() { return testd<0> (); }
Index: test/Sema/asm.c
===
--- test/Sema/asm.c
+++ test/Sema/asm.c
@@ -295,3 +295,28 @@
   return r0 + r1;
 }
 
+void test18()
+{
+  // expected-error@+2 {{duplicate use of asm operand name "lab"}}
+  // expected-note@+1 {{asm operand name "lab" first referenced here}}
+  asm goto ("" : : : : lab, lab, lab2, lab);
+  // expected-error@+2 {{duplicate use of asm operand name "lab"}}
+  // expected-note@+1 {{asm operand name "lab" first referenced here}}
+  asm goto ("xorw %[lab], %[lab]; je %l[lab]" : : [lab] "i" (0) : : lab);
+lab:;
+lab2:;
+  int x,x1;
+  // expected-error@+2 {{duplicate use of asm operand name "lab"}}
+  // expected-note@+1 {{asm operand name "lab" first referenced here}}
+  asm ("" : [lab] "=r" (x),[lab] "+r" (x) : [lab1] "r" (x));
+  // expected-error@+2 {{duplicate use of asm operand name "lab"}}
+  // expected-note@+1 {{asm operand name "lab" first referenced here}}
+  asm ("" : [lab] "=r" (x1) : [lab] "r" (x));
+  // expected-error@+1 {{operand with 'l' modifier must refer to a label}}
+  asm ("jne %l0"::"r"(&));
+  // expected-error@+1 {{invalid operand number in inline asm string}}
+  asm ("jne %l0":::);
+  // expected-error@+1 {{operand with 'l' modifier must refer to a label}}
+  asm goto ("jne %l0"::"r"(x)::lab);
+  asm goto ("jne %l0"lab);
+}
Index: test/Parser/asm.cpp
===
--- test/Parser/asm.cpp
+++ test/Parser/asm.cpp
@@ -7,3 +7,28 @@
 int foo5 asm (U"bar5"); // expected-error {{cannot use unicode string literal in 'asm'}}
 int foo6 asm ("bar6"_x); // expected-error {{string literal with user-defined suffix cannot be used here}}
 int foo6 asm ("" L"bar7"); // expected-error {{cannot use wide string literal in 'asm'}}
+
+int zoo ()
+{
+  int x,cond,*e;
+  // expected-error@+1 {{expected ')'}}
+  asm ("mov %[e], %[e]" : : [e] "rm" (*e)::a)
+  // expected-error@+1  {{expected ':'}}
+  asm goto ("decl %0; jnz %l[a]" :"=r"(x): "m"(x) : "memory" : a);
+  // expected-error@+1 {{expected identifie}}
+  asm goto ("decl %0;" :: "m"(x) : "memory" : );
+  // expected-error@+1  {{expected ':'}}
+  asm goto ("decl %0;" :: "m"(x) : "memory" );
+  // expected-error@+1 {{use of undeclared label 'x'}}
+  asm goto ("decl %0;" :: "m"(x) : "memory" :x);
+  // expected-error@+1 {{use of undeclared label 'b'}}
+  asm goto ("decl %0;" :: "m"(x) : "memory" :b);
+  // expected-error@+1 {{invalid operand number in inline asm string}}
+  asm goto ("testl %0, %0; jne %l3;" :: "r"(cond)::label_true, loop)
+  // expected-error@+1 {{unknown symbolic operand name in inline assembly string}}
+  asm goto ("decl %0; jnz %l[b]" :: "m"(x) : "memory" : a);
+label_true:
+loop:
+a:
+  return 0;
+}
Index: test/Parser/asm.c
===
--- test/Parser/asm.c
+++ test/Parser/asm.c
@@ -16,6 +16,31 @@
   asm _Atomic (""); // expected-warning {{ignored _Atomic qualifier on asm}}
 }
 
+int zoo ()
+{
+  int x,cond,*e;
+  // expected-error@+1 {{expected ')'}}
+  asm ("mov %[e], %[e]" : : [e] "rm" (*e)::a)
+  // expected-error@+1 {{expected ':'}}
+  asm goto ("decl %0; jnz %l[a]" :"=r"(x): "m"(x) : "memory" : a);
+  // expected-error@+1 {{expected identifie}}
+  asm goto ("decl %0;" :: "m"(x) : "memory" : );
+  // expected-error@+1 {{expected ':'}}
+  asm goto ("decl 

[PATCH] D56731: Add -Wimplicit-ctad warning to diagnose CTAD on types with no user defined deduction guides.

2019-01-15 Thread Eric Fiselier via Phabricator via cfe-commits
EricWF updated this revision to Diff 181972.
EricWF added a comment.

Address review comments.

- Use "%0 maybe not intend to support ctad" like warning text.
- Add note about suppression.
- Rename `-Wimplicit-ctad` -> `-Wctad-maybe-unsupported` (Perhaps it should be 
`-Wctad-maybe-unintended`?)

Add more tests!


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

https://reviews.llvm.org/D56731

Files:
  include/clang/Basic/DiagnosticGroups.td
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Sema/SemaInit.cpp
  test/SemaCXX/cxx1z-class-template-argument-deduction.cpp

Index: test/SemaCXX/cxx1z-class-template-argument-deduction.cpp
===
--- test/SemaCXX/cxx1z-class-template-argument-deduction.cpp
+++ test/SemaCXX/cxx1z-class-template-argument-deduction.cpp
@@ -409,6 +409,86 @@
 
 }
 
+#pragma clang diagnostic push
+#pragma clang diagnostic warning "-Wctad-maybe-unsupported"
+namespace test_implicit_ctad_warning {
+
+template 
+struct Tag {};
+
+template 
+struct NoExplicit { // expected-note {{add a user-defined deduction guide to suppress this warning}}
+  NoExplicit(T) {}
+  NoExplicit(T, int) {}
+};
+
+// expected-warning@+1 {{'NoExplicit' may not intend to support class template argument deduction}}
+NoExplicit ne(42);
+
+template 
+struct HasExplicit {
+  HasExplicit(U) {}
+  HasExplicit(U, int) {}
+};
+template  HasExplicit(U, int) -> HasExplicit>;
+
+HasExplicit he(42);
+
+// Motivating examples from (taken from Stephan Lavavej's 2018 Cppcon talk)
+template 
+struct AmateurPair { // expected-note {{add a user-defined deduction guide to suppress this warning}}
+  T first;
+  U second;
+  explicit AmateurPair(const T , const U ) {}
+};
+// expected-warning@+1 {{'AmateurPair' may not intend to support class template argument deduction}}
+AmateurPair p1(42, "hello world"); // deduces to Pair
+
+template 
+struct AmateurPair2 { // expected-note {{add a user-defined deduction guide to suppress this warning}}
+  T first;
+  U second;
+  explicit AmateurPair2(T t, U u) {}
+};
+// expected-warning@+1 {{'AmateurPair2' may not intend to support class template argument deduction}}
+AmateurPair2 p2(42, "hello world"); // deduces to Pair2
+
+template 
+struct ProPair {
+  T first; U second;
+explicit ProPair(T const& t, U  const& u)  {}
+};
+template
+ProPair(T1, T2) -> ProPair;
+ProPair p3(42, "hello world"); // deduces to ProPair
+static_assert(__is_same(decltype(p3), ProPair));
+
+// Test that user-defined explicit guides suppress the warning even if they
+// aren't used as candidates.
+template 
+struct TestExplicitCtor {
+  TestExplicitCtor(T) {}
+};
+template 
+explicit TestExplicitCtor(TestExplicitCtor const&) -> TestExplicitCtor;
+TestExplicitCtor ce1{42};
+TestExplicitCtor ce2 = ce1;
+static_assert(__is_same(decltype(ce2), TestExplicitCtor), "");
+
+struct allow_ctad_t {
+  allow_ctad_t() = delete;
+};
+
+template 
+struct TestSuppression {
+  TestSuppression(T) {}
+};
+TestSuppression(allow_ctad_t)->TestSuppression;
+TestSuppression ta("abc");
+static_assert(__is_same(decltype(ta), TestSuppression), "");
+}
+#pragma clang diagnostic pop
+
 #else
 
 // expected-no-diagnostics
Index: lib/Sema/SemaInit.cpp
===
--- lib/Sema/SemaInit.cpp
+++ lib/Sema/SemaInit.cpp
@@ -9264,9 +9264,14 @@
   OverloadCandidateSet Candidates(Kind.getLocation(),
   OverloadCandidateSet::CSK_Normal);
   OverloadCandidateSet::iterator Best;
+
+  bool HasAnyDeductionGuide = false;
+
   auto tryToResolveOverload =
   [&](bool OnlyListConstructors) -> OverloadingResult {
 Candidates.clear(OverloadCandidateSet::CSK_Normal);
+HasAnyDeductionGuide = false;
+
 for (auto I = Guides.begin(), E = Guides.end(); I != E; ++I) {
   NamedDecl *D = (*I)->getUnderlyingDecl();
   if (D->isInvalidDecl())
@@ -9278,6 +9283,9 @@
   if (!GD)
 continue;
 
+  if (!GD->isImplicit())
+HasAnyDeductionGuide = true;
+
   // C++ [over.match.ctor]p1: (non-list copy-initialization from non-class)
   //   For copy-initialization, the candidate functions are all the
   //   converting constructors (12.3.1) of that class.
@@ -9430,5 +9438,15 @@
   Diag(TSInfo->getTypeLoc().getBeginLoc(),
diag::warn_cxx14_compat_class_template_argument_deduction)
   << TSInfo->getTypeLoc().getSourceRange() << 1 << DeducedType;
+
+  // Warn if CTAD was used on a type that does not have any user-defined
+  // deduction guides.
+  if (!HasAnyDeductionGuide) {
+Diag(TSInfo->getTypeLoc().getBeginLoc(),
+ diag::warn_ctad_maybe_unsupported)
+<< TemplateName;
+Diag(Template->getLocation(), diag::note_suppress_ctad_maybe_unsupported);
+  }
+
   return DeducedType;
 }
Index: include/clang/Basic/DiagnosticSemaKinds.td
===
--- 

r351298 - [WebAssembly] COWS has been renamed to WASI.

2019-01-15 Thread Dan Gohman via cfe-commits
Author: djg
Date: Tue Jan 15 21:23:57 2019
New Revision: 351298

URL: http://llvm.org/viewvc/llvm-project?rev=351298=rev
Log:
[WebAssembly] COWS has been renamed to WASI.

Modified:
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/test/Driver/wasm-toolchain.c
cfe/trunk/test/Driver/wasm-toolchain.cpp

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=351298=351297=351298=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Tue Jan 15 21:23:57 2019
@@ -571,7 +571,7 @@ TargetInfo *AllocateTarget(const llvm::T
 !Triple.isOSBinFormatWasm())
   return nullptr;
 if (Triple.getOS() != llvm::Triple::UnknownOS &&
-Triple.getOS() != llvm::Triple::COWS)
+Triple.getOS() != llvm::Triple::WASI)
   return nullptr;
 return new WebAssemblyOSTargetInfo(Triple, Opts);
   case llvm::Triple::wasm64:
@@ -580,7 +580,7 @@ TargetInfo *AllocateTarget(const llvm::T
 !Triple.isOSBinFormatWasm())
   return nullptr;
 if (Triple.getOS() != llvm::Triple::UnknownOS &&
-Triple.getOS() != llvm::Triple::COWS)
+Triple.getOS() != llvm::Triple::WASI)
   return nullptr;
 return new WebAssemblyOSTargetInfo(Triple, Opts);
 

Modified: cfe/trunk/test/Driver/wasm-toolchain.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/wasm-toolchain.c?rev=351298=351297=351298=diff
==
--- cfe/trunk/test/Driver/wasm-toolchain.c (original)
+++ cfe/trunk/test/Driver/wasm-toolchain.c Tue Jan 15 21:23:57 2019
@@ -24,17 +24,17 @@
 
 // A basic C link command-line with known OS.
 
-// RUN: %clang -### -no-canonical-prefixes -target wasm32-unknown-cows-musl 
--sysroot=/foo -fuse-ld=wasm-ld %s 2>&1 | FileCheck -check-prefix=LINK_KNOWN %s
+// RUN: %clang -### -no-canonical-prefixes -target wasm32-unknown-wasi-musl 
--sysroot=/foo -fuse-ld=wasm-ld %s 2>&1 | FileCheck -check-prefix=LINK_KNOWN %s
 // LINK_KNOWN: clang{{.*}}" "-cc1" {{.*}} "-o" "[[temp:[^"]*]]"
-// LINK_KNOWN: wasm-ld{{.*}}" "-L/foo/lib/wasm32-cows-musl" "crt1.o" 
"[[temp]]" "-lc" "{{.*[/\\]}}libclang_rt.builtins-wasm32.a" "-o" "a.out"
+// LINK_KNOWN: wasm-ld{{.*}}" "-L/foo/lib/wasm32-wasi-musl" "crt1.o" 
"[[temp]]" "-lc" "{{.*[/\\]}}libclang_rt.builtins-wasm32.a" "-o" "a.out"
 
 // A basic C link command-line with optimization with known OS.
 
-// RUN: %clang -### -O2 -no-canonical-prefixes -target 
wasm32-unknown-cows-musl --sysroot=/foo -fuse-ld=wasm-ld %s 2>&1 | FileCheck 
-check-prefix=LINK_OPT_KNOWN %s
+// RUN: %clang -### -O2 -no-canonical-prefixes -target 
wasm32-unknown-wasi-musl --sysroot=/foo -fuse-ld=wasm-ld %s 2>&1 | FileCheck 
-check-prefix=LINK_OPT_KNOWN %s
 // LINK_OPT_KNOWN: clang{{.*}}" "-cc1" {{.*}} "-o" "[[temp:[^"]*]]"
-// LINK_OPT_KNOWN: wasm-ld{{.*}}" "-L/foo/lib/wasm32-cows-musl" "crt1.o" 
"[[temp]]" "-lc" "{{.*[/\\]}}libclang_rt.builtins-wasm32.a" "-o" "a.out"
+// LINK_OPT_KNOWN: wasm-ld{{.*}}" "-L/foo/lib/wasm32-wasi-musl" "crt1.o" 
"[[temp]]" "-lc" "{{.*[/\\]}}libclang_rt.builtins-wasm32.a" "-o" "a.out"
 
 // A basic C compile command-line with known OS.
 
-// RUN: %clang -### -no-canonical-prefixes -target wasm32-unknown-cows-musl 
--sysroot=/foo %s 2>&1 | FileCheck -check-prefix=COMPILE %s
-// COMPILE: clang{{.*}}" "-cc1" {{.*}} "-internal-isystem" 
"/foo/include/wasm32-cows-musl" "-internal-isystem" "/foo/include"
+// RUN: %clang -### -no-canonical-prefixes -target wasm32-unknown-wasi-musl 
--sysroot=/foo %s 2>&1 | FileCheck -check-prefix=COMPILE %s
+// COMPILE: clang{{.*}}" "-cc1" {{.*}} "-internal-isystem" 
"/foo/include/wasm32-wasi-musl" "-internal-isystem" "/foo/include"

Modified: cfe/trunk/test/Driver/wasm-toolchain.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/wasm-toolchain.cpp?rev=351298=351297=351298=diff
==
--- cfe/trunk/test/Driver/wasm-toolchain.cpp (original)
+++ cfe/trunk/test/Driver/wasm-toolchain.cpp Tue Jan 15 21:23:57 2019
@@ -24,17 +24,17 @@
 
 // A basic C++ link command-line with known OS.
 
-// RUN: %clangxx -### -no-canonical-prefixes -target wasm32-unknown-cows-musl 
--sysroot=/foo -fuse-ld=wasm-ld --stdlib=c++ %s 2>&1 | FileCheck 
-check-prefix=LINK_KNOWN %s
+// RUN: %clangxx -### -no-canonical-prefixes -target wasm32-unknown-wasi-musl 
--sysroot=/foo -fuse-ld=wasm-ld --stdlib=c++ %s 2>&1 | FileCheck 
-check-prefix=LINK_KNOWN %s
 // LINK_KNOWN: clang{{.*}}" "-cc1" {{.*}} "-o" "[[temp:[^"]*]]"
-// LINK_KNOWN: wasm-ld{{.*}}" "-L/foo/lib/wasm32-cows-musl" "crt1.o" 
"[[temp]]" "-lc++" "-lc++abi" "-lc" "{{.*[/\\]}}libclang_rt.builtins-wasm32.a" 
"-o" "a.out"
+// LINK_KNOWN: wasm-ld{{.*}}" "-L/foo/lib/wasm32-wasi-musl" "crt1.o" 
"[[temp]]" "-lc++" "-lc++abi" "-lc" "{{.*[/\\]}}libclang_rt.builtins-wasm32.a" 

[PATCH] D56731: Add -Wimplicit-ctad warning to diagnose CTAD on types with no user defined deduction guides.

2019-01-15 Thread Eric Fiselier via Phabricator via cfe-commits
EricWF marked 10 inline comments as done.
EricWF added inline comments.



Comment at: include/clang/Basic/DiagnosticSemaKinds.td:2129
+def warn_class_template_argument_deduction_no_user_defined_guides : Warning<
+  "using class template argument deduction for %0 that has no user-defined 
deduction guides" >,
+  InGroup, DefaultIgnore;

rsmith wrote:
> gromer wrote:
> > I'd prefer a phrasing more along the lines of "using class template 
> > argument deduction for %0 that might not intentionally support it". That 
> > gives us more room to do things like add an attribute later if necessary, 
> > and it helps the user understand why this warning indicates a potential 
> > problem.
> I like that approach; something like "using class template argument deduction 
> for %0 that might not intend to support it" -- or perhaps more directly "%0 
> might not intend to support class template argument deduction" -- along with 
> a note describing how to syntactically suppress the warning (w"add a 
> deduction guide to suppress this warning" or "use the [[clang::ctad]] 
> attribute to suppress this warning" or whatever we decide is best).
This sounds like a reasonable change to me. Done.

I'm not sure an attribute is needed at this point; AFAIK there is no case where 
a user defined guide can't be added. Even if it's just a dummy guide to 
suppress the warning. For example:

```

struct allow_ctad_t {
  allow_ctad_t() = delete;
};

template 
struct TestSuppression {
  TestSuppression(int, T) {}
};
TestSuppression(allow_ctad_t) -> TestSuppression;
```

Also, before we add an attribute, we want to be sure that it's not harmful to 
allowing users to suppress the warning without actually addressing the root 
problem (tha implicit CTAD results are often surprising). I would like to see 
real world examples of types that don't need user-defined guides to work.




Comment at: lib/Sema/SemaInit.cpp:9287
 
+  HasUserDeclaredDeductionGuideCandidate |= !GD->isImplicit();
+

rsmith wrote:
> Quuxplusone wrote:
> > Nitpick: I don't know if this is LLVM style, but I wish this were written as
> > 
> > if (!GD->isImplicit())
> >   HasUserDeclaredDeductionGuideCandidate = true;
> > 
> > for clarity. Also, is it "user-defined" (per the error message) or 
> > "user-declared" (per the name of this variable)?
> Formally, it's actually just "any deduction guides". Constructors aren't 
> transformed into deduction guides; rather, deduction guides and constructors 
> both form candidates for CTAD. So `HasAnyDeductionGuides` would work. (I also 
> think we should omit the "candidates", because we don't care whether any 
> deduction guides were candidates for this particular overload resolution, 
> only whether there are any at all -- if we're excluding explicit deduction 
> guides and the only deduction guides are explicit, we still want to (and do!) 
> suppress the warning.
I changed the name to `HasAnyDeductionGuides`.

Otherwise, I think I've address all of the cases in your comment.


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

https://reviews.llvm.org/D56731



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


[PATCH] D56353: Replace cc1 options '-mdisable-fp-elim' and '-momit-leaf-frame-pointer' with'-mframe-pointer='

2019-01-15 Thread Chandler Carruth via Phabricator via cfe-commits
chandlerc requested changes to this revision.
chandlerc added a comment.
This revision now requires changes to proceed.

Wow, thanks for the cleanups. This is much easier to read as a consequence. And 
sorry it took a while to get you another round of review. Comments below.




Comment at: include/clang/Driver/CC1Options.td:270
+def mframe_pointer_EQ : Joined<["-"], "mframe-pointer=">,
+  HelpText<"Specify effect of frame pointer elimination optimization 
(all,non-leaf,none)">, Values<"all,non-leaf,none">;
 def mdisable_tail_calls : Flag<["-"], "mdisable-tail-calls">,

Should say more `Specify which frame pointers to retain (all, non-leaf, none)`.



Comment at: lib/Driver/ToolChains/Clang.cpp:574
 
-static bool shouldUseFramePointer(const ArgList ,
-  const llvm::Triple ) {
-  if (Arg *A = Args.getLastArg(options::OPT_fno_omit_frame_pointer,
-   options::OPT_fomit_frame_pointer))
-return A->getOption().matches(options::OPT_fno_omit_frame_pointer) ||
-   mustUseNonLeafFramePointerForTarget(Triple);
-
-  if (Args.hasArg(options::OPT_pg))
-return true;
-
-  return useFramePointerForTargetByDefault(Args, Triple);
-}
+static StringRef DetermineFramePointer(const ArgList ,
+   const llvm::Triple ) {

Keep LLVM coding convention naming pattern please.



Comment at: lib/Driver/ToolChains/Clang.cpp:576-579
+  Arg *FP = Args.getLastArg(options::OPT_fno_omit_frame_pointer,
+options::OPT_fomit_frame_pointer);
+  Arg *LeafFP = Args.getLastArg(options::OPT_mno_omit_leaf_frame_pointer,
+options::OPT_momit_leaf_frame_pointer);

This still doesn't make sense to me...

If the user specifies `-fomit-frame-point` or `-fno-omit-frame-pointer` *after* 
`-momit-leaf-frame-pointer` or `-mno-omit-leaf-frame-pointer`, then that last 
flag should win...

I think you need to first get the "base" FP state by checking the main two 
flags. Then you need to get the "last" FP state by checking *all four flags*. 
When the last flag is a leaf flag, then the state is determined by the base + 
the last. When the last flag is not one of the leaf flags, then the last flag 
fully specifies the result.

I think you can also process these variables into something simpler to test 
below, essentially handling all the matching logic in one place.


Repository:
  rC Clang

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

https://reviews.llvm.org/D56353



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


[PATCH] D56411: [CUDA][HIP][Sema] Fix template kernel with function as template parameter

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

In D56411#1352602 , @yaxunl wrote:

> In D56411#1352332 , @rjmccall wrote:
>
> > This patch still doesn't make any sense.  You don't need to do any special 
> > validation when passing a function as a template argument.  When Sema 
> > instantiates the template definition, it'll rebuild the expressions that 
> > refer to the template parameter, which will trigger the normal checking for 
> > whether those expressions are illegally referencing a host function from 
> > the device, etc.  All you need to do is suppress that checking (whether it 
> > happens in a template definition or not) for references from 
> > non-potentially-evaluated contexts.
>
>
> If you look at line 6583 of lib/Sema/SemaTemplate.cpp, you will see clang 
> does the check if the function needs overloading resolution. However, clang 
> missed the check if the function does not need overloading resolution. That's 
> why I need to add the check at line 6593. All the other stuff is just to help 
> make this check.
>
> why clang does not do the reference check when there is no overloading 
> resolution?


We should have already done the check for a non-overloaded function reference 
as part of building the DRE.  See `Sema::BuildDeclarationNameExpr`.  Template 
argument checking can resolve an overload set based on the type of the template 
parameter, so overload sets have to be treated specially there.

> I think in usual cases clang already does that check during template argument 
> parsing, so it does not need to do that again at line 6593. Unfortunately, 
> for CUDA host/device check, it has to be skipped in template argument parsing 
> and deferred to line 6593.

Again, you really should not ever impose this restriction in template arguments.


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

https://reviews.llvm.org/D56411



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


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

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

It's an interesting idea at least, and it does seem like there ought to be some 
way to express it, at least internally.  A `-cc1` option is fine for your 
purposes, right?


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

https://reviews.llvm.org/D53153



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


[PATCH] D49466: Initial implementation of -fmacro-prefix-map and -ffile-prefix-map

2019-01-15 Thread Dan McGregor via Phabricator via cfe-commits
dankm updated this revision to Diff 181964.
dankm marked an inline comment as done.
dankm added a comment.

Enforce path mapping. This requires LLVM review D56769 
.


Repository:
  rC Clang

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

https://reviews.llvm.org/D49466

Files:
  include/clang/Basic/DiagnosticDriverKinds.td
  include/clang/Driver/Options.td
  include/clang/Lex/PreprocessorOptions.h
  lib/CodeGen/CGDebugInfo.cpp
  lib/CodeGen/CGDebugInfo.h
  lib/Driver/ToolChains/Clang.cpp
  lib/Driver/ToolChains/FreeBSD.cpp
  lib/Driver/ToolChains/Gnu.cpp
  lib/Frontend/CompilerInvocation.cpp
  lib/Lex/PPMacroExpansion.cpp
  test/CodeGen/debug-prefix-map.c
  test/Driver/debug-prefix-map.S
  test/Driver/debug-prefix-map.c
  test/Preprocessor/file_test.c
  test/Preprocessor/file_test.h

Index: test/Preprocessor/file_test.h
===
--- /dev/null
+++ test/Preprocessor/file_test.h
@@ -0,0 +1,2 @@
+filename: __FILE__
+basefile: __BASE_FILE__
Index: test/Preprocessor/file_test.c
===
--- /dev/null
+++ test/Preprocessor/file_test.c
@@ -0,0 +1,22 @@
+// RUN: %clang -E -ffile-prefix-map=%p=/UNLIKELY_PATH/empty -c -o - %s | FileCheck %s
+// RUN: %clang -E -fmacro-prefix-map=%p=/UNLIKELY_PATH/empty -c -o - %s | FileCheck %s
+// RUN: %clang -E -fmacro-prefix-map=%p=/UNLIKELY_PATH=empty -c -o - %s | FileCheck %s -check-prefix CHECK-EVIL
+// RUN: %clang -E -fmacro-prefix-map=%p/= -c -o - %s | FileCheck %s --check-prefix CHECK-REMOVE
+
+filename: __FILE__
+#include "file_test.h"
+
+// CHECK: filename: "/UNLIKELY_PATH/empty{{[/\\]}}file_test.c"
+// CHECK: filename: "/UNLIKELY_PATH/empty{{[/\\]}}file_test.h"
+// CHECK: basefile: "/UNLIKELY_PATH/empty{{[/\\]}}file_test.c"
+// CHECK-NOT: filename:
+
+// CHECK-EVIL: filename: "/UNLIKELY_PATH=empty{{[/\\]}}file_test.c"
+// CHECK-EVIL: filename: "/UNLIKELY_PATH=empty{{[/\\]}}file_test.h"
+// CHECK-EVIL: basefile: "/UNLIKELY_PATH=empty{{[/\\]}}file_test.c"
+// CHECK-EVIL-NOT: filename:
+
+// CHECK-REMOVE: filename: "file_test.c"
+// CHECK-REMOVE: filename: "file_test.h"
+// CHECK-REMOVE: basefile: "file_test.c"
+// CHECK-REMOVE-NOT: filename:
Index: test/Driver/debug-prefix-map.c
===
--- test/Driver/debug-prefix-map.c
+++ test/Driver/debug-prefix-map.c
@@ -1,9 +1,28 @@
-// RUN: %clang -### -fdebug-prefix-map=old %s 2>&1 | FileCheck %s -check-prefix CHECK-INVALID
-// RUN: %clang -### -fdebug-prefix-map=old=new %s 2>&1 | FileCheck %s -check-prefix CHECK-SIMPLE
-// RUN: %clang -### -fdebug-prefix-map=old=n=ew %s 2>&1 | FileCheck %s -check-prefix CHECK-COMPLEX
-// RUN: %clang -### -fdebug-prefix-map=old= %s 2>&1 | FileCheck %s -check-prefix CHECK-EMPTY
+// RUN: %clang -### -fdebug-prefix-map=old %s 2>&1 | FileCheck %s -check-prefix CHECK-DEBUG-INVALID
+// RUN: %clang -### -fmacro-prefix-map=old %s 2>&1 | FileCheck %s -check-prefix CHECK-MACRO-INVALID
+// RUN: %clang -### -ffile-prefix-map=old %s 2>&1 | FileCheck %s -check-prefix CHECK-FILE-INVALID
 
-// CHECK-INVALID: error: invalid argument 'old' to -fdebug-prefix-map
-// CHECK-SIMPLE: fdebug-prefix-map=old=new
-// CHECK-COMPLEX: fdebug-prefix-map=old=n=ew
-// CHECK-EMPTY: fdebug-prefix-map=old=
+// RUN: %clang -### -fdebug-prefix-map=old=new %s 2>&1 | FileCheck %s -check-prefix CHECK-DEBUG-SIMPLE
+// RUN: %clang -### -fmacro-prefix-map=old=new %s 2>&1 | FileCheck %s -check-prefix CHECK-MACRO-SIMPLE
+// RUN: %clang -### -ffile-prefix-map=old=new %s 2>&1 | FileCheck %s -check-prefix CHECK-DEBUG-SIMPLE
+// RUN: %clang -### -ffile-prefix-map=old=new %s 2>&1 | FileCheck %s -check-prefix CHECK-MACRO-SIMPLE
+
+// RUN: %clang -### -fdebug-prefix-map=old=n=ew %s 2>&1 | FileCheck %s -check-prefix CHECK-DEBUG-COMPLEX
+// RUN: %clang -### -fmacro-prefix-map=old=n=ew %s 2>&1 | FileCheck %s -check-prefix CHECK-MACRO-COMPLEX
+// RUN: %clang -### -ffile-prefix-map=old=n=ew %s 2>&1 | FileCheck %s -check-prefix CHECK-DEBUG-COMPLEX
+// RUN: %clang -### -ffile-prefix-map=old=n=ew %s 2>&1 | FileCheck %s -check-prefix CHECK-MACRO-COMPLEX
+
+// RUN: %clang -### -fdebug-prefix-map=old= %s 2>&1 | FileCheck %s -check-prefix CHECK-DEBUG-EMPTY
+// RUN: %clang -### -fmacro-prefix-map=old= %s 2>&1 | FileCheck %s -check-prefix CHECK-MACRO-EMPTY
+// RUN: %clang -### -ffile-prefix-map=old= %s 2>&1 | FileCheck %s -check-prefix CHECK-DEBUG-EMPTY
+// RUN: %clang -### -ffile-prefix-map=old= %s 2>&1 | FileCheck %s -check-prefix CHECK-MACRO-EMPTY
+
+// CHECK-DEBUG-INVALID: error: invalid argument 'old' to -fdebug-prefix-map
+// CHECK-MACRO-INVALID: error: invalid argument 'old' to -fmacro-prefix-map
+// CHECK-FILE-INVALID: error: invalid argument 'old' to -ffile-prefix-map
+// CHECK-DEBUG-SIMPLE: fdebug-prefix-map=old=new
+// CHECK-MACRO-SIMPLE: fmacro-prefix-map=old=new
+// CHECK-DEBUG-COMPLEX: fdebug-prefix-map=old=n=ew
+// 

r351294 - [SemaCXX] Unconfuse Clang when std::align_val_t is unscoped in C++03

2019-01-15 Thread Eric Fiselier via cfe-commits
Author: ericwf
Date: Tue Jan 15 18:34:36 2019
New Revision: 351294

URL: http://llvm.org/viewvc/llvm-project?rev=351294=rev
Log:
[SemaCXX] Unconfuse Clang when std::align_val_t is unscoped in C++03

When -faligned-allocation is specified in C++03 libc++ defines
std::align_val_t as an unscoped enumeration type (because Clang didn't
provide scoped enumerations as an extension until 8.0).
Unfortunately Clang confuses the `align_val_t` overloads of delete with
the sized deallocation overloads which aren't enabled. This caused Clang
to call the aligned deallocation function as if it were the sized
deallocation overload.

For example: https://godbolt.org/z/xXJELh

This patch fixes the confusion.

Added:
cfe/trunk/test/SemaCXX/cxx03-aligned-allocation-unscoped-enum.cpp
Modified:
cfe/trunk/lib/Sema/SemaExprCXX.cpp

Modified: cfe/trunk/lib/Sema/SemaExprCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExprCXX.cpp?rev=351294=351293=351294=diff
==
--- cfe/trunk/lib/Sema/SemaExprCXX.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExprCXX.cpp Tue Jan 15 18:34:36 2019
@@ -1511,11 +1511,19 @@ namespace {
 Destroying = true;
 ++NumBaseParams;
   }
-  if (FD->getNumParams() == NumBaseParams + 2)
-HasAlignValT = HasSizeT = true;
-  else if (FD->getNumParams() == NumBaseParams + 1) {
-HasSizeT = FD->getParamDecl(NumBaseParams)->getType()->isIntegerType();
-HasAlignValT = !HasSizeT;
+
+  if (NumBaseParams < FD->getNumParams() &&
+  S.Context.hasSameUnqualifiedType(
+  FD->getParamDecl(NumBaseParams)->getType(),
+  S.Context.getSizeType())) {
+++NumBaseParams;
+HasSizeT = true;
+  }
+
+  if (NumBaseParams < FD->getNumParams() &&
+  FD->getParamDecl(NumBaseParams)->getType()->isAlignValT()) {
+++NumBaseParams;
+HasAlignValT = true;
   }
 
   // In CUDA, determine how much we'd like / dislike to call this.

Added: cfe/trunk/test/SemaCXX/cxx03-aligned-allocation-unscoped-enum.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/cxx03-aligned-allocation-unscoped-enum.cpp?rev=351294=auto
==
--- cfe/trunk/test/SemaCXX/cxx03-aligned-allocation-unscoped-enum.cpp (added)
+++ cfe/trunk/test/SemaCXX/cxx03-aligned-allocation-unscoped-enum.cpp Tue Jan 
15 18:34:36 2019
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 -std=c++03 -triple x86_64-pc-linux-gnu %s \
+// RUN:   -faligned-allocation -emit-llvm -o - -Wno-c++11-extensions | 
FileCheck %s
+
+// Ensure Clang doesn't confuse std::align_val_t with the sized deallocation
+// parameter when the enum type is unscoped. Libc++ does this in C++03 in order
+// to support aligned allocation in that dialect.
+
+using size_t = __decltype(sizeof(0));
+
+namespace std {
+enum align_val_t : size_t {};
+}
+_Static_assert(__is_same(__underlying_type(std::align_val_t), size_t), "");
+
+// CHECK-LABEL: define void @_Z1fPi(
+void f(int *p) {
+  // CHECK-NOT: call void @_ZdlPvSt11align_val_t(
+  // CHECK: call void @_ZdlPv(
+  // CHECK: ret void
+  delete p;
+}


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


[PATCH] D56760: Add a new builtin: __builtin_dynamic_object_size

2019-01-15 Thread George Burgess IV via Phabricator via cfe-commits
george.burgess.iv added a comment.

Thanks for this!

> Would it make sense to model this as an (optional) extra flag bit for 
> __builtin_object_size rather than as a new builtin?

+1. That way, we could avoid making a `pass_dynamic_object_size` (assuming we 
wouldn't want to have a different API between that and __builtin_object_size), 
as well. :)


Repository:
  rC Clang

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

https://reviews.llvm.org/D56760



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


[PATCH] D56424: [clang-tidy] Add check for underscores in googletest names.

2019-01-15 Thread Kar Epker via Phabricator via cfe-commits
karepker added a comment.

In D56424#1357484 , @MyDeveloperDay 
wrote:

> In D56424#1357481 , @lebedev.ri 
> wrote:
>
> > In D56424#1357471 , 
> > @MyDeveloperDay wrote:
> >
> > > In D56424#1356959 , @karepker 
> > > wrote:
> > >
> > > > Hi all, ping on this patch. I've addressed all comments to the best of 
> > > > my ability. Is there anything outstanding that needs to be changed?
> > >
> > >
> > > Round about this time of a review we normally hear @JonasToth asking if 
> > > you've run this on a large C++ code base like LLVM (with fix-its), and 
> > > seen if the project still builds afterwards..might be worth doing that 
> > > ahead of time if you haven't done so already
> >
> >
> > From docs: `This check does not propose any fixes.`.
>
>
> Thats a great suggestion for the future then transform
>
>   TEST(TestCase_Name, Test_Name) {} 
>
>
> into
>
>   TEST(TestCaseName, TestName) {}
>


I considered doing this for the check, but decided against it based on the 
cases in which I've seen underscores in use. I've seen a few cases in the style 
of this:

SuccessfullyWrites_InfiniteDeadline
SuccessfullyWrites_DefaultDeadline

changing these to:

SuccessfullyWritesInfiniteDeadline
SuccessfullyWritesDefaultDeadline

has a subtle difference to the reader. In the first case, underscore functions 
like "with", whereas in the fix it sounds like the test is for writing the 
deadline.

While removing the underscore does seem to work for a large portion of the 
cases, based on the cases like that above, I didn't think it was appropriate to 
make these modifications.

Please let me know what you think.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D56424



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


[PATCH] D56632: [analyzer] Track region liveness only through base regions.

2019-01-15 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added inline comments.



Comment at: include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h:390
 
-  // FIXME: Remove when we migrate over to just using ValueManager.
   SymbolManager () { return SymMgr; }

baloghadamsoftware wrote:
> Is this comment intentionally deleted?
Yeah, i don't think anybody remembers what was that about and there doesn't 
seem to be an immediate need in something like that.

Hmm, why did i delete it as part of that revision? I guess because i was moving 
these helper methods around. Let me bring them back because this place is 
actually better, now that i think about it.

Also i wonder if anybody ever uses this const getter two lines below (or even 
passes `ExprEngine` by const reference anywhere). Hmm, seems to compile without 
it.



Comment at: test/Analysis/symbol-reaper.cpp:1
+// RUN: %clang_analyze_cc1 -analyzer-checker=debug.ExprInspection -verify %s
+

Szelethus wrote:
> Core intentionally left out?
Thx ^.^ No, just still have this habit since before it was decided to make it 
mandatory >.<



Comment at: test/Analysis/symbol-reaper.cpp:13
+  void foo() {
+// Ugh, maybe just let clang_analyzer_eval() work within callees already?
+// The glob variable shouldn't keep our symbol alive because

a_sidorin wrote:
> //FIXME?
Yeah, i guess it's a more polite way of expressing it :)



Comment at: test/Analysis/symbol-reaper.cpp:31
+  clang_analyzer_eval(glob); // expected-warning{{TRUE}}
+ // expected-warning@-1{{SYMBOL DEAD}}
+}

Szelethus wrote:
> N00b question: What does `SYMBOL DEAD` mean here exactly?
It's a warning produced by `clang_analyzer_warnOnDeadSymbol(a.x)` when the 
value that was in `a.x` (that was there when that function was called) dies. 
This is an `ExprInspection` utility that was created in order to test 
`SymbolReaper` more directly. See `symbol-reaper.c` for more such tests.



Comment at: unittests/StaticAnalyzer/SymbolReaperTest.cpp:52
+assert(Matches.size() == 1 && "Ambiguous name!");
+for (BoundNodes  : Matches)
+  return M.getNodeAs("d");

a_sidorin wrote:
> It looks like `selectFirst` helper is what you need here.
Wow, this one's handy.



Comment at: unittests/StaticAnalyzer/SymbolReaperTest.cpp:97
+  bool HandleTopLevelDecl(DeclGroupRef DG) override {
+for (auto D: DG)
+  performTest(D);

a_sidorin wrote:
> Nit: `const auto *D : DG`
Fxd^^


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

https://reviews.llvm.org/D56632



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


[PATCH] D56632: [analyzer] Track region liveness only through base regions.

2019-01-15 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ updated this revision to Diff 181961.
NoQ marked 12 inline comments as done.
NoQ added a comment.

Fix stuff.

In D56632#1356163 , 
@baloghadamsoftware wrote:

> Did you measure decrease in the false-positive rate or an increase in the 
> true-positive rate on real code? I expect some.


In progress :)

In D56632#1356249 , @xazax.hun wrote:

> > When a memory region is live, all its sub-regions and super-regions are 
> > automatically live (and vice versa), so it is only necessary to track 
> > liveness of base regions.
>
>
>
>   I think this is non-obvious. If we had all the information it would make 
> perfect sense to have a dead field in an alive struct. But since the liveness 
> analysis is intraprocedural and we cannot know what happens to a struct when 
> it escapes we have no choice but keep the field alive. A more sophisticated 
> analysis (which is also likely to be more expensive) could have dead fields 
> in an alive struct in case the struct never escapes. 


Great point indeed! I vaguely remember that some other tools do actually work 
that way. If a field is not referenced anywhere in the path and there's no 
weird pointer arithmetic going on upon the variable, we can actually diagnose a 
leak of the value within the field *before* the variable itself dies. Even 
intraprocedurally, we can just handle escapes and still do slightly better than 
we do now. This gets really valuable when the variable is, say, a non-escaping 
static (local or global). The variable never dies, but there may still be no 
deallocation for the field anywhere in the code and we may be able to see this 
within the translation unit. This doesn't have to have anything to do with 
fields though, the variable itself may carry the leaking pointer. Same with 
private fields regardless of storage. Neat food for thought.

Added a comment. Is there anything else worth documenting here, other than "the 
whole damn thing"?

>> The answer is yes, it does work correctly, because scanReachableSymbols 
>> always scans the whole super-region chain of every region. Which means that 
>> every time the Environment or the Store marks a region as live, all of its 
>> super-regions are added to RegionRoots. However, i would still like to add 
>> conversion to the base region into markLive(), because this behavior is 
>> something that should be guaranteed by SymbolReaper rather implied by 
>> callers manually, even if the callers have to do that anyway.
> 
> I did not really follow, but probably my understanding of how memory regions 
> work is not correct. If we work with base regions, why do we still need to 
> scan the whole super-region chain?

It's just that `scanReachableSymbols` is written that way, and it's used 
everywhere for these kind of purposes. I.e., we (i.e., `SymbolReaper`) don't 
(i.e., doesn't) need to scan the whole chain of regions (apart from the 
`markElementIndicesLive()` thing... wait a minute, does it work in the opposite 
direction? - i.e., if an array-typed region is live, does it automatically mean 
that all index symbols in all element regions within it are actually treated as 
live everywhere in the program state? - need to check), but this behavior is 
re-used from other users `scanReachableSymbols` (wait a minute, do any of the 
other users actually need that? - i'm not immediately seeing any user actually 
need that, it seems that *everybody* operates on base regions only - but 
probably it's anyway not that much slower than jumping to the base region 
directly - need to check).


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

https://reviews.llvm.org/D56632

Files:
  include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
  lib/StaticAnalyzer/Core/ExprEngine.cpp
  lib/StaticAnalyzer/Core/SymbolManager.cpp
  test/Analysis/diagnostics/dtors.cpp
  test/Analysis/symbol-reaper.cpp
  unittests/StaticAnalyzer/CMakeLists.txt
  unittests/StaticAnalyzer/SymbolReaperTest.cpp

Index: unittests/StaticAnalyzer/SymbolReaperTest.cpp
===
--- /dev/null
+++ unittests/StaticAnalyzer/SymbolReaperTest.cpp
@@ -0,0 +1,121 @@
+//===- unittests/StaticAnalyzer/SymbolReaperTest.cpp --===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Frontend/CompilerInstance.h"
+#include "clang/StaticAnalyzer/Core/BugReporter/BugReporter.h"
+#include "clang/StaticAnalyzer/Core/BugReporter/BugType.h"
+#include "clang/CrossTU/CrossTranslationUnit.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h"
+#include "clang/StaticAnalyzer/Frontend/AnalysisConsumer.h"

[PATCH] D56732: [clang] [test] Disable Python binding tests w/ LLVM_ENABLE_PIC=OFF

2019-01-15 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.

Thanks!

I can't easily test this since only some of our bots see this and I don't have 
a Linux box at hand, but it looks like it should work and I can verify on the 
bots once this is in :)


Repository:
  rC Clang

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

https://reviews.llvm.org/D56732



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


[PATCH] D56731: Add -Wimplicit-ctad warning to diagnose CTAD on types with no user defined deduction guides.

2019-01-15 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added a comment.

[This discussion should probably move to cfe-dev@, since it's not directly 
relevant for this patch.]

In D56731#1358907 , @Quuxplusone wrote:

> > Concretely, I think we could warn if, during template instantiation from a 
> > type-dependent initializer, we select the copy deduction candidate and 
> > there was another viable candidate (the `optional o(x)` case, the `tuple 
> > t{args...}` case, etc), maybe under a new `-Wctad-unwrap` or similar.
>
> The trick is that you have to give the warning //even when the copy deduction 
> candidate is not selected// — e.g. `tuple t{args...}` when `args...` is not a 
> 1-parameter pack //right now// but if it might turn out to be a 1-parameter 
> pack at "production time" (after the library has reached the customer).


There's a balance here between practical usability and warning as early as 
possible. If the template is never actually instantiated with only one 
argument, then warning on it is noise, and noise that'd be hard to turn off 
without losing the value of the warning. So we need to decide whether we want a 
(hopefully!) low-false-positive warning that helps library vendors that think 
to test this corner case themselves, or a (presumably) higher-false-positive 
warning that also helps the incautious library vendors that insufficiently 
tested their library, and we need to keep in mind while making that decision 
that a warning that is either off-by-default or turned off by nearly everyone 
delivers much less value than a warning that can be made on by default and that 
people don't turn off. Are there open-source projects making use of CTAD on 
which we could perform an analysis?

>> I don't see a good general way to catch and warn on bugs like 
>> `vector v("foo", "bar")`
> 
> You mean `vector v("foo", "bar")`.

Hmm, I think I was actually thinking of cases more like:

  vector s = {{"foo", "bar"}};

... which I have seen come up quite a lot.


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

https://reviews.llvm.org/D56731



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


[PATCH] D56766: [Frontend] Make WrapperFrontendAction call WrappedAction.PrepareToExecuteAction.

2019-01-15 Thread Volodymyr Sapsai via Phabricator via cfe-commits
vsapsai created this revision.
vsapsai added a reviewer: rsmith.
Herald added subscribers: dexonsmith, jkorous.

Fixes `-emit-header-module` when GenerateHeaderModuleAction is wrapped
by another frontend action.

rdar://problem/47302588


https://reviews.llvm.org/D56766

Files:
  clang/include/clang/Frontend/FrontendAction.h
  clang/lib/Frontend/FrontendAction.cpp


Index: clang/lib/Frontend/FrontendAction.cpp
===
--- clang/lib/Frontend/FrontendAction.cpp
+++ clang/lib/Frontend/FrontendAction.cpp
@@ -1045,6 +1045,9 @@
   llvm_unreachable("Invalid CreateASTConsumer on preprocessor action!");
 }
 
+bool WrapperFrontendAction::PrepareToExecuteAction(CompilerInstance ) {
+  return WrappedAction->PrepareToExecuteAction(CI);
+}
 std::unique_ptr
 WrapperFrontendAction::CreateASTConsumer(CompilerInstance ,
  StringRef InFile) {
Index: clang/include/clang/Frontend/FrontendAction.h
===
--- clang/include/clang/Frontend/FrontendAction.h
+++ clang/include/clang/Frontend/FrontendAction.h
@@ -305,6 +305,7 @@
   std::unique_ptr WrappedAction;
 
 protected:
+  bool PrepareToExecuteAction(CompilerInstance ) override;
   std::unique_ptr CreateASTConsumer(CompilerInstance ,
  StringRef InFile) override;
   bool BeginInvocation(CompilerInstance ) override;


Index: clang/lib/Frontend/FrontendAction.cpp
===
--- clang/lib/Frontend/FrontendAction.cpp
+++ clang/lib/Frontend/FrontendAction.cpp
@@ -1045,6 +1045,9 @@
   llvm_unreachable("Invalid CreateASTConsumer on preprocessor action!");
 }
 
+bool WrapperFrontendAction::PrepareToExecuteAction(CompilerInstance ) {
+  return WrappedAction->PrepareToExecuteAction(CI);
+}
 std::unique_ptr
 WrapperFrontendAction::CreateASTConsumer(CompilerInstance ,
  StringRef InFile) {
Index: clang/include/clang/Frontend/FrontendAction.h
===
--- clang/include/clang/Frontend/FrontendAction.h
+++ clang/include/clang/Frontend/FrontendAction.h
@@ -305,6 +305,7 @@
   std::unique_ptr WrappedAction;
 
 protected:
+  bool PrepareToExecuteAction(CompilerInstance ) override;
   std::unique_ptr CreateASTConsumer(CompilerInstance ,
  StringRef InFile) override;
   bool BeginInvocation(CompilerInstance ) override;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D56746: [Fixed Point Arithmetic] Add APFixedPoint to APValue

2019-01-15 Thread John McCall via Phabricator via cfe-commits
rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.

Thanks, LGTM.


Repository:
  rC Clang

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

https://reviews.llvm.org/D56746



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


[PATCH] D56760: Add a new builtin: __builtin_dynamic_object_size

2019-01-15 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added a comment.

Thanks, this seems like a useful feature to me.

Would it make sense to model this as an (optional) extra flag bit for 
`__builtin_object_size` rather than as a new builtin? It'd seem reasonable to 
me to ask on the gcc dev list if they'd be interested in such an extension to 
their builtin -- if not, then we should use a new name, and something like this 
seems fine to me.


Repository:
  rC Clang

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

https://reviews.llvm.org/D56760



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


[PATCH] D53738: [Fixed Point Arithmetic] Fixed Point Addition

2019-01-15 Thread John McCall via Phabricator via cfe-commits
rjmccall accepted this revision.
rjmccall added a comment.
This revision is now accepted and ready to land.

I think that's the right direction, yeah.

I thought I told you it was fine to commit this patch under that assumption 
awhile ago.  Did I just never click "accept"?


Repository:
  rC Clang

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

https://reviews.llvm.org/D53738



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


[PATCH] D56731: Add -Wimplicit-ctad warning to diagnose CTAD on types with no user defined deduction guides.

2019-01-15 Thread Geoffrey Romer via Phabricator via cfe-commits
gromer added a comment.

In D56731#1358926 , @jdennett wrote:

> In D56731#1358907 , @Quuxplusone 
> wrote:
>
> > For my own use-cases, I will continue to want a 100% comprehensive 
> > `-Wctad`. All these "heuristics" you're proposing seem very ad-hoc, and 
> > make a lot of work for the compiler vendor, and seem complicated enough 
> > that I would still worry about bugs slipping through the cracks. Whereas, 
> > if the user can simply 100% outlaw CTAD, then they don't ever have to worry.
>
>
> That's fair; I don't think anyone here is speaking against such a diagnostic 
> (though maybe the name will be a bikeshed).


Agreed.

> It's just that this patch is a solution for a different problem: allowing the 
> sufficiently safe uses of CTAD without allowing too many bugs.

That makes it sound like a difference of degree, but I think it's more 
fundamental: those other warnings/heuristics/whatever are intended to protect 
//library users// against buggy uses of CTAD, but this one is intended to 
protect //library maintainers// from being forced to support CTAD usages that 
are correct (from the user's point of view), but that the maintainer didn't 
intend to support. So the only way that anything can "slip through the cracks" 
of this warning is if there's some way to use CTAD with a class template whose 
maintainers never intended to support CTAD, without triggering this warning 
(I'm reluctantly willing to exclude the case where user code opens up the 
library's namespace and adds a deduction guide, because I expect most 
maintainers will be only too happy to break such code).


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

https://reviews.llvm.org/D56731



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


[PATCH] D56748: [EH] Rename llvm.x86.seh.recoverfp intrinsic to llvm.eh.recoverfp

2019-01-15 Thread Eli Friedman via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL351284: [EH] Rename llvm.x86.seh.recoverfp intrinsic to 
llvm.eh.recoverfp (authored by efriedma, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D56748?vs=181901=181936#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D56748

Files:
  cfe/trunk/lib/CodeGen/CGException.cpp
  cfe/trunk/test/CodeGen/exceptions-seh.c
  cfe/trunk/test/CodeGenCXX/exceptions-seh-filter-captures.cpp


Index: cfe/trunk/test/CodeGen/exceptions-seh.c
===
--- cfe/trunk/test/CodeGen/exceptions-seh.c
+++ cfe/trunk/test/CodeGen/exceptions-seh.c
@@ -52,7 +52,7 @@
 //
 // X86-LABEL: define internal i32 @"?filt$0@0@safe_div@@"()
 // X86: %[[ebp:[^ ]*]] = call i8* @llvm.frameaddress(i32 1)
-// X86: %[[fp:[^ ]*]] = call i8* @llvm.x86.seh.recoverfp(i8* bitcast (i32 
(i32, i32, i32*)* @safe_div to i8*), i8* %[[ebp]])
+// X86: %[[fp:[^ ]*]] = call i8* @llvm.eh.recoverfp(i8* bitcast (i32 (i32, 
i32, i32*)* @safe_div to i8*), i8* %[[ebp]])
 // X86: call i8* @llvm.localrecover(i8* bitcast (i32 (i32, i32, i32*)* 
@safe_div to i8*), i8* %[[fp]], i32 0)
 // X86: load i8*, i8**
 // X86: load i32*, i32**
@@ -95,16 +95,16 @@
 // CHECK: ret i32 %[[rv]]
 
 // X64-LABEL: define internal i32 @"?filt$0@0@filter_expr_capture@@"(i8* 
%exception_pointers, i8* %frame_pointer)
-// X64: %[[fp:[^ ]*]] = call i8* @llvm.x86.seh.recoverfp(i8* bitcast (i32 ()* 
@filter_expr_capture to i8*), i8* %frame_pointer)
+// X64: %[[fp:[^ ]*]] = call i8* @llvm.eh.recoverfp(i8* bitcast (i32 ()* 
@filter_expr_capture to i8*), i8* %frame_pointer)
 // X64: call i8* @llvm.localrecover(i8* bitcast (i32 ()* @filter_expr_capture 
to i8*), i8* %[[fp]], i32 0)
 //
 // ARM64-LABEL: define internal i32 @"?filt$0@0@filter_expr_capture@@"(i8* 
%exception_pointers, i8* %frame_pointer)
-// ARM64: %[[fp:[^ ]*]] = call i8* @llvm.x86.seh.recoverfp(i8* bitcast (i32 
()* @filter_expr_capture to i8*), i8* %frame_pointer)
+// ARM64: %[[fp:[^ ]*]] = call i8* @llvm.eh.recoverfp(i8* bitcast (i32 ()* 
@filter_expr_capture to i8*), i8* %frame_pointer)
 // ARM64: call i8* @llvm.localrecover(i8* bitcast (i32 ()* 
@filter_expr_capture to i8*), i8* %[[fp]], i32 0)
 //
 // X86-LABEL: define internal i32 @"?filt$0@0@filter_expr_capture@@"()
 // X86: %[[ebp:[^ ]*]] = call i8* @llvm.frameaddress(i32 1)
-// X86: %[[fp:[^ ]*]] = call i8* @llvm.x86.seh.recoverfp(i8* bitcast (i32 ()* 
@filter_expr_capture to i8*), i8* %[[ebp]])
+// X86: %[[fp:[^ ]*]] = call i8* @llvm.eh.recoverfp(i8* bitcast (i32 ()* 
@filter_expr_capture to i8*), i8* %[[ebp]])
 // X86: call i8* @llvm.localrecover(i8* bitcast (i32 ()* @filter_expr_capture 
to i8*), i8* %[[fp]], i32 0)
 //
 // CHECK: store i32 -1, i32* %{{.*}}
@@ -166,13 +166,13 @@
 // CHECK: br label %[[inner_try_cont]]
 //
 // CHECK-LABEL: define internal i32 @"?filt$0@0@nested_try@@"({{.*}})
-// X86: call i8* @llvm.x86.seh.recoverfp({{.*}})
+// X86: call i8* @llvm.eh.recoverfp({{.*}})
 // CHECK: load i32*, i32**
 // CHECK: load i32, i32*
 // CHECK: icmp eq i32 %{{.*}}, 456
 //
 // CHECK-LABEL: define internal i32 @"?filt$1@0@nested_try@@"({{.*}})
-// X86: call i8* @llvm.x86.seh.recoverfp({{.*}})
+// X86: call i8* @llvm.eh.recoverfp({{.*}})
 // CHECK: load i32*, i32**
 // CHECK: load i32, i32*
 // CHECK: icmp eq i32 %{{.*}}, 123
Index: cfe/trunk/test/CodeGenCXX/exceptions-seh-filter-captures.cpp
===
--- cfe/trunk/test/CodeGenCXX/exceptions-seh-filter-captures.cpp
+++ cfe/trunk/test/CodeGenCXX/exceptions-seh-filter-captures.cpp
@@ -21,7 +21,7 @@
 // CHECK: invoke void @might_crash()
 
 // CHECK-LABEL: define internal i32 @"?filt$0@0@test_freefunc@@"(i8* 
%exception_pointers, i8* %frame_pointer)
-// CHECK: %[[fp:[^ ]*]] = call i8* @llvm.x86.seh.recoverfp(i8* bitcast (void 
(i32)* @test_freefunc to i8*), i8* %frame_pointer)
+// CHECK: %[[fp:[^ ]*]] = call i8* @llvm.eh.recoverfp(i8* bitcast (void (i32)* 
@test_freefunc to i8*), i8* %frame_pointer)
 // CHECK: %[[p1_i8:[^ ]*]] = call i8* @llvm.localrecover(i8* bitcast (void 
(i32)* @test_freefunc to i8*), i8* %[[fp]], i32 0)
 // CHECK: %[[p1_ptr:[^ ]*]] = bitcast i8* %[[p1_i8]] to i32*
 // CHECK: %[[l1_i8:[^ ]*]] = call i8* @llvm.localrecover(i8* bitcast (void 
(i32)* @test_freefunc to i8*), i8* %[[fp]], i32 1)
@@ -51,7 +51,7 @@
 // CHECK: invoke void @might_crash()
 
 // CHECK-LABEL: define internal i32 @"?filt$0@0@test_method@S@@"(i8* 
%exception_pointers, i8* %frame_pointer)
-// CHECK: %[[fp:[^ ]*]] = call i8* @llvm.x86.seh.recoverfp(i8* bitcast (void 
(%struct.S*)* @"?test_method@S@@QEAAXXZ" to i8*), i8* %frame_pointer)
+// CHECK: %[[fp:[^ ]*]] = call i8* @llvm.eh.recoverfp(i8* bitcast (void 
(%struct.S*)* @"?test_method@S@@QEAAXXZ" to i8*), i8* %frame_pointer)
 // CHECK: %[[l1_i8:[^ ]*]] 

r351284 - [EH] Rename llvm.x86.seh.recoverfp intrinsic to llvm.eh.recoverfp

2019-01-15 Thread Eli Friedman via cfe-commits
Author: efriedma
Date: Tue Jan 15 16:50:44 2019
New Revision: 351284

URL: http://llvm.org/viewvc/llvm-project?rev=351284=rev
Log:
[EH] Rename llvm.x86.seh.recoverfp intrinsic to llvm.eh.recoverfp

This is the clang counterpart to D56747.

Patch by Mandeep Singh Grang.

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


Modified:
cfe/trunk/lib/CodeGen/CGException.cpp
cfe/trunk/test/CodeGen/exceptions-seh.c
cfe/trunk/test/CodeGenCXX/exceptions-seh-filter-captures.cpp

Modified: cfe/trunk/lib/CodeGen/CGException.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGException.cpp?rev=351284=351283=351284=diff
==
--- cfe/trunk/lib/CodeGen/CGException.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGException.cpp Tue Jan 15 16:50:44 2019
@@ -1781,7 +1781,7 @@ void CodeGenFunction::EmitCapturedLocals
 // frame pointer of the parent function. We only need to do this in 
filters,
 // since finally funclets recover the parent FP for us.
 llvm::Function *RecoverFPIntrin =
-CGM.getIntrinsic(llvm::Intrinsic::x86_seh_recoverfp);
+CGM.getIntrinsic(llvm::Intrinsic::eh_recoverfp);
 llvm::Constant *ParentI8Fn =
 llvm::ConstantExpr::getBitCast(ParentCGF.CurFn, Int8PtrTy);
 ParentFP = Builder.CreateCall(RecoverFPIntrin, {ParentI8Fn, EntryFP});

Modified: cfe/trunk/test/CodeGen/exceptions-seh.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/exceptions-seh.c?rev=351284=351283=351284=diff
==
--- cfe/trunk/test/CodeGen/exceptions-seh.c (original)
+++ cfe/trunk/test/CodeGen/exceptions-seh.c Tue Jan 15 16:50:44 2019
@@ -52,7 +52,7 @@ int safe_div(int numerator, int denomina
 //
 // X86-LABEL: define internal i32 @"?filt$0@0@safe_div@@"()
 // X86: %[[ebp:[^ ]*]] = call i8* @llvm.frameaddress(i32 1)
-// X86: %[[fp:[^ ]*]] = call i8* @llvm.x86.seh.recoverfp(i8* bitcast (i32 
(i32, i32, i32*)* @safe_div to i8*), i8* %[[ebp]])
+// X86: %[[fp:[^ ]*]] = call i8* @llvm.eh.recoverfp(i8* bitcast (i32 (i32, 
i32, i32*)* @safe_div to i8*), i8* %[[ebp]])
 // X86: call i8* @llvm.localrecover(i8* bitcast (i32 (i32, i32, i32*)* 
@safe_div to i8*), i8* %[[fp]], i32 0)
 // X86: load i8*, i8**
 // X86: load i32*, i32**
@@ -95,16 +95,16 @@ int filter_expr_capture(void) {
 // CHECK: ret i32 %[[rv]]
 
 // X64-LABEL: define internal i32 @"?filt$0@0@filter_expr_capture@@"(i8* 
%exception_pointers, i8* %frame_pointer)
-// X64: %[[fp:[^ ]*]] = call i8* @llvm.x86.seh.recoverfp(i8* bitcast (i32 ()* 
@filter_expr_capture to i8*), i8* %frame_pointer)
+// X64: %[[fp:[^ ]*]] = call i8* @llvm.eh.recoverfp(i8* bitcast (i32 ()* 
@filter_expr_capture to i8*), i8* %frame_pointer)
 // X64: call i8* @llvm.localrecover(i8* bitcast (i32 ()* @filter_expr_capture 
to i8*), i8* %[[fp]], i32 0)
 //
 // ARM64-LABEL: define internal i32 @"?filt$0@0@filter_expr_capture@@"(i8* 
%exception_pointers, i8* %frame_pointer)
-// ARM64: %[[fp:[^ ]*]] = call i8* @llvm.x86.seh.recoverfp(i8* bitcast (i32 
()* @filter_expr_capture to i8*), i8* %frame_pointer)
+// ARM64: %[[fp:[^ ]*]] = call i8* @llvm.eh.recoverfp(i8* bitcast (i32 ()* 
@filter_expr_capture to i8*), i8* %frame_pointer)
 // ARM64: call i8* @llvm.localrecover(i8* bitcast (i32 ()* 
@filter_expr_capture to i8*), i8* %[[fp]], i32 0)
 //
 // X86-LABEL: define internal i32 @"?filt$0@0@filter_expr_capture@@"()
 // X86: %[[ebp:[^ ]*]] = call i8* @llvm.frameaddress(i32 1)
-// X86: %[[fp:[^ ]*]] = call i8* @llvm.x86.seh.recoverfp(i8* bitcast (i32 ()* 
@filter_expr_capture to i8*), i8* %[[ebp]])
+// X86: %[[fp:[^ ]*]] = call i8* @llvm.eh.recoverfp(i8* bitcast (i32 ()* 
@filter_expr_capture to i8*), i8* %[[ebp]])
 // X86: call i8* @llvm.localrecover(i8* bitcast (i32 ()* @filter_expr_capture 
to i8*), i8* %[[fp]], i32 0)
 //
 // CHECK: store i32 -1, i32* %{{.*}}
@@ -166,13 +166,13 @@ int nested_try(void) {
 // CHECK: br label %[[inner_try_cont]]
 //
 // CHECK-LABEL: define internal i32 @"?filt$0@0@nested_try@@"({{.*}})
-// X86: call i8* @llvm.x86.seh.recoverfp({{.*}})
+// X86: call i8* @llvm.eh.recoverfp({{.*}})
 // CHECK: load i32*, i32**
 // CHECK: load i32, i32*
 // CHECK: icmp eq i32 %{{.*}}, 456
 //
 // CHECK-LABEL: define internal i32 @"?filt$1@0@nested_try@@"({{.*}})
-// X86: call i8* @llvm.x86.seh.recoverfp({{.*}})
+// X86: call i8* @llvm.eh.recoverfp({{.*}})
 // CHECK: load i32*, i32**
 // CHECK: load i32, i32*
 // CHECK: icmp eq i32 %{{.*}}, 123

Modified: cfe/trunk/test/CodeGenCXX/exceptions-seh-filter-captures.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/exceptions-seh-filter-captures.cpp?rev=351284=351283=351284=diff
==
--- cfe/trunk/test/CodeGenCXX/exceptions-seh-filter-captures.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/exceptions-seh-filter-captures.cpp Tue Jan 15 
16:50:44 2019
@@ 

[PATCH] D56760: Add a new builtin: __builtin_dynamic_object_size

2019-01-15 Thread Erik Pilkington via Phabricator via cfe-commits
erik.pilkington created this revision.
erik.pilkington added reviewers: george.burgess.iv, ahatanak, rjmccall, rsmith.
Herald added subscribers: kristina, dexonsmith, jkorous.

This builtin has the same UI as `__builtin_object_size`, but has the potential 
to be evaluated dynamically. It is meant to be used as a drop-in replacement 
for libraries that use `__builtin_object_size` when a dynamic checking mode is 
enabled. For instance, `__builtin_object_size` fails to provide any extra 
checking in the following function:

  void f(size_t alloc) {
char* p = malloc(alloc);
strcpy(p, "foobar"); // expands to __builtin___strcpy_chk(p, "foobar", 
__builtin_object_size(p, 0))
  }

This is an overflow if `alloc < 7`, but because LLVM can't fold the object size 
intrinsic statically, it folds `__builtin_object_size` to `-1`. With 
__builtin_dynamic_object_size, `alloc` is passed through to 
`__builtin___strcpy_chk`.

rdar://problem/32212419 ER: evaluate builtin_objectsize (or a successor) at 
runtime, at least when alloc_size is available

Thanks for taking a look!
Erik


Repository:
  rC Clang

https://reviews.llvm.org/D56760

Files:
  clang/docs/LanguageExtensions.rst
  clang/include/clang/Basic/Builtins.def
  clang/lib/AST/ExprConstant.cpp
  clang/lib/Analysis/CFG.cpp
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/StaticAnalyzer/Checkers/BuiltinFunctionChecker.cpp
  clang/test/CodeGen/alloc-size.c
  clang/test/CodeGen/catch-undef-behavior.c
  clang/test/CodeGen/object-size.c
  clang/test/CodeGen/object-size.cpp
  clang/test/Sema/builtin-object-size.c

Index: clang/test/Sema/builtin-object-size.c
===
--- clang/test/Sema/builtin-object-size.c
+++ clang/test/Sema/builtin-object-size.c
@@ -1,22 +1,29 @@
 // RUN: %clang_cc1 -fsyntax-only -verify %s
 // RUN: %clang_cc1 -fsyntax-only -triple x86_64-apple-darwin9 -verify %s
+// RUN: %clang_cc1 -DDYNAMIC -fsyntax-only -triple x86_64-apple-darwin9 -verify %s
+
+#ifndef DYNAMIC
+#define OBJECT_SIZE_BUILTIN __builtin_object_size
+#else
+#define OBJECT_SIZE_BUILTIN __builtin_dynamic_object_size
+#endif
 
 int a[10];
 
 int f0() {
-  return __builtin_object_size(); // expected-error {{too few arguments to function}}
+  return OBJECT_SIZE_BUILTIN(); // expected-error {{too few arguments to function}}
 }
 int f1() {
-  return (__builtin_object_size(, 0) + 
-  __builtin_object_size(, 1) + 
-  __builtin_object_size(, 2) + 
-  __builtin_object_size(, 3));
+  return (OBJECT_SIZE_BUILTIN(, 0) + 
+  OBJECT_SIZE_BUILTIN(, 1) + 
+  OBJECT_SIZE_BUILTIN(, 2) + 
+  OBJECT_SIZE_BUILTIN(, 3));
 }
 int f2() {
-  return __builtin_object_size(, -1); // expected-error {{argument value -1 is outside the valid range [0, 3]}}
+  return OBJECT_SIZE_BUILTIN(, -1); // expected-error {{argument value -1 is outside the valid range [0, 3]}}
 }
 int f3() {
-  return __builtin_object_size(, 4); // expected-error {{argument value 4 is outside the valid range [0, 3]}}
+  return OBJECT_SIZE_BUILTIN(, 4); // expected-error {{argument value 4 is outside the valid range [0, 3]}}
 }
 
 
@@ -31,9 +38,9 @@
 void * memcset(void *restrict dst, int src, size_t n);
 void * memcpy(void *restrict dst, const void *restrict src, size_t n);
 
-#define memset(dest, src, len) __builtin___memset_chk(dest, src, len, __builtin_object_size(dest, 0))
-#define memcpy(dest, src, len) __builtin___memcpy_chk(dest, src, len, __builtin_object_size(dest, 0))
-#define memcpy1(dest, src, len) __builtin___memcpy_chk(dest, src, len, __builtin_object_size(dest, 4))
+#define memset(dest, src, len) __builtin___memset_chk(dest, src, len, OBJECT_SIZE_BUILTIN(dest, 0))
+#define memcpy(dest, src, len) __builtin___memcpy_chk(dest, src, len, OBJECT_SIZE_BUILTIN(dest, 0))
+#define memcpy1(dest, src, len) __builtin___memcpy_chk(dest, src, len, OBJECT_SIZE_BUILTIN(dest, 4))
 #define NULL ((void *)0)
 
 void f5(void)
@@ -49,8 +56,8 @@
 {
   char b[5];
   char buf[10];
-  __builtin___memccpy_chk (buf, b, '\0', sizeof(b), __builtin_object_size (buf, 0));
-  __builtin___memccpy_chk (b, buf, '\0', sizeof(buf), __builtin_object_size (b, 0));  // expected-warning {{'__builtin___memccpy_chk' will always overflow; destination buffer has size 5, but size argument is 10}}
+  __builtin___memccpy_chk (buf, b, '\0', sizeof(b), OBJECT_SIZE_BUILTIN (buf, 0));
+  __builtin___memccpy_chk (b, buf, '\0', sizeof(buf), OBJECT_SIZE_BUILTIN (b, 0));  // expected-warning {{'__builtin___memccpy_chk' will always overflow; destination buffer has size 5, but size argument is 10}}
 }
 
 int pr28314(void) {
@@ -70,10 +77,10 @@
   } *p3;
 
   int a = 0;
-  a += __builtin_object_size(>a, 0);
-  a += __builtin_object_size(p->b, 0);
-  a += __builtin_object_size(p2->b, 0);
-  a += __builtin_object_size(p3->b, 0);
+  a += 

Re: r351222 - [Tooling] Make clang-tool find libc++ dir on mac when running on a file without compilation database.

2019-01-15 Thread Vlad Tsyrklevich via cfe-commits
This change was causing MSan/ASan failures on the sanitizer bots:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/28272

I reverted it in r351282.

On Tue, Jan 15, 2019 at 11:09 AM Haojian Wu via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: hokein
> Date: Tue Jan 15 11:05:50 2019
> New Revision: 351222
>
> URL: http://llvm.org/viewvc/llvm-project?rev=351222=rev
> Log:
> [Tooling] Make clang-tool find libc++ dir on mac when running on a file
> without compilation database.
>
> Summary:
> This is a regression of r348365.
>
> When clang-tools run on a file without a complation database (`clang-check
> /tmp/t.cc`),
> we will use fixed compilation database as a fallback. However the actual
> compiler
> path in the fallback complation command is just `clang-tool` which is
> insufficient to detect the libc++ dir.
>
> Reviewers: ilya-biryukov, EricWF
>
> Reviewed By: ilya-biryukov
>
> Subscribers: cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D56680
>
> Added:
> cfe/trunk/test/Tooling/clang-check-mac-libcxx-fixed-compilation-db.cpp
> Modified:
> cfe/trunk/lib/Tooling/CompilationDatabase.cpp
>
> Modified: cfe/trunk/lib/Tooling/CompilationDatabase.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Tooling/CompilationDatabase.cpp?rev=351222=351221=351222=diff
>
> ==
> --- cfe/trunk/lib/Tooling/CompilationDatabase.cpp (original)
> +++ cfe/trunk/lib/Tooling/CompilationDatabase.cpp Tue Jan 15 11:05:50 2019
> @@ -227,6 +227,16 @@ struct FilterUnusedFlags {
>}
>  };
>
> +std::string GetClangToolCommand() {
> +  static int Dummy;
> +  std::string ClangExecutable =
> +  llvm::sys::fs::getMainExecutable("clang", (void *));
> +  SmallString<128> ClangToolPath;
> +  ClangToolPath = llvm::sys::path::parent_path(ClangExecutable);
> +  llvm::sys::path::append(ClangToolPath, "clang-tool");
> +  return ClangToolPath.str();
> +}
> +
>  } // namespace
>
>  /// Strips any positional args and possible argv[0] from a command-line
> @@ -266,9 +276,9 @@ static bool stripPositionalArgs(std::vec
>Diagnostics));
>NewDriver->setCheckInputsExist(false);
>
> -  // This becomes the new argv[0]. The value is actually not important as
> it
> -  // isn't used for invoking Tools.
> -  Args.insert(Args.begin(), "clang-tool");
> +  // This becomes the new argv[0]. The value is used to detect libc++
> include
> +  // dirs on Mac, it isn't used for other platforms.
> +  Args.insert(Args.begin(), GetClangToolCommand().c_str());
>
>// By adding -c, we force the driver to treat compilation as the last
> phase.
>// It will then issue warnings via Diagnostics about un-used options
> that
> @@ -366,7 +376,7 @@ FixedCompilationDatabase::loadFromFile(S
>
>  FixedCompilationDatabase::
>  FixedCompilationDatabase(Twine Directory, ArrayRef
> CommandLine) {
> -  std::vector ToolCommandLine(1, "clang-tool");
> +  std::vector ToolCommandLine(1, GetClangToolCommand());
>ToolCommandLine.insert(ToolCommandLine.end(),
>   CommandLine.begin(), CommandLine.end());
>CompileCommands.emplace_back(Directory, StringRef(),
>
> Added:
> cfe/trunk/test/Tooling/clang-check-mac-libcxx-fixed-compilation-db.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Tooling/clang-check-mac-libcxx-fixed-compilation-db.cpp?rev=351222=auto
>
> ==
> --- cfe/trunk/test/Tooling/clang-check-mac-libcxx-fixed-compilation-db.cpp
> (added)
> +++ cfe/trunk/test/Tooling/clang-check-mac-libcxx-fixed-compilation-db.cpp
> Tue Jan 15 11:05:50 2019
> @@ -0,0 +1,16 @@
> +// Clang on MacOS can find libc++ living beside the installed compiler.
> +// This test makes sure our libTooling-based tools emulate this properly
> with
> +// fixed compilation database.
> +//
> +// RUN: rm -rf %t
> +// RUN: mkdir %t
> +//
> +// Install the mock libc++ (simulates the libc++ directory structure).
> +// RUN: cp -r %S/Inputs/mock-libcxx %t/
> +//
> +// RUN: cp clang-check %t/mock-libcxx/bin/
> +// RUN: cp "%s" "%t/test.cpp"
> +// RUN: %t/mock-libcxx/bin/clang-check -p "%t" "%t/test.cpp" --
> -stdlib=libc++
> +
> +#include 
> +vector v;
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r351282 - Revert "[Tooling] Make clang-tool find libc++ dir on mac when running on a file without compilation database."

2019-01-15 Thread Vlad Tsyrklevich via cfe-commits
Author: vlad.tsyrklevich
Date: Tue Jan 15 16:37:39 2019
New Revision: 351282

URL: http://llvm.org/viewvc/llvm-project?rev=351282=rev
Log:
Revert "[Tooling] Make clang-tool find libc++ dir on mac when running on a file 
without compilation database."

This reverts commits r351222 and r351229, they were causing ASan/MSan failures
on the sanitizer bots.

Removed:
cfe/trunk/test/Tooling/clang-check-mac-libcxx-fixed-compilation-db.cpp
Modified:
cfe/trunk/lib/Tooling/CompilationDatabase.cpp
cfe/trunk/unittests/Tooling/CompilationDatabaseTest.cpp

Modified: cfe/trunk/lib/Tooling/CompilationDatabase.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Tooling/CompilationDatabase.cpp?rev=351282=351281=351282=diff
==
--- cfe/trunk/lib/Tooling/CompilationDatabase.cpp (original)
+++ cfe/trunk/lib/Tooling/CompilationDatabase.cpp Tue Jan 15 16:37:39 2019
@@ -227,16 +227,6 @@ struct FilterUnusedFlags {
   }
 };
 
-std::string GetClangToolCommand() {
-  static int Dummy;
-  std::string ClangExecutable =
-  llvm::sys::fs::getMainExecutable("clang", (void *));
-  SmallString<128> ClangToolPath;
-  ClangToolPath = llvm::sys::path::parent_path(ClangExecutable);
-  llvm::sys::path::append(ClangToolPath, "clang-tool");
-  return ClangToolPath.str();
-}
-
 } // namespace
 
 /// Strips any positional args and possible argv[0] from a command-line
@@ -276,9 +266,9 @@ static bool stripPositionalArgs(std::vec
   Diagnostics));
   NewDriver->setCheckInputsExist(false);
 
-  // This becomes the new argv[0]. The value is used to detect libc++ include
-  // dirs on Mac, it isn't used for other platforms.
-  Args.insert(Args.begin(), GetClangToolCommand().c_str());
+  // This becomes the new argv[0]. The value is actually not important as it
+  // isn't used for invoking Tools.
+  Args.insert(Args.begin(), "clang-tool");
 
   // By adding -c, we force the driver to treat compilation as the last phase.
   // It will then issue warnings via Diagnostics about un-used options that
@@ -376,7 +366,7 @@ FixedCompilationDatabase::loadFromFile(S
 
 FixedCompilationDatabase::
 FixedCompilationDatabase(Twine Directory, ArrayRef CommandLine) {
-  std::vector ToolCommandLine(1, GetClangToolCommand());
+  std::vector ToolCommandLine(1, "clang-tool");
   ToolCommandLine.insert(ToolCommandLine.end(),
  CommandLine.begin(), CommandLine.end());
   CompileCommands.emplace_back(Directory, StringRef(),

Removed: cfe/trunk/test/Tooling/clang-check-mac-libcxx-fixed-compilation-db.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Tooling/clang-check-mac-libcxx-fixed-compilation-db.cpp?rev=351281=auto
==
--- cfe/trunk/test/Tooling/clang-check-mac-libcxx-fixed-compilation-db.cpp 
(original)
+++ cfe/trunk/test/Tooling/clang-check-mac-libcxx-fixed-compilation-db.cpp 
(removed)
@@ -1,16 +0,0 @@
-// Clang on MacOS can find libc++ living beside the installed compiler.
-// This test makes sure our libTooling-based tools emulate this properly with
-// fixed compilation database.
-//
-// RUN: rm -rf %t
-// RUN: mkdir %t
-//
-// Install the mock libc++ (simulates the libc++ directory structure).
-// RUN: cp -r %S/Inputs/mock-libcxx %t/
-//
-// RUN: cp clang-check %t/mock-libcxx/bin/
-// RUN: cp "%s" "%t/test.cpp"
-// RUN: %t/mock-libcxx/bin/clang-check -p "%t" "%t/test.cpp" -- -stdlib=libc++
-
-#include 
-vector v;

Modified: cfe/trunk/unittests/Tooling/CompilationDatabaseTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Tooling/CompilationDatabaseTest.cpp?rev=351282=351281=351282=diff
==
--- cfe/trunk/unittests/Tooling/CompilationDatabaseTest.cpp (original)
+++ cfe/trunk/unittests/Tooling/CompilationDatabaseTest.cpp Tue Jan 15 16:37:39 
2019
@@ -14,15 +14,11 @@
 #include "clang/Tooling/JSONCompilationDatabase.h"
 #include "clang/Tooling/Tooling.h"
 #include "llvm/Support/Path.h"
-#include "gmock/gmock.h"
 #include "gtest/gtest.h"
 
 namespace clang {
 namespace tooling {
 
-using testing::ElementsAre;
-using testing::EndsWith;
-
 static void expectFailure(StringRef JSONDatabase, StringRef Explanation) {
   std::string ErrorMessage;
   EXPECT_EQ(nullptr,
@@ -471,15 +467,21 @@ TEST(unescapeJsonCommandLine, ParsesSing
 }
 
 TEST(FixedCompilationDatabase, ReturnsFixedCommandLine) {
-  FixedCompilationDatabase Database(".", /*CommandLine*/ {"one", "two"});
+  std::vector CommandLine;
+  CommandLine.push_back("one");
+  CommandLine.push_back("two");
+  FixedCompilationDatabase Database(".", CommandLine);
   StringRef FileName("source");
   std::vector Result =
 Database.getCompileCommands(FileName);
   ASSERT_EQ(1ul, Result.size());
+  std::vector ExpectedCommandLine(1, "clang-tool");
+  ExpectedCommandLine.insert(ExpectedCommandLine.end(),
+  

[PATCH] D56748: [EH] Rename llvm.x86.seh.recoverfp intrinsic to llvm.eh.recoverfp

2019-01-15 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/D56748/new/

https://reviews.llvm.org/D56748



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


[PATCH] D54428: [clangd] XPC transport layer, framework, test-client

2019-01-15 Thread Jan Korous via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rCTE351280: [clangd] XPC transport layer (authored by jkorous, 
committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D54428?vs=180809=181925#toc

Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D54428

Files:
  CMakeLists.txt
  clangd/CMakeLists.txt
  clangd/Features.inc.in
  clangd/Transport.h
  clangd/tool/CMakeLists.txt
  clangd/tool/ClangdMain.cpp
  clangd/xpc/CMakeLists.txt
  clangd/xpc/Conversion.cpp
  clangd/xpc/Conversion.h
  clangd/xpc/README.txt
  clangd/xpc/XPCTransport.cpp
  clangd/xpc/cmake/Info.plist.in
  clangd/xpc/cmake/XPCServiceInfo.plist.in
  clangd/xpc/cmake/modules/CreateClangdXPCFramework.cmake
  clangd/xpc/framework/CMakeLists.txt
  clangd/xpc/framework/ClangdXPC.cpp
  clangd/xpc/test-client/CMakeLists.txt
  clangd/xpc/test-client/ClangdXPCTestClient.cpp
  test/CMakeLists.txt
  test/clangd/xpc/initialize.test
  test/lit.cfg
  test/lit.site.cfg.in
  unittests/clangd/CMakeLists.txt
  unittests/clangd/xpc/CMakeLists.txt
  unittests/clangd/xpc/ConversionTests.cpp

Index: unittests/clangd/xpc/ConversionTests.cpp
===
--- unittests/clangd/xpc/ConversionTests.cpp
+++ unittests/clangd/xpc/ConversionTests.cpp
@@ -0,0 +1,36 @@
+//===-- ConversionTests.cpp  --*- C++ -*---===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "xpc/Conversion.h"
+#include "gtest/gtest.h"
+
+#include 
+
+namespace clang {
+namespace clangd {
+namespace {
+
+using namespace llvm;
+
+TEST(JsonXpcConversionTest, JsonToXpcToJson) {
+
+  for (auto  :
+   {json::Value(false), json::Value(3.14), json::Value(42),
+json::Value(-100), json::Value("foo"), json::Value(""),
+json::Value("123"), json::Value(" "),
+json::Value{true, "foo", nullptr, 42},
+json::Value(json::Object{
+{"a", true}, {"b", "foo"}, {"c", nullptr}, {"d", 42}})}) {
+EXPECT_TRUE(testcase == xpcToJson(jsonToXpc(testcase))) << testcase;
+  }
+}
+
+} // namespace
+} // namespace clangd
+} // namespace clang
Index: unittests/clangd/xpc/CMakeLists.txt
===
--- unittests/clangd/xpc/CMakeLists.txt
+++ unittests/clangd/xpc/CMakeLists.txt
@@ -0,0 +1,21 @@
+set(LLVM_LINK_COMPONENTS
+  support
+  )
+
+get_filename_component(CLANGD_SOURCE_DIR
+  ${CMAKE_CURRENT_SOURCE_DIR}/../../clangd REALPATH)
+include_directories(
+  ${CLANGD_SOURCE_DIR}
+  )
+
+add_extra_unittest(ClangdXpcTests
+  ConversionTests.cpp
+  )
+
+target_link_libraries(ClangdXpcTests
+  PRIVATE
+  clangdXpcJsonConversions
+  clangDaemon
+  LLVMSupport
+  LLVMTestingSupport
+  )
Index: unittests/clangd/CMakeLists.txt
===
--- unittests/clangd/CMakeLists.txt
+++ unittests/clangd/CMakeLists.txt
@@ -65,3 +65,7 @@
   LLVMSupport
   LLVMTestingSupport
   )
+
+if (CLANGD_BUILD_XPC)
+  add_subdirectory(xpc)
+endif ()
Index: clangd/Features.inc.in
===
--- clangd/Features.inc.in
+++ clangd/Features.inc.in
@@ -0,0 +1 @@
+#define CLANGD_BUILD_XPC @CLANGD_BUILD_XPC@
Index: clangd/xpc/framework/ClangdXPC.cpp
===
--- clangd/xpc/framework/ClangdXPC.cpp
+++ clangd/xpc/framework/ClangdXPC.cpp
@@ -0,0 +1,5 @@
+
+/// Returns the bundle identifier of the Clangd XPC service.
+extern "C" const char *clangd_xpc_get_bundle_identifier() {
+  return "org.llvm.clangd";
+}
Index: clangd/xpc/framework/CMakeLists.txt
===
--- clangd/xpc/framework/CMakeLists.txt
+++ clangd/xpc/framework/CMakeLists.txt
@@ -0,0 +1,9 @@
+
+set(SOURCES
+ClangdXPC.cpp)
+add_clang_library(ClangdXPCLib SHARED
+  ${SOURCES}
+  DEPENDS
+  clangd
+)
+create_clangd_xpc_framework(ClangdXPCLib "ClangdXPC")
Index: clangd/xpc/CMakeLists.txt
===
--- clangd/xpc/CMakeLists.txt
+++ clangd/xpc/CMakeLists.txt
@@ -0,0 +1,29 @@
+set(CLANGD_XPC_SOURCE_DIR "${CMAKE_CURRENT_SOURCE_DIR}")
+set(CLANGD_XPC_BINARY_DIR "${CMAKE_CURRENT_BINARY_DIR}")
+
+list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake/modules")
+include(CreateClangdXPCFramework)
+
+add_subdirectory(framework)
+add_subdirectory(test-client)
+
+include_directories(
+  ${CMAKE_CURRENT_SOURCE_DIR}/../
+)
+
+set(LLVM_LINK_COMPONENTS
+  Support
+  )
+
+# Needed by LLVM's CMake checks because this file defines multiple targets.
+set(LLVM_OPTIONAL_SOURCES Conversion.cpp 

[clang-tools-extra] r351280 - [clangd] XPC transport layer

2019-01-15 Thread Jan Korous via cfe-commits
Author: jkorous
Date: Tue Jan 15 16:24:22 2019
New Revision: 351280

URL: http://llvm.org/viewvc/llvm-project?rev=351280=rev
Log:
[clangd] XPC transport layer

- New transport layer for macOS.
- XPC Framework
- Test client

Framework and client were written by Alex Lorenz.

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

Added:
clang-tools-extra/trunk/clangd/Features.inc.in
clang-tools-extra/trunk/clangd/xpc/
clang-tools-extra/trunk/clangd/xpc/CMakeLists.txt
clang-tools-extra/trunk/clangd/xpc/Conversion.cpp
clang-tools-extra/trunk/clangd/xpc/Conversion.h
clang-tools-extra/trunk/clangd/xpc/README.txt
clang-tools-extra/trunk/clangd/xpc/XPCTransport.cpp
clang-tools-extra/trunk/clangd/xpc/cmake/
clang-tools-extra/trunk/clangd/xpc/cmake/Info.plist.in
clang-tools-extra/trunk/clangd/xpc/cmake/XPCServiceInfo.plist.in
clang-tools-extra/trunk/clangd/xpc/cmake/modules/

clang-tools-extra/trunk/clangd/xpc/cmake/modules/CreateClangdXPCFramework.cmake
clang-tools-extra/trunk/clangd/xpc/framework/
clang-tools-extra/trunk/clangd/xpc/framework/CMakeLists.txt
clang-tools-extra/trunk/clangd/xpc/framework/ClangdXPC.cpp
clang-tools-extra/trunk/clangd/xpc/test-client/
clang-tools-extra/trunk/clangd/xpc/test-client/CMakeLists.txt
clang-tools-extra/trunk/clangd/xpc/test-client/ClangdXPCTestClient.cpp
clang-tools-extra/trunk/test/clangd/xpc/
clang-tools-extra/trunk/test/clangd/xpc/initialize.test
clang-tools-extra/trunk/unittests/clangd/xpc/
clang-tools-extra/trunk/unittests/clangd/xpc/CMakeLists.txt
clang-tools-extra/trunk/unittests/clangd/xpc/ConversionTests.cpp
Modified:
clang-tools-extra/trunk/CMakeLists.txt
clang-tools-extra/trunk/clangd/CMakeLists.txt
clang-tools-extra/trunk/clangd/Transport.h
clang-tools-extra/trunk/clangd/tool/CMakeLists.txt
clang-tools-extra/trunk/clangd/tool/ClangdMain.cpp
clang-tools-extra/trunk/test/CMakeLists.txt
clang-tools-extra/trunk/test/lit.cfg
clang-tools-extra/trunk/test/lit.site.cfg.in
clang-tools-extra/trunk/unittests/clangd/CMakeLists.txt

Modified: clang-tools-extra/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/CMakeLists.txt?rev=351280=351279=351280=diff
==
--- clang-tools-extra/trunk/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/CMakeLists.txt Tue Jan 15 16:24:22 2019
@@ -1,3 +1,8 @@
+option(CLANGD_BUILD_XPC "Build XPC Support For Clangd." OFF)
+if (${CMAKE_SYSTEM_NAME} MATCHES "Darwin")
+  set(CLANGD_BUILD_XPC ON CACHE BOOL "" FORCE)
+endif ()
+
 add_subdirectory(clang-apply-replacements)
 add_subdirectory(clang-reorder-fields)
 add_subdirectory(modularize)

Modified: clang-tools-extra/trunk/clangd/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/CMakeLists.txt?rev=351280=351279=351280=diff
==
--- clang-tools-extra/trunk/clangd/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clangd/CMakeLists.txt Tue Jan 15 16:24:22 2019
@@ -1,3 +1,11 @@
+# Configure the Features.inc file.
+llvm_canonicalize_cmake_booleans(
+  CLANGD_BUILD_XPC)
+configure_file(
+  ${CMAKE_CURRENT_SOURCE_DIR}/Features.inc.in
+  ${CMAKE_CURRENT_BINARY_DIR}/Features.inc
+)
+
 set(LLVM_LINK_COMPONENTS
   Support
   )
@@ -109,3 +117,6 @@ add_subdirectory(index/dex/dexp)
 if (LLVM_INCLUDE_BENCHMARKS)
   add_subdirectory(benchmarks)
 endif()
+if ( CLANGD_BUILD_XPC )
+  add_subdirectory(xpc)
+endif ()

Added: clang-tools-extra/trunk/clangd/Features.inc.in
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/Features.inc.in?rev=351280=auto
==
--- clang-tools-extra/trunk/clangd/Features.inc.in (added)
+++ clang-tools-extra/trunk/clangd/Features.inc.in Tue Jan 15 16:24:22 2019
@@ -0,0 +1 @@
+#define CLANGD_BUILD_XPC @CLANGD_BUILD_XPC@

Modified: clang-tools-extra/trunk/clangd/Transport.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/Transport.h?rev=351280=351279=351280=diff
==
--- clang-tools-extra/trunk/clangd/Transport.h (original)
+++ clang-tools-extra/trunk/clangd/Transport.h Tue Jan 15 16:24:22 2019
@@ -86,6 +86,12 @@ newJSONTransport(std::FILE *In, llvm::ra
  llvm::raw_ostream *InMirror, bool Pretty,
  JSONStreamStyle = JSONStreamStyle::Standard);
 
+#ifdef CLANGD_BUILD_XPC
+// Returns a Transport for macOS based on XPC.
+// Clangd with this transport is meant to be run as bundled XPC service.
+std::unique_ptr newXPCTransport();
+#endif
+
 } // namespace clangd
 } // namespace clang
 

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

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

2019-01-15 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers added a comment.

With this patch, DD53765, and one out of tree kernel patch to work around a 
separate issue 
,
 I can confirm that I can compile, link, and boot an x86_64 Linux kernel with 
Clang. :)  I'm triple checking with a few other architectures (that also suffer 
from the separate issue) to see if I can find any codegen issues.


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

https://reviews.llvm.org/D56571



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


[PATCH] D56746: [Fixed Point Arithmetic] Add APFixedPoint to APValue

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

Repository:
  rC Clang

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

https://reviews.llvm.org/D56746

Files:
  clang/include/clang/AST/APValue.h
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/FixedPoint.h
  clang/lib/AST/APValue.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/AST/Type.cpp
  clang/lib/Basic/FixedPoint.cpp
  clang/lib/CodeGen/CGExprConstant.cpp
  clang/lib/Sema/SemaTemplate.cpp

Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -6342,6 +6342,7 @@
 }
 case APValue::AddrLabelDiff:
   return Diag(StartLoc, diag::err_non_type_template_arg_addr_label_diff);
+case APValue::FixedPoint:
 case APValue::Float:
 case APValue::ComplexInt:
 case APValue::ComplexFloat:
Index: clang/lib/CodeGen/CGExprConstant.cpp
===
--- clang/lib/CodeGen/CGExprConstant.cpp
+++ clang/lib/CodeGen/CGExprConstant.cpp
@@ -1873,6 +1873,9 @@
 return ConstantLValueEmitter(*this, Value, DestType).tryEmit();
   case APValue::Int:
 return llvm::ConstantInt::get(CGM.getLLVMContext(), Value.getInt());
+  case APValue::FixedPoint:
+return llvm::ConstantInt::get(CGM.getLLVMContext(),
+  Value.getFixedPoint().getValue());
   case APValue::ComplexInt: {
 llvm::Constant *Complex[2];
 
Index: clang/lib/Basic/FixedPoint.cpp
===
--- clang/lib/Basic/FixedPoint.cpp
+++ clang/lib/Basic/FixedPoint.cpp
@@ -137,4 +137,31 @@
  ResultIsSaturated, ResultHasUnsignedPadding);
 }
 
+void APFixedPoint::toString(llvm::SmallVectorImpl ) const {
+  llvm::APSInt Val = getValue();
+  unsigned Scale = getScale();
+
+  if (Val.isSigned() && Val.isNegative() && Val != -Val) {
+Val = -Val;
+Str.push_back('-');
+  }
+
+  llvm::APSInt IntPart = Val >> Scale;
+
+  // Add 4 digits to hold the value after multiplying 10 (the radix)
+  unsigned Width = Val.getBitWidth() + 4;
+  llvm::APInt FractPart = Val.zextOrTrunc(Scale).zext(Width);
+  llvm::APInt FractPartMask = llvm::APInt::getAllOnesValue(Scale).zext(Width);
+  llvm::APInt RadixInt = llvm::APInt(Width, 10);
+
+  IntPart.toString(Str, /*radix=*/10);
+  Str.push_back('.');
+  do {
+(FractPart * RadixInt)
+.lshr(Scale)
+.toString(Str, /*radix=*/10, Val.isSigned());
+FractPart = (FractPart * RadixInt) & FractPartMask;
+  } while (FractPart != 0);
+}
+
 }  // namespace clang
Index: clang/lib/AST/Type.cpp
===
--- clang/lib/AST/Type.cpp
+++ clang/lib/AST/Type.cpp
@@ -4016,25 +4016,8 @@
 
 void clang::FixedPointValueToString(SmallVectorImpl ,
 llvm::APSInt Val, unsigned Scale) {
-  if (Val.isSigned() && Val.isNegative() && Val != -Val) {
-Val = -Val;
-Str.push_back('-');
-  }
-
-  llvm::APSInt IntPart = Val >> Scale;
-
-  // Add 4 digits to hold the value after multiplying 10 (the radix)
-  unsigned Width = Val.getBitWidth() + 4;
-  llvm::APInt FractPart = Val.zextOrTrunc(Scale).zext(Width);
-  llvm::APInt FractPartMask = llvm::APInt::getAllOnesValue(Scale).zext(Width);
-  llvm::APInt RadixInt = llvm::APInt(Width, 10);
-
-  IntPart.toString(Str, /*radix=*/10);
-  Str.push_back('.');
-  do {
-(FractPart * RadixInt)
-.lshr(Scale)
-.toString(Str, /*radix=*/10, Val.isSigned());
-FractPart = (FractPart * RadixInt) & FractPartMask;
-  } while (FractPart != 0);
+  FixedPointSemantics FXSema(Val.getBitWidth(), Scale, Val.isSigned(),
+ /*isSaturated=*/false,
+ /*hasUnsignedPadding=*/false);
+  APFixedPoint(Val, FXSema).toString(Str);
 }
Index: clang/lib/AST/ExprConstant.cpp
===
--- clang/lib/AST/ExprConstant.cpp
+++ clang/lib/AST/ExprConstant.cpp
@@ -2027,6 +2027,9 @@
   case APValue::Int:
 Result = Val.getInt().getBoolValue();
 return true;
+  case APValue::FixedPoint:
+Result = Val.getFixedPoint().getBoolValue();
+return true;
   case APValue::Float:
 Result = !Val.getFloat().isZero();
 return true;
Index: clang/lib/AST/APValue.cpp
===
--- clang/lib/AST/APValue.cpp
+++ clang/lib/AST/APValue.cpp
@@ -176,6 +176,11 @@
 MakeFloat();
 setFloat(RHS.getFloat());
 break;
+  case FixedPoint: {
+APFixedPoint FXCopy = RHS.getFixedPoint();
+MakeFixedPoint(std::move(FXCopy));
+break;
+  }
   case Vector:
 MakeVector();
 setVector(((const Vec *)(const char *)RHS.Data.buffer)->Elts,
@@ -233,6 +238,8 @@
 ((APSInt*)(char*)Data.buffer)->~APSInt();
   else 

[PATCH] D38430: Enable -pie and --enable-new-dtags by default on Android.

2019-01-15 Thread Dan Albert via Phabricator via cfe-commits
danalbert added inline comments.



Comment at: cfe/trunk/lib/Driver/ToolChains/Linux.cpp:814
+bool Linux::isPIEDefault() const {
+  return (getTriple().isAndroid() && !getTriple().isAndroidVersionLT(16)) ||
+ getSanitizerArgs().requiresPIE();

pcc wrote:
> eugenis wrote:
> > pcc wrote:
> > > Why only on API level >= 16? If I create an executable targeting an older 
> > > API level, it should still work on higher API levels.
> > Because it needs to work on lower API levels, too. I think at some point 
> > PIE was actually not supported, so there is no good default that works for 
> > everyone.
> I see. Looking at the tags in which 
> https://github.com/aosp-mirror/platform_bionic/commit/d9ad62343c2db6b66a5fa597c9b20a6faabd7a9a
>  was present, support was indeed added in Jelly Bean, which was API level 16. 
> So this is correct.
Correct. Supported as of 16, required as of 21.

The NDK itself doesn't actually support pre-16 any more, but probably best for 
Clang to do the right thing anyway in case some user is trying to maintain 
their own sysroot for ICS that uses a modern Clang.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D38430



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


Re: r351160 - [X86] Make _xgetbv/_xsetbv on non-windows platforms

2019-01-15 Thread Craig Topper via cfe-commits
This isn't blocking anything. Just doing some archaeology because I noticed
we had an intrinsic in the backend, but it wasn't used by the frontend due
to a previous revert a couple years ago.

~Craig


On Tue, Jan 15, 2019 at 3:47 PM Benjamin Kramer  wrote:

> I think the only viable solution is to make v8 not define reserved
> identifiers & reland this change. That will take some time, so unless this
> is blocking something important I'd prefer to reland after the release cut
> so the world can catch up before the next release. I can take care of
> sending v8 a patch if nobody else feels like doing it.
>
> On Tue, Jan 15, 2019 at 11:28 PM Craig Topper 
> wrote:
>
>> any suggestions on how to proceed here?
>>
>> ~Craig
>>
>>
>> On Tue, Jan 15, 2019 at 10:56 AM Benjamin Kramer 
>> wrote:
>>
>>> I think the main issue is that libstdc++ 4.9 includes x86intrin.h
>>> transitively from . That's probably broken with all compilers :(
>>>
>>> On Tue, Jan 15, 2019 at 7:31 PM Craig Topper 
>>> wrote:
>>>
 Does V8 work with gcc which also has _xgetbv? Or is it because I had to
 make _xgetbv a macro to make the patch work?

 ~Craig


 On Tue, Jan 15, 2019 at 9:28 AM Benjamin Kramer via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> I rolled it back for now in r351210, this pattern seems to be quite
> common even outside of v8. Let's figure out if we can keep the code 
> working
> or if it needs to be fixed all over the place :(
>
> On Tue, Jan 15, 2019 at 3:02 PM Benjamin Kramer 
> wrote:
>
>> I'm seeing breakages on v8 with this, it defines its own _xgetbv. Any
>> ideas what do do about this?
>>
>>
>> https://chromium.googlesource.com/v8/v8.git/+/master/src/x64/assembler-x64.cc#36
>>
>> src/x64/assembler-x64.cc:35:1: error: inline variables are
>> incompatible with C++ standards before C++17
>> [-Werror,-Wc++98-c++11-c++14-compat]
>> V8_INLINE uint64_t _xgetbv(unsigned int xcr) {
>> ^
>> include/v8config.h:294:20: note: expanded from macro 'V8_INLINE'
>> # define V8_INLINE inline __attribute__((always_inline))
>>^
>> src/x64/assembler-x64.cc:35:41: error: expected ')'
>> V8_INLINE uint64_t _xgetbv(unsigned int xcr) {
>> ^
>> src/x64/assembler-x64.cc:35:20: note: to match this '('
>> V8_INLINE uint64_t _xgetbv(unsigned int xcr) {
>>^
>> lib/clang/include/xsaveintrin.h:49:53: note: expanded from macro
>> '_xgetbv'
>> #define _xgetbv(A) __builtin_ia32_xgetbv((long long)(A))
>>
>> On Tue, Jan 15, 2019 at 6:06 AM Craig Topper via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: ctopper
>>> Date: Mon Jan 14 21:03:18 2019
>>> New Revision: 351160
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=351160=rev
>>> Log:
>>> [X86] Make _xgetbv/_xsetbv on non-windows platforms
>>>
>>> Summary:
>>> This patch attempts to redo what was tried in r278783, but was
>>> reverted.
>>>
>>> These intrinsics should be available on non-windows platforms with
>>> "xsave" feature check. But on Windows platforms they shouldn't have 
>>> feature
>>> check since that's how MSVC behaves.
>>>
>>> To accomplish this I've added a MS builtin with no feature check.
>>> And a normal gcc builtin with a feature check. When _MSC_VER is not 
>>> defined
>>> _xgetbv/_xsetbv will be macros pointing to the gcc builtin name.
>>>
>>> I've moved the forward declarations from intrin.h to immintrin.h to
>>> match the MSDN documentation and used that as the header file for the MS
>>> builtin.
>>>
>>> I'm not super happy with this implementation, and I'm open to
>>> suggestions for better ways to do it.
>>>
>>> Reviewers: rnk, RKSimon, spatel
>>>
>>> Reviewed By: rnk
>>>
>>> Subscribers: cfe-commits
>>>
>>> Differential Revision: https://reviews.llvm.org/D56686
>>>
>>> Modified:
>>> cfe/trunk/include/clang/Basic/BuiltinsX86.def
>>> cfe/trunk/lib/CodeGen/CGBuiltin.cpp
>>> cfe/trunk/lib/Headers/immintrin.h
>>> cfe/trunk/lib/Headers/intrin.h
>>> cfe/trunk/lib/Headers/xsaveintrin.h
>>> cfe/trunk/test/CodeGen/builtins-x86.c
>>> cfe/trunk/test/CodeGen/x86_32-xsave.c
>>> cfe/trunk/test/CodeGen/x86_64-xsave.c
>>> cfe/trunk/test/Headers/ms-intrin.cpp
>>>
>>> Modified: cfe/trunk/include/clang/Basic/BuiltinsX86.def
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsX86.def?rev=351160=351159=351160=diff
>>>
>>> ==
>>> --- cfe/trunk/include/clang/Basic/BuiltinsX86.def (original)
>>> +++ cfe/trunk/include/clang/Basic/BuiltinsX86.def Mon Jan 14

[PATCH] D56752: [ASTDump] Mark BlockDecls which capture this with a tag

2019-01-15 Thread Stephen Kelly via Phabricator via cfe-commits
steveire updated this revision to Diff 181909.
steveire added a comment.

Update


Repository:
  rC Clang

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

https://reviews.llvm.org/D56752

Files:
  lib/AST/ASTDumper.cpp


Index: lib/AST/ASTDumper.cpp
===
--- lib/AST/ASTDumper.cpp
+++ lib/AST/ASTDumper.cpp
@@ -1379,12 +1379,12 @@
   if (D->isVariadic())
 OS << " variadic";
 
+  if (D->capturesCXXThis())
+OS << " captures_this";
+
   for (auto I : D->parameters())
 dumpDecl(I);
 
-  if (D->capturesCXXThis())
-dumpChild([=]{ OS << "capture this"; });
-
   for (const auto  : D->captures())
 Visit(I);
   dumpStmt(D->getBody());


Index: lib/AST/ASTDumper.cpp
===
--- lib/AST/ASTDumper.cpp
+++ lib/AST/ASTDumper.cpp
@@ -1379,12 +1379,12 @@
   if (D->isVariadic())
 OS << " variadic";
 
+  if (D->capturesCXXThis())
+OS << " captures_this";
+
   for (auto I : D->parameters())
 dumpDecl(I);
 
-  if (D->capturesCXXThis())
-dumpChild([=]{ OS << "capture this"; });
-
   for (const auto  : D->captures())
 Visit(I);
   dumpStmt(D->getBody());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D56753: [ASTDump] Mark null params with a tag rather than a child node

2019-01-15 Thread Stephen Kelly via Phabricator via cfe-commits
steveire created this revision.
steveire added a reviewer: aaron.ballman.
Herald added a subscriber: cfe-commits.

Repository:
  rC Clang

https://reviews.llvm.org/D56753

Files:
  lib/AST/ASTDumper.cpp


Index: lib/AST/ASTDumper.cpp
===
--- lib/AST/ASTDumper.cpp
+++ lib/AST/ASTDumper.cpp
@@ -633,13 +633,14 @@
 }
   }
 
+  if (!D->param_begin() && D->getNumParams())
+OS << " >";
+
   if (const auto *FTSI = D->getTemplateSpecializationInfo())
 dumpTemplateArgumentList(*FTSI->TemplateArguments);
 
-  if (!D->param_begin() && D->getNumParams())
-dumpChild([=] { OS << ">"; });
-  else
-for (const ParmVarDecl *Parameter : D->parameters())
+  if (D->param_begin() || !D->getNumParams())
+for (const auto *Parameter : D->parameters())
   dumpDecl(Parameter);
 
   if (const auto *C = dyn_cast(D))


Index: lib/AST/ASTDumper.cpp
===
--- lib/AST/ASTDumper.cpp
+++ lib/AST/ASTDumper.cpp
@@ -633,13 +633,14 @@
 }
   }
 
+  if (!D->param_begin() && D->getNumParams())
+OS << " >";
+
   if (const auto *FTSI = D->getTemplateSpecializationInfo())
 dumpTemplateArgumentList(*FTSI->TemplateArguments);
 
-  if (!D->param_begin() && D->getNumParams())
-dumpChild([=] { OS << ">"; });
-  else
-for (const ParmVarDecl *Parameter : D->parameters())
+  if (D->param_begin() || !D->getNumParams())
+for (const auto *Parameter : D->parameters())
   dumpDecl(Parameter);
 
   if (const auto *C = dyn_cast(D))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: r351160 - [X86] Make _xgetbv/_xsetbv on non-windows platforms

2019-01-15 Thread Benjamin Kramer via cfe-commits
I think the only viable solution is to make v8 not define reserved
identifiers & reland this change. That will take some time, so unless this
is blocking something important I'd prefer to reland after the release cut
so the world can catch up before the next release. I can take care of
sending v8 a patch if nobody else feels like doing it.

On Tue, Jan 15, 2019 at 11:28 PM Craig Topper 
wrote:

> any suggestions on how to proceed here?
>
> ~Craig
>
>
> On Tue, Jan 15, 2019 at 10:56 AM Benjamin Kramer 
> wrote:
>
>> I think the main issue is that libstdc++ 4.9 includes x86intrin.h
>> transitively from . That's probably broken with all compilers :(
>>
>> On Tue, Jan 15, 2019 at 7:31 PM Craig Topper 
>> wrote:
>>
>>> Does V8 work with gcc which also has _xgetbv? Or is it because I had to
>>> make _xgetbv a macro to make the patch work?
>>>
>>> ~Craig
>>>
>>>
>>> On Tue, Jan 15, 2019 at 9:28 AM Benjamin Kramer via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 I rolled it back for now in r351210, this pattern seems to be quite
 common even outside of v8. Let's figure out if we can keep the code working
 or if it needs to be fixed all over the place :(

 On Tue, Jan 15, 2019 at 3:02 PM Benjamin Kramer 
 wrote:

> I'm seeing breakages on v8 with this, it defines its own _xgetbv. Any
> ideas what do do about this?
>
>
> https://chromium.googlesource.com/v8/v8.git/+/master/src/x64/assembler-x64.cc#36
>
> src/x64/assembler-x64.cc:35:1: error: inline variables are
> incompatible with C++ standards before C++17
> [-Werror,-Wc++98-c++11-c++14-compat]
> V8_INLINE uint64_t _xgetbv(unsigned int xcr) {
> ^
> include/v8config.h:294:20: note: expanded from macro 'V8_INLINE'
> # define V8_INLINE inline __attribute__((always_inline))
>^
> src/x64/assembler-x64.cc:35:41: error: expected ')'
> V8_INLINE uint64_t _xgetbv(unsigned int xcr) {
> ^
> src/x64/assembler-x64.cc:35:20: note: to match this '('
> V8_INLINE uint64_t _xgetbv(unsigned int xcr) {
>^
> lib/clang/include/xsaveintrin.h:49:53: note: expanded from macro
> '_xgetbv'
> #define _xgetbv(A) __builtin_ia32_xgetbv((long long)(A))
>
> On Tue, Jan 15, 2019 at 6:06 AM Craig Topper via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: ctopper
>> Date: Mon Jan 14 21:03:18 2019
>> New Revision: 351160
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=351160=rev
>> Log:
>> [X86] Make _xgetbv/_xsetbv on non-windows platforms
>>
>> Summary:
>> This patch attempts to redo what was tried in r278783, but was
>> reverted.
>>
>> These intrinsics should be available on non-windows platforms with
>> "xsave" feature check. But on Windows platforms they shouldn't have 
>> feature
>> check since that's how MSVC behaves.
>>
>> To accomplish this I've added a MS builtin with no feature check. And
>> a normal gcc builtin with a feature check. When _MSC_VER is not defined
>> _xgetbv/_xsetbv will be macros pointing to the gcc builtin name.
>>
>> I've moved the forward declarations from intrin.h to immintrin.h to
>> match the MSDN documentation and used that as the header file for the MS
>> builtin.
>>
>> I'm not super happy with this implementation, and I'm open to
>> suggestions for better ways to do it.
>>
>> Reviewers: rnk, RKSimon, spatel
>>
>> Reviewed By: rnk
>>
>> Subscribers: cfe-commits
>>
>> Differential Revision: https://reviews.llvm.org/D56686
>>
>> Modified:
>> cfe/trunk/include/clang/Basic/BuiltinsX86.def
>> cfe/trunk/lib/CodeGen/CGBuiltin.cpp
>> cfe/trunk/lib/Headers/immintrin.h
>> cfe/trunk/lib/Headers/intrin.h
>> cfe/trunk/lib/Headers/xsaveintrin.h
>> cfe/trunk/test/CodeGen/builtins-x86.c
>> cfe/trunk/test/CodeGen/x86_32-xsave.c
>> cfe/trunk/test/CodeGen/x86_64-xsave.c
>> cfe/trunk/test/Headers/ms-intrin.cpp
>>
>> Modified: cfe/trunk/include/clang/Basic/BuiltinsX86.def
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsX86.def?rev=351160=351159=351160=diff
>>
>> ==
>> --- cfe/trunk/include/clang/Basic/BuiltinsX86.def (original)
>> +++ cfe/trunk/include/clang/Basic/BuiltinsX86.def Mon Jan 14 21:03:18
>> 2019
>> @@ -693,6 +693,10 @@ TARGET_BUILTIN(__builtin_ia32_fxsave, "v
>>  // XSAVE
>>  TARGET_BUILTIN(__builtin_ia32_xsave, "vv*ULLi", "n", "xsave")
>>  TARGET_BUILTIN(__builtin_ia32_xrstor, "vv*ULLi", "n", "xsave")
>> +TARGET_BUILTIN(__builtin_ia32_xgetbv, "ULLiUi", "n", "xsave")
>> +TARGET_HEADER_BUILTIN(_xgetbv, "UWiUi", "nh", "immintrin.h",
>> 

[PATCH] D56731: Add -Wimplicit-ctad warning to diagnose CTAD on types with no user defined deduction guides.

2019-01-15 Thread James Dennett via Phabricator via cfe-commits
jdennett added a comment.

In D56731#1358907 , @Quuxplusone wrote:

> For my own use-cases, I will continue to want a 100% comprehensive `-Wctad`. 
> All these "heuristics" you're proposing seem very ad-hoc, and make a lot of 
> work for the compiler vendor, and seem complicated enough that I would still 
> worry about bugs slipping through the cracks. Whereas, if the user can simply 
> 100% outlaw CTAD, then they don't ever have to worry.


That's fair; I don't think anyone here is speaking against such a diagnostic 
(though maybe the name will be a bikeshed).  It's just that this patch is a 
solution for a different problem: allowing the sufficiently safe uses of CTAD 
without allowing too many bugs.


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

https://reviews.llvm.org/D56731



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


[PATCH] D56752: [ASTDump] Mark BlockDecls which capture this with a tag

2019-01-15 Thread Stephen Kelly via Phabricator via cfe-commits
steveire created this revision.
steveire added a reviewer: aaron.ballman.
Herald added a subscriber: cfe-commits.

Removal of the child node makes it easier to separate traversal from
output generation.


Repository:
  rC Clang

https://reviews.llvm.org/D56752

Files:
  lib/AST/ASTDumper.cpp


Index: lib/AST/ASTDumper.cpp
===
--- lib/AST/ASTDumper.cpp
+++ lib/AST/ASTDumper.cpp
@@ -1379,12 +1379,12 @@
   if (D->isVariadic())
 OS << " variadic";
 
+  if (D->capturesCXXThis())
+OS << "captures_this";
+
   for (auto I : D->parameters())
 dumpDecl(I);
 
-  if (D->capturesCXXThis())
-dumpChild([=]{ OS << "capture this"; });
-
   for (const auto  : D->captures())
 Visit(I);
   dumpStmt(D->getBody());


Index: lib/AST/ASTDumper.cpp
===
--- lib/AST/ASTDumper.cpp
+++ lib/AST/ASTDumper.cpp
@@ -1379,12 +1379,12 @@
   if (D->isVariadic())
 OS << " variadic";
 
+  if (D->capturesCXXThis())
+OS << "captures_this";
+
   for (auto I : D->parameters())
 dumpDecl(I);
 
-  if (D->capturesCXXThis())
-dumpChild([=]{ OS << "capture this"; });
-
   for (const auto  : D->captures())
 Visit(I);
   dumpStmt(D->getBody());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D56731: Add -Wimplicit-ctad warning to diagnose CTAD on types with no user defined deduction guides.

2019-01-15 Thread Arthur O'Dwyer via Phabricator via cfe-commits
Quuxplusone added a comment.

> Concretely, I think we could warn if, during template instantiation from a 
> type-dependent initializer, we select the copy deduction candidate and there 
> was another viable candidate (the `optional o(x)` case, the `tuple 
> t{args...}` case, etc), maybe under a new `-Wctad-unwrap` or similar.

The trick is that you have to give the warning //even when the copy deduction 
candidate is not selected// — e.g. `tuple t{args...}` when `args...` is not a 
1-parameter pack //right now// but if it might turn out to be a 1-parameter 
pack at "production time" (after the library has reached the customer).

> I don't see a good general way to catch and warn on bugs like `vector 
> v("foo", "bar")`

You mean `vector v("foo", "bar")`. Without CTAD — `vector v("foo", 
"bar")` — there's no bug; the line of code simply doesn't compile, that's all. 
What CTAD adds is the possibility for the line to quietly //compile into the 
wrong thing//.

> (this problem isn't really specific to CTAD)

Maybe not, but it's certainly //correlated//, right?

> but we could certainly add some special-case heuristics to detect cases where 
> a pair of string literals is passed to a constructor of a container-like type 
> (for example, we could check whether the constructor looks like it can be 
> called with arbitrary iterators as arguments, the class also has an 
> `initializer_list` constructor where a string literal can be implicitly 
> converted to `T`, and the class has begin and end member functions).

For my own use-cases, I will continue to want a 100% comprehensive `-Wctad`. 
All these "heuristics" you're proposing seem very ad-hoc, and make a lot of 
work for the compiler vendor, and seem complicated enough that I would still 
worry about bugs slipping through the cracks. Whereas, if the user can simply 
100% outlaw CTAD, then they don't ever have to worry.


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

https://reviews.llvm.org/D56731



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


[PATCH] D56751: [ASTDump] Mark variadic declarations with a tag instead of child node

2019-01-15 Thread Stephen Kelly via Phabricator via cfe-commits
steveire created this revision.
steveire added a reviewer: aaron.ballman.
Herald added a subscriber: cfe-commits.

This makes it easier to separate traversal of the AST from output
generation.


Repository:
  rC Clang

https://reviews.llvm.org/D56751

Files:
  lib/AST/ASTDumper.cpp
  lib/AST/TextNodeDumper.cpp
  test/AST/ast-dump-decl.m


Index: test/AST/ast-dump-decl.m
===
--- test/AST/ast-dump-decl.m
+++ test/AST/ast-dump-decl.m
@@ -28,20 +28,18 @@
 @interface testObjCMethodDecl : A {
 }
 - (int) TestObjCMethodDecl: (int)i, ...;
-// CHECK:  ObjCMethodDecl{{.*}} - TestObjCMethodDecl: 'int'
+// CHECK:  ObjCMethodDecl{{.*}} - TestObjCMethodDecl: 'int' variadic
 // CHECK-NEXT:   ParmVarDecl{{.*}} i 'int'
-// CHECK-NEXT:   ...
 @end
 
 @implementation testObjCMethodDecl
 - (int) TestObjCMethodDecl: (int)i, ... {
   return 0;
 }
-// CHECK:  ObjCMethodDecl{{.*}} - TestObjCMethodDecl: 'int'
+// CHECK:  ObjCMethodDecl{{.*}} - TestObjCMethodDecl: 'int' variadic
 // CHECK-NEXT:   ImplicitParamDecl{{.*}} self
 // CHECK-NEXT:   ImplicitParamDecl{{.*}} _cmd
 // CHECK-NEXT:   ParmVarDecl{{.*}} i 'int'
-// CHECK-NEXT:   ...
 // CHECK-NEXT:   CompoundStmt
 @end
 
@@ -137,9 +135,8 @@
   ^(int y, ...){ x; };
 }
 // CHECK:  FunctionDecl{{.*}}TestBlockDecl
-// CHECK:  BlockDecl
+// CHECK:  BlockDecl {{.+}}  col:3 variadic
 // CHECK-NEXT:   ParmVarDecl{{.*}} y 'int'
-// CHECK-NEXT:   ...
 // CHECK-NEXT:   capture ParmVar{{.*}} 'x' 'int'
 // CHECK-NEXT:   CompoundStmt
 
Index: lib/AST/TextNodeDumper.cpp
===
--- lib/AST/TextNodeDumper.cpp
+++ lib/AST/TextNodeDumper.cpp
@@ -1096,6 +1096,8 @@
 OS << " volatile";
   if (T->isRestrict())
 OS << " restrict";
+  if (T->getExtProtoInfo().Variadic)
+OS << " variadic";
   switch (EPI.RefQualifier) {
   case RQ_None:
 break;
Index: lib/AST/ASTDumper.cpp
===
--- lib/AST/ASTDumper.cpp
+++ lib/AST/ASTDumper.cpp
@@ -164,8 +164,6 @@
   VisitFunctionType(T);
   for (QualType PT : T->getParamTypes())
 dumpTypeAsChild(PT);
-  if (T->getExtProtoInfo().Variadic)
-dumpChild([=] { OS << "..."; });
 }
 void VisitTypeOfExprType(const TypeOfExprType *T) {
   dumpStmt(T->getUnderlyingExpr());
@@ -1236,6 +1234,9 @@
   NodeDumper.dumpName(D);
   NodeDumper.dumpType(D->getReturnType());
 
+  if (D->isVariadic())
+OS << " variadic";
+
   if (D->isThisDeclarationADefinition()) {
 dumpDeclContext(D);
   } else {
@@ -1243,9 +1244,6 @@
   dumpDecl(Parameter);
   }
 
-  if (D->isVariadic())
-dumpChild([=] { OS << "..."; });
-
   if (D->hasBody())
 dumpStmt(D->getBody());
 }
@@ -1378,12 +1376,12 @@
 }
 
 void ASTDumper::VisitBlockDecl(const BlockDecl *D) {
+  if (D->isVariadic())
+OS << " variadic";
+
   for (auto I : D->parameters())
 dumpDecl(I);
 
-  if (D->isVariadic())
-dumpChild([=]{ OS << "..."; });
-
   if (D->capturesCXXThis())
 dumpChild([=]{ OS << "capture this"; });
 


Index: test/AST/ast-dump-decl.m
===
--- test/AST/ast-dump-decl.m
+++ test/AST/ast-dump-decl.m
@@ -28,20 +28,18 @@
 @interface testObjCMethodDecl : A {
 }
 - (int) TestObjCMethodDecl: (int)i, ...;
-// CHECK:  ObjCMethodDecl{{.*}} - TestObjCMethodDecl: 'int'
+// CHECK:  ObjCMethodDecl{{.*}} - TestObjCMethodDecl: 'int' variadic
 // CHECK-NEXT:   ParmVarDecl{{.*}} i 'int'
-// CHECK-NEXT:   ...
 @end
 
 @implementation testObjCMethodDecl
 - (int) TestObjCMethodDecl: (int)i, ... {
   return 0;
 }
-// CHECK:  ObjCMethodDecl{{.*}} - TestObjCMethodDecl: 'int'
+// CHECK:  ObjCMethodDecl{{.*}} - TestObjCMethodDecl: 'int' variadic
 // CHECK-NEXT:   ImplicitParamDecl{{.*}} self
 // CHECK-NEXT:   ImplicitParamDecl{{.*}} _cmd
 // CHECK-NEXT:   ParmVarDecl{{.*}} i 'int'
-// CHECK-NEXT:   ...
 // CHECK-NEXT:   CompoundStmt
 @end
 
@@ -137,9 +135,8 @@
   ^(int y, ...){ x; };
 }
 // CHECK:  FunctionDecl{{.*}}TestBlockDecl
-// CHECK:  BlockDecl
+// CHECK:  BlockDecl {{.+}}  col:3 variadic
 // CHECK-NEXT:   ParmVarDecl{{.*}} y 'int'
-// CHECK-NEXT:   ...
 // CHECK-NEXT:   capture ParmVar{{.*}} 'x' 'int'
 // CHECK-NEXT:   CompoundStmt
 
Index: lib/AST/TextNodeDumper.cpp
===
--- lib/AST/TextNodeDumper.cpp
+++ lib/AST/TextNodeDumper.cpp
@@ -1096,6 +1096,8 @@
 OS << " volatile";
   if (T->isRestrict())
 OS << " restrict";
+  if (T->getExtProtoInfo().Variadic)
+OS << " variadic";
   switch (EPI.RefQualifier) {
   case RQ_None:
 break;
Index: lib/AST/ASTDumper.cpp
===
--- lib/AST/ASTDumper.cpp
+++ lib/AST/ASTDumper.cpp
@@ -164,8 +164,6 @@
   VisitFunctionType(T);
   for (QualType PT : T->getParamTypes())
 

[PATCH] D38430: Enable -pie and --enable-new-dtags by default on Android.

2019-01-15 Thread Peter Collingbourne via Phabricator via cfe-commits
pcc added inline comments.



Comment at: cfe/trunk/lib/Driver/ToolChains/Linux.cpp:814
+bool Linux::isPIEDefault() const {
+  return (getTriple().isAndroid() && !getTriple().isAndroidVersionLT(16)) ||
+ getSanitizerArgs().requiresPIE();

eugenis wrote:
> pcc wrote:
> > Why only on API level >= 16? If I create an executable targeting an older 
> > API level, it should still work on higher API levels.
> Because it needs to work on lower API levels, too. I think at some point PIE 
> was actually not supported, so there is no good default that works for 
> everyone.
I see. Looking at the tags in which 
https://github.com/aosp-mirror/platform_bionic/commit/d9ad62343c2db6b66a5fa597c9b20a6faabd7a9a
 was present, support was indeed added in Jelly Bean, which was API level 16. 
So this is correct.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D38430



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


[PATCH] D55447: [Sema] Fix Modified Type in address_space AttributedType

2019-01-15 Thread Leonard Chan via Phabricator via cfe-commits
leonardchan marked an inline comment as done.
leonardchan added inline comments.



Comment at: clang/tools/libclang/CXType.cpp:132
+  if (!(TU->ParsingOptions & CXTranslationUnit_IncludeAttributedTypes) &&
+  ATT->getAttrKind() != attr::AddressSpace) {
 return MakeCXType(ATT->getModifiedType(), TU);

aaron.ballman wrote:
> leonardchan wrote:
> > leonardchan wrote:
> > > aaron.ballman wrote:
> > > > leonardchan wrote:
> > > > > aaron.ballman wrote:
> > > > > > leonardchan wrote:
> > > > > > > aaron.ballman wrote:
> > > > > > > > leonardchan wrote:
> > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > leonardchan wrote:
> > > > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > > > This change seems surprising -- if the parsing options 
> > > > > > > > > > > > say the caller does not want attributed types, why are 
> > > > > > > > > > > > we returning one anyway for address space?
> > > > > > > > > > > This has to do with ensuring `clang_getAddressSpace` 
> > > > > > > > > > > still returns the proper address_space. It does this by 
> > > > > > > > > > > essentially checking the qualifiers of the type, which we 
> > > > > > > > > > > now attach to the `AttributedType` whereas before it was 
> > > > > > > > > > > attached to the modified type.
> > > > > > > > > > > 
> > > > > > > > > > > This extra condition is necessary for ensuring that 
> > > > > > > > > > > calling `clang_getAddressSpace` points to the qualified 
> > > > > > > > > > > AttributedType instead of the unqualified modified type.
> > > > > > > > > > My fear is that this will be breaking assumptions in 
> > > > > > > > > > third-party code. If someone disables 
> > > > > > > > > > `CXTranslationUnit_IncludeAttributedTypes`, they are 
> > > > > > > > > > unlikely to expect to receive an `AttributedType` and may 
> > > > > > > > > > react poorly to it.
> > > > > > > > > Instead check if the type is address_space attributed and 
> > > > > > > > > apply the qualifiers the modified type.
> > > > > > > > Sure, they can always modify their code to handle it 
> > > > > > > > gracefully, but it's a silent, breaking change to a somewhat 
> > > > > > > > stable API which is why I was prodding about it.
> > > > > > > > 
> > > > > > > > After talking with @rsmith, we're thinking the correct change 
> > > > > > > > here is to return the attributed type when the user asks for 
> > > > > > > > it, but return the equivalent type rather than the modified 
> > > > > > > > type if the user doesn't want attribute sugar (for all 
> > > > > > > > attributes, not just address spaces). This way, when a user 
> > > > > > > > asks for CXType for one of these, they always get a correct 
> > > > > > > > type but sometimes it has attribute type sugar and sometimes it 
> > > > > > > > doesn't, depending on the parsing options.
> > > > > > > > 
> > > > > > > > This is still a silent, breaking change in behavior, which is 
> > > > > > > > unfortunate. It should probably come with a mention in the 
> > > > > > > > release notes about the change to the API and some unit tests 
> > > > > > > > as well.
> > > > > > > Ok. In the case of qualifiers then, should the equivalent type 
> > > > > > > still contain the address_space qualifiers when creating the 
> > > > > > > AttributedType?
> > > > > > I believe so, yes -- that would ensure it's the minimally desugared 
> > > > > > type which the type is canonically equivalent to.
> > > > > Sorry for the holdup. So for an AddressSpace AttributedType, we 
> > > > > attach the qualifiers only to the equivalent type.
> > > > > 
> > > > > As for this though, the only problem I ran into with returning the 
> > > > > equivalent type is for AttributedTypes with `attr::ObjCKindOf`, a 
> > > > > test expects returning the modified type which is an `ObjCInterface` 
> > > > > instead of the equivalent type which is an `ObjCObject`. The test 
> > > > > itself just tests printing of a type, but I'm not sure how 
> > > > > significant or intentional printing this specific way was.
> > > > Which test was failing because of this?
> > > clang/test/Index/print-type.m
> > Specifically just the check:
> > 
> > ```
> > CHECK: ParmDecl=p:6:36 (Definition) [type=__kindof Foo *] 
> > [typekind=ObjCObjectPointer] [canonicaltype=__kindof Foo *] 
> > [canonicaltypekind=ObjCObjectPointer] [basetype=Foo] 
> > [basekind=ObjCInterface] [isPOD=1] [pointeetype=Foo] 
> > [pointeekind=ObjCInterface]
> > ```
> > 
> > Where the last 2 fields we're instead `[pointeetype=__kindof Foo] 
> > [pointeekind=ObjCObject]` instead of what they are now.
> I looked at the review adding the impacted test case and I did not have the 
> impression this was a principled decision so much as "that's what it prints". 
> I suspect we'd be fine removing the hack and always returning the equivalent 
> type, but ObjC is not my area of expertise.
Done. Is there also a place I should add this to let others know of this change?



[PATCH] D55447: [Sema] Fix Modified Type in address_space AttributedType

2019-01-15 Thread Leonard Chan via Phabricator via cfe-commits
leonardchan updated this revision to Diff 181902.
leonardchan marked an inline comment as done.
Herald added a subscriber: arphaman.

Repository:
  rC Clang

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

https://reviews.llvm.org/D55447

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/AST/address_space_attribute.cpp
  clang/test/Index/print-type.m
  clang/tools/libclang/CXType.cpp

Index: clang/tools/libclang/CXType.cpp
===
--- clang/tools/libclang/CXType.cpp
+++ clang/tools/libclang/CXType.cpp
@@ -129,7 +129,9 @@
 // Handle attributed types as the original type
 if (auto *ATT = T->getAs()) {
   if (!(TU->ParsingOptions & CXTranslationUnit_IncludeAttributedTypes)) {
-return MakeCXType(ATT->getModifiedType(), TU);
+// Return the equivalent type which represents the canonically
+// equivalent type.
+return MakeCXType(ATT->getEquivalentType(), TU);
   }
 }
 // Handle paren types as the original type
Index: clang/test/Index/print-type.m
===
--- clang/test/Index/print-type.m
+++ clang/test/Index/print-type.m
@@ -19,6 +19,6 @@
 // CHECK: ObjCInstanceMethodDecl=methodIn:andOut::5:10 (variadic) [Bycopy,] [type=] [typekind=Invalid] [resulttype=id] [resulttypekind=ObjCId] [args= [int] [Int] [short *] [Pointer]] [isPOD=0]
 // CHECK: ParmDecl=i:5:27 (Definition) [In,] [type=int] [typekind=Int] [isPOD=1]
 // CHECK: ParmDecl=j:5:49 (Definition) [Out,] [type=short *] [typekind=Pointer] [isPOD=1] [pointeetype=short] [pointeekind=Short]
-// CHECK: ParmDecl=p:6:36 (Definition) [type=__kindof Foo *] [typekind=ObjCObjectPointer] [canonicaltype=__kindof Foo *] [canonicaltypekind=ObjCObjectPointer] [basetype=Foo] [basekind=ObjCInterface] [isPOD=1] [pointeetype=Foo] [pointeekind=ObjCInterface]
+// CHECK: ParmDecl=p:6:36 (Definition) [type=__kindof Foo *] [typekind=ObjCObjectPointer] [canonicaltype=__kindof Foo *] [canonicaltypekind=ObjCObjectPointer] [basetype=Foo] [basekind=ObjCInterface] [isPOD=1] [pointeetype=__kindof Foo] [pointeekind=ObjCObject]
 // CHECK: ObjCPropertyDecl=classProp:7:23 [class,] [type=int] [typekind=Int] [isPOD=1]
 // CHECK: ObjCInstanceMethodDecl=generic:11:12 [type=] [typekind=Invalid] [resulttype=SomeType] [resulttypekind=ObjCTypeParam] [isPOD=0]
Index: clang/test/AST/address_space_attribute.cpp
===
--- /dev/null
+++ clang/test/AST/address_space_attribute.cpp
@@ -0,0 +1,23 @@
+// RUN: %clang_cc1 %s -ast-dump | FileCheck %s
+
+// Veryify the ordering of the address_space attribute still comes before the
+// type whereas other attributes are still printed after.
+
+template 
+void func() {
+  // CHECK: VarDecl {{.*}} x '__attribute__((address_space(1))) int *'
+  __attribute__((address_space(1))) int *x;
+
+  // CHECK: VarDecl {{.*}} a 'int * __attribute__((noderef))'
+  int __attribute__((noderef)) * a;
+
+  // CHECK: VarDecl {{.*}} y '__attribute__((address_space(2))) int *'
+  __attribute__((address_space(I))) int *y;
+
+  // CHECK: VarDecl {{.*}} z '__attribute__((address_space(3))) int *'
+  [[clang::address_space(3)]] int *z;
+}
+
+void func2() {
+  func<2>();
+}
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -5756,28 +5756,27 @@
 // Type Attribute Processing
 //===--===//
 
-/// BuildAddressSpaceAttr - Builds a DependentAddressSpaceType if an expression
-/// is uninstantiated. If instantiated it will apply the appropriate address space
-/// to the type. This function allows dependent template variables to be used in
-/// conjunction with the address_space attribute
-QualType Sema::BuildAddressSpaceAttr(QualType , Expr *AddrSpace,
- SourceLocation AttrLoc) {
+/// Build an AddressSpace index from a constant expression and diagnose any
+/// errors related to invalid address_spaces. Returns true on successfully
+/// building an AddressSpace index.
+static bool BuildAddressSpaceIndex(Sema , LangAS ,
+   const Expr *AddrSpace,
+   SourceLocation AttrLoc) {
   if (!AddrSpace->isValueDependent()) {
-
 llvm::APSInt addrSpace(32);
-if (!AddrSpace->isIntegerConstantExpr(addrSpace, Context)) {
-  Diag(AttrLoc, diag::err_attribute_argument_type)
+if (!AddrSpace->isIntegerConstantExpr(addrSpace, S.Context)) {
+  S.Diag(AttrLoc, diag::err_attribute_argument_type)
   << "'address_space'" << AANT_ArgumentIntegerConstant
   << AddrSpace->getSourceRange();
-  return QualType();
+  return false;
 }
 
 // Bounds checking.
 

[PATCH] D53541: [COFF, ARM64] Do not emit x86_seh_recoverfp intrinsic

2019-01-15 Thread Mandeep Singh Grang via Phabricator via cfe-commits
mgrang added a comment.

I have renamed llvm.x86.seh.recoverfp intrinsic to llvm.eh.recoverfp in D56747 
 and D56748 .


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

https://reviews.llvm.org/D53541



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


[PATCH] D56748: [EH] Rename llvm.x86.seh.recoverfp intrinsic to llvm.eh.recoverfp

2019-01-15 Thread Mandeep Singh Grang via Phabricator via cfe-commits
mgrang created this revision.
mgrang added reviewers: rnk, efriedma.

This is the clang counterpart to D56747 .


Repository:
  rC Clang

https://reviews.llvm.org/D56748

Files:
  lib/CodeGen/CGException.cpp
  test/CodeGen/exceptions-seh.c
  test/CodeGenCXX/exceptions-seh-filter-captures.cpp


Index: test/CodeGenCXX/exceptions-seh-filter-captures.cpp
===
--- test/CodeGenCXX/exceptions-seh-filter-captures.cpp
+++ test/CodeGenCXX/exceptions-seh-filter-captures.cpp
@@ -21,7 +21,7 @@
 // CHECK: invoke void @might_crash()
 
 // CHECK-LABEL: define internal i32 @"?filt$0@0@test_freefunc@@"(i8* 
%exception_pointers, i8* %frame_pointer)
-// CHECK: %[[fp:[^ ]*]] = call i8* @llvm.x86.seh.recoverfp(i8* bitcast (void 
(i32)* @test_freefunc to i8*), i8* %frame_pointer)
+// CHECK: %[[fp:[^ ]*]] = call i8* @llvm.eh.recoverfp(i8* bitcast (void (i32)* 
@test_freefunc to i8*), i8* %frame_pointer)
 // CHECK: %[[p1_i8:[^ ]*]] = call i8* @llvm.localrecover(i8* bitcast (void 
(i32)* @test_freefunc to i8*), i8* %[[fp]], i32 0)
 // CHECK: %[[p1_ptr:[^ ]*]] = bitcast i8* %[[p1_i8]] to i32*
 // CHECK: %[[l1_i8:[^ ]*]] = call i8* @llvm.localrecover(i8* bitcast (void 
(i32)* @test_freefunc to i8*), i8* %[[fp]], i32 1)
@@ -51,7 +51,7 @@
 // CHECK: invoke void @might_crash()
 
 // CHECK-LABEL: define internal i32 @"?filt$0@0@test_method@S@@"(i8* 
%exception_pointers, i8* %frame_pointer)
-// CHECK: %[[fp:[^ ]*]] = call i8* @llvm.x86.seh.recoverfp(i8* bitcast (void 
(%struct.S*)* @"?test_method@S@@QEAAXXZ" to i8*), i8* %frame_pointer)
+// CHECK: %[[fp:[^ ]*]] = call i8* @llvm.eh.recoverfp(i8* bitcast (void 
(%struct.S*)* @"?test_method@S@@QEAAXXZ" to i8*), i8* %frame_pointer)
 // CHECK: %[[l1_i8:[^ ]*]] = call i8* @llvm.localrecover(i8* bitcast (void 
(%struct.S*)* @"?test_method@S@@QEAAXXZ" to i8*), i8* %[[fp]], i32 0)
 // CHECK: %[[l1_ptr:[^ ]*]] = bitcast i8* %[[l1_i8]] to i32*
 // CHECK: %[[l1:[^ ]*]] = load i32, i32* %[[l1_ptr]]
@@ -76,7 +76,7 @@
 // CHECK: invoke void @might_crash()
 
 // CHECK-LABEL: define internal i32 
@"?filt$0@0@?R@?0??test_lambda@@YAXXZ@"(i8* %exception_pointers, i8* 
%frame_pointer)
-// CHECK: %[[fp:[^ ]*]] = call i8* @llvm.x86.seh.recoverfp(i8* bitcast (void 
(%class.anon*)* @"??R@?0??test_lambda@@YAXXZ@QEBA@XZ" to i8*), i8* 
%frame_pointer)
+// CHECK: %[[fp:[^ ]*]] = call i8* @llvm.eh.recoverfp(i8* bitcast (void 
(%class.anon*)* @"??R@?0??test_lambda@@YAXXZ@QEBA@XZ" to i8*), i8* 
%frame_pointer)
 // CHECK: %[[l2_i8:[^ ]*]] = call i8* @llvm.localrecover(i8* bitcast (void 
(%class.anon*)* @"??R@?0??test_lambda@@YAXXZ@QEBA@XZ" to i8*), i8* 
%[[fp]], i32 0)
 // CHECK: %[[l2_ptr:[^ ]*]] = bitcast i8* %[[l2_i8]] to i32*
 // CHECK: %[[l2:[^ ]*]] = load i32, i32* %[[l2_ptr]]
Index: test/CodeGen/exceptions-seh.c
===
--- test/CodeGen/exceptions-seh.c
+++ test/CodeGen/exceptions-seh.c
@@ -52,7 +52,7 @@
 //
 // X86-LABEL: define internal i32 @"?filt$0@0@safe_div@@"()
 // X86: %[[ebp:[^ ]*]] = call i8* @llvm.frameaddress(i32 1)
-// X86: %[[fp:[^ ]*]] = call i8* @llvm.x86.seh.recoverfp(i8* bitcast (i32 
(i32, i32, i32*)* @safe_div to i8*), i8* %[[ebp]])
+// X86: %[[fp:[^ ]*]] = call i8* @llvm.eh.recoverfp(i8* bitcast (i32 (i32, 
i32, i32*)* @safe_div to i8*), i8* %[[ebp]])
 // X86: call i8* @llvm.localrecover(i8* bitcast (i32 (i32, i32, i32*)* 
@safe_div to i8*), i8* %[[fp]], i32 0)
 // X86: load i8*, i8**
 // X86: load i32*, i32**
@@ -95,16 +95,16 @@
 // CHECK: ret i32 %[[rv]]
 
 // X64-LABEL: define internal i32 @"?filt$0@0@filter_expr_capture@@"(i8* 
%exception_pointers, i8* %frame_pointer)
-// X64: %[[fp:[^ ]*]] = call i8* @llvm.x86.seh.recoverfp(i8* bitcast (i32 ()* 
@filter_expr_capture to i8*), i8* %frame_pointer)
+// X64: %[[fp:[^ ]*]] = call i8* @llvm.eh.recoverfp(i8* bitcast (i32 ()* 
@filter_expr_capture to i8*), i8* %frame_pointer)
 // X64: call i8* @llvm.localrecover(i8* bitcast (i32 ()* @filter_expr_capture 
to i8*), i8* %[[fp]], i32 0)
 //
 // ARM64-LABEL: define internal i32 @"?filt$0@0@filter_expr_capture@@"(i8* 
%exception_pointers, i8* %frame_pointer)
-// ARM64: %[[fp:[^ ]*]] = call i8* @llvm.x86.seh.recoverfp(i8* bitcast (i32 
()* @filter_expr_capture to i8*), i8* %frame_pointer)
+// ARM64: %[[fp:[^ ]*]] = call i8* @llvm.eh.recoverfp(i8* bitcast (i32 ()* 
@filter_expr_capture to i8*), i8* %frame_pointer)
 // ARM64: call i8* @llvm.localrecover(i8* bitcast (i32 ()* 
@filter_expr_capture to i8*), i8* %[[fp]], i32 0)
 //
 // X86-LABEL: define internal i32 @"?filt$0@0@filter_expr_capture@@"()
 // X86: %[[ebp:[^ ]*]] = call i8* @llvm.frameaddress(i32 1)
-// X86: %[[fp:[^ ]*]] = call i8* @llvm.x86.seh.recoverfp(i8* bitcast (i32 ()* 
@filter_expr_capture to i8*), i8* %[[ebp]])
+// X86: %[[fp:[^ ]*]] = call i8* @llvm.eh.recoverfp(i8* bitcast (i32 ()* 
@filter_expr_capture to i8*), i8* %[[ebp]])
 // X86: call i8* @llvm.localrecover(i8* bitcast (i32 

[PATCH] D56731: Add -Wimplicit-ctad warning to diagnose CTAD on types with no user defined deduction guides.

2019-01-15 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added a comment.

I like @Quuxplusone's suggestions for more heuristics here, but I think they 
should probably live under a different warning flag (collectively grouped under 
`-Wctad` as @lebedev.ri suggested). Concretely, I think we could warn if, 
during template instantiation from a type-dependent initializer, we select the 
copy deduction candidate and there was another viable candidate (the `optional 
o(x)` case, the `tuple t{args...}`case, etc), maybe under a new `-Wctad-unwrap` 
or similar.

I don't see a good general way to catch and warn on bugs like `vector 
v("foo", "bar")` (this problem isn't really specific to CTAD), but we could 
certainly add some special-case heuristics to detect cases where a pair of 
string literals is passed to a constructor of a container-like type (for 
example, we could check whether the constructor looks like it can be called 
with arbitrary iterators as arguments, the class also has an 
`initializer_list` constructor where a string literal can be implicitly 
converted to `T`, and the class has `begin` and `end` member functions).




Comment at: include/clang/Basic/DiagnosticGroups.td:1054
+
+def ImplicitCTADUsage : DiagGroup<"implicit-ctad">;

lebedev.ri wrote:
> Should this be in some group?
> Alternatively, would it make sense to add it to new `-Wctad` group?
Let's not add a `-Wctad` until we have more than one thing to put in it. I 
expect that to happen relatively soon :)



Comment at: include/clang/Basic/DiagnosticSemaKinds.td:2129
+def warn_class_template_argument_deduction_no_user_defined_guides : Warning<
+  "using class template argument deduction for %0 that has no user-defined 
deduction guides" >,
+  InGroup, DefaultIgnore;

gromer wrote:
> I'd prefer a phrasing more along the lines of "using class template argument 
> deduction for %0 that might not intentionally support it". That gives us more 
> room to do things like add an attribute later if necessary, and it helps the 
> user understand why this warning indicates a potential problem.
I like that approach; something like "using class template argument deduction 
for %0 that might not intend to support it" -- or perhaps more directly "%0 
might not intend to support class template argument deduction" -- along with a 
note describing how to syntactically suppress the warning (w"add a deduction 
guide to suppress this warning" or "use the [[clang::ctad]] attribute to 
suppress this warning" or whatever we decide is best).



Comment at: lib/Sema/SemaInit.cpp:9268
+
+  // Record if at least one user-defined deduction guide was considered
+  bool HasUserDefinedDeductionGuideCandidate = false;

Nit: LLVM / Clang style wants a period at the end of a comment.



Comment at: lib/Sema/SemaInit.cpp:9287
 
+  HasUserDeclaredDeductionGuideCandidate |= !GD->isImplicit();
+

Quuxplusone wrote:
> Nitpick: I don't know if this is LLVM style, but I wish this were written as
> 
> if (!GD->isImplicit())
>   HasUserDeclaredDeductionGuideCandidate = true;
> 
> for clarity. Also, is it "user-defined" (per the error message) or 
> "user-declared" (per the name of this variable)?
Formally, it's actually just "any deduction guides". Constructors aren't 
transformed into deduction guides; rather, deduction guides and constructors 
both form candidates for CTAD. So `HasAnyDeductionGuides` would work. (I also 
think we should omit the "candidates", because we don't care whether any 
deduction guides were candidates for this particular overload resolution, only 
whether there are any at all -- if we're excluding explicit deduction guides 
and the only deduction guides are explicit, we still want to (and do!) suppress 
the warning.


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

https://reviews.llvm.org/D56731



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


[PATCH] D53738: [Fixed Point Arithmetic] Fixed Point Addition

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

In D53738#1358249 , @rjmccall wrote:

> In D53738#172 , @rjmccall wrote:
>
> > In D53738#1333276 , @leonardchan 
> > wrote:
> >
> > > In D53738#1326071 , @rjmccall 
> > > wrote:
> > >
> > > > I'm fine with making this change under the assumption that we've gotten 
> > > > the language rule right.  Even if that weren't abstractly reasonable 
> > > > for general language work — and I do think it's reasonable when we have 
> > > > a good-faith question about the right semantics — this is clearly still 
> > > > an experimental implementation and will be for several months yet, and 
> > > > hopefully it won't take that long for us to get a response.
> > >
> > >
> > > @rjmccall Have you received a response yet? If not, do you think you have 
> > > an estimate on the response time, or also mind sharing the contact 
> > > information if that's ok?
> >
> >
> > I just have a coworker who's part of the committee.  I think you might be 
> > over-opimistic about how quickly things get answered with the C committee, 
> > though.  We should not allow our work to be blocked waiting for a response.
>
>
> The committee was less helpful than I hoped, but what I decided to take away 
> from their response was that we should not artificially lose precision here 
> by separating the signedness conversion from the operation.


Understood. I imagine this is a good way to proceed still. Currently in this 
patch, the signedness only affects determining the resulting type and does not 
change the operands during the operation. Is there anything else with this 
patch that should be addressed, or is it still fine to proceed without 
committing this patch yet?


Repository:
  rC Clang

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

https://reviews.llvm.org/D53738



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


[PATCH] D55850: [OpenCL] Allow address spaces as method qualifiers

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

Okay, so is this ready to re-review independently?


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

https://reviews.llvm.org/D55850



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


[PATCH] D56746: [Fixed Point Arithmetic] Add APFixedPoint to APValue

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

One nit-pick, then this is good to go.




Comment at: clang/include/clang/AST/APValue.h:183
+setFixedPoint(std::move(FX));
+  }
   explicit APValue(const APValue *E, unsigned N) : Kind(Uninitialized) {

I know this is the established pattern, but could you just make 
`MakeFixedPoint` take a `APFixedPoint &&` and move it into place instead of 
default-constructing one and then assigning over it?


Repository:
  rC Clang

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

https://reviews.llvm.org/D56746



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


[PATCH] D38430: Enable -pie and --enable-new-dtags by default on Android.

2019-01-15 Thread Evgenii Stepanov via Phabricator via cfe-commits
eugenis marked an inline comment as done.
eugenis added inline comments.



Comment at: cfe/trunk/lib/Driver/ToolChains/Linux.cpp:814
+bool Linux::isPIEDefault() const {
+  return (getTriple().isAndroid() && !getTriple().isAndroidVersionLT(16)) ||
+ getSanitizerArgs().requiresPIE();

pcc wrote:
> Why only on API level >= 16? If I create an executable targeting an older API 
> level, it should still work on higher API levels.
Because it needs to work on lower API levels, too. I think at some point PIE 
was actually not supported, so there is no good default that works for everyone.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D38430



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


[PATCH] D55394: Re-order type param children of ObjC nodes

2019-01-15 Thread Stephen Kelly via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL351272: Re-order type param children of ObjC nodes (authored 
by steveire, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D55394?vs=177071=181898#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D55394

Files:
  cfe/trunk/lib/AST/ASTDumper.cpp
  cfe/trunk/test/AST/ast-dump-decl.m


Index: cfe/trunk/test/AST/ast-dump-decl.m
===
--- cfe/trunk/test/AST/ast-dump-decl.m
+++ cfe/trunk/test/AST/ast-dump-decl.m
@@ -85,9 +85,9 @@
 }
 @end
 // CHECK:  ObjCInterfaceDecl{{.*}} TestGenericInterface
-// CHECK-NEXT:   -ObjCTypeParamDecl {{.+}}  col:33 T 'id':'id'
 // CHECK-NEXT:   -super ObjCInterface {{.+}} 'A'
 // CHECK-NEXT:   -ObjCProtocol {{.+}} 'P'
+// CHECK-NEXT:   -ObjCTypeParamDecl {{.+}}  col:33 T 'id':'id'
 
 @implementation TestObjCClass (TestObjCCategoryDecl)
 - (void) bar {
Index: cfe/trunk/lib/AST/ASTDumper.cpp
===
--- cfe/trunk/lib/AST/ASTDumper.cpp
+++ cfe/trunk/lib/AST/ASTDumper.cpp
@@ -1273,12 +1273,12 @@
 void ASTDumper::VisitObjCCategoryDecl(const ObjCCategoryDecl *D) {
   NodeDumper.dumpName(D);
   NodeDumper.dumpDeclRef(D->getClassInterface());
-  dumpObjCTypeParamList(D->getTypeParamList());
   NodeDumper.dumpDeclRef(D->getImplementation());
   for (ObjCCategoryDecl::protocol_iterator I = D->protocol_begin(),
E = D->protocol_end();
I != E; ++I)
 NodeDumper.dumpDeclRef(*I);
+  dumpObjCTypeParamList(D->getTypeParamList());
 }
 
 void ASTDumper::VisitObjCCategoryImplDecl(const ObjCCategoryImplDecl *D) {
@@ -1296,12 +1296,12 @@
 
 void ASTDumper::VisitObjCInterfaceDecl(const ObjCInterfaceDecl *D) {
   NodeDumper.dumpName(D);
-  dumpObjCTypeParamList(D->getTypeParamListAsWritten());
   NodeDumper.dumpDeclRef(D->getSuperClass(), "super");
 
   NodeDumper.dumpDeclRef(D->getImplementation());
   for (auto *Child : D->protocols())
 NodeDumper.dumpDeclRef(Child);
+  dumpObjCTypeParamList(D->getTypeParamListAsWritten());
 }
 
 void ASTDumper::VisitObjCImplementationDecl(const ObjCImplementationDecl *D) {


Index: cfe/trunk/test/AST/ast-dump-decl.m
===
--- cfe/trunk/test/AST/ast-dump-decl.m
+++ cfe/trunk/test/AST/ast-dump-decl.m
@@ -85,9 +85,9 @@
 }
 @end
 // CHECK:  ObjCInterfaceDecl{{.*}} TestGenericInterface
-// CHECK-NEXT:   -ObjCTypeParamDecl {{.+}}  col:33 T 'id':'id'
 // CHECK-NEXT:   -super ObjCInterface {{.+}} 'A'
 // CHECK-NEXT:   -ObjCProtocol {{.+}} 'P'
+// CHECK-NEXT:   -ObjCTypeParamDecl {{.+}}  col:33 T 'id':'id'
 
 @implementation TestObjCClass (TestObjCCategoryDecl)
 - (void) bar {
Index: cfe/trunk/lib/AST/ASTDumper.cpp
===
--- cfe/trunk/lib/AST/ASTDumper.cpp
+++ cfe/trunk/lib/AST/ASTDumper.cpp
@@ -1273,12 +1273,12 @@
 void ASTDumper::VisitObjCCategoryDecl(const ObjCCategoryDecl *D) {
   NodeDumper.dumpName(D);
   NodeDumper.dumpDeclRef(D->getClassInterface());
-  dumpObjCTypeParamList(D->getTypeParamList());
   NodeDumper.dumpDeclRef(D->getImplementation());
   for (ObjCCategoryDecl::protocol_iterator I = D->protocol_begin(),
E = D->protocol_end();
I != E; ++I)
 NodeDumper.dumpDeclRef(*I);
+  dumpObjCTypeParamList(D->getTypeParamList());
 }
 
 void ASTDumper::VisitObjCCategoryImplDecl(const ObjCCategoryImplDecl *D) {
@@ -1296,12 +1296,12 @@
 
 void ASTDumper::VisitObjCInterfaceDecl(const ObjCInterfaceDecl *D) {
   NodeDumper.dumpName(D);
-  dumpObjCTypeParamList(D->getTypeParamListAsWritten());
   NodeDumper.dumpDeclRef(D->getSuperClass(), "super");
 
   NodeDumper.dumpDeclRef(D->getImplementation());
   for (auto *Child : D->protocols())
 NodeDumper.dumpDeclRef(Child);
+  dumpObjCTypeParamList(D->getTypeParamListAsWritten());
 }
 
 void ASTDumper::VisitObjCImplementationDecl(const ObjCImplementationDecl *D) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r351272 - Re-order type param children of ObjC nodes

2019-01-15 Thread Stephen Kelly via cfe-commits
Author: steveire
Date: Tue Jan 15 15:07:30 2019
New Revision: 351272

URL: http://llvm.org/viewvc/llvm-project?rev=351272=rev
Log:
Re-order type param children of ObjC nodes

Reviewers: aaron.ballman

Subscribers: cfe-commits

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

Modified:
cfe/trunk/lib/AST/ASTDumper.cpp
cfe/trunk/test/AST/ast-dump-decl.m

Modified: cfe/trunk/lib/AST/ASTDumper.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ASTDumper.cpp?rev=351272=351271=351272=diff
==
--- cfe/trunk/lib/AST/ASTDumper.cpp (original)
+++ cfe/trunk/lib/AST/ASTDumper.cpp Tue Jan 15 15:07:30 2019
@@ -1273,12 +1273,12 @@ void ASTDumper::VisitObjCTypeParamDecl(c
 void ASTDumper::VisitObjCCategoryDecl(const ObjCCategoryDecl *D) {
   NodeDumper.dumpName(D);
   NodeDumper.dumpDeclRef(D->getClassInterface());
-  dumpObjCTypeParamList(D->getTypeParamList());
   NodeDumper.dumpDeclRef(D->getImplementation());
   for (ObjCCategoryDecl::protocol_iterator I = D->protocol_begin(),
E = D->protocol_end();
I != E; ++I)
 NodeDumper.dumpDeclRef(*I);
+  dumpObjCTypeParamList(D->getTypeParamList());
 }
 
 void ASTDumper::VisitObjCCategoryImplDecl(const ObjCCategoryImplDecl *D) {
@@ -1296,12 +1296,12 @@ void ASTDumper::VisitObjCProtocolDecl(co
 
 void ASTDumper::VisitObjCInterfaceDecl(const ObjCInterfaceDecl *D) {
   NodeDumper.dumpName(D);
-  dumpObjCTypeParamList(D->getTypeParamListAsWritten());
   NodeDumper.dumpDeclRef(D->getSuperClass(), "super");
 
   NodeDumper.dumpDeclRef(D->getImplementation());
   for (auto *Child : D->protocols())
 NodeDumper.dumpDeclRef(Child);
+  dumpObjCTypeParamList(D->getTypeParamListAsWritten());
 }
 
 void ASTDumper::VisitObjCImplementationDecl(const ObjCImplementationDecl *D) {

Modified: cfe/trunk/test/AST/ast-dump-decl.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/AST/ast-dump-decl.m?rev=351272=351271=351272=diff
==
--- cfe/trunk/test/AST/ast-dump-decl.m (original)
+++ cfe/trunk/test/AST/ast-dump-decl.m Tue Jan 15 15:07:30 2019
@@ -85,9 +85,9 @@
 }
 @end
 // CHECK:  ObjCInterfaceDecl{{.*}} TestGenericInterface
-// CHECK-NEXT:   -ObjCTypeParamDecl {{.+}}  col:33 T 'id':'id'
 // CHECK-NEXT:   -super ObjCInterface {{.+}} 'A'
 // CHECK-NEXT:   -ObjCProtocol {{.+}} 'P'
+// CHECK-NEXT:   -ObjCTypeParamDecl {{.+}}  col:33 T 'id':'id'
 
 @implementation TestObjCClass (TestObjCCategoryDecl)
 - (void) bar {


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


r351271 - NFC: Some cleanups that I missed in the previous commit

2019-01-15 Thread Stephen Kelly via cfe-commits
Author: steveire
Date: Tue Jan 15 15:05:11 2019
New Revision: 351271

URL: http://llvm.org/viewvc/llvm-project?rev=351271=rev
Log:
NFC: Some cleanups that I missed in the previous commit

Modified:
cfe/trunk/lib/AST/ASTDumper.cpp

Modified: cfe/trunk/lib/AST/ASTDumper.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ASTDumper.cpp?rev=351271=351270=351271=diff
==
--- cfe/trunk/lib/AST/ASTDumper.cpp (original)
+++ cfe/trunk/lib/AST/ASTDumper.cpp Tue Jan 15 15:05:11 2019
@@ -599,7 +599,7 @@ void ASTDumper::VisitFunctionDecl(const
   if (D->isTrivial())
 OS << " trivial";
 
-  if (const FunctionProtoType *FPT = D->getType()->getAs()) 
{
+  if (const auto *FPT = D->getType()->getAs()) {
 FunctionProtoType::ExtProtoInfo EPI = FPT->getExtProtoInfo();
 switch (EPI.ExceptionSpec.Type) {
 default: break;
@@ -612,7 +612,7 @@ void ASTDumper::VisitFunctionDecl(const
 }
   }
 
-  if (const CXXMethodDecl *MD = dyn_cast(D)) {
+  if (const auto *MD = dyn_cast(D)) {
 if (MD->size_overridden_methods() != 0) {
   auto dumpOverride = [=](const CXXMethodDecl *D) {
 SplitQualType T_split = D->getType().split();
@@ -635,8 +635,7 @@ void ASTDumper::VisitFunctionDecl(const
 }
   }
 
-  if (const FunctionTemplateSpecializationInfo *FTSI =
-  D->getTemplateSpecializationInfo())
+  if (const auto *FTSI = D->getTemplateSpecializationInfo())
 dumpTemplateArgumentList(*FTSI->TemplateArguments);
 
   if (!D->param_begin() && D->getNumParams())
@@ -645,11 +644,9 @@ void ASTDumper::VisitFunctionDecl(const
 for (const ParmVarDecl *Parameter : D->parameters())
   dumpDecl(Parameter);
 
-  if (const CXXConstructorDecl *C = dyn_cast(D))
-for (CXXConstructorDecl::init_const_iterator I = C->init_begin(),
- E = C->init_end();
- I != E; ++I)
-  dumpCXXCtorInitializer(*I);
+  if (const auto *C = dyn_cast(D))
+for (const auto *I : C->inits())
+  dumpCXXCtorInitializer(I);
 
   if (D->doesThisDeclarationHaveABody())
 dumpStmt(D->getBody());


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


[PATCH] D55868: [Fixed Point Arithmetic] Fixed Point Addition Constant Expression Evaluation

2019-01-15 Thread Leonard Chan via Phabricator via cfe-commits
leonardchan updated this revision to Diff 181897.
leonardchan marked 10 inline comments as done.

Repository:
  rC Clang

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

https://reviews.llvm.org/D55868

Files:
  clang/include/clang/AST/Expr.h
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/FixedPoint.h
  clang/lib/AST/ExprConstant.cpp
  clang/lib/Basic/FixedPoint.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/Frontend/fixed_point_add.c
  clang/test/Frontend/fixed_point_conversions.c
  clang/test/Frontend/fixed_point_errors.c

Index: clang/test/Frontend/fixed_point_errors.c
===
--- clang/test/Frontend/fixed_point_errors.c
+++ clang/test/Frontend/fixed_point_errors.c
@@ -232,3 +232,9 @@
   auto auto_accum = 0k;  // expected-error{{invalid suffix 'k' on integer constant}}
  // expected-warning@-1{{type specifier missing, defaults to 'int'}}
 }
+
+// Overflow
+short _Accum sa_const = 256.0k;   // expected-warning{{implicit conversion from 256.0 cannot fit within the range of values for 'short _Accum'}}
+short _Fract sf_const = 1.0hk;// expected-warning{{implicit conversion from 1.0 cannot fit within the range of values for 'short _Fract'}}
+unsigned _Accum ua_const = -1.0k; // expected-warning{{implicit conversion from -1.0 cannot fit within the range of values for 'unsigned _Accum'}}
+short _Accum sa_const2 = 128.0k + 128.0k; // expected-warning{{implicit conversion from 256.0 cannot fit within the range of values for 'short _Accum'}}
Index: clang/test/Frontend/fixed_point_conversions.c
===
--- clang/test/Frontend/fixed_point_conversions.c
+++ clang/test/Frontend/fixed_point_conversions.c
@@ -1,5 +1,39 @@
-// RUN: %clang_cc1 -ffixed-point -S -emit-llvm %s -o - | FileCheck %s -check-prefix=DEFAULT
-// RUN: %clang_cc1 -ffixed-point -S -emit-llvm %s -o - -fpadding-on-unsigned-fixed-point | FileCheck %s -check-prefix=SAME
+// RUN: %clang_cc1 -ffixed-point -triple x86_64-unknown-linux-gnu -S -emit-llvm %s -o - | FileCheck %s -check-prefix=DEFAULT
+// RUN: %clang_cc1 -ffixed-point -triple x86_64-unknown-linux-gnu -S -emit-llvm %s -o - -fpadding-on-unsigned-fixed-point | FileCheck %s -check-prefix=SAME
+
+// Between different fixed point types
+short _Accum sa_const = 2.5hk; // DEFAULT-DAG: @sa_const  = {{.*}}global i16 320, align 2
+_Accum a_const = 2.5hk;// DEFAULT-DAG: @a_const   = {{.*}}global i32 81920, align 4
+short _Accum sa_const2 = 2.5k; // DEFAULT-DAG: @sa_const2 = {{.*}}global i16 320, align 2
+
+short _Accum sa_from_f_const = 0.5r; // DEFAULT-DAG: sa_from_f_const = {{.*}}global i16 64, align 2
+_Fract f_from_sa_const = 0.5hk;  // DEFAULT-DAG: f_from_sa_const = {{.*}}global i16 16384, align 2
+
+unsigned short _Accum usa_const = 2.5uk;
+unsigned _Accum ua_const = 2.5uhk;
+// DEFAULT-DAG: @usa_const  = {{.*}}global i16 640, align 2
+// DEFAULT-DAG: @ua_const   = {{.*}}global i32 163840, align 4
+// SAME-DAG:@usa_const  = {{.*}}global i16 320, align 2
+// SAME-DAG:@ua_const   = {{.*}}global i32 81920, align 4
+
+// Signedness
+unsigned short _Accum usa_const2 = 2.5hk;
+// DEFAULT-DAG: @usa_const2  = {{.*}}global i16 640, align 2
+// SAME-DAG:@usa_const2  = {{.*}}global i16 320, align 2
+short _Accum sa_const3 = 2.5hk; // DEFAULT-DAG: @sa_const3 = {{.*}}global i16 320, align 2
+
+// Overflow (this is undefined but allowed)
+short _Accum sa_const4 = 256.0k;
+
+// Saturation
+_Sat short _Accum sat_sa_const = 2.5hk;   // DEFAULT-DAG: @sat_sa_const  = {{.*}}global i16 320, align 2
+_Sat short _Accum sat_sa_const2 = 256.0k; // DEFAULT-DAG: @sat_sa_const2 = {{.*}}global i16 32767, align 2
+_Sat unsigned short _Accum sat_usa_const = -1.0hk;
+// DEFAULT-DAG: @sat_usa_const = {{.*}}global i16 0, align 2
+// SAME-DAG:@sat_usa_const = {{.*}}global i16 0, align 2
+_Sat unsigned short _Accum sat_usa_const2 = 256.0k;
+// DEFAULT-DAG: @sat_usa_const2 = {{.*}}global i16 -1, align 2
+// SAME-DAG:@sat_usa_const2 = {{.*}}global i16 32767, align 2
 
 void TestFixedPointCastSameType() {
   _Accum a = 2.5k;
Index: clang/test/Frontend/fixed_point_add.c
===
--- clang/test/Frontend/fixed_point_add.c
+++ clang/test/Frontend/fixed_point_add.c
@@ -1,5 +1,48 @@
-// RUN: %clang_cc1 -ffixed-point -S -emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK,SIGNED
-// RUN: %clang_cc1 -ffixed-point -fpadding-on-unsigned-fixed-point -S -emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK,UNSIGNED
+// RUN: %clang_cc1 -ffixed-point -triple x86_64-unknown-linux-gnu -S -emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK,SIGNED
+// RUN: %clang_cc1 -ffixed-point -triple x86_64-unknown-linux-gnu -fpadding-on-unsigned-fixed-point -S -emit-llvm %s -o - | FileCheck %s 

[PATCH] D55868: [Fixed Point Arithmetic] Fixed Point Addition Constant Expression Evaluation

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

In D55868#1358208 , @rjmccall wrote:

> Yeah, I would recommend splitting the `APFixedPoint` in `APValue` changes 
> into a separate patch.


Added D56746  as a child revision of this that 
has the `APValue` changes.




Comment at: clang/lib/AST/ExprConstant.cpp:9927
   }
   return Success(-Value, E);
 }

ebevhan wrote:
> I think I've mentioned this before, but just as a reminder; this doesn't 
> perform correctly for saturation.
Added a `negate()` method to `APFixedPoint` which handles this now and accounts 
for saturation.



Comment at: clang/lib/AST/ExprConstant.cpp:9979
+APFixedPoint Result =
+LHSFX.getFixedPoint().add(RHSFX.getFixedPoint()).convert(ResultFXSema);
+return Success(Result, E);

ebevhan wrote:
> Perhaps this should call HandleOverflow (or do something else) to signal that 
> overflow occurred. HandleOverflow only seems to emit a note, though, but I 
> think it should probably be a warning.
> 
> Maybe for casts as well? Might get double warnings then, though.
Done. Double warnings don't seem to appear though.



Comment at: clang/lib/Basic/FixedPoint.cpp:25
   bool Upscaling = DstScale > getScale();
+  bool Overflowed = false;
 

ebevhan wrote:
> I think it's a bit cleaner if you avoid this variable and simply assign 
> `Overflow` directly here, with the 'else' cases below replaced with `else if 
> (Overflow)`.
> 
> That style isn't cleaner in `add` if you use the APInt add_ov functions 
> though, so maybe it's better to keep it this way for consistency.
I'm not really bothered much by either style, but if we want to be consistent 
with the APInt overflow operations, we could just make the overflow parameter a 
reference also while it's still new/under work.


Repository:
  rC Clang

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

https://reviews.llvm.org/D55868



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


Re: r351269 - Re-order overrides in FunctionDecl dump

2019-01-15 Thread Stephen Kelly via cfe-commits


On 15/01/2019 23:00, Aaron Ballman wrote:

On Tue, Jan 15, 2019 at 5:54 PM Stephen Kelly via cfe-commits
 wrote:

Author: steveire
Date: Tue Jan 15 14:50:37 2019
New Revision: 351269

URL: http://llvm.org/viewvc/llvm-project?rev=351269=rev
Log:
Re-order overrides in FunctionDecl dump

Output all content which is local to the FunctionDecl before traversing
to child AST nodes.

This is necessary so that all of the part which is local to the
FunctionDecl can be split into a different method.

Reviewers: aaron.ballman

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

Modified:
 cfe/trunk/lib/AST/ASTDumper.cpp
 cfe/trunk/test/AST/ast-dump-funcs.cpp

Modified: cfe/trunk/lib/AST/ASTDumper.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ASTDumper.cpp?rev=351269=351268=351269=diff
==
--- cfe/trunk/lib/AST/ASTDumper.cpp (original)
+++ cfe/trunk/lib/AST/ASTDumper.cpp Tue Jan 15 14:50:37 2019
@@ -612,20 +612,6 @@ void ASTDumper::VisitFunctionDecl(const
  }
}

-  if (const FunctionTemplateSpecializationInfo *FTSI =
-  D->getTemplateSpecializationInfo())
-dumpTemplateArgumentList(*FTSI->TemplateArguments);
-
-  if (!D->param_begin() && D->getNumParams())
-dumpChild([=] { OS << ">"; });
-  else
-for (const ParmVarDecl *Parameter : D->parameters())
-  dumpDecl(Parameter);
-
-  if (const CXXConstructorDecl *C = dyn_cast(D))
-for (const auto *I : C->inits())
-  dumpCXXCtorInitializer(I);
-
if (const CXXMethodDecl *MD = dyn_cast(D)) {
  if (MD->size_overridden_methods() != 0) {
auto dumpOverride = [=](const CXXMethodDecl *D) {
@@ -649,6 +635,22 @@ void ASTDumper::VisitFunctionDecl(const
  }
}

+  if (const FunctionTemplateSpecializationInfo *FTSI =
+  D->getTemplateSpecializationInfo())
+dumpTemplateArgumentList(*FTSI->TemplateArguments);
+
+  if (!D->param_begin() && D->getNumParams())
+dumpChild([=] { OS << ">"; });
+  else
+for (const ParmVarDecl *Parameter : D->parameters())
+  dumpDecl(Parameter);
+
+  if (const CXXConstructorDecl *C = dyn_cast(D))

Missed this nit from the review.


+for (CXXConstructorDecl::init_const_iterator I = C->init_begin(),
+ E = C->init_end();
+ I != E; ++I)
+  dumpCXXCtorInitializer(*I);

This accidentally reverts what you did in r351268.



Lol, thanks! Fixing now

Stephen.


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


[PATCH] D56746: [Fixed Point Arithmetic] Add APFixedPoint to APValue

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

Regarding tests, I couldn't actually find any under clang/unittests that test 
APValue specifically. Is it worth it to add some still?


Repository:
  rC Clang

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

https://reviews.llvm.org/D56746



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


[PATCH] D56746: [Fixed Point Arithmetic] Add APFixedPoint to APValue

2019-01-15 Thread Leonard Chan via Phabricator via cfe-commits
leonardchan created this revision.
leonardchan added reviewers: rjmccall, ebevhan, bjope.
leonardchan added a project: clang.

This adds APFixedPoint to the union of values that can be represented with an 
APValue.


Repository:
  rC Clang

https://reviews.llvm.org/D56746

Files:
  clang/include/clang/AST/APValue.h
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/FixedPoint.h
  clang/lib/AST/APValue.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/AST/Type.cpp
  clang/lib/Basic/FixedPoint.cpp
  clang/lib/CodeGen/CGExprConstant.cpp
  clang/lib/Sema/SemaTemplate.cpp

Index: clang/lib/Sema/SemaTemplate.cpp
===
--- clang/lib/Sema/SemaTemplate.cpp
+++ clang/lib/Sema/SemaTemplate.cpp
@@ -6342,6 +6342,7 @@
 }
 case APValue::AddrLabelDiff:
   return Diag(StartLoc, diag::err_non_type_template_arg_addr_label_diff);
+case APValue::FixedPoint:
 case APValue::Float:
 case APValue::ComplexInt:
 case APValue::ComplexFloat:
Index: clang/lib/CodeGen/CGExprConstant.cpp
===
--- clang/lib/CodeGen/CGExprConstant.cpp
+++ clang/lib/CodeGen/CGExprConstant.cpp
@@ -1873,6 +1873,9 @@
 return ConstantLValueEmitter(*this, Value, DestType).tryEmit();
   case APValue::Int:
 return llvm::ConstantInt::get(CGM.getLLVMContext(), Value.getInt());
+  case APValue::FixedPoint:
+return llvm::ConstantInt::get(CGM.getLLVMContext(),
+  Value.getFixedPoint().getValue());
   case APValue::ComplexInt: {
 llvm::Constant *Complex[2];
 
Index: clang/lib/Basic/FixedPoint.cpp
===
--- clang/lib/Basic/FixedPoint.cpp
+++ clang/lib/Basic/FixedPoint.cpp
@@ -137,4 +137,31 @@
  ResultIsSaturated, ResultHasUnsignedPadding);
 }
 
+void APFixedPoint::toString(llvm::SmallVectorImpl ) const {
+  llvm::APSInt Val = getValue();
+  unsigned Scale = getScale();
+
+  if (Val.isSigned() && Val.isNegative() && Val != -Val) {
+Val = -Val;
+Str.push_back('-');
+  }
+
+  llvm::APSInt IntPart = Val >> Scale;
+
+  // Add 4 digits to hold the value after multiplying 10 (the radix)
+  unsigned Width = Val.getBitWidth() + 4;
+  llvm::APInt FractPart = Val.zextOrTrunc(Scale).zext(Width);
+  llvm::APInt FractPartMask = llvm::APInt::getAllOnesValue(Scale).zext(Width);
+  llvm::APInt RadixInt = llvm::APInt(Width, 10);
+
+  IntPart.toString(Str, /*radix=*/10);
+  Str.push_back('.');
+  do {
+(FractPart * RadixInt)
+.lshr(Scale)
+.toString(Str, /*radix=*/10, Val.isSigned());
+FractPart = (FractPart * RadixInt) & FractPartMask;
+  } while (FractPart != 0);
+}
+
 }  // namespace clang
Index: clang/lib/AST/Type.cpp
===
--- clang/lib/AST/Type.cpp
+++ clang/lib/AST/Type.cpp
@@ -4016,25 +4016,8 @@
 
 void clang::FixedPointValueToString(SmallVectorImpl ,
 llvm::APSInt Val, unsigned Scale) {
-  if (Val.isSigned() && Val.isNegative() && Val != -Val) {
-Val = -Val;
-Str.push_back('-');
-  }
-
-  llvm::APSInt IntPart = Val >> Scale;
-
-  // Add 4 digits to hold the value after multiplying 10 (the radix)
-  unsigned Width = Val.getBitWidth() + 4;
-  llvm::APInt FractPart = Val.zextOrTrunc(Scale).zext(Width);
-  llvm::APInt FractPartMask = llvm::APInt::getAllOnesValue(Scale).zext(Width);
-  llvm::APInt RadixInt = llvm::APInt(Width, 10);
-
-  IntPart.toString(Str, /*radix=*/10);
-  Str.push_back('.');
-  do {
-(FractPart * RadixInt)
-.lshr(Scale)
-.toString(Str, /*radix=*/10, Val.isSigned());
-FractPart = (FractPart * RadixInt) & FractPartMask;
-  } while (FractPart != 0);
+  FixedPointSemantics FXSema(Val.getBitWidth(), Scale, Val.isSigned(),
+ /*isSaturated=*/false,
+ /*hasUnsignedPadding=*/false);
+  APFixedPoint(Val, FXSema).toString(Str);
 }
Index: clang/lib/AST/ExprConstant.cpp
===
--- clang/lib/AST/ExprConstant.cpp
+++ clang/lib/AST/ExprConstant.cpp
@@ -2027,6 +2027,9 @@
   case APValue::Int:
 Result = Val.getInt().getBoolValue();
 return true;
+  case APValue::FixedPoint:
+Result = Val.getFixedPoint().getBoolValue();
+return true;
   case APValue::Float:
 Result = !Val.getFloat().isZero();
 return true;
Index: clang/lib/AST/APValue.cpp
===
--- clang/lib/AST/APValue.cpp
+++ clang/lib/AST/APValue.cpp
@@ -176,6 +176,10 @@
 MakeFloat();
 setFloat(RHS.getFloat());
 break;
+  case FixedPoint:
+MakeFixedPoint();
+setFixedPoint(RHS.getFixedPoint());
+break;
   case Vector:
 MakeVector();
 setVector(((const Vec *)(const char *)RHS.Data.buffer)->Elts,
@@ -233,6 +237,8 @@
 

Re: r351269 - Re-order overrides in FunctionDecl dump

2019-01-15 Thread Aaron Ballman via cfe-commits
On Tue, Jan 15, 2019 at 5:54 PM Stephen Kelly via cfe-commits
 wrote:
>
> Author: steveire
> Date: Tue Jan 15 14:50:37 2019
> New Revision: 351269
>
> URL: http://llvm.org/viewvc/llvm-project?rev=351269=rev
> Log:
> Re-order overrides in FunctionDecl dump
>
> Output all content which is local to the FunctionDecl before traversing
> to child AST nodes.
>
> This is necessary so that all of the part which is local to the
> FunctionDecl can be split into a different method.
>
> Reviewers: aaron.ballman
>
> Differential Revision: https://reviews.llvm.org/D55083
>
> Modified:
> cfe/trunk/lib/AST/ASTDumper.cpp
> cfe/trunk/test/AST/ast-dump-funcs.cpp
>
> Modified: cfe/trunk/lib/AST/ASTDumper.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ASTDumper.cpp?rev=351269=351268=351269=diff
> ==
> --- cfe/trunk/lib/AST/ASTDumper.cpp (original)
> +++ cfe/trunk/lib/AST/ASTDumper.cpp Tue Jan 15 14:50:37 2019
> @@ -612,20 +612,6 @@ void ASTDumper::VisitFunctionDecl(const
>  }
>}
>
> -  if (const FunctionTemplateSpecializationInfo *FTSI =
> -  D->getTemplateSpecializationInfo())
> -dumpTemplateArgumentList(*FTSI->TemplateArguments);
> -
> -  if (!D->param_begin() && D->getNumParams())
> -dumpChild([=] { OS << ">"; 
> });
> -  else
> -for (const ParmVarDecl *Parameter : D->parameters())
> -  dumpDecl(Parameter);
> -
> -  if (const CXXConstructorDecl *C = dyn_cast(D))
> -for (const auto *I : C->inits())
> -  dumpCXXCtorInitializer(I);
> -
>if (const CXXMethodDecl *MD = dyn_cast(D)) {
>  if (MD->size_overridden_methods() != 0) {
>auto dumpOverride = [=](const CXXMethodDecl *D) {
> @@ -649,6 +635,22 @@ void ASTDumper::VisitFunctionDecl(const
>  }
>}
>
> +  if (const FunctionTemplateSpecializationInfo *FTSI =
> +  D->getTemplateSpecializationInfo())
> +dumpTemplateArgumentList(*FTSI->TemplateArguments);
> +
> +  if (!D->param_begin() && D->getNumParams())
> +dumpChild([=] { OS << ">"; 
> });
> +  else
> +for (const ParmVarDecl *Parameter : D->parameters())
> +  dumpDecl(Parameter);
> +
> +  if (const CXXConstructorDecl *C = dyn_cast(D))

Missed this nit from the review.

> +for (CXXConstructorDecl::init_const_iterator I = C->init_begin(),
> + E = C->init_end();
> + I != E; ++I)
> +  dumpCXXCtorInitializer(*I);

This accidentally reverts what you did in r351268.

~Aaron
> +
>if (D->doesThisDeclarationHaveABody())
>  dumpStmt(D->getBody());
>  }
>
> Modified: cfe/trunk/test/AST/ast-dump-funcs.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/AST/ast-dump-funcs.cpp?rev=351269=351268=351269=diff
> ==
> --- cfe/trunk/test/AST/ast-dump-funcs.cpp (original)
> +++ cfe/trunk/test/AST/ast-dump-funcs.cpp Tue Jan 15 14:50:37 2019
> @@ -56,10 +56,10 @@ struct S {
>  struct T : S { // T is not referenced, but S is
>void f(float, int = 100) override;
>// CHECK: CXXMethodDecl 0x{{[^ ]*}}  col:8 f 
> 'void (float, int)'
> +  // CHECK-NEXT: Overrides: [ 0x{{[^ ]*}} S::f 'void (float, int)' ]
>// CHECK-NEXT: ParmVarDecl 0x{{[^ ]*}}  col:15 'float'
>// CHECK-NEXT: ParmVarDecl 0x{{[^ ]*}}  col:21 'int' cinit
>// CHECK-NEXT: IntegerLiteral 0x{{[^ ]*}}  'int' 100
> -  // CHECK-NEXT: Overrides: [ 0x{{[^ ]*}} S::f 'void (float, int)' ]
>// CHECK-NEXT: OverrideAttr
>
>// CHECK: CXXConstructorDecl 0x{{[^ ]*}}  col:8 
> implicit T 'void (const T &)' inline default_delete noexcept-unevaluated
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D55083: Re-arrange content in FunctionDecl dump

2019-01-15 Thread Stephen Kelly via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rC351269: Re-order overrides in FunctionDecl dump (authored by 
steveire, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D55083?vs=181744=181892#toc

Repository:
  rC Clang

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

https://reviews.llvm.org/D55083

Files:
  lib/AST/ASTDumper.cpp
  test/AST/ast-dump-funcs.cpp


Index: lib/AST/ASTDumper.cpp
===
--- lib/AST/ASTDumper.cpp
+++ lib/AST/ASTDumper.cpp
@@ -612,20 +612,6 @@
 }
   }
 
-  if (const FunctionTemplateSpecializationInfo *FTSI =
-  D->getTemplateSpecializationInfo())
-dumpTemplateArgumentList(*FTSI->TemplateArguments);
-
-  if (!D->param_begin() && D->getNumParams())
-dumpChild([=] { OS << ">"; });
-  else
-for (const ParmVarDecl *Parameter : D->parameters())
-  dumpDecl(Parameter);
-
-  if (const CXXConstructorDecl *C = dyn_cast(D))
-for (const auto *I : C->inits())
-  dumpCXXCtorInitializer(I);
-
   if (const CXXMethodDecl *MD = dyn_cast(D)) {
 if (MD->size_overridden_methods() != 0) {
   auto dumpOverride = [=](const CXXMethodDecl *D) {
@@ -649,6 +635,22 @@
 }
   }
 
+  if (const FunctionTemplateSpecializationInfo *FTSI =
+  D->getTemplateSpecializationInfo())
+dumpTemplateArgumentList(*FTSI->TemplateArguments);
+
+  if (!D->param_begin() && D->getNumParams())
+dumpChild([=] { OS << ">"; });
+  else
+for (const ParmVarDecl *Parameter : D->parameters())
+  dumpDecl(Parameter);
+
+  if (const CXXConstructorDecl *C = dyn_cast(D))
+for (CXXConstructorDecl::init_const_iterator I = C->init_begin(),
+ E = C->init_end();
+ I != E; ++I)
+  dumpCXXCtorInitializer(*I);
+
   if (D->doesThisDeclarationHaveABody())
 dumpStmt(D->getBody());
 }
Index: test/AST/ast-dump-funcs.cpp
===
--- test/AST/ast-dump-funcs.cpp
+++ test/AST/ast-dump-funcs.cpp
@@ -56,10 +56,10 @@
 struct T : S { // T is not referenced, but S is
   void f(float, int = 100) override;
   // CHECK: CXXMethodDecl 0x{{[^ ]*}}  col:8 f 
'void (float, int)'
+  // CHECK-NEXT: Overrides: [ 0x{{[^ ]*}} S::f 'void (float, int)' ]
   // CHECK-NEXT: ParmVarDecl 0x{{[^ ]*}}  col:15 'float'
   // CHECK-NEXT: ParmVarDecl 0x{{[^ ]*}}  col:21 'int' cinit
   // CHECK-NEXT: IntegerLiteral 0x{{[^ ]*}}  'int' 100
-  // CHECK-NEXT: Overrides: [ 0x{{[^ ]*}} S::f 'void (float, int)' ]
   // CHECK-NEXT: OverrideAttr
 
   // CHECK: CXXConstructorDecl 0x{{[^ ]*}}  col:8 implicit 
T 'void (const T &)' inline default_delete noexcept-unevaluated


Index: lib/AST/ASTDumper.cpp
===
--- lib/AST/ASTDumper.cpp
+++ lib/AST/ASTDumper.cpp
@@ -612,20 +612,6 @@
 }
   }
 
-  if (const FunctionTemplateSpecializationInfo *FTSI =
-  D->getTemplateSpecializationInfo())
-dumpTemplateArgumentList(*FTSI->TemplateArguments);
-
-  if (!D->param_begin() && D->getNumParams())
-dumpChild([=] { OS << ">"; });
-  else
-for (const ParmVarDecl *Parameter : D->parameters())
-  dumpDecl(Parameter);
-
-  if (const CXXConstructorDecl *C = dyn_cast(D))
-for (const auto *I : C->inits())
-  dumpCXXCtorInitializer(I);
-
   if (const CXXMethodDecl *MD = dyn_cast(D)) {
 if (MD->size_overridden_methods() != 0) {
   auto dumpOverride = [=](const CXXMethodDecl *D) {
@@ -649,6 +635,22 @@
 }
   }
 
+  if (const FunctionTemplateSpecializationInfo *FTSI =
+  D->getTemplateSpecializationInfo())
+dumpTemplateArgumentList(*FTSI->TemplateArguments);
+
+  if (!D->param_begin() && D->getNumParams())
+dumpChild([=] { OS << ">"; });
+  else
+for (const ParmVarDecl *Parameter : D->parameters())
+  dumpDecl(Parameter);
+
+  if (const CXXConstructorDecl *C = dyn_cast(D))
+for (CXXConstructorDecl::init_const_iterator I = C->init_begin(),
+ E = C->init_end();
+ I != E; ++I)
+  dumpCXXCtorInitializer(*I);
+
   if (D->doesThisDeclarationHaveABody())
 dumpStmt(D->getBody());
 }
Index: test/AST/ast-dump-funcs.cpp
===
--- test/AST/ast-dump-funcs.cpp
+++ test/AST/ast-dump-funcs.cpp
@@ -56,10 +56,10 @@
 struct T : S { // T is not referenced, but S is
   void f(float, int = 100) override;
   // CHECK: CXXMethodDecl 0x{{[^ ]*}}  col:8 f 'void (float, int)'
+  // CHECK-NEXT: Overrides: [ 0x{{[^ ]*}} S::f 'void (float, int)' ]
   // CHECK-NEXT: ParmVarDecl 0x{{[^ ]*}}  col:15 'float'
   // CHECK-NEXT: ParmVarDecl 0x{{[^ ]*}}  col:21 'int' cinit
   // CHECK-NEXT: IntegerLiteral 0x{{[^ ]*}}  'int' 100
-  // CHECK-NEXT: Overrides: [ 0x{{[^ ]*}} S::f 'void 

r351269 - Re-order overrides in FunctionDecl dump

2019-01-15 Thread Stephen Kelly via cfe-commits
Author: steveire
Date: Tue Jan 15 14:50:37 2019
New Revision: 351269

URL: http://llvm.org/viewvc/llvm-project?rev=351269=rev
Log:
Re-order overrides in FunctionDecl dump

Output all content which is local to the FunctionDecl before traversing
to child AST nodes.

This is necessary so that all of the part which is local to the
FunctionDecl can be split into a different method.

Reviewers: aaron.ballman

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

Modified:
cfe/trunk/lib/AST/ASTDumper.cpp
cfe/trunk/test/AST/ast-dump-funcs.cpp

Modified: cfe/trunk/lib/AST/ASTDumper.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ASTDumper.cpp?rev=351269=351268=351269=diff
==
--- cfe/trunk/lib/AST/ASTDumper.cpp (original)
+++ cfe/trunk/lib/AST/ASTDumper.cpp Tue Jan 15 14:50:37 2019
@@ -612,20 +612,6 @@ void ASTDumper::VisitFunctionDecl(const
 }
   }
 
-  if (const FunctionTemplateSpecializationInfo *FTSI =
-  D->getTemplateSpecializationInfo())
-dumpTemplateArgumentList(*FTSI->TemplateArguments);
-
-  if (!D->param_begin() && D->getNumParams())
-dumpChild([=] { OS << ">"; });
-  else
-for (const ParmVarDecl *Parameter : D->parameters())
-  dumpDecl(Parameter);
-
-  if (const CXXConstructorDecl *C = dyn_cast(D))
-for (const auto *I : C->inits())
-  dumpCXXCtorInitializer(I);
-
   if (const CXXMethodDecl *MD = dyn_cast(D)) {
 if (MD->size_overridden_methods() != 0) {
   auto dumpOverride = [=](const CXXMethodDecl *D) {
@@ -649,6 +635,22 @@ void ASTDumper::VisitFunctionDecl(const
 }
   }
 
+  if (const FunctionTemplateSpecializationInfo *FTSI =
+  D->getTemplateSpecializationInfo())
+dumpTemplateArgumentList(*FTSI->TemplateArguments);
+
+  if (!D->param_begin() && D->getNumParams())
+dumpChild([=] { OS << ">"; });
+  else
+for (const ParmVarDecl *Parameter : D->parameters())
+  dumpDecl(Parameter);
+
+  if (const CXXConstructorDecl *C = dyn_cast(D))
+for (CXXConstructorDecl::init_const_iterator I = C->init_begin(),
+ E = C->init_end();
+ I != E; ++I)
+  dumpCXXCtorInitializer(*I);
+
   if (D->doesThisDeclarationHaveABody())
 dumpStmt(D->getBody());
 }

Modified: cfe/trunk/test/AST/ast-dump-funcs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/AST/ast-dump-funcs.cpp?rev=351269=351268=351269=diff
==
--- cfe/trunk/test/AST/ast-dump-funcs.cpp (original)
+++ cfe/trunk/test/AST/ast-dump-funcs.cpp Tue Jan 15 14:50:37 2019
@@ -56,10 +56,10 @@ struct S {
 struct T : S { // T is not referenced, but S is
   void f(float, int = 100) override;
   // CHECK: CXXMethodDecl 0x{{[^ ]*}}  col:8 f 
'void (float, int)'
+  // CHECK-NEXT: Overrides: [ 0x{{[^ ]*}} S::f 'void (float, int)' ]
   // CHECK-NEXT: ParmVarDecl 0x{{[^ ]*}}  col:15 'float'
   // CHECK-NEXT: ParmVarDecl 0x{{[^ ]*}}  col:21 'int' cinit
   // CHECK-NEXT: IntegerLiteral 0x{{[^ ]*}}  'int' 100
-  // CHECK-NEXT: Overrides: [ 0x{{[^ ]*}} S::f 'void (float, int)' ]
   // CHECK-NEXT: OverrideAttr
 
   // CHECK: CXXConstructorDecl 0x{{[^ ]*}}  col:8 implicit 
T 'void (const T &)' inline default_delete noexcept-unevaluated


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


[PATCH] D38430: Enable -pie and --enable-new-dtags by default on Android.

2019-01-15 Thread Peter Collingbourne via Phabricator via cfe-commits
pcc added inline comments.
Herald added a subscriber: llvm-commits.



Comment at: cfe/trunk/lib/Driver/ToolChains/Linux.cpp:814
+bool Linux::isPIEDefault() const {
+  return (getTriple().isAndroid() && !getTriple().isAndroidVersionLT(16)) ||
+ getSanitizerArgs().requiresPIE();

Why only on API level >= 16? If I create an executable targeting an older API 
level, it should still work on higher API levels.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D38430



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


r351268 - NFC: Replace iterator loop with cxx_range_for

2019-01-15 Thread Stephen Kelly via cfe-commits
Author: steveire
Date: Tue Jan 15 14:45:46 2019
New Revision: 351268

URL: http://llvm.org/viewvc/llvm-project?rev=351268=rev
Log:
NFC: Replace iterator loop with cxx_range_for

Modified:
cfe/trunk/lib/AST/ASTDumper.cpp

Modified: cfe/trunk/lib/AST/ASTDumper.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ASTDumper.cpp?rev=351268=351267=351268=diff
==
--- cfe/trunk/lib/AST/ASTDumper.cpp (original)
+++ cfe/trunk/lib/AST/ASTDumper.cpp Tue Jan 15 14:45:46 2019
@@ -623,10 +623,8 @@ void ASTDumper::VisitFunctionDecl(const
   dumpDecl(Parameter);
 
   if (const CXXConstructorDecl *C = dyn_cast(D))
-for (CXXConstructorDecl::init_const_iterator I = C->init_begin(),
- E = C->init_end();
- I != E; ++I)
-  dumpCXXCtorInitializer(*I);
+for (const auto *I : C->inits())
+  dumpCXXCtorInitializer(I);
 
   if (const CXXMethodDecl *MD = dyn_cast(D)) {
 if (MD->size_overridden_methods() != 0) {


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


Re: r351160 - [X86] Make _xgetbv/_xsetbv on non-windows platforms

2019-01-15 Thread Craig Topper via cfe-commits
any suggestions on how to proceed here?

~Craig


On Tue, Jan 15, 2019 at 10:56 AM Benjamin Kramer 
wrote:

> I think the main issue is that libstdc++ 4.9 includes x86intrin.h
> transitively from . That's probably broken with all compilers :(
>
> On Tue, Jan 15, 2019 at 7:31 PM Craig Topper 
> wrote:
>
>> Does V8 work with gcc which also has _xgetbv? Or is it because I had to
>> make _xgetbv a macro to make the patch work?
>>
>> ~Craig
>>
>>
>> On Tue, Jan 15, 2019 at 9:28 AM Benjamin Kramer via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> I rolled it back for now in r351210, this pattern seems to be quite
>>> common even outside of v8. Let's figure out if we can keep the code working
>>> or if it needs to be fixed all over the place :(
>>>
>>> On Tue, Jan 15, 2019 at 3:02 PM Benjamin Kramer 
>>> wrote:
>>>
 I'm seeing breakages on v8 with this, it defines its own _xgetbv. Any
 ideas what do do about this?


 https://chromium.googlesource.com/v8/v8.git/+/master/src/x64/assembler-x64.cc#36

 src/x64/assembler-x64.cc:35:1: error: inline variables are incompatible
 with C++ standards before C++17 [-Werror,-Wc++98-c++11-c++14-compat]
 V8_INLINE uint64_t _xgetbv(unsigned int xcr) {
 ^
 include/v8config.h:294:20: note: expanded from macro 'V8_INLINE'
 # define V8_INLINE inline __attribute__((always_inline))
^
 src/x64/assembler-x64.cc:35:41: error: expected ')'
 V8_INLINE uint64_t _xgetbv(unsigned int xcr) {
 ^
 src/x64/assembler-x64.cc:35:20: note: to match this '('
 V8_INLINE uint64_t _xgetbv(unsigned int xcr) {
^
 lib/clang/include/xsaveintrin.h:49:53: note: expanded from macro
 '_xgetbv'
 #define _xgetbv(A) __builtin_ia32_xgetbv((long long)(A))

 On Tue, Jan 15, 2019 at 6:06 AM Craig Topper via cfe-commits <
 cfe-commits@lists.llvm.org> wrote:

> Author: ctopper
> Date: Mon Jan 14 21:03:18 2019
> New Revision: 351160
>
> URL: http://llvm.org/viewvc/llvm-project?rev=351160=rev
> Log:
> [X86] Make _xgetbv/_xsetbv on non-windows platforms
>
> Summary:
> This patch attempts to redo what was tried in r278783, but was
> reverted.
>
> These intrinsics should be available on non-windows platforms with
> "xsave" feature check. But on Windows platforms they shouldn't have 
> feature
> check since that's how MSVC behaves.
>
> To accomplish this I've added a MS builtin with no feature check. And
> a normal gcc builtin with a feature check. When _MSC_VER is not defined
> _xgetbv/_xsetbv will be macros pointing to the gcc builtin name.
>
> I've moved the forward declarations from intrin.h to immintrin.h to
> match the MSDN documentation and used that as the header file for the MS
> builtin.
>
> I'm not super happy with this implementation, and I'm open to
> suggestions for better ways to do it.
>
> Reviewers: rnk, RKSimon, spatel
>
> Reviewed By: rnk
>
> Subscribers: cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D56686
>
> Modified:
> cfe/trunk/include/clang/Basic/BuiltinsX86.def
> cfe/trunk/lib/CodeGen/CGBuiltin.cpp
> cfe/trunk/lib/Headers/immintrin.h
> cfe/trunk/lib/Headers/intrin.h
> cfe/trunk/lib/Headers/xsaveintrin.h
> cfe/trunk/test/CodeGen/builtins-x86.c
> cfe/trunk/test/CodeGen/x86_32-xsave.c
> cfe/trunk/test/CodeGen/x86_64-xsave.c
> cfe/trunk/test/Headers/ms-intrin.cpp
>
> Modified: cfe/trunk/include/clang/Basic/BuiltinsX86.def
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsX86.def?rev=351160=351159=351160=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/BuiltinsX86.def (original)
> +++ cfe/trunk/include/clang/Basic/BuiltinsX86.def Mon Jan 14 21:03:18
> 2019
> @@ -693,6 +693,10 @@ TARGET_BUILTIN(__builtin_ia32_fxsave, "v
>  // XSAVE
>  TARGET_BUILTIN(__builtin_ia32_xsave, "vv*ULLi", "n", "xsave")
>  TARGET_BUILTIN(__builtin_ia32_xrstor, "vv*ULLi", "n", "xsave")
> +TARGET_BUILTIN(__builtin_ia32_xgetbv, "ULLiUi", "n", "xsave")
> +TARGET_HEADER_BUILTIN(_xgetbv, "UWiUi", "nh", "immintrin.h",
> ALL_MS_LANGUAGES, "")
> +TARGET_BUILTIN(__builtin_ia32_xsetbv, "vUiULLi", "n", "xsave")
> +TARGET_HEADER_BUILTIN(_xsetbv, "vUiUWi", "nh", "immintrin.h",
> ALL_MS_LANGUAGES, "")
>  TARGET_BUILTIN(__builtin_ia32_xsaveopt, "vv*ULLi", "n", "xsaveopt")
>  TARGET_BUILTIN(__builtin_ia32_xrstors, "vv*ULLi", "n", "xsaves")
>  TARGET_BUILTIN(__builtin_ia32_xsavec, "vv*ULLi", "n", "xsavec")
>
> Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
> URL:
> 

[PATCH] D56731: Add -Wimplicit-ctad warning to diagnose CTAD on types with no user defined deduction guides.

2019-01-15 Thread Arthur O'Dwyer via Phabricator via cfe-commits
Quuxplusone added inline comments.



Comment at: test/SemaCXX/cxx1z-class-template-argument-deduction.cpp:426
+// expected-warning@+1 {{class template argument deduction for 'NoExplicit' 
that has no user defined deduction guides}}
+NoExplicit ne(42);
+

EricWF wrote:
> Quuxplusone wrote:
> > I suggest that additional (more realistic) motivating examples can be found 
> > in STL's CppCon 2018 talk. E.g.
> > 
> > ```
> > template
> > struct Pair {
> > T first; U second;
> > explicit Pair(const T& t, const U& u) : first(t), second(u) {}
> > };
> > Pair p(42, "hello world");  // constructs a Pair
> > 
> > template
> > struct Pair2 {
> > T first; U second;
> > explicit Pair2(T t, U u) : first(t), second(u) {}
> > };
> > Pair2 p(42, "hello world");  // constructs a Pair2
> > ```
> > 
> > I would expect (and, with your patch, receive) diagnostics for both of 
> > these.
> > 
> > But for something like `Vector("a", "b")` your patch gives no diagnostic: 
> > https://godbolt.org/z/_9zhav
> > And for something like [`std::optional o(x);` in generic 
> > context](https://quuxplusone.github.io/blog/2018/12/11/dont-inherit-from-std-types/)
> >  your patch gives no diagnostic.
> > 
> > I do have a patch out for a general-purpose `-Wctad` that would give 
> > warnings on those latter cases as well: D54565
> > I think `-Wimplicit-ctad` is a good start, but it doesn't solve all the 
> > cases I'd like to see solved.
> I'll add the tests you described. And indeed, this solution is incomplete.
> 
> Can you expand on you `std::optional` example? I don't understand it.
> 
> Can you expand on you std::optional example? I don't understand it.

https://quuxplusone.github.io/blog/2018/12/09/wctad/
https://akrzemi1.wordpress.com/2018/12/09/deducing-your-intentions/

Essentially, CTAD tries to guess your intention, and it's easy for CTAD to 
guess wrong //in a generic context//.  The `vector v("a", "b")` example is 
about being in a concrete context and always guessing wrong; the more 
pernicious `auto o = optional(x)` example is about being in a generic context 
and //sometimes// guessing right and sometimes guessing wrong, depending on the 
type of `x` (and maybe not finding out until after you've shipped your 
header-only library).


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

https://reviews.llvm.org/D56731



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


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

2019-01-15 Thread Scott Linder via Phabricator via cfe-commits
scott.linder added a comment.

It sounds like `-fextern-visiblity=` isn't something we really want, then? I 
think it would have to be implemented in the abstract linkage computer.

Would a patch to add an option to apply the normal visibility calculations to 
extern decls be reasonable, then? This change could be done entirely in CodeGen.


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

https://reviews.llvm.org/D53153



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


[PATCH] D56563: [clang-tidy] add options documentation to readability-identifier-naming checker

2019-01-15 Thread Phabricator via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL351261: [clang-tidy] add options documentation to 
readability-identifier-naming checker (authored by paulhoad, committed by ).
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D56563?vs=181836=181884#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D56563

Files:
  
clang-tools-extra/trunk/docs/clang-tidy/checks/readability-identifier-naming.rst

Index: clang-tools-extra/trunk/docs/clang-tidy/checks/readability-identifier-naming.rst
===
--- clang-tools-extra/trunk/docs/clang-tidy/checks/readability-identifier-naming.rst
+++ clang-tools-extra/trunk/docs/clang-tidy/checks/readability-identifier-naming.rst
@@ -5,14 +5,1919 @@
 
 Checks for identifiers naming style mismatch.
 
-This check will try to enforce coding guidelines on the identifiers naming.
-It supports `lower_case`, `UPPER_CASE`, `camelBack` and `CamelCase` casing and
-tries to convert from one to another if a mismatch is detected.
+This check will try to enforce coding guidelines on the identifiers naming. It
+supports one of the following casing types and tries to convert from one to
+another if a mismatch is detected
 
-It also supports a fixed prefix and suffix that will be prepended or
-appended to the identifiers, regardless of the casing.
+Casing types inclde:
+
+ - ``lower_case``,
+ - ``UPPER_CASE``,
+ - ``camelBack``,
+ - ``CamelCase``,
+ - ``camel_Snake_Back``,
+ - ``Camel_Snake_Case``,
+ - ``aNy_CasE``.
+
+It also supports a fixed prefix and suffix that will be prepended or appended
+to the identifiers, regardless of the casing.
 
 Many configuration options are available, in order to be able to create
-different rules for different kind of identifier. In general, the
-rules are falling back to a more generic rule if the specific case is not
-configured.
+different rules for different kinds of identifiers. In general, the rules are
+falling back to a more generic rule if the specific case is not configured.
+
+Options
+---
+
+The following options are describe below:
+
+ - :option:`AbstractClassCase`, :option:`AbstractClassPrefix`, :option:`AbstractClassSuffix`
+ - :option:`ClassCase`, :option:`ClassPrefix`, :option:`ClassSuffix`
+ - :option:`ClassConstantCase`, :option:`ClassConstantPrefix`, :option:`ClassConstantSuffix`
+ - :option:`ClassMemberCase`, :option:`ClassMemberPrefix`, :option:`ClassMemberSuffix`
+ - :option:`ClassMethodCase`, :option:`ClassMethodPrefix`, :option:`ClassMethodSuffix`
+ - :option:`ConstantCase`, :option:`ConstantPrefix`, :option:`ConstantSuffix`
+ - :option:`ConstantMemberCase`, :option:`ConstantMemberPrefix`, :option:`ConstantMemberSuffix`
+ - :option:`ConstantParameterCase`, :option:`ConstantParameterPrefix`, :option:`ConstantParameterSuffix`
+ - :option:`ConstantPointerParameterCase`, :option:`ConstantPointerParameterPrefix`, :option:`ConstantPointerParameterSuffix`
+ - :option:`ConstexprFunctionCase`, :option:`ConstexprFunctionPrefix`, :option:`ConstexprFunctionSuffix`
+ - :option:`ConstexprMethodCase`, :option:`ConstexprMethodPrefix`, :option:`ConstexprMethodSuffix`
+ - :option:`ConstexprVariableCase`, :option:`ConstexprVariablePrefix`, :option:`ConstexprVariableSuffix`
+ - :option:`EnumCase`, :option:`EnumPrefix`, :option:`EnumSuffix`
+ - :option:`EnumConstantCase`, :option:`EnumConstantPrefix`, :option:`EnumConstantSuffix`
+ - :option:`FunctionCase`, :option:`FunctionPrefix`, :option:`FunctionSuffix`
+ - :option:`GlobalConstantCase`, :option:`GlobalConstantPrefix`, :option:`GlobalConstantSuffix`
+ - :option:`GlobalConstantPointerCase`, :option:`GlobalConstantPointerPrefix`, :option:`GlobalConstantPointerSuffix`
+ - :option:`GlobalFunctionCase`, :option:`GlobalFunctionPrefix`, :option:`GlobalFunctionSuffix`
+ - :option:`GlobalPointerCase`, :option:`GlobalPointerPrefix`, :option:`GlobalPointerSuffix`
+ - :option:`GlobalVariableCase`, :option:`GlobalVariablePrefix`, :option:`GlobalVariableSuffix`
+ - :option:`InlineNamespaceCase`, :option:`InlineNamespacePrefix`, :option:`InlineNamespaceSuffix`
+ - :option:`LocalConstantCase`, :option:`LocalConstantPrefix`, :option:`LocalConstantSuffix`
+ - :option:`LocalConstantPointerCase`, :option:`LocalConstantPointerPrefix`, :option:`LocalConstantPointerSuffix`
+ - :option:`LocalPointerCase`, :option:`LocalPointerPrefix`, :option:`LocalPointerSuffix`
+ - :option:`LocalVariableCase`, :option:`LocalVariablePrefix`, :option:`LocalVariableSuffix`
+ - :option:`MemberCase`, :option:`MemberPrefix`, :option:`MemberSuffix`
+ - :option:`MethodCase`, :option:`MethodPrefix`, :option:`MethodSuffix`
+ - :option:`NamespaceCase`, :option:`NamespacePrefix`, :option:`NamespaceSuffix`
+ - :option:`ParameterCase`, :option:`ParameterPrefix`, :option:`ParameterSuffix`
+ - :option:`ParameterPackCase`, 

[clang-tools-extra] r351261 - [clang-tidy] add options documentation to readability-identifier-naming checker

2019-01-15 Thread Paul Hoad via cfe-commits
Author: paulhoad
Date: Tue Jan 15 14:06:49 2019
New Revision: 351261

URL: http://llvm.org/viewvc/llvm-project?rev=351261=rev
Log:
[clang-tidy] add options documentation to readability-identifier-naming checker

Summary:
The documentation for this clang-checker did not explain what the options are. 
But this checkers only works with at least some options defined.

To discover the options, you have to read the source code. This shouldn't be 
necessary for users who just have access to the clang-tidy binary.

This revision, explains the options and gives an example.

Patch by MyDeveloperDay.

Reviewers: JonasToth, Eugene.Zelenko

Reviewed By: JonasToth

Subscribers: xazax.hun, Eugene.Zelenko

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

Modified:

clang-tools-extra/trunk/docs/clang-tidy/checks/readability-identifier-naming.rst

Modified: 
clang-tools-extra/trunk/docs/clang-tidy/checks/readability-identifier-naming.rst
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/docs/clang-tidy/checks/readability-identifier-naming.rst?rev=351261=351260=351261=diff
==
--- 
clang-tools-extra/trunk/docs/clang-tidy/checks/readability-identifier-naming.rst
 (original)
+++ 
clang-tools-extra/trunk/docs/clang-tidy/checks/readability-identifier-naming.rst
 Tue Jan 15 14:06:49 2019
@@ -5,14 +5,1919 @@ readability-identifier-naming
 
 Checks for identifiers naming style mismatch.
 
-This check will try to enforce coding guidelines on the identifiers naming.
-It supports `lower_case`, `UPPER_CASE`, `camelBack` and `CamelCase` casing and
-tries to convert from one to another if a mismatch is detected.
+This check will try to enforce coding guidelines on the identifiers naming. It
+supports one of the following casing types and tries to convert from one to
+another if a mismatch is detected
 
-It also supports a fixed prefix and suffix that will be prepended or
-appended to the identifiers, regardless of the casing.
+Casing types inclde:
+
+ - ``lower_case``,
+ - ``UPPER_CASE``,
+ - ``camelBack``,
+ - ``CamelCase``,
+ - ``camel_Snake_Back``,
+ - ``Camel_Snake_Case``,
+ - ``aNy_CasE``.
+
+It also supports a fixed prefix and suffix that will be prepended or appended
+to the identifiers, regardless of the casing.
 
 Many configuration options are available, in order to be able to create
-different rules for different kind of identifier. In general, the
-rules are falling back to a more generic rule if the specific case is not
-configured.
+different rules for different kinds of identifiers. In general, the rules are
+falling back to a more generic rule if the specific case is not configured.
+
+Options
+---
+
+The following options are describe below:
+
+ - :option:`AbstractClassCase`, :option:`AbstractClassPrefix`, 
:option:`AbstractClassSuffix`
+ - :option:`ClassCase`, :option:`ClassPrefix`, :option:`ClassSuffix`
+ - :option:`ClassConstantCase`, :option:`ClassConstantPrefix`, 
:option:`ClassConstantSuffix`
+ - :option:`ClassMemberCase`, :option:`ClassMemberPrefix`, 
:option:`ClassMemberSuffix`
+ - :option:`ClassMethodCase`, :option:`ClassMethodPrefix`, 
:option:`ClassMethodSuffix`
+ - :option:`ConstantCase`, :option:`ConstantPrefix`, :option:`ConstantSuffix`
+ - :option:`ConstantMemberCase`, :option:`ConstantMemberPrefix`, 
:option:`ConstantMemberSuffix`
+ - :option:`ConstantParameterCase`, :option:`ConstantParameterPrefix`, 
:option:`ConstantParameterSuffix`
+ - :option:`ConstantPointerParameterCase`, 
:option:`ConstantPointerParameterPrefix`, 
:option:`ConstantPointerParameterSuffix`
+ - :option:`ConstexprFunctionCase`, :option:`ConstexprFunctionPrefix`, 
:option:`ConstexprFunctionSuffix`
+ - :option:`ConstexprMethodCase`, :option:`ConstexprMethodPrefix`, 
:option:`ConstexprMethodSuffix`
+ - :option:`ConstexprVariableCase`, :option:`ConstexprVariablePrefix`, 
:option:`ConstexprVariableSuffix`
+ - :option:`EnumCase`, :option:`EnumPrefix`, :option:`EnumSuffix`
+ - :option:`EnumConstantCase`, :option:`EnumConstantPrefix`, 
:option:`EnumConstantSuffix`
+ - :option:`FunctionCase`, :option:`FunctionPrefix`, :option:`FunctionSuffix`
+ - :option:`GlobalConstantCase`, :option:`GlobalConstantPrefix`, 
:option:`GlobalConstantSuffix`
+ - :option:`GlobalConstantPointerCase`, :option:`GlobalConstantPointerPrefix`, 
:option:`GlobalConstantPointerSuffix`
+ - :option:`GlobalFunctionCase`, :option:`GlobalFunctionPrefix`, 
:option:`GlobalFunctionSuffix`
+ - :option:`GlobalPointerCase`, :option:`GlobalPointerPrefix`, 
:option:`GlobalPointerSuffix`
+ - :option:`GlobalVariableCase`, :option:`GlobalVariablePrefix`, 
:option:`GlobalVariableSuffix`
+ - :option:`InlineNamespaceCase`, :option:`InlineNamespacePrefix`, 
:option:`InlineNamespaceSuffix`
+ - :option:`LocalConstantCase`, :option:`LocalConstantPrefix`, 
:option:`LocalConstantSuffix`
+ - :option:`LocalConstantPointerCase`, :option:`LocalConstantPointerPrefix`, 

[PATCH] D40854: [clang-tidy] WIP implement cppcoreguidelines check for mixed integer arithmetic

2019-01-15 Thread Jonas Toth via Phabricator via cfe-commits
JonasToth updated this revision to Diff 181877.
JonasToth added a comment.

- Merge branch 'master' into check_mixed_arithmetic, a lot has happened...


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D40854

Files:
  clang-tidy/cppcoreguidelines/CMakeLists.txt
  clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
  clang-tidy/cppcoreguidelines/MixedIntArithmeticCheck.cpp
  clang-tidy/cppcoreguidelines/MixedIntArithmeticCheck.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/cppcoreguidelines-mixed-int-arithmetic.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/cppcoreguidelines-mixed-int-arithmetic.cpp

Index: test/clang-tidy/cppcoreguidelines-mixed-int-arithmetic.cpp
===
--- /dev/null
+++ test/clang-tidy/cppcoreguidelines-mixed-int-arithmetic.cpp
@@ -0,0 +1,188 @@
+// RUN: %check_clang_tidy %s cppcoreguidelines-mixed-int-arithmetic %t
+
+enum UnsignedEnum : unsigned char {
+  UEnum1,
+  UEnum2
+};
+
+enum SignedEnum : signed char {
+  SEnum1,
+  SEnum2
+};
+
+unsigned char returnUnsignedCharacter() { return 42; }
+unsigned returnUnsignedNumber() { return 42u; }
+long returnBigNumber() { return 42; }
+float unrelatedThing() { return 42.f; }
+SignedEnum returnSignedEnum() { return SEnum1; }
+UnsignedEnum returnUnsignedEnum() { return UEnum1; }
+
+void mixed_binary() {
+  unsigned int UInt1 = 42;
+  signed int SInt1 = 42;
+  UnsignedEnum UE1 = UEnum1;
+  SignedEnum SE1 = SEnum1;
+  float UnrelatedFloat = 42.f;
+
+  // Test traditional integer types.
+  auto R1 = UInt1 + SInt1;
+  // CHECK-MESSAGES: [[@LINE-1]]:13: warning: mixed signed and unsigned arithmetic; prefer signed integers and use unsigned types only for modulo arithmetic
+  // CHECK-MESSAGES: [[@LINE-2]]:21: note: signed operand
+  // CHECK-MESSAGES: [[@LINE-3]]:13: note: unsigned operand
+
+  int R2 = UInt1 - SInt1;
+  // CHECK-MESSAGES: [[@LINE-1]]:12: warning: mixed signed and unsigned arithmetic; prefer signed integers and use unsigned types only for modulo arithmetic
+  // CHECK-MESSAGES: [[@LINE-2]]:20: note: signed operand
+  // CHECK-MESSAGES: [[@LINE-3]]:12: note: unsigned operand
+
+  unsigned int R3 = UInt1 * SInt1;
+  // CHECK-MESSAGES: [[@LINE-1]]:21: warning: mixed signed and unsigned arithmetic; prefer signed integers and use unsigned types only for modulo arithmetic
+  // CHECK-MESSAGES: [[@LINE-2]]:29: note: signed operand
+  // CHECK-MESSAGES: [[@LINE-3]]:21: note: unsigned operand
+
+  unsigned int R4 = UInt1 / returnBigNumber();
+  // CHECK-MESSAGES: [[@LINE-1]]:21: warning: mixed signed and unsigned arithmetic; prefer signed integers and use unsigned types only for modulo arithmetic
+  // CHECK-MESSAGES: [[@LINE-2]]:29: note: signed operand
+  // CHECK-MESSAGES: [[@LINE-3]]:21: note: unsigned operand
+
+  char R5 = returnUnsignedCharacter() + SInt1;
+  // CHECK-MESSAGES: [[@LINE-1]]:13: warning: mixed signed and unsigned arithmetic; prefer signed integers and use unsigned types only for modulo arithmetic
+  // CHECK-MESSAGES: [[@LINE-2]]:41: note: signed operand
+  // CHECK-MESSAGES: [[@LINE-3]]:13: note: unsigned operand
+
+  auto R6 = SInt1 - 10u;
+  // CHECK-MESSAGES: [[@LINE-1]]:13: warning: mixed signed and unsigned arithmetic; prefer signed integers and use unsigned types only for modulo arithmetic
+  // CHECK-MESSAGES: [[@LINE-2]]:13: note: signed operand
+  // CHECK-MESSAGES: [[@LINE-3]]:21: note: unsigned operand
+
+  auto R7 = UInt1 * 10;
+  // CHECK-MESSAGES: [[@LINE-1]]:13: warning: mixed signed and unsigned arithmetic; prefer signed integers and use unsigned types only for modulo arithmetic
+  // CHECK-MESSAGES: [[@LINE-2]]:21: note: signed operand
+  // CHECK-MESSAGES: [[@LINE-3]]:13: note: unsigned operand
+
+  auto R8 = 10u / returnBigNumber();
+  // CHECK-MESSAGES: [[@LINE-1]]:13: warning: mixed signed and unsigned arithmetic; prefer signed integers and use unsigned types only for modulo arithmetic
+  // CHECK-MESSAGES: [[@LINE-2]]:19: note: signed operand
+  // CHECK-MESSAGES: [[@LINE-3]]:13: note: unsigned operand
+
+  auto R9 = 10 + returnUnsignedCharacter();
+  // CHECK-MESSAGES: [[@LINE-1]]:13: warning: mixed signed and unsigned arithmetic; prefer signed integers and use unsigned types only for modulo arithmetic
+  // CHECK-MESSAGES: [[@LINE-2]]:13: note: signed operand
+  // CHECK-MESSAGES: [[@LINE-3]]:18: note: unsigned operand
+
+  // Test enum types.
+  char R10 = returnUnsignedEnum() - SInt1;
+  // CHECK-MESSAGES: [[@LINE-1]]:14: warning: mixed signed and unsigned arithmetic; prefer signed integers and use unsigned types only for modulo arithmetic
+  // CHECK-MESSAGES: [[@LINE-2]]:37: note: signed operand
+  // CHECK-MESSAGES: [[@LINE-3]]:14: note: unsigned operand
+
+  unsigned char R11 = returnSignedEnum() * UInt1;
+  // CHECK-MESSAGES: [[@LINE-1]]:23: warning: mixed signed and unsigned arithmetic; prefer signed integers and use unsigned 

[PATCH] D56658: [MSP430] Add msp430 toochain

2019-01-15 Thread Anton Korobeynikov via Phabricator via cfe-commits
asl added inline comments.



Comment at: cfe/trunk/lib/CodeGen/CodeGenModule.cpp:141
+  (!CodeGenOpts.RelaxedAliasing && CodeGenOpts.OptimizationLevel > 0)) {
+fprintf(stderr, "TBAA enabled\n");
 TBAA.reset(new CodeGenTBAA(Context, TheModule, CodeGenOpts, getLangOpts(),

nathanchance wrote:
> asl wrote:
> > nathanchance wrote:
> > > I'm just curious, was committing this change intentional? Seems like 
> > > something for debugging purposes, rather than a useful diagnostic, since 
> > > it doesn't appear to be related to the rest of the patch (as far as I can 
> > > tell).
> > > 
> > > I see it quite a bit on a Linux kernel build: 
> > > https://gist.github.com/nathanchance/0b2d3b16d5b30396038d86f5cba3
> > Oh... Sorry, maybe unclean tree or something like this. Will fix!
> Thanks for the quick reply, looks like Peter Collingbourne beat you to it :) 
> https://reviews.llvm.org/rC351241
Pete already fixed this in r351241.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D56658



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


[PATCH] D56658: [MSP430] Add msp430 toochain

2019-01-15 Thread Nathan Chancellor via Phabricator via cfe-commits
nathanchance marked an inline comment as done.
nathanchance added inline comments.



Comment at: cfe/trunk/lib/CodeGen/CodeGenModule.cpp:141
+  (!CodeGenOpts.RelaxedAliasing && CodeGenOpts.OptimizationLevel > 0)) {
+fprintf(stderr, "TBAA enabled\n");
 TBAA.reset(new CodeGenTBAA(Context, TheModule, CodeGenOpts, getLangOpts(),

asl wrote:
> nathanchance wrote:
> > I'm just curious, was committing this change intentional? Seems like 
> > something for debugging purposes, rather than a useful diagnostic, since it 
> > doesn't appear to be related to the rest of the patch (as far as I can 
> > tell).
> > 
> > I see it quite a bit on a Linux kernel build: 
> > https://gist.github.com/nathanchance/0b2d3b16d5b30396038d86f5cba3
> Oh... Sorry, maybe unclean tree or something like this. Will fix!
Thanks for the quick reply, looks like Peter Collingbourne beat you to it :) 
https://reviews.llvm.org/rC351241


Repository:
  rL LLVM

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

https://reviews.llvm.org/D56658



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


Re: r351241 - CodeGen: Remove debug printf unintentionally added in r351228.

2019-01-15 Thread Anton Korobeynikov via cfe-commits
Thanks!

On Wed, Jan 16, 2019 at 12:03 AM Peter Collingbourne via cfe-commits
 wrote:
>
> Author: pcc
> Date: Tue Jan 15 12:59:59 2019
> New Revision: 351241
>
> URL: http://llvm.org/viewvc/llvm-project?rev=351241=rev
> Log:
> CodeGen: Remove debug printf unintentionally added in r351228.
>
> Modified:
> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=351241=351240=351241=diff
> ==
> --- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Tue Jan 15 12:59:59 2019
> @@ -137,12 +137,10 @@ CodeGenModule::CodeGenModule(ASTContext
>
>// Enable TBAA unless it's suppressed. ThreadSanitizer needs TBAA even at 
> O0.
>if (LangOpts.Sanitize.has(SanitizerKind::Thread) ||
> -  (!CodeGenOpts.RelaxedAliasing && CodeGenOpts.OptimizationLevel > 0)) {
> -fprintf(stderr, "TBAA enabled\n");
> +  (!CodeGenOpts.RelaxedAliasing && CodeGenOpts.OptimizationLevel > 0))
>  TBAA.reset(new CodeGenTBAA(Context, TheModule, CodeGenOpts, 
> getLangOpts(),
> getCXXABI().getMangleContext()));
> -  }
> -
> +
>// If debug info or coverage generation is enabled, create the CGDebugInfo
>// object.
>if (CodeGenOpts.getDebugInfo() != codegenoptions::NoDebugInfo ||
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits



-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r351249 - [clang-cl] Alias /Zc:alignedNew[-] to -f[no-]aligned-allocation

2019-01-15 Thread Reid Kleckner via cfe-commits
Author: rnk
Date: Tue Jan 15 13:24:55 2019
New Revision: 351249

URL: http://llvm.org/viewvc/llvm-project?rev=351249=rev
Log:
[clang-cl] Alias /Zc:alignedNew[-] to -f[no-]aligned-allocation

Implements PR40180.

clang-cl has one minor behavior difference with cl with this change.
Clang allows the user to enable the C++17 feature of aligned allocation
without enabling all of C++17, but MSVC will not call the aligned
allocation overloads unless -std:c++17 is passed. While our behavior is
technically incompatible, it would require making driver mode specific
changes to match MSVC precisely, and clang's behavior is useful because
it allows people to experiment with new C++17 features individually.
Therefore, I plan to leave it as is.

Modified:
cfe/trunk/include/clang/Driver/CLCompatOptions.td
cfe/trunk/test/Driver/cl-zc.cpp

Modified: cfe/trunk/include/clang/Driver/CLCompatOptions.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CLCompatOptions.td?rev=351249=351248=351249=diff
==
--- cfe/trunk/include/clang/Driver/CLCompatOptions.td (original)
+++ cfe/trunk/include/clang/Driver/CLCompatOptions.td Tue Jan 15 13:24:55 2019
@@ -207,6 +207,12 @@ def _SLASH_Zc_sizedDealloc : CLFlag<"Zc:
 def _SLASH_Zc_sizedDealloc_ : CLFlag<"Zc:sizedDealloc-">,
   HelpText<"Disable C++14 sized global deallocation functions">,
   Alias;
+def _SLASH_Zc_alignedNew : CLFlag<"Zc:alignedNew">,
+  HelpText<"Enable C++17 aligned allocation functions">,
+  Alias;
+def _SLASH_Zc_alignedNew_ : CLFlag<"Zc:alignedNew-">,
+  HelpText<"Disable C++17 aligned allocation functions">,
+  Alias;
 def _SLASH_Zc_strictStrings : CLFlag<"Zc:strictStrings">,
   HelpText<"Treat string literals as const">, Alias,
   AliasArgs<["error=c++11-compat-deprecated-writable-strings"]>;

Modified: cfe/trunk/test/Driver/cl-zc.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/cl-zc.cpp?rev=351249=351248=351249=diff
==
--- cfe/trunk/test/Driver/cl-zc.cpp (original)
+++ cfe/trunk/test/Driver/cl-zc.cpp Tue Jan 15 13:24:55 2019
@@ -18,6 +18,12 @@
 // RUN: %clang_cl /c -### /Zc:sizedDealloc- -- %s 2>&1 | FileCheck 
-check-prefix=SIZED-DEALLOC-OFF %s
 // SIZED-DEALLOC-OFF-NOT: "-fsized-deallocation"
 
+// RUN: %clang_cl /c /std:c++17 -### /Zc:alignedNew -- %s 2>&1 | FileCheck 
-check-prefix=ALIGNED-NEW-ON %s
+// ALIGNED-NEW-ON: "-faligned-allocation"
+
+// RUN: %clang_cl /c /std:c++17 -### /Zc:alignedNew- -- %s 2>&1 | FileCheck 
-check-prefix=ALIGNED-NEW-OFF %s
+// ALIGNED-NEW-OFF-NOT: "-faligned-allocation"
+
 // RUN: %clang_cl /c -### -- %s 2>&1 | FileCheck 
-check-prefix=STRICTSTRINGS-DEFAULT %s
 // STRICTSTRINGS-DEFAULT-NOT: -Werror=c++11-compat-deprecated-writable-strings
 // RUN: %clang_cl /c -### /Zc:strictStrings -- %s 2>&1 | FileCheck 
-check-prefix=STRICTSTRINGS-ON %s


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


[PATCH] D56658: [MSP430] Add msp430 toochain

2019-01-15 Thread Anton Korobeynikov via Phabricator via cfe-commits
asl added inline comments.



Comment at: cfe/trunk/lib/CodeGen/CodeGenModule.cpp:141
+  (!CodeGenOpts.RelaxedAliasing && CodeGenOpts.OptimizationLevel > 0)) {
+fprintf(stderr, "TBAA enabled\n");
 TBAA.reset(new CodeGenTBAA(Context, TheModule, CodeGenOpts, getLangOpts(),

nathanchance wrote:
> I'm just curious, was committing this change intentional? Seems like 
> something for debugging purposes, rather than a useful diagnostic, since it 
> doesn't appear to be related to the rest of the patch (as far as I can tell).
> 
> I see it quite a bit on a Linux kernel build: 
> https://gist.github.com/nathanchance/0b2d3b16d5b30396038d86f5cba3
Oh... Sorry, maybe unclean tree or something like this. Will fix!


Repository:
  rL LLVM

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

https://reviews.llvm.org/D56658



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


[PATCH] D56663: [MSP430] Improve support of 'interrupt' attribute

2019-01-15 Thread Kristina Bessonova via Phabricator via cfe-commits
krisb updated this revision to Diff 181866.
krisb added a comment.

Addressed feedback.


Repository:
  rC Clang

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

https://reviews.llvm.org/D56663

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/CodeGen/TargetInfo.cpp
  lib/Sema/SemaDeclAttr.cpp
  test/CodeGen/attr-msp430.c
  test/Sema/attr-msp430.c

Index: test/Sema/attr-msp430.c
===
--- test/Sema/attr-msp430.c
+++ test/Sema/attr-msp430.c
@@ -1,6 +1,13 @@
 // RUN: %clang_cc1 -triple msp430-unknown-unknown -fsyntax-only -verify %s
 
+__attribute__((interrupt(1))) int t; // expected-warning {{'interrupt' attribute only applies to functions}}
+
 int i;
-void f(void) __attribute__((interrupt(i))); /* expected-error {{'interrupt' attribute requires an integer constant}} */
+__attribute__((interrupt(i))) void f(void); // expected-error {{'interrupt' attribute requires an integer constant}}
+__attribute__((interrupt(1, 2))) void f2(void); // expected-error {{'interrupt' attribute takes one argument}}
+__attribute__((interrupt(1))) int f3(void); // expected-warning {{MSP430 'interrupt' attribute only applies to functions that have a 'void' return type}}
+__attribute__((interrupt(1))) void f4(int a); // expected-warning {{MSP430 'interrupt' attribute only applies to functions that have no parameters}}
+__attribute__((interrupt(64))) void f5(void); // expected-error {{'interrupt' attribute parameter 64 is out of bounds}}
 
-void f2(void) __attribute__((interrupt(12)));
+__attribute__((interrupt(0))) void f6(void);
+__attribute__((interrupt(63))) void f7(void);
Index: test/CodeGen/attr-msp430.c
===
--- /dev/null
+++ test/CodeGen/attr-msp430.c
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -triple msp430-unknown-unknown -emit-llvm < %s| FileCheck %s
+
+__attribute__((interrupt(1))) void foo(void) {}
+// CHECK: @llvm.used
+// CHECK-SAME: @foo
+
+// CHECK: define msp430_intrcc void @foo() #0
+// CHECK: attributes #0
+// CHECK-SAME: noinline
+// CHECK-SAME: "interrupt"="1"
Index: lib/Sema/SemaDeclAttr.cpp
===
--- lib/Sema/SemaDeclAttr.cpp
+++ lib/Sema/SemaDeclAttr.cpp
@@ -5377,6 +5377,27 @@
 }
 
 static void handleMSP430InterruptAttr(Sema , Decl *D, const ParsedAttr ) {
+  // MSP430 'interrupt' attribute is applied to
+  // a function with no parameters and void return type.
+  if (!isFunctionOrMethod(D)) {
+S.Diag(D->getLocation(), diag::warn_attribute_wrong_decl_type)
+<< "'interrupt'" << ExpectedFunctionOrMethod;
+return;
+  }
+
+  if (hasFunctionProto(D) && getFunctionOrMethodNumParams(D) != 0) {
+S.Diag(D->getLocation(), diag::warn_msp430_interrupt_attribute)
+<< 0;
+return;
+  }
+
+  if (!getFunctionOrMethodResultType(D)->isVoidType()) {
+S.Diag(D->getLocation(), diag::warn_msp430_interrupt_attribute)
+<< 1;
+return;
+  }
+
+  // The attribute takes one integer argument.
   if (!checkAttributeNumArgs(S, AL, 1))
 return;
 
@@ -5386,8 +5407,6 @@
 return;
   }
 
-  // FIXME: Check for decl - it should be void ()(void).
-
   Expr *NumParamsExpr = static_cast(AL.getArgAsExpr(0));
   llvm::APSInt NumParams(32);
   if (!NumParamsExpr->isIntegerConstantExpr(NumParams, S.Context)) {
@@ -5396,9 +5415,9 @@
 << NumParamsExpr->getSourceRange();
 return;
   }
-
+  // The argument should be in range 0..63.
   unsigned Num = NumParams.getLimitedValue(255);
-  if ((Num & 1) || Num > 30) {
+  if (Num > 63) {
 S.Diag(AL.getLoc(), diag::err_attribute_argument_out_of_bounds)
 << AL << (int)NumParams.getSExtValue()
 << NumParamsExpr->getSourceRange();
Index: lib/CodeGen/TargetInfo.cpp
===
--- lib/CodeGen/TargetInfo.cpp
+++ lib/CodeGen/TargetInfo.cpp
@@ -6774,21 +6774,19 @@
   if (GV->isDeclaration())
 return;
   if (const FunctionDecl *FD = dyn_cast_or_null(D)) {
-if (const MSP430InterruptAttr *attr = FD->getAttr()) {
-  // Handle 'interrupt' attribute:
-  llvm::Function *F = cast(GV);
+const auto *InterruptAttr = FD->getAttr();
+if (!InterruptAttr)
+  return;
 
-  // Step 1: Set ISR calling convention.
-  F->setCallingConv(llvm::CallingConv::MSP430_INTR);
+// Handle 'interrupt' attribute:
+llvm::Function *F = cast(GV);
 
-  // Step 2: Add attributes goodness.
-  F->addFnAttr(llvm::Attribute::NoInline);
+// Step 1: Set ISR calling convention.
+F->setCallingConv(llvm::CallingConv::MSP430_INTR);
 
-  // Step 3: Emit ISR vector alias.
-  unsigned Num = attr->getNumber() / 2;
-  llvm::GlobalAlias::create(llvm::Function::ExternalLinkage,
-"__isr_" + Twine(Num), F);
-}
+// Step 2: Add attributes goodness.
+F->addFnAttr(llvm::Attribute::NoInline);
+

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

2019-01-15 Thread Jennifer Yu via Phabricator via cfe-commits
jyu2 marked 2 inline comments as done.
jyu2 added inline comments.



Comment at: lib/Sema/SemaStmtAsm.cpp:470
+if (NS->isGCCAsmGoto() &&
+Exprs[ConstraintIdx]->getStmtClass() == Stmt::AddrLabelExprClass)
+  break;

efriedma wrote:
> jyu2 wrote:
> > efriedma wrote:
> > > jyu2 wrote:
> > > > efriedma wrote:
> > > > > jyu2 wrote:
> > > > > > jyu2 wrote:
> > > > > > > efriedma wrote:
> > > > > > > > jyu2 wrote:
> > > > > > > > > efriedma wrote:
> > > > > > > > > > jyu2 wrote:
> > > > > > > > > > > efriedma wrote:
> > > > > > > > > > > > This looks suspicious; an AddrLabelExpr could be an 
> > > > > > > > > > > > input or output, e.g. `"r"(&)`.
> > > > > > > > > > > Syntax for asm goto:
> > > > > > > > > > >  Syntax:
> > > > > > > > > > >asm [volatile] goto ( AssemblerTemplate
> > > > > > > > > > >:
> > > > > > > > > > >: InputOperands
> > > > > > > > > > >: Clobbers
> > > > > > > > > > >: GotoLabels)
> > > > > > > > > > > 
> > > > > > > > > > >  Only input is allowed.  Output is not allowed
> > > > > > > > > > > 
> > > > > > > > > > That doesn't really address my point here... ignore the "or 
> > > > > > > > > > output" part of the comment.
> > > > > > > > > Sorry did not realize that.  Thank you so much for catching 
> > > > > > > > > that.  Need to add other condition "ConstraintIdx > 
> > > > > > > > > NS->getNumInputs() - 1", change to :
> > > > > > > > > 
> > > > > > > > > if (NS->isGCCAsmGoto() && ConstraintIdx > NS->getNumInputs() 
> > > > > > > > > - 1 &&
> > > > > > > > > Exprs[ConstraintIdx]->getStmtClass() == 
> > > > > > > > > Stmt::AddrLabelExprClass)
> > > > > > > > >   break;
> > > > > > > > > 
> > > > > > > > > Is this ok with you?  Thanks
> > > > > > > > That's the right idea. But I still see a few issues at that 
> > > > > > > > point:
> > > > > > > > 
> > > > > > > > 1. The AddrLabelExprClass check is redundant.
> > > > > > > > 2. "NS->getNumInputs() - 1" can overflow; probably should use 
> > > > > > > > "ConstraintIdx >= NS->getNumInputs()".
> > > > > > > > 3. "break" exits the loop completely (so it skips validating 
> > > > > > > > all constraints written after the label).
> > > > > > > > 4. The code needs to verify that the user correctly specified 
> > > > > > > > the "l" constraint modifier.
> > > > > > > Sorry not done yet.  
> > > > > > For you comment 4:
> > > > > > 
> > > > > > The code needs to verify that the user correctly specified the "l" 
> > > > > > constraint modifier.  We already emit error like following?
> > > > > > 
> > > > > > Do you mean, we need more checking here?  Thanks. 
> > > > > > 
> > > > > > n.c:4:35: error: unknown symbolic operand name in inline assembly 
> > > > > > string
> > > > > >   asm goto ("frob %%r5, %1; jc %l[error]; mov (%2), %%r5"
> > > > > > ~~^~~
> > > > > > n.c:8:15: error: use of undeclared label 'error1'
> > > > > > : error1);
> > > > > > 
> > > > > > Test is:
> > > > > > int frob(int x)
> > > > > > {
> > > > > >   int y;
> > > > > >   asm goto ("frob %%r5, %1; jc %l[error]; mov (%2), %%r5"
> > > > > > : /* No outputs. */
> > > > > > : "r"(x), "r"()
> > > > > > : "memory"
> > > > > > : error1);
> > > > > >   return y;
> > > > > > error:
> > > > > >   return -1;
> > > > > > }
> > > > > > 
> > > > > > 
> > > > > I mean, there needs to be a diagnostic for the following:
> > > > > 
> > > > > ```
> > > > > asm goto ("jne %h0"x);
> > > > > ```
> > > > > 
> > > > > On a related note, there should also be a diagnostic for the 
> > > > > following somewhere:
> > > > > 
> > > > > ```
> > > > > asm ("jne %l0"::"r"(0));
> > > > > ```
> > > > Hi Eli,
> > > > 
> > > > Thanks for your review.
> > > > 
> > > > For case:
> > > > asm goto ("jne %h0"x);
> > > > 
> > > > Without define label x, both clang and my current implementation give 
> > > > error of "use of undeclared label"
> > > > 
> > > > if x is defined: gcc give error 
> > > > asm_goto>!gcc
> > > > gcc n.c
> > > > n.c: Assembler messages:
> > > > n.c:4: Error: operand type mismatch for `jne'
> > > > 
> > > > My current implementation don't emit error.  I think this is need to be 
> > > > done in LLVM.  Am I right here?
> > > > 
> > > > For the case:
> > > > asm ("jne %l0"::"r"(0));
> > > > 
> > > > gcc don't allow any modifier 'l' with  asm stmt but it allows with asm 
> > > > goto.  Is that something you are look for?  Thanks.
> > > > 
> > > > So I add code in AST/Stmt.cpp to emit error.
> > > > .
> > > >  return diag::err_asm_invalid_escape;
> > > >   } else if (!this->isGCCAsmGoto() && EscapedChar == 'l' &&
> > > >  isDigit(*CurPtr)) {
> > > > DiagOffs = CurPtr-StrStart;
> > > > return diag::err_asm_invalid_operand_number;
> > > >   }
> > > > 
> > > For the first 

[PATCH] D55447: [Sema] Fix Modified Type in address_space AttributedType

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



Comment at: clang/tools/libclang/CXType.cpp:132
+  if (!(TU->ParsingOptions & CXTranslationUnit_IncludeAttributedTypes) &&
+  ATT->getAttrKind() != attr::AddressSpace) {
 return MakeCXType(ATT->getModifiedType(), TU);

leonardchan wrote:
> leonardchan wrote:
> > aaron.ballman wrote:
> > > leonardchan wrote:
> > > > aaron.ballman wrote:
> > > > > leonardchan wrote:
> > > > > > aaron.ballman wrote:
> > > > > > > leonardchan wrote:
> > > > > > > > aaron.ballman wrote:
> > > > > > > > > leonardchan wrote:
> > > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > > This change seems surprising -- if the parsing options 
> > > > > > > > > > > say the caller does not want attributed types, why are we 
> > > > > > > > > > > returning one anyway for address space?
> > > > > > > > > > This has to do with ensuring `clang_getAddressSpace` still 
> > > > > > > > > > returns the proper address_space. It does this by 
> > > > > > > > > > essentially checking the qualifiers of the type, which we 
> > > > > > > > > > now attach to the `AttributedType` whereas before it was 
> > > > > > > > > > attached to the modified type.
> > > > > > > > > > 
> > > > > > > > > > This extra condition is necessary for ensuring that calling 
> > > > > > > > > > `clang_getAddressSpace` points to the qualified 
> > > > > > > > > > AttributedType instead of the unqualified modified type.
> > > > > > > > > My fear is that this will be breaking assumptions in 
> > > > > > > > > third-party code. If someone disables 
> > > > > > > > > `CXTranslationUnit_IncludeAttributedTypes`, they are unlikely 
> > > > > > > > > to expect to receive an `AttributedType` and may react poorly 
> > > > > > > > > to it.
> > > > > > > > Instead check if the type is address_space attributed and apply 
> > > > > > > > the qualifiers the modified type.
> > > > > > > Sure, they can always modify their code to handle it gracefully, 
> > > > > > > but it's a silent, breaking change to a somewhat stable API which 
> > > > > > > is why I was prodding about it.
> > > > > > > 
> > > > > > > After talking with @rsmith, we're thinking the correct change 
> > > > > > > here is to return the attributed type when the user asks for it, 
> > > > > > > but return the equivalent type rather than the modified type if 
> > > > > > > the user doesn't want attribute sugar (for all attributes, not 
> > > > > > > just address spaces). This way, when a user asks for CXType for 
> > > > > > > one of these, they always get a correct type but sometimes it has 
> > > > > > > attribute type sugar and sometimes it doesn't, depending on the 
> > > > > > > parsing options.
> > > > > > > 
> > > > > > > This is still a silent, breaking change in behavior, which is 
> > > > > > > unfortunate. It should probably come with a mention in the 
> > > > > > > release notes about the change to the API and some unit tests as 
> > > > > > > well.
> > > > > > Ok. In the case of qualifiers then, should the equivalent type 
> > > > > > still contain the address_space qualifiers when creating the 
> > > > > > AttributedType?
> > > > > I believe so, yes -- that would ensure it's the minimally desugared 
> > > > > type which the type is canonically equivalent to.
> > > > Sorry for the holdup. So for an AddressSpace AttributedType, we attach 
> > > > the qualifiers only to the equivalent type.
> > > > 
> > > > As for this though, the only problem I ran into with returning the 
> > > > equivalent type is for AttributedTypes with `attr::ObjCKindOf`, a test 
> > > > expects returning the modified type which is an `ObjCInterface` instead 
> > > > of the equivalent type which is an `ObjCObject`. The test itself just 
> > > > tests printing of a type, but I'm not sure how significant or 
> > > > intentional printing this specific way was.
> > > Which test was failing because of this?
> > clang/test/Index/print-type.m
> Specifically just the check:
> 
> ```
> CHECK: ParmDecl=p:6:36 (Definition) [type=__kindof Foo *] 
> [typekind=ObjCObjectPointer] [canonicaltype=__kindof Foo *] 
> [canonicaltypekind=ObjCObjectPointer] [basetype=Foo] [basekind=ObjCInterface] 
> [isPOD=1] [pointeetype=Foo] [pointeekind=ObjCInterface]
> ```
> 
> Where the last 2 fields we're instead `[pointeetype=__kindof Foo] 
> [pointeekind=ObjCObject]` instead of what they are now.
I looked at the review adding the impacted test case and I did not have the 
impression this was a principled decision so much as "that's what it prints". I 
suspect we'd be fine removing the hack and always returning the equivalent 
type, but ObjC is not my area of expertise.


Repository:
  rC Clang

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

https://reviews.llvm.org/D55447



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


[PATCH] D56658: [MSP430] Add msp430 toochain

2019-01-15 Thread Nathan Chancellor via Phabricator via cfe-commits
nathanchance added inline comments.



Comment at: cfe/trunk/lib/CodeGen/CodeGenModule.cpp:141
+  (!CodeGenOpts.RelaxedAliasing && CodeGenOpts.OptimizationLevel > 0)) {
+fprintf(stderr, "TBAA enabled\n");
 TBAA.reset(new CodeGenTBAA(Context, TheModule, CodeGenOpts, getLangOpts(),

I'm just curious, was committing this change intentional? Seems like something 
for debugging purposes, rather than a useful diagnostic, since it doesn't 
appear to be related to the rest of the patch (as far as I can tell).

I see it quite a bit on a Linux kernel build: 
https://gist.github.com/nathanchance/0b2d3b16d5b30396038d86f5cba3


Repository:
  rL LLVM

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

https://reviews.llvm.org/D56658



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


[PATCH] D54630: Move detection of libc++ include dirs to Driver on MacOS

2019-01-15 Thread Matthew Voss via Phabricator via cfe-commits
ormris added a comment.

Hi Ilya,

This commit is causing a test failure on the PS4 bot. Could you take a look?

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

Thanks,
Matthew


Repository:
  rC Clang

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

https://reviews.llvm.org/D54630



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


[PATCH] D55447: [Sema] Fix Modified Type in address_space AttributedType

2019-01-15 Thread Leonard Chan via Phabricator via cfe-commits
leonardchan marked an inline comment as done.
leonardchan added inline comments.



Comment at: clang/tools/libclang/CXType.cpp:132
+  if (!(TU->ParsingOptions & CXTranslationUnit_IncludeAttributedTypes) &&
+  ATT->getAttrKind() != attr::AddressSpace) {
 return MakeCXType(ATT->getModifiedType(), TU);

leonardchan wrote:
> aaron.ballman wrote:
> > leonardchan wrote:
> > > aaron.ballman wrote:
> > > > leonardchan wrote:
> > > > > aaron.ballman wrote:
> > > > > > leonardchan wrote:
> > > > > > > aaron.ballman wrote:
> > > > > > > > leonardchan wrote:
> > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > This change seems surprising -- if the parsing options say 
> > > > > > > > > > the caller does not want attributed types, why are we 
> > > > > > > > > > returning one anyway for address space?
> > > > > > > > > This has to do with ensuring `clang_getAddressSpace` still 
> > > > > > > > > returns the proper address_space. It does this by essentially 
> > > > > > > > > checking the qualifiers of the type, which we now attach to 
> > > > > > > > > the `AttributedType` whereas before it was attached to the 
> > > > > > > > > modified type.
> > > > > > > > > 
> > > > > > > > > This extra condition is necessary for ensuring that calling 
> > > > > > > > > `clang_getAddressSpace` points to the qualified 
> > > > > > > > > AttributedType instead of the unqualified modified type.
> > > > > > > > My fear is that this will be breaking assumptions in 
> > > > > > > > third-party code. If someone disables 
> > > > > > > > `CXTranslationUnit_IncludeAttributedTypes`, they are unlikely 
> > > > > > > > to expect to receive an `AttributedType` and may react poorly 
> > > > > > > > to it.
> > > > > > > Instead check if the type is address_space attributed and apply 
> > > > > > > the qualifiers the modified type.
> > > > > > Sure, they can always modify their code to handle it gracefully, 
> > > > > > but it's a silent, breaking change to a somewhat stable API which 
> > > > > > is why I was prodding about it.
> > > > > > 
> > > > > > After talking with @rsmith, we're thinking the correct change here 
> > > > > > is to return the attributed type when the user asks for it, but 
> > > > > > return the equivalent type rather than the modified type if the 
> > > > > > user doesn't want attribute sugar (for all attributes, not just 
> > > > > > address spaces). This way, when a user asks for CXType for one of 
> > > > > > these, they always get a correct type but sometimes it has 
> > > > > > attribute type sugar and sometimes it doesn't, depending on the 
> > > > > > parsing options.
> > > > > > 
> > > > > > This is still a silent, breaking change in behavior, which is 
> > > > > > unfortunate. It should probably come with a mention in the release 
> > > > > > notes about the change to the API and some unit tests as well.
> > > > > Ok. In the case of qualifiers then, should the equivalent type still 
> > > > > contain the address_space qualifiers when creating the AttributedType?
> > > > I believe so, yes -- that would ensure it's the minimally desugared 
> > > > type which the type is canonically equivalent to.
> > > Sorry for the holdup. So for an AddressSpace AttributedType, we attach 
> > > the qualifiers only to the equivalent type.
> > > 
> > > As for this though, the only problem I ran into with returning the 
> > > equivalent type is for AttributedTypes with `attr::ObjCKindOf`, a test 
> > > expects returning the modified type which is an `ObjCInterface` instead 
> > > of the equivalent type which is an `ObjCObject`. The test itself just 
> > > tests printing of a type, but I'm not sure how significant or intentional 
> > > printing this specific way was.
> > Which test was failing because of this?
> clang/test/Index/print-type.m
Specifically just the check:

```
CHECK: ParmDecl=p:6:36 (Definition) [type=__kindof Foo *] 
[typekind=ObjCObjectPointer] [canonicaltype=__kindof Foo *] 
[canonicaltypekind=ObjCObjectPointer] [basetype=Foo] [basekind=ObjCInterface] 
[isPOD=1] [pointeetype=Foo] [pointeekind=ObjCInterface]
```

Where the last 2 fields we're instead `[pointeetype=__kindof Foo] 
[pointeekind=ObjCObject]` instead of what they are now.


Repository:
  rC Clang

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

https://reviews.llvm.org/D55447



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


[PATCH] D56160: [clang-tidy] modernize-use-trailing-return check

2019-01-15 Thread Jonas Toth via Phabricator via cfe-commits
JonasToth added inline comments.



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:33
+const LangOptions ) {
+  // we start with the location of the closing parenthesis.
+  const TypeSourceInfo *TSI = F.getTypeSourceInfo();

Nit: s/we/We



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:39
+  }
+  const FunctionTypeLoc FTL =
+  TSI->getTypeLoc().IgnoreParens().getAs();

`const` is omitted in LLVM for value-types, only references and pointers are 
annottated with it.



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:46
+
+  // if the function argument list ends inside of a macro, it is dangerous to
+  // start lexing from here - bail out.

Nit: s/if/If/



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:48
+  // start lexing from here - bail out.
+  const SourceLocation ClosingParen = FTL.getRParenLoc();
+  if (ClosingParen.isMacroID()) {

same `const` argument.



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:57
+
+  // skip subsequent CV and ref qualifiers.
+  std::pair Loc = SM.getDecomposedLoc(Result);

Nit: s/skip/Skip/



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:87
+
+  // we start with the range of the return type and expand to neighboring const
+  // and volatile.

Nit: s/we/We/, s/const/'const'/, s/volatile/'volatile'/
We aim to highlight code-constructs to emphasize we are talking about the 
construct and not confuse the meaing of words.



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:91
+  if (ReturnTypeRange.isInvalid()) {
+diag(F.getLocation(), Message); // happens if e.g. clang cannot resolve all
+// includes and the return type is unknow.

I think this comment does not add value? Logically it makes sense to not return 
an invalid range and not work further with it regardless of reason for invalid 
range.

Anyhow, i would prefer a non-trailing comment.

s/happens/Happens/, s/unknow/unknown/ typo.



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:96
+
+  // if the return type has no local qualifiers, it's source range is accurate.
+  if (!F.getReturnType().hasLocalQualifiers())

Nit: s/if/If/ (stop commenting on these now :P)



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:100
+
+  const SourceLocation BeginF = expandIfMacroId(F.getBeginLoc(), SM);
+  const SourceLocation BeginNameF = expandIfMacroId(F.getLocation(), SM);

please ellide this `const`, as above



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:118
+  if (Info.hasMacroDefinition()) {
+diag(F.getLocation(), Message); // CV qualifiers in macros
+return {};

Please improve that comment and here I would prefer a non-trailing comment, too.
Especially formulate whats with CV and macros, the meaning has to be guessed 
(and can be guessed wrong).



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:133
+  bool ExtendedLeft = false;
+  for (size_t i = 0; i < Tokens.size(); i++) {
+// if we found the beginning of the return type, include const and volatile

please use uppercase `i` and `j` names for consistency.



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:136
+// to the left.
+if (!SM.isBeforeInTranslationUnit(Tokens[i].getLocation(),
+  ReturnTypeRange.getBegin()) &&

The whole function is quite complex, involved in multiple things (lexing, 
diagnostics, macro-stuff) and not easy to understand.
Could you please take a look at it again and try to split it up in smaller 
functions?
It looks a bit fragile and parts of it might deserve separate unit-tests.

Clarifying these parts of the code is definitly worth it.



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:162
+  functionDecl(unless(anyOf(hasTrailingReturn(), returns(voidType()),
+returns(autoType()), cxxConversionDecl(),
+cxxMethodDecl(isImplicit()

Shouldn't you include `returns(decltypeType())` as well?



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:176
+  // TODO: implement those
+  if (F->getDeclaredReturnType()->isFunctionPointerType() ||
+  F->getDeclaredReturnType()->isMemberFunctionPointerType() ||

Please add these as `Limitations` to the user-facing documentation. Some other 
checks do the same, just grep a bit for an example-



Comment at: clang-tidy/modernize/UseTrailingReturnCheck.cpp:187
+
+  const SourceLocation InsertionLoc =
+

r351245 - Enable IAS for OpenBSD SPARC.

2019-01-15 Thread Brad Smith via cfe-commits
Author: brad
Date: Tue Jan 15 13:04:36 2019
New Revision: 351245

URL: http://llvm.org/viewvc/llvm-project?rev=351245=rev
Log:
Enable IAS for OpenBSD SPARC.

Modified:
cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
cfe/trunk/test/Driver/openbsd.c

Modified: cfe/trunk/lib/Driver/ToolChains/Gnu.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Gnu.cpp?rev=351245=351244=351245=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Gnu.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Gnu.cpp Tue Jan 15 13:04:36 2019
@@ -2512,7 +2512,7 @@ bool Generic_GCC::IsIntegratedAssemblerD
   case llvm::Triple::sparc:
   case llvm::Triple::sparcel:
   case llvm::Triple::sparcv9:
-if (getTriple().isOSSolaris())
+if (getTriple().isOSSolaris() || getTriple().isOSOpenBSD())
   return true;
 return false;
   default:

Modified: cfe/trunk/test/Driver/openbsd.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/openbsd.c?rev=351245=351244=351245=diff
==
--- cfe/trunk/test/Driver/openbsd.c (original)
+++ cfe/trunk/test/Driver/openbsd.c Tue Jan 15 13:04:36 2019
@@ -74,12 +74,16 @@
 // CHECK-MIPS64EL: as{{.*}}" "-mabi" "64" "-EL"
 // CHECK-MIPS64EL-PIC: as{{.*}}" "-mabi" "64" "-EL" "-KPIC"
 
-// Check that the integrated assembler is enabled for MIPS64
+// Check that the integrated assembler is enabled for MIPS64/SPARC
 // RUN: %clang -target mips64-unknown-openbsd -### -c %s 2>&1 \
-// RUN:   | FileCheck -check-prefix=CHECK-MIPS64-AS %s
+// RUN:   | FileCheck -check-prefix=CHECK-IAS %s
 // RUN: %clang -target mips64el-unknown-openbsd -### -c %s 2>&1 \
-// RUN:   | FileCheck -check-prefix=CHECK-MIPS64-AS %s
-// CHECK-MIPS64-AS-NOT: "-no-integrated-as"
+// RUN:   | FileCheck -check-prefix=CHECK-IAS %s
+// RUN: %clang -target sparc-unknown-openbsd -### -c %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHECK-IAS %s
+// RUN: %clang -target sparc64-unknown-openbsd -### -c %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHECK-IAS %s
+// CHECK-IAS-NOT: "-no-integrated-as"
 
 // Check linking against correct startup code when (not) using PIE
 // RUN: %clang -no-canonical-prefixes -target i686-pc-openbsd %s -### 2>&1 \


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


[PATCH] D55447: [Sema] Fix Modified Type in address_space AttributedType

2019-01-15 Thread Leonard Chan via Phabricator via cfe-commits
leonardchan marked an inline comment as done.
leonardchan added inline comments.



Comment at: clang/tools/libclang/CXType.cpp:132
+  if (!(TU->ParsingOptions & CXTranslationUnit_IncludeAttributedTypes) &&
+  ATT->getAttrKind() != attr::AddressSpace) {
 return MakeCXType(ATT->getModifiedType(), TU);

aaron.ballman wrote:
> leonardchan wrote:
> > aaron.ballman wrote:
> > > leonardchan wrote:
> > > > aaron.ballman wrote:
> > > > > leonardchan wrote:
> > > > > > aaron.ballman wrote:
> > > > > > > leonardchan wrote:
> > > > > > > > aaron.ballman wrote:
> > > > > > > > > This change seems surprising -- if the parsing options say 
> > > > > > > > > the caller does not want attributed types, why are we 
> > > > > > > > > returning one anyway for address space?
> > > > > > > > This has to do with ensuring `clang_getAddressSpace` still 
> > > > > > > > returns the proper address_space. It does this by essentially 
> > > > > > > > checking the qualifiers of the type, which we now attach to the 
> > > > > > > > `AttributedType` whereas before it was attached to the modified 
> > > > > > > > type.
> > > > > > > > 
> > > > > > > > This extra condition is necessary for ensuring that calling 
> > > > > > > > `clang_getAddressSpace` points to the qualified AttributedType 
> > > > > > > > instead of the unqualified modified type.
> > > > > > > My fear is that this will be breaking assumptions in third-party 
> > > > > > > code. If someone disables 
> > > > > > > `CXTranslationUnit_IncludeAttributedTypes`, they are unlikely to 
> > > > > > > expect to receive an `AttributedType` and may react poorly to it.
> > > > > > Instead check if the type is address_space attributed and apply the 
> > > > > > qualifiers the modified type.
> > > > > Sure, they can always modify their code to handle it gracefully, but 
> > > > > it's a silent, breaking change to a somewhat stable API which is why 
> > > > > I was prodding about it.
> > > > > 
> > > > > After talking with @rsmith, we're thinking the correct change here is 
> > > > > to return the attributed type when the user asks for it, but return 
> > > > > the equivalent type rather than the modified type if the user doesn't 
> > > > > want attribute sugar (for all attributes, not just address spaces). 
> > > > > This way, when a user asks for CXType for one of these, they always 
> > > > > get a correct type but sometimes it has attribute type sugar and 
> > > > > sometimes it doesn't, depending on the parsing options.
> > > > > 
> > > > > This is still a silent, breaking change in behavior, which is 
> > > > > unfortunate. It should probably come with a mention in the release 
> > > > > notes about the change to the API and some unit tests as well.
> > > > Ok. In the case of qualifiers then, should the equivalent type still 
> > > > contain the address_space qualifiers when creating the AttributedType?
> > > I believe so, yes -- that would ensure it's the minimally desugared type 
> > > which the type is canonically equivalent to.
> > Sorry for the holdup. So for an AddressSpace AttributedType, we attach the 
> > qualifiers only to the equivalent type.
> > 
> > As for this though, the only problem I ran into with returning the 
> > equivalent type is for AttributedTypes with `attr::ObjCKindOf`, a test 
> > expects returning the modified type which is an `ObjCInterface` instead of 
> > the equivalent type which is an `ObjCObject`. The test itself just tests 
> > printing of a type, but I'm not sure how significant or intentional 
> > printing this specific way was.
> Which test was failing because of this?
clang/test/Index/print-type.m


Repository:
  rC Clang

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

https://reviews.llvm.org/D55447



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


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

2019-01-15 Thread Jennifer Yu via Phabricator via cfe-commits
jyu2 updated this revision to Diff 181862.
jyu2 added a comment.

I add additional test.


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

https://reviews.llvm.org/D56571

Files:
  include/clang/AST/Expr.h
  include/clang/AST/ExprCXX.h
  include/clang/AST/ExprObjC.h
  include/clang/AST/Stmt.h
  include/clang/Basic/DiagnosticASTKinds.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Sema/Sema.h
  lib/AST/ASTImporter.cpp
  lib/AST/Stmt.cpp
  lib/AST/StmtPrinter.cpp
  lib/AST/StmtProfile.cpp
  lib/Analysis/CFG.cpp
  lib/CodeGen/CGStmt.cpp
  lib/CodeGen/CodeGenFunction.h
  lib/Parse/ParseStmtAsm.cpp
  lib/Sema/SemaStmtAsm.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReaderStmt.cpp
  lib/Serialization/ASTWriterStmt.cpp
  test/Analysis/asm-goto.cpp
  test/CodeGen/asm-goto.c
  test/CodeGen/asm.c
  test/CodeGen/inline-asm-mixed-style.c
  test/Coverage/c-language-features.inc
  test/PCH/asm.h
  test/Parser/asm-goto.c
  test/Parser/asm-goto.cpp
  test/Parser/asm.c
  test/Parser/asm.cpp
  test/Sema/asm.c
  test/Sema/inline-asm-validate-tmpl.cpp

Index: test/Sema/inline-asm-validate-tmpl.cpp
===
--- test/Sema/inline-asm-validate-tmpl.cpp
+++ test/Sema/inline-asm-validate-tmpl.cpp
@@ -23,3 +23,13 @@
 	asm("rol %1, %0" :"=r"(value): "I"(N + 1));
 }
 int	foo() { testc<2>(10); }
+
+// these should compile without error
+template  bool testd()
+{
+  __asm goto ("" : : : : lab);
+  return true;
+lab:
+  return false;
+}
+bool foox() { return testd<0> (); }
Index: test/Sema/asm.c
===
--- test/Sema/asm.c
+++ test/Sema/asm.c
@@ -295,3 +295,28 @@
   return r0 + r1;
 }
 
+void test18()
+{
+  // expected-error@+2 {{duplicate use of asm operand name "lab"}}
+  // expected-note@+1 {{asm operand name "lab" first referenced here}}
+  asm goto ("" : : : : lab, lab, lab2, lab);
+  // expected-error@+2 {{duplicate use of asm operand name "lab"}}
+  // expected-note@+1 {{asm operand name "lab" first referenced here}}
+  asm goto ("xorw %[lab], %[lab]; je %l[lab]" : : [lab] "i" (0) : : lab);
+lab:;
+lab2:;
+  int x,x1;
+  // expected-error@+2 {{duplicate use of asm operand name "lab"}}
+  // expected-note@+1 {{asm operand name "lab" first referenced here}}
+  asm ("" : [lab] "=r" (x),[lab] "+r" (x) : [lab1] "r" (x));
+  // expected-error@+2 {{duplicate use of asm operand name "lab"}}
+  // expected-note@+1 {{asm operand name "lab" first referenced here}}
+  asm ("" : [lab] "=r" (x1) : [lab] "r" (x));
+  // expected-error@+1 {{invalid operand number which isn't point to a goto label in asm string}}
+  asm ("jne %l0"::"r"(&));
+  // expected-error@+1 {{invalid operand number in inline asm string}}
+  asm ("jne %l0":::);
+  // expected-error@+1 {{invalid operand number which isn't point to a goto label in asm string}}
+  asm goto ("jne %l0"::"r"(x)::lab);
+  asm goto ("jne %l0"lab);
+}
Index: test/Parser/asm.cpp
===
--- test/Parser/asm.cpp
+++ test/Parser/asm.cpp
@@ -7,3 +7,28 @@
 int foo5 asm (U"bar5"); // expected-error {{cannot use unicode string literal in 'asm'}}
 int foo6 asm ("bar6"_x); // expected-error {{string literal with user-defined suffix cannot be used here}}
 int foo6 asm ("" L"bar7"); // expected-error {{cannot use wide string literal in 'asm'}}
+
+int zoo ()
+{
+  int x,cond,*e;
+  // expected-error@+1 {{expected ')'}}
+  asm ("mov %[e], %[e]" : : [e] "rm" (*e)::a)
+  // expected-error@+1  {{expected ':'}}
+  asm goto ("decl %0; jnz %l[a]" :"=r"(x): "m"(x) : "memory" : a);
+  // expected-error@+1 {{expected identifie}}
+  asm goto ("decl %0;" :: "m"(x) : "memory" : );
+  // expected-error@+1  {{expected ':'}}
+  asm goto ("decl %0;" :: "m"(x) : "memory" );
+  // expected-error@+1 {{use of undeclared label 'x'}}
+  asm goto ("decl %0;" :: "m"(x) : "memory" :x);
+  // expected-error@+1 {{use of undeclared label 'b'}}
+  asm goto ("decl %0;" :: "m"(x) : "memory" :b);
+  // expected-error@+1 {{invalid operand number in inline asm string}}
+  asm goto ("testl %0, %0; jne %l3;" :: "r"(cond)::label_true, loop)
+  // expected-error@+1 {{unknown symbolic operand name in inline assembly string}}
+  asm goto ("decl %0; jnz %l[b]" :: "m"(x) : "memory" : a);
+label_true:
+loop:
+a:
+  return 0;
+}
Index: test/Parser/asm.c
===
--- test/Parser/asm.c
+++ test/Parser/asm.c
@@ -16,6 +16,31 @@
   asm _Atomic (""); // expected-warning {{ignored _Atomic qualifier on asm}}
 }
 
+int zoo ()
+{
+  int x,cond,*e;
+  // expected-error@+1 {{expected ')'}}
+  asm ("mov %[e], %[e]" : : [e] "rm" (*e)::a)
+  // expected-error@+1 {{expected ':'}}
+  asm goto ("decl %0; jnz %l[a]" :"=r"(x): "m"(x) : "memory" : a);
+  // expected-error@+1 {{expected identifie}}
+  asm goto ("decl %0;" :: "m"(x) : "memory" : );
+  // expected-error@+1 {{expected ':'}}
+  asm 

r351241 - CodeGen: Remove debug printf unintentionally added in r351228.

2019-01-15 Thread Peter Collingbourne via cfe-commits
Author: pcc
Date: Tue Jan 15 12:59:59 2019
New Revision: 351241

URL: http://llvm.org/viewvc/llvm-project?rev=351241=rev
Log:
CodeGen: Remove debug printf unintentionally added in r351228.

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

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=351241=351240=351241=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Tue Jan 15 12:59:59 2019
@@ -137,12 +137,10 @@ CodeGenModule::CodeGenModule(ASTContext
 
   // Enable TBAA unless it's suppressed. ThreadSanitizer needs TBAA even at O0.
   if (LangOpts.Sanitize.has(SanitizerKind::Thread) ||
-  (!CodeGenOpts.RelaxedAliasing && CodeGenOpts.OptimizationLevel > 0)) {
-fprintf(stderr, "TBAA enabled\n");
+  (!CodeGenOpts.RelaxedAliasing && CodeGenOpts.OptimizationLevel > 0))
 TBAA.reset(new CodeGenTBAA(Context, TheModule, CodeGenOpts, getLangOpts(),
getCXXABI().getMangleContext()));
-  }
-  
+
   // If debug info or coverage generation is enabled, create the CGDebugInfo
   // object.
   if (CodeGenOpts.getDebugInfo() != codegenoptions::NoDebugInfo ||


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


[PATCH] D56663: [MSP430] Improve support of 'interrupt' attribute

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



Comment at: include/clang/Basic/DiagnosticSemaKinds.td:277-280
+def warn_msp430_interrupt_attribute : Warning<
+   "MSP430 'interrupt' attribute only applies to functions that have "
+   "%select{no parameters|a 'void' return type}0">,
+   InGroup;

krisb wrote:
> aaron.ballman wrote:
> > I'd fold this in to the preceding diagnostics using `%select{}`. Perhaps 
> > the new diagnostic name should be 
> > `warn_interrupt_attribute_invalid_subject` or some such?
> I thought about this but decided to not touch other targets in this patch. 
> So, I'd prefer to make a follow-up patch to refactor these 3 diagnostics (for 
> mips, riscv and msp430) to a single.  What do you think?
I'm fine with that, thanks!


Repository:
  rC Clang

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

https://reviews.llvm.org/D56663



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


[PATCH] D55447: [Sema] Fix Modified Type in address_space AttributedType

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



Comment at: clang/tools/libclang/CXType.cpp:132
+  if (!(TU->ParsingOptions & CXTranslationUnit_IncludeAttributedTypes) &&
+  ATT->getAttrKind() != attr::AddressSpace) {
 return MakeCXType(ATT->getModifiedType(), TU);

leonardchan wrote:
> aaron.ballman wrote:
> > leonardchan wrote:
> > > aaron.ballman wrote:
> > > > leonardchan wrote:
> > > > > aaron.ballman wrote:
> > > > > > leonardchan wrote:
> > > > > > > aaron.ballman wrote:
> > > > > > > > This change seems surprising -- if the parsing options say the 
> > > > > > > > caller does not want attributed types, why are we returning one 
> > > > > > > > anyway for address space?
> > > > > > > This has to do with ensuring `clang_getAddressSpace` still 
> > > > > > > returns the proper address_space. It does this by essentially 
> > > > > > > checking the qualifiers of the type, which we now attach to the 
> > > > > > > `AttributedType` whereas before it was attached to the modified 
> > > > > > > type.
> > > > > > > 
> > > > > > > This extra condition is necessary for ensuring that calling 
> > > > > > > `clang_getAddressSpace` points to the qualified AttributedType 
> > > > > > > instead of the unqualified modified type.
> > > > > > My fear is that this will be breaking assumptions in third-party 
> > > > > > code. If someone disables 
> > > > > > `CXTranslationUnit_IncludeAttributedTypes`, they are unlikely to 
> > > > > > expect to receive an `AttributedType` and may react poorly to it.
> > > > > Instead check if the type is address_space attributed and apply the 
> > > > > qualifiers the modified type.
> > > > Sure, they can always modify their code to handle it gracefully, but 
> > > > it's a silent, breaking change to a somewhat stable API which is why I 
> > > > was prodding about it.
> > > > 
> > > > After talking with @rsmith, we're thinking the correct change here is 
> > > > to return the attributed type when the user asks for it, but return the 
> > > > equivalent type rather than the modified type if the user doesn't want 
> > > > attribute sugar (for all attributes, not just address spaces). This 
> > > > way, when a user asks for CXType for one of these, they always get a 
> > > > correct type but sometimes it has attribute type sugar and sometimes it 
> > > > doesn't, depending on the parsing options.
> > > > 
> > > > This is still a silent, breaking change in behavior, which is 
> > > > unfortunate. It should probably come with a mention in the release 
> > > > notes about the change to the API and some unit tests as well.
> > > Ok. In the case of qualifiers then, should the equivalent type still 
> > > contain the address_space qualifiers when creating the AttributedType?
> > I believe so, yes -- that would ensure it's the minimally desugared type 
> > which the type is canonically equivalent to.
> Sorry for the holdup. So for an AddressSpace AttributedType, we attach the 
> qualifiers only to the equivalent type.
> 
> As for this though, the only problem I ran into with returning the equivalent 
> type is for AttributedTypes with `attr::ObjCKindOf`, a test expects returning 
> the modified type which is an `ObjCInterface` instead of the equivalent type 
> which is an `ObjCObject`. The test itself just tests printing of a type, but 
> I'm not sure how significant or intentional printing this specific way was.
Which test was failing because of this?


Repository:
  rC Clang

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

https://reviews.llvm.org/D55447



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


[PATCH] D56663: [MSP430] Improve support of 'interrupt' attribute

2019-01-15 Thread Kristina Bessonova via Phabricator via cfe-commits
krisb added inline comments.



Comment at: include/clang/Basic/DiagnosticSemaKinds.td:277-280
+def warn_msp430_interrupt_attribute : Warning<
+   "MSP430 'interrupt' attribute only applies to functions that have "
+   "%select{no parameters|a 'void' return type}0">,
+   InGroup;

aaron.ballman wrote:
> I'd fold this in to the preceding diagnostics using `%select{}`. Perhaps the 
> new diagnostic name should be `warn_interrupt_attribute_invalid_subject` or 
> some such?
I thought about this but decided to not touch other targets in this patch. So, 
I'd prefer to make a follow-up patch to refactor these 3 diagnostics (for mips, 
riscv and msp430) to a single.  What do you think?


Repository:
  rC Clang

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

https://reviews.llvm.org/D56663



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


[PATCH] D55483: Introduce the callback attribute and emit !callback metadata

2019-01-15 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM aside from some minor nits.

However, please hold off on committing this until *after* the 8.0 branch 
happens. While I don't expect there to be issues with this patch, it does 
introduce a pretty novel new way to interact with attributes and I want to 
ensure that the community has the opportunity to react to any major issues with 
this approach, and I'm not certain a month or so will be enough time for that. 
If you need this patch to go in *before* the branch for some reason, please 
mention it! I'm not strictly opposed to it going in sooner rather than later, 
but if there's not a pressing need for the functionality, I'd prefer to wait 
out of an abundance of caution.




Comment at: include/clang/Basic/AttrDocs.td:3778
+The callback callee is required to be callable with the number, and order, of
+the specified arguments. The index `0`, or the identifier `__this`, is used to
+represent an implicit "this" pointer in class methods. If there is no implicit

`__this` should be `this` now.



Comment at: utils/TableGen/ClangAttrEmitter.cpp:2169
 
+static bool keywordThisIsaIdentifierInArgument(Record *Arg) {
+  return !Arg->getSuperClasses().empty() &&

`const Record *`



Comment at: utils/TableGen/ClangAttrEmitter.cpp:2177-2178
+
+static void emitClangAttrThisIsaIdentifierArgList(RecordKeeper ,
+  raw_ostream ) {
+  OS << "#if defined(CLANG_ATTR_THIS_ISA_IDENTIFIER_ARG_LIST)\n";

The formatting looks off here.


Repository:
  rC Clang

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

https://reviews.llvm.org/D55483



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


[PATCH] D56709: Implement BlockDecl::Capture dump in terms of visitors

2019-01-15 Thread Stephen Kelly via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rC351239: Implement BlockDecl::Capture dump in terms of 
visitors (authored by steveire, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D56709?vs=181751=181859#toc

Repository:
  rC Clang

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

https://reviews.llvm.org/D56709

Files:
  include/clang/AST/TextNodeDumper.h
  lib/AST/ASTDumper.cpp
  lib/AST/TextNodeDumper.cpp


Index: lib/AST/TextNodeDumper.cpp
===
--- lib/AST/TextNodeDumper.cpp
+++ lib/AST/TextNodeDumper.cpp
@@ -272,6 +272,18 @@
   }
 }
 
+void TextNodeDumper::Visit(const BlockDecl::Capture ) {
+  OS << "capture";
+  if (C.isByRef())
+OS << " byref";
+  if (C.isNested())
+OS << " nested";
+  if (C.getVariable()) {
+OS << ' ';
+dumpBareDeclRef(C.getVariable());
+  }
+}
+
 void TextNodeDumper::Visit(const OMPClause *C) {
   if (!C) {
 ColorScope Color(OS, ShowColors, NullColor);
Index: lib/AST/ASTDumper.cpp
===
--- lib/AST/ASTDumper.cpp
+++ lib/AST/ASTDumper.cpp
@@ -283,6 +283,7 @@
 void VisitObjCCompatibleAliasDecl(const ObjCCompatibleAliasDecl *D);
 void VisitObjCPropertyDecl(const ObjCPropertyDecl *D);
 void VisitObjCPropertyImplDecl(const ObjCPropertyImplDecl *D);
+void Visit(const BlockDecl::Capture );
 void VisitBlockDecl(const BlockDecl *D);
 
 // Stmts.
@@ -1371,6 +1372,14 @@
   NodeDumper.dumpDeclRef(D->getPropertyIvarDecl());
 }
 
+void ASTDumper::Visit(const BlockDecl::Capture ) {
+  dumpChild([=] {
+NodeDumper.Visit(C);
+if (C.hasCopyExpr())
+  dumpStmt(C.getCopyExpr());
+  });
+}
+
 void ASTDumper::VisitBlockDecl(const BlockDecl *D) {
   for (auto I : D->parameters())
 dumpDecl(I);
@@ -1381,21 +1390,8 @@
   if (D->capturesCXXThis())
 dumpChild([=]{ OS << "capture this"; });
 
-  for (const auto  : D->captures()) {
-dumpChild([=] {
-  OS << "capture";
-  if (I.isByRef())
-OS << " byref";
-  if (I.isNested())
-OS << " nested";
-  if (I.getVariable()) {
-OS << ' ';
-NodeDumper.dumpBareDeclRef(I.getVariable());
-  }
-  if (I.hasCopyExpr())
-dumpStmt(I.getCopyExpr());
-});
-  }
+  for (const auto  : D->captures())
+Visit(I);
   dumpStmt(D->getBody());
 }
 
Index: include/clang/AST/TextNodeDumper.h
===
--- include/clang/AST/TextNodeDumper.h
+++ include/clang/AST/TextNodeDumper.h
@@ -171,6 +171,8 @@
 
   void Visit(const OMPClause *C);
 
+  void Visit(const BlockDecl::Capture );
+
   void dumpPointer(const void *Ptr);
   void dumpLocation(SourceLocation Loc);
   void dumpSourceRange(SourceRange R);


Index: lib/AST/TextNodeDumper.cpp
===
--- lib/AST/TextNodeDumper.cpp
+++ lib/AST/TextNodeDumper.cpp
@@ -272,6 +272,18 @@
   }
 }
 
+void TextNodeDumper::Visit(const BlockDecl::Capture ) {
+  OS << "capture";
+  if (C.isByRef())
+OS << " byref";
+  if (C.isNested())
+OS << " nested";
+  if (C.getVariable()) {
+OS << ' ';
+dumpBareDeclRef(C.getVariable());
+  }
+}
+
 void TextNodeDumper::Visit(const OMPClause *C) {
   if (!C) {
 ColorScope Color(OS, ShowColors, NullColor);
Index: lib/AST/ASTDumper.cpp
===
--- lib/AST/ASTDumper.cpp
+++ lib/AST/ASTDumper.cpp
@@ -283,6 +283,7 @@
 void VisitObjCCompatibleAliasDecl(const ObjCCompatibleAliasDecl *D);
 void VisitObjCPropertyDecl(const ObjCPropertyDecl *D);
 void VisitObjCPropertyImplDecl(const ObjCPropertyImplDecl *D);
+void Visit(const BlockDecl::Capture );
 void VisitBlockDecl(const BlockDecl *D);
 
 // Stmts.
@@ -1371,6 +1372,14 @@
   NodeDumper.dumpDeclRef(D->getPropertyIvarDecl());
 }
 
+void ASTDumper::Visit(const BlockDecl::Capture ) {
+  dumpChild([=] {
+NodeDumper.Visit(C);
+if (C.hasCopyExpr())
+  dumpStmt(C.getCopyExpr());
+  });
+}
+
 void ASTDumper::VisitBlockDecl(const BlockDecl *D) {
   for (auto I : D->parameters())
 dumpDecl(I);
@@ -1381,21 +1390,8 @@
   if (D->capturesCXXThis())
 dumpChild([=]{ OS << "capture this"; });
 
-  for (const auto  : D->captures()) {
-dumpChild([=] {
-  OS << "capture";
-  if (I.isByRef())
-OS << " byref";
-  if (I.isNested())
-OS << " nested";
-  if (I.getVariable()) {
-OS << ' ';
-NodeDumper.dumpBareDeclRef(I.getVariable());
-  }
-  if (I.hasCopyExpr())
-dumpStmt(I.getCopyExpr());
-});
-  }
+  for (const auto  : D->captures())
+Visit(I);
   dumpStmt(D->getBody());
 }
 
Index: include/clang/AST/TextNodeDumper.h
===
--- include/clang/AST/TextNodeDumper.h
+++ 

r351239 - Implement BlockDecl::Capture dump in terms of visitors

2019-01-15 Thread Stephen Kelly via cfe-commits
Author: steveire
Date: Tue Jan 15 12:41:37 2019
New Revision: 351239

URL: http://llvm.org/viewvc/llvm-project?rev=351239=rev
Log:
Implement BlockDecl::Capture dump in terms of visitors

Reviewers: aaron.ballman

Subscribers: cfe-commits

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

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

Modified: cfe/trunk/include/clang/AST/TextNodeDumper.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/TextNodeDumper.h?rev=351239=351238=351239=diff
==
--- cfe/trunk/include/clang/AST/TextNodeDumper.h (original)
+++ cfe/trunk/include/clang/AST/TextNodeDumper.h Tue Jan 15 12:41:37 2019
@@ -171,6 +171,8 @@ public:
 
   void Visit(const OMPClause *C);
 
+  void Visit(const BlockDecl::Capture );
+
   void dumpPointer(const void *Ptr);
   void dumpLocation(SourceLocation Loc);
   void dumpSourceRange(SourceRange R);

Modified: cfe/trunk/lib/AST/ASTDumper.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ASTDumper.cpp?rev=351239=351238=351239=diff
==
--- cfe/trunk/lib/AST/ASTDumper.cpp (original)
+++ cfe/trunk/lib/AST/ASTDumper.cpp Tue Jan 15 12:41:37 2019
@@ -283,6 +283,7 @@ namespace  {
 void VisitObjCCompatibleAliasDecl(const ObjCCompatibleAliasDecl *D);
 void VisitObjCPropertyDecl(const ObjCPropertyDecl *D);
 void VisitObjCPropertyImplDecl(const ObjCPropertyImplDecl *D);
+void Visit(const BlockDecl::Capture );
 void VisitBlockDecl(const BlockDecl *D);
 
 // Stmts.
@@ -1371,6 +1372,14 @@ void ASTDumper::VisitObjCPropertyImplDec
   NodeDumper.dumpDeclRef(D->getPropertyIvarDecl());
 }
 
+void ASTDumper::Visit(const BlockDecl::Capture ) {
+  dumpChild([=] {
+NodeDumper.Visit(C);
+if (C.hasCopyExpr())
+  dumpStmt(C.getCopyExpr());
+  });
+}
+
 void ASTDumper::VisitBlockDecl(const BlockDecl *D) {
   for (auto I : D->parameters())
 dumpDecl(I);
@@ -1381,21 +1390,8 @@ void ASTDumper::VisitBlockDecl(const Blo
   if (D->capturesCXXThis())
 dumpChild([=]{ OS << "capture this"; });
 
-  for (const auto  : D->captures()) {
-dumpChild([=] {
-  OS << "capture";
-  if (I.isByRef())
-OS << " byref";
-  if (I.isNested())
-OS << " nested";
-  if (I.getVariable()) {
-OS << ' ';
-NodeDumper.dumpBareDeclRef(I.getVariable());
-  }
-  if (I.hasCopyExpr())
-dumpStmt(I.getCopyExpr());
-});
-  }
+  for (const auto  : D->captures())
+Visit(I);
   dumpStmt(D->getBody());
 }
 

Modified: cfe/trunk/lib/AST/TextNodeDumper.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/TextNodeDumper.cpp?rev=351239=351238=351239=diff
==
--- cfe/trunk/lib/AST/TextNodeDumper.cpp (original)
+++ cfe/trunk/lib/AST/TextNodeDumper.cpp Tue Jan 15 12:41:37 2019
@@ -272,6 +272,18 @@ void TextNodeDumper::Visit(const CXXCtor
   }
 }
 
+void TextNodeDumper::Visit(const BlockDecl::Capture ) {
+  OS << "capture";
+  if (C.isByRef())
+OS << " byref";
+  if (C.isNested())
+OS << " nested";
+  if (C.getVariable()) {
+OS << ' ';
+dumpBareDeclRef(C.getVariable());
+  }
+}
+
 void TextNodeDumper::Visit(const OMPClause *C) {
   if (!C) {
 ColorScope Color(OS, ShowColors, NullColor);


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


  1   2   3   >