[PATCH] D31706: [clang-format] Handle NSString literals by merging tokens.

2017-04-10 Thread Daniel Jasper via Phabricator via cfe-commits
djasper accepted this revision.
djasper added a comment.
This revision is now accepted and ready to land.

Looks good. Thanks for cleaning this up.


https://reviews.llvm.org/D31706



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


[libcxx] r299909 - Fix a C++03 failure

2017-04-10 Thread Marshall Clow via cfe-commits
Author: marshall
Date: Mon Apr 10 20:54:48 2017
New Revision: 299909

URL: http://llvm.org/viewvc/llvm-project?rev=299909=rev
Log:
Fix a C++03 failure

Modified:

libcxx/trunk/test/std/utilities/meta/meta.trans/meta.trans.other/common_type.pass.cpp

Modified: 
libcxx/trunk/test/std/utilities/meta/meta.trans/meta.trans.other/common_type.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/meta/meta.trans/meta.trans.other/common_type.pass.cpp?rev=299909=299908=299909=diff
==
--- 
libcxx/trunk/test/std/utilities/meta/meta.trans/meta.trans.other/common_type.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/utilities/meta/meta.trans/meta.trans.other/common_type.pass.cpp
 Mon Apr 10 20:54:48 2017
@@ -96,6 +96,9 @@ void test_bullet_two() {
   static_assert(std::is_same::value, "");
   static_assert(std::is_same::value, "");
   static_assert(std::is_same, void(*)()>::value, "");
+
+  static_assert(no_common_type::value, "");
+  static_assert(no_common_type::value, "");
 }
 
 template 
@@ -306,7 +309,4 @@ int main()
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::type,   
int>::value), "");
 static_assert((std::is_same::value), "");
-
-static_assert(no_common_type::value, "");
-static_assert(no_common_type::value, "");
 }


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


[PATCH] D31542: [clang-tidy] Extend readability-container-size-empty to add comparisons to newly-constructed objects

2017-04-10 Thread Josh Zimmerman via Phabricator via cfe-commits
joshz added a comment.

Hey there, reviewers. 
Any chance you can take a look at this change?

Thanks! :-)


Repository:
  rL LLVM

https://reviews.llvm.org/D31542



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


[libcxx] r299907 - Remove some trigraphs that GCC was complaining about

2017-04-10 Thread Marshall Clow via cfe-commits
Author: marshall
Date: Mon Apr 10 19:18:28 2017
New Revision: 299907

URL: http://llvm.org/viewvc/llvm-project?rev=299907=rev
Log:
Remove some trigraphs that GCC was complaining about

Modified:

libcxx/trunk/test/std/utilities/meta/meta.trans/meta.trans.other/common_type.pass.cpp

Modified: 
libcxx/trunk/test/std/utilities/meta/meta.trans/meta.trans.other/common_type.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/meta/meta.trans/meta.trans.other/common_type.pass.cpp?rev=299907=299906=299907=diff
==
--- 
libcxx/trunk/test/std/utilities/meta/meta.trans/meta.trans.other/common_type.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/utilities/meta/meta.trans/meta.trans.other/common_type.pass.cpp
 Mon Apr 10 19:18:28 2017
@@ -45,8 +45,8 @@ namespace std
 
 template <> struct common_type< ::S, long> {};
 template <> struct common_type {};
-template <> struct common_type<::X > {};
-template <> struct common_type<::X, ::X > {};
+template <> struct common_type< ::X > {};
+template <> struct common_type< ::X, ::X > {};
 }
 
 #if TEST_STD_VER >= 11


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


r299902 - docs: Use the term "whole-program devirtualization" instead of "virtual function call optimization".

2017-04-10 Thread Peter Collingbourne via cfe-commits
Author: pcc
Date: Mon Apr 10 18:54:28 2017
New Revision: 299902

URL: http://llvm.org/viewvc/llvm-project?rev=299902=rev
Log:
docs: Use the term "whole-program devirtualization" instead of "virtual 
function call optimization".

The former term is probably more familiar to users. Also add references to
the command line flags used to enable the features described in the doc.

Modified:
cfe/trunk/docs/LTOVisibility.rst

Modified: cfe/trunk/docs/LTOVisibility.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LTOVisibility.rst?rev=299902=299901=299902=diff
==
--- cfe/trunk/docs/LTOVisibility.rst (original)
+++ cfe/trunk/docs/LTOVisibility.rst Mon Apr 10 18:54:28 2017
@@ -10,15 +10,16 @@ using link-time optimization; in the cas
 linkage unit's LTO unit is empty. Each linkage unit has only a single LTO unit.
 
 The LTO visibility of a class is used by the compiler to determine which
-classes the virtual function call optimization and control flow integrity
-features apply to. These features use whole-program information, so they
-require the entire class hierarchy to be visible in order to work correctly.
+classes the whole-program devirtualization (``-fwhole-program-vtables``) and
+control flow integrity (``-fsanitize=cfi-vcall``) features apply to. These
+features use whole-program information, so they require the entire class
+hierarchy to be visible in order to work correctly.
 
-If any translation unit in the program uses either of the virtual function
-call optimization or control flow integrity features, it is effectively an
-ODR violation to define a class with hidden LTO visibility in multiple linkage
+If any translation unit in the program uses either of the whole-program
+devirtualization or control flow integrity features, it is effectively an ODR
+violation to define a class with hidden LTO visibility in multiple linkage
 units. A class with public LTO visibility may be defined in multiple linkage
-units, but the tradeoff is that the virtual function call optimization and
+units, but the tradeoff is that the whole-program devirtualization and
 control flow integrity features can only be applied to classes with hidden LTO
 visibility. A class's LTO visibility is treated as an ODR-relevant property
 of its definition, so it must be consistent between translation units.


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


[libcxx] r299901 - Fix PR#32605: common_type is not SFINAE-friendly

2017-04-10 Thread Marshall Clow via cfe-commits
Author: marshall
Date: Mon Apr 10 18:47:47 2017
New Revision: 299901

URL: http://llvm.org/viewvc/llvm-project?rev=299901=rev
Log:
Fix PR#32605: common_type is not SFINAE-friendly

Modified:
libcxx/trunk/include/type_traits

libcxx/trunk/test/std/utilities/meta/meta.trans/meta.trans.other/common_type.pass.cpp

Modified: libcxx/trunk/include/type_traits
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/type_traits?rev=299901=299900=299901=diff
==
--- libcxx/trunk/include/type_traits (original)
+++ libcxx/trunk/include/type_traits Mon Apr 10 18:47:47 2017
@@ -1998,9 +1998,7 @@ struct _LIBCPP_TEMPLATE_VIS common_type
 
 template 
 struct _LIBCPP_TEMPLATE_VIS common_type<_Tp>
-{
-typedef typename common_type<_Tp, _Tp>::type type;
-};
+: public common_type<_Tp, _Tp> {};
 
 // bullet 3 - sizeof...(Tp) == 2
 

Modified: 
libcxx/trunk/test/std/utilities/meta/meta.trans/meta.trans.other/common_type.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/meta/meta.trans/meta.trans.other/common_type.pass.cpp?rev=299901=299900=299901=diff
==
--- 
libcxx/trunk/test/std/utilities/meta/meta.trans/meta.trans.other/common_type.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/utilities/meta/meta.trans/meta.trans.other/common_type.pass.cpp
 Mon Apr 10 18:47:47 2017
@@ -45,6 +45,8 @@ namespace std
 
 template <> struct common_type< ::S, long> {};
 template <> struct common_type {};
+template <> struct common_type<::X > {};
+template <> struct common_type<::X, ::X > {};
 }
 
 #if TEST_STD_VER >= 11
@@ -304,5 +306,7 @@ int main()
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::type,   
int>::value), "");
 static_assert((std::is_same::value), "");
-
+
+static_assert(no_common_type::value, "");
+static_assert(no_common_type::value, "");
 }


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


r299899 - Reland "[IR] Make AttributeSetNode public, avoid temporary AttributeList copies"

2017-04-10 Thread Reid Kleckner via cfe-commits
Author: rnk
Date: Mon Apr 10 18:31:05 2017
New Revision: 299899

URL: http://llvm.org/viewvc/llvm-project?rev=299899=rev
Log:
Reland "[IR] Make AttributeSetNode public, avoid temporary AttributeList copies"

This re-lands r299875.

I introduced a bug in Clang code responsible for replacing K, no
prototype declarations with a real function definition with a prototype.
The bug was here:

   // Collect any return attributes from the call.
  -if (oldAttrs.hasAttributes(llvm::AttributeList::ReturnIndex))
  -  newAttrs.push_back(llvm::AttributeList::get(newFn->getContext(),
  -  
oldAttrs.getRetAttributes()));
  +newAttrs.push_back(oldAttrs.getRetAttributes());

Previously getRetAttributes() carried AttributeList::ReturnIndex in its
AttributeList. Now that we return the AttributeSetNode* directly, it no
longer carries that index, and we call this overload with a single node:
  AttributeList::get(LLVMContext&, ArrayRef)

That aborted with an assertion on x86_32 targets. I added an explicit
triple to the test and added CHECKs to help find issues like this in the
future sooner.

Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp   (contents, props changed)
cfe/trunk/test/CodeGen/2006-05-19-SingleEltReturn.c

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=299899=299898=299899=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Mon Apr 10 18:31:05 2017
@@ -2935,13 +2935,11 @@ static void replaceUsesOfNonProtoConstan
   continue;
 
 // Get the call site's attribute list.
-SmallVector newAttrs;
+SmallVector newAttrs;
 llvm::AttributeList oldAttrs = callSite.getAttributes();
 
 // Collect any return attributes from the call.
-if (oldAttrs.hasAttributes(llvm::AttributeList::ReturnIndex))
-  newAttrs.push_back(llvm::AttributeList::get(newFn->getContext(),
-  
oldAttrs.getRetAttributes()));
+newAttrs.push_back(oldAttrs.getRetAttributes());
 
 // If the function was passed too few arguments, don't transform.
 unsigned newNumArgs = newFn->arg_size();
@@ -2959,16 +2957,12 @@ static void replaceUsesOfNonProtoConstan
   }
 
   // Add any parameter attributes.
-  if (oldAttrs.hasAttributes(argNo + 1))
-newAttrs.push_back(llvm::AttributeList::get(
-newFn->getContext(), oldAttrs.getParamAttributes(argNo + 1)));
+  newAttrs.push_back(oldAttrs.getParamAttributes(argNo + 1));
 }
 if (dontTransform)
   continue;
 
-if (oldAttrs.hasAttributes(llvm::AttributeList::FunctionIndex))
-  newAttrs.push_back(llvm::AttributeList::get(newFn->getContext(),
-  oldAttrs.getFnAttributes()));
+newAttrs.push_back(oldAttrs.getFnAttributes());
 
 // Okay, we can transform this.  Create the new call instruction and copy
 // over the required information.

Propchange: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
--
--- svn:eol-style (original)
+++ svn:eol-style (removed)
@@ -1 +0,0 @@
-native

Modified: cfe/trunk/test/CodeGen/2006-05-19-SingleEltReturn.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/2006-05-19-SingleEltReturn.c?rev=299899=299898=299899=diff
==
--- cfe/trunk/test/CodeGen/2006-05-19-SingleEltReturn.c (original)
+++ cfe/trunk/test/CodeGen/2006-05-19-SingleEltReturn.c Mon Apr 10 18:31:05 2017
@@ -1,12 +1,13 @@
 // Test returning a single element aggregate value containing a double.
+// RUN: %clang_cc1 -triple i686-linux %s -emit-llvm -o - | FileCheck %s 
--check-prefix=X86_32
 // RUN: %clang_cc1 %s -emit-llvm -o -
 
 struct X {
   double D;
 };
 
-struct Y { 
-  struct X x; 
+struct Y {
+  struct X x;
 };
 
 struct Y bar();
@@ -21,3 +22,9 @@ struct Y bar() {
   return a;
 }
 
+
+// X86_32: define void @foo(%struct.Y* %P)
+// X86_32:   call void @bar(%struct.Y* sret %{{[^),]*}})
+
+// X86_32: define void @bar(%struct.Y* noalias sret %{{[^,)]*}})
+// X86_32:   ret void


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


[libcxx] r299894 - Fix PR#32606: std::decay mishandles abominable function types

2017-04-10 Thread Marshall Clow via cfe-commits
Author: marshall
Date: Mon Apr 10 17:51:07 2017
New Revision: 299894

URL: http://llvm.org/viewvc/llvm-project?rev=299894=rev
Log:
Fix PR#32606: std::decay mishandles abominable function types

Modified:
libcxx/trunk/include/type_traits

libcxx/trunk/test/std/utilities/meta/meta.trans/meta.trans.other/decay.pass.cpp

Modified: libcxx/trunk/include/type_traits
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/type_traits?rev=299894=299893=299894=diff
==
--- libcxx/trunk/include/type_traits (original)
+++ libcxx/trunk/include/type_traits Mon Apr 10 17:51:07 2017
@@ -1272,11 +1272,13 @@ template  using remove_all_ex
 
 // decay
 
-template 
-struct _LIBCPP_TEMPLATE_VIS decay
-{
-private:
-typedef typename remove_reference<_Tp>::type _Up;
+template 
+struct __decay {
+typedef typename remove_cv<_Up>::type type;
+};
+
+template 
+struct __decay<_Up, true> {
 public:
 typedef typename conditional
  <
@@ -1291,6 +1293,15 @@ public:
  >::type type;
 };
 
+template 
+struct _LIBCPP_TEMPLATE_VIS decay
+{
+private:
+typedef typename remove_reference<_Tp>::type _Up;
+public:
+typedef typename __decay<_Up, __is_referenceable<_Up>::value>::type type;
+};
+
 #if _LIBCPP_STD_VER > 11
 template  using decay_t = typename decay<_Tp>::type;
 #endif

Modified: 
libcxx/trunk/test/std/utilities/meta/meta.trans/meta.trans.other/decay.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/meta/meta.trans/meta.trans.other/decay.pass.cpp?rev=299894=299893=299894=diff
==
--- 
libcxx/trunk/test/std/utilities/meta/meta.trans/meta.trans.other/decay.pass.cpp 
(original)
+++ 
libcxx/trunk/test/std/utilities/meta/meta.trans/meta.trans.other/decay.pass.cpp 
Mon Apr 10 17:51:07 2017
@@ -33,4 +33,10 @@ int main()
 test_decay();
 test_decay();
 test_decay();
+#if TEST_STD_VER > 11
+   test_decay();
+   test_decay();
+   test_decay();
+   test_decay();
+#endif
 }


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


[PATCH] D31561: cmath: Skip Libc for integral types in isinf, etc.

2017-04-10 Thread Hal Finkel via Phabricator via cfe-commits
hfinkel added a subscriber: mclow.lists.
hfinkel added a comment.

I'm happy with this now. @EricWF , @mclow.lists , thoughts?


https://reviews.llvm.org/D31561



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


[PATCH] D31044: Update for alloca construction changes

2017-04-10 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm closed this revision.
arsenm added a comment.

r299889


https://reviews.llvm.org/D31044



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


r299889 - Update for AllocaInst construction changes

2017-04-10 Thread Matt Arsenault via cfe-commits
Author: arsenm
Date: Mon Apr 10 17:28:02 2017
New Revision: 299889

URL: http://llvm.org/viewvc/llvm-project?rev=299889=rev
Log:
Update for AllocaInst construction changes

Modified:
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/lib/CodeGen/CGExpr.cpp

Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=299889=299888=299889=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Mon Apr 10 17:28:02 2017
@@ -3710,12 +3710,14 @@ RValue CodeGenFunction::EmitCall(const C
   Address ArgMemory = Address::invalid();
   const llvm::StructLayout *ArgMemoryLayout = nullptr;
   if (llvm::StructType *ArgStruct = CallInfo.getArgStruct()) {
-ArgMemoryLayout = CGM.getDataLayout().getStructLayout(ArgStruct);
+const llvm::DataLayout  = CGM.getDataLayout();
+ArgMemoryLayout = DL.getStructLayout(ArgStruct);
 llvm::Instruction *IP = CallArgs.getStackBase();
 llvm::AllocaInst *AI;
 if (IP) {
   IP = IP->getNextNode();
-  AI = new llvm::AllocaInst(ArgStruct, "argmem", IP);
+  AI = new llvm::AllocaInst(ArgStruct, DL.getAllocaAddrSpace(),
+"argmem", IP);
 } else {
   AI = CreateTempAlloca(ArgStruct, "argmem");
 }

Modified: cfe/trunk/lib/CodeGen/CGExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExpr.cpp?rev=299889=299888=299889=diff
==
--- cfe/trunk/lib/CodeGen/CGExpr.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGExpr.cpp Mon Apr 10 17:28:02 2017
@@ -71,7 +71,8 @@ Address CodeGenFunction::CreateTempAlloc
 /// block.
 llvm::AllocaInst *CodeGenFunction::CreateTempAlloca(llvm::Type *Ty,
 const Twine ) {
-  return new llvm::AllocaInst(Ty, nullptr, Name, AllocaInsertPt);
+  return new llvm::AllocaInst(Ty, CGM.getDataLayout().getAllocaAddrSpace(),
+  nullptr, Name, AllocaInsertPt);
 }
 
 /// CreateDefaultAlignTempAlloca - This creates an alloca with the


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


[PATCH] D30158: [clang-tidy] modernize: Find usage of random_shuffle and replace it with shuffle.

2017-04-10 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.

There are a few small nits I've mentioned, but otherwise LGTM.




Comment at: clang-tidy/modernize/ReplaceRandomShuffleCheck.cpp:34-35
+
+  const auto first = hasArgument(0, expr().bind("one"));
+  const auto second = hasArgument(1, expr().bind("two"));
+  const auto third = hasArgument(2, expr().bind("three"));

No need to bind either of these -- the bound name never gets used.



Comment at: clang-tidy/modernize/ReplaceRandomShuffleCheck.cpp:36
+  const auto second = hasArgument(1, expr().bind("two"));
+  const auto third = hasArgument(2, expr().bind("three"));
+  Finder->addMatcher(

Can likely pick a better name to bind than "three". ;-) I would recommend 
"RandomFunc" since that's what the parameter represents.



Comment at: clang-tidy/modernize/ReplaceRandomShuffleCheck.cpp:70
+if (MatchedCallExpr->getNumArgs() == 3) {
+  auto DiagL = diag(MatchedCallExpr->getLocStart(), "'std::random_shuffle' 
has been removed in C++17; use 'std::shuffle' and an alternative random 
mechanism instead");
+  DiagL << FixItHint::CreateReplacement(

Wrap for 80-column (here and elsewhere).


https://reviews.llvm.org/D30158



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


[PATCH] D31561: cmath: Skip Libc for integral types in isinf, etc.

2017-04-10 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith marked 2 inline comments as done.
dexonsmith added a comment.

Marking Hal's comments as "Done".  Thanks for the review.


https://reviews.llvm.org/D31561



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


[PATCH] D31561: cmath: Skip Libc for integral types in isinf, etc.

2017-04-10 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith updated this revision to Diff 94750.
dexonsmith added a comment.

Responding to Hal's comments.


https://reviews.llvm.org/D31561

Files:
  libcxx/include/math.h
  libcxx/test/std/numerics/c.math/cmath.pass.cpp

Index: libcxx/test/std/numerics/c.math/cmath.pass.cpp
===
--- libcxx/test/std/numerics/c.math/cmath.pass.cpp
+++ libcxx/test/std/numerics/c.math/cmath.pass.cpp
@@ -10,6 +10,7 @@
 // 
 
 #include 
+#include 
 #include 
 #include 
 
@@ -551,6 +552,13 @@
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 assert(std::signbit(-1.0) == true);
+assert(std::signbit(0u) == false);
+assert(std::signbit(std::numeric_limits::max()) == false);
+assert(std::signbit(0) == false);
+assert(std::signbit(1) == false);
+assert(std::signbit(-1) == true);
+assert(std::signbit(std::numeric_limits::max()) == false);
+assert(std::signbit(std::numeric_limits::min()) == true);
 }
 
 void test_fpclassify()
@@ -564,6 +572,11 @@
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 assert(std::fpclassify(-1.0) == FP_NORMAL);
+assert(std::fpclassify(0) == FP_ZERO);
+assert(std::fpclassify(1) == FP_NORMAL);
+assert(std::fpclassify(-1) == FP_NORMAL);
+assert(std::fpclassify(std::numeric_limits::max()) == FP_NORMAL);
+assert(std::fpclassify(std::numeric_limits::min()) == FP_NORMAL);
 }
 
 void test_isfinite()
@@ -577,6 +590,11 @@
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 assert(std::isfinite(-1.0) == true);
+assert(std::isfinite(0) == true);
+assert(std::isfinite(1) == true);
+assert(std::isfinite(-1) == true);
+assert(std::isfinite(std::numeric_limits::max()) == true);
+assert(std::isfinite(std::numeric_limits::min()) == true);
 }
 
 void test_isnormal()
@@ -590,6 +608,11 @@
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 assert(std::isnormal(-1.0) == true);
+assert(std::isnormal(0) == false);
+assert(std::isnormal(1) == true);
+assert(std::isnormal(-1) == true);
+assert(std::isnormal(std::numeric_limits::max()) == true);
+assert(std::isnormal(std::numeric_limits::min()) == true);
 }
 
 void test_isgreater()
@@ -651,6 +674,11 @@
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 assert(std::isinf(-1.0) == false);
+assert(std::isinf(0) == false);
+assert(std::isinf(1) == false);
+assert(std::isinf(-1) == false);
+assert(std::isinf(std::numeric_limits::max()) == false);
+assert(std::isinf(std::numeric_limits::min()) == false);
 }
 
 void test_isless()
@@ -731,6 +759,11 @@
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 assert(std::isnan(-1.0) == false);
+assert(std::isnan(0) == false);
+assert(std::isnan(1) == false);
+assert(std::isnan(-1) == false);
+assert(std::isnan(std::numeric_limits::max()) == false);
+assert(std::isnan(std::numeric_limits::min()) == false);
 }
 
 void test_isunordered()
Index: libcxx/include/math.h
===
--- libcxx/include/math.h
+++ libcxx/include/math.h
@@ -307,6 +307,7 @@
 extern "C++" {
 
 #include 
+#include 
 
 // signbit
 
@@ -324,22 +325,54 @@
 
 template 
 inline _LIBCPP_INLINE_VISIBILITY
-typename std::enable_if::value, bool>::type
+typename std::enable_if<
+std::is_arithmetic<_A1>::value && !std::is_integral<_A1>::value,
+bool>::type
 signbit(_A1 __lcpp_x) _NOEXCEPT
 {
 return __libcpp_signbit((typename std::__promote<_A1>::type)__lcpp_x);
 }
 
+template 
+inline _LIBCPP_INLINE_VISIBILITY
+typename std::enable_if<
+std::is_integral<_A1>::value && std::is_signed<_A1>::value, bool>::type
+signbit(_A1 __lcpp_x) _NOEXCEPT
+{ return __lcpp_x < 0; }
+
+template 
+inline _LIBCPP_INLINE_VISIBILITY
+typename std::enable_if<
+std::is_integral<_A1>::value && !std::is_signed<_A1>::value, bool>::type
+signbit(_A1) _NOEXCEPT
+{ return false; }
+
 #elif defined(_LIBCPP_MSVCRT)
 
 template 
 inline _LIBCPP_INLINE_VISIBILITY
-typename std::enable_if::value, bool>::type
+typename std::enable_if<
+std::is_arithmetic<_A1>::value && !std::is_integral<_A1>::value,
+bool>::type
 

[PATCH] D31167: Use FPContractModeKind universally

2017-04-10 Thread Adam Nemet via Phabricator via cfe-commits
anemet added inline comments.



Comment at: cfe/trunk/include/clang/Basic/LangOptions.def:220
+/// \brief FP_CONTRACT mode (on/off/fast).
+ENUM_LANGOPT(DefaultFPContractMode, FPContractModeKind, 2, FPC_Off, "FP 
contraction type")
 LANGOPT(NoBitFieldTypeAlign , 1, 0, "bit-field type alignment")

yaxunl wrote:
> anemet wrote:
> > yaxunl wrote:
> > > This change seemed to cause some performance degradations in some OpenCL 
> > > applications.
> > > 
> > > This option used to be on by default. Now it is off by default.
> > > 
> > > There are applications do separated compile/link/codegen stages. In the 
> > > codegen stage, clang is invoked with .bc as input, therefore this option 
> > > is off by default, whereas it was on by default before this change.
> > > 
> > > Is there any reason not to keep the original behavior?
> > > 
> > > Thanks.
> > > This change seemed to cause some performance degradations in some OpenCL 
> > > applications.
> > > 
> > > This option used to be on by default. Now it is off by default.
> > 
> > It's always been off.  It was set to fast for CUDA which should still be 
> > the case.  See the changes further down on the patch.
> > 
> > > 
> > > There are applications do separated compile/link/codegen stages. In the 
> > > codegen stage, clang is invoked with .bc as input, therefore this option 
> > > is off by default, whereas it was on by default before this change.
> > > 
> > > Is there any reason not to keep the original behavior?
> > 
> > Sorry but I am not sure what changed, can you elaborate on what you're 
> > doing and how things used to work for you?
> Before your change, -ffp-contract was a codegen option defined as
> 
> 
> ```
> ENUM_CODEGENOPT(FPContractMode, FPContractModeKind, 2, FPC_On)
> ```
> 
> therefore the default value as on. After your change, it becomes off by 
> default.
No. -ffp-contract=on was a FE option and -ffp-contract=fast was a backend 
option.  I still don't understand your use-case.  Can you include a small 
testcase how this used to work before?


Repository:
  rL LLVM

https://reviews.llvm.org/D31167



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


[PATCH] D29877: Warn about unused static file scope function template declarations.

2017-04-10 Thread Richard Smith via Phabricator via cfe-commits
rsmith accepted this revision.
rsmith added a comment.
This revision is now accepted and ready to land.

LGTM with the overloaded operator check removed.


https://reviews.llvm.org/D29877



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


[PATCH] D29877: Warn about unused static file scope function template declarations.

2017-04-10 Thread Richard Smith via Phabricator via cfe-commits
rsmith added inline comments.



Comment at: lib/Sema/Sema.cpp:473
   if (const FunctionDecl *FD = dyn_cast(D)) {
+// If this is a function template and neither of its specs is used, warn.
+if (FunctionTemplateDecl *Template = FD->getDescribedFunctionTemplate())

neither -> none, specs -> specializations ("specs" makes me think 
"specifications").



Comment at: lib/Sema/Sema.cpp:503
+if (VarTemplateDecl *Template = VD->getDescribedVarTemplate())
+  // If this is a variable template and neither of its specs is used, warn.
+  for (const auto *Spec : Template->specializations())

As above.



Comment at: lib/Sema/SemaDecl.cpp:1496
 return false;
+  // 'static operator' functions are defined in headers; don't warn.
+  if (FD->isOverloadedOperator() &&

v.g.vassilev wrote:
> rsmith wrote:
> > Why? Defining a static operator in a header sounds like a bug to me.
> It seems we have some of these here:
> 
> include/llvm/ADT/PointerUnion.h:static bool operator==(PointerUnion 
> lhs, PointerUnion rhs) {
> include/llvm/ADT/PointerUnion.h:static bool operator!=(PointerUnion 
> lhs, PointerUnion rhs) {
> include/llvm/ADT/PointerUnion.h:static bool operator<(PointerUnion 
> lhs, PointerUnion rhs) {
> include/llvm/Transforms/Utils/ValueMapper.h:static inline RemapFlags 
> operator|(RemapFlags LHS, RemapFlags RHS) {
> 
> If that's a bug, I will remove this check.
Yes, those are bugs.


https://reviews.llvm.org/D29877



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


[PATCH] D31627: [coroutines] Skip over passthrough operator co_await

2017-04-10 Thread Gor Nishanov via Phabricator via cfe-commits
GorNishanov added a comment.

gentle ping


https://reviews.llvm.org/D31627



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


[PATCH] D31586: [coroutines] Replace all coro.frame builtins with an SSA value of coro.begin

2017-04-10 Thread Gor Nishanov via Phabricator via cfe-commits
GorNishanov added a comment.

gentle ping


https://reviews.llvm.org/D31586



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


[PATCH] D31590: [coroutines] Add support for deallocation elision

2017-04-10 Thread Gor Nishanov via Phabricator via cfe-commits
GorNishanov added a comment.

Gentle ping


https://reviews.llvm.org/D31590



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


[PATCH] D31608: [coroutines] Add emission of initial and final suspends

2017-04-10 Thread Gor Nishanov via Phabricator via cfe-commits
GorNishanov added a comment.

Pretty please. Gentle ping.


https://reviews.llvm.org/D31608



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


[PATCH] D31584: [coroutines] Add support for allocation elision

2017-04-10 Thread Gor Nishanov via Phabricator via cfe-commits
GorNishanov added a comment.

Gentle ping


https://reviews.llvm.org/D31584



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


[PATCH] D31757: [clang-tidy] Add a clang-tidy check for possible inefficient vector operations

2017-04-10 Thread Haojian Wu via Phabricator via cfe-commits
hokein added inline comments.



Comment at: clang-tidy/performance/InefficientVectorOperationCheck.cpp:22
+void InefficientVectorOperationCheck::registerMatchers(MatchFinder *Finder) {
+  const auto VectorDecl = cxxRecordDecl(hasName("std::vector"));
+  const auto VectorDefaultConstructorCall = cxxConstructExpr(

aaron.ballman wrote:
> Why does this check only focus on vector? Other containers allow you to 
> preallocate space for their elements or lend themselves to inefficient 
> operations.
> 
> Also, this should be checking `::std::vector` instead.
> Why does this check only focus on vector? Other containers allow you to 
> preallocate space for their elements or lend themselves to inefficient 
> operations.

Only a few std containers (`vector`, `unordered_map`, `unorder_set`) provide 
the preallocate ability ("reserve") to users. `vector` is the most widely used 
container with these inefficient operations in the real world. 

Yes, we could extend this check to support other containers, but it will make 
the check more complicated (in the future, I plan to support for-range loops 
and for loops with iterators, and use other  elegant fix-it solutions like 
"range insert" or "range constructor" in some specific cases rather than merely 
inserting `reserve` statements).  So I think it makes more sense to make this 
check only focus on `vector`.




Comment at: clang-tidy/performance/InefficientVectorOperationCheck.cpp:32
+  const auto ReserveCall = cxxMemberCallExpr(
+  callee(cxxMethodDecl(hasName("reserve"))), on(hasType(VectorDecl)));
+  const auto PushBackCall =

aaron.ballman wrote:
> This isn't paying attention to what is being reserved.
Good catch. Added a test for it.



Comment at: clang-tidy/performance/InefficientVectorOperationCheck.cpp:46-50
+  hasCondition(binaryOperator(hasOperatorName("<"),
+  hasLHS(RefersToLoopVar),
+  hasRHS(expr().bind("loop_end_expr",
+  hasIncrement(unaryOperator(hasOperatorName("++"),
+ hasUnaryOperand(RefersToLoopVar))),

aaron.ballman wrote:
> These conditions seem rather restrictive -- why should you not get the same 
> issue with a range-based for loop?
Yeah, this is intended. We want to match typical for-loops with counters here.  
For-range loop will be supported in the future.



Comment at: clang-tidy/performance/InefficientVectorOperationCheck.cpp:53-54
+PushBackCall)),
+  hasParent(compoundStmt(unless(has(ReserveCall)),
+ has(VectorVarDefStmt
+  .bind("for_loop"),

aaron.ballman wrote:
> I'm really not keen on this. It will catch trivial cases, so there is some 
> utility, but this will quickly fall apart with anything past the trivial case.
The motivation of this check is to find code patterns like `for (int i = 0; i < 
n; ++i) { v.push_back(i); }` and clean them in our codebase (we have lots of 
similar cases). 
[These](https://docs.google.com/document/d/1Bbc-6DlNs6zQujWD5-XOHWbfPJVMG7Z_T27Kv0WcFb4/edit?usp=sharing)
 are all cases we want to support. Using `hasParent` is a simple and sufficient 
way to do it IMO.



Comment at: test/clang-tidy/performance-inefficient-vector-operation.cpp:53
+std::vector v;
+v.reserve(20);
+// CHECK-FIXES-NOT: v.reserve(10);

aaron.ballman wrote:
> I'd like to see a test where you reserve 5 elements and then loop for 10 
> elements.
Even for this case, the check will also ignore it.


https://reviews.llvm.org/D31757



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


[PATCH] D31757: [clang-tidy] Add a clang-tidy check for possible inefficient vector operations

2017-04-10 Thread Haojian Wu via Phabricator via cfe-commits
hokein updated this revision to Diff 94734.
hokein marked 7 inline comments as done.
hokein added a comment.

Address review comments.


https://reviews.llvm.org/D31757

Files:
  clang-tidy/performance/CMakeLists.txt
  clang-tidy/performance/InefficientVectorOperationCheck.cpp
  clang-tidy/performance/InefficientVectorOperationCheck.h
  clang-tidy/performance/PerformanceTidyModule.cpp
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/performance-inefficient-vector-operation.rst
  test/clang-tidy/performance-inefficient-vector-operation.cpp

Index: test/clang-tidy/performance-inefficient-vector-operation.cpp
===
--- /dev/null
+++ test/clang-tidy/performance-inefficient-vector-operation.cpp
@@ -0,0 +1,120 @@
+// RUN: %check_clang_tidy %s performance-inefficient-vector-operation %t -- -format-style=llvm --
+
+typedef int size_t;
+
+namespace std {
+template 
+class vector {
+ public:
+  typedef T* iterator;
+  typedef const T* const_iterator;
+  typedef T& reference;
+  typedef const T& const_reference;
+  typedef size_t size_type;
+
+  explicit vector();
+  explicit vector(size_type n);
+
+  void push_back(const T& val);
+  void reserve(size_t n);
+  size_t size();
+  const_reference operator[] (size_type) const;
+  reference operator[] (size_type);
+};
+} // namespace std
+
+void f(std::vector& t) {
+  {
+std::vector v;
+// CHECK-FIXES: v.reserve(10);
+for (int i = 0; i < 10; ++i)
+  v.push_back(i);
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: 'push_back' is called inside a loop; consider pre-allocating the vector capacity before the loop
+  }
+  {
+std::vector v;
+std::vector v2;
+v2.reserve(3);
+// CHECK-FIXES: v.reserve(10);
+for (int i = 0; i < 10; ++i)
+  v.push_back(i);
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: 'push_back' is called
+  }
+  {
+std::vector v;
+// CHECK-FIXES: v.reserve(t.size());
+for (size_t i = 0; i < t.size(); ++i) {
+  v.push_back(t[i]);
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: 'push_back' is called
+}
+  }
+  {
+std::vector v;
+// CHECK-FIXES: v.reserve(t.size() - 1);
+for (size_t i = 0; i < t.size() - 1; ++i) {
+  v.push_back(t[i]);
+} // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: 'push_back' is called
+  }
+
+  //  Non-fixed Cases 
+  {
+std::vector v;
+v.reserve(20);
+// CHECK-FIXES-NOT: v.reserve(10);
+// There is a "reserve" call already.
+for (int i = 0; i < 10; ++i) {
+  v.push_back(i);
+}
+  }
+  {
+std::vector v;
+v.reserve(5);
+// CHECK-FIXES-NOT: v.reserve(10);
+// There is a "reserve" call already.
+for (int i = 0; i < 10; ++i) {
+  v.push_back(i);
+}
+  }
+  {
+std::vector v(20);
+// CHECK-FIXES-NOT: v.reserve(10);
+// v is not constructed with default constructor.
+for (int i = 0; i < 10; ++i) {
+  v.push_back(i);
+}
+  }
+  {
+std::vector v;
+// CHECK-FIXES-NOT: v.reserve(10);
+// For-loop is not started with 0.
+for (int i = 1; i < 10; ++i) {
+  v.push_back(i);
+}
+  }
+  {
+std::vector v;
+// CHECK-FIXES-NOT: v.reserve(t.size());
+// v isn't referenced in for-loop body.
+for (size_t i = 0; i < t.size(); ++i) {
+  t.push_back(i);
+}
+  }
+  {
+std::vector v;
+int k;
+// CHECK-FIXES-NOT: v.reserve(10);
+// For-loop isn't a fixable loop.
+for (size_t i = 0; k < 10; ++i) {
+  v.push_back(t[i]);
+}
+  }
+  {
+std::vector v;
+int k;
+// CHECK-FIXES-NOT: v.reserve(10);
+// For-loop isn't a fixable loop.
+for (size_t i = 0; i < 10; ++k) {
+  v.push_back(t[i]);
+}
+  }
+}
Index: docs/clang-tidy/checks/performance-inefficient-vector-operation.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/performance-inefficient-vector-operation.rst
@@ -0,0 +1,17 @@
+.. title:: clang-tidy - performance-inefficient-vector-operation
+
+performance-inefficient-vector-operation
+
+
+Finds possible inefficient `std::vector` operations (e.g. `push_back`) that may
+cause unnecessary memory reallocations.
+
+.. code-block:: c++
+
+  std::vector v;
+  for (int i = 0; i < n; ++i) {
+v.push_back(n);
+// This will trigger the warning since the push_back may cause multiple
+// memory reallocations in v. This can be avoid by inserting a reserve(n)
+// statment before the for statment.
+  }
Index: docs/clang-tidy/checks/list.rst
===
--- docs/clang-tidy/checks/list.rst
+++ docs/clang-tidy/checks/list.rst
@@ -141,6 +141,7 @@
performance-for-range-copy
performance-implicit-cast-in-loop
performance-inefficient-string-concatenation
+   performance-inefficient-vector-operation
performance-type-promotion-in-math-fn

[PATCH] D22045: [X86] Support of no_caller_saved_registers attribute (Clang part)

2017-04-10 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

There appears to be two reviews out for this same functionality. You should 
probably close one of the reviews (but still address the comments from it).


https://reviews.llvm.org/D22045



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


[PATCH] D31043: Update for lifetime intrinsic signature change

2017-04-10 Thread Matt Arsenault via Phabricator via cfe-commits
arsenm closed this revision.
arsenm added a comment.

r299877


https://reviews.llvm.org/D31043



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


r299877 - Update for lifetime intrinsic signature change

2017-04-10 Thread Matt Arsenault via cfe-commits
Author: arsenm
Date: Mon Apr 10 15:18:45 2017
New Revision: 299877

URL: http://llvm.org/viewvc/llvm-project?rev=299877=rev
Log:
Update for lifetime intrinsic signature change

Modified:
cfe/trunk/lib/CodeGen/CGDecl.cpp
cfe/trunk/test/CodeGen/cleanup-destslot-simple.c
cfe/trunk/test/CodeGen/lifetime-asan.c
cfe/trunk/test/CodeGen/lifetime2.c
cfe/trunk/test/CodeGen/temporary-lifetime-exceptions.cpp
cfe/trunk/test/CodeGen/temporary-lifetime.cpp
cfe/trunk/test/CodeGenCXX/destructors.cpp
cfe/trunk/test/CodeGenCXX/microsoft-abi-eh-cleanups.cpp
cfe/trunk/test/CodeGenCXX/nrvo.cpp
cfe/trunk/test/CodeGenObjC/arc-blocks.m
cfe/trunk/test/CodeGenObjC/arc-precise-lifetime.m
cfe/trunk/test/CodeGenObjC/arc-ternary-op.m
cfe/trunk/test/CodeGenObjC/arc.m
cfe/trunk/test/CodeGenObjC/exceptions.m
cfe/trunk/test/CodeGenObjCXX/arc-move.mm
cfe/trunk/test/CodeGenObjCXX/arc-references.mm
cfe/trunk/test/CodeGenObjCXX/arc.mm
cfe/trunk/test/CodeGenObjCXX/literals.mm

Modified: cfe/trunk/lib/CodeGen/CGDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDecl.cpp?rev=299877=299876=299877=diff
==
--- cfe/trunk/lib/CodeGen/CGDecl.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDecl.cpp Mon Apr 10 15:18:45 2017
@@ -1726,17 +1726,19 @@ void CodeGenFunction::pushRegularPartial
 
 /// Lazily declare the @llvm.lifetime.start intrinsic.
 llvm::Constant *CodeGenModule::getLLVMLifetimeStartFn() {
-  if (LifetimeStartFn) return LifetimeStartFn;
+  if (LifetimeStartFn)
+return LifetimeStartFn;
   LifetimeStartFn = llvm::Intrinsic::getDeclaration((),
-llvm::Intrinsic::lifetime_start);
+llvm::Intrinsic::lifetime_start, Int8PtrTy);
   return LifetimeStartFn;
 }
 
 /// Lazily declare the @llvm.lifetime.end intrinsic.
 llvm::Constant *CodeGenModule::getLLVMLifetimeEndFn() {
-  if (LifetimeEndFn) return LifetimeEndFn;
+  if (LifetimeEndFn)
+return LifetimeEndFn;
   LifetimeEndFn = llvm::Intrinsic::getDeclaration((),
-  llvm::Intrinsic::lifetime_end);
+llvm::Intrinsic::lifetime_end, Int8PtrTy);
   return LifetimeEndFn;
 }
 

Modified: cfe/trunk/test/CodeGen/cleanup-destslot-simple.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/cleanup-destslot-simple.c?rev=299877=299876=299877=diff
==
--- cfe/trunk/test/CodeGen/cleanup-destslot-simple.c (original)
+++ cfe/trunk/test/CodeGen/cleanup-destslot-simple.c Mon Apr 10 15:18:45 2017
@@ -13,9 +13,9 @@ int test() {
   return *p;
 // CHECK: [[X:%.*]] = alloca i32
 // CHECK: [[P:%.*]] = alloca i32*
-// LIFETIME: call void @llvm.lifetime.start(i64 4, i8* nonnull %{{.*}}){{( 
#[0-9]+)?}}, !dbg
-// LIFETIME: call void @llvm.lifetime.start(i64 8, i8* nonnull %{{.*}}){{( 
#[0-9]+)?}}, !dbg
+// LIFETIME: call void @llvm.lifetime.start.p0i8(i64 4, i8* nonnull 
%{{.*}}){{( #[0-9]+)?}}, !dbg
+// LIFETIME: call void @llvm.lifetime.start.p0i8(i64 8, i8* nonnull 
%{{.*}}){{( #[0-9]+)?}}, !dbg
 // CHECK-NOT: store i32 %{{.*}}, i32* %cleanup.dest.slot
-// LIFETIME: call void @llvm.lifetime.end(i64 8, {{.*}}){{( #[0-9]+)?}}, !dbg
-// LIFETIME: call void @llvm.lifetime.end(i64 4, {{.*}}){{( #[0-9]+)?}}, !dbg
+// LIFETIME: call void @llvm.lifetime.end.p0i8(i64 8, {{.*}}){{( #[0-9]+)?}}, 
!dbg
+// LIFETIME: call void @llvm.lifetime.end.p0i8(i64 4, {{.*}}){{( #[0-9]+)?}}, 
!dbg
 }

Modified: cfe/trunk/test/CodeGen/lifetime-asan.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/lifetime-asan.c?rev=299877=299876=299877=diff
==
--- cfe/trunk/test/CodeGen/lifetime-asan.c (original)
+++ cfe/trunk/test/CodeGen/lifetime-asan.c Mon Apr 10 15:18:45 2017
@@ -8,14 +8,14 @@ extern int bar(char *A, int n);
 // CHECK-O0-NOT: @llvm.lifetime.start
 int foo(int n) {
   if (n) {
-// CHECK-ASAN-USE-AFTER-SCOPE: @llvm.lifetime.start(i64 10, i8* {{.*}})
+// CHECK-ASAN-USE-AFTER-SCOPE: @llvm.lifetime.start.p0i8(i64 10, i8* 
{{.*}})
 char A[10];
 return bar(A, 1);
-// CHECK-ASAN-USE-AFTER-SCOPE: @llvm.lifetime.end(i64 10, i8* {{.*}})
+// CHECK-ASAN-USE-AFTER-SCOPE: @llvm.lifetime.end.p0i8(i64 10, i8* {{.*}})
   } else {
-// CHECK-ASAN-USE-AFTER-SCOPE: @llvm.lifetime.start(i64 20, i8* {{.*}})
+// CHECK-ASAN-USE-AFTER-SCOPE: @llvm.lifetime.start.p0i8(i64 20, i8* 
{{.*}})
 char A[20];
 return bar(A, 2);
-// CHECK-ASAN-USE-AFTER-SCOPE: @llvm.lifetime.end(i64 20, i8* {{.*}})
+// CHECK-ASAN-USE-AFTER-SCOPE: @llvm.lifetime.end.p0i8(i64 20, i8* {{.*}})
   }
 }

Modified: cfe/trunk/test/CodeGen/lifetime2.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/lifetime2.c?rev=299877=299876=299877=diff

[PATCH] D31167: Use FPContractModeKind universally

2017-04-10 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added inline comments.



Comment at: cfe/trunk/lib/Frontend/CompilerInvocation.cpp:1638
 Opts.LaxVectorConversions = 0;
-Opts.DefaultFPContract = 1;
+Opts.setDefaultFPContractMode(LangOptions::FPC_On);
 Opts.NativeHalfType = 1;

hfinkel wrote:
> yaxunl wrote:
> > hfinkel wrote:
> > > Looks like the intent is certainly to have kept the OpenCL default the 
> > > same here.
> > Well we also use clang to compile LLVM IR to ISA. Before this change, 
> > fp-contract was on so that backend did fp contract. However, now clang does 
> > not turn on fp-contract when compiling LLVM IRs.
> That's the equivalent of 'Fast'. Maybe this should also be set to Fast then.
Agree. That should fix this issue.


Repository:
  rL LLVM

https://reviews.llvm.org/D31167



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


[PATCH] D31167: Use FPContractModeKind universally

2017-04-10 Thread Hal Finkel via Phabricator via cfe-commits
hfinkel added inline comments.



Comment at: cfe/trunk/lib/Frontend/CompilerInvocation.cpp:1638
 Opts.LaxVectorConversions = 0;
-Opts.DefaultFPContract = 1;
+Opts.setDefaultFPContractMode(LangOptions::FPC_On);
 Opts.NativeHalfType = 1;

yaxunl wrote:
> hfinkel wrote:
> > Looks like the intent is certainly to have kept the OpenCL default the same 
> > here.
> Well we also use clang to compile LLVM IR to ISA. Before this change, 
> fp-contract was on so that backend did fp contract. However, now clang does 
> not turn on fp-contract when compiling LLVM IRs.
That's the equivalent of 'Fast'. Maybe this should also be set to Fast then.


Repository:
  rL LLVM

https://reviews.llvm.org/D31167



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


[PATCH] D31860: Add more examples to clang tidy checkers

2017-04-10 Thread Alexander Kornienko via Phabricator via cfe-commits
alexfh accepted this revision.
alexfh added a comment.
This revision is now accepted and ready to land.

Thanks!

LG with a couple of nits.




Comment at: docs/clang-tidy/checks/misc-inefficient-algorithm.rst:25
+  std::set s;
+  auto c = count(s.begin(), s.end(), 43);
+

std::count



Comment at: docs/clang-tidy/checks/misc-unused-parameters.rst:25
+
+  static void staticFunctionA()

The example seems incomplete?


https://reviews.llvm.org/D31860



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


[PATCH] D31853: [clangd] Implement item kind for completion results

2017-04-10 Thread Stanislav Ionascu via Phabricator via cfe-commits
stanionascu added a comment.

In https://reviews.llvm.org/D31853#722219, @krasimir wrote:

> Looks good! However it would be easier for reviewers if you could please use 
> arc: http://llvm.org/docs/Phabricator.html#id2
>  This makes it easy since I only have to do `arc patch D31853` in order to 
> update my client source tree with your changes.
>  Could you please create a review like that?


I did use arc diff to upload this patch, from my git clone as described in 
http://llvm.org/docs/GettingStarted.html#developers-work-with-git-svn
I've recreated the clone now and the `arc patch D31853`  seems to work for both 
git+svn/svn clones.
Sorry if my setup was causing issues.


https://reviews.llvm.org/D31853



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


[PATCH] D31885: Remove TBAA information from LValues representing union members

2017-04-10 Thread Krzysztof Parzyszek via Phabricator via cfe-commits
kparzysz updated this revision to Diff 94721.
kparzysz added a comment.

Cleaned the code up, added testcases.


Repository:
  rL LLVM

https://reviews.llvm.org/D31885

Files:
  lib/CodeGen/CGExpr.cpp
  lib/CodeGen/CodeGenFunction.h
  test/CodeGen/union-tbaa1.c
  test/CodeGenCXX/union-tbaa2.cpp

Index: test/CodeGenCXX/union-tbaa2.cpp
===
--- /dev/null
+++ test/CodeGenCXX/union-tbaa2.cpp
@@ -0,0 +1,41 @@
+// RUN: %clang_cc1 %s -triple x86_64-unknown-linux-gnu -target-cpu x86-64 -target-feature +sse4.2 -target-feature +avx -emit-llvm -o -
+
+// Testcase from llvm.org/PR32056
+
+extern "C" int printf (const char *__restrict __format, ...);
+
+typedef double __m256d __attribute__((__vector_size__(32)));
+
+static __inline __m256d __attribute__((__always_inline__, __nodebug__,
+   __target__("avx")))
+_mm256_setr_pd(double __a, double __b, double __c, double __d) {
+  return (__m256d){ __a, __b, __c, __d };
+}
+
+struct A {
+  A () {
+// Check that there is no TBAA information generated for the stores to the
+// union members:
+// CHECK: store <4 x double>
+// CHECK-NOT: tbaa
+// CHECK: store <4 x double>
+// CHECK-NOT: tbaa
+a = _mm256_setr_pd(0.0, 1.0, 2.0, 3.0);
+b = _mm256_setr_pd(4.0, 5.0, 6.0, 7.0);
+  }
+
+  const double *begin() { return c; }
+  const double *end() { return c+8; }
+
+  union {
+struct { __m256d a, b; };
+double c[8];
+  };
+};
+
+int main(int argc, char *argv[]) {
+  A a;
+  for (double value : a)
+printf("%f ", value);
+  return 0;
+}
Index: test/CodeGen/union-tbaa1.c
===
--- /dev/null
+++ test/CodeGen/union-tbaa1.c
@@ -0,0 +1,37 @@
+// RUN: %clang_cc1 %s -triple hexagon-unknown-elf -O2 -emit-llvm -o -
+
+typedef union __attribute__((aligned(4))) {
+  unsigned short uh[2];
+  unsigned uw;
+} vect32;
+
+void bar(vect32 p[][2]);
+
+// CHECK-LABEL: define void @fred
+void fred(unsigned Num, int Vec[2], int *Index, int Arr[4][2]) {
+  vect32 Tmp[4][2];
+// Generate tbaa for the load of Index:
+// CHECK: load i32, i32* %Index{{.*}}tbaa
+// But no tbaa for the two stores:
+// CHECK: %uw[UW1:[0-9]*]] = getelementptr
+// CHECK: store{{.*}}%uw[[UW1]]
+// CHECK-NOT: tbaa
+  Tmp[*Index][0].uw = Arr[*Index][0] * Num;
+// CHECK: %uw[UW2:[0-9]*]] = getelementptr
+// CHECK: store{{.*}}%uw[[UW1]]
+// CHECK-NOT: tbaa
+  Tmp[*Index][1].uw = Arr[*Index][1] * Num;
+// Same here, don't generate tbaa for the loads:
+// CHECK: %uh[[UH1:[0-9]*]] = bitcast %union.vect32
+// CHECK: %arrayidx[[AX1:[0-9]*]] = getelementptr{{.*}}%uh[[UH1]
+// CHECK: load i16, i16* %arrayidx[[AX1]]
+// CHECK-NOT: tbaa
+  Vec[0] = Tmp[*Index][0].uh[1];
+// CHECK: %uh[[UH2:[0-9]*]] = bitcast %union.vect32
+// CHECK: %arrayidx[[AX2:[0-9]*]] = getelementptr{{.*}}%uh[[UH2]
+// CHECK: load i16, i16* %arrayidx[[AX2]]
+// CHECK-NOT: tbaa
+  Vec[1] = Tmp[*Index][1].uh[1];
+  bar(Tmp);
+}
+
Index: lib/CodeGen/CodeGenFunction.h
===
--- lib/CodeGen/CodeGenFunction.h
+++ lib/CodeGen/CodeGenFunction.h
@@ -2886,6 +2886,17 @@
   /// that the address will be used to access the object.
   LValue EmitCheckedLValue(const Expr *E, TypeCheckKind TCK);
 
+private:
+  /// The actual implementations of LValue emission. As a workaround for
+  /// a problem in representing union member accesses in TBAA, the public
+  /// functions will remove the TBAA information from any LValue generated
+  /// for such an access.
+  /// When the TBAA issue is fixed, the public wrappers (declared above)
+  /// should be replaced with these functions.
+  LValue EmitLValueImpl(const Expr *E);
+  LValue EmitCheckedLValueImpl(const Expr *E, TypeCheckKind TCK);
+
+public:
   RValue convertTempToRValue(Address addr, QualType type,
  SourceLocation Loc);
 
Index: lib/CodeGen/CGExpr.cpp
===
--- lib/CodeGen/CGExpr.cpp
+++ lib/CodeGen/CGExpr.cpp
@@ -979,7 +979,37 @@
   return true;
 }
 
+/// Hacks to remove TBAA information from LValues that represent union members.
+/// The TBAA in the current form does not work for union members: the aliasing
+/// information emitted in such cases may be incorrect (leading to incorrect
+/// optimizations).
+static bool isUnionAccess(const Expr *E) {
+  switch (E->getStmtClass()) {
+case Stmt::MemberExprClass: {
+  const Expr *BE = cast(E)->getBase();
+  if (BE->getType()->isUnionType())
+return true;
+  return isUnionAccess(BE);
+}
+case Stmt::ImplicitCastExprClass:
+  return isUnionAccess(cast(E)->getSubExpr());
+case Stmt::ArraySubscriptExprClass:
+  return isUnionAccess(cast(E)->getBase());
+default:
+  break;
+  }
+  return false;
+}
+
 LValue CodeGenFunction::EmitCheckedLValue(const Expr *E, TypeCheckKind TCK) {
+  LValue LV = EmitCheckedLValueImpl(E, TCK);

[PATCH] D31853: [clangd] Implement item kind for completion results

2017-04-10 Thread Stanislav Ionascu via Phabricator via cfe-commits
stanionascu updated this revision to Diff 94720.
stanionascu added a comment.

One more try updating the revision on fresh git+svn clone.


https://reviews.llvm.org/D31853

Files:
  clangd/ASTManager.cpp
  clangd/Protocol.cpp
  test/clangd/completion.test

Index: test/clangd/completion.test
===
--- test/clangd/completion.test
+++ test/clangd/completion.test
@@ -16,9 +16,9 @@
 # nondeterministic, so we check regardless of order.
 #
 # CHECK: {"jsonrpc":"2.0","id":1,"result":[
-# CHECK-DAG: {"label":"a"}
-# CHECK-DAG: {"label":"bb"}
-# CHECK-DAG: {"label":"ccc"}
+# CHECK-DAG: {"label":"a","kind":5}
+# CHECK-DAG: {"label":"bb","kind":5}
+# CHECK-DAG: {"label":"ccc","kind":5}
 # CHECK: ]}
 Content-Length: 44
 
Index: clangd/Protocol.cpp
===
--- clangd/Protocol.cpp
+++ clangd/Protocol.cpp
@@ -672,7 +672,7 @@
   assert(!CI.label.empty() && "completion item label is required");
   Os << R"("label":")" << llvm::yaml::escape(CI.label) << R"(",)";
   if (CI.kind != CompletionItemKind::Missing)
-Os << R"("kind":)" << static_cast(CI.kind) << R"(",)";
+Os << R"("kind":)" << static_cast(CI.kind) << R"(,)";
   if (!CI.detail.empty())
 Os << R"("detail":")" << llvm::yaml::escape(CI.detail) << R"(",)";
   if (!CI.documentation.empty())
Index: clangd/ASTManager.cpp
===
--- clangd/ASTManager.cpp
+++ clangd/ASTManager.cpp
@@ -76,6 +76,49 @@
   llvm_unreachable("Unknown diagnostic level!");
 }
 
+static CompletionItemKind getKind(CXCursorKind K) {
+  switch (K) {
+  case CXCursor_MacroInstantiation:
+  case CXCursor_MacroDefinition:
+return CompletionItemKind::Text;
+  case CXCursor_CXXMethod:
+return CompletionItemKind::Method;
+  case CXCursor_FunctionDecl:
+  case CXCursor_FunctionTemplate:
+return CompletionItemKind::Function;
+  case CXCursor_Constructor:
+  case CXCursor_Destructor:
+return CompletionItemKind::Constructor;
+  case CXCursor_FieldDecl:
+return CompletionItemKind::Field;
+  case CXCursor_VarDecl:
+  case CXCursor_ParmDecl:
+return CompletionItemKind::Variable;
+  case CXCursor_ClassDecl:
+  case CXCursor_StructDecl:
+  case CXCursor_UnionDecl:
+  case CXCursor_ClassTemplate:
+  case CXCursor_ClassTemplatePartialSpecialization:
+return CompletionItemKind::Class;
+  case CXCursor_Namespace:
+  case CXCursor_NamespaceAlias:
+  case CXCursor_NamespaceRef:
+return CompletionItemKind::Module;
+  case CXCursor_EnumConstantDecl:
+return CompletionItemKind::Value;
+  case CXCursor_EnumDecl:
+return CompletionItemKind::Enum;
+  case CXCursor_TypeAliasDecl:
+  case CXCursor_TypeAliasTemplateDecl:
+  case CXCursor_TypedefDecl:
+  case CXCursor_MemberRef:
+  case CXCursor_TypeRef:
+return CompletionItemKind::Reference;
+  default:
+return CompletionItemKind::Missing;
+  }
+}
+
 ASTManager::ASTManager(JSONOutput , DocumentStore ,
bool RunSynchronously)
 : Output(Output), Store(Store), RunSynchronously(RunSynchronously),
@@ -334,13 +377,15 @@
   CodeCompletionResult *Results,
   unsigned NumResults) override {
 for (unsigned I = 0; I != NumResults; ++I) {
-  CodeCompletionString *CCS = Results[I].CreateCodeCompletionString(
+  CodeCompletionResult  = Results[I];
+  CodeCompletionString *CCS = Result.CreateCodeCompletionString(
   S, Context, *Allocator, CCTUInfo,
   CodeCompleteOpts.IncludeBriefComments);
   if (CCS) {
 CompletionItem Item;
 assert(CCS->getTypedText());
 Item.label = CCS->getTypedText();
+Item.kind = getKind(Result.CursorKind);
 if (CCS->getBriefComment())
   Item.documentation = CCS->getBriefComment();
 Items->push_back(std::move(Item));
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D31167: Use FPContractModeKind universally

2017-04-10 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added inline comments.



Comment at: cfe/trunk/lib/Frontend/CompilerInvocation.cpp:1638
 Opts.LaxVectorConversions = 0;
-Opts.DefaultFPContract = 1;
+Opts.setDefaultFPContractMode(LangOptions::FPC_On);
 Opts.NativeHalfType = 1;

hfinkel wrote:
> Looks like the intent is certainly to have kept the OpenCL default the same 
> here.
Well we also use clang to compile LLVM IR to ISA. Before this change, 
fp-contract was on so that backend did fp contract. However, now clang does not 
turn on fp-contract when compiling LLVM IRs.


Repository:
  rL LLVM

https://reviews.llvm.org/D31167



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


[PATCH] D31167: Use FPContractModeKind universally

2017-04-10 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added inline comments.



Comment at: cfe/trunk/include/clang/Basic/LangOptions.def:220
+/// \brief FP_CONTRACT mode (on/off/fast).
+ENUM_LANGOPT(DefaultFPContractMode, FPContractModeKind, 2, FPC_Off, "FP 
contraction type")
 LANGOPT(NoBitFieldTypeAlign , 1, 0, "bit-field type alignment")

anemet wrote:
> yaxunl wrote:
> > This change seemed to cause some performance degradations in some OpenCL 
> > applications.
> > 
> > This option used to be on by default. Now it is off by default.
> > 
> > There are applications do separated compile/link/codegen stages. In the 
> > codegen stage, clang is invoked with .bc as input, therefore this option is 
> > off by default, whereas it was on by default before this change.
> > 
> > Is there any reason not to keep the original behavior?
> > 
> > Thanks.
> > This change seemed to cause some performance degradations in some OpenCL 
> > applications.
> > 
> > This option used to be on by default. Now it is off by default.
> 
> It's always been off.  It was set to fast for CUDA which should still be the 
> case.  See the changes further down on the patch.
> 
> > 
> > There are applications do separated compile/link/codegen stages. In the 
> > codegen stage, clang is invoked with .bc as input, therefore this option is 
> > off by default, whereas it was on by default before this change.
> > 
> > Is there any reason not to keep the original behavior?
> 
> Sorry but I am not sure what changed, can you elaborate on what you're doing 
> and how things used to work for you?
Before your change, -ffp-contract was a codegen option defined as


```
ENUM_CODEGENOPT(FPContractMode, FPContractModeKind, 2, FPC_On)
```

therefore the default value as on. After your change, it becomes off by default.


Repository:
  rL LLVM

https://reviews.llvm.org/D31167



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


[PATCH] D31167: Use FPContractModeKind universally

2017-04-10 Thread Hal Finkel via Phabricator via cfe-commits
hfinkel added inline comments.



Comment at: cfe/trunk/lib/Frontend/CompilerInvocation.cpp:1638
 Opts.LaxVectorConversions = 0;
-Opts.DefaultFPContract = 1;
+Opts.setDefaultFPContractMode(LangOptions::FPC_On);
 Opts.NativeHalfType = 1;

Looks like the intent is certainly to have kept the OpenCL default the same 
here.


Repository:
  rL LLVM

https://reviews.llvm.org/D31167



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


r299868 - [OPENMP] Fix for PR32333: Crash in call of outlined Function.

2017-04-10 Thread Alexey Bataev via cfe-commits
Author: abataev
Date: Mon Apr 10 14:16:45 2017
New Revision: 299868

URL: http://llvm.org/viewvc/llvm-project?rev=299868=rev
Log:
[OPENMP] Fix for PR32333: Crash in call of outlined Function.

If the type of the captured variable is a pointer(s) to variably
modified type, this type was not processed correctly. Need to drill into
the type, find the innermost variably modified array type and convert it
to canonical parameter type.

Added:
cfe/trunk/test/OpenMP/vla_crash.c
Modified:
cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp

Modified: cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp?rev=299868=299867=299868=diff
==
--- cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp Mon Apr 10 14:16:45 2017
@@ -227,6 +227,17 @@ static Address castValueFromUintptr(Code
   return TmpAddr;
 }
 
+static QualType getCanonicalParamType(ASTContext , QualType T) {
+  if (T->isLValueReferenceType()) {
+return C.getLValueReferenceType(
+getCanonicalParamType(C, T.getNonReferenceType()),
+/*SpelledAsLValue=*/false);
+  }
+  if (T->isPointerType())
+return C.getPointerType(getCanonicalParamType(C, T->getPointeeType()));
+  return C.getCanonicalParamType(T);
+}
+
 llvm::Function *
 CodeGenFunction::GenerateOpenMPCapturedStmtFunction(const CapturedStmt ) {
   assert(
@@ -266,13 +277,8 @@ CodeGenFunction::GenerateOpenMPCapturedS
   II = ().Idents.get("vla");
 }
 if (ArgType->isVariablyModifiedType()) {
-  bool IsReference = ArgType->isLValueReferenceType();
   ArgType =
-  getContext().getCanonicalParamType(ArgType.getNonReferenceType());
-  if (IsReference && !ArgType->isPointerType()) {
-ArgType = getContext().getLValueReferenceType(
-ArgType, /*SpelledAsLValue=*/false);
-  }
+  getCanonicalParamType(getContext(), ArgType.getNonReferenceType());
 }
 Args.push_back(ImplicitParamDecl::Create(getContext(), nullptr,
  FD->getLocation(), II, ArgType));

Added: cfe/trunk/test/OpenMP/vla_crash.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/vla_crash.c?rev=299868=auto
==
--- cfe/trunk/test/OpenMP/vla_crash.c (added)
+++ cfe/trunk/test/OpenMP/vla_crash.c Mon Apr 10 14:16:45 2017
@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 -verify -triple powerpc64le-unknown-linux-gnu -fopenmp -x c 
-emit-llvm %s -o - | FileCheck %s
+// expected-no-diagnostics
+
+int a;
+
+// CHECK-LABEL: foo
+void foo() {
+  int(*b)[a];
+  int *(**c)[a];
+  // CHECK: [[B:%.+]] = alloca i32*,
+  // CHECK: [[C:%.+]] = alloca i32***,
+  // CHECK: @__kmpc_global_thread_num
+  // CHECK: call void @__kmpc_serialized_parallel
+  // CHECK: call void [[OUTLINED:@[^(]+]](i32* %{{[^,]+}}, i32* %{{[^,]+}}, 
i64 %{{[^,]+}}, i32** [[B]], i64 %{{[^,]+}}, i32 [[C]])
+  // CHECK: call void @__kmpc_end_serialized_parallel
+  // CHECK: ret void
+#pragma omp parallel if (0)
+  b[0][0] = c[0][a][0][a];
+}
+
+// CHECK: define internal void [[OUTLINED]](i32* {{[^,]+}}, i32* {{[^,]+}}, 
i64 {{[^,]+}}, i32** {{[^,]+}}, i64 {{[^,]+}}, i32 {{[^,]+}})
+


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


[PATCH] D31561: cmath: Skip Libc for integral types in isinf, etc.

2017-04-10 Thread Hal Finkel via Phabricator via cfe-commits
hfinkel added inline comments.



Comment at: libcxx/include/math.h:354
 inline _LIBCPP_INLINE_VISIBILITY
-typename std::enable_if::value, bool>::type
+typename std::enable_if::value, bool>::type
 signbit(_A1 __lcpp_x) _NOEXCEPT

I think that it would be safer / easier to understand if we used 
!std::is_integral here. It is true for all standard types that 
std::is_arithmetic implies is_integral or is_floating_point, but it seems 
likely that some implementations have arithemtic types that are neither (e.g. 
fixed-point types), and user-defined types seem likely.



Comment at: libcxx/include/math.h:400
+inline _LIBCPP_INLINE_VISIBILITY
+typename std::enable_if::value, int>::type
+fpclassify(_A1 __lcpp_x) _NOEXCEPT

Maybe we should predicate this, and other infinity-related functions, on 
std::numeric_limits<_A1>::has_infinity. That seems more general, and safer for 
potential user-defined types.


https://reviews.llvm.org/D31561



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


[PATCH] D31167: Use FPContractModeKind universally

2017-04-10 Thread Adam Nemet via Phabricator via cfe-commits
anemet added inline comments.



Comment at: cfe/trunk/include/clang/Basic/LangOptions.def:220
+/// \brief FP_CONTRACT mode (on/off/fast).
+ENUM_LANGOPT(DefaultFPContractMode, FPContractModeKind, 2, FPC_Off, "FP 
contraction type")
 LANGOPT(NoBitFieldTypeAlign , 1, 0, "bit-field type alignment")

yaxunl wrote:
> This change seemed to cause some performance degradations in some OpenCL 
> applications.
> 
> This option used to be on by default. Now it is off by default.
> 
> There are applications do separated compile/link/codegen stages. In the 
> codegen stage, clang is invoked with .bc as input, therefore this option is 
> off by default, whereas it was on by default before this change.
> 
> Is there any reason not to keep the original behavior?
> 
> Thanks.
> This change seemed to cause some performance degradations in some OpenCL 
> applications.
> 
> This option used to be on by default. Now it is off by default.

It's always been off.  It was set to fast for CUDA which should still be the 
case.  See the changes further down on the patch.

> 
> There are applications do separated compile/link/codegen stages. In the 
> codegen stage, clang is invoked with .bc as input, therefore this option is 
> off by default, whereas it was on by default before this change.
> 
> Is there any reason not to keep the original behavior?

Sorry but I am not sure what changed, can you elaborate on what you're doing 
and how things used to work for you?


Repository:
  rL LLVM

https://reviews.llvm.org/D31167



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


[PATCH] D31853: [clangd] Implement item kind for completion results

2017-04-10 Thread Stanislav Ionascu via Phabricator via cfe-commits
stanionascu updated this revision to Diff 94716.
stanionascu added a comment.

recreated from svn checkout


https://reviews.llvm.org/D31853

Files:
  clangd/ASTManager.cpp
  clangd/Protocol.cpp
  test/clangd/completion.test

Index: test/clangd/completion.test
===
--- test/clangd/completion.test
+++ test/clangd/completion.test
@@ -16,9 +16,9 @@
 # nondeterministic, so we check regardless of order.
 #
 # CHECK: {"jsonrpc":"2.0","id":1,"result":[
-# CHECK-DAG: {"label":"a"}
-# CHECK-DAG: {"label":"bb"}
-# CHECK-DAG: {"label":"ccc"}
+# CHECK-DAG: {"label":"a","kind":5}
+# CHECK-DAG: {"label":"bb","kind":5}
+# CHECK-DAG: {"label":"ccc","kind":5}
 # CHECK: ]}
 Content-Length: 44
 
Index: clangd/Protocol.cpp
===
--- clangd/Protocol.cpp
+++ clangd/Protocol.cpp
@@ -672,7 +672,7 @@
   assert(!CI.label.empty() && "completion item label is required");
   Os << R"("label":")" << llvm::yaml::escape(CI.label) << R"(",)";
   if (CI.kind != CompletionItemKind::Missing)
-Os << R"("kind":)" << static_cast(CI.kind) << R"(",)";
+Os << R"("kind":)" << static_cast(CI.kind) << R"(,)";
   if (!CI.detail.empty())
 Os << R"("detail":")" << llvm::yaml::escape(CI.detail) << R"(",)";
   if (!CI.documentation.empty())
Index: clangd/ASTManager.cpp
===
--- clangd/ASTManager.cpp
+++ clangd/ASTManager.cpp
@@ -76,6 +76,49 @@
   llvm_unreachable("Unknown diagnostic level!");
 }
 
+static CompletionItemKind getKind(CXCursorKind K) {
+  switch (K) {
+  case CXCursor_MacroInstantiation:
+  case CXCursor_MacroDefinition:
+return CompletionItemKind::Text;
+  case CXCursor_CXXMethod:
+return CompletionItemKind::Method;
+  case CXCursor_FunctionDecl:
+  case CXCursor_FunctionTemplate:
+return CompletionItemKind::Function;
+  case CXCursor_Constructor:
+  case CXCursor_Destructor:
+return CompletionItemKind::Constructor;
+  case CXCursor_FieldDecl:
+return CompletionItemKind::Field;
+  case CXCursor_VarDecl:
+  case CXCursor_ParmDecl:
+return CompletionItemKind::Variable;
+  case CXCursor_ClassDecl:
+  case CXCursor_StructDecl:
+  case CXCursor_UnionDecl:
+  case CXCursor_ClassTemplate:
+  case CXCursor_ClassTemplatePartialSpecialization:
+return CompletionItemKind::Class;
+  case CXCursor_Namespace:
+  case CXCursor_NamespaceAlias:
+  case CXCursor_NamespaceRef:
+return CompletionItemKind::Module;
+  case CXCursor_EnumConstantDecl:
+return CompletionItemKind::Value;
+  case CXCursor_EnumDecl:
+return CompletionItemKind::Enum;
+  case CXCursor_TypeAliasDecl:
+  case CXCursor_TypeAliasTemplateDecl:
+  case CXCursor_TypedefDecl:
+  case CXCursor_MemberRef:
+  case CXCursor_TypeRef:
+return CompletionItemKind::Reference;
+  default:
+return CompletionItemKind::Missing;
+  }
+}
+
 ASTManager::ASTManager(JSONOutput , DocumentStore ,
bool RunSynchronously)
 : Output(Output), Store(Store), RunSynchronously(RunSynchronously),
@@ -334,13 +377,15 @@
   CodeCompletionResult *Results,
   unsigned NumResults) override {
 for (unsigned I = 0; I != NumResults; ++I) {
-  CodeCompletionString *CCS = Results[I].CreateCodeCompletionString(
+  CodeCompletionResult  = Results[I];
+  CodeCompletionString *CCS = Result.CreateCodeCompletionString(
   S, Context, *Allocator, CCTUInfo,
   CodeCompleteOpts.IncludeBriefComments);
   if (CCS) {
 CompletionItem Item;
 assert(CCS->getTypedText());
 Item.label = CCS->getTypedText();
+Item.kind = getKind(Result.CursorKind);
 if (CCS->getBriefComment())
   Item.documentation = CCS->getBriefComment();
 Items->push_back(std::move(Item));
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D31840: [analyzer] Fix crash on access to property

2017-04-10 Thread Alexander Shaposhnikov via Phabricator via cfe-commits
alexshap updated this revision to Diff 94713.
alexshap added a comment.

1. update the patch following NoQ@ suggestion
2. rerun the tests: make check-all - they are green


Repository:
  rL LLVM

https://reviews.llvm.org/D31840

Files:
  lib/StaticAnalyzer/Core/CallEvent.cpp
  test/Analysis/properties.m


Index: test/Analysis/properties.m
===
--- test/Analysis/properties.m
+++ test/Analysis/properties.m
@@ -987,5 +987,21 @@
 }
 
 @end
+
+@interface Wrapper
+@property(nonatomic, readonly) int value;
+@end
+
+@implementation Wrapper
+@synthesize value;
+@end
+
+void testNoCrashWhenAccessPropertyAndThereAreNoDirectBindingsAtAll() {
+   union {
+Wrapper *wrapper;
+   } u = { 0 };
+   [u.wrapper value];
+}
+
 #endif // non-ARC
 
Index: lib/StaticAnalyzer/Core/CallEvent.cpp
===
--- lib/StaticAnalyzer/Core/CallEvent.cpp
+++ lib/StaticAnalyzer/Core/CallEvent.cpp
@@ -695,13 +695,15 @@
   if (const ObjCPropertyDecl *PropDecl = getAccessedProperty()) {
 if (const ObjCIvarDecl *PropIvar = PropDecl->getPropertyIvarDecl()) {
   SVal IvarLVal = getState()->getLValue(PropIvar, getReceiverSVal());
-  const MemRegion *IvarRegion = IvarLVal.getAsRegion();
-  ETraits->setTrait(
+  if (const MemRegion *IvarRegion = IvarLVal.getAsRegion()) {
+ETraits->setTrait(
   IvarRegion,
   RegionAndSymbolInvalidationTraits::TK_DoNotInvalidateSuperRegion);
-  ETraits->setTrait(IvarRegion,
-RegionAndSymbolInvalidationTraits::TK_SuppressEscape);
-  Values.push_back(IvarLVal);
+ETraits->setTrait(
+  IvarRegion,
+  RegionAndSymbolInvalidationTraits::TK_SuppressEscape);
+Values.push_back(IvarLVal);
+  }
   return;
 }
   }


Index: test/Analysis/properties.m
===
--- test/Analysis/properties.m
+++ test/Analysis/properties.m
@@ -987,5 +987,21 @@
 }
 
 @end
+
+@interface Wrapper
+@property(nonatomic, readonly) int value;
+@end
+
+@implementation Wrapper
+@synthesize value;
+@end
+
+void testNoCrashWhenAccessPropertyAndThereAreNoDirectBindingsAtAll() {
+   union {
+Wrapper *wrapper;
+   } u = { 0 };
+   [u.wrapper value];
+}
+
 #endif // non-ARC
 
Index: lib/StaticAnalyzer/Core/CallEvent.cpp
===
--- lib/StaticAnalyzer/Core/CallEvent.cpp
+++ lib/StaticAnalyzer/Core/CallEvent.cpp
@@ -695,13 +695,15 @@
   if (const ObjCPropertyDecl *PropDecl = getAccessedProperty()) {
 if (const ObjCIvarDecl *PropIvar = PropDecl->getPropertyIvarDecl()) {
   SVal IvarLVal = getState()->getLValue(PropIvar, getReceiverSVal());
-  const MemRegion *IvarRegion = IvarLVal.getAsRegion();
-  ETraits->setTrait(
+  if (const MemRegion *IvarRegion = IvarLVal.getAsRegion()) {
+ETraits->setTrait(
   IvarRegion,
   RegionAndSymbolInvalidationTraits::TK_DoNotInvalidateSuperRegion);
-  ETraits->setTrait(IvarRegion,
-RegionAndSymbolInvalidationTraits::TK_SuppressEscape);
-  Values.push_back(IvarLVal);
+ETraits->setTrait(
+  IvarRegion,
+  RegionAndSymbolInvalidationTraits::TK_SuppressEscape);
+Values.push_back(IvarLVal);
+  }
   return;
 }
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D31839: make -Winteger-overflow find overflows in function arguments

2017-04-10 Thread Akira Hatanaka via Phabricator via cfe-commits
ahatanak added a comment.

Is it possible to fix ObjCMessageExpr too while you are in here?

I think clang should issue a warning when compiling the following code:

  @protocol NSObject
  @end
  
  @interface NSObject
  @end
  
  @interface C1 : NSObject
  - (void)foo:(int)i;
  @end
  @implementation C1
  - (void)foo:(int)i {
  }
  @end
  
  void test1(C1 *c) {
[c foo:(4068 * 1024 * 1024)];
  }


https://reviews.llvm.org/D31839



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


[PATCH] D30489: [analyzer] catch out of bounds for VLA

2017-04-10 Thread Daniel Marjamäki via Phabricator via cfe-commits
danielmarjamaki updated this revision to Diff 94509.
danielmarjamaki added a comment.

This is just work in progress!!

With these changes Clang static analyzer will detect overflow in this sample 
code:

  void foo(int X) {
char *Data = new char[X];
Data[X] = 0; // <- error
delete[] Data;
  }

I updated SimpleSValBuilder so evalEQ can calculate a SVal when both lhs and 
rhs are symbols. Source code that used to have problems:

  DefinedOrUnknownSVal extentMatchesSize = svalBuilder.evalEQ(
  State, Extent, SizeInBytes.castAs());

Inputs: Extent is "extent_$3{SymRegion{conj_$1{char *}}}" and SizeInBytes is 
"reg_$0".

Before my quick fix the return SVal is "Unknown".
With my quick fix it will return a SVal "(extent_$3{SymRegion{conj_$1{char 
*}}}) == (reg_$0)".

I also made a simple fix for the ConstraintManager. If the state says X==Y then 
the ConstraintManager should be able to evaluate Y>=X. My evalUgly loops 
through the constraints and matches them manually.

Do you have some feedback? Do you think my SimpleSValBuilder approach is fine 
to commit if I polish it? It was just a quick hack so I guess it might make 
some tests fail etc.

About the ConstraintManager fix. Is it a good idea to handle simple SymSymExpr 
constraints? Or should this be handled by Z3 instead?


Repository:
  rL LLVM

https://reviews.llvm.org/D30489

Files:
  include/clang/StaticAnalyzer/Core/PathSensitive/ConstraintManager.h
  lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  lib/StaticAnalyzer/Core/SimpleConstraintManager.cpp
  lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp


Index: lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
===
--- lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
+++ lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
@@ -547,6 +547,13 @@
   if (const llvm::APSInt *RHSValue = getKnownValue(state, rhs))
 return MakeSymIntVal(Sym, op, *RHSValue, resultTy);
 
+  if (!state->isTainted(rhs) && !state->isTainted(lhs)) {
+const SymExpr *lhse = lhs.getAsSymExpr();
+const SymExpr *rhse = rhs.getAsSymExpr();
+return nonloc::SymbolVal(
+SymMgr.getSymSymExpr(lhse, op, rhse, resultTy));
+  }
+
   // Give up -- this is not a symbolic expression we can handle.
   return makeSymExprValNN(state, op, InputLHS, InputRHS, resultTy);
 }
Index: lib/StaticAnalyzer/Core/SimpleConstraintManager.cpp
===
--- lib/StaticAnalyzer/Core/SimpleConstraintManager.cpp
+++ lib/StaticAnalyzer/Core/SimpleConstraintManager.cpp
@@ -53,6 +53,19 @@
 ProgramStateRef SimpleConstraintManager::assumeAux(ProgramStateRef State,
NonLoc Cond,
bool Assumption) {
+  if (1) {
+Optional SymVal = Cond.getAs();
+if (SymVal && SymVal->isExpression()) {
+  const SymExpr *SE = SymVal->getSymbol();
+  if (const SymSymExpr *SSE = dyn_cast(SE)) {
+if (SSE->getOpcode() == BO_GE) {
+  SymSymExpr SSE2(SSE->getRHS(), BO_EQ, SSE->getLHS(), SSE->getType());
+  if (State->getConstraintManager().uglyEval(, State))
+return Assumption ? State : nullptr;
+}
+  }
+}
+  }
 
   // We cannot reason about SymSymExprs, and can only reason about some
   // SymIntExprs.
Index: lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -287,6 +287,8 @@
   RangeConstraintManager(SubEngine *SE, SValBuilder )
   : RangedConstraintManager(SE, SVB) {}
 
+  virtual bool uglyEval(const SymSymExpr *SSE, ProgramStateRef state);
+
   //===--===//
   // Implementation for interface from ConstraintManager.
   //===--===//
@@ -723,6 +725,25 @@
 // Pretty-printing.
 
//======/
 
+bool RangeConstraintManager::uglyEval(const SymSymExpr *SSE,
+  ProgramStateRef State) {
+  ConstraintRangeTy Ranges = State->get();
+  for (ConstraintRangeTy::iterator I = Ranges.begin(), E = Ranges.end(); I != 
E;
+   ++I) {
+SymbolRef SR = I.getKey();
+if (const SymSymExpr *SSE2 = dyn_cast(SR)) {
+  if (SSE->getOpcode() != SSE2->getOpcode())
+continue;
+  if (SSE->getLHS() != SSE2->getLHS())
+continue;
+  if (SSE->getRHS() != SSE2->getRHS())
+continue;
+  return true;
+}
+  }
+  return false;
+}
+
 void RangeConstraintManager::print(ProgramStateRef St, raw_ostream ,
const char *nl, const char *sep) {
 
Index: 

[PATCH] D31408: Add more examples to clang-format configuration

2017-04-10 Thread Sylvestre Ledru via Phabricator via cfe-commits
sylvestre.ledru added a comment.

Daniel, is that ok with you?


https://reviews.llvm.org/D31408



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


[PATCH] D26794: [OpenCL] Blocks are allowed to capture arrays in OpenCL 2.0 and higher.

2017-04-10 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added inline comments.



Comment at: lib/Sema/SemaExpr.cpp:13645
   
   // Blocks are not allowed to capture arrays.
+  if (!S.getLangOpts().OpenCL && CaptureType->isArrayType()) {

I think the comment should be updated.



Comment at: test/SemaOpenCL/blocks_with_array.cl:9
+  block_t b = ^() {
+// CHECK:   %{{.*}} = getelementptr inbounds [3 x i32], [3 x i32] 
addrspace(4)* %{{.*}}, i64 0, i64 0
+return a[0];

Does this test anything different from the function `foo` below?



Comment at: test/SemaOpenCL/blocks_with_array.cl:21
+  block_t bl1 = ^(){return s.arr[1];};
+// CHECK: define internal spir_func i32 @__foo_block_invoke(i8 addrspace(4)* 
%.block_descriptor)
+// CHECK:   %{{.*}} = getelementptr inbounds %struct.v, %struct.v 
addrspace(4)* %{{.*}}, i32 0, i32 0

Can we check there is a memcpy here?



Comment at: test/SemaOpenCL/blocks_with_array.cl:27
+  block_t bl2 = ^(){return arr[1];};
+// CHECK: define internal spir_func i32 @__foo_block_invoke_2(i8 addrspace(4)* 
%.block_descriptor)
+// CHECK:   %{{.*}} = getelementptr inbounds [2 x i32], [2 x i32] 
addrspace(4)* %{{.*}}, i64 0, i64 1

Can we CHECK-NOT memcpy?



Comment at: test/SemaOpenCL/blocks_with_array.cl:30
+  // array decayed to pointer while captured
+  s.arr[1] = arr[1] = 877;
+}

Do we need this line as well?


https://reviews.llvm.org/D26794



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


[PATCH] D30691: [analyzer] Support for naive cross translational unit analysis

2017-04-10 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun marked 6 inline comments as done.
xazax.hun added inline comments.



Comment at: test/Analysis/Inputs/externalFnMap.txt:1
+_Z7h_chaini@x86_64 xtu-chain.cpp.ast
+_ZN4chns4chf2Ei@x86_64 xtu-chain.cpp.ast

NoQ wrote:
> These tests use a pre-made external function map.
> 
> Are you willing to add tests for generating function maps?
> 
> That'd be useful, in my opinion, because it'd actually tell people how to run 
> the whole thing.
Good idea! We will add a test for that. 



Comment at: tools/clang-cmdline-arch-extractor/ClangCmdlineArchExtractor.cpp:1
+//===- ClangCmdlineArchExtractor.cpp ===//
+//

NoQ wrote:
> Do we really intend to keep this as a tool? I suspect obtaining the 
> architecture could be done much easier by parsing the run-line in python 
> scripts, we were just in too much rush to consider this possibility, and 
> calling a whole tool for just that sounds like an overkill. I think it would 
> be great to simplify this out.
> 
> Additionally, this whole architecture hassle kicks in only rarely. It is only 
> important to know the architecture because some projects have the same file 
> compiled for different architectures (we used to have it in Android which has 
> binaries that are compiled for both host machine and target machine, but for 
> most projects just having a mangled name is already good enough). So we can 
> delay this discussion by splitting this out of the initial patch, if you 
> want, but that's extra work, of course, so please take the above as more of a 
> mumble than of a request.
We had the same idea recently. Next version of this patch will do this by 
parsing the clang cc1 command line (gathered by -###).



Comment at: tools/clang-cmdline-arch-extractor/ClangCmdlineArchExtractor.cpp:72
+
+  return 0;
+}

danielmarjamaki wrote:
> EXIT_SUCCESS is also possible however I guess that is 0 on all 
> implementations.
Other clang tools return 0.



Comment at: tools/clang-func-mapping/ClangFnMapGen.cpp:192
+  lockedWrite(BuildDir + "/definedFns.txt", DefinedFuncsStr.str());
+  std::ostringstream CFGStr;
+  for (auto  : CG) {

a.sidorin wrote:
> It is not 'CFG'Str, it should be 'CallGraph'Str. Sorry for this issue.
That part is removed from this version of the patch. It wasn't used anywhere. 



Comment at: tools/clang-func-mapping/ClangFnMapGen.cpp:257
+  Tool.run(newFrontendActionFactory().get());
+}

danielmarjamaki wrote:
> no return.
That is not a problem for C++ programs, but added it.


https://reviews.llvm.org/D30691



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


[PATCH] D31673: Allow casting C pointers declared using extern "C" to ObjC pointer types

2017-04-10 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.


https://reviews.llvm.org/D31673



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


[PATCH] D30691: [analyzer] Support for naive cross translational unit analysis

2017-04-10 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun updated this revision to Diff 94709.
xazax.hun edited the summary of this revision.
xazax.hun added a comment.

- Fixed some memory leaks.
- Removed some unrelated style changes.
- Simplifications to the python scripts.
- Removed debug prints.


https://reviews.llvm.org/D30691

Files:
  include/clang/AST/ASTContext.h
  include/clang/AST/Decl.h
  include/clang/AST/Mangle.h
  include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
  include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h
  include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
  lib/AST/ASTContext.cpp
  lib/AST/ASTImporter.cpp
  lib/AST/ItaniumMangle.cpp
  lib/Basic/SourceManager.cpp
  lib/StaticAnalyzer/Core/AnalyzerOptions.cpp
  lib/StaticAnalyzer/Core/CMakeLists.txt
  lib/StaticAnalyzer/Core/CallEvent.cpp
  lib/StaticAnalyzer/Core/ExprEngine.cpp
  lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
  test/Analysis/Inputs/ctu-chain.cpp
  test/Analysis/Inputs/ctu-other.cpp
  test/Analysis/Inputs/externalFnMap.txt
  test/Analysis/ctu-main.cpp
  tools/CMakeLists.txt
  tools/clang-cmdline-arch-extractor/CMakeLists.txt
  tools/clang-cmdline-arch-extractor/ClangCmdlineArchExtractor.cpp
  tools/clang-func-mapping/CMakeLists.txt
  tools/clang-func-mapping/ClangFnMapGen.cpp
  tools/ctu-analysis/ctu-analyze.py
  tools/ctu-analysis/ctu-build.py
  tools/scan-build-py/libscanbuild/runner.py

Index: tools/scan-build-py/libscanbuild/runner.py
===
--- tools/scan-build-py/libscanbuild/runner.py
+++ tools/scan-build-py/libscanbuild/runner.py
@@ -162,7 +162,8 @@
 
 def target():
 """ Creates output file name for reports. """
-if opts['output_format'] in {'plist', 'plist-html'}:
+if opts['output_format'] in {'plist', 'plist-html',
+ 'plist-multi-file'}:
 (handle, name) = tempfile.mkstemp(prefix='report-',
   suffix='.plist',
   dir=opts['output_dir'])
Index: tools/ctu-analysis/ctu-build.py
===
--- /dev/null
+++ tools/ctu-analysis/ctu-build.py
@@ -0,0 +1,219 @@
+#!/usr/bin/env python
+
+import argparse
+import json
+import logging
+import multiprocessing
+import os
+import re
+import signal
+import subprocess
+
+
+SOURCE_PATTERN = re.compile('.*\.(C|c|cc|cpp|cxx|ii|m|mm)$', re.IGNORECASE)
+TIMEOUT = 86400
+DEFINED_FUNCTIONS_FILENAME = 'definedFns.txt'
+EXTERNAL_FUNCTIONS_FILENAME = 'externalFns.txt'
+EXTERNAL_FUNCTION_MAP_FILENAME = 'externalFnMap.txt'
+
+
+def get_args():
+parser = argparse.ArgumentParser(
+description='Executes 1st pass of CTU analysis where we preprocess '
+'all files in the compilation database and generate '
+'AST dumps and other necessary information from those '
+'to be used later by the 2nd pass of '
+'Cross Translation Unit analysis',
+formatter_class=argparse.ArgumentDefaultsHelpFormatter)
+parser.add_argument('-b', required=True, dest='buildlog',
+metavar='build.json',
+help='JSON Compilation Database to be used')
+parser.add_argument('-p', metavar='preanalyze-dir', dest='ctuindir',
+help='Target directory for preanalyzation data',
+default='.ctu')
+parser.add_argument('-j', metavar='threads', dest='threads', type=int,
+help='Number of threads to be used',
+default=int(multiprocessing.cpu_count() * 1.0))
+parser.add_argument('-v', dest='verbose', action='store_true',
+help='Verbose output')
+parser.add_argument('--clang-path', metavar='clang-path',
+dest='clang_path',
+help='Set path to directory of clang binaries used '
+ '(default taken from CLANG_PATH envvar)',
+default=os.environ.get('CLANG_PATH'))
+mainargs = parser.parse_args()
+
+if mainargs.verbose:
+logging.getLogger().setLevel(logging.INFO)
+
+if mainargs.clang_path is None:
+clang_path = ''
+else:
+clang_path = os.path.abspath(mainargs.clang_path)
+logging.info('CTU uses clang dir: ' +
+ (clang_path if clang_path != '' else ''))
+
+return mainargs, clang_path
+
+
+def process_buildlog(buildlog_filename, src_2_dir, src_2_cmd, src_order,
+ cmd_2_src, cmd_order):
+with open(buildlog_filename, 'r') as buildlog_file:
+buildlog = json.load(buildlog_file)
+for step in buildlog:
+if SOURCE_PATTERN.match(step['file']):
+if step['file'] not in src_2_dir:
+src_2_dir[step['file']] = step['directory']
+src_2_cmd[step['file']] = step['command']
+   

[PATCH] D31404: [OpenCL] Allow alloca return non-zero private pointer

2017-04-10 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl marked 2 inline comments as done.
yaxunl added inline comments.



Comment at: include/clang/Basic/AddressSpaces.h:32
+  // QualType represents private address space in OpenCL source code.
+  Default = 0,
+

Anastasia wrote:
> yaxunl wrote:
> > Anastasia wrote:
> > > The alloca AS is not taken from the target AS map but from the 
> > > DataLayout. This keep me wonder whether the explicit Default item is 
> > > actually needed here
> > For OpenCL, the default addr space is mapped to alloca addr space. For 
> > other languages, it is mapped by the address space mapping table.
> Ok. BTW, why is it done differently for other languages than OpenCL now? Is 
> it something we missed in the programming model before? Or is it something 
> specific to AMD target support?
This is because amdgcn target now supports a new address space mapping where 
alloca address space is different from generic address space. For OpenCL, 
address space 0 should be mapped to alloca address space; for other languages, 
address space 0 should be mapped to a target specific generic address space. 
The previous approach for mapping address spaces cannot handle the requirements 
since it always maps address space 0 to target address space 0. Therefore it 
needs to be extended for more general cases.


https://reviews.llvm.org/D31404



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


[PATCH] D31760: [lsan] Enable LSan on arm Linux, clang part

2017-04-10 Thread Evgeniy Stepanov via Phabricator via cfe-commits
eugenis accepted this revision.
eugenis added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rL LLVM

https://reviews.llvm.org/D31760



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


[PATCH] D31760: [lsan] Enable LSan on arm Linux, clang part

2017-04-10 Thread Maxim Ostapenko via Phabricator via cfe-commits
m.ostapenko updated this revision to Diff 94708.
m.ostapenko added a project: Sanitizers.
m.ostapenko added a comment.

Add armeb and thumbeb for completeness.
Just curious, does anyone use sanitizers in these targets? I see no public 
buildbots for armeb and thumbeb. Anyway, not a big deal of course.


Repository:
  rL LLVM

https://reviews.llvm.org/D31760

Files:
  lib/Driver/ToolChains/Linux.cpp
  test/Driver/fsanitize.c


Index: test/Driver/fsanitize.c
===
--- test/Driver/fsanitize.c
+++ test/Driver/fsanitize.c
@@ -237,6 +237,30 @@
 // RUN: %clang -target i686-linux-gnu -fsanitize=address,leak 
-fno-sanitize=address %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANA-SANL-NO-SANA-X86
 // CHECK-SANA-SANL-NO-SANA-X86: "-fsanitize=leak"
 
+// RUN: %clang -target arm-linux-gnu -fsanitize=leak %s -### 2>&1 | FileCheck 
%s --check-prefix=CHECK-SANL-ARM
+// CHECK-SANL-ARM: "-fsanitize=leak"
+
+// RUN: %clang -target arm-linux-gnu -fsanitize=address,leak 
-fno-sanitize=address %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANA-SANL-NO-SANA-ARM
+// CHECK-SANA-SANL-NO-SANA-ARM: "-fsanitize=leak"
+
+// RUN: %clang -target thumb-linux -fsanitize=leak %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANL-THUMB
+// CHECK-SANL-THUMB: "-fsanitize=leak"
+
+// RUN: %clang -target thumb-linux -fsanitize=address,leak 
-fno-sanitize=address %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANA-SANL-NO-SANA-THUMB
+// CHECK-SANA-SANL-NO-SANA-THUMB: "-fsanitize=leak"
+
+// RUN: %clang -target armeb-linux-gnu -fsanitize=leak %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-SANL-ARMEB
+// CHECK-SANL-ARMEB: "-fsanitize=leak"
+
+// RUN: %clang -target armeb-linux-gnu -fsanitize=address,leak 
-fno-sanitize=address %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANA-SANL-NO-SANA-ARMEB
+// CHECK-SANA-SANL-NO-SANA-ARMEB: "-fsanitize=leak"
+
+// RUN: %clang -target thumbeb-linux -fsanitize=leak %s -### 2>&1 | FileCheck 
%s --check-prefix=CHECK-SANL-THUMBEB
+// CHECK-SANL-THUMBEB: "-fsanitize=leak"
+
+// RUN: %clang -target thumbeb-linux -fsanitize=address,leak 
-fno-sanitize=address %s -### 2>&1 | FileCheck %s 
--check-prefix=CHECK-SANA-SANL-NO-SANA-THUMBEB
+// CHECK-SANA-SANL-NO-SANA-THUMBEB: "-fsanitize=leak"
+
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=memory %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-MSAN
 // CHECK-MSAN: "-fno-assume-sane-operator-new"
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=address %s -### 2>&1 | 
FileCheck %s --check-prefix=CHECK-ASAN
Index: lib/Driver/ToolChains/Linux.cpp
===
--- lib/Driver/ToolChains/Linux.cpp
+++ lib/Driver/ToolChains/Linux.cpp
@@ -864,14 +864,17 @@
getTriple().getArch() == llvm::Triple::ppc64le;
   const bool IsAArch64 = getTriple().getArch() == llvm::Triple::aarch64 ||
  getTriple().getArch() == llvm::Triple::aarch64_be;
+  const bool IsArmArch = getTriple().getArch() == llvm::Triple::arm ||
+ llvm::Triple::thumb || llvm::Triple::armeb ||
+ llvm::Triple::thumbeb;
   SanitizerMask Res = ToolChain::getSupportedSanitizers();
   Res |= SanitizerKind::Address;
   Res |= SanitizerKind::KernelAddress;
   Res |= SanitizerKind::Vptr;
   Res |= SanitizerKind::SafeStack;
   if (IsX86_64 || IsMIPS64 || IsAArch64)
 Res |= SanitizerKind::DataFlow;
-  if (IsX86_64 || IsMIPS64 || IsAArch64 || IsX86)
+  if (IsX86_64 || IsMIPS64 || IsAArch64 || IsX86 || IsArmArch)
 Res |= SanitizerKind::Leak;
   if (IsX86_64 || IsMIPS64 || IsAArch64 || IsPowerPC64)
 Res |= SanitizerKind::Thread;


Index: test/Driver/fsanitize.c
===
--- test/Driver/fsanitize.c
+++ test/Driver/fsanitize.c
@@ -237,6 +237,30 @@
 // RUN: %clang -target i686-linux-gnu -fsanitize=address,leak -fno-sanitize=address %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-SANA-SANL-NO-SANA-X86
 // CHECK-SANA-SANL-NO-SANA-X86: "-fsanitize=leak"
 
+// RUN: %clang -target arm-linux-gnu -fsanitize=leak %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-SANL-ARM
+// CHECK-SANL-ARM: "-fsanitize=leak"
+
+// RUN: %clang -target arm-linux-gnu -fsanitize=address,leak -fno-sanitize=address %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-SANA-SANL-NO-SANA-ARM
+// CHECK-SANA-SANL-NO-SANA-ARM: "-fsanitize=leak"
+
+// RUN: %clang -target thumb-linux -fsanitize=leak %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-SANL-THUMB
+// CHECK-SANL-THUMB: "-fsanitize=leak"
+
+// RUN: %clang -target thumb-linux -fsanitize=address,leak -fno-sanitize=address %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-SANA-SANL-NO-SANA-THUMB
+// CHECK-SANA-SANL-NO-SANA-THUMB: "-fsanitize=leak"
+
+// RUN: %clang -target armeb-linux-gnu -fsanitize=leak %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-SANL-ARMEB
+// CHECK-SANL-ARMEB: "-fsanitize=leak"
+
+// RUN: 

[PATCH] D31886: [analyzer] Simplify values in binary operations more aggressively

2017-04-10 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun added a comment.

This is a very welcome addition. I hope the performance will be still good :)




Comment at: lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp:1023
+
+SVal VisitSymIntExpr(const SymIntExpr *S) {
+  SValBuilder  = State->getStateManager().getSValBuilder();

We do not expect to see IntSymExpr? Maybe it is worth to document why. 



Comment at: lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp:1024
+SVal VisitSymIntExpr(const SymIntExpr *S) {
+  SValBuilder  = State->getStateManager().getSValBuilder();
+  SVal LHS, RHS;

Maybe worth to have this as a member instead of query it every time?



Comment at: lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp:1027
+  if (Loc::isLocType(S->getLHS()->getType()) &&
+  BinaryOperator::isComparisonOp(S->getOpcode())) {
+LHS = Visit(S->getLHS());

Why are these ops special?



Comment at: lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp:1033
+  } else {
+LHS = Visit(S->getLHS());
+RHS = SVB.makeIntVal(S->getRHS());

Maybe this can be hoisted?


https://reviews.llvm.org/D31886



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


[PATCH] D31840: [analyzer] Fix crash on access to property

2017-04-10 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a comment.

This defensive check looks reasonable regardless of how well we model unions 
(we don't). Thanks for the patch!




Comment at: lib/StaticAnalyzer/Core/CallEvent.cpp:706
+  }
   Values.push_back(IvarLVal);
   return;

I believe there's not much to `push_back` here when we don't have the region. 
So this can go under the `if(){}` as well.


Repository:
  rL LLVM

https://reviews.llvm.org/D31840



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


[PATCH] D31308: [clang-tidy] new check readability-no-alternative-tokens

2017-04-10 Thread Piotr Padlewski via Phabricator via cfe-commits
Prazek added a comment.

Yep, I am also a fan of "and","or" and "not". The other tokens doesn't make it 
more readable imho


https://reviews.llvm.org/D31308



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


[PATCH] D30691: [analyzer] Support for naive cross translational unit analysis

2017-04-10 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a comment.

Yeah, of course, ideally sticking this into scan-build, one way or another, 
would be great. I understand that it'd require quite a bit of communication 
with Laszlo. Otherwise we're just duplicating a whole lot of things.

Thanks for digging into this, guys. Really.




Comment at: lib/AST/ASTContext.cpp:1529-1530
+iterateContextDecls(TU, MangledFnName, MangleCtx)) {
+llvm::errs() << "Importing function " << MangledFnName << " from "
+ << ASTFileName << "\n";
+// FIXME: Refactor const_cast

These debug prints should be removed, i guess.



Comment at: lib/AST/ASTImporter.cpp:3222
 
-  if (FunctionDecl *FoundFunction = dyn_cast(FoundDecls[I])) 
{
+  if (auto *FoundFunction = dyn_cast(FoundDecls[I])) {
 if (FoundFunction->hasExternalFormalLinkage() &&

We could probably commit the `auto`-related changes separately in order to keep 
this patch clean.



Comment at: test/Analysis/Inputs/externalFnMap.txt:1
+_Z7h_chaini@x86_64 xtu-chain.cpp.ast
+_ZN4chns4chf2Ei@x86_64 xtu-chain.cpp.ast

These tests use a pre-made external function map.

Are you willing to add tests for generating function maps?

That'd be useful, in my opinion, because it'd actually tell people how to run 
the whole thing.



Comment at: tools/clang-cmdline-arch-extractor/ClangCmdlineArchExtractor.cpp:1
+//===- ClangCmdlineArchExtractor.cpp ===//
+//

Do we really intend to keep this as a tool? I suspect obtaining the 
architecture could be done much easier by parsing the run-line in python 
scripts, we were just in too much rush to consider this possibility, and 
calling a whole tool for just that sounds like an overkill. I think it would be 
great to simplify this out.

Additionally, this whole architecture hassle kicks in only rarely. It is only 
important to know the architecture because some projects have the same file 
compiled for different architectures (we used to have it in Android which has 
binaries that are compiled for both host machine and target machine, but for 
most projects just having a mangled name is already good enough). So we can 
delay this discussion by splitting this out of the initial patch, if you want, 
but that's extra work, of course, so please take the above as more of a mumble 
than of a request.


https://reviews.llvm.org/D30691



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


[PATCH] D31746: Remove ASTUnits for closed documents and cache CompilationDatabase per directory in clangd.

2017-04-10 Thread Krasimir Georgiev via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL299843: [clangd] Remove ASTUnits for closed documents and 
cache CompilationDatabase per… (authored by krasimir).

Changed prior to commit:
  https://reviews.llvm.org/D31746?vs=94664=94665#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D31746

Files:
  clang-tools-extra/trunk/clangd/ASTManager.cpp
  clang-tools-extra/trunk/clangd/ASTManager.h
  clang-tools-extra/trunk/clangd/ClangDMain.cpp
  clang-tools-extra/trunk/clangd/Protocol.cpp
  clang-tools-extra/trunk/clangd/Protocol.h
  clang-tools-extra/trunk/clangd/ProtocolHandlers.cpp
  clang-tools-extra/trunk/clangd/ProtocolHandlers.h

Index: clang-tools-extra/trunk/clangd/ProtocolHandlers.cpp
===
--- clang-tools-extra/trunk/clangd/ProtocolHandlers.cpp
+++ clang-tools-extra/trunk/clangd/ProtocolHandlers.cpp
@@ -24,6 +24,17 @@
   Store.addDocument(DOTDP->textDocument.uri.file, DOTDP->textDocument.text);
 }
 
+void TextDocumentDidCloseHandler::handleNotification(
+llvm::yaml::MappingNode *Params) {
+  auto DCTDP = DidCloseTextDocumentParams::parse(Params);
+  if (!DCTDP) {
+Output.log("Failed to decode DidCloseTextDocumentParams!\n");
+return;
+  }
+
+  Store.removeDocument(DCTDP->textDocument.uri.file);
+}
+
 void TextDocumentDidChangeHandler::handleNotification(
 llvm::yaml::MappingNode *Params) {
   auto DCTDP = DidChangeTextDocumentParams::parse(Params);
@@ -156,7 +167,7 @@
   std::string Code = AST.getStore().getDocument(CAP->textDocument.uri.file);
   std::string Commands;
   for (Diagnostic  : CAP->context.diagnostics) {
-std::vector Fixes = AST.getFixIts(D);
+std::vector Fixes = AST.getFixIts(CAP->textDocument.uri.file, D);
 std::string Edits = replacementsToEdits(Code, Fixes);
 
 if (!Edits.empty())
Index: clang-tools-extra/trunk/clangd/ASTManager.cpp
===
--- clang-tools-extra/trunk/clangd/ASTManager.cpp
+++ clang-tools-extra/trunk/clangd/ASTManager.cpp
@@ -20,6 +20,29 @@
 using namespace clang;
 using namespace clangd;
 
+void DocData::setAST(std::unique_ptr AST) {
+  this->AST = std::move(AST);
+}
+
+ASTUnit *DocData::getAST() const { return AST.get(); }
+
+void DocData::cacheFixIts(DiagnosticToReplacementMap FixIts) {
+  this->FixIts = std::move(FixIts);
+}
+
+std::vector
+DocData::getFixIts(const clangd::Diagnostic ) const {
+  auto it = FixIts.find(D);
+  if (it != FixIts.end())
+return it->second;
+  return {};
+}
+
+ASTManagerRequest::ASTManagerRequest(ASTManagerRequestType Type,
+ std::string File,
+ DocVersion Version)
+: Type(Type), File(File), Version(Version) {}
+
 /// Retrieve a copy of the contents of every file in the store, for feeding into
 /// ASTUnit.
 static std::vector
@@ -61,82 +84,125 @@
 
 void ASTManager::runWorker() {
   while (true) {
-std::string File;
+ASTManagerRequest Request;
 
+// Pick request from the queue
 {
   std::unique_lock Lock(RequestLock);
-  // Check if there's another request pending. We keep parsing until
-  // our one-element queue is empty.
+  // Wait for more requests.
   ClangRequestCV.wait(Lock,
   [this] { return !RequestQueue.empty() || Done; });
-
-  if (RequestQueue.empty() && Done)
+  if (Done)
 return;
+  assert(!RequestQueue.empty() && "RequestQueue was empty");
 
-  File = std::move(RequestQueue.back());
+  Request = std::move(RequestQueue.back());
   RequestQueue.pop_back();
-} // unlock.
 
+  // Skip outdated requests
+  if (Request.Version != DocVersions.find(Request.File)->second) {
+Output.log("Version for " + Twine(Request.File) +
+   " in request is outdated, skipping request\n");
+continue;
+  }
+} // unlock RequestLock
+
+handleRequest(Request.Type, Request.File);
+  }
+}
+
+void ASTManager::queueOrRun(ASTManagerRequestType RequestType, StringRef File) {
+  if (RunSynchronously) {
+handleRequest(RequestType, File);
+return;
+  }
+
+  std::lock_guard Guard(RequestLock);
+  // We increment the version of the added document immediately and schedule
+  // the requested operation to be run on a worker thread
+  DocVersion version = ++DocVersions[File];
+  RequestQueue.push_back(ASTManagerRequest(RequestType, File, version));
+  ClangRequestCV.notify_one();
+}
+
+void ASTManager::handleRequest(ASTManagerRequestType RequestType,
+   StringRef File) {
+  switch (RequestType) {
+  case ASTManagerRequestType::ParseAndPublishDiagnostics:
 parseFileAndPublishDiagnostics(File);
+break;
+  case ASTManagerRequestType::RemoveDocData: {
+std::lock_guard Lock(ClangObjectLock);
+auto DocDataIt = DocDatas.find(File);
+// We could get the remove request before parsing for 

[PATCH] D31746: Remove ASTUnits for closed documents and cache CompilationDatabase per directory in clangd.

2017-04-10 Thread Krasimir Georgiev via Phabricator via cfe-commits
krasimir accepted this revision.
krasimir added a comment.
This revision is now accepted and ready to land.

Looks good!


https://reviews.llvm.org/D31746



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


[PATCH] D31886: [analyzer] Simplify values in binary operations more aggressively

2017-04-10 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ created this revision.

SValBuilder tries to constant-fold symbols in the left-hand side of the 
symbolic expression whenever it fails to evaluate the expression directly. 
However, it only constant-folds them when they are atomic expressions, not when 
they are complicated expressions themselves. This patch adds recursive 
constant-folding to the left-hand side expression (there's a lack of symmetry 
because we're trying to have symbols on the left and constants on the right). 
As an example, we'd now be able to handle operations similar to "$x + 1 < $y", 
when $x is constrained to a constant.

The constant-folding procedure, which i put into `SValBuilder::simplifySVal()`, 
is reusable, and i suspect that there are numerous places around `SValBuilder`, 
`ConstraintManager`, and our checkers, where it could be useful, but this patch 
tries to be relatively careful.

I'm still to see how it affects performance.


https://reviews.llvm.org/D31886

Files:
  include/clang/StaticAnalyzer/Core/PathSensitive/SValBuilder.h
  lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
  test/Analysis/additive-folding.cpp

Index: test/Analysis/additive-folding.cpp
===
--- test/Analysis/additive-folding.cpp
+++ test/Analysis/additive-folding.cpp
@@ -205,3 +205,12 @@
 
   clang_analyzer_eval(x == 3); // expected-warning{{UNKNOWN}}
 }
+
+void additiveSymSymFolding(int x, int y) {
+  // We should simplify 'x - 1' to '0' and handle the comparison,
+  // despite both sides being complicated symbols.
+  int z = x - 1;
+  if (x == 1)
+if (y >= 0)
+  clang_analyzer_eval(z <= y); // expected-warning{{TRUE}}
+}
Index: lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
===
--- lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
+++ lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
@@ -14,6 +14,7 @@
 #include "clang/StaticAnalyzer/Core/PathSensitive/SValBuilder.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/APSIntType.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/SValVisitor.h"
 
 using namespace clang;
 using namespace ento;
@@ -44,6 +45,10 @@
   ///  (integer) value, that value is returned. Otherwise, returns NULL.
   const llvm::APSInt *getKnownValue(ProgramStateRef state, SVal V) override;
 
+  /// Recursively descends into symbolic expressions and replaces symbols
+  /// with thier known values (in the sense of the getKnownValue() method).
+  SVal simplifySVal(ProgramStateRef State, SVal V) override;
+
   SVal MakeSymIntVal(const SymExpr *LHS, BinaryOperator::Opcode op,
  const llvm::APSInt , QualType resultTy);
 };
@@ -537,11 +542,12 @@
   // Does the symbolic expression simplify to a constant?
   // If so, "fold" the constant by setting 'lhs' to a ConcreteInt
   // and try again.
-  ConstraintManager  = state->getConstraintManager();
-  if (const llvm::APSInt *Constant = CMgr.getSymVal(state, Sym)) {
-lhs = nonloc::ConcreteInt(*Constant);
-continue;
-  }
+  SVal simplifiedLhs = simplifySVal(state, lhs);
+  if (simplifiedLhs != lhs)
+if (auto simplifiedLhsAsNonLoc = simplifiedLhs.getAs()) {
+  lhs = *simplifiedLhsAsNonLoc;
+  continue;
+}
 
   // Is the RHS a constant?
   if (const llvm::APSInt *RHSValue = getKnownValue(state, rhs))
@@ -993,3 +999,64 @@
   // FIXME: Add support for SymExprs.
   return nullptr;
 }
+
+SVal SimpleSValBuilder::simplifySVal(ProgramStateRef State, SVal V) {
+  // For now, this function tries to constant-fold symbols inside a
+  // nonloc::SymbolVal, and does nothing else. More simplifications should
+  // be possible, such as constant-folding an index in an ElementRegion.
+
+  class Simplifier : public FullSValVisitor {
+ProgramStateRef State;
+
+  public:
+Simplifier(ProgramStateRef State) : State(State) {}
+
+SVal VisitSymbolData(const SymbolData *S) {
+  SValBuilder  = State->getStateManager().getSValBuilder();
+  if (const llvm::APSInt *I =
+  SVB.getKnownValue(State, nonloc::SymbolVal(S)))
+return Loc::isLocType(S->getType()) ? (SVal)SVB.makeIntLocVal(*I)
+: (SVal)SVB.makeIntVal(*I);
+  return nonloc::SymbolVal(S);
+}
+
+SVal VisitSymIntExpr(const SymIntExpr *S) {
+  SValBuilder  = State->getStateManager().getSValBuilder();
+  SVal LHS, RHS;
+  if (Loc::isLocType(S->getLHS()->getType()) &&
+  BinaryOperator::isComparisonOp(S->getOpcode())) {
+LHS = Visit(S->getLHS());
+if (SymbolRef Sym = LHS.getAsSymbol())
+  LHS = SVB.makeLoc(Sym);
+RHS = SVB.makeIntLocVal(S->getRHS());
+  } else {
+LHS = Visit(S->getLHS());
+RHS = SVB.makeIntVal(S->getRHS());
+  }
+  return SVB.evalBinOp(State, S->getOpcode(), LHS, 

[PATCH] D31673: Allow casting C pointers declared using extern "C" to ObjC pointer types

2017-04-10 Thread Akira Hatanaka via Phabricator via cfe-commits
ahatanak updated this revision to Diff 94686.
ahatanak marked an inline comment as done.

https://reviews.llvm.org/D31673

Files:
  lib/Sema/SemaExprObjC.cpp
  test/SemaObjCXX/arc-bridged-cast.mm


Index: test/SemaObjCXX/arc-bridged-cast.mm
===
--- test/SemaObjCXX/arc-bridged-cast.mm
+++ test/SemaObjCXX/arc-bridged-cast.mm
@@ -52,3 +52,19 @@
   ref = (__bridge_retained CFAnnotatedObjectRef) CreateSomething();
   ref = (__bridge_retained CFAnnotatedObjectRef) CreateNSString();
 }
+
+struct __CFAnnotatedObject {
+} cf0;
+
+extern const CFAnnotatedObjectRef r0;
+extern const CFAnnotatedObjectRef r1 = 
+extern "C" const CFAnnotatedObjectRef r2;
+extern "C" const CFAnnotatedObjectRef r3 = 
+
+void testExternC() {
+  id obj;
+  obj = (id)r0;
+  obj = (id)r1; // expected-error{{cast of C pointer type 
'CFAnnotatedObjectRef' (aka 'const __CFAnnotatedObject *') to Objective-C 
pointer type 'id' requires a bridged cast}} expected-note{{use __bridge to 
convert directly}} expected-note{{use __bridge_transfer to transfer ownership 
of a +1 'CFAnnotatedObjectRef'}}
+  obj = (id)r2;
+  obj = (id)r3; // expected-error{{cast of C pointer type 
'CFAnnotatedObjectRef' (aka 'const __CFAnnotatedObject *') to Objective-C 
pointer type 'id' requires a bridged cast}} expected-note{{use __bridge to 
convert directly}} expected-note{{use __bridge_transfer to transfer ownership 
of a +1 'CFAnnotatedObjectRef'}}
+}
Index: lib/Sema/SemaExprObjC.cpp
===
--- lib/Sema/SemaExprObjC.cpp
+++ lib/Sema/SemaExprObjC.cpp
@@ -3355,7 +3355,7 @@
   if (isAnyRetainable(TargetClass) &&
   isAnyRetainable(SourceClass) &&
   var &&
-  var->getStorageClass() == SC_Extern &&
+  !var->hasDefinition(Context) &&
   var->getType().isConstQualified()) {
 
 // In system headers, they can also be assumed to be immune to retains.


Index: test/SemaObjCXX/arc-bridged-cast.mm
===
--- test/SemaObjCXX/arc-bridged-cast.mm
+++ test/SemaObjCXX/arc-bridged-cast.mm
@@ -52,3 +52,19 @@
   ref = (__bridge_retained CFAnnotatedObjectRef) CreateSomething();
   ref = (__bridge_retained CFAnnotatedObjectRef) CreateNSString();
 }
+
+struct __CFAnnotatedObject {
+} cf0;
+
+extern const CFAnnotatedObjectRef r0;
+extern const CFAnnotatedObjectRef r1 = 
+extern "C" const CFAnnotatedObjectRef r2;
+extern "C" const CFAnnotatedObjectRef r3 = 
+
+void testExternC() {
+  id obj;
+  obj = (id)r0;
+  obj = (id)r1; // expected-error{{cast of C pointer type 'CFAnnotatedObjectRef' (aka 'const __CFAnnotatedObject *') to Objective-C pointer type 'id' requires a bridged cast}} expected-note{{use __bridge to convert directly}} expected-note{{use __bridge_transfer to transfer ownership of a +1 'CFAnnotatedObjectRef'}}
+  obj = (id)r2;
+  obj = (id)r3; // expected-error{{cast of C pointer type 'CFAnnotatedObjectRef' (aka 'const __CFAnnotatedObject *') to Objective-C pointer type 'id' requires a bridged cast}} expected-note{{use __bridge to convert directly}} expected-note{{use __bridge_transfer to transfer ownership of a +1 'CFAnnotatedObjectRef'}}
+}
Index: lib/Sema/SemaExprObjC.cpp
===
--- lib/Sema/SemaExprObjC.cpp
+++ lib/Sema/SemaExprObjC.cpp
@@ -3355,7 +3355,7 @@
   if (isAnyRetainable(TargetClass) &&
   isAnyRetainable(SourceClass) &&
   var &&
-  var->getStorageClass() == SC_Extern &&
+  !var->hasDefinition(Context) &&
   var->getType().isConstQualified()) {
 
 // In system headers, they can also be assumed to be immune to retains.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D30435: [clang-import-test] Lookup inside entities

2017-04-10 Thread Aleksei Sidorin via Phabricator via cfe-commits
a.sidorin accepted this revision.
a.sidorin added a comment.

Looks excellent now. Thank you Sean!


Repository:
  rL LLVM

https://reviews.llvm.org/D30435



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


[PATCH] D31673: Allow casting C pointers declared using extern "C" to ObjC pointer types

2017-04-10 Thread Akira Hatanaka via Phabricator via cfe-commits
ahatanak added inline comments.



Comment at: lib/Sema/SemaExprObjC.cpp:3358
   var &&
-  var->getStorageClass() == SC_Extern &&
+  !var->isThisDeclarationADefinition() &&
   var->getType().isConstQualified()) {

rjmccall wrote:
> ahatanak wrote:
> > rjmccall wrote:
> > > Hmm.  Come to think of it, I wonder if we actually care whether the 
> > > variable has a definition, given that it's const.
> > > 
> > > Well, we can consider that later.  I agree that this change is good.
> > If we don't care whether the variable is a definition, it's possible to 
> > check whether the variable declaration is directly contained in a language 
> > linkage instead (using a function like isSingleLineLanguageLinkage in 
> > lib/AST/Decl.cpp).
> Nah, let's keep it simple for now.
> 
> Well, maybe the rule ought to be "does a definition exist?" rather than "is 
> the specific declaration that lookup found a definition?"
I think you are right. Changed it to a call to hasDefinition.


https://reviews.llvm.org/D31673



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


[PATCH] D31885: Remove TBAA information from LValues representing union members

2017-04-10 Thread Krzysztof Parzyszek via Phabricator via cfe-commits
kparzysz created this revision.

The TBAA information for union members may be wrong, and in the current form 
TBAA cannot represent them correctly.

This is a follow-up to this thread from llvm-dev:
http://lists.llvm.org/pipermail/llvm-dev/2017-April/111859.html


Repository:
  rL LLVM

https://reviews.llvm.org/D31885

Files:
  lib/CodeGen/CGExpr.cpp

Index: lib/CodeGen/CGExpr.cpp
===
--- lib/CodeGen/CGExpr.cpp
+++ lib/CodeGen/CGExpr.cpp
@@ -1011,66 +1011,97 @@
 /// type of the same size of the lvalue's type.  If the lvalue has a variable
 /// length type, this is not possible.
 ///
+
+/// Hacks to remove TBAA information from LValues that represent union members.
+/// The TBAA in the current form does not work for union members: the aliasing
+/// information emitted in such cases may be incorrect (leading to incorrect
+/// optimizations).
+static bool isUnionAccess(const Expr *E) {
+  switch (E->getStmtClass()) {
+case Stmt::MemberExprClass:
+  return cast(E)->getBase()->getType()->isUnionType();
+case Stmt::ImplicitCastExprClass:
+  return isUnionAccess(cast(E)->getSubExpr());
+case Stmt::ArraySubscriptExprClass:
+  return isUnionAccess(cast(E)->getBase());
+default:
+  break;
+  }
+  return false;
+}
+
+static LValue ClearTBAA(LValue &, bool Reset) {
+  if (Reset)
+LV.setTBAAInfo(nullptr);
+  return LV;
+}
+
 LValue CodeGenFunction::EmitLValue(const Expr *E) {
+  bool R = CGM.shouldUseTBAA() && isUnionAccess(E);
   ApplyDebugLocation DL(*this, E);
   switch (E->getStmtClass()) {
-  default: return EmitUnsupportedLValue(E, "l-value expression");
+  default: return ClearTBAA(EmitUnsupportedLValue(E, "l-value expression"), R);
 
   case Expr::ObjCPropertyRefExprClass:
 llvm_unreachable("cannot emit a property reference directly");
 
   case Expr::ObjCSelectorExprClass:
-return EmitObjCSelectorLValue(cast(E));
+return ClearTBAA(EmitObjCSelectorLValue(cast(E)), R);
   case Expr::ObjCIsaExprClass:
-return EmitObjCIsaExpr(cast(E));
+return ClearTBAA(EmitObjCIsaExpr(cast(E)), R);
   case Expr::BinaryOperatorClass:
-return EmitBinaryOperatorLValue(cast(E));
+return ClearTBAA(EmitBinaryOperatorLValue(cast(E)), R);
   case Expr::CompoundAssignOperatorClass: {
 QualType Ty = E->getType();
 if (const AtomicType *AT = Ty->getAs())
   Ty = AT->getValueType();
+const auto *CA = cast(E);
 if (!Ty->isAnyComplexType())
-  return EmitCompoundAssignmentLValue(cast(E));
-return EmitComplexCompoundAssignmentLValue(cast(E));
+  return ClearTBAA(EmitCompoundAssignmentLValue(CA), R);
+return ClearTBAA(EmitComplexCompoundAssignmentLValue(CA), R);
   }
   case Expr::CallExprClass:
   case Expr::CXXMemberCallExprClass:
   case Expr::CXXOperatorCallExprClass:
   case Expr::UserDefinedLiteralClass:
-return EmitCallExprLValue(cast(E));
+return ClearTBAA(EmitCallExprLValue(cast(E)), R);
   case Expr::VAArgExprClass:
-return EmitVAArgExprLValue(cast(E));
+return ClearTBAA(EmitVAArgExprLValue(cast(E)), R);
   case Expr::DeclRefExprClass:
-return EmitDeclRefLValue(cast(E));
+return ClearTBAA(EmitDeclRefLValue(cast(E)), R);
   case Expr::ParenExprClass:
-return EmitLValue(cast(E)->getSubExpr());
-  case Expr::GenericSelectionExprClass:
-return EmitLValue(cast(E)->getResultExpr());
+return ClearTBAA(EmitLValue(cast(E)->getSubExpr()), R);
+  case Expr::GenericSelectionExprClass: {
+const auto *GS = cast(E);
+return ClearTBAA(EmitLValue(GS->getResultExpr()), R);
+  }
   case Expr::PredefinedExprClass:
-return EmitPredefinedLValue(cast(E));
+return ClearTBAA(EmitPredefinedLValue(cast(E)), R);
   case Expr::StringLiteralClass:
-return EmitStringLiteralLValue(cast(E));
+return ClearTBAA(EmitStringLiteralLValue(cast(E)), R);
   case Expr::ObjCEncodeExprClass:
-return EmitObjCEncodeExprLValue(cast(E));
+return ClearTBAA(EmitObjCEncodeExprLValue(cast(E)), R);
   case Expr::PseudoObjectExprClass:
-return EmitPseudoObjectLValue(cast(E));
+return ClearTBAA(EmitPseudoObjectLValue(cast(E)), R);
   case Expr::InitListExprClass:
-return EmitInitListLValue(cast(E));
+return ClearTBAA(EmitInitListLValue(cast(E)), R);
   case Expr::CXXTemporaryObjectExprClass:
   case Expr::CXXConstructExprClass:
-return EmitCXXConstructLValue(cast(E));
-  case Expr::CXXBindTemporaryExprClass:
-return EmitCXXBindTemporaryLValue(cast(E));
+return ClearTBAA(EmitCXXConstructLValue(cast(E)), R);
+  case Expr::CXXBindTemporaryExprClass: {
+const auto *BT = cast(E);
+return ClearTBAA(EmitCXXBindTemporaryLValue(BT), R);
+  }
   case Expr::CXXUuidofExprClass:
-return EmitCXXUuidofLValue(cast(E));
+return ClearTBAA(EmitCXXUuidofLValue(cast(E)), R);
   case Expr::LambdaExprClass:
-return EmitLambdaLValue(cast(E));
+return ClearTBAA(EmitLambdaLValue(cast(E)), R);
 
   case Expr::ExprWithCleanupsClass: {
  

[PATCH] D30691: [analyzer] Support for naive cross translational unit analysis

2017-04-10 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a comment.

One more obvious observation regarding scan-build: because you are already 
reading a compilation database, the whole tool is essentially usable in 
combination with the current scan-build-py (which can create compilation 
databases). So it's already quite usable, but you're forced to do regular 
analysis before cross-translation-unit analysis. So all we need is an extra 
mode in scan-build-py that does the interception and leaves the rest of the 
work to us, either by piping commands to us directly, or by providing us with a 
compilation database (if `--intercept-first` is passed). Having some kind of 
`--intercept-only` would solve half of the problems. Of course, ideally the 
logic that adds the `-analyzer*` options should also be re-used, but for 
usability it isn't immediately necessary.


https://reviews.llvm.org/D30691



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


[PATCH] D30158: [clang-tidy] modernize: Find usage of random_shuffle and replace it with shuffle.

2017-04-10 Thread Mads Ravn via Phabricator via cfe-commits
madsravn added a comment.

In https://reviews.llvm.org/D30158#702778, @jroelofs wrote:

> In https://reviews.llvm.org/D30158#702760, @madsravn wrote:
>
> > In https://reviews.llvm.org/D30158#699342, @jroelofs wrote:
> >
> > > In https://reviews.llvm.org/D30158#699132, @madsravn wrote:
> > >
> > > > In https://reviews.llvm.org/D30158#698871, @aaron.ballman wrote:
> > > >
> > > > > In https://reviews.llvm.org/D30158#696534, @madsravn wrote:
> > > > >
> > > > > > Any updates on this?
> > > > >
> > > > >
> > > > > Have you run it over the test suite on the revision before 
> > > > > random_shuffle was removed from libc++?
> > > >
> > > >
> > > > I can't find any more tests for random_shuffle. I have looked in the 
> > > > SVN log for from december 2014 until now. It works on the three tests 
> > > > currently in trunk.
> > >
> > >
> > > Try just before r294328.
> >
> >
> > I can't see any random_shuffle tests in the libc++ repo before r294328 
> > either. I don't know if they aren't there or if I just can't find them. 
> > Would you be able to point them out for me with revision and path?
>
>
> Did you look at the diff from the commit I mentioned? That's the one that 
> removed them.


I found them and I have tested them all. This check works fine on them.


https://reviews.llvm.org/D30158



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


[PATCH] D31885: Remove TBAA information from LValues representing union members

2017-04-10 Thread Krzysztof Parzyszek via Phabricator via cfe-commits
kparzysz added inline comments.



Comment at: lib/CodeGen/CGExpr.cpp:1019
+/// optimizations).
+static bool isUnionAccess(const Expr *E) {
+  switch (E->getStmtClass()) {

I'm not sure if this is a complete list of different ways to get a union member.


Repository:
  rL LLVM

https://reviews.llvm.org/D31885



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


[PATCH] D31404: [OpenCL] Allow alloca return non-zero private pointer

2017-04-10 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added inline comments.



Comment at: include/clang/Basic/AddressSpaces.h:32
+  // QualType represents private address space in OpenCL source code.
+  Default = 0,
+

yaxunl wrote:
> Anastasia wrote:
> > The alloca AS is not taken from the target AS map but from the DataLayout. 
> > This keep me wonder whether the explicit Default item is actually needed 
> > here
> For OpenCL, the default addr space is mapped to alloca addr space. For other 
> languages, it is mapped by the address space mapping table.
Ok. BTW, why is it done differently for other languages than OpenCL now? Is it 
something we missed in the programming model before? Or is it something 
specific to AMD target support?


https://reviews.llvm.org/D31404



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


[PATCH] D31853: [clangd] Implement item kind for completion results

2017-04-10 Thread Krasimir Georgiev via Phabricator via cfe-commits
krasimir requested changes to this revision.
krasimir added a comment.
This revision now requires changes to proceed.

Looks good! However it would be easier for reviewers if you could please use 
arc: http://llvm.org/docs/Phabricator.html#id2
This makes it easy since I only have to do `arc patch D31853` in order to 
update my client source tree with your changes.
Could you please create a review like that?


https://reviews.llvm.org/D31853



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


[PATCH] D31697: Check for null before using TUScope

2017-04-10 Thread Kim Gräsman via Phabricator via cfe-commits
kimgr added a comment.

For some context, the backtrace when this happens is:

 include-what-you-use.exe!clang::Scope::getEntity() Line 313C++

include-what-you-use.exe!clang::Sema::PushOnScopeChains(clang::NamedDecl * 
D=0x07ed05b0, clang::Scope * S=0x, bool AddToContext=true) Line 1302 C++

include-what-you-use.exe!clang::Sema::LazilyCreateBuiltin(clang::IdentifierInfo 
* II=0x008087f0, unsigned int ID=0x0114, clang::Scope * S=0x, bool 
ForRedeclaration=false, clang::SourceLocation Loc={...}) Line 1910   C++
include-what-you-use.exe!LookupBuiltin(clang::Sema & S={...}, 
clang::LookupResult & R={...}) Line 699   C++
include-what-you-use.exe!LookupDirect(clang::Sema & S={...}, 
clang::LookupResult & R={...}, const clang::DeclContext * DC=0x007c1a14) Line 
850  C++
include-what-you-use.exe!CppNamespaceLookup(clang::Sema & S={...}, 
clang::LookupResult & R={...}, clang::ASTContext & Context={...}, 
clang::DeclContext * NS=0x007c1a14, 
`anonymous-namespace'::UnqualUsingDirectiveSet & UDirs={...}) Line 931 C++
include-what-you-use.exe!clang::Sema::CppLookupName(clang::LookupResult 
& R={...}, clang::Scope * S=0x0078c870) Line 1310   C++
include-what-you-use.exe!clang::Sema::LookupName(clang::LookupResult & 
R={...}, clang::Scope * S=0x079fcd10, bool AllowBuiltinCreation=false) Line 
1798 C++
include-what-you-use.exe!clang::Sema::getTypeName(const 
clang::IdentifierInfo & II={...}, clang::SourceLocation NameLoc={...}, 
clang::Scope * S=0x079fcd10, clang::CXXScopeSpec * SS=0x0449db94, bool 
isClassName=false, bool HasTrailingDot=false, clang::OpaquePtr 
ObjectTypePtr={...}, bool IsCtorOrDtorName=false, bool 
WantNontrivialTypeSourceInfo=true, bool IsClassTemplateDeductionContext=true, 
clang::IdentifierInfo * * CorrectedII=0x) Line 331   C++

include-what-you-use.exe!clang::Parser::TryAnnotateTypeOrScopeTokenAfterScopeSpec(clang::CXXScopeSpec
 & SS={...}, bool IsNewScope=true) Line 1727   C++
include-what-you-use.exe!clang::Parser::TryAnnotateTypeOrScopeToken() 
Line 1717 C++
include-what-you-use.exe!clang::Parser::ParseCastExpression(bool 
isUnaryExpression=false, bool isAddressOfOperand=false, bool & 
NotCastExpr=false, clang::Parser::TypeCastState isTypeCast=NotTypeCast, bool 
isVectorLiteral=false) Line 876C++
include-what-you-use.exe!clang::Parser::ParseCastExpression(bool 
isUnaryExpression=false, bool isAddressOfOperand=false, 
clang::Parser::TypeCastState isTypeCast=NotTypeCast, bool 
isVectorLiteral=false) Line 484  C++

include-what-you-use.exe!clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState
 isTypeCast=NotTypeCast) Line 171 C++

include-what-you-use.exe!clang::Parser::ParseExpression(clang::Parser::TypeCastState
 isTypeCast=NotTypeCast) Line 121   C++
include-what-you-use.exe!clang::Parser::ParseReturnStatement() Line 
1905C++

include-what-you-use.exe!clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector & Stmts={...}, clang::Parser::AllowedConstructsKind Allowed=ACK_Any, 
clang::SourceLocation * TrailingElseLoc=0x, 
clang::Parser::ParsedAttributesWithRange & Attrs={...}) Line 265C++

include-what-you-use.exe!clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector & Stmts={...}, clang::Parser::AllowedConstructsKind Allowed=ACK_Any, 
clang::SourceLocation * TrailingElseLoc=0x) Line 113   C++
include-what-you-use.exe!clang::Parser::ParseCompoundStatementBody(bool 
isStmtExpr=false) Line 996  C++

include-what-you-use.exe!clang::Parser::ParseFunctionStatementBody(clang::Decl 
* Decl=0x07e84ce0, clang::Parser::ParseScope & BodyScope={...}) Line 1965   
 C++

include-what-you-use.exe!clang::Parser::ParseLateTemplatedFuncDef(clang::LateParsedTemplate
 & LPT={...}) Line 1418  C++
include-what-you-use.exe!clang::Parser::LateTemplateParserCallback(void 
* P=0x0077d438, clang::LateParsedTemplate & LPT={...}) Line 1339C++

include-what-you-use.exe!include_what_you_use::IwyuAstConsumer::ParseFunctionTemplates(clang::TranslationUnitDecl
 * decl=0x007c1a00) Line 3558  C++

include-what-you-use.exe!include_what_you_use::IwyuAstConsumer::HandleTranslationUnit(clang::ASTContext
 & context={...}) Line 3503  C++
include-what-you-use.exe!clang::ParseAST(clang::Sema & S={...}, bool 
PrintStats=false, bool SkipFunctionBodies=false) Line 159  C++
include-what-you-use.exe!clang::ASTFrontendAction::ExecuteAction() Line 
611 C++
include-what-you-use.exe!clang::FrontendAction::Execute() Line 512  
C++

include-what-you-use.exe!clang::CompilerInstance::ExecuteAction(clang::FrontendAction
 & Act={...}) Line 970 C++

This is triggered when we invoke a hacky hook in Sema to force instantiation of 
late-parsed function templates:

  void 

[PATCH] D30909: [Analyzer] Finish taint propagation to derived symbols of tainted regions

2017-04-10 Thread Vlad Tsyrklevich via Phabricator via cfe-commits
vlad.tsyrklevich marked 2 inline comments as done.
vlad.tsyrklevich added inline comments.



Comment at: lib/StaticAnalyzer/Checkers/GenericTaintChecker.cpp:494
+  SymbolManager  = C.getSymbolManager();
+  return SM.getDerivedSymbol(Sym, LCV.getRegion());
 }

NoQ wrote:
> vlad.tsyrklevich wrote:
> > NoQ wrote:
> > > I'd think about this a bit more and come back.
> > > 
> > > I need to understand how come that constructing a symbol manually is the 
> > > right thing to do; that doesn't happen very often, but it seems correct 
> > > here.
> > Indeed it is odd. The best justification I could come up with: LCVs are 
> > meant to be optimizations, their 'purpose' is to expose an SVal that hides 
> > SymbolRef values so that we can have a split store. We don't have to copy 
> > all of a compound values SymbolRef mappings because LCVs are kept distinct. 
> > Hence to set/query/constrain region values you use SVals so that 
> > RegionStore can differentiate between LCVs and SymbolRef backed SVals for 
> > the two different stores it contains.
> > 
> > The taint interface however requires you taint a SymbolRef, not an SVal. If 
> > we wanted, instead of doing this logic here, we could change 
> > getPointedToSymbol() to return an SVal and update usages of it accordingly 
> > since that value is only passed on to 
> > ProgramState.isTainted()/ProgramState.addTaint() anyway. Then we could 
> > update addTaint/isTainted to perform this logic, hiding it from the checker.
> > 
> > This still requires manually constructing a symbol, now it's just performed 
> > in the analyzer instead of in a checker. Not sure if that addresses the 
> > issue you were considering, but the idea that we need to 'undo' the LCV 
> > optimization hiding the SymbolRef to have a value to taint seems somewhat 
> > convincing to me. What do you think?
> Hmm (!) I suggest adding a new function to the program state, that we'd call 
> `addPartialTaint()` or something like that, and this function would accept a 
> symbol and a region and would act identically to passing a derived symbol 
> (from this symbol and that region) to `addTaint()` (but we wouldn't need to 
> actually construct a derived symbol here).
> 
> Such API would be easier to understand and use than the current approach that 
> forces the user to construct a derived symbol manually in the checker code. 
> Unfortunately, this checker's `getLCVSymbol()` would become a bit more 
> complicated (having various return types depending on circumstances), but 
> this misfortune seems more random than systematic to me.
> 
> Since we're having this new kind of partial taint, why don't we expose it in 
> the API.
I'm happy to implement it this way, but figured I'd ask why you prefer this 
approach first in the interest of keeping the TaintChecker simple! The optimal 
approach to me seems to be changing `getPointedToSymbol()` to 
`getPointedToSVal()` and having `addTaint(SVal)` call `addPartialTaint()` when 
it's passed an LCV sub-region. That way users of the taint interface like the 
TaintChecker have a clean way to add & check regardless of whether it's a 
SymbolRef or an LCV but the partial taint functionality is still exposed and 
documented for those who might want to use it in new ways.

Just curious to understand your rationale. Thanks for the feedback!


https://reviews.llvm.org/D30909



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


[PATCH] D31868: [analyzer] Check NULL pointer dereference issue for memset function

2017-04-10 Thread Leslie Zhai via Phabricator via cfe-commits
xiangzhai created this revision.

Hi LLVM developers,

As Anna mentioned:

> One idea is to check that we do not pass a pointer that is known to be NULL 
> to functions that are known to dereference pointers such as memcpy. There is 
> a checker that determines if a null pointer could be dereferenced already, 
> but there is no extension to check if such a pointer could be passed to a 
> function tat could dereference it.

So I implemented `evalMemset` in the CStringChecker to detect null-deref issue. 
please review my patch, thanks a lot!

Regards,
Leslie Zhai


Repository:
  rL LLVM

https://reviews.llvm.org/D31868

Files:
  lib/StaticAnalyzer/Checkers/CStringChecker.cpp
  test/Analysis/null-deref-ps-region.c

Index: test/Analysis/null-deref-ps-region.c
===
--- test/Analysis/null-deref-ps-region.c
+++ test/Analysis/null-deref-ps-region.c
@@ -1,6 +1,9 @@
-// RUN: %clang_analyze_cc1 -analyzer-checker=core,alpha.core -std=gnu99 -analyzer-store=region -verify %s
-// expected-no-diagnostics
+// RUN: %clang_analyze_cc1 -analyzer-checker=core,alpha.core,unix,alpha.unix -std=gnu99 -analyzer-store=region -verify %s
 
+#include "Inputs/system-header-simulator.h"
+
+typedef __typeof(sizeof(int)) size_t;
+void *memset (void *__s, int __c, size_t __n);
 
 // The store for 'a[1]' should not be removed mistakenly. SymbolicRegions may
 // also be live roots.
@@ -13,3 +16,18 @@
 i = *p; // no-warning
   }
 }
+
+void f531() {
+  int *x = 0;
+  memset(x, 0, 1); // expected-warning {{Null pointer argument in call to memory set function}}
+}
+
+void f66() {
+  char buf[1];
+  memset(buf, 0, 1024); // expected-warning {{Memory set function accesses out-of-bound array element}}
+}
+
+void f77() {
+  char buf[1];
+  memset(buf, 0, sizeof(buf)); // no-warning
+}
Index: lib/StaticAnalyzer/Checkers/CStringChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/CStringChecker.cpp
+++ lib/StaticAnalyzer/Checkers/CStringChecker.cpp
@@ -120,6 +120,7 @@
   void evalStdCopy(CheckerContext , const CallExpr *CE) const;
   void evalStdCopyBackward(CheckerContext , const CallExpr *CE) const;
   void evalStdCopyCommon(CheckerContext , const CallExpr *CE) const;
+  void evalMemset(CheckerContext , const CallExpr *CE) const;
 
   // Utility methods
   std::pair
@@ -1999,6 +2000,63 @@
   C.addTransition(State);
 }
 
+void CStringChecker::evalMemset(CheckerContext , const CallExpr *CE) const {
+  if (CE->getNumArgs() < 3)
+return;
+
+  CurrentFunctionDescription = "memory set function";
+
+  const Expr *S = CE->getArg(0);
+  const Expr *Size = CE->getArg(2);
+  ProgramStateRef state = C.getState();
+
+  // See if the size argument is zero.
+  const LocationContext *LCtx = C.getLocationContext();
+  SVal sizeVal = state->getSVal(Size, LCtx);
+  QualType sizeTy = Size->getType();
+
+  ProgramStateRef stateZeroSize, stateNonZeroSize;
+  std::tie(stateZeroSize, stateNonZeroSize) =
+assumeZero(C, state, sizeVal, sizeTy);
+
+  // Get the value of the memory area pointed to by S.
+  SVal sVal = state->getSVal(S, LCtx);
+
+  // If the size is zero, there won't be any actual memory access, so   
+  // just bind the return value to the destination buffer and return.
+  if (stateZeroSize && !stateNonZeroSize) {
+stateZeroSize = stateZeroSize->BindExpr(CE, LCtx, sVal);
+C.addTransition(stateZeroSize);
+return;
+  }
+
+  // If the size can be nonzero, we have to check the other arguments.
+  if (stateNonZeroSize) {
+state = stateNonZeroSize;
+
+// Ensure the memory area pointed to by s is not null. 
+// If it is NULL there will be a NULL pointer dereference.
+state = checkNonNull(C, state, S, sVal);
+if (!state)
+  return;
+
+// Ensure the accesses are valid.
+state = CheckBufferAccess(C, state, Size, S);
+if (!state)
+  return;
+
+// Return the memory area pointed to by s buffer.
+state = state->BindExpr(CE, LCtx, sVal);
+
+// Invalidate the memory area pointed to by s (regular invalidation without 
+// pointer-escaping the address of the top-level region). 
+state = InvalidateBuffer(C, state, S, C.getSVal(S),
+ /*IsSourceBuffer*/false, Size);
+
+C.addTransition(state);
+  }
+}
+
 static bool isCPPStdLibraryFunction(const FunctionDecl *FD, StringRef Name) {
   IdentifierInfo *II = FD->getIdentifier();
   if (!II)
@@ -2032,6 +2090,8 @@
 evalFunction =  ::evalMemcmp;
   else if (C.isCLibraryFunction(FDecl, "memmove"))
 evalFunction =  ::evalMemmove;
+  else if (C.isCLibraryFunction(FDecl, "memset"))
+evalFunction =  ::evalMemset;
   else if (C.isCLibraryFunction(FDecl, "strcpy"))
 evalFunction =  ::evalStrcpy;
   else if (C.isCLibraryFunction(FDecl, "strncpy"))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org

[PATCH] D31696: Automatically add include-what-you-use for when building in tree

2017-04-10 Thread Kim Gräsman via Phabricator via cfe-commits
kimgr added inline comments.



Comment at: clang/tools/CMakeLists.txt:35
+# if include-what-you-use is cloned for building in-tree, add it here.
+if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/include-what-you-use")
+  add_clang_subdirectory(include-what-you-use)

beanz wrote:
> rnk wrote:
> > Maybe we should do `llvm_add_implicit_projects(CLANG)` here instead?
> > 
> > Or do we not want clang/tools to be a project extension point? Would IWYU 
> > build fine if we added it to llvm/projects or llvm/tools? Maybe we should 
> > just recommend that.
> Either `llvm_add_implicit_projects(CLANG)` or 
> `add_llvm_external_project(include-what-you-use include-what-you-use)`.
> 
> The former case would make this a generic extension point, which I think is 
> good, the later would add just this project without needing to wrap it in an 
> `if`.
> 
> I would prefer going the implicit route because I actually have a distaste 
> for having code living in-tree that is specifically for supporting 
> out-of-tree code.
> Would IWYU build fine if we added it to llvm/projects or llvm/tools? Maybe we 
> should just recommend that.

IWYU has all dependencies explicitly listed to support out-of-tree builds too, 
so I think it could be made to work with some include/lib path setup. But it 
would feel weird layering-wise, since it depends so heavily on clang.

As for `llvm_add_implicit_projects` vs `add_llvm_external_project`, I'm 
guessing it doesn't make a difference for IWYU's CMake system? Mild preference 
for `llvm_add_implicit_projects` to keep mention of `include-what-you-use` out 
of Clang until we can form a coherent story about upstreaming.


https://reviews.llvm.org/D31696



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


[PATCH] D31766: [Clang][X86][SSE] Update MOVNTDQA non-temporal loads to generic implementation

2017-04-10 Thread Craig Topper via Phabricator via cfe-commits
craig.topper accepted this revision.
craig.topper added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rL LLVM

https://reviews.llvm.org/D31766



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


[PATCH] D27251: [PPC] some bugs mainly about sign problem fixed in altivec.h

2017-04-10 Thread Nemanja Ivanovic via Phabricator via cfe-commits
nemanjai added a comment.

@Zeson are you working on an update to this or is this to be abandoned?


https://reviews.llvm.org/D27251



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


[PATCH] D31856: Headers: Make the type of SIZE_MAX the same as size_t

2017-04-10 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith created this revision.

size_t is usually defined as unsigned long, but on 64-bit platforms,
stdint.h currently defines SIZE_MAX using "ull" (unsigned long long).
Although this is the same width, it doesn't necessarily have the same
alignment or calling convention.  It also triggers printf warnings when
using the format flag "%zu" to print SIZE_MAX.

1. Is there a better way to get the right type for SIZE_MAX?
2. Should we do this for ptrdiff_t as well?


https://reviews.llvm.org/D31856

Files:
  clang/lib/Headers/stdint.h
  clang/test/Headers/stdint-type-of-SIZE_MAX.cpp


Index: clang/test/Headers/stdint-type-of-SIZE_MAX.cpp
===
--- /dev/null
+++ clang/test/Headers/stdint-type-of-SIZE_MAX.cpp
@@ -0,0 +1,6 @@
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only %s
+#include 
+#include 
+
+static_assert(__is_same(__typeof__(SIZE_MAX), size_t),
+  "SIZE_MAX should be size_t");
Index: clang/lib/Headers/stdint.h
===
--- clang/lib/Headers/stdint.h
+++ clang/lib/Headers/stdint.h
@@ -664,7 +664,7 @@
 #define UINTPTR_MAX __UINTN_MAX(__INTPTR_WIDTH__)
 #define PTRDIFF_MIN  __INTN_MIN(__PTRDIFF_WIDTH__)
 #define PTRDIFF_MAX  __INTN_MAX(__PTRDIFF_WIDTH__)
-#defineSIZE_MAX __UINTN_MAX(__SIZE_WIDTH__)
+#defineSIZE_MAX ((__SIZE_TYPE__)__UINTN_MAX(__SIZE_WIDTH__))
 
 /* ISO9899:2011 7.20 (C11 Annex K): Define RSIZE_MAX if __STDC_WANT_LIB_EXT1__
  * is enabled. */


Index: clang/test/Headers/stdint-type-of-SIZE_MAX.cpp
===
--- /dev/null
+++ clang/test/Headers/stdint-type-of-SIZE_MAX.cpp
@@ -0,0 +1,6 @@
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only %s
+#include 
+#include 
+
+static_assert(__is_same(__typeof__(SIZE_MAX), size_t),
+  "SIZE_MAX should be size_t");
Index: clang/lib/Headers/stdint.h
===
--- clang/lib/Headers/stdint.h
+++ clang/lib/Headers/stdint.h
@@ -664,7 +664,7 @@
 #define UINTPTR_MAX __UINTN_MAX(__INTPTR_WIDTH__)
 #define PTRDIFF_MIN  __INTN_MIN(__PTRDIFF_WIDTH__)
 #define PTRDIFF_MAX  __INTN_MAX(__PTRDIFF_WIDTH__)
-#defineSIZE_MAX __UINTN_MAX(__SIZE_WIDTH__)
+#defineSIZE_MAX ((__SIZE_TYPE__)__UINTN_MAX(__SIZE_WIDTH__))
 
 /* ISO9899:2011 7.20 (C11 Annex K): Define RSIZE_MAX if __STDC_WANT_LIB_EXT1__
  * is enabled. */
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D31862: docs/clang-tidy/tools/dump_check_docs.py: Remove deprecated script

2017-04-10 Thread Sylvestre Ledru via Phabricator via cfe-commits
sylvestre.ledru created this revision.

This has been used to create the doc from the code comments.

Now, this is very out of sync.


https://reviews.llvm.org/D31862

Files:
  docs/clang-tidy/tools/dump_check_docs.py


Index: docs/clang-tidy/tools/dump_check_docs.py
===
--- docs/clang-tidy/tools/dump_check_docs.py
+++ docs/clang-tidy/tools/dump_check_docs.py
@@ -1,79 +0,0 @@
-#!/usr/bin/env python
-
-r"""
-Create stubs for check documentation files.
-"""
-
-import os
-import re
-import sys
-
-def main():
-  clang_tidy_dir = os.path.normpath(
-  os.path.join(os.path.dirname(sys.argv[0]), '..', '..', '..',
-   'clang-tidy'))
-
-  checks_doc_dir = os.path.normpath(
-  os.path.join(clang_tidy_dir, '..', 'docs', 'clang-tidy', 'checks'))
-
-  registered_checks = {}
-  defined_checks = {}
-
-  for dir_name, subdir_list, file_list in os.walk(clang_tidy_dir):
-print('Processing directory ' + dir_name + '...')
-for file_name in file_list:
-  full_name = os.path.join(dir_name, file_name)
-  if file_name.endswith('Module.cpp'):
-print('Module ' + file_name)
-with open(full_name, 'r') as f:
-  text = f.read()
-for class_name, check_name in re.findall(
-r'\.\s*registerCheck\s*<\s*([A-Za-z0-9:]+)\s*>\(\s*"([a-z0-9-]+)"',
-text):
-  registered_checks[check_name] = class_name
-  elif file_name.endswith('.h'):
-print('' + file_name + '...')
-with open(full_name, 'r') as f:
-  text = f.read()
-for comment, _, _, class_name in re.findall(
-r'((([\r\n]//)[^\r\n]*)*)\s+class (\w+)\s*:' +
-'\s*public\s+ClangTidyCheck\s*\{', text):
-  defined_checks[class_name] = comment
-
-  print('Registered checks [%s]: [%s]' %
-(len(registered_checks), registered_checks))
-  print('Check implementations: %s' % len(defined_checks))
-
-  checks = registered_checks.keys()
-  checks.sort()
-
-  for check_name in checks:
-doc_file_name = os.path.join(checks_doc_dir, check_name + '.rst')
-#if os.path.exists(doc_file_name):
-#  print('Skipping existing file %s...')
-#  continue
-print('Updating %s...' % doc_file_name)
-with open(doc_file_name, 'w') as f:
-  class_name = re.sub(r'.*:', '', registered_checks[check_name])
-  f.write(check_name + '\n' + ('=' * len(check_name)) + '\n\n')
-  if class_name in defined_checks:
-text = defined_checks[class_name]
-text = re.sub(r'\n//+ ?(\\brief )?', r'\n', text)
-text = re.sub(r'(\n *)\\code\n', r'\1.. code:: c++\n\n', text)
-text = re.sub(r'(\n *)\\endcode(\n|$)', r'\n', text)
-text = re.sub(r'`', r'``', text)
-f.write(text + '\n')
-  else:
-f.write('TODO: add docs\n')
-
-  with open(os.path.join(checks_doc_dir, 'list.rst'), 'w') as f:
-f.write(
-r"""List of clang-tidy Checks
-=
-
-.. toctree::
-   """ + '\n   '.join(checks))
-
-
-if __name__ == '__main__':
-  main()


Index: docs/clang-tidy/tools/dump_check_docs.py
===
--- docs/clang-tidy/tools/dump_check_docs.py
+++ docs/clang-tidy/tools/dump_check_docs.py
@@ -1,79 +0,0 @@
-#!/usr/bin/env python
-
-r"""
-Create stubs for check documentation files.
-"""
-
-import os
-import re
-import sys
-
-def main():
-  clang_tidy_dir = os.path.normpath(
-  os.path.join(os.path.dirname(sys.argv[0]), '..', '..', '..',
-   'clang-tidy'))
-
-  checks_doc_dir = os.path.normpath(
-  os.path.join(clang_tidy_dir, '..', 'docs', 'clang-tidy', 'checks'))
-
-  registered_checks = {}
-  defined_checks = {}
-
-  for dir_name, subdir_list, file_list in os.walk(clang_tidy_dir):
-print('Processing directory ' + dir_name + '...')
-for file_name in file_list:
-  full_name = os.path.join(dir_name, file_name)
-  if file_name.endswith('Module.cpp'):
-print('Module ' + file_name)
-with open(full_name, 'r') as f:
-  text = f.read()
-for class_name, check_name in re.findall(
-r'\.\s*registerCheck\s*<\s*([A-Za-z0-9:]+)\s*>\(\s*"([a-z0-9-]+)"',
-text):
-  registered_checks[check_name] = class_name
-  elif file_name.endswith('.h'):
-print('' + file_name + '...')
-with open(full_name, 'r') as f:
-  text = f.read()
-for comment, _, _, class_name in re.findall(
-r'((([\r\n]//)[^\r\n]*)*)\s+class (\w+)\s*:' +
-'\s*public\s+ClangTidyCheck\s*\{', text):
-  defined_checks[class_name] = comment
-
-  print('Registered checks [%s]: [%s]' %
-(len(registered_checks), registered_checks))
-  print('Check implementations: %s' % len(defined_checks))
-
-  checks = registered_checks.keys()
-  checks.sort()
-
-  for check_name in checks:
-doc_file_name = os.path.join(checks_doc_dir, check_name + 

[PATCH] D31860: Add more examples to clang tidy checkers

2017-04-10 Thread Sylvestre Ledru via Phabricator via cfe-commits
sylvestre.ledru created this revision.
sylvestre.ledru added a project: clang-tools-extra.

https://reviews.llvm.org/D31860

Files:
  docs/clang-tidy/checks/llvm-namespace-comment.rst
  docs/clang-tidy/checks/llvm-twine-local.rst
  docs/clang-tidy/checks/misc-inefficient-algorithm.rst
  docs/clang-tidy/checks/misc-unused-parameters.rst
  docs/clang-tidy/checks/performance-type-promotion-in-math-fn.rst
  docs/clang-tidy/checks/readability-redundant-string-init.rst
  docs/clang-tidy/checks/readability-uniqueptr-delete-release.rst

Index: docs/clang-tidy/checks/readability-uniqueptr-delete-release.rst
===
--- docs/clang-tidy/checks/readability-uniqueptr-delete-release.rst
+++ docs/clang-tidy/checks/readability-uniqueptr-delete-release.rst
@@ -5,3 +5,11 @@
 
 Replace ``delete .release()`` with `` = nullptr``.
 The latter is shorter, simpler and does not require use of raw pointer APIs.
+
+.. code-block:: c++
+
+  delete P.release();
+
+  // becomes
+
+  P = nullptr;
Index: docs/clang-tidy/checks/readability-redundant-string-init.rst
===
--- docs/clang-tidy/checks/readability-redundant-string-init.rst
+++ docs/clang-tidy/checks/readability-redundant-string-init.rst
@@ -12,3 +12,8 @@
   // Initializing string with empty string literal is unnecessary.
   std::string a = "";
   std::string b("");
+
+  // becomes
+
+  std::string a;
+  std::string b;
Index: docs/clang-tidy/checks/performance-type-promotion-in-math-fn.rst
===
--- docs/clang-tidy/checks/performance-type-promotion-in-math-fn.rst
+++ docs/clang-tidy/checks/performance-type-promotion-in-math-fn.rst
@@ -9,3 +9,13 @@
 For example, warns on ``::sin(0.f)``, because this funciton's parameter is a
 double. You probably meant to call ``std::sin(0.f)`` (in C++), or ``sinf(0.f)``
 (in C).
+
+.. code-block:: c++
+
+  float a;
+  asin(a);
+
+  // becomes
+
+  float a;
+  std::asin(a);
Index: docs/clang-tidy/checks/misc-unused-parameters.rst
===
--- docs/clang-tidy/checks/misc-unused-parameters.rst
+++ docs/clang-tidy/checks/misc-unused-parameters.rst
@@ -5,3 +5,21 @@
 
 Finds unused parameters and fixes them, so that `-Wunused-parameter` can be
 turned on.
+
+.. code-block:: c++
+
+  void a(int i) {}
+
+  // becomes
+
+  void a(int  /*i*/) {}
+
+
+.. code-block:: c++
+
+  static void staticFunctionA(int i);
+  static void staticFunctionA(int i) {}
+
+  // becomes
+
+  static void staticFunctionA()
Index: docs/clang-tidy/checks/misc-inefficient-algorithm.rst
===
--- docs/clang-tidy/checks/misc-inefficient-algorithm.rst
+++ docs/clang-tidy/checks/misc-inefficient-algorithm.rst
@@ -9,3 +9,21 @@
 Associative containers implements some of the algorithms as methods which
 should be preferred to the algorithms in the algorithm header. The methods
 can take advanatage of the order of the elements.
+
+.. code-block:: c++
+
+  std::set s;
+  auto it = std::find(s.begin(), s.end(), 43);
+
+  // becomes
+
+  auto it = s.find(43);
+
+.. code-block:: c++
+
+  std::set s;
+  auto c = count(s.begin(), s.end(), 43);
+
+  // becomes
+
+  auto c = s.count(43);
Index: docs/clang-tidy/checks/llvm-twine-local.rst
===
--- docs/clang-tidy/checks/llvm-twine-local.rst
+++ docs/clang-tidy/checks/llvm-twine-local.rst
@@ -6,3 +6,11 @@
 
 Looks for local ``Twine`` variables which are prone to use after frees and
 should be generally avoided.
+
+.. code-block:: c++
+
+  static Twine Moo = Twine("bark") + "bah";
+
+  // becomes
+
+  static std::string Moo = (Twine("bark") + "bah").str();
Index: docs/clang-tidy/checks/llvm-namespace-comment.rst
===
--- docs/clang-tidy/checks/llvm-namespace-comment.rst
+++ docs/clang-tidy/checks/llvm-namespace-comment.rst
@@ -12,6 +12,19 @@
 
 https://google.github.io/styleguide/cppguide.html#Namespaces
 
+.. code-block:: c++
+
+  namespace n1 {
+  void f();
+  }
+
+  // becomes
+
+  namespace n1 {
+  void f();
+  }  // namespace n1
+
+
 Options
 ---
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D31561: cmath: Skip Libc for integral types in isinf, etc.

2017-04-10 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith added a comment.

Ping.


https://reviews.llvm.org/D31561



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


[PATCH] D30954: Modules: Simulate diagnostic settings for implicit modules

2017-04-10 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith added a comment.

Thanks for the review!  Somehow I missed it until now (I think I must have an 
"ignore rsmith" filter set up), but I should find a chance to rebase and commit 
tomorrow or Monday.


https://reviews.llvm.org/D30954



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


[PATCH] D31853: [clangd] Implement item kind for completion results

2017-04-10 Thread Stanislav Ionascu via Phabricator via cfe-commits
stanionascu created this revision.
stanionascu added a project: clang-tools-extra.

The patch implements the conversion method from CXCursorKind to 
clangd::CompletionItemKind.


https://reviews.llvm.org/D31853

Files:
  clangd/ASTManager.cpp
  clangd/Protocol.cpp
  test/clangd/completion.test

Index: test/clangd/completion.test
===
--- test/clangd/completion.test
+++ test/clangd/completion.test
@@ -16,9 +16,9 @@
 # nondeterministic, so we check regardless of order.
 #
 # CHECK: {"jsonrpc":"2.0","id":1,"result":[
-# CHECK-DAG: {"label":"a"}
-# CHECK-DAG: {"label":"bb"}
-# CHECK-DAG: {"label":"ccc"}
+# CHECK-DAG: {"label":"a","kind":5}
+# CHECK-DAG: {"label":"bb","kind":5}
+# CHECK-DAG: {"label":"ccc","kind":5}
 # CHECK: ]}
 Content-Length: 44
 
Index: clangd/Protocol.cpp
===
--- clangd/Protocol.cpp
+++ clangd/Protocol.cpp
@@ -645,7 +645,7 @@
   assert(!CI.label.empty() && "completion item label is required");
   Os << R"("label":")" << llvm::yaml::escape(CI.label) << R"(",)";
   if (CI.kind != CompletionItemKind::Missing)
-Os << R"("kind":)" << static_cast(CI.kind) << R"(",)";
+Os << R"("kind":)" << static_cast(CI.kind) << R"(,)";
   if (!CI.detail.empty())
 Os << R"("detail":")" << llvm::yaml::escape(CI.detail) << R"(",)";
   if (!CI.documentation.empty())
Index: clangd/ASTManager.cpp
===
--- clangd/ASTManager.cpp
+++ clangd/ASTManager.cpp
@@ -53,6 +53,49 @@
   llvm_unreachable("Unknown diagnostic level!");
 }
 
+static CompletionItemKind getKind(CXCursorKind K) {
+  switch (K) {
+  case CXCursor_MacroInstantiation:
+  case CXCursor_MacroDefinition:
+return CompletionItemKind::Text;
+  case CXCursor_CXXMethod:
+return CompletionItemKind::Method;
+  case CXCursor_FunctionDecl:
+  case CXCursor_FunctionTemplate:
+return CompletionItemKind::Function;
+  case CXCursor_Constructor:
+  case CXCursor_Destructor:
+return CompletionItemKind::Constructor;
+  case CXCursor_FieldDecl:
+return CompletionItemKind::Field;
+  case CXCursor_VarDecl:
+  case CXCursor_ParmDecl:
+return CompletionItemKind::Variable;
+  case CXCursor_ClassDecl:
+  case CXCursor_StructDecl:
+  case CXCursor_UnionDecl:
+  case CXCursor_ClassTemplate:
+  case CXCursor_ClassTemplatePartialSpecialization:
+return CompletionItemKind::Class;
+  case CXCursor_Namespace:
+  case CXCursor_NamespaceAlias:
+  case CXCursor_NamespaceRef:
+return CompletionItemKind::Module;
+  case CXCursor_EnumConstantDecl:
+return CompletionItemKind::Value;
+  case CXCursor_EnumDecl:
+return CompletionItemKind::Enum;
+  case CXCursor_TypeAliasDecl:
+  case CXCursor_TypeAliasTemplateDecl:
+  case CXCursor_TypedefDecl:
+  case CXCursor_MemberRef:
+  case CXCursor_TypeRef:
+return CompletionItemKind::Reference;
+  default:
+return CompletionItemKind::Missing;
+  }
+}
+
 ASTManager::ASTManager(JSONOutput , DocumentStore ,
bool RunSynchronously)
 : Output(Output), Store(Store), RunSynchronously(RunSynchronously),
@@ -252,13 +295,15 @@
   CodeCompletionResult *Results,
   unsigned NumResults) override {
 for (unsigned I = 0; I != NumResults; ++I) {
-  CodeCompletionString *CCS = Results[I].CreateCodeCompletionString(
+  CodeCompletionResult  = Results[I];
+  CodeCompletionString *CCS = Result.CreateCodeCompletionString(
   S, Context, *Allocator, CCTUInfo,
   CodeCompleteOpts.IncludeBriefComments);
   if (CCS) {
 CompletionItem Item;
 assert(CCS->getTypedText());
 Item.label = CCS->getTypedText();
+Item.kind = getKind(Result.CursorKind);
 if (CCS->getBriefComment())
   Item.documentation = CCS->getBriefComment();
 Items->push_back(std::move(Item));
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D31830: Emit invariant.group.barrier when using union field

2017-04-10 Thread Piotr Padlewski via Phabricator via cfe-commits
Prazek created this revision.

We need to emit barrier if the union field
is CXXRecordDecl because it might have vptrs. The testcode 
was wrongly devirtualized. It also proves that having different
groups for different dynamic types is not sufficient.


https://reviews.llvm.org/D31830

Files:
  lib/CodeGen/CGExpr.cpp
  test/CodeGenCXX/strict-vtable-pointers.cpp


Index: test/CodeGenCXX/strict-vtable-pointers.cpp
===
--- test/CodeGenCXX/strict-vtable-pointers.cpp
+++ test/CodeGenCXX/strict-vtable-pointers.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 %s -I%S -triple=x86_64-apple-darwin10 
-fstrict-vtable-pointers -disable-llvm-passes -O2 -emit-llvm -o %t.ll
+// RUN: %clang_cc1 %s -I%S -triple=x86_64-apple-darwin10 
-fstrict-vtable-pointers -std=c++11 -disable-llvm-passes -O2 -emit-llvm -o %t.ll
 // RUN: FileCheck --check-prefix=CHECK-CTORS %s < %t.ll
 // RUN: FileCheck --check-prefix=CHECK-NEW %s < %t.ll
 // RUN: FileCheck --check-prefix=CHECK-DTORS %s < %t.ll
@@ -180,6 +180,62 @@
 // CHECK-CTORS-NOT: @llvm.invariant.group.barrier(
 // CHECK-CTORS-LABEL: {{^}}}
 
+struct A {
+  virtual void foo();
+};
+struct B : A {
+  virtual void foo();
+};
+
+union U {
+  A a;
+  B b;
+};
+
+void changeToB(U *u);
+void changeToA(U *u);
+
+void g2(A *a) {
+  a->foo();
+}
+// We have to guard access to union fields with invariant.group, because
+// it is very easy to skip the barrier with unions. In this example the inlined
+// g2 will produce loads with the same !invariant.group metadata, and
+// u->a and u->b would use the same pointer.
+// CHECK-NEW-LABEL: define void @_Z14UnionsBarriersP1U
+void UnionsBarriers(U *u) {
+  // CHECK-NEW: call void @_Z9changeToBP1U(
+  changeToB(u);
+  // CHECK-NEW: call i8* @llvm.invariant.group.barrier(i8*
+  // CHECK-NEW: call void @_Z2g2P1A(%struct.A*
+  g2(>b);
+  // CHECK-NEW: call void @_Z9changeToAP1U(%union.U* %6)
+  changeToA(u);
+  // CHECK-NEW: call i8* @llvm.invariant.group.barrier(i8*
+  // call void @_Z2g2P1A(%struct.A* %a)
+  g2(>a);
+  // CHECK-NEW-NOT: call i8* @llvm.invariant.group.barrier(i8*
+}
+
+struct HoldingVirtuals {
+  A a;
+};
+
+union U2 {
+  HoldingVirtuals h;
+  int z;
+};
+void take(HoldingVirtuals &);
+
+// CHECK-NEW-LABEL: define void @_Z15UnionsBarriers2R2U2
+void UnionsBarriers2(U2 ) {
+  // CHECK-NEW-NOT: call i8* @llvm.invariant.group.barrier(i8*
+  // CHECK-NEW: 42
+  u.z += 42;
+  // CHECK-NEW: call i8* @llvm.invariant.group.barrier(i8*
+  // CHECK-NEW: call void @_Z4takeR15HoldingVirtuals(
+  take(u.h);
+}
 
 /** DTORS **/
 // CHECK-DTORS-LABEL: define linkonce_odr void @_ZN10StaticBaseD2Ev(
Index: lib/CodeGen/CGExpr.cpp
===
--- lib/CodeGen/CGExpr.cpp
+++ lib/CodeGen/CGExpr.cpp
@@ -3508,6 +3508,15 @@
 assert(!type->isReferenceType() && "union has reference member");
 // TODO: handle path-aware TBAA for union.
 TBAAPath = false;
+// Because unions can easily skip invariant.barriers, we need to add
+// a barrier every time CXXRecord field is referenced. We don't check if
+// it is dynamic type because it might have dynamic member, so we would
+// have to check it recursively.
+if (field->getType().getTypePtr()->getAsCXXRecordDecl() &&
+CGM.getCodeGenOpts().StrictVTablePointers &&
+CGM.getCodeGenOpts().OptimizationLevel > 0)
+  addr = Address(Builder.CreateInvariantGroupBarrier(addr.getPointer()),
+ addr.getAlignment());
   } else {
 // For structs, we GEP to the field that the record layout suggests.
 addr = emitAddrOfFieldStorage(*this, addr, field);


Index: test/CodeGenCXX/strict-vtable-pointers.cpp
===
--- test/CodeGenCXX/strict-vtable-pointers.cpp
+++ test/CodeGenCXX/strict-vtable-pointers.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 %s -I%S -triple=x86_64-apple-darwin10 -fstrict-vtable-pointers -disable-llvm-passes -O2 -emit-llvm -o %t.ll
+// RUN: %clang_cc1 %s -I%S -triple=x86_64-apple-darwin10 -fstrict-vtable-pointers -std=c++11 -disable-llvm-passes -O2 -emit-llvm -o %t.ll
 // RUN: FileCheck --check-prefix=CHECK-CTORS %s < %t.ll
 // RUN: FileCheck --check-prefix=CHECK-NEW %s < %t.ll
 // RUN: FileCheck --check-prefix=CHECK-DTORS %s < %t.ll
@@ -180,6 +180,62 @@
 // CHECK-CTORS-NOT: @llvm.invariant.group.barrier(
 // CHECK-CTORS-LABEL: {{^}}}
 
+struct A {
+  virtual void foo();
+};
+struct B : A {
+  virtual void foo();
+};
+
+union U {
+  A a;
+  B b;
+};
+
+void changeToB(U *u);
+void changeToA(U *u);
+
+void g2(A *a) {
+  a->foo();
+}
+// We have to guard access to union fields with invariant.group, because
+// it is very easy to skip the barrier with unions. In this example the inlined
+// g2 will produce loads with the same !invariant.group metadata, and
+// u->a and u->b would use the same pointer.
+// CHECK-NEW-LABEL: define void @_Z14UnionsBarriersP1U
+void UnionsBarriers(U *u) {

[PATCH] D31839: make -Winteger-overflow find overflows in function arguments

2017-04-10 Thread Nick Lewycky via Phabricator via cfe-commits
nlewycky created this revision.

When checkingForOverflow(), look through call arguments (and the callee itself 
if calculated).

Make the statement visitor go through ObjCBoxedExpr by default because it has a 
single subexpr node. Don't do that when looking for a pointer object, stop 
because the boxed expr is the pointer.


https://reviews.llvm.org/D31839

Files:
  include/clang/Sema/Sema.h
  lib/AST/ExprConstant.cpp
  lib/Sema/SemaChecking.cpp
  lib/Sema/SemaExprObjC.cpp
  test/OpenMP/distribute_parallel_for_simd_aligned_messages.cpp
  test/OpenMP/distribute_simd_aligned_messages.cpp
  test/OpenMP/for_simd_aligned_messages.cpp
  test/OpenMP/parallel_for_simd_aligned_messages.cpp
  test/OpenMP/simd_aligned_messages.cpp
  test/OpenMP/target_parallel_for_simd_aligned_messages.cpp
  test/OpenMP/target_simd_aligned_messages.cpp
  test/OpenMP/target_teams_distribute_parallel_for_simd_aligned_messages.cpp
  test/OpenMP/target_teams_distribute_simd_aligned_messages.cpp
  test/OpenMP/taskloop_simd_aligned_messages.cpp
  test/OpenMP/teams_distribute_parallel_for_simd_aligned_messages.cpp
  test/OpenMP/teams_distribute_simd_aligned_messages.cpp
  test/SemaCXX/integer-overflow.cpp

Index: test/SemaCXX/integer-overflow.cpp
===
--- test/SemaCXX/integer-overflow.cpp
+++ test/SemaCXX/integer-overflow.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 %s -verify -fsyntax-only -std=gnu++98 -triple x86_64-pc-linux-gnu
+// RUN: %clang_cc1 %s -verify -std=gnu++98 -triple x86_64-pc-linux-gnu
 typedef unsigned long long uint64_t;
 typedef unsigned int uint32_t;
 
@@ -166,6 +166,9 @@
   uint64_t a[10];
   a[4608 * 1024 * 1024] = 1i;
 
+// expected-warning@+1 {{overflow in expression; result is 536870912 with type 'int'}}
+  f0(4608 * 1024 * 1024);
+
 // expected-warning@+1 2{{overflow in expression; result is 536870912 with type 'int'}}
   return ((4608 * 1024 * 1024) + ((uint64_t)(4608 * 1024 * 1024)));
 }
Index: test/OpenMP/teams_distribute_simd_aligned_messages.cpp
===
--- test/OpenMP/teams_distribute_simd_aligned_messages.cpp
+++ test/OpenMP/teams_distribute_simd_aligned_messages.cpp
@@ -123,9 +123,8 @@
 template int foomain(I argc, C **argv) {
   I e(argc);
   I g(argc);
-  int i; // expected-note {{declared here}} expected-note {{'i' defined here}}
-  // expected-note@+2 {{declared here}}
-  // expected-note@+1 {{reference to 'i' is not a constant expression}}
+  int i; // expected-note {{'i' defined here}}
+  // expected-note@+1 {{declared here}}
   int  = i;
 
 #pragma omp target
Index: test/OpenMP/teams_distribute_parallel_for_simd_aligned_messages.cpp
===
--- test/OpenMP/teams_distribute_parallel_for_simd_aligned_messages.cpp
+++ test/OpenMP/teams_distribute_parallel_for_simd_aligned_messages.cpp
@@ -123,9 +123,8 @@
 template int foomain(I argc, C **argv) {
   I e(argc);
   I g(argc);
-  int i; // expected-note {{declared here}} expected-note {{'i' defined here}}
-  // expected-note@+2 {{declared here}}
-  // expected-note@+1 {{reference to 'i' is not a constant expression}}
+  int i; // expected-note {{'i' defined here}}
+  // expected-note@+1 {{declared here}}
   int  = i;
 
 #pragma omp target
Index: test/OpenMP/taskloop_simd_aligned_messages.cpp
===
--- test/OpenMP/taskloop_simd_aligned_messages.cpp
+++ test/OpenMP/taskloop_simd_aligned_messages.cpp
@@ -107,9 +107,8 @@
 template int foomain(I argc, C **argv) {
   I e(argc);
   I g(argc);
-  int i; // expected-note {{declared here}} expected-note {{'i' defined here}}
-  // expected-note@+2 {{declared here}}
-  // expected-note@+1 {{reference to 'i' is not a constant expression}}
+  int i; // expected-note {{'i' defined here}}
+  // expected-note@+1 {{declared here}}
   int  = i;
   #pragma omp taskloop simd aligned // expected-error {{expected '(' after 'aligned'}}
   for (I k = 0; k < argc; ++k) ++k;
Index: test/OpenMP/target_teams_distribute_simd_aligned_messages.cpp
===
--- test/OpenMP/target_teams_distribute_simd_aligned_messages.cpp
+++ test/OpenMP/target_teams_distribute_simd_aligned_messages.cpp
@@ -110,9 +110,8 @@
 template int foomain(I argc, C **argv) {
   I e(argc);
   I g(argc);
-  int i; // expected-note {{declared here}} expected-note {{'i' defined here}}
-  // expected-note@+2 {{declared here}}
-  // expected-note@+1 {{reference to 'i' is not a constant expression}}
+  int i; // expected-note {{'i' defined here}}
+  // expected-note@+1 {{declared here}}
   int  = i;
 
 #pragma omp target teams distribute simd aligned // expected-error {{expected '(' after 'aligned'}}
Index: test/OpenMP/target_teams_distribute_parallel_for_simd_aligned_messages.cpp
===
--- 

[PATCH] D31756: [cmake] Support Gentoo install for z3

2017-04-10 Thread Michał Górny via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL299813: [cmake] Support Gentoo install for z3 (authored by 
mgorny).

Changed prior to commit:
  https://reviews.llvm.org/D31756?vs=94354=94594#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D31756

Files:
  cfe/trunk/cmake/modules/FindZ3.cmake


Index: cfe/trunk/cmake/modules/FindZ3.cmake
===
--- cfe/trunk/cmake/modules/FindZ3.cmake
+++ cfe/trunk/cmake/modules/FindZ3.cmake
@@ -1,5 +1,5 @@
 find_path(Z3_INCLUDE_DIR NAMES z3.h
-   PATH_SUFFIXES libz3
+   PATH_SUFFIXES libz3 z3
)
 
 find_library(Z3_LIBRARIES NAMES z3 libz3


Index: cfe/trunk/cmake/modules/FindZ3.cmake
===
--- cfe/trunk/cmake/modules/FindZ3.cmake
+++ cfe/trunk/cmake/modules/FindZ3.cmake
@@ -1,5 +1,5 @@
 find_path(Z3_INCLUDE_DIR NAMES z3.h
-   PATH_SUFFIXES libz3
+   PATH_SUFFIXES libz3 z3
)
 
 find_library(Z3_LIBRARIES NAMES z3 libz3
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D31869: Register isStaticStorageClass matcher

2017-04-10 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; I don't think this needs a test case.


https://reviews.llvm.org/D31869



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


[PATCH] D31840: [analyzer] Fix crash on access to property

2017-04-10 Thread Alexander Shaposhnikov via Phabricator via cfe-commits
alexshap created this revision.
alexshap created this object with visibility "All Users".

Preliminary context about unions:
at the moment for unions the static analyzer creates default bindings (as a 
compoundVal).
If a union has only one field x which is initialized to zero this is handled as 
an unknown val.

In the newly added test case a union contains a pointer to an objc object.
When the static analyzer (during the path sensitive analysis) processes the 
call of the objc method, 
in this particular case it will fall back on defaultEvalCall / 
conservativeEvalCall. The sub calls of invalidateRegions / 
getExtraInvalidatedValues assume that the returned MemRegion for the associated 
ivar is not zero, 
which is not the case here. Similarly to CXXInstanceCall we add the 
corresponding check to ObjCMethodCall.


Repository:
  rL LLVM

https://reviews.llvm.org/D31840

Files:
  lib/StaticAnalyzer/Core/CallEvent.cpp
  test/Analysis/properties.m


Index: test/Analysis/properties.m
===
--- test/Analysis/properties.m
+++ test/Analysis/properties.m
@@ -987,5 +987,21 @@
 }
 
 @end
+
+@interface Wrapper
+@property(nonatomic, readonly) int value;
+@end
+
+@implementation Wrapper
+@synthesize value;
+@end
+
+void testNoCrashWhenAccessPropertyAndThereAreNoDirectBindingsAtAll() {
+   union {
+Wrapper *wrapper;
+   } u = { 0 };
+   [u.wrapper value];
+}
+
 #endif // non-ARC
 
Index: lib/StaticAnalyzer/Core/CallEvent.cpp
===
--- lib/StaticAnalyzer/Core/CallEvent.cpp
+++ lib/StaticAnalyzer/Core/CallEvent.cpp
@@ -695,12 +695,14 @@
   if (const ObjCPropertyDecl *PropDecl = getAccessedProperty()) {
 if (const ObjCIvarDecl *PropIvar = PropDecl->getPropertyIvarDecl()) {
   SVal IvarLVal = getState()->getLValue(PropIvar, getReceiverSVal());
-  const MemRegion *IvarRegion = IvarLVal.getAsRegion();
-  ETraits->setTrait(
+  if (const MemRegion *IvarRegion = IvarLVal.getAsRegion()) {
+ETraits->setTrait(
   IvarRegion,
   RegionAndSymbolInvalidationTraits::TK_DoNotInvalidateSuperRegion);
-  ETraits->setTrait(IvarRegion,
-RegionAndSymbolInvalidationTraits::TK_SuppressEscape);
+ETraits->setTrait(
+  IvarRegion,
+  RegionAndSymbolInvalidationTraits::TK_SuppressEscape);
+  }
   Values.push_back(IvarLVal);
   return;
 }


Index: test/Analysis/properties.m
===
--- test/Analysis/properties.m
+++ test/Analysis/properties.m
@@ -987,5 +987,21 @@
 }
 
 @end
+
+@interface Wrapper
+@property(nonatomic, readonly) int value;
+@end
+
+@implementation Wrapper
+@synthesize value;
+@end
+
+void testNoCrashWhenAccessPropertyAndThereAreNoDirectBindingsAtAll() {
+   union {
+Wrapper *wrapper;
+   } u = { 0 };
+   [u.wrapper value];
+}
+
 #endif // non-ARC
 
Index: lib/StaticAnalyzer/Core/CallEvent.cpp
===
--- lib/StaticAnalyzer/Core/CallEvent.cpp
+++ lib/StaticAnalyzer/Core/CallEvent.cpp
@@ -695,12 +695,14 @@
   if (const ObjCPropertyDecl *PropDecl = getAccessedProperty()) {
 if (const ObjCIvarDecl *PropIvar = PropDecl->getPropertyIvarDecl()) {
   SVal IvarLVal = getState()->getLValue(PropIvar, getReceiverSVal());
-  const MemRegion *IvarRegion = IvarLVal.getAsRegion();
-  ETraits->setTrait(
+  if (const MemRegion *IvarRegion = IvarLVal.getAsRegion()) {
+ETraits->setTrait(
   IvarRegion,
   RegionAndSymbolInvalidationTraits::TK_DoNotInvalidateSuperRegion);
-  ETraits->setTrait(IvarRegion,
-RegionAndSymbolInvalidationTraits::TK_SuppressEscape);
+ETraits->setTrait(
+  IvarRegion,
+  RegionAndSymbolInvalidationTraits::TK_SuppressEscape);
+  }
   Values.push_back(IvarLVal);
   return;
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D25866: [Sema] Support implicit scalar to vector conversions

2017-04-10 Thread Bruno Cardoso Lopes via Phabricator via cfe-commits
bruno added inline comments.



Comment at: lib/Sema/SemaExpr.cpp:10024
+  // FIXME: The check for C++ here is for GCC compatibility. GCC rejects the
+  //usage of logical operators with vectors in C. This check could be
+  //notionally dropped.

Please mention in the comment the list of logical ops that this applies to: "!, 
&&, ||"



Comment at: test/Sema/vector-gcc-compat.c:101
+
+  v2i64_r = v2i64_a && 1; // expected-error {{invalid vector operand to binary 
expression ('v2i64' (vector of 2 'long long' values))}}
+  v2i64_r = v2i64_a || 1; // expected-error {{invalid vector operand to binary 
expression ('v2i64' (vector of 2 'long long' values))}}

Is this because of && and others only working in C++? If so, we need a better 
error message here, along the lines of "logical expression with vector only 
support in C++". If later on we decide to support it in non-C++, we then get 
rid of the warning.





https://reviews.llvm.org/D25866



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


[PATCH] D30295: [analyzer] clarify undef shift result when shift count is negative or exceeds the bit width

2017-04-10 Thread Anna Zaks via Phabricator via cfe-commits
zaks.anna added inline comments.



Comment at: include/clang/StaticAnalyzer/Core/PathSensitive/CheckerHelpers.h:46
 
-} // end GR namespace
+bool isExprResultConformsComparisonRule(CheckerContext ,
+BinaryOperatorKind CompRule,

NoQ wrote:
> Because you are making these functions public, i think it's worth it to make 
> it obvious what they do without looking at the particular checker code. 
> Comments are definitely worth it. I think function names could be worded 
> better; i suggest `exprComparesTo(const Expr *LHSExpr, BinaryOperatorKind 
> ComparisonOp, SVal RHSVal, CheckerContext );` and `isGreaterOrEqual(...)`; 
> i'm personally fond of having CheckerContext at the back because that's where 
> we have it in checker callbacks, but that's not important.
+ 1 on Artem's comment of making the names more clear and providing 
documentation. Also, should these be part of CheckerContext?


Repository:
  rL LLVM

https://reviews.llvm.org/D30295



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


[PATCH] D31760: [lsan] Enable LSan on arm Linux, clang part

2017-04-10 Thread Evgeniy Stepanov via Phabricator via cfe-commits
eugenis added a comment.

I think it should also include armeb and thumbeb for completeness.


Repository:
  rL LLVM

https://reviews.llvm.org/D31760



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


[PATCH] D31805: [clang-tidy] Mention "add the check to release note" in add_new_check.py.

2017-04-10 Thread Eugene Zelenko via Phabricator via cfe-commits
Eugene.Zelenko added a comment.

I don't know how hard it'll be to implement, but will be great to add

- New ` `_ check

  Please add short description here.

into "Improvements to clang-tidy" section. Ideally according to alphabetic 
order.


https://reviews.llvm.org/D31805



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


[PATCH] D31696: Automatically add include-what-you-use for when building in tree

2017-04-10 Thread Chris Bieneman via Phabricator via cfe-commits
beanz added inline comments.



Comment at: clang/tools/.gitignore:12
+#==#
+# The include-what-you-use project, for when building in-tree.
+include-what-you-use

rnk wrote:
> LLVM doesn't currently have any .gitignore files for other projects, and they 
> don't show up in `git status`. What's the difference here?
We actually should put this into the clang/.gitignore instead of a separate 
.gitignore in the tools directory. That is how we've done things in LLVM & 
Clang before.



Comment at: clang/tools/CMakeLists.txt:35
+# if include-what-you-use is cloned for building in-tree, add it here.
+if (EXISTS "${CMAKE_CURRENT_SOURCE_DIR}/include-what-you-use")
+  add_clang_subdirectory(include-what-you-use)

rnk wrote:
> Maybe we should do `llvm_add_implicit_projects(CLANG)` here instead?
> 
> Or do we not want clang/tools to be a project extension point? Would IWYU 
> build fine if we added it to llvm/projects or llvm/tools? Maybe we should 
> just recommend that.
Either `llvm_add_implicit_projects(CLANG)` or 
`add_llvm_external_project(include-what-you-use include-what-you-use)`.

The former case would make this a generic extension point, which I think is 
good, the later would add just this project without needing to wrap it in an 
`if`.

I would prefer going the implicit route because I actually have a distaste for 
having code living in-tree that is specifically for supporting out-of-tree code.


https://reviews.llvm.org/D31696



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


[PATCH] D31167: Use FPContractModeKind universally

2017-04-10 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added inline comments.



Comment at: cfe/trunk/include/clang/Basic/LangOptions.def:220
+/// \brief FP_CONTRACT mode (on/off/fast).
+ENUM_LANGOPT(DefaultFPContractMode, FPContractModeKind, 2, FPC_Off, "FP 
contraction type")
 LANGOPT(NoBitFieldTypeAlign , 1, 0, "bit-field type alignment")

This change seemed to cause some performance degradations in some OpenCL 
applications.

This option used to be on by default. Now it is off by default.

There are applications do separated compile/link/codegen stages. In the codegen 
stage, clang is invoked with .bc as input, therefore this option is off by 
default, whereas it was on by default before this change.

Is there any reason not to keep the original behavior?

Thanks.


Repository:
  rL LLVM

https://reviews.llvm.org/D31167



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


[PATCH] D31736: Implement _interlockedbittestandset as a builtin

2017-04-10 Thread Hans Wennborg via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL299782: Implement _interlockedbittestandset as a builtin 
(authored by hans).

Changed prior to commit:
  https://reviews.llvm.org/D31736?vs=94433=94539#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D31736

Files:
  cfe/trunk/include/clang/Basic/Builtins.def
  cfe/trunk/lib/CodeGen/CGBuiltin.cpp
  cfe/trunk/lib/Headers/intrin.h
  cfe/trunk/test/CodeGen/ms-intrinsics.c

Index: cfe/trunk/test/CodeGen/ms-intrinsics.c
===
--- cfe/trunk/test/CodeGen/ms-intrinsics.c
+++ cfe/trunk/test/CodeGen/ms-intrinsics.c
@@ -434,6 +434,17 @@
 
 #endif
 
+unsigned char test_interlockedbittestandset(volatile long *ptr, long bit) {
+  return _interlockedbittestandset(ptr, bit);
+}
+// CHECK-LABEL: define{{.*}} i8 @test_interlockedbittestandset
+// CHECK: %0 = shl i32 1, %bit
+// CHECK: %1 = atomicrmw or i32* %ptr, i32 %0 seq_cst
+// CHECK: %2 = lshr i32 %1, %bit
+// CHECK: %3 = trunc i32 %2 to i8
+// CHECK: %4 = and i8 %3, 1
+// CHECK: ret i8 %4
+
 void test__fastfail() {
   __fastfail(42);
 }
Index: cfe/trunk/lib/Headers/intrin.h
===
--- cfe/trunk/lib/Headers/intrin.h
+++ cfe/trunk/lib/Headers/intrin.h
@@ -173,7 +173,6 @@
 void __cdecl _enable(void);
 long _InterlockedAddLargeStatistic(__int64 volatile *_Addend, long _Value);
 unsigned char _interlockedbittestandreset(long volatile *, long);
-static __inline__
 unsigned char _interlockedbittestandset(long volatile *, long);
 long _InterlockedCompareExchange_HLEAcquire(long volatile *, long, long);
 long _InterlockedCompareExchange_HLERelease(long volatile *, long, long);
@@ -369,11 +368,6 @@
   *_BitBase = *_BitBase | (1 << _BitPos);
   return _Res;
 }
-static __inline__ unsigned char __DEFAULT_FN_ATTRS
-_interlockedbittestandset(long volatile *_BitBase, long _BitPos) {
-  long _PrevVal = __atomic_fetch_or(_BitBase, 1l << _BitPos, __ATOMIC_SEQ_CST);
-  return (_PrevVal >> _BitPos) & 1;
-}
 #if defined(__arm__) || defined(__aarch64__)
 static __inline__ unsigned char __DEFAULT_FN_ATTRS
 _interlockedbittestandset_acq(long volatile *_BitBase, long _BitPos) {
Index: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
===
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp
@@ -492,6 +492,7 @@
   _InterlockedIncrement,
   _InterlockedOr,
   _InterlockedXor,
+  _interlockedbittestandset,
   __fastfail,
 };
 
@@ -559,6 +560,22 @@
   case MSVCIntrin::_InterlockedXor:
 return MakeBinaryAtomicValue(*this, AtomicRMWInst::Xor, E);
 
+  case MSVCIntrin::_interlockedbittestandset: {
+llvm::Value *Addr = EmitScalarExpr(E->getArg(0));
+llvm::Value *Bit = EmitScalarExpr(E->getArg(1));
+AtomicRMWInst *RMWI = Builder.CreateAtomicRMW(
+AtomicRMWInst::Or, Addr,
+Builder.CreateShl(ConstantInt::get(Bit->getType(), 1), Bit),
+llvm::AtomicOrdering::SequentiallyConsistent);
+// Shift the relevant bit to the least significant position, truncate to
+// the result type, and test the low bit.
+llvm::Value *Shifted = Builder.CreateLShr(RMWI, Bit);
+llvm::Value *Truncated =
+Builder.CreateTrunc(Shifted, ConvertType(E->getType()));
+return Builder.CreateAnd(Truncated,
+ ConstantInt::get(Truncated->getType(), 1));
+  }
+
   case MSVCIntrin::_InterlockedDecrement: {
 llvm::Type *IntTy = ConvertType(E->getType());
 AtomicRMWInst *RMWI = Builder.CreateAtomicRMW(
@@ -2238,6 +2255,9 @@
   case Builtin::BI_InterlockedXor16:
   case Builtin::BI_InterlockedXor:
 return RValue::get(EmitMSVCBuiltinExpr(MSVCIntrin::_InterlockedXor, E));
+  case Builtin::BI_interlockedbittestandset:
+return RValue::get(
+EmitMSVCBuiltinExpr(MSVCIntrin::_interlockedbittestandset, E));
 
   case Builtin::BI__exception_code:
   case Builtin::BI_exception_code:
@@ -2309,10 +2329,8 @@
 break;
   }
 
-  case Builtin::BI__fastfail: {
+  case Builtin::BI__fastfail:
 return RValue::get(EmitMSVCBuiltinExpr(MSVCIntrin::__fastfail, E));
-break;
-  }
 
   case Builtin::BI__builtin_coro_size: {
 auto & Context = getContext();
Index: cfe/trunk/include/clang/Basic/Builtins.def
===
--- cfe/trunk/include/clang/Basic/Builtins.def
+++ cfe/trunk/include/clang/Basic/Builtins.def
@@ -756,6 +756,7 @@
 LANGBUILTIN(_InterlockedXor8,  "ccD*c",   "n", ALL_MS_LANGUAGES)
 LANGBUILTIN(_InterlockedXor16, "ssD*s",   "n", ALL_MS_LANGUAGES)
 LANGBUILTIN(_InterlockedXor,   "LiLiD*Li","n", ALL_MS_LANGUAGES)
+LANGBUILTIN(_interlockedbittestandset, "UcLiD*Li", "n", ALL_MS_LANGUAGES)
 LANGBUILTIN(__noop,   "i.",  "n", ALL_MS_LANGUAGES)
 LANGBUILTIN(__popcnt16, "UsUs", "nc", ALL_MS_LANGUAGES)
 LANGBUILTIN(__popcnt,   "UiUi", "nc", ALL_MS_LANGUAGES)

[PATCH] D31745: [OpenCL] Added diagnostic for implicit declaration of function in OpenCL

2017-04-10 Thread Egor Churaev via Phabricator via cfe-commits
echuraev added inline comments.



Comment at: include/clang/Basic/DiagnosticSemaKinds.td:8254
   "%0 cannot be used as the type of a kernel parameter">;
+def err_opencl_implicit_function_decl : Error<
+  "implicit declaration of function %0 is invalid in OpenCL">;

Anastasia wrote:
> Could this be in OpenCL group please?
But this is already in OpenCL group. Please, see line 8232. In this line is a 
comment that OpenCL warnings and errors are below.



Comment at: test/SemaOpenCL/clang-builtin-version.cl:32
+  work_group_reserve_write_pipe(tmp, tmp); // expected-error{{implicit 
declaration of function 'work_group_reserve_write_pipe' is invalid in OpenCL}}
+  // expected-note@-1{{did you mean 'work_group_reserve_read_pipe'?}}
+  // expected-note@-2{{'work_group_reserve_write_pipe' declared here}}

Anastasia wrote:
> Why do we get this note now? I believe work_group_reserve_read_pipe shouldn't 
> be available either?
May be I don't understand something but I think that it is the right diagnostic 
message. We called work_group_reserve_read_pipe in line 29. So for this case we 
will get the following message: 
//clang-builtin-version.cl: 31 error: implicit declaration of function 
'work_group_reserve_write_pipe' is invalid in OpenCL
clang-builtin-version.cl: 31 note: did you mean 'work_group_reserve_read_pipe'?
clang-builtin-version.cl: 29 note: 'work_group_reserve_read_pipe' declared 
here//


https://reviews.llvm.org/D31745



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


[PATCH] D31745: [OpenCL] Added diagnostic for implicit declaration of function in OpenCL

2017-04-10 Thread Egor Churaev via Phabricator via cfe-commits
echuraev updated this revision to Diff 94537.

https://reviews.llvm.org/D31745

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Sema/SemaDecl.cpp
  test/SemaOpenCL/clang-builtin-version.cl
  test/SemaOpenCL/to_addr_builtin.cl

Index: test/SemaOpenCL/to_addr_builtin.cl
===
--- test/SemaOpenCL/to_addr_builtin.cl
+++ test/SemaOpenCL/to_addr_builtin.cl
@@ -10,7 +10,7 @@
 
   glob = to_global(glob, loc);
 #if __OPENCL_C_VERSION__ < CL_VERSION_2_0
-  // expected-warning@-2{{implicit declaration of function 'to_global' is invalid in C99}}
+  // expected-error@-2{{implicit declaration of function 'to_global' is invalid in OpenCL}}
   // expected-warning@-3{{incompatible integer to pointer conversion assigning to '__global int *' from 'int'}}
 #else
   // expected-error@-5{{invalid number of arguments to function: 'to_global'}}
Index: test/SemaOpenCL/clang-builtin-version.cl
===
--- test/SemaOpenCL/clang-builtin-version.cl
+++ test/SemaOpenCL/clang-builtin-version.cl
@@ -4,41 +4,62 @@
 
 kernel void dse_builtins() {
   int tmp;
-  enqueue_kernel(tmp, tmp, tmp, ^(void) { // expected-warning{{implicit declaration of function 'enqueue_kernel' is invalid in C99}}
+  enqueue_kernel(tmp, tmp, tmp, ^(void) { // expected-error{{implicit declaration of function 'enqueue_kernel' is invalid in OpenCL}}
 return;
   });
-  unsigned size = get_kernel_work_group_size(^(void) { // expected-warning{{implicit declaration of function 'get_kernel_work_group_size' is invalid in C99}}
+  unsigned size = get_kernel_work_group_size(^(void) { // expected-error{{implicit declaration of function 'get_kernel_work_group_size' is invalid in OpenCL}}
 return;
   });
-  size = get_kernel_preferred_work_group_size_multiple(^(void) { // expected-warning{{implicit declaration of function 'get_kernel_preferred_work_group_size_multiple' is invalid in C99}}
+  size = get_kernel_preferred_work_group_size_multiple(^(void) { // expected-error{{implicit declaration of function 'get_kernel_preferred_work_group_size_multiple' is invalid in OpenCL}}
 return;
   });
 }
 
 void pipe_builtins() {
   int tmp;
 
-  read_pipe(tmp, tmp);  // expected-warning{{implicit declaration of function 'read_pipe' is invalid in C99}}
-  write_pipe(tmp, tmp); // expected-warning{{implicit declaration of function 'write_pipe' is invalid in C99}}
+  foo(void); // expected-error{{implicit declaration of function 'foo' is invalid in OpenCL}}
+  // expected-note@-1{{'foo' declared here}}
+  // expected-error@-2{{expected expression}}
+  boo(); // expected-error{{implicit declaration of function 'boo' is invalid in OpenCL}}
+  // expected-note@-1{{did you mean 'foo'?}}
 
-  reserve_read_pipe(tmp, tmp);  // expected-warning{{implicit declaration of function 'reserve_read_pipe' is invalid in C99}}
-  reserve_write_pipe(tmp, tmp); // expected-warning{{implicit declaration of function 'reserve_write_pipe' is invalid in C99}}
+  read_pipe(tmp, tmp);  // expected-error{{implicit declaration of function 'read_pipe' is invalid in OpenCL}}
+  write_pipe(tmp, tmp); // expected-error{{implicit declaration of function 'write_pipe' is invalid in OpenCL}}
 
-  work_group_reserve_read_pipe(tmp, tmp);  // expected-warning{{implicit declaration of function 'work_group_reserve_read_pipe' is invalid in C99}}
-  work_group_reserve_write_pipe(tmp, tmp); // expected-warning{{implicit declaration of function 'work_group_reserve_write_pipe' is invalid in C99}}
+  reserve_read_pipe(tmp, tmp);  // expected-error{{implicit declaration of function 'reserve_read_pipe' is invalid in OpenCL}}
+  // expected-note@-1{{'reserve_read_pipe' declared here}}
+  reserve_write_pipe(tmp, tmp); // expected-error{{implicit declaration of function 'reserve_write_pipe' is invalid in OpenCL}}
+  // expected-note@-1{{did you mean 'reserve_read_pipe'?}}
 
-  sub_group_reserve_write_pipe(tmp, tmp); // expected-warning{{implicit declaration of function 'sub_group_reserve_write_pipe' is invalid in C99}}
-  sub_group_reserve_read_pipe(tmp, tmp);  // expected-warning{{implicit declaration of function 'sub_group_reserve_read_pipe' is invalid in C99}}
+  work_group_reserve_read_pipe(tmp, tmp);  // expected-error{{implicit declaration of function 'work_group_reserve_read_pipe' is invalid in OpenCL}}
+  // expected-note@-1 2{{'work_group_reserve_read_pipe' declared here}}
+  work_group_reserve_write_pipe(tmp, tmp); // expected-error{{implicit declaration of function 'work_group_reserve_write_pipe' is invalid in OpenCL}}
+  // expected-note@-1{{did you mean 'work_group_reserve_read_pipe'?}}
+  // expected-note@-2{{'work_group_reserve_write_pipe' declared here}}
 
-  commit_read_pipe(tmp, tmp);  // expected-warning{{implicit declaration of function 'commit_read_pipe' is invalid in C99}}
-  commit_write_pipe(tmp, tmp); // expected-warning{{implicit declaration of function 'commit_write_pipe' is 

[PATCH] D30009: Add support for '#pragma clang attribute'

2017-04-10 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.

This LGTM, but you should give @rsmith some time to review before committing in 
case he catches something I've missed.


Repository:
  rL LLVM

https://reviews.llvm.org/D30009



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


[PATCH] D27181: [ASTImporter] Support for importing UsingDecl and UsingShadowDecl

2017-04-10 Thread Aleksei Sidorin via Phabricator via cfe-commits
a.sidorin added inline comments.



Comment at: lib/AST/ASTImporter.cpp:4305
+  DeclarationNameInfo NameInfo(Name, 
Importer.Import(D->getNameInfo().getLoc()));
+  ImportDeclarationNameLoc(D->getNameInfo(), NameInfo);
+

spyffe wrote:
> I've seen this pattern before, in [[ https://reviews.llvm.org/D27033 | D20733 
> ]], at ASTImporter.cpp:6488:
> ```
>   DeclarationNameInfo NameInfo(E->getName(), E->getNameLoc());
>   ImportDeclarationNameLoc(E->getNameInfo(), NameInfo);
> ```
> That code didn't do the `Import` during the initialization of the 
> `DeclarationNameInfo`.  Is either of these incorrect?
This may come from our published code but it looks like an issue that needs to 
be fixed. Thank you for spotting this.


https://reviews.llvm.org/D27181



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


[PATCH] D31885: Remove TBAA information from LValues representing union members

2017-04-10 Thread Krzysztof Parzyszek via Phabricator via cfe-commits
kparzysz updated this revision to Diff 94699.
kparzysz added a comment.

Do not stop the check for unions at the first MemberExpr (unless it's a union).


Repository:
  rL LLVM

https://reviews.llvm.org/D31885

Files:
  lib/CodeGen/CGExpr.cpp

Index: lib/CodeGen/CGExpr.cpp
===
--- lib/CodeGen/CGExpr.cpp
+++ lib/CodeGen/CGExpr.cpp
@@ -1011,66 +1011,101 @@
 /// type of the same size of the lvalue's type.  If the lvalue has a variable
 /// length type, this is not possible.
 ///
+
+/// Hacks to remove TBAA information from LValues that represent union members.
+/// The TBAA in the current form does not work for union members: the aliasing
+/// information emitted in such cases may be incorrect (leading to incorrect
+/// optimizations).
+static bool isUnionAccess(const Expr *E) {
+  switch (E->getStmtClass()) {
+case Stmt::MemberExprClass: {
+  const Expr *BE = cast(E)->getBase();
+  if (BE->getType()->isUnionType())
+return true;
+  return isUnionAccess(BE);
+}
+case Stmt::ImplicitCastExprClass:
+  return isUnionAccess(cast(E)->getSubExpr());
+case Stmt::ArraySubscriptExprClass:
+  return isUnionAccess(cast(E)->getBase());
+default:
+  break;
+  }
+  return false;
+}
+
+static LValue ClearTBAA(LValue &, bool Reset) {
+  if (Reset)
+LV.setTBAAInfo(nullptr);
+  return LV;
+}
+
 LValue CodeGenFunction::EmitLValue(const Expr *E) {
+  bool R = CGM.shouldUseTBAA() && isUnionAccess(E);
   ApplyDebugLocation DL(*this, E);
   switch (E->getStmtClass()) {
-  default: return EmitUnsupportedLValue(E, "l-value expression");
+  default: return ClearTBAA(EmitUnsupportedLValue(E, "l-value expression"), R);
 
   case Expr::ObjCPropertyRefExprClass:
 llvm_unreachable("cannot emit a property reference directly");
 
   case Expr::ObjCSelectorExprClass:
-return EmitObjCSelectorLValue(cast(E));
+return ClearTBAA(EmitObjCSelectorLValue(cast(E)), R);
   case Expr::ObjCIsaExprClass:
-return EmitObjCIsaExpr(cast(E));
+return ClearTBAA(EmitObjCIsaExpr(cast(E)), R);
   case Expr::BinaryOperatorClass:
-return EmitBinaryOperatorLValue(cast(E));
+return ClearTBAA(EmitBinaryOperatorLValue(cast(E)), R);
   case Expr::CompoundAssignOperatorClass: {
 QualType Ty = E->getType();
 if (const AtomicType *AT = Ty->getAs())
   Ty = AT->getValueType();
+const auto *CA = cast(E);
 if (!Ty->isAnyComplexType())
-  return EmitCompoundAssignmentLValue(cast(E));
-return EmitComplexCompoundAssignmentLValue(cast(E));
+  return ClearTBAA(EmitCompoundAssignmentLValue(CA), R);
+return ClearTBAA(EmitComplexCompoundAssignmentLValue(CA), R);
   }
   case Expr::CallExprClass:
   case Expr::CXXMemberCallExprClass:
   case Expr::CXXOperatorCallExprClass:
   case Expr::UserDefinedLiteralClass:
-return EmitCallExprLValue(cast(E));
+return ClearTBAA(EmitCallExprLValue(cast(E)), R);
   case Expr::VAArgExprClass:
-return EmitVAArgExprLValue(cast(E));
+return ClearTBAA(EmitVAArgExprLValue(cast(E)), R);
   case Expr::DeclRefExprClass:
-return EmitDeclRefLValue(cast(E));
+return ClearTBAA(EmitDeclRefLValue(cast(E)), R);
   case Expr::ParenExprClass:
-return EmitLValue(cast(E)->getSubExpr());
-  case Expr::GenericSelectionExprClass:
-return EmitLValue(cast(E)->getResultExpr());
+return ClearTBAA(EmitLValue(cast(E)->getSubExpr()), R);
+  case Expr::GenericSelectionExprClass: {
+const auto *GS = cast(E);
+return ClearTBAA(EmitLValue(GS->getResultExpr()), R);
+  }
   case Expr::PredefinedExprClass:
-return EmitPredefinedLValue(cast(E));
+return ClearTBAA(EmitPredefinedLValue(cast(E)), R);
   case Expr::StringLiteralClass:
-return EmitStringLiteralLValue(cast(E));
+return ClearTBAA(EmitStringLiteralLValue(cast(E)), R);
   case Expr::ObjCEncodeExprClass:
-return EmitObjCEncodeExprLValue(cast(E));
+return ClearTBAA(EmitObjCEncodeExprLValue(cast(E)), R);
   case Expr::PseudoObjectExprClass:
-return EmitPseudoObjectLValue(cast(E));
+return ClearTBAA(EmitPseudoObjectLValue(cast(E)), R);
   case Expr::InitListExprClass:
-return EmitInitListLValue(cast(E));
+return ClearTBAA(EmitInitListLValue(cast(E)), R);
   case Expr::CXXTemporaryObjectExprClass:
   case Expr::CXXConstructExprClass:
-return EmitCXXConstructLValue(cast(E));
-  case Expr::CXXBindTemporaryExprClass:
-return EmitCXXBindTemporaryLValue(cast(E));
+return ClearTBAA(EmitCXXConstructLValue(cast(E)), R);
+  case Expr::CXXBindTemporaryExprClass: {
+const auto *BT = cast(E);
+return ClearTBAA(EmitCXXBindTemporaryLValue(BT), R);
+  }
   case Expr::CXXUuidofExprClass:
-return EmitCXXUuidofLValue(cast(E));
+return ClearTBAA(EmitCXXUuidofLValue(cast(E)), R);
   case Expr::LambdaExprClass:
-return EmitLambdaLValue(cast(E));
+return ClearTBAA(EmitLambdaLValue(cast(E)), R);
 
   case Expr::ExprWithCleanupsClass: {
 const auto 

[PATCH] D31706: [clang-format] Handle NSString literals by merging tokens.

2017-04-10 Thread Alexander Kornienko via Phabricator via cfe-commits
alexfh added a comment.

Friendly ping.


https://reviews.llvm.org/D31706



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


[PATCH] D31869: Register isStaticStorageClass matcher

2017-04-10 Thread Dave Lee via Phabricator via cfe-commits
kastiglione created this revision.
Herald added a subscriber: klimek.

I noticed I couldn't `isStaticStorageClass()` from `clang-query`. This change 
fixed that.


https://reviews.llvm.org/D31869

Files:
  lib/ASTMatchers/Dynamic/Registry.cpp


Index: lib/ASTMatchers/Dynamic/Registry.cpp
===
--- lib/ASTMatchers/Dynamic/Registry.cpp
+++ lib/ASTMatchers/Dynamic/Registry.cpp
@@ -330,6 +330,7 @@
   REGISTER_MATCHER(isPublic);
   REGISTER_MATCHER(isPure);
   REGISTER_MATCHER(isSignedInteger);
+  REGISTER_MATCHER(isStaticStorageClass);
   REGISTER_MATCHER(isStruct);
   REGISTER_MATCHER(isTemplateInstantiation);
   REGISTER_MATCHER(isUnion);


Index: lib/ASTMatchers/Dynamic/Registry.cpp
===
--- lib/ASTMatchers/Dynamic/Registry.cpp
+++ lib/ASTMatchers/Dynamic/Registry.cpp
@@ -330,6 +330,7 @@
   REGISTER_MATCHER(isPublic);
   REGISTER_MATCHER(isPure);
   REGISTER_MATCHER(isSignedInteger);
+  REGISTER_MATCHER(isStaticStorageClass);
   REGISTER_MATCHER(isStruct);
   REGISTER_MATCHER(isTemplateInstantiation);
   REGISTER_MATCHER(isUnion);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D31745: [OpenCL] Added diagnostic for implicit declaration of function in OpenCL

2017-04-10 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added inline comments.



Comment at: test/SemaOpenCL/clang-builtin-version.cl:32
+  work_group_reserve_write_pipe(tmp, tmp); // expected-error{{implicit 
declaration of function 'work_group_reserve_write_pipe' is invalid in OpenCL}}
+  // expected-note@-1{{did you mean 'work_group_reserve_read_pipe'?}}
+  // expected-note@-2{{'work_group_reserve_write_pipe' declared here}}

Anastasia wrote:
> echuraev wrote:
> > Anastasia wrote:
> > > Why do we get this note now? I believe work_group_reserve_read_pipe 
> > > shouldn't be available either?
> > May be I don't understand something but I think that it is the right 
> > diagnostic message. We called work_group_reserve_read_pipe in line 29. So 
> > for this case we will get the following message: 
> > //clang-builtin-version.cl: 31 error: implicit declaration of function 
> > 'work_group_reserve_write_pipe' is invalid in OpenCL
> > clang-builtin-version.cl: 31 note: did you mean 
> > 'work_group_reserve_read_pipe'?
> > clang-builtin-version.cl: 29 note: 'work_group_reserve_read_pipe' declared 
> > here//
> But there is an error now given for the call to 
> 'work_group_reserve_read_pipe'. Why is it still added to the declarations? I 
> think we should prevent this.
Also do you know why we didn't have these notes before? I don't see anything 
related in your change.


https://reviews.llvm.org/D31745



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


[PATCH] D31856: Headers: Make the type of SIZE_MAX the same as size_t

2017-04-10 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith updated this revision to Diff 94675.
dexonsmith added a comment.

Updated clang/test/Preprocessor/stdint.c, which I missed in the original patch.


https://reviews.llvm.org/D31856

Files:
  clang/lib/Headers/stdint.h
  clang/test/Headers/stdint-type-of-SIZE_MAX.cpp
  clang/test/Preprocessor/stdint.c

Index: clang/test/Preprocessor/stdint.c
===
--- clang/test/Preprocessor/stdint.c
+++ clang/test/Preprocessor/stdint.c
@@ -79,7 +79,7 @@
 // ARM:UINTPTR_MAX_ 4294967295U
 // ARM:PTRDIFF_MIN_ (-2147483647 -1)
 // ARM:PTRDIFF_MAX_ 2147483647
-// ARM:SIZE_MAX_ 4294967295U
+// ARM:SIZE_MAX_ ((unsigned int)4294967295U)
 //
 // ARM:INTMAX_MIN_ (-9223372036854775807LL -1)
 // ARM:INTMAX_MAX_ 9223372036854775807LL
@@ -187,7 +187,7 @@
 // I386:UINTPTR_MAX_ 4294967295U
 // I386:PTRDIFF_MIN_ (-2147483647 -1)
 // I386:PTRDIFF_MAX_ 2147483647
-// I386:SIZE_MAX_ 4294967295U
+// I386:SIZE_MAX_ ((unsigned int)4294967295U)
 //
 // I386:INTMAX_MIN_ (-9223372036854775807LL -1)
 // I386:INTMAX_MAX_ 9223372036854775807LL
@@ -294,7 +294,7 @@
 // MIPS:UINTPTR_MAX_ 4294967295U
 // MIPS:PTRDIFF_MIN_ (-2147483647 -1)
 // MIPS:PTRDIFF_MAX_ 2147483647
-// MIPS:SIZE_MAX_ 4294967295U
+// MIPS:SIZE_MAX_ ((unsigned int)4294967295U)
 //
 // MIPS:INTMAX_MIN_ (-9223372036854775807LL -1)
 // MIPS:INTMAX_MAX_ 9223372036854775807LL
@@ -401,7 +401,7 @@
 // MIPS64:UINTPTR_MAX_ 18446744073709551615UL
 // MIPS64:PTRDIFF_MIN_ (-9223372036854775807L -1)
 // MIPS64:PTRDIFF_MAX_ 9223372036854775807L
-// MIPS64:SIZE_MAX_ 18446744073709551615UL
+// MIPS64:SIZE_MAX_ ((long unsigned int)18446744073709551615UL)
 //
 // MIPS64:INTMAX_MIN_ (-9223372036854775807L -1)
 // MIPS64:INTMAX_MAX_ 9223372036854775807L
@@ -501,7 +501,7 @@
 // MSP430:UINTPTR_MAX_ 65535
 // MSP430:PTRDIFF_MIN_ (-32767 -1)
 // MSP430:PTRDIFF_MAX_ 32767
-// MSP430:SIZE_MAX_ 65535
+// MSP430:SIZE_MAX_ ((unsigned int)65535U)
 //
 // MSP430:INTMAX_MIN_ (-9223372036854775807LL -1)
 // MSP430:INTMAX_MAX_ 9223372036854775807LL
@@ -608,7 +608,7 @@
 // PPC64:UINTPTR_MAX_ 18446744073709551615UL
 // PPC64:PTRDIFF_MIN_ (-9223372036854775807L -1)
 // PPC64:PTRDIFF_MAX_ 9223372036854775807L
-// PPC64:SIZE_MAX_ 18446744073709551615UL
+// PPC64:SIZE_MAX_ ((long unsigned int)18446744073709551615UL)
 //
 // PPC64:INTMAX_MIN_ (-9223372036854775807L -1)
 // PPC64:INTMAX_MAX_ 9223372036854775807L
@@ -715,7 +715,7 @@
 // PPC64-NETBSD:UINTPTR_MAX_ 18446744073709551615ULL
 // PPC64-NETBSD:PTRDIFF_MIN_ (-9223372036854775807LL -1)
 // PPC64-NETBSD:PTRDIFF_MAX_ 9223372036854775807LL
-// PPC64-NETBSD:SIZE_MAX_ 18446744073709551615ULL
+// PPC64-NETBSD:SIZE_MAX_ ((long unsigned int)18446744073709551615ULL)
 //
 // PPC64-NETBSD:INTMAX_MIN_ (-9223372036854775807LL -1)
 // PPC64-NETBSD:INTMAX_MAX_ 9223372036854775807LL
@@ -823,7 +823,7 @@
 // PPC:UINTPTR_MAX_ 4294967295U
 // PPC:PTRDIFF_MIN_ (-2147483647 -1)
 // PPC:PTRDIFF_MAX_ 2147483647
-// PPC:SIZE_MAX_ 4294967295U
+// PPC:SIZE_MAX_ ((long unsigned int)4294967295U)
 //
 // PPC:INTMAX_MIN_ (-9223372036854775807LL -1)
 // PPC:INTMAX_MAX_ 9223372036854775807LL
@@ -930,7 +930,7 @@
 // S390X:UINTPTR_MAX_ 18446744073709551615UL
 // S390X:PTRDIFF_MIN_ (-9223372036854775807L -1)
 // S390X:PTRDIFF_MAX_ 9223372036854775807L
-// S390X:SIZE_MAX_ 18446744073709551615UL
+// S390X:SIZE_MAX_ ((long unsigned int)18446744073709551615UL)
 //
 // S390X:INTMAX_MIN_ (-9223372036854775807L -1)
 // S390X:INTMAX_MAX_ 9223372036854775807L
@@ -1037,7 +1037,7 @@
 // SPARC:UINTPTR_MAX_ 4294967295U
 // SPARC:PTRDIFF_MIN_ (-2147483647 -1)
 // SPARC:PTRDIFF_MAX_ 2147483647
-// SPARC:SIZE_MAX_ 4294967295U
+// SPARC:SIZE_MAX_ ((unsigned int)4294967295U)
 //
 // SPARC:INTMAX_MIN_ (-9223372036854775807LL -1)
 // SPARC:INTMAX_MAX_ 9223372036854775807LL
@@ -1137,7 +1137,7 @@
 // TCE:UINTPTR_MAX_ 4294967295U
 // TCE:PTRDIFF_MIN_ (-2147483647 -1)
 // TCE:PTRDIFF_MAX_ 2147483647
-// TCE:SIZE_MAX_ 4294967295U
+// TCE:SIZE_MAX_ ((unsigned int)4294967295U)
 //
 // TCE:INTMAX_MIN_ (-2147483647 -1)
 // TCE:INTMAX_MAX_ 2147483647
@@ -1245,7 +1245,7 @@
 // X86_64:UINTPTR_MAX_ 18446744073709551615UL
 // X86_64:PTRDIFF_MIN_ (-9223372036854775807L -1)
 // X86_64:PTRDIFF_MAX_ 9223372036854775807L
-// X86_64:SIZE_MAX_ 18446744073709551615UL
+// X86_64:SIZE_MAX_ ((long unsigned int)18446744073709551615UL)
 //
 // X86_64:INTMAX_MIN_ (-9223372036854775807L -1)
 // X86_64:INTMAX_MAX_ 9223372036854775807L
@@ -1365,7 +1365,7 @@
 // XCORE:UINTPTR_MAX_ 4294967295U
 // XCORE:PTRDIFF_MIN_ (-2147483647 -1)
 // XCORE:PTRDIFF_MAX_ 2147483647
-// XCORE:SIZE_MAX_ 4294967295U
+// XCORE:SIZE_MAX_ ((unsigned int)4294967295U)
 //
 // XCORE:INTMAX_MIN_ (-9223372036854775807LL -1)
 // XCORE:INTMAX_MAX_ 9223372036854775807LL
@@ -1408,7 +1408,7 @@
 // JOIN:UINTPTR_MAX_ 4294967295U
 // JOIN:PTRDIFF_MIN_ (-2147483647 -1)
 // JOIN:PTRDIFF_MAX_ 2147483647
-// JOIN:SIZE_MAX_ 4294967295U
+// JOIN:SIZE_MAX_ ((unsigned a)4294967295U)
 // JOIN:INTMAX_MIN_ (-9223372036854775807LL 

  1   2   >