date:20151023

[libcxx] r251131 - Set LC_COLLATE rather than LANG to override collation.

2015-10-23 Thread Tim Northover via cfe-commits

Author: tnorthover
Date: Fri Oct 23 12:56:08 2015
New Revision: 251131

URL: http://llvm.org/viewvc/llvm-project?rev=251131=rev
Log:
Set LC_COLLATE rather than LANG to override collation.

On a system with LC_COLLATE=C, this takes precedence over a non-C LANG
the test tries to impose and the test fails.

Modified:

libcxx/trunk/test/std/localization/locale.categories/category.collate/locale.collate.byname/transform.pass.cpp

Modified: 
libcxx/trunk/test/std/localization/locale.categories/category.collate/locale.collate.byname/transform.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/localization/locale.categories/category.collate/locale.collate.byname/transform.pass.cpp?rev=251131=251130=251131=diff
==
--- 
libcxx/trunk/test/std/localization/locale.categories/category.collate/locale.collate.byname/transform.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/localization/locale.categories/category.collate/locale.collate.byname/transform.pass.cpp
 Fri Oct 23 12:56:08 2015
@@ -26,7 +26,7 @@
 int main()
 {
 // Ensure that the default locale is not C.  If it is, the second tests 
will fail.
-putenv(const_cast("LANG=" LOCALE_en_US_UTF_8));
+putenv(const_cast("LC_COLLATE=" LOCALE_en_US_UTF_8));
 {
 std::locale l(LOCALE_en_US_UTF_8);
 {


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

r251101 - [AST] Re-add TypeLocs and NestedNameSpecifierLocs to the ParentMap.

2015-10-23 Thread Benjamin Kramer via cfe-commits

Author: d0k
Date: Fri Oct 23 04:04:55 2015
New Revision: 251101

URL: http://llvm.org/viewvc/llvm-project?rev=251101=rev
Log:
[AST] Re-add TypeLocs and NestedNameSpecifierLocs to the ParentMap.

This relands r250831 after some fixes to shrink the ParentMap overall
with one addtional tweak: nodes with pointer identity (e.g. Decl* and
friends) can be store more efficiently so I put them in a separate map.
All other nodes (so far only TypeLoc and NNSLoc) go in a different map
keyed on DynTypedNode. This further uglifies the code but significantly
reduces memory overhead.

Overall this change still make ParentMap significantly larger but it's
nowhere as bad as before. I see about 25 MB over baseline (pre-r251008)
on X86ISelLowering.cpp. If this becomes an issue we could consider
splitting the maps further as DynTypedNode is still larger (32 bytes)
than a single TypeLoc (16 bytes) but I didn't want to introduce even
more complexity now.

Differential Revision: http://reviews.llvm.org/D14011

Modified:
cfe/trunk/include/clang/AST/ASTContext.h
cfe/trunk/include/clang/AST/ASTTypeTraits.h
cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
cfe/trunk/lib/AST/ASTContext.cpp
cfe/trunk/lib/ASTMatchers/ASTMatchFinder.cpp
cfe/trunk/unittests/AST/ASTContextParentMapTest.cpp
cfe/trunk/unittests/ASTMatchers/Dynamic/ParserTest.cpp
cfe/trunk/unittests/ASTMatchers/Dynamic/RegistryTest.cpp

Modified: cfe/trunk/include/clang/AST/ASTContext.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTContext.h?rev=251101=251100=251101=diff
==
--- cfe/trunk/include/clang/AST/ASTContext.h (original)
+++ cfe/trunk/include/clang/AST/ASTContext.h Fri Oct 23 04:04:55 2015
@@ -451,11 +451,21 @@ public:
   /// \brief Contains parents of a node.
   typedef llvm::SmallVector ParentVector;
 
-  /// \brief Maps from a node to its parents.
+  /// \brief Maps from a node to its parents. This is used for nodes that have
+  /// pointer identity only, which are more common and we can save space by
+  /// only storing a unique pointer to them.
   typedef llvm::DenseMap> ParentMap;
+ ParentVector *>> 
ParentMapPointers;
+
+  /// Parent map for nodes without pointer identity. We store a full
+  /// DynTypedNode for all keys.
+  typedef llvm::DenseMap<
+  ast_type_traits::DynTypedNode,
+  llvm::PointerUnion4>
+  ParentMapOtherNodes;
 
   /// Container for either a single DynTypedNode or for an ArrayRef to
   /// DynTypedNode. For use with ParentMap.
@@ -2513,7 +2523,8 @@ private:
   void ReleaseDeclContextMaps();
   void ReleaseParentMapEntries();
 
-  std::unique_ptr AllParents;
+  std::unique_ptr PointerParents;
+  std::unique_ptr OtherParents;
 
   std::unique_ptr VTContext;
 

Modified: cfe/trunk/include/clang/AST/ASTTypeTraits.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTTypeTraits.h?rev=251101=251100=251101=diff
==
--- cfe/trunk/include/clang/AST/ASTTypeTraits.h (original)
+++ cfe/trunk/include/clang/AST/ASTTypeTraits.h Fri Oct 23 04:04:55 2015
@@ -268,6 +268,28 @@ public:
   /// FIXME: Implement comparsion for other node types (currently
   /// only Stmt, Decl, Type and NestedNameSpecifier return memoization data).
   bool operator<(const DynTypedNode ) const {
+if (!NodeKind.isSame(Other.NodeKind))
+  return NodeKind < Other.NodeKind;
+
+if (ASTNodeKind::getFromNodeKind().isSame(NodeKind)) {
+  auto TLA = getUnchecked();
+  auto TLB = Other.getUnchecked();
+  return std::make_pair(TLA.getType().getAsOpaquePtr(),
+TLA.getOpaqueData()) <
+ std::make_pair(TLB.getType().getAsOpaquePtr(),
+TLB.getOpaqueData());
+}
+
+if (ASTNodeKind::getFromNodeKind().isSame(
+NodeKind)) {
+  auto NNSLA = getUnchecked();
+  auto NNSLB = Other.getUnchecked();
+  return std::make_pair(NNSLA.getNestedNameSpecifier(),
+NNSLA.getOpaqueData()) <
+ std::make_pair(NNSLB.getNestedNameSpecifier(),
+NNSLB.getOpaqueData());
+}
+
 assert(getMemoizationData() && Other.getMemoizationData());
 return getMemoizationData() < Other.getMemoizationData();
   }
@@ -281,6 +303,13 @@ public:
 if (ASTNodeKind::getFromNodeKind().isSame(NodeKind))
   return getUnchecked() == Other.getUnchecked();
 
+if (ASTNodeKind::getFromNodeKind().isSame(NodeKind))
+  return getUnchecked() == Other.getUnchecked();
+
+if 
(ASTNodeKind::getFromNodeKind().isSame(NodeKind))
+  return getUnchecked() ==
+ Other.getUnchecked();
+
 assert(getMemoizationData() && Other.getMemoizationData());

Re: [PATCH] D14011: [AST] Re-add TypeLocs and NestedNameSpecifierLocs to the ParentMap.

2015-10-23 Thread Phabricator via cfe-commits

This revision was automatically updated to reflect the committed changes.
Closed by commit rL251101: [AST] Re-add TypeLocs and NestedNameSpecifierLocs to 
the ParentMap. (authored by d0k).

Changed prior to commit:
  http://reviews.llvm.org/D14011?vs=38216=38220#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D14011

Files:
  cfe/trunk/include/clang/AST/ASTContext.h
  cfe/trunk/include/clang/AST/ASTTypeTraits.h
  cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
  cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
  cfe/trunk/lib/AST/ASTContext.cpp
  cfe/trunk/lib/ASTMatchers/ASTMatchFinder.cpp
  cfe/trunk/unittests/AST/ASTContextParentMapTest.cpp
  cfe/trunk/unittests/ASTMatchers/Dynamic/ParserTest.cpp
  cfe/trunk/unittests/ASTMatchers/Dynamic/RegistryTest.cpp

Index: cfe/trunk/lib/AST/ASTContext.cpp
===
--- cfe/trunk/lib/AST/ASTContext.cpp
+++ cfe/trunk/lib/AST/ASTContext.cpp
@@ -793,8 +793,15 @@
 }
 
 void ASTContext::ReleaseParentMapEntries() {
-  if (!AllParents) return;
-  for (const auto  : *AllParents) {
+  if (!PointerParents) return;
+  for (const auto  : *PointerParents) {
+if (Entry.second.is()) {
+  delete Entry.second.get();
+} else if (Entry.second.is()) {
+  delete Entry.second.get();
+}
+  }
+  for (const auto  : *OtherParents) {
 if (Entry.second.is()) {
   delete Entry.second.get();
 } else if (Entry.second.is()) {
@@ -8670,15 +8677,32 @@
 
 namespace {
 
-ast_type_traits::DynTypedNode
-getSingleDynTypedNodeFromParentMap(ASTContext::ParentMap::mapped_type U) {
+ast_type_traits::DynTypedNode getSingleDynTypedNodeFromParentMap(
+ASTContext::ParentMapPointers::mapped_type U) {
   if (const auto *D = U.dyn_cast())
 return ast_type_traits::DynTypedNode::create(*D);
   if (const auto *S = U.dyn_cast())
 return ast_type_traits::DynTypedNode::create(*S);
   return *U.get();
 }
 
+/// Template specializations to abstract away from pointers and TypeLocs.
+/// @{
+template 
+ast_type_traits::DynTypedNode createDynTypedNode(const T ) {
+  return ast_type_traits::DynTypedNode::create(*Node);
+}
+template <>
+ast_type_traits::DynTypedNode createDynTypedNode(const TypeLoc ) {
+  return ast_type_traits::DynTypedNode::create(Node);
+}
+template <>
+ast_type_traits::DynTypedNode
+createDynTypedNode(const NestedNameSpecifierLoc ) {
+  return ast_type_traits::DynTypedNode::create(Node);
+}
+/// @}
+
   /// \brief A \c RecursiveASTVisitor that builds a map from nodes to their
   /// parents as defined by the \c RecursiveASTVisitor.
   ///
@@ -8693,17 +8717,21 @@
 /// \brief Builds and returns the translation unit's parent map.
 ///
 ///  The caller takes ownership of the returned \c ParentMap.
-static ASTContext::ParentMap *buildMap(TranslationUnitDecl ) {
-  ParentMapASTVisitor Visitor(new ASTContext::ParentMap);
+static std::pair
+buildMap(TranslationUnitDecl ) {
+  ParentMapASTVisitor Visitor(new ASTContext::ParentMapPointers,
+  new ASTContext::ParentMapOtherNodes);
   Visitor.TraverseDecl();
-  return Visitor.Parents;
+  return std::make_pair(Visitor.Parents, Visitor.OtherParents);
 }
 
   private:
 typedef RecursiveASTVisitor VisitorBase;
 
-ParentMapASTVisitor(ASTContext::ParentMap *Parents) : Parents(Parents) {
-}
+ParentMapASTVisitor(ASTContext::ParentMapPointers *Parents,
+ASTContext::ParentMapOtherNodes *OtherParents)
+: Parents(Parents), OtherParents(OtherParents) {}
 
 bool shouldVisitTemplateInstantiations() const {
   return true;
@@ -8717,8 +8745,9 @@
   return false;
 }
 
-template 
-bool TraverseNode(T *Node, bool(VisitorBase:: *traverse) (T *)) {
+template 
+bool TraverseNode(T Node, MapNodeTy MapNode,
+  bool (VisitorBase::*traverse)(T), MapTy *Parents) {
   if (!Node)
 return true;
   if (ParentStack.size() > 0) {
@@ -8732,7 +8761,7 @@
 // map. The main problem there is to implement hash functions /
 // comparison operators for all types that DynTypedNode supports that
 // do not have pointer identity.
-auto  = (*Parents)[Node];
+auto  = (*Parents)[MapNode];
 if (NodeOrVector.isNull()) {
   if (const auto *D = ParentStack.back().get())
 NodeOrVector = D;
@@ -8765,49 +8794,70 @@
 Vector->push_back(ParentStack.back());
 }
   }
-  ParentStack.push_back(ast_type_traits::DynTypedNode::create(*Node));
+  ParentStack.push_back(createDynTypedNode(Node));
   bool Result = (this ->* traverse) (Node);
   ParentStack.pop_back();
   return Result;
 }
 
 bool TraverseDecl(Decl *DeclNode) {
-  return TraverseNode(DeclNode, ::TraverseDecl);
+  return TraverseNode(DeclNode, DeclNode, ::TraverseDecl,
+  Parents);
 }
 
 bool

Re: [PATCH] D13973: CFG: Delay creating Dtors for CompoundStmts which end in ReturnStmt

2015-10-23 Thread Manuel Klimek via cfe-commits

klimek added inline comments.


Comment at: lib/Analysis/CFG.cpp:1949-1952
@@ +1948,6 @@
+  }
+  if(!C->body_empty() && !dyn_cast(*C->body_rbegin())) {
+// If the body ends with a ReturnStmt, the dtors will be added in 
VisitReturnStmt
+addAutomaticObjDtors(ScopePos, scopeBeginPos, C);
+  }
+

If the body is non-empty, but the return is not the last statement, won't that 
still call addAutomaticObjDtors twice?


http://reviews.llvm.org/D13973



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

Re: [PATCH] D13336: [MSVC] 'property' with an empty array in array subscript expression.

2015-10-23 Thread Alexey Bataev via cfe-commits

ABataev updated this revision to Diff 38232.
ABataev marked 4 inline comments as done.
ABataev added a comment.

Update after review


http://reviews.llvm.org/D13336

Files:
  include/clang/AST/DataRecursiveASTVisitor.h
  include/clang/AST/ExprCXX.h
  include/clang/AST/RecursiveASTVisitor.h
  include/clang/Basic/StmtNodes.td
  include/clang/Serialization/ASTBitCodes.h
  lib/AST/Expr.cpp
  lib/AST/ExprClassification.cpp
  lib/AST/ExprConstant.cpp
  lib/AST/ItaniumMangle.cpp
  lib/AST/StmtPrinter.cpp
  lib/AST/StmtProfile.cpp
  lib/Sema/SemaExceptionSpec.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaPseudoObject.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReaderStmt.cpp
  lib/Serialization/ASTWriterStmt.cpp
  lib/StaticAnalyzer/Core/ExprEngine.cpp
  test/CodeGenCXX/ms-property.cpp
  test/SemaCXX/ms-property-error.cpp
  test/SemaCXX/ms-property.cpp
  tools/libclang/CXCursor.cpp

Index: lib/Serialization/ASTWriterStmt.cpp
===
--- lib/Serialization/ASTWriterStmt.cpp
+++ lib/Serialization/ASTWriterStmt.cpp
@@ -1668,6 +1668,14 @@
   Code = serialization::EXPR_CXX_PROPERTY_REF_EXPR;
 }
 
+void ASTStmtWriter::VisitMSPropertySubscriptExpr(MSPropertySubscriptExpr *E) {
+  VisitExpr(E);
+  Writer.AddStmt(E->getBase());
+  Writer.AddStmt(E->getIdx());
+  Writer.AddSourceLocation(E->getRBracketLoc(), Record);
+  Code = serialization::EXPR_CXX_PROPERTY_SUBSCRIPT_EXPR;
+}
+
 void ASTStmtWriter::VisitCXXUuidofExpr(CXXUuidofExpr *E) {
   VisitExpr(E);
   Writer.AddSourceRange(E->getSourceRange(), Record);
Index: lib/Serialization/ASTReaderStmt.cpp
===
--- lib/Serialization/ASTReaderStmt.cpp
+++ lib/Serialization/ASTReaderStmt.cpp
@@ -1641,6 +1641,13 @@
   E->TheDecl = ReadDeclAs(Record, Idx);
 }
 
+void ASTStmtReader::VisitMSPropertySubscriptExpr(MSPropertySubscriptExpr *E) {
+  VisitExpr(E);
+  E->setBase(Reader.ReadSubExpr());
+  E->setIdx(Reader.ReadSubExpr());
+  E->setRBracketLoc(ReadSourceLocation(Record, Idx));
+}
+
 void ASTStmtReader::VisitCXXUuidofExpr(CXXUuidofExpr *E) {
   VisitExpr(E);
   E->setSourceRange(ReadSourceRange(Record, Idx));
@@ -3037,6 +3044,9 @@
 case EXPR_CXX_PROPERTY_REF_EXPR:
   S = new (Context) MSPropertyRefExpr(Empty);
   break;
+case EXPR_CXX_PROPERTY_SUBSCRIPT_EXPR:
+  S = new (Context) MSPropertySubscriptExpr(Empty);
+  break;
 case EXPR_CXX_UUIDOF_TYPE:
   S = new (Context) CXXUuidofExpr(Empty, false);
   break;
Index: lib/StaticAnalyzer/Core/ExprEngine.cpp
===
--- lib/StaticAnalyzer/Core/ExprEngine.cpp
+++ lib/StaticAnalyzer/Core/ExprEngine.cpp
@@ -754,6 +754,7 @@
 case Stmt::CXXUuidofExprClass:
 case Stmt::CXXFoldExprClass:
 case Stmt::MSPropertyRefExprClass:
+case Stmt::MSPropertySubscriptExprClass:
 case Stmt::CXXUnresolvedConstructExprClass:
 case Stmt::DependentScopeDeclRefExprClass:
 case Stmt::ArrayTypeTraitExprClass:
Index: lib/AST/Expr.cpp
===
--- lib/AST/Expr.cpp
+++ lib/AST/Expr.cpp
@@ -2998,6 +2998,7 @@
 return true;
 
   case MSPropertyRefExprClass:
+  case MSPropertySubscriptExprClass:
   case CompoundAssignOperatorClass:
   case VAArgExprClass:
   case AtomicExprClass:
Index: lib/AST/StmtProfile.cpp
===
--- lib/AST/StmtProfile.cpp
+++ lib/AST/StmtProfile.cpp
@@ -1123,6 +1123,11 @@
   VisitDecl(S->getPropertyDecl());
 }
 
+void StmtProfiler::VisitMSPropertySubscriptExpr(
+const MSPropertySubscriptExpr *S) {
+  VisitExpr(S);
+}
+
 void StmtProfiler::VisitCXXThisExpr(const CXXThisExpr *S) {
   VisitExpr(S);
   ID.AddBoolean(S->isImplicit());
Index: lib/AST/StmtPrinter.cpp
===
--- lib/AST/StmtPrinter.cpp
+++ lib/AST/StmtPrinter.cpp
@@ -1715,6 +1715,13 @@
   OS << Node->getPropertyDecl()->getDeclName();
 }
 
+void StmtPrinter::VisitMSPropertySubscriptExpr(MSPropertySubscriptExpr *Node) {
+  PrintExpr(Node->getBase());
+  OS << "[";
+  PrintExpr(Node->getIdx());
+  OS << "]";
+}
+
 void StmtPrinter::VisitUserDefinedLiteral(UserDefinedLiteral *Node) {
   switch (Node->getLiteralOperatorKind()) {
   case UserDefinedLiteral::LOK_Raw:
Index: lib/AST/ItaniumMangle.cpp
===
--- lib/AST/ItaniumMangle.cpp
+++ lib/AST/ItaniumMangle.cpp
@@ -2809,6 +2809,7 @@
   case Expr::ParenListExprClass:
   case Expr::LambdaExprClass:
   case Expr::MSPropertyRefExprClass:
+  case Expr::MSPropertySubscriptExprClass:
   case Expr::TypoExprClass:  // This should no longer exist in the AST by now.
   case Expr::OMPArraySectionExprClass:
 llvm_unreachable("unexpected statement kind");
Index: lib/AST/ExprConstant.cpp
===

r251110 - [AST] Plug a memory leak when promoting a single ParentMap entry to a vector.

2015-10-23 Thread Benjamin Kramer via cfe-commits

Author: d0k
Date: Fri Oct 23 08:24:18 2015
New Revision: 251110

URL: http://llvm.org/viewvc/llvm-project?rev=251110=rev
Log:
[AST] Plug a memory leak when promoting a single ParentMap entry to a vector.

Found by asan!

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

Modified: cfe/trunk/lib/AST/ASTContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ASTContext.cpp?rev=251110=251109=251110=diff
==
--- cfe/trunk/lib/AST/ASTContext.cpp (original)
+++ cfe/trunk/lib/AST/ASTContext.cpp Fri Oct 23 08:24:18 2015
@@ -8774,11 +8774,11 @@ createDynTypedNode(const NestedNameSpeci
   if (!NodeOrVector.template is()) {
 auto *Vector = new ASTContext::ParentVector(
 1, getSingleDynTypedNodeFromParentMap(NodeOrVector));
-NodeOrVector = Vector;
 if (auto *Node =
 NodeOrVector
 .template dyn_cast())
   delete Node;
+NodeOrVector = Vector;
   }
 
   auto *Vector =


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

[PATCH] D14014: Checker of proper vfork usage

2015-10-23 Thread Yury Gribov via cfe-commits

ygribov created this revision.
ygribov added reviewers: zaks.anna, dcoughlin, jordan_rose, krememek.
ygribov added a subscriber: cfe-commits.
ygribov set the repository for this revision to rL LLVM.

Hi all,

This checker verifies that vfork is used safely. Vforked process shared stack 
with parent process so it's range of actions is significantly limited (can't 
write variables, can't call functions not in whitelist, etc.).

The patch grew out of complicated 2-day debugging of production SW caused by 
well-known vfork bug in xtables (see 
http://lists.netfilter.org/pipermail/netfilter-buglog/2014-October/003280.html).

Is something like this interesting for upstream?

Repository:
  rL LLVM

http://reviews.llvm.org/D14014

Files:
  lib/StaticAnalyzer/Checkers/CMakeLists.txt
  lib/StaticAnalyzer/Checkers/Checkers.td
  lib/StaticAnalyzer/Checkers/VforkChecker.cpp
  test/Analysis/Inputs/system-header-simulator.h
  test/Analysis/vfork-1.c
  test/Analysis/vfork-2.c

Index: test/Analysis/vfork-2.c
===
--- /dev/null
+++ test/Analysis/vfork-2.c
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -analyze -analyzer-checker=alpha.unix.Vfork %s -verify
+
+#include "Inputs/system-header-simulator.h"
+
+void foo() {
+  // See "libxtables: move some code to avoid cautions in vfork man page"
+  if (vfork() == 0) {
+execl("prog", "arg1", 0);
+exit(1);  // expected-warning{{}}
+  }
+}
+
Index: test/Analysis/vfork-1.c
===
--- /dev/null
+++ test/Analysis/vfork-1.c
@@ -0,0 +1,104 @@
+// RUN: %clang_cc1 -analyze -analyzer-checker=core.builtin.NoReturnFunctions,alpha.unix.Vfork %s -verify
+
+#include "Inputs/system-header-simulator.h"
+
+void foo();
+
+// Check that child process is checked
+int f1(int x) {
+  pid_t pid = vfork();
+  if (pid != 0)
+return 0;
+
+  switch (x) {
+  case 0:
+// writing pid is ok
+pid = 1;
+// calling whitelisted routines is ok
+execl("", "", 0);
+_exit(1);
+break;
+  case 1:
+// writing variables is prohibited
+x = 0; // expected-warning{{}}
+break;
+  case 2:
+// calling functions is prohibited
+foo(); // expected-warning{{}}
+break;
+  default:
+// returning from function is prohibited
+return 0;
+  }
+
+  while(1);
+} // expected-warning{{}}
+
+// Same but without explicit pid
+int f2(int x) {
+  pid_t pid = vfork();
+
+  switch (x) {
+  case 0:
+// writing pid is ok
+pid = 1;
+// calling whitelisted routines is ok
+execl("", "", 0);
+_exit(1);
+break;
+  case 1:
+// writing variables is prohibited
+x = 0; // expected-warning{{}}
+break;
+  case 2:
+// calling functions is prohibited
+foo(); // expected-warning{{}}
+break;
+  default:
+// returning from function is prohibited
+return 0;
+  }
+
+  while(1);
+} // expected-warning{{}}
+
+// check that parent process can do anything
+int f3(int x) {
+  if (vfork() == 0)
+_exit(1);
+  x = 0;
+  foo();
+  return 0;
+}
+
+// unbound pids are special so test them separately
+void f4(int x) {
+  switch (x) {
+  case 0:
+vfork();
+x = 0; // expected-warning{{}}
+break;
+
+  case 1:
+{
+  char args[2];
+  switch (vfork()) {
+  case 0:
+args[0] = 0; // expected-warning{{}}
+exit(1);
+  }
+  break;
+}
+
+  case 2:
+{
+  pid_t pid;
+  if ((pid = vfork()) == 0)
+while(1);
+  break;
+}
+  }
+  while(1);
+}
+
+
Index: test/Analysis/Inputs/system-header-simulator.h
===
--- test/Analysis/Inputs/system-header-simulator.h
+++ test/Analysis/Inputs/system-header-simulator.h
@@ -86,3 +86,13 @@
   char * p;
 } SomeStruct;
 void fakeSystemHeaderCall(SomeStruct *);
+
+typedef int pid_t;
+pid_t fork(void);
+pid_t vfork(void);
+int execl(const char *path, const char *arg, ...);
+
+void exit(int status) __attribute__ ((__noreturn__));
+void _exit(int status) __attribute__ ((__noreturn__));
+void _Exit(int status) __attribute__ ((__noreturn__));
+
Index: lib/StaticAnalyzer/Checkers/VforkChecker.cpp
===
--- /dev/null
+++ lib/StaticAnalyzer/Checkers/VforkChecker.cpp
@@ -0,0 +1,260 @@
+//===- VforkChecker.cpp  Vfork usage checks --*- C++ -*-==//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+//  This file defines chroot checker, which checks improper use of chroot.
+//
+//===--===//
+
+#include "ClangSACheckers.h"
+#include "clang/AST/ParentMap.h"
+#include "clang/StaticAnalyzer/Core/BugReporter/BugType.h"
+#include

Re: [PATCH] D12906: [RFC] Bug identification("issue_hash") change for CmpRuns.py

2015-10-23 Thread Honggyu Kim via cfe-commits

honggyu.kim added a comment.

In http://reviews.llvm.org/D12906#273089, @xazax.hun wrote:

> By default it is disabled for security reasons. You can enable by passing a 
> command line option to the code checker, something like --not-host-only.

Thanks, I can remotely access now with --not-host-only.
But I cannot see the correct diff result when I click "Diff" button with two 
different Run Ids in List of runs menu.
Is it working properly with your bug identification patch? (It has changed 
"issue_hash" field)
Please correct me if I did something wrong.

And here is one more question. I'm just wondering how CodeChecker runs clang 
static analyzer. Does it override CC and CXX just like scan-build?
I can only see the actual build command with "-b" option as below:

  CodeChecker check --dbusername test_user --dbport 5432 -n test_project_check 
-w ~/checker_workspace -b "cd my_test_project && make clean && make"

Thank you!

http://reviews.llvm.org/D12906

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

[clang-tools-extra] r251103 - Make isExpensiveToCopy() tri-state.

2015-10-23 Thread Manuel Klimek via cfe-commits

Author: klimek
Date: Fri Oct 23 05:00:50 2015
New Revision: 251103

URL: http://llvm.org/viewvc/llvm-project?rev=251103=rev
Log:
Make isExpensiveToCopy() tri-state.

This allows returning "don't know" for dependent types.

Modified:
clang-tools-extra/trunk/clang-tidy/utils/Matchers.h
clang-tools-extra/trunk/clang-tidy/utils/TypeTraits.cpp
clang-tools-extra/trunk/clang-tidy/utils/TypeTraits.h
clang-tools-extra/trunk/test/clang-tidy/misc-move-constructor-init.cpp

Modified: clang-tools-extra/trunk/clang-tidy/utils/Matchers.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/utils/Matchers.h?rev=251103=251102=251103=diff
==
--- clang-tools-extra/trunk/clang-tidy/utils/Matchers.h (original)
+++ clang-tools-extra/trunk/clang-tidy/utils/Matchers.h Fri Oct 23 05:00:50 2015
@@ -18,7 +18,9 @@ namespace tidy {
 namespace matchers {
 
 AST_MATCHER(QualType, isExpensiveToCopy) {
-  return type_traits::isExpensiveToCopy(Node, Finder->getASTContext());
+  llvm::Optional IsExpensive =
+  type_traits::isExpensiveToCopy(Node, Finder->getASTContext());
+  return IsExpensive && *IsExpensive;
 }
 
 } // namespace matchers

Modified: clang-tools-extra/trunk/clang-tidy/utils/TypeTraits.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/utils/TypeTraits.cpp?rev=251103=251102=251103=diff
==
--- clang-tools-extra/trunk/clang-tidy/utils/TypeTraits.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/utils/TypeTraits.cpp Fri Oct 23 05:00:50 
2015
@@ -24,9 +24,11 @@ bool classHasTrivialCopyAndDestroy(QualT
 }
 } // namespace
 
-bool isExpensiveToCopy(QualType Type, ASTContext ) {
+llvm::Optional isExpensiveToCopy(QualType Type, ASTContext ) {
+  if (Type->isDependentType())
+return llvm::None;
   return !Type.isTriviallyCopyableType(Context) &&
-  !classHasTrivialCopyAndDestroy(Type);
+ !classHasTrivialCopyAndDestroy(Type);
 }
 
 } // type_traits

Modified: clang-tools-extra/trunk/clang-tidy/utils/TypeTraits.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/utils/TypeTraits.h?rev=251103=251102=251103=diff
==
--- clang-tools-extra/trunk/clang-tidy/utils/TypeTraits.h (original)
+++ clang-tools-extra/trunk/clang-tidy/utils/TypeTraits.h Fri Oct 23 05:00:50 
2015
@@ -18,7 +18,7 @@ namespace tidy {
 namespace type_traits {
 
 // \brief Returns true If \c Type is expensive to copy.
-bool isExpensiveToCopy(QualType Type, ASTContext );
+llvm::Optional isExpensiveToCopy(QualType Type, ASTContext );
 
 } // type_traits
 } // namespace tidy

Modified: clang-tools-extra/trunk/test/clang-tidy/misc-move-constructor-init.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/misc-move-constructor-init.cpp?rev=251103=251102=251103=diff
==
--- clang-tools-extra/trunk/test/clang-tidy/misc-move-constructor-init.cpp 
(original)
+++ clang-tools-extra/trunk/test/clang-tidy/misc-move-constructor-init.cpp Fri 
Oct 23 05:00:50 2015
@@ -120,11 +120,6 @@ struct NegativeParamTriviallyCopyable {
   int I_;
 };
 
-template  struct NegativeDependentType {
-  NegativeDependentType(T Value) : T_(Value) {}
-  T T_;
-};
-
 struct NegativeNotPassedByValue {
   NegativeNotPassedByValue(const Movable ) : M_(M) {}
   NegativeNotPassedByValue(const Movable M) : M_(M) {}


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

r251116 - Remove a redundant check. NFC

2015-10-23 Thread Adrian Prantl via cfe-commits

Author: adrian
Date: Fri Oct 23 11:51:32 2015
New Revision: 251116

URL: http://llvm.org/viewvc/llvm-project?rev=251116=rev
Log:
Remove a redundant check. NFC

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

Modified: cfe/trunk/lib/CodeGen/ObjectFilePCHContainerOperations.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/ObjectFilePCHContainerOperations.cpp?rev=251116=251115=251116=diff
==
--- cfe/trunk/lib/CodeGen/ObjectFilePCHContainerOperations.cpp (original)
+++ cfe/trunk/lib/CodeGen/ObjectFilePCHContainerOperations.cpp Fri Oct 23 
11:51:32 2015
@@ -159,8 +159,7 @@ public:
   }
 
   bool HandleTopLevelDecl(DeclGroupRef D) override {
-if (Diags.hasErrorOccurred() ||
-(CodeGenOpts.getDebugInfo() == CodeGenOptions::NoDebugInfo))
+if (Diags.hasErrorOccurred())
   return true;
 
 // Collect debug info for all decls in this group.


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

r251120 - Module Debugging: Emit module debug info for types inside of Objective-C

2015-10-23 Thread Adrian Prantl via cfe-commits

Author: adrian
Date: Fri Oct 23 12:02:22 2015
New Revision: 251120

URL: http://llvm.org/viewvc/llvm-project?rev=251120=rev
Log:
Module Debugging: Emit module debug info for types inside of Objective-C
containers.

rdar://problem/23196170

Modified:
cfe/trunk/lib/CodeGen/ObjectFilePCHContainerOperations.cpp
cfe/trunk/test/Modules/ExtDebugInfo.m
cfe/trunk/test/Modules/Inputs/DebugObjC.h
cfe/trunk/test/Modules/ModuleDebugInfo.m

Modified: cfe/trunk/lib/CodeGen/ObjectFilePCHContainerOperations.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/ObjectFilePCHContainerOperations.cpp?rev=251120=251119=251120=diff
==
--- cfe/trunk/lib/CodeGen/ObjectFilePCHContainerOperations.cpp (original)
+++ cfe/trunk/lib/CodeGen/ObjectFilePCHContainerOperations.cpp Fri Oct 23 
12:02:22 2015
@@ -171,6 +171,10 @@ public:
 return true;
   }
 
+  void HandleTopLevelDeclInObjCContainer(DeclGroupRef D) override {
+HandleTopLevelDecl(D);
+  }
+
   void HandleTagDeclDefinition(TagDecl *D) override {
 if (Diags.hasErrorOccurred())
   return;

Modified: cfe/trunk/test/Modules/ExtDebugInfo.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/ExtDebugInfo.m?rev=251120=251119=251120=diff
==
--- cfe/trunk/test/Modules/ExtDebugInfo.m (original)
+++ cfe/trunk/test/Modules/ExtDebugInfo.m Fri Oct 23 12:02:22 2015
@@ -19,6 +19,7 @@
 #endif
 
 int foo(ObjCClass *c) {
+  InnerEnum e = e0;
   [c instanceMethodWithInt: 0];
   return [c property];
 }
@@ -30,3 +31,6 @@ int foo(ObjCClass *c) {
 // CHECK-NOT: !DICompositeType(tag: DW_TAG_structure_type,
 // CHECK: ![[MOD]] = !DIModule(scope: null, name: {{.*}}DebugObjC
 // CHECK-NOT: !DICompositeType(tag: DW_TAG_structure_type,
+// CHECK: !DICompositeType(tag: DW_TAG_enumeration_type,
+// CHECK-SAME: scope: ![[MOD]],
+// CHECK-SAME: flags: DIFlagFwdDecl)

Modified: cfe/trunk/test/Modules/Inputs/DebugObjC.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/DebugObjC.h?rev=251120=251119=251120=diff
==
--- cfe/trunk/test/Modules/Inputs/DebugObjC.h (original)
+++ cfe/trunk/test/Modules/Inputs/DebugObjC.h Fri Oct 23 12:02:22 2015
@@ -12,3 +12,13 @@
 @interface ObjCClass (Category)
 - categoryMethod;
 @end
+
+@protocol ObjCProtocol
+
+typedef enum {
+  e0 = 0
+}  InnerEnum;
+
++ (InnerEnum)protocolMethod;
+
+@end

Modified: cfe/trunk/test/Modules/ModuleDebugInfo.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/ModuleDebugInfo.m?rev=251120=251119=251120=diff
==
--- cfe/trunk/test/Modules/ModuleDebugInfo.m (original)
+++ cfe/trunk/test/Modules/ModuleDebugInfo.m Fri Oct 23 12:02:22 2015
@@ -33,6 +33,7 @@
 // CHECK: !DISubprogram(name: "+[ObjCClass classMethod]"
 // CHECK: !DISubprogram(name: "-[ObjCClass instanceMethodWithInt:]"
 // CHECK: !DISubprogram(name: "-[ categoryMethod]"
+// CHECK: !DITypedefType(name: "InnerEnum"
 
 // MODULE-CHECK: !DICompositeType(tag: DW_TAG_structure_type,
 // MODULE-CHECK-SAME: name: "FwdDecl",


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

r251124 - [ARM] Renaming +t2dsp feature into +dsp, as discussed on llvm-dev

2015-10-23 Thread Artyom Skrobov via cfe-commits

Author: askrobov
Date: Fri Oct 23 12:19:02 2015
New Revision: 251124

URL: http://llvm.org/viewvc/llvm-project?rev=251124=rev
Log:
[ARM] Renaming +t2dsp feature into +dsp, as discussed on llvm-dev

Modified:
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/test/CodeGen/arm-target-features.c

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=251124=251123=251124=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Fri Oct 23 12:19:02 2015
@@ -4518,7 +4518,7 @@ public:
 CRC = 1;
   } else if (Feature == "+crypto") {
 Crypto = 1;
-  } else if (Feature == "+t2dsp") {
+  } else if (Feature == "+dsp") {
 DSP = 1;
   } else if (Feature == "+fp-only-sp") {
 HW_FP_remove |= HW_FP_DP; 

Modified: cfe/trunk/test/CodeGen/arm-target-features.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/arm-target-features.c?rev=251124=251123=251124=diff
==
--- cfe/trunk/test/CodeGen/arm-target-features.c (original)
+++ cfe/trunk/test/CodeGen/arm-target-features.c Fri Oct 23 12:19:02 2015
@@ -1,15 +1,15 @@
 // REQUIRES: arm-registered-target
 
 // RUN: %clang_cc1 -triple thumbv7-linux-gnueabihf -target-cpu cortex-a8 
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP3
-// CHECK-VFP3: "target-features"="+neon,+t2dsp,+vfp3"
+// CHECK-VFP3: "target-features"="+dsp,+neon,+vfp3"
 
 
 // RUN: %clang_cc1 -triple thumbv7-linux-gnueabi -target-cpu cortex-a9 
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP3-FP16
-// CHECK-VFP3-FP16: "target-features"="+fp16,+neon,+t2dsp,+vfp3"
+// CHECK-VFP3-FP16: "target-features"="+dsp,+fp16,+neon,+vfp3"
 
 
 // RUN: %clang_cc1 -triple thumbv7-linux-gnueabihf -target-cpu cortex-a5 
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4
-// CHECK-VFP4: "target-features"="+neon,+t2dsp,+vfp4"
+// CHECK-VFP4: "target-features"="+dsp,+neon,+vfp4"
 
 
 // RUN: %clang_cc1 -triple thumbv7-linux-gnueabihf -target-cpu cortex-a7 
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV
@@ -18,38 +18,38 @@
 // RUN: %clang_cc1 -triple armv7-linux-gnueabihf -target-cpu cortex-a17 
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV
 // RUN: %clang_cc1 -triple thumbv7s-linux-gnueabi -target-cpu swift -emit-llvm 
-o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV
 // RUN: %clang_cc1 -triple thumbv7-linux-gnueabihf -target-cpu krait 
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-DIV
-// CHECK-VFP4-DIV: "target-features"="+hwdiv,+hwdiv-arm,+neon,+t2dsp,+vfp4"
+// CHECK-VFP4-DIV: "target-features"="+dsp,+hwdiv,+hwdiv-arm,+neon,+vfp4"
 
 
 // RUN: %clang_cc1 -triple thumbv7s-apple-ios7.0 -target-cpu cyclone 
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
 // RUN: %clang_cc1 -triple armv8-linux-gnueabi -target-cpu cortex-a53 
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
 // RUN: %clang_cc1 -triple thumbv8-linux-gnueabihf -target-cpu cortex-a57 
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
 // RUN: %clang_cc1 -triple thumbv8-linux-gnueabihf -target-cpu cortex-a72 
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-BASIC-V8
-// CHECK-BASIC-V8: 
"target-features"="+crc,+crypto,+fp-armv8,+hwdiv,+hwdiv-arm,+neon,+t2dsp"
+// CHECK-BASIC-V8: 
"target-features"="+crc,+crypto,+dsp,+fp-armv8,+hwdiv,+hwdiv-arm,+neon"
 
 
 // RUN: %clang_cc1 -triple thumbv7-linux-gnueabi -target-cpu cortex-r5 
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP3-D16-DIV
-// CHECK-VFP3-D16-DIV: "target-features"="+d16,+hwdiv,+hwdiv-arm,+t2dsp,+vfp3"
+// CHECK-VFP3-D16-DIV: "target-features"="+d16,+dsp,+hwdiv,+hwdiv-arm,+vfp3"
 
 
 // RUN: %clang_cc1 -triple armv7-linux-gnueabi -target-cpu cortex-r4f 
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP3-D16-THUMB-DIV
-// CHECK-VFP3-D16-THUMB-DIV: "target-features"="+d16,+hwdiv,+t2dsp,+vfp3"
+// CHECK-VFP3-D16-THUMB-DIV: "target-features"="+d16,+dsp,+hwdiv,+vfp3"
 
 
 // RUN: %clang_cc1 -triple thumbv7-linux-gnueabi -target-cpu cortex-r7 
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP3-D16-FP16-DIV
-// CHECK-VFP3-D16-FP16-DIV: 
"target-features"="+d16,+fp16,+hwdiv,+hwdiv-arm,+t2dsp,+vfp3"
+// CHECK-VFP3-D16-FP16-DIV: 
"target-features"="+d16,+dsp,+fp16,+hwdiv,+hwdiv-arm,+vfp3"
 
 
 // RUN: %clang_cc1 -triple thumbv7-linux-gnueabi -target-cpu cortex-m4 
-emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-VFP4-D16-SP-THUMB-DIV
-// CHECK-VFP4-D16-SP-THUMB-DIV: 
"target-features"="+d16,+fp-only-sp,+hwdiv,+t2dsp,+vfp4"
+// CHECK-VFP4-D16-SP-THUMB-DIV: 
"target-features"="+d16,+dsp,+fp-only-sp,+hwdiv,+vfp4"
 
 
 // RUN: %clang_cc1 -triple thumbv7-linux-gnueabi -target-cpu cortex-m7 
-emit-llvm -o - %s | FileCheck %s

r251126 - Fixup this testcase after r251120.

2015-10-23 Thread Adrian Prantl via cfe-commits

Author: adrian
Date: Fri Oct 23 12:25:17 2015
New Revision: 251126

URL: http://llvm.org/viewvc/llvm-project?rev=251126=rev
Log:
Fixup this testcase after r251120.
I accidentally tested r251120 with assertions disabled.

Modified:
cfe/trunk/test/Modules/ModuleDebugInfo.m

Modified: cfe/trunk/test/Modules/ModuleDebugInfo.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/ModuleDebugInfo.m?rev=251126=251125=251126=diff
==
--- cfe/trunk/test/Modules/ModuleDebugInfo.m (original)
+++ cfe/trunk/test/Modules/ModuleDebugInfo.m Fri Oct 23 12:25:17 2015
@@ -30,16 +30,18 @@
 // CHECK-SAME: name: "ObjCClass",
 // CHECK: !DIObjCProperty(name: "property",
 // CHECK: !DIDerivedType(tag: DW_TAG_member, name: "ivar"
+// CHECK: !DIDerivedType(tag: DW_TAG_typedef, name: "InnerEnum"
 // CHECK: !DISubprogram(name: "+[ObjCClass classMethod]"
 // CHECK: !DISubprogram(name: "-[ObjCClass instanceMethodWithInt:]"
 // CHECK: !DISubprogram(name: "-[ categoryMethod]"
-// CHECK: !DITypedefType(name: "InnerEnum"
 
-// MODULE-CHECK: !DICompositeType(tag: DW_TAG_structure_type,
-// MODULE-CHECK-SAME: name: "FwdDecl",
+// MODULE-CHECK: !DICompositeType(tag: DW_TAG_enumeration_type,
 // MODULE-CHECK-SAME: scope: ![[MODULE:[0-9]+]],
 // MODULE-CHECK: ![[MODULE]] = !DIModule(scope: null, name: "DebugObjC"
 // MODULE-CHECK: !DICompositeType(tag: DW_TAG_structure_type,
+// MODULE-CHECK-SAME: name: "FwdDecl",
+// MODULE-CHECK-SAME: scope: ![[MODULE]],
+// MODULE-CHECK: !DICompositeType(tag: DW_TAG_structure_type,
 // MODULE-CHECK-SAME: name: "ObjCClass",
 // MODULE-CHECK-SAME: scope: ![[MODULE]],
 // MODULE-CHECK: !DISubprogram(name: "+[ObjCClass classMethod]",


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

Re: [PATCH] D12614: [OpenMP] Offloading descriptor registration and device codegen.

2015-10-23 Thread Samuel Antao via cfe-commits

sfantao added a comment.

Hi John,

Thanks for the remark!

In http://reviews.llvm.org/D12614#272354, @rjmccall wrote:

> CurFuncDecl is supposed to be the enclosing user function.  Things like 
> outlined functions should be getting stored in CurCodeDecl; that's how it's 
> done for blocks and lambdas.

Apologies I was not accurate in my previous post. `CurFuncDecl` is in fact the 
declaration of the enclosing user function. What is not defined in some times 
undefined is `CurGD` and this is what I was trying to use to get the right 
mangled name of the user function, given that it also encodes the structor 
type. So my question is: is there a good/safe way to get the mangled  name of 
the user function given the function declaration? I didn't find any good way to 
do that without replicating part of the stuff that happens in the mangler.

Just a little bit of context. The reason I was relying on the mangled name 
(along with source information) to unequivocally identify a target region is 
that it seemed as the most straightforward way to differentiate between 
different instances of the same template function/aggregate. So if you are 
aware of a different/easier way to accomplish the same goal please let me know.

Thanks again!
Samuel

http://reviews.llvm.org/D12614

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

Re: [PATCH] D13978: [X86] Support MCU psABI when marking inregs

2015-10-23 Thread Reid Kleckner via cfe-commits

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

lgtm with the suggested simplification.



Comment at: lib/CodeGen/TargetInfo.cpp:857
@@ -854,3 +856,3 @@
   IsWin32StructABI(Win32StructABI),
-  IsSoftFloatABI(SoftFloatABI),
+  IsSoftFloatABI(SoftFloatABI), IsMCUABI(MCUABI),
   DefaultNumRegisterParameters(NumRegisterParameters) {}

Rather than taking this as a parameter, how about initializing IsMCUABI with 
`getTarget().getTriple().isEnvironmentIAMCU()`? Then you can drop a level of 
parameters.


http://reviews.llvm.org/D13978



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

Re: [PATCH] D14014: Checker of proper vfork usage

2015-10-23 Thread Vedant Kumar via cfe-commits

vsk added a subscriber: vsk.
vsk added a comment.

Thanks for the patch.

I didn't know vfork() is in regular use. Afaict copy-on-write fork() and 
threading both solve a similar (the same?) problem. I'm also not convinced that 
flagging all stores in the vfork child process is the right thing to do, since 
the FP rate could be quite high. For example, doing 'x = malloc(4); *x = 0;' in 
the child process seems fine to me.

Some inline comments --



Comment at: lib/StaticAnalyzer/Checkers/VforkChecker.cpp:10
@@ +9,3 @@
+//
+//  This file defines chroot checker, which checks improper use of chroot.
+//

This comment needs an update.


Comment at: lib/StaticAnalyzer/Checkers/VforkChecker.cpp:38
@@ +37,3 @@
+//  |
+//  --return--> bug
+class VforkChecker : public Checker

Re: [PATCH] D7639: Add readability-redundant-void-arg check to clang-tidy

2015-10-23 Thread Richard via cfe-commits

LegalizeAdulthood marked 17 inline comments as done.
LegalizeAdulthood added a comment.

Can we get this committed?  I've addressed all comments.


http://reviews.llvm.org/D7639



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

Re: [PATCH] D7639: Add readability-redundant-void-arg check to clang-tidy

2015-10-23 Thread Samuel Benzaquen via cfe-commits

sbenza added a comment.

I'm sorry. This change fell through the cracks. I'll take a look today.


http://reviews.llvm.org/D7639



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

RE: [libcxx] r251065 - Dont required CMake 3 to install a linker script

2015-10-23 Thread Hahnfeld, Jonas via cfe-commits

Hi,

thanks for the attempt to fix this, but this isn't working for in-tree builds 
of libcxx:
CMake Error at projects/libcxx/lib/cmake_install.cmake:56 (FILE):
  file INSTALL cannot find
  "<<>>/projects/libcxx/lib/libc++.so"

It is located at <<>>/lib/libc++.so. CMake version is 2.8.12.2 which 
should be the minimum required version when building all LLVM projects.

Cheers,
Jonas

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf
> Of Eric Fiselier via cfe-commits
> Sent: Thursday, October 22, 2015 11:24 PM
> To: cfe-commits@lists.llvm.org
> Subject: [libcxx] r251065 - Dont required CMake 3 to install a linker script
>
> Author: ericwf
> Date: Thu Oct 22 16:24:01 2015
> New Revision: 251065
>
> URL: http://llvm.org/viewvc/llvm-project?rev=251065=rev
> Log:
> Dont required CMake 3 to install a linker script
>
> Modified:
> libcxx/trunk/lib/CMakeLists.txt
>
> Modified: libcxx/trunk/lib/CMakeLists.txt
> URL: http://llvm.org/viewvc/llvm-
> project/libcxx/trunk/lib/CMakeLists.txt?rev=251065=251064=251065&
> view=diff
> ==
> 
> --- libcxx/trunk/lib/CMakeLists.txt (original)
> +++ libcxx/trunk/lib/CMakeLists.txt Thu Oct 22 16:24:01 2015
> @@ -154,7 +154,6 @@ if (LIBCXX_ENABLE_ABI_LINKER_SCRIPT)
>)
>  endif()
>
> -
>  if (LIBCXX_INSTALL_LIBRARY)
>install(TARGETS cxx
>  LIBRARY DESTINATION lib${LIBCXX_LIBDIR_SUFFIX} COMPONENT libcxx
> @@ -163,7 +162,9 @@ if (LIBCXX_INSTALL_LIBRARY)
># NOTE: This install command must go after the cxx install command
> otherwise
># it will not be executed after the library symlinks are installed.
>if (LIBCXX_ENABLE_ABI_LINKER_SCRIPT)
> -install(FILES "$"
> +# Replace the libc++ filename with $
> +# after we required CMake 3.0.
> +install(FILES
> "${CMAKE_CURRENT_BINARY_DIR}/libc++${CMAKE_SHARED_LIBRARY_SUFF
> IX}"
>DESTINATION lib${LIBCXX_LIBDIR_SUFFIX}
>COMPONENT libcxx)
>endif()
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


smime.p7s
Description: S/MIME cryptographic signature
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r251065 - Dont required CMake 3 to install a linker script

2015-10-23 Thread Eric Fiselier via cfe-commits

Hi Jonas,

Thanks for being patient and sorry for the failed first attempt. I think I
fixed it in r251100.

I swear I'm normally more careful.

/Eric

On Thu, Oct 22, 2015 at 8:34 PM, Hahnfeld, Jonas <
hahnf...@itc.rwth-aachen.de> wrote:

> Hi,
>
> thanks for the attempt to fix this, but this isn't working for in-tree
> builds
> of libcxx:
> CMake Error at projects/libcxx/lib/cmake_install.cmake:56 (FILE):
>   file INSTALL cannot find
>   "<<>>/projects/libcxx/lib/libc++.so"
>
> It is located at <<>>/lib/libc++.so. CMake version is 2.8.12.2 which
> should be the minimum required version when building all LLVM projects.
>
> Cheers,
> Jonas
>
> > -Original Message-
> > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf
> > Of Eric Fiselier via cfe-commits
> > Sent: Thursday, October 22, 2015 11:24 PM
> > To: cfe-commits@lists.llvm.org
> > Subject: [libcxx] r251065 - Dont required CMake 3 to install a linker
> script
> >
> > Author: ericwf
> > Date: Thu Oct 22 16:24:01 2015
> > New Revision: 251065
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=251065=rev
> > Log:
> > Dont required CMake 3 to install a linker script
> >
> > Modified:
> > libcxx/trunk/lib/CMakeLists.txt
> >
> > Modified: libcxx/trunk/lib/CMakeLists.txt
> > URL: http://llvm.org/viewvc/llvm-
> > project/libcxx/trunk/lib/CMakeLists.txt?rev=251065=251064=251065&
> > view=diff
> > ==
> > 
> > --- libcxx/trunk/lib/CMakeLists.txt (original)
> > +++ libcxx/trunk/lib/CMakeLists.txt Thu Oct 22 16:24:01 2015
> > @@ -154,7 +154,6 @@ if (LIBCXX_ENABLE_ABI_LINKER_SCRIPT)
> >)
> >  endif()
> >
> > -
> >  if (LIBCXX_INSTALL_LIBRARY)
> >install(TARGETS cxx
> >  LIBRARY DESTINATION lib${LIBCXX_LIBDIR_SUFFIX} COMPONENT libcxx
> > @@ -163,7 +162,9 @@ if (LIBCXX_INSTALL_LIBRARY)
> ># NOTE: This install command must go after the cxx install command
> > otherwise
> ># it will not be executed after the library symlinks are installed.
> >if (LIBCXX_ENABLE_ABI_LINKER_SCRIPT)
> > -install(FILES "$"
> > +# Replace the libc++ filename with $
> > +# after we required CMake 3.0.
> > +install(FILES
> > "${CMAKE_CURRENT_BINARY_DIR}/libc++${CMAKE_SHARED_LIBRARY_SUFF
> > IX}"
> >DESTINATION lib${LIBCXX_LIBDIR_SUFFIX}
> >COMPONENT libcxx)
> >endif()
> >
> >
> > ___
> > cfe-commits mailing list
> > cfe-commits@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[libcxx] r251100 - Use proper output directory when naminging the libc++ output

2015-10-23 Thread Eric Fiselier via cfe-commits

Author: ericwf
Date: Fri Oct 23 02:04:24 2015
New Revision: 251100

URL: http://llvm.org/viewvc/llvm-project?rev=251100=rev
Log:
Use proper output directory when naminging the  libc++ output

Modified:
libcxx/trunk/lib/CMakeLists.txt

Modified: libcxx/trunk/lib/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/lib/CMakeLists.txt?rev=251100=251099=251100=diff
==
--- libcxx/trunk/lib/CMakeLists.txt (original)
+++ libcxx/trunk/lib/CMakeLists.txt Fri Oct 23 02:04:24 2015
@@ -164,7 +164,7 @@ if (LIBCXX_INSTALL_LIBRARY)
   if (LIBCXX_ENABLE_ABI_LINKER_SCRIPT)
 # Replace the libc++ filename with $
 # after we required CMake 3.0.
-install(FILES 
"${CMAKE_CURRENT_BINARY_DIR}/libc++${CMAKE_SHARED_LIBRARY_SUFFIX}"
+install(FILES "${LIBCXX_LIBRARY_DIR}/libc++${CMAKE_SHARED_LIBRARY_SUFFIX}"
   DESTINATION lib${LIBCXX_LIBDIR_SUFFIX}
   COMPONENT libcxx)
   endif()


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

RE: [libcxx] r251065 - Dont required CMake 3 to install a linker script

2015-10-23 Thread Hahnfeld, Jonas via cfe-commits

No problem, seems to work now :-)



Thanks

Jonas



From: Eric Fiselier [mailto:e...@efcs.ca]
Sent: Friday, October 23, 2015 9:08 AM
To: Hahnfeld, Jonas
Cc: cfe-commits@lists.llvm.org
Subject: Re: [libcxx] r251065 - Dont required CMake 3 to install a linker 
script



Hi Jonas,



Thanks for being patient and sorry for the failed first attempt. I think I 
fixed it in r251100.



I swear I'm normally more careful.



/Eric



On Thu, Oct 22, 2015 at 8:34 PM, Hahnfeld, Jonas  
wrote:

Hi,

thanks for the attempt to fix this, but this isn't working for in-tree builds
of libcxx:
CMake Error at projects/libcxx/lib/cmake_install.cmake:56 (FILE):
  file INSTALL cannot find
  "<<>>/projects/libcxx/lib/libc++.so"

It is located at <<>>/lib/libc++.so. CMake version is 2.8.12.2 which
should be the minimum required version when building all LLVM projects.

Cheers,
Jonas


> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf
> Of Eric Fiselier via cfe-commits
> Sent: Thursday, October 22, 2015 11:24 PM
> To: cfe-commits@lists.llvm.org
> Subject: [libcxx] r251065 - Dont required CMake 3 to install a linker script
>
> Author: ericwf
> Date: Thu Oct 22 16:24:01 2015
> New Revision: 251065
>
> URL: http://llvm.org/viewvc/llvm-project?rev=251065 
>  =rev
> Log:
> Dont required CMake 3 to install a linker script
>
> Modified:
> libcxx/trunk/lib/CMakeLists.txt
>
> Modified: libcxx/trunk/lib/CMakeLists.txt
> URL: http://llvm.org/viewvc/llvm-
> project/libcxx/trunk/lib/CMakeLists.txt?rev=251065=251064=251065&
> view=diff
> ==
> 
> --- libcxx/trunk/lib/CMakeLists.txt (original)
> +++ libcxx/trunk/lib/CMakeLists.txt Thu Oct 22 16:24:01 2015
> @@ -154,7 +154,6 @@ if (LIBCXX_ENABLE_ABI_LINKER_SCRIPT)
>)
>  endif()
>
> -
>  if (LIBCXX_INSTALL_LIBRARY)
>install(TARGETS cxx
>  LIBRARY DESTINATION lib${LIBCXX_LIBDIR_SUFFIX} COMPONENT libcxx
> @@ -163,7 +162,9 @@ if (LIBCXX_INSTALL_LIBRARY)
># NOTE: This install command must go after the cxx install command
> otherwise
># it will not be executed after the library symlinks are installed.
>if (LIBCXX_ENABLE_ABI_LINKER_SCRIPT)
> -install(FILES "$"
> +# Replace the libc++ filename with $
> +# after we required CMake 3.0.
> +install(FILES
> "${CMAKE_CURRENT_BINARY_DIR}/libc++${CMAKE_SHARED_LIBRARY_SUFF
> IX}"
>DESTINATION lib${LIBCXX_LIBDIR_SUFFIX}
>COMPONENT libcxx)
>endif()
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits





smime.p7s
Description: S/MIME cryptographic signature
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D14014: Checker of proper vfork usage

2015-10-23 Thread Devin Coughlin via cfe-commits

dcoughlin added a comment.

Hi Yury,

Thanks for the patch. This is definitely interesting for upstream!

One thing to note (which I assume you are already aware of) is that we already 
have the "security.insecureAPI.vfork" checker, an AST check that warns on 
*every* use of vfork. This check is on by default (which I think makes sense, 
given the variety of ways that vfork is problematic) -- so users of your more 
permissive check would have to disable the default check.

Comment at: lib/StaticAnalyzer/Checkers/Checkers.td:360
@@ +359,3 @@
+def VforkChecker : Checker<"Vfork">,
+  HelpText<"Check for proper usage of vfork.">,
+  DescFile<"VforkChecker.cpp">;

The convention here is to not have a '.' after the help text.

Comment at: lib/StaticAnalyzer/Checkers/VforkChecker.cpp:61
@@ +60,3 @@
+
+  // these are used to track vfork state
+  void checkPostCall(const CallEvent , CheckerContext ) const;

LLVM convention is to use capitalization and punctuation for comments. (See 
http://llvm.org/docs/CodingStandards.html#commenting).

Comment at: lib/StaticAnalyzer/Checkers/VforkChecker.cpp:74
@@ +73,3 @@
+// region child is allowed to write)
+REGISTER_TRAIT_WITH_PROGRAMSTATE(VforkLhs, const void *)
+#define VFORK_LHS_NONE ((void *)(uintptr_t)1)

Is it possible to use a name that implies a more semantic notion? For example, 
"VforkResultRegion"?

Comment at: lib/StaticAnalyzer/Checkers/VforkChecker.cpp:102
@@ +101,3 @@
+
+  for (SmallVectorImpl::iterator
+ I = VforkWhitelist.begin(), E = VforkWhitelist.end();

I think it is better to use SmallSet for VforkWhitelist rather than duplicate 
that functionality here.

Comment at: lib/StaticAnalyzer/Checkers/VforkChecker.cpp:115
@@ +114,3 @@
+BT_BadChildCode.reset(
+  new BuiltinBug(this, "Dangerous construct in vforked process",
+ "Prohibited construct after successful "

What do you think about making the warnings more descriptive here? For example, 
you could one warning saying that "Child can only modify variable used to store 
result of vfork()", one that says "Child can only call _exit() or `exec()` 
family of functions", "Child must not return from function calling vfork()", 
etc.

These descriptions would help the user not have to guess what they are doing 
wrong.

Comment at: lib/StaticAnalyzer/Checkers/VforkChecker.cpp:118
@@ +117,3 @@
+ "vfork"));
+  ExplodedNode *N = C.generateSink(C.getState(), C.getPredecessor());
+  auto Report = llvm::make_unique(*BT_BadChildCode, 

You should use `C.generateErrorNode()` here, which expresses the intent to 
create a node for the purposes of error reporting.

Comment at: lib/StaticAnalyzer/Checkers/VforkChecker.cpp:135
@@ +134,3 @@
+  do {
+const DeclStmt *PD = dyn_cast_or_null(P);
+if (!PD)

For dyn_cast and friends and you use `auto` to avoid repeating the type twice. 
For example:

```
const auto *PD = dyn_cast_or_null(P);
```

Comment at: lib/StaticAnalyzer/Checkers/VforkChecker.cpp:186
@@ +185,3 @@
+ CheckerContext ) const {
+  // we can't call vfork in child so don't bother
+  ProgramStateRef State = C.getState();

vsk wrote:
> Actually, if this is the case, wouldn't it be worthwhile to flag calls to 
> vfork() in child processes?
This will get caught by `checkPreCall`, right? Because `vfork` is not in the 
white list.

Comment at: test/Analysis/vfork-1.c:1
@@ +1,2 @@
+// RUN: %clang_cc1 -analyze 
-analyzer-checker=core.builtin.NoReturnFunctions,alpha.unix.Vfork %s -verify
+

Tests generally need to have all of core turned on (e.g., 
`-analyzer-checker=core,alpha.unix.Vfork`) because the analyzer implements key 
functionality in the core checkers. (It is not safe to run a path-sensitive 
checker without core turned on).

Comment at: test/Analysis/vfork-1.c:68
@@ +67,3 @@
+  if (vfork() == 0)
+_exit(1);
+  x = 0;

I think it would be good to add `// no-warning` on the lines that shouldn't 
warn. This will make it easier for people tracking down test failures to know 
that there really shouldn't be a warning on that line.

Comment at: test/Analysis/vfork-2.c:1
@@ +1,2 @@
+// RUN: %clang_cc1 -analyze -analyzer-checker=alpha.unix.Vfork %s -verify
+

Is it possible to combine this with the other test file? If not, can you rename 
the files to be more descriptive than "-1" or "-2". This will help people 
adding future tests decide which file they should go in.

Repository:
  rL LLVM

http://reviews.llvm.org/D14014

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

Re: [PATCH] D14014: Checker of proper vfork usage

2015-10-23 Thread Yury Gribov via cfe-commits

ygribov added a comment.

> This is a valid concern because it greatly complicates enablement of 
> VforkChecker for a casual user.


I think at the very least I can check that InsecureAPI is enable and issue a 
warning to user.


Repository:
  rL LLVM

http://reviews.llvm.org/D14014



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

Re: [PATCH] D13144: [CUDA] propagate to CUDA sub-compilations target triple of opposite side.

2015-10-23 Thread Artem Belevich via cfe-commits

tra updated this revision to Diff 38269.
tra added a comment.

Instead of passing AuxTriple around as an argument, store ToolChain info in 
Compilation and retrieve it from there.


http://reviews.llvm.org/D13144

Files:
  include/clang/Driver/Compilation.h
  include/clang/Driver/Driver.h
  lib/Driver/Compilation.cpp
  lib/Driver/Driver.cpp
  lib/Driver/Tools.cpp
  test/Driver/cuda-options.cu
  test/SemaCUDA/function-target-hd.cu

Index: test/SemaCUDA/function-target-hd.cu
===
--- test/SemaCUDA/function-target-hd.cu
+++ test/SemaCUDA/function-target-hd.cu
@@ -8,9 +8,9 @@
 // host device functions are not allowed to call device functions.
 
 // RUN: %clang_cc1 -fsyntax-only -verify %s
-// RUN: %clang_cc1 -fsyntax-only -fcuda-is-device -verify %s
+// RUN: %clang_cc1 -fsyntax-only -fcuda-is-device -triple nvptx-unknown-cuda -verify %s
 // RUN: %clang_cc1 -fsyntax-only -fcuda-allow-host-calls-from-host-device -verify %s -DTEST_WARN_HD
-// RUN: %clang_cc1 -fsyntax-only -fcuda-is-device -fcuda-allow-host-calls-from-host-device -verify %s -DTEST_WARN_HD
+// RUN: %clang_cc1 -fsyntax-only -fcuda-is-device -triple nvptx-unknown-cuda -fcuda-allow-host-calls-from-host-device -verify %s -DTEST_WARN_HD
 
 #include "Inputs/cuda.h"
 
Index: test/Driver/cuda-options.cu
===
--- test/Driver/cuda-options.cu
+++ test/Driver/cuda-options.cu
@@ -111,14 +111,6 @@
 // Make sure we don't link anything.
 // RUN:   -check-prefix CUDA-NL %s
 
-// Match device-side preprocessor, and compiler phases with -save-temps
-// CUDA-D1S: "-cc1" "-triple" "nvptx{{(64)?}}-nvidia-cuda"
-// CUDA-D1S-SAME: "-fcuda-is-device"
-// CUDA-D1S-SAME: "-x" "cuda"
-// CUDA-D1S: "-cc1" "-triple" "nvptx{{(64)?}}-nvidia-cuda"
-// CUDA-D1S-SAME: "-fcuda-is-device"
-// CUDA-D1S-SAME: "-x" "cuda-cpp-output"
-
 // --cuda-host-only should never trigger unused arg warning.
 // RUN: %clang -### -target x86_64-linux-gnu --cuda-host-only -c %s 2>&1 | \
 // RUN:FileCheck -check-prefix CUDA-NO-UNUSED-CHO %s
@@ -133,34 +125,47 @@
 // RUN: %clang -### -target x86_64-linux-gnu --cuda-device-only -x c -c %s 2>&1 | \
 // RUN:FileCheck -check-prefix CUDA-UNUSED-CDO %s
 
+// Match device-side preprocessor, and compiler phases with -save-temps
+// CUDA-D1S: "-cc1" "-triple" "nvptx64-nvidia-cuda"
+// CUDA-D1S-SAME: "-aux-triple" "x86_64--linux-gnu"
+// CUDA-D1S-SAME: "-fcuda-is-device"
+// CUDA-D1S-SAME: "-x" "cuda"
+
+// CUDA-D1S: "-cc1" "-triple" "nvptx64-nvidia-cuda"
+// CUDA-D1S-SAME: "-aux-triple" "x86_64--linux-gnu"
+// CUDA-D1S-SAME: "-fcuda-is-device"
+// CUDA-D1S-SAME: "-x" "cuda-cpp-output"
+
 // Match the job that produces PTX assembly
-// CUDA-D1: "-cc1" "-triple" "nvptx{{(64)?}}-nvidia-cuda"
+// CUDA-D1: "-cc1" "-triple" "nvptx64-nvidia-cuda"
+// CUDA-D1NS-SAME: "-aux-triple" "x86_64--linux-gnu"
 // CUDA-D1-SAME: "-fcuda-is-device"
 // CUDA-D1-SM35-SAME: "-target-cpu" "sm_35"
 // CUDA-D1-SAME: "-o" "[[GPUBINARY1:[^"]*]]"
 // CUDA-D1NS-SAME: "-x" "cuda"
 // CUDA-D1S-SAME: "-x" "ir"
 
-// Match anothe device-side compilation
-// CUDA-D2: "-cc1" "-triple" "nvptx{{(64)?}}-nvidia-cuda"
+// Match another device-side compilation
+// CUDA-D2: "-cc1" "-triple" "nvptx64-nvidia-cuda"
+// CUDA-D2-SAME: "-aux-triple" "x86_64--linux-gnu"
 // CUDA-D2-SAME: "-fcuda-is-device"
 // CUDA-D2-SM30-SAME: "-target-cpu" "sm_30"
 // CUDA-D2-SAME: "-o" "[[GPUBINARY2:[^"]*]]"
 // CUDA-D2-SAME: "-x" "cuda"
 
 // Match no device-side compilation
-// CUDA-ND-NOT: "-cc1" "-triple" "nvptx{{(64)?}}-nvidia-cuda"
+// CUDA-ND-NOT: "-cc1" "-triple" "nvptx64-nvidia-cuda"
 // CUDA-ND-SAME-NOT: "-fcuda-is-device"
 
 // Match host-side preprocessor job with -save-temps
-// CUDA-HS: "-cc1" "-triple"
-// CUDA-HS-SAME-NOT: "nvptx{{(64)?}}-nvidia-cuda"
+// CUDA-HS: "-cc1" "-triple" "x86_64--linux-gnu"
+// CUDA-HS-SAME: "-aux-triple" "nvptx64-nvidia-cuda"
 // CUDA-HS-SAME-NOT: "-fcuda-is-device"
 // CUDA-HS-SAME: "-x" "cuda"
 
 // Match host-side compilation
-// CUDA-H: "-cc1" "-triple"
-// CUDA-H-SAME-NOT: "nvptx{{(64)?}}-nvidia-cuda"
+// CUDA-H: "-cc1" "-triple" "x86_64--linux-gnu"
+// CUDA-H-SAME: "-aux-triple" "nvptx64-nvidia-cuda"
 // CUDA-H-SAME-NOT: "-fcuda-is-device"
 // CUDA-H-SAME: "-o" "[[HOSTOUTPUT:[^"]*]]"
 // CUDA-HNS-SAME: "-x" "cuda"
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -3197,6 +3197,20 @@
   CmdArgs.push_back("-triple");
   CmdArgs.push_back(Args.MakeArgString(TripleStr));
 
+  if (IsCuda) {
+const ToolChain *AuxToolChain;
+if (() == C.getCudaDeviceToolChain())
+  AuxToolChain = C.getCudaHostToolChain();
+else if (() == C.getCudaHostToolChain())
+  AuxToolChain = C.getCudaDeviceToolChain();
+else
+  llvm_unreachable("Can't figure out CUDA compilation mode.");
+if (AuxToolChain) {
+  CmdArgs.push_back("-aux-triple");

Re: [PATCH] D14014: Checker of proper vfork usage

2015-10-23 Thread Yury Gribov via cfe-commits

ygribov added a comment.

> I didn't know vfork() is in regular use.


Neither did I, until I had to debug the damned code. Actually Android has some 
5 or 6 uses of it.

> I'm also not convinced that flagging all stores in the vfork child process is 
> the right thing to do,

>  since the FP rate could be quite high.


I also have these concerns. Manpage is very strict about behavior of vforked 
processes (for a good reason though). Currently most uses of vfork are 
incorrect according to this checker.

I think there is some potential to relax the constraints:

- at the very least we can allow calls to functions marked as inline as those 
won't result in any memory writes
- we can even allow to call any functions which are guaranteed to not change 
global state

> For example, doing 'x = malloc(4); *x = 0;' in the child process seems fine 
> to me.


I also thought about similar examples. Here are some not so obvious 
side-effects:

- you'll get a memory leak (as malloc will be shared by parent and child 
processes)
- in the following case behavior of parent is undefined because original value 
of variable will be corrupted:

  x = some_very_important_lost;
  if (vfork()==0) {
x = ...; // some_very_important_data is lost
_exit(1);
  }
  // parent code
  if (some_very_important_data) {
// UB
  }

- even if child does not explicitly write any parent's variables, compiler may 
decide to merge stack slots so write into a local variable in child process may 
corrupt a seemingly unrelated variable in parent



Comment at: lib/StaticAnalyzer/Checkers/VforkChecker.cpp:10
@@ +9,3 @@
+//
+//  This file defines chroot checker, which checks improper use of chroot.
+//

vsk wrote:
> This comment needs an update.
Yikes, thanks for pointing this out.


Comment at: lib/StaticAnalyzer/Checkers/VforkChecker.cpp:38
@@ +37,3 @@
+//  |
+//  --return--> bug
+class VforkChecker : public Checker Please clarify this comment -- it might be better to state a list of specific 
> buggy conditions.
> 
> E.g, are writes into heap-allocated allowed? Where are return statements 
> allowed?
This primitive scheme simply mirrors the manpage which is very strict about 
this - write to _any_ data besides return value of vfork is disallowed, ditto 
for function calls (and so "return" only applies to current function).


Comment at: lib/StaticAnalyzer/Checkers/VforkChecker.cpp:44
@@ +43,3 @@
+
+  // This bug refers to dangerous code in vforked child.
+  mutable std::unique_ptr BT_BadChildCode;

vsk wrote:
> This comment isn't needed -- a description to this effect can go in the 
> top-of-file comment.
Right.


Comment at: lib/StaticAnalyzer/Checkers/VforkChecker.cpp:65
@@ +64,3 @@
+
+  // these constructs are prohibited in vforked child
+  void checkPreCall(const CallEvent , CheckerContext ) const;

vsk wrote:
> This comment doesn't add much, please remove it.
Ok.


Comment at: lib/StaticAnalyzer/Checkers/VforkChecker.cpp:75
@@ +74,3 @@
+REGISTER_TRAIT_WITH_PROGRAMSTATE(VforkLhs, const void *)
+#define VFORK_LHS_NONE ((void *)(uintptr_t)1)
+

vsk wrote:
> Why not nullptr? If there's a good reason, please explain it with a comment.
Ok, this indeed deserves a comment. FTR: nullptr means parent process, 
VFORK_LHS_NONE means vforked process without explicit LHS and rest means LHS 
variable.


Comment at: lib/StaticAnalyzer/Checkers/VforkChecker.cpp:147
@@ +146,3 @@
+return D;
+  } while (0);
+

vsk wrote:
> This is hard to read, please simplify this. E.g;
> 
>   if (PD = dyn-cast(P)) { /* handle cases where P is-a DeclStmt */ }
>   else if (Assign = dyn-cast(P)) { /* handle cases where P is-a binop */ }
> 
> Using loop constructs here shouldn't be necessary.
In this case each statement depends on the previous one so we'll have to resort 
to deeply nested conditionals. I thought that do-while-false is a common 
pattern for simplifying such constructs but I may be wrong.


Comment at: lib/StaticAnalyzer/Checkers/VforkChecker.cpp:167
@@ +166,3 @@
+  // otherwise no lhs
+  return (const VarDecl *)VFORK_LHS_NONE;
+}

vsk wrote:
> Typically nullptr is used here.
See my comment above, these two encode two different things.


Comment at: lib/StaticAnalyzer/Checkers/VforkChecker.cpp:186
@@ +185,3 @@
+ CheckerContext ) const {
+  // we can't call vfork in child so don't bother
+  ProgramStateRef State = C.getState();

dcoughlin wrote:
> vsk wrote:
> > Actually, if this is the case, wouldn't it be worthwhile to flag calls to 
> > vfork() in child processes?
> This will get caught by `checkPreCall`, right? Because `vfork` is not in the 
> white list.

Re: [PATCH] D14014: Checker of proper vfork usage

2015-10-23 Thread Devin Coughlin via cfe-commits

dcoughlin added a comment.

> For example, doing 'x = malloc(4); *x = 0;' in the child process seems fine 
> to me.


I don't think this is necessarily safe. For example, malloc() could end up both 
modifying memory shared between the child and parent process but only modifying 
process state for the child, leaving the parent in an inconsistent state.

POSIX (before removing vfork() completely) was pretty brutal about the 
restrictions in the child:

> ...the behavior is undefined if the process created by vfork() either 
> modifies any data other than a variable of type pid_t used to store the 
> return value from vfork(), or returns from the function in which vfork() was 
> called, or calls any other function before successfully calling _exit() or 
> one of the exec family of functions.





Repository:
  rL LLVM

http://reviews.llvm.org/D14014



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

Re: [PATCH] D14014: Checker of proper vfork usage

2015-10-23 Thread Yury Gribov via cfe-commits

ygribov added a comment.

> One thing to note (which I assume you are already aware of) is that we 
> already have the "security.insecureAPI.vfork" checker,

>  an AST check that warns on *every* use of vfork.


Yes, I was aware of this one. Unfortunately as I mentioned above vfork is 
probably to stay with us for quite a while.

> This check is on by default (which I think makes sense, given the variety of 
> ways that vfork is problematic) --

>  so users of your more permissive check would have to disable the default 
> check.


This is a valid concern because it greatly complicates enablement of 
VforkChecker for a casual user. Do we have some mechanism so that one checker 
(here VforkChecker) could disable/modify behavior of it's less precise 
companion (insecureAPI)? This sounds like a generally useful feature (although 
it damages the modularity of checkers).



Comment at: lib/StaticAnalyzer/Checkers/Checkers.td:360
@@ +359,3 @@
+def VforkChecker : Checker<"Vfork">,
+  HelpText<"Check for proper usage of vfork.">,
+  DescFile<"VforkChecker.cpp">;

dcoughlin wrote:
> The convention here is to not have a '.' after the help text.
Got it.


Comment at: lib/StaticAnalyzer/Checkers/VforkChecker.cpp:61
@@ +60,3 @@
+
+  // these are used to track vfork state
+  void checkPostCall(const CallEvent , CheckerContext ) const;

dcoughlin wrote:
> LLVM convention is to use capitalization and punctuation for comments. (See 
> http://llvm.org/docs/CodingStandards.html#commenting).
Thanks, I should probably re-read the std once again.


Comment at: lib/StaticAnalyzer/Checkers/VforkChecker.cpp:74
@@ +73,3 @@
+// region child is allowed to write)
+REGISTER_TRAIT_WITH_PROGRAMSTATE(VforkLhs, const void *)
+#define VFORK_LHS_NONE ((void *)(uintptr_t)1)

dcoughlin wrote:
> Is it possible to use a name that implies a more semantic notion? For 
> example, "VforkResultRegion"?
That would be the fourth iteration of the name) But yes, "Result region" sounds 
more descriptive.


Comment at: lib/StaticAnalyzer/Checkers/VforkChecker.cpp:102
@@ +101,3 @@
+
+  for (SmallVectorImpl::iterator
+ I = VforkWhitelist.begin(), E = VforkWhitelist.end();

dcoughlin wrote:
> I think it is better to use SmallSet for VforkWhitelist rather than duplicate 
> that functionality here.
Ok.


Comment at: lib/StaticAnalyzer/Checkers/VforkChecker.cpp:115
@@ +114,3 @@
+BT_BadChildCode.reset(
+  new BuiltinBug(this, "Dangerous construct in vforked process",
+ "Prohibited construct after successful "

dcoughlin wrote:
> What do you think about making the warnings more descriptive here? For 
> example, you could one warning saying that "Child can only modify variable 
> used to store result of vfork()", one that says "Child can only call _exit() 
> or `exec()` family of functions", "Child must not return from function 
> calling vfork()", etc.
> 
> These descriptions would help the user not have to guess what they are doing 
> wrong.
Yes, given the public ignorance about vfork's idiosyncrasies that makes good 
sense.


Comment at: lib/StaticAnalyzer/Checkers/VforkChecker.cpp:118
@@ +117,3 @@
+ "vfork"));
+  ExplodedNode *N = C.generateSink(C.getState(), C.getPredecessor());
+  auto Report = llvm::make_unique(*BT_BadChildCode, 

dcoughlin wrote:
> You should use `C.generateErrorNode()` here, which expresses the intent to 
> create a node for the purposes of error reporting.
Will do.


Comment at: lib/StaticAnalyzer/Checkers/VforkChecker.cpp:135
@@ +134,3 @@
+  do {
+const DeclStmt *PD = dyn_cast_or_null(P);
+if (!PD)

dcoughlin wrote:
> For dyn_cast and friends and you use `auto` to avoid repeating the type 
> twice. For example:
> 
> ```
> const auto *PD = dyn_cast_or_null(P);
> ```
True. This was forward-ported from our ancient version so lacks C++11 beauties.


Comment at: test/Analysis/vfork-1.c:1
@@ +1,2 @@
+// RUN: %clang_cc1 -analyze 
-analyzer-checker=core.builtin.NoReturnFunctions,alpha.unix.Vfork %s -verify
+

dcoughlin wrote:
> Tests generally need to have all of core turned on (e.g., 
> `-analyzer-checker=core,alpha.unix.Vfork`) because the analyzer implements 
> key functionality in the core checkers. (It is not safe to run a 
> path-sensitive checker without core turned on).
Ok, good to know.


Comment at: test/Analysis/vfork-1.c:68
@@ +67,3 @@
+  if (vfork() == 0)
+_exit(1);
+  x = 0;

dcoughlin wrote:
> I think it would be good to add `// no-warning` on the lines that shouldn't 
> warn. This will make it easier for people tracking down test failures to know 
> that there really shouldn't be a warning on that line.
Sounds like a good maintenance practice, I'll definitely add it.

[PATCH] D14030: Use linker option to reference profile runtime hook (Linux)

2015-10-23 Thread David Li via cfe-commits

davidxl created this revision.
davidxl added a reviewer: bogner.
davidxl added a subscriber: cfe-commits.

Currently when profile instrumentation is on, the compiler emits a runtime hook 
use function (__llvm_profile_runtime_use) for every module that is 
instrumented. The generated function references hook __llvm_profile_runtime in 
order for linker to link in runtime initialization module 
(InstrProfilingRuntime.o) that registers the profile dumper atexit.  The cost 
(though very small) can be avoided by changing the driver to emit the right 
linker option.

The clang patch itself does not change any functionality. There will be a 
follow up patch in LLVM that disables the hook use emission once this one is 
committed.

http://reviews.llvm.org/D14030

Files:
  lib/Driver/ToolChains.cpp
  lib/Driver/ToolChains.h

Index: lib/Driver/ToolChains.h
===
--- lib/Driver/ToolChains.h
+++ lib/Driver/ToolChains.h
@@ -744,6 +744,8 @@
   llvm::opt::ArgStringList ) const override;
   bool isPIEDefault() const override;
   SanitizerMask getSupportedSanitizers() const override;
+  void addProfileRTLibs(const llvm::opt::ArgList ,
+llvm::opt::ArgStringList ) const override;
 
   std::string Linker;
   std::vector ExtraOpts;
Index: lib/Driver/ToolChains.cpp
===
--- lib/Driver/ToolChains.cpp
+++ lib/Driver/ToolChains.cpp
@@ -25,6 +25,7 @@
 #include "llvm/Option/ArgList.h"
 #include "llvm/Option/OptTable.h"
 #include "llvm/Option/Option.h"
+#include "llvm/ProfileData/InstrProf.h"
 #include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/MemoryBuffer.h"
@@ -3811,6 +3812,18 @@
   return Res;
 }
 
+void Linux::addProfileRTLibs(const llvm::opt::ArgList ,
+ llvm::opt::ArgStringList ) const {
+  if (!needsProfileRT(Args)) return;
+
+  // Add linker option -u__llvm_runtime_variable to cause runtime
+  // initialization module to be linked in.
+  if (!Args.hasArg(options::OPT_coverage))
+CmdArgs.push_back(Args.MakeArgString(
+Twine("-u", llvm::getInstrProfRuntimeHookVarName(;
+  ToolChain::addProfileRTLibs(Args, CmdArgs);
+}
+
 /// DragonFly - DragonFly tool chain which can call as(1) and ld(1) directly.
 
 DragonFly::DragonFly(const Driver , const llvm::Triple ,


Index: lib/Driver/ToolChains.h
===
--- lib/Driver/ToolChains.h
+++ lib/Driver/ToolChains.h
@@ -744,6 +744,8 @@
   llvm::opt::ArgStringList ) const override;
   bool isPIEDefault() const override;
   SanitizerMask getSupportedSanitizers() const override;
+  void addProfileRTLibs(const llvm::opt::ArgList ,
+llvm::opt::ArgStringList ) const override;
 
   std::string Linker;
   std::vector ExtraOpts;
Index: lib/Driver/ToolChains.cpp
===
--- lib/Driver/ToolChains.cpp
+++ lib/Driver/ToolChains.cpp
@@ -25,6 +25,7 @@
 #include "llvm/Option/ArgList.h"
 #include "llvm/Option/OptTable.h"
 #include "llvm/Option/Option.h"
+#include "llvm/ProfileData/InstrProf.h"
 #include "llvm/Support/ErrorHandling.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/MemoryBuffer.h"
@@ -3811,6 +3812,18 @@
   return Res;
 }
 
+void Linux::addProfileRTLibs(const llvm::opt::ArgList ,
+ llvm::opt::ArgStringList ) const {
+  if (!needsProfileRT(Args)) return;
+
+  // Add linker option -u__llvm_runtime_variable to cause runtime
+  // initialization module to be linked in.
+  if (!Args.hasArg(options::OPT_coverage))
+CmdArgs.push_back(Args.MakeArgString(
+Twine("-u", llvm::getInstrProfRuntimeHookVarName(;
+  ToolChain::addProfileRTLibs(Args, CmdArgs);
+}
+
 /// DragonFly - DragonFly tool chain which can call as(1) and ld(1) directly.
 
 DragonFly::DragonFly(const Driver , const llvm::Triple ,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D14011: [AST] Re-add TypeLocs and NestedNameSpecifierLocs to the ParentMap.

2015-10-23 Thread Benjamin Kramer via cfe-commits

bkramer created this revision.
bkramer added reviewers: klimek, djasper.
bkramer added a subscriber: cfe-commits.
Herald added a subscriber: klimek.

This relands r250831 after some fixes to shrink the ParentMap overall
with one addtional tweak: nodes with pointer identity (e.g. Decl* and
friends) can be store more efficiently so I put them in a separate map.
All other nodes (so far only TypeLoc and NNSLoc) go in a different map
keyed on DynTypedNode. This further uglifies the code but significantly
reduces memory overhead.

Overall this change still make ParentMap significantly larger but it's
nowhere as bad as before. I see about 25 MB over baseline (pre-r251008)
on X86ISelLowering.cpp. If this becomes an issue we could consider
splitting the maps further as DynTypedNode is still larger (32 bytes)
than a single TypeLoc (16 bytes) but I didn't want to introduce even
more complexity now.

http://reviews.llvm.org/D14011

Files:
  include/clang/AST/ASTContext.h
  include/clang/AST/ASTTypeTraits.h
  include/clang/ASTMatchers/ASTMatchers.h
  include/clang/ASTMatchers/ASTMatchersInternal.h
  lib/AST/ASTContext.cpp
  lib/ASTMatchers/ASTMatchFinder.cpp
  unittests/AST/ASTContextParentMapTest.cpp
  unittests/ASTMatchers/Dynamic/ParserTest.cpp
  unittests/ASTMatchers/Dynamic/RegistryTest.cpp

Index: unittests/ASTMatchers/Dynamic/RegistryTest.cpp
===
--- unittests/ASTMatchers/Dynamic/RegistryTest.cpp
+++ unittests/ASTMatchers/Dynamic/RegistryTest.cpp
@@ -448,7 +448,9 @@
   CompVector Comps = getCompletions();
   // Overloaded
   EXPECT_TRUE(hasCompletion(
-  Comps, "hasParent(", "Matcher hasParent(Matcher)"));
+  Comps, "hasParent(",
+  "Matcher "
+  "hasParent(Matcher)"));
   // Variadic.
   EXPECT_TRUE(hasCompletion(Comps, "whileStmt(",
 "Matcher whileStmt(Matcher...)"));
@@ -464,7 +466,9 @@
   EXPECT_TRUE(hasCompletion(WhileComps, "hasBody(",
 "Matcher hasBody(Matcher)"));
   EXPECT_TRUE(hasCompletion(WhileComps, "hasParent(",
-"Matcher hasParent(Matcher)"));
+"Matcher "
+"hasParent(Matcher)"));
   EXPECT_TRUE(
   hasCompletion(WhileComps, "allOf(", "Matcher allOf(Matcher...)"));
 
Index: unittests/ASTMatchers/Dynamic/ParserTest.cpp
===
--- unittests/ASTMatchers/Dynamic/ParserTest.cpp
+++ unittests/ASTMatchers/Dynamic/ParserTest.cpp
@@ -318,8 +318,10 @@
   Comps[1].MatcherDecl);
 
   EXPECT_EQ("arent(", Comps[2].TypedText);
-  EXPECT_EQ("Matcher hasParent(Matcher)",
-Comps[2].MatcherDecl);
+  EXPECT_EQ(
+  "Matcher "
+  "hasParent(Matcher)",
+  Comps[2].MatcherDecl);
 }
 
 }  // end anonymous namespace
Index: unittests/AST/ASTContextParentMapTest.cpp
===
--- unittests/AST/ASTContextParentMapTest.cpp
+++ unittests/AST/ASTContextParentMapTest.cpp
@@ -38,6 +38,19 @@
  ifStmt(hasParent(compoundStmt();
 }
 
+TEST(GetParents, ReturnsParentForTypeLoc) {
+  MatchVerifier Verifier;
+  EXPECT_TRUE(
+  Verifier.match("namespace a { class b {}; } void f(a::b) {}",
+ typeLoc(hasParent(typeLoc(hasParent(functionDecl()));
+}
+
+TEST(GetParents, ReturnsParentForNestedNameSpecifierLoc) {
+  MatchVerifier Verifier;
+  EXPECT_TRUE(Verifier.match("namespace a { class b {}; } void f(a::b) {}",
+ nestedNameSpecifierLoc(hasParent(typeLoc();
+}
+
 TEST(GetParents, ReturnsParentInsideTemplateInstantiations) {
   MatchVerifier DeclVerifier;
   EXPECT_TRUE(DeclVerifier.match(
Index: lib/ASTMatchers/ASTMatchFinder.cpp
===
--- lib/ASTMatchers/ASTMatchFinder.cpp
+++ lib/ASTMatchers/ASTMatchFinder.cpp
@@ -621,9 +621,6 @@
 if (Node.get() ==
 ActiveASTContext->getTranslationUnitDecl())
   return false;
-assert(Node.getMemoizationData() &&
-   "Invariant broken: only nodes that support memoization may be "
-   "used in the parent map.");
 
 MatchKey Key;
 Key.MatcherID = Matcher.getID();
@@ -867,7 +864,11 @@
 
 bool MatchASTVisitor::TraverseNestedNameSpecifierLoc(
 NestedNameSpecifierLoc NNS) {
+  if (!NNS)
+return true;
+
   match(NNS);
+
   // We only match the nested name specifier here (as opposed to traversing it)
   // because the traversal is already done in the parallel "Loc"-hierarchy.
   if (NNS.hasQualifier())
Index: lib/AST/ASTContext.cpp

Re: [PATCH] D14011: [AST] Re-add TypeLocs and NestedNameSpecifierLocs to the ParentMap.

2015-10-23 Thread Manuel Klimek via cfe-commits

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

lg; let's see whether it sticks this time :)



Comment at: include/clang/AST/ASTContext.h:456
@@ -455,1 +455,3 @@
+  /// pointer identity only, which are more common and we can save space by
+  /// only storing an unique pointer to them.
   typedef llvm::DenseMaphttp://reviews.llvm.org/D14011



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

[libcxx] r251131 - Set LC_COLLATE rather than LANG to override collation.

r251101 - [AST] Re-add TypeLocs and NestedNameSpecifierLocs to the ParentMap.

Re: [PATCH] D14011: [AST] Re-add TypeLocs and NestedNameSpecifierLocs to the ParentMap.

Re: [PATCH] D13973: CFG: Delay creating Dtors for CompoundStmts which end in ReturnStmt

Re: [PATCH] D13336: [MSVC] 'property' with an empty array in array subscript expression.

r251110 - [AST] Plug a memory leak when promoting a single ParentMap entry to a vector.

[PATCH] D14014: Checker of proper vfork usage

Re: [PATCH] D12906: [RFC] Bug identification("issue_hash") change for CmpRuns.py

[clang-tools-extra] r251103 - Make isExpensiveToCopy() tri-state.

r251116 - Remove a redundant check. NFC

r251120 - Module Debugging: Emit module debug info for types inside of Objective-C

r251124 - [ARM] Renaming +t2dsp feature into +dsp, as discussed on llvm-dev

r251126 - Fixup this testcase after r251120.

Re: [PATCH] D12614: [OpenMP] Offloading descriptor registration and device codegen.

Re: [PATCH] D13978: [X86] Support MCU psABI when marking inregs

Re: [PATCH] D14014: Checker of proper vfork usage

Re: [PATCH] D7639: Add readability-redundant-void-arg check to clang-tidy

Re: [PATCH] D7639: Add readability-redundant-void-arg check to clang-tidy

RE: [libcxx] r251065 - Dont required CMake 3 to install a linker script

Re: [libcxx] r251065 - Dont required CMake 3 to install a linker script

[libcxx] r251100 - Use proper output directory when naminging the libc++ output

RE: [libcxx] r251065 - Dont required CMake 3 to install a linker script

Re: [PATCH] D14014: Checker of proper vfork usage

Re: [PATCH] D14014: Checker of proper vfork usage

Re: [PATCH] D13144: [CUDA] propagate to CUDA sub-compilations target triple of opposite side.

Re: [PATCH] D14014: Checker of proper vfork usage

Re: [PATCH] D14014: Checker of proper vfork usage

Re: [PATCH] D14014: Checker of proper vfork usage

[PATCH] D14030: Use linker option to reference profile runtime hook (Linux)

[PATCH] D14011: [AST] Re-add TypeLocs and NestedNameSpecifierLocs to the ParentMap.

Re: [PATCH] D14011: [AST] Re-add TypeLocs and NestedNameSpecifierLocs to the ParentMap.

31 matches

Site Navigation

Mail list logo

Footer information