[PATCH] D39451: P0620 follow-up: deducing `auto` from braced-init-list in new expr

2017-10-31 Thread Zhihao Yuan via Phabricator via cfe-commits
lichray created this revision.

This is a side-effect brought in by p0620r0, which allows other placeholder 
types (derived from `auto` and `decltype(auto)`) to be usable in a `new` 
expression with a single-clause //braced-init-list// as its initializer (8.3.4 
[expr.new]/2).  N3922 defined its semantics.

References:
 http://wg21.link/p0620r0
 http://wg21.link/n3922


https://reviews.llvm.org/D39451

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Sema/SemaExprCXX.cpp
  test/CXX/expr/expr.unary/expr.new/p2-cxx0x.cpp
  test/SemaCXX/cxx0x-initializer-stdinitializerlist.cpp


Index: test/SemaCXX/cxx0x-initializer-stdinitializerlist.cpp
===
--- test/SemaCXX/cxx0x-initializer-stdinitializerlist.cpp
+++ test/SemaCXX/cxx0x-initializer-stdinitializerlist.cpp
@@ -148,7 +148,7 @@
 }
 
 void dangle() {
-  new auto{1, 2, 3}; // expected-error {{cannot use list-initialization}}
+  new auto{1, 2, 3}; // expected-error {{new expression for type 'auto' 
contains multiple constructor arguments}}
   new std::initializer_list{1, 2, 3}; // expected-warning {{at the end of 
the full-expression}}
 }
 
Index: test/CXX/expr/expr.unary/expr.new/p2-cxx0x.cpp
===
--- test/CXX/expr/expr.unary/expr.new/p2-cxx0x.cpp
+++ test/CXX/expr/expr.unary/expr.new/p2-cxx0x.cpp
@@ -9,12 +9,14 @@
 void f() {
   only p = new const auto (0);
   only q = new (auto) (0.0);
+  only r = new auto {'a'};
 
   new auto; // expected-error{{new expression for type 'auto' requires a 
constructor argument}}
   new (const auto)(); // expected-error{{new expression for type 'const auto' 
requires a constructor argument}}
   new (auto) (1,2,3); // expected-error{{new expression for type 'auto' 
contains multiple constructor arguments}}
-  new auto {1,2,3}; // expected-error{{new expression for type 'auto' cannot 
use list-initialization}}
-  new auto ({1,2,3}); // expected-error{{new expression for type 'auto' cannot 
use list-initialization}}
+  new auto {}; // expected-error{{new expression for type 'auto' requires a 
constructor argument}}
+  new auto {1,2,3}; // expected-error{{new expression for type 'auto' contains 
multiple constructor arguments}}
+  new auto ({1,2,3}); // expected-error{{new expression for type 'auto' 
contains multiple constructor arguments}}
 }
 
 void p2example() {
Index: lib/Sema/SemaExprCXX.cpp
===
--- lib/Sema/SemaExprCXX.cpp
+++ lib/Sema/SemaExprCXX.cpp
@@ -1748,14 +1748,16 @@
 if (AllocType.isNull())
   return ExprError();
   } else if (Deduced) {
+if (NumInits == 1) {
+  if (auto p = dyn_cast_or_null(Inits[0])) {
+Inits = p->getInits();
+NumInits = p->getNumInits();
+  }
+}
+
 if (initStyle == CXXNewExpr::NoInit || NumInits == 0)
   return ExprError(Diag(StartLoc, diag::err_auto_new_requires_ctor_arg)
<< AllocType << TypeRange);
-if (initStyle == CXXNewExpr::ListInit ||
-(NumInits == 1 && isa(Inits[0])))
-  return ExprError(Diag(Inits[0]->getLocStart(),
-diag::err_auto_new_list_init)
-   << AllocType << TypeRange);
 if (NumInits > 1) {
   Expr *FirstBad = Inits[1];
   return ExprError(Diag(FirstBad->getLocStart(),
Index: include/clang/Basic/DiagnosticSemaKinds.td
===
--- include/clang/Basic/DiagnosticSemaKinds.td
+++ include/clang/Basic/DiagnosticSemaKinds.td
@@ -1981,8 +1981,6 @@
   "declaration of variable %0 with deduced type %1 requires an initializer">;
 def err_auto_new_requires_ctor_arg : Error<
   "new expression for type %0 requires a constructor argument">;
-def err_auto_new_list_init : Error<
-  "new expression for type %0 cannot use list-initialization">;
 def err_auto_var_init_no_expression : Error<
   "initializer for variable %0 with type %1 is empty">;
 def err_auto_var_init_multiple_expressions : Error<


Index: test/SemaCXX/cxx0x-initializer-stdinitializerlist.cpp
===
--- test/SemaCXX/cxx0x-initializer-stdinitializerlist.cpp
+++ test/SemaCXX/cxx0x-initializer-stdinitializerlist.cpp
@@ -148,7 +148,7 @@
 }
 
 void dangle() {
-  new auto{1, 2, 3}; // expected-error {{cannot use list-initialization}}
+  new auto{1, 2, 3}; // expected-error {{new expression for type 'auto' contains multiple constructor arguments}}
   new std::initializer_list{1, 2, 3}; // expected-warning {{at the end of the full-expression}}
 }
 
Index: test/CXX/expr/expr.unary/expr.new/p2-cxx0x.cpp
===
--- test/CXX/expr/expr.unary/expr.new/p2-cxx0x.cpp
+++ test/CXX/expr/expr.unary/expr.new/p2-cxx0x.cpp
@@ -9,12 +9,14 @@
 void f() {
   only p = new const auto (0);
   only q = new (auto) (0.0);
+  only r = new auto {'

[PATCH] D32642: [Analyzer] Iterator Checker - Part 2: Increment, decrement operators and ahead-of-begin checks

2017-10-31 Thread Balogh , Ádám via Phabricator via cfe-commits
baloghadamsoftware added a comment.

It seems that review on https://reviews.llvm.org/D35109 is stuck forever. So 
maybe we should forget about this simplification and return to the local 
solution I tried to use here originally. It is Part2, and we need to go through 
all parts as soon as possible. In the meanwhile I also tested the whole 
iterator solution on the whole Clang project and got rid of many false 
positives. So the checker itself is very promissing.


https://reviews.llvm.org/D32642



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


[PATCH] D35109: [Analyzer] SValBuilder Comparison Rearrangement

2017-10-31 Thread Balogh , Ádám via Phabricator via cfe-commits
baloghadamsoftware added inline comments.



Comment at: lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp:595
+
+  if (origWidth < 128) {
+auto newWidth = std::max(2 * origWidth, (uint32_t) 8);

danielmarjamaki wrote:
> I would like that "128" is rewritten somehow. Using expression instead.
Do you have an exact suggestion here? `int128` is the widest integer type which 
I cannot multiply by `2` because there is not `256` bit wide integer type. 
Maybe I should take the size of `int128`? Is it any better than just typing 
`128`?



Comment at: lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp:596
+  if (origWidth < 128) {
+auto newWidth = std::max(2 * origWidth, (uint32_t) 8);
+auto newAPSIntType = APSIntType(newWidth, false);

danielmarjamaki wrote:
> Is `origWidth < 4` possible?
> 
> I wonder about "8". Is that CHAR_BIT hardcoded?
Width of `bool` is 1. There is no integer type for bit-width of `2` so I had to 
round it up to 8.


https://reviews.llvm.org/D35109



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


[PATCH] D35109: [Analyzer] SValBuilder Comparison Rearrangement

2017-10-31 Thread Balogh , Ádám via Phabricator via cfe-commits
baloghadamsoftware added a comment.

Any progress reviewing this? Iterator checkers are pending for more than half a 
year because of this.

An alternative solution is to always extend the type and change 
`ProgramState::assumeInbound()` so it does not move everything to the bottom of 
the range, but maybe to the middle.


https://reviews.llvm.org/D35109



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


[PATCH] D39428: [Analyzer] As suggested, use value storage for BodyFarm

2017-10-31 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun accepted this revision.
xazax.hun added a comment.

Some minor nits otherwise LGTM!




Comment at: include/clang/Analysis/AnalysisDeclContext.h:479
+  /// Get a reference to {@code BodyFarm} instance.
+  BodyFarm& getBodyFarm();
 

The reference is on the wrong side. 



Comment at: include/clang/Analysis/BodyFarm.h:43
+  /// Remove copy constructor to avoid accidental copying.
+  BodyFarm(const BodyFarm& other) = delete;
+

Reference is on the wrong side.



Comment at: lib/Analysis/AnalysisDeclContext.cpp:308
 
-BodyFarm *AnalysisDeclContextManager::getBodyFarm() {
-  if (!FunctionBodyFarm)
-FunctionBodyFarm = llvm::make_unique(ASTCtx, Injector.get());
-  return FunctionBodyFarm.get();
+BodyFarm& AnalysisDeclContextManager::getBodyFarm() {
+  return FunctionBodyFarm;

Same as above.


https://reviews.llvm.org/D39428



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


[PATCH] D38844: [analyzer] Make issue hash related tests more concise

2017-10-31 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun added inline comments.



Comment at: lib/StaticAnalyzer/Checkers/ExprInspectionChecker.cpp:68
   // (globals should not be invalidated, etc), hence the use of evalCall.
-  FnCheck Handler = llvm::StringSwitch(C.getCalleeName(CE))
-.Case("clang_analyzer_eval", &ExprInspectionChecker::analyzerEval)
-.Case("clang_analyzer_checkInlined",
-  &ExprInspectionChecker::analyzerCheckInlined)
-.Case("clang_analyzer_crash", &ExprInspectionChecker::analyzerCrash)
-.Case("clang_analyzer_warnIfReached",
-  &ExprInspectionChecker::analyzerWarnIfReached)
-.Case("clang_analyzer_warnOnDeadSymbol",
-  &ExprInspectionChecker::analyzerWarnOnDeadSymbol)
-.StartsWith("clang_analyzer_explain", 
&ExprInspectionChecker::analyzerExplain)
-.StartsWith("clang_analyzer_dump", &ExprInspectionChecker::analyzerDump)
-.Case("clang_analyzer_getExtent", 
&ExprInspectionChecker::analyzerGetExtent)
-.Case("clang_analyzer_printState",
-  &ExprInspectionChecker::analyzerPrintState)
-.Case("clang_analyzer_numTimesReached",
-  &ExprInspectionChecker::analyzerNumTimesReached)
-.Default(nullptr);
+  FnCheck Handler =
+  llvm::StringSwitch(C.getCalleeName(CE))

zaks.anna wrote:
> xazax.hun wrote:
> > zaks.anna wrote:
> > > Unrelated change?
> > Since I touched this snippet I reformatted it using clang-format. Apart 
> > from adding a new case before the default all other changes are formatting 
> > changes. I will revert the formatting changes. So in general, we prefer to 
> > minimize the diffs over converging to be clang-formatted?
> It's much easier to review when the diff does not contain formatting changes 
> intermixed with functional changes. Looks like you can configure clang-format 
> to only format the diff.
I see. Unfortunately, formatting only the diff is not always a solution. The 
clang-format tool cannot format arbitrary source regions, it will extend the 
formatted region to certain units of the language, in this case to the whole 
variable definition which spans across multiple lines. Fortunately, it wasn't a 
big deal to do formatting by hand in this case. 


Repository:
  rL LLVM

https://reviews.llvm.org/D38844



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


[PATCH] D39422: [analyzer] pr34779: CStringChecker: Don't get crashed by non-standard standard library function definitions.

2017-10-31 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun added inline comments.



Comment at: test/Analysis/string-with-signedness.c:1
+// RUN: %clang_analyze_cc1 -Wno-incompatible-library-redeclaration 
-analyzer-checker=core,unix.cstring,alpha.unix.cstring -verify %s
+

NoQ wrote:
> We do have a warning for this.
Oh, so we already have a warning for this. Good :)


https://reviews.llvm.org/D39422



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


[PATCH] D22374: [analyzer] Copy and move constructors - ExprEngine extended for "almost trivial" copy and move constructors

2017-10-31 Thread Balogh , Ádám via Phabricator via cfe-commits
baloghadamsoftware updated this revision to Diff 120954.
baloghadamsoftware added a comment.
Herald added subscribers: szepet, whisperity.

Tests updated.


https://reviews.llvm.org/D22374

Files:
  lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
  test/Analysis/ctor.mm

Index: test/Analysis/ctor.mm
===
--- test/Analysis/ctor.mm
+++ test/Analysis/ctor.mm
@@ -146,10 +146,12 @@
 NonPOD(const NonPOD &Other)
   : x(Other.x), y(Other.y) // expected-warning {{undefined}}
 {
+  int z = 1;
 }
 NonPOD(NonPOD &&Other)
 : x(Other.x), y(Other.y) // expected-warning {{undefined}}
 {
+  int z = 1;
 }
 
 NonPOD &operator=(const NonPOD &Other)
@@ -176,10 +178,12 @@
   Inner(const Inner &Other)
 : x(Other.x), y(Other.y) // expected-warning {{undefined}}
   {
+int z = 1;
   }
   Inner(Inner &&Other)
   : x(Other.x), y(Other.y) // expected-warning {{undefined}}
   {
+int z = 1;
   }
 
   Inner &operator=(const Inner &Other)
@@ -199,6 +203,19 @@
 Inner p;
   };
 
+  class AlmostPOD {
+  public:
+int x, y;
+
+AlmostPOD() {}
+AlmostPOD(const AlmostPOD &Other)
+  : x(Other.x), y(Other.y) // no-warning
+{}
+AlmostPOD(AlmostPOD &&Other)
+: x(Other.x), y(Other.y) // no-warning
+{}
+  };
+
   void testPOD(const POD &pp) {
 POD p;
 p.x = 1;
@@ -254,6 +271,31 @@
 NonPODWrapper w2 = move(w);
   }
 
+  void testAlmostPOD() {
+AlmostPOD p;
+p.x = 1;
+AlmostPOD p2 = p; // no-warning
+clang_analyzer_eval(p2.x == 1); // expected-warning{{TRUE}}
+  }
+
+  void testAlmostPODMove() {
+AlmostPOD p;
+p.x = 1;
+AlmostPOD p2 = move(p); // no-warning
+clang_analyzer_eval(p2.x == 1); // expected-warning{{TRUE}}
+  }
+
+  // FIXME: These copies are now handled with a single per-structure bind,
+  // and the undefined assignment checker fails to realize that
+  // all contents of the structure that's being copied are undefined.
+  // Perhaps we could teach the checker to warn here.
+  void testCompletelyUndefined() {
+POD p;
+POD p2 = p; // no-warning
+AlmostPOD ap;
+AlmostPOD ap2 = ap; // no-warning
+  }
+
   // Not strictly about constructors, but trivial assignment operators should
   // essentially work the same way.
   namespace AssignmentOperator {
Index: lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
===
--- lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
+++ lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
@@ -19,6 +19,8 @@
 #include "clang/StaticAnalyzer/Core/PathSensitive/AnalysisManager.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h"
 
+#include "llvm/ADT/SmallPtrSet.h"
+
 using namespace clang;
 using namespace ento;
 
@@ -34,19 +36,136 @@
   Bldr.generateNode(ME, Pred, state);
 }
 
+static bool isCopyOrMoveLike(const CXXConstructorDecl *Constr) {
+  if (Constr->isCopyOrMoveConstructor())
+return true;
+
+  if (Constr->getNumParams() != 1)
+return false;
+
+  const auto ParamType =
+  Constr->getParamDecl(0)->getType()->getUnqualifiedDesugaredType();
+  if (!ParamType->isReferenceType())
+return false;
+
+  const auto ParamPointeeType =
+  ParamType->getAs()->getPointeeType();
+  if (!ParamPointeeType->isRecordType())
+return false;
+
+  const auto *ParamRecDecl = ParamPointeeType->getAs()->getDecl();
+  const auto *ThisRecDecl = Constr->getParent();
+
+  if (ParamRecDecl != ThisRecDecl)
+return false;
+
+  return true;
+}
+
+static bool isAlmostTrivialConstructor(const CXXMethodDecl *Met) {
+  if (Met->isTrivial())
+return true;
+
+  if (!Met->hasTrivialBody()) // Returns false if body is not available
+return false;
+
+  if (Met->getNumParams() != 1)
+return false;
+
+  const auto *Param = Met->getParamDecl(0);
+  const auto *ThisRecDecl = Met->getParent();
+
+  const auto *Constr = dyn_cast(Met);
+  if (!Constr)
+return false;
+
+  if (ThisRecDecl->getNumVBases() > 0)
+return false;
+
+  llvm::SmallPtrSet InitBaseSet;
+  llvm::SmallPtrSet InitFieldSet;
+
+  for (const auto *Initzer : Constr->inits()) {
+if (Initzer->isBaseInitializer()) {
+  const auto *Base = Initzer->getBaseClass();
+  if (const auto *CtrCall = dyn_cast(
+  Initzer->getInit()->IgnoreParenImpCasts())) {
+if (!isCopyOrMoveLike(CtrCall->getConstructor()) ||
+!isAlmostTrivialConstructor(CtrCall->getConstructor()))
+  return false;
+if (const auto *Init = dyn_cast(
+CtrCall->getArg(0)->IgnoreParenImpCasts())) {
+  if (Init->getDecl() != Param)
+return false;
+} else {
+  return false;
+}
+  } else {
+return false;
+  }
+  InitBaseSet.insert(Base);
+} else if (Initzer->isMemberInitializer()) {
+  const auto *Field = Initzer->getMember();
+  const MemberExpr *InitMe

[PATCH] D39438: [analyzer] Diagnose stack leaks via block captures

2017-10-31 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun added inline comments.



Comment at: lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp:145
+  if (dyn_cast_or_null(Region->getMemorySpace())) {
+ExplodedNode *N = C.generateErrorNode();
+if (!N)

This will stop the analysis on this execution path. Is this desired? Usually, 
we stop the execution when there is no way to model the program state after the 
error, e.g.: after a division by zero. In this case the stack address escaped 
but it wasn't dereferenced (yet), so I think it might be safe to continue the 
analysis on this path.  What do you think?



Comment at: lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp:156
+   "asynchronously";
+auto report =
+llvm::make_unique(*BT_capturestackleak, Out.str(), N);

The variable should start with an uppercase letter.


Repository:
  rL LLVM

https://reviews.llvm.org/D39438



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


[PATCH] D39452: [LibCrossTU] Adding code ownership

2017-10-31 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun created this revision.

In order to reduce the load on the other code owners, I would like to step up 
as an owner of the new library.


https://reviews.llvm.org/D39452

Files:
  CODE_OWNERS.TXT


Index: CODE_OWNERS.TXT
===
--- CODE_OWNERS.TXT
+++ CODE_OWNERS.TXT
@@ -56,3 +56,7 @@
 N: Anastasia Stulova
 E: anastasia.stul...@arm.com
 D: OpenCL support
+
+N: Gábor Horváth
+E: xazax@gmail.com
+D: LibCrossTU


Index: CODE_OWNERS.TXT
===
--- CODE_OWNERS.TXT
+++ CODE_OWNERS.TXT
@@ -56,3 +56,7 @@
 N: Anastasia Stulova
 E: anastasia.stul...@arm.com
 D: OpenCL support
+
+N: Gábor Horváth
+E: xazax@gmail.com
+D: LibCrossTU
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D30946: [ScopePrinting] Added support to print full scopes of types and declarations.

2017-10-31 Thread Simon Schroeder via Phabricator via cfe-commits
schroedersi added a comment.

Ping


https://reviews.llvm.org/D30946



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


r316988 - [CodeGen] Propagate may-alias'ness of lvalues with TBAA info

2017-10-31 Thread Ivan A. Kosarev via cfe-commits
Author: kosarev
Date: Tue Oct 31 04:05:34 2017
New Revision: 316988

URL: http://llvm.org/viewvc/llvm-project?rev=316988&view=rev
Log:
[CodeGen] Propagate may-alias'ness of lvalues with TBAA info

This patch fixes various places in clang to propagate may-alias
TBAA access descriptors during construction of lvalues, thus
eliminating the need for the LValueBaseInfo::MayAlias flag.

This is part of D38126 reworked to be a separate patch to
simplify review.

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

Modified:
cfe/trunk/lib/CodeGen/CGExpr.cpp
cfe/trunk/lib/CodeGen/CGObjCRuntime.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
cfe/trunk/lib/CodeGen/CGValue.h
cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.h
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.h
cfe/trunk/lib/CodeGen/CodeGenTBAA.cpp
cfe/trunk/lib/CodeGen/CodeGenTBAA.h

Modified: cfe/trunk/lib/CodeGen/CGExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExpr.cpp?rev=316988&r1=316987&r2=316988&view=diff
==
--- cfe/trunk/lib/CodeGen/CGExpr.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGExpr.cpp Tue Oct 31 04:05:34 2017
@@ -1538,8 +1538,6 @@ llvm::Value *CodeGenFunction::EmitLoadOf
 Load->setMetadata(CGM.getModule().getMDKindID("nontemporal"), Node);
   }
 
-  if (BaseInfo.getMayAlias())
-TBAAInfo = CGM.getTBAAMayAliasAccessInfo();
   CGM.DecorateInstructionWithTBAA(Load, TBAAInfo);
 
   if (EmitScalarRangeCheck(Load, Ty, Loc)) {
@@ -1622,8 +1620,6 @@ void CodeGenFunction::EmitStoreOfScalar(
 Store->setMetadata(CGM.getModule().getMDKindID("nontemporal"), Node);
   }
 
-  if (BaseInfo.getMayAlias())
-TBAAInfo = CGM.getTBAAMayAliasAccessInfo();
   CGM.DecorateInstructionWithTBAA(Store, TBAAInfo);
 }
 
@@ -2170,10 +2166,7 @@ CodeGenFunction::EmitLoadOfReference(LVa
  TBAAAccessInfo *PointeeTBAAInfo) {
   llvm::LoadInst *Load = Builder.CreateLoad(RefLVal.getAddress(),
 RefLVal.isVolatile());
-  TBAAAccessInfo RefTBAAInfo = RefLVal.getTBAAInfo();
-  if (RefLVal.getBaseInfo().getMayAlias())
-RefTBAAInfo = CGM.getTBAAMayAliasAccessInfo();
-  CGM.DecorateInstructionWithTBAA(Load, RefTBAAInfo);
+  CGM.DecorateInstructionWithTBAA(Load, RefLVal.getTBAAInfo());
 
   CharUnits Align = 
getNaturalTypeAlignment(RefLVal.getType()->getPointeeType(),
 PointeeBaseInfo, PointeeTBAAInfo,
@@ -2356,11 +2349,10 @@ LValue CodeGenFunction::EmitDeclRefLValu
 LValue CapLVal =
 EmitCapturedFieldLValue(*this, CapturedStmtInfo->lookup(VD),
 CapturedStmtInfo->getContextValue());
-bool MayAlias = CapLVal.getBaseInfo().getMayAlias();
 return MakeAddrLValue(
 Address(CapLVal.getPointer(), getContext().getDeclAlign(VD)),
-CapLVal.getType(), LValueBaseInfo(AlignmentSource::Decl, MayAlias),
-CGM.getTBAAAccessInfo(CapLVal.getType()));
+CapLVal.getType(), LValueBaseInfo(AlignmentSource::Decl),
+CapLVal.getTBAAInfo());
   }
 
   assert(isa(CurCodeDecl));
@@ -2504,7 +2496,7 @@ LValue CodeGenFunction::EmitUnaryOpLValu
  ? emitAddrOfRealComponent(LV.getAddress(), LV.getType())
  : emitAddrOfImagComponent(LV.getAddress(), LV.getType()));
 LValue ElemLV = MakeAddrLValue(Component, T, LV.getBaseInfo(),
-   CGM.getTBAAAccessInfo(T));
+   CGM.getTBAAInfoForSubobject(LV, T));
 ElemLV.getQuals().addQualifiers(LV.getQuals());
 return ElemLV;
   }
@@ -3242,18 +3234,18 @@ LValue CodeGenFunction::EmitArraySubscri
 Addr = emitArraySubscriptGEP(*this, Addr, Idx, EltType, /*inbounds*/ true,
  SignedIndices, E->getExprLoc());
 return MakeAddrLValue(Addr, EltType, LV.getBaseInfo(),
-  CGM.getTBAAAccessInfo(EltType));
+  CGM.getTBAAInfoForSubobject(LV, EltType));
   }
 
-  LValueBaseInfo BaseInfo;
-  TBAAAccessInfo TBAAInfo;
+  LValueBaseInfo EltBaseInfo;
+  TBAAAccessInfo EltTBAAInfo;
   Address Addr = Address::invalid();
   if (const VariableArrayType *vla =
getContext().getAsVariableArrayType(E->getType())) {
 // The base must be a pointer, which is not an aggregate.  Emit
 // it.  It needs to be emitted first in case it's what captures
 // the VLA bounds.
-Addr = EmitPointerWithAlignment(E->getBase(), &BaseInfo, &TBAAInfo);
+Addr = EmitPointerWithAlignment(E->getBase(), &EltBaseInfo, &EltTBAAInfo);
 auto *Idx = EmitIdxAfterBase(/*Promote*/true);
 
 // The element count here is the total number of non-VLA elements.
@@ -3277,7 +3269,7 @@ LValue CodeGenFunction::EmitArraySubscri
 // Indexing over an interface, as

[PATCH] D39008: [CodeGen] Propagate may-alias'ness of lvalues with TBAA info

2017-10-31 Thread Ivan Kosarev via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL316988: [CodeGen] Propagate may-alias'ness of lvalues with 
TBAA info (authored by kosarev).

Changed prior to commit:
  https://reviews.llvm.org/D39008?vs=120828&id=120958#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D39008

Files:
  cfe/trunk/lib/CodeGen/CGExpr.cpp
  cfe/trunk/lib/CodeGen/CGObjCRuntime.cpp
  cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
  cfe/trunk/lib/CodeGen/CGValue.h
  cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
  cfe/trunk/lib/CodeGen/CodeGenFunction.h
  cfe/trunk/lib/CodeGen/CodeGenModule.cpp
  cfe/trunk/lib/CodeGen/CodeGenModule.h
  cfe/trunk/lib/CodeGen/CodeGenTBAA.cpp
  cfe/trunk/lib/CodeGen/CodeGenTBAA.h

Index: cfe/trunk/lib/CodeGen/CodeGenFunction.h
===
--- cfe/trunk/lib/CodeGen/CodeGenFunction.h
+++ cfe/trunk/lib/CodeGen/CodeGenFunction.h
@@ -1919,8 +1919,7 @@
 
   LValue MakeAddrLValue(Address Addr, QualType T,
 AlignmentSource Source = AlignmentSource::Type) {
-return LValue::MakeAddr(Addr, T, getContext(),
-LValueBaseInfo(Source, false),
+return LValue::MakeAddr(Addr, T, getContext(), LValueBaseInfo(Source),
 CGM.getTBAAAccessInfo(T));
   }
 
@@ -1932,8 +1931,7 @@
   LValue MakeAddrLValue(llvm::Value *V, QualType T, CharUnits Alignment,
 AlignmentSource Source = AlignmentSource::Type) {
 return LValue::MakeAddr(Address(V, Alignment), T, getContext(),
-LValueBaseInfo(Source, false),
-CGM.getTBAAAccessInfo(T));
+LValueBaseInfo(Source), CGM.getTBAAAccessInfo(T));
   }
 
   LValue MakeAddrLValue(llvm::Value *V, QualType T, CharUnits Alignment,
@@ -3092,8 +3090,7 @@
 SourceLocation Loc,
 AlignmentSource Source = AlignmentSource::Type,
 bool isNontemporal = false) {
-return EmitLoadOfScalar(Addr, Volatile, Ty, Loc,
-LValueBaseInfo(Source, false),
+return EmitLoadOfScalar(Addr, Volatile, Ty, Loc, LValueBaseInfo(Source),
 CGM.getTBAAAccessInfo(Ty), isNontemporal);
   }
 
@@ -3115,7 +3112,7 @@
  bool Volatile, QualType Ty,
  AlignmentSource Source = AlignmentSource::Type,
  bool isInit = false, bool isNontemporal = false) {
-EmitStoreOfScalar(Value, Addr, Volatile, Ty, LValueBaseInfo(Source, false),
+EmitStoreOfScalar(Value, Addr, Volatile, Ty, LValueBaseInfo(Source),
   CGM.getTBAAAccessInfo(Ty), isInit, isNontemporal);
   }
 
Index: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
===
--- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
+++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -993,7 +993,7 @@
   CGF.Builder.CreateElementBitCast(SharedLVal.getAddress(),
CGF.ConvertTypeForMem(SharedType)),
   SharedType, SharedAddresses[N].first.getBaseInfo(),
-  CGF.CGM.getTBAAAccessInfo(SharedType));
+  CGF.CGM.getTBAAInfoForSubobject(SharedAddresses[N].first, SharedType));
   if (CGF.getContext().getAsArrayType(PrivateVD->getType())) {
 emitAggregateInitialization(CGF, N, PrivateAddr, SharedLVal, DRD);
   } else if (DRD && (DRD->getInitializer() || !PrivateVD->hasInit())) {
@@ -1046,7 +1046,7 @@
   CGF.Builder.CreateElementBitCast(BaseLV.getAddress(),
CGF.ConvertTypeForMem(ElTy)),
   BaseLV.getType(), BaseLV.getBaseInfo(),
-  CGF.CGM.getTBAAAccessInfo(BaseLV.getType()));
+  CGF.CGM.getTBAAInfoForSubobject(BaseLV, BaseLV.getType()));
 }
 
 static Address castToBase(CodeGenFunction &CGF, QualType BaseTy, QualType ElTy,
@@ -4084,9 +4084,8 @@
 SharedRefLValue = CGF.MakeAddrLValue(
 Address(SharedRefLValue.getPointer(), C.getDeclAlign(OriginalVD)),
 SharedRefLValue.getType(),
-LValueBaseInfo(AlignmentSource::Decl,
-   SharedRefLValue.getBaseInfo().getMayAlias()),
-CGF.CGM.getTBAAAccessInfo(SharedRefLValue.getType()));
+LValueBaseInfo(AlignmentSource::Decl),
+SharedRefLValue.getTBAAInfo());
 QualType Type = OriginalVD->getType();
 if (Type->isArrayType()) {
   // Initialize firstprivate array.
Index: cfe/trunk/lib/CodeGen/CodeGenTBAA.cpp
===
--- cfe/trunk/lib/CodeGen/CodeGenTBAA.cpp
+++ cfe/trunk/lib/CodeGen/CodeGenTBAA.cpp
@@ -88,6 +88,25 @@
   return false;
 }
 
+/// Check if the given type is a valid base type to be used in access tags.
+static bool isValidBaseType(QualType QTy) {
+  if (QTy->isReferenceType())
+return false;
+

[libunwind] r316991 - Merge r311574: ARM: explicitly specify the 8-byte alignment

2017-10-31 Thread Renato Golin via cfe-commits
Author: rengolin
Date: Tue Oct 31 05:21:32 2017
New Revision: 316991

URL: http://llvm.org/viewvc/llvm-project?rev=316991&view=rev
Log:
Merge r311574: ARM: explicitly specify the 8-byte alignment

Fixing the last libunwind failure on ARM.



Modified:
libunwind/branches/release_50/include/unwind.h
libunwind/branches/release_50/test/alignment.pass.cpp

Modified: libunwind/branches/release_50/include/unwind.h
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/branches/release_50/include/unwind.h?rev=316991&r1=316990&r2=316991&view=diff
==
--- libunwind/branches/release_50/include/unwind.h (original)
+++ libunwind/branches/release_50/include/unwind.h Tue Oct 31 05:21:32 2017
@@ -100,7 +100,7 @@ struct _Unwind_Control_Block {
   } pr_cache;
 
   long long int :0; /* Enforce the 8-byte alignment */
-};
+} __attribute__((__aligned__(8)));
 
 typedef _Unwind_Reason_Code (*_Unwind_Stop_Fn)
   (_Unwind_State state,

Modified: libunwind/branches/release_50/test/alignment.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/branches/release_50/test/alignment.pass.cpp?rev=316991&r1=316990&r2=316991&view=diff
==
--- libunwind/branches/release_50/test/alignment.pass.cpp (original)
+++ libunwind/branches/release_50/test/alignment.pass.cpp Tue Oct 31 05:21:32 
2017
@@ -13,8 +13,16 @@
 
 #include 
 
-struct MaxAligned {} __attribute__((aligned));
-static_assert(alignof(_Unwind_Exception) == alignof(MaxAligned), "");
+// EHABI  : 8-byte aligned
+// itanium: largest supported alignment for the system
+#if defined(_LIBUNWIND_ARM_EHABI)
+static_assert(alignof(_Unwind_Control_Block) == 8,
+  "_Unwind_Control_Block must be double-word aligned");
+#else
+struct MaxAligned {} __attribute__((__aligned__));
+static_assert(alignof(_Unwind_Exception) == alignof(MaxAligned),
+  "_Unwind_Exception must be maximally aligned");
+#endif
 
 int main()
 {


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


[PATCH] D33620: [CodeGenCXX] do not default to dllimport storage for mingw-w64

2017-10-31 Thread Martin Storsjö via Phabricator via cfe-commits
mstorsjo added a comment.

After trying to build a bit more code with clang and a static libcxx, I agree 
with this change, so +1 from me. @compnerd ?


Repository:
  rL LLVM

https://reviews.llvm.org/D33620



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


[PATCH] D36101: Fix usage of right shift operator in fold expressions

2017-10-31 Thread Nicolas Lesser via Phabricator via cfe-commits
Rakete updated this revision to Diff 120966.
Rakete added a comment.

Used Parser's `GreaterThanIsOperator` just to be sure. :)


https://reviews.llvm.org/D36101

Files:
  include/clang/Parse/Parser.h
  lib/Parse/ParseExpr.cpp
  test/Parser/cxx1z-fold-expressions.cpp


Index: test/Parser/cxx1z-fold-expressions.cpp
===
--- test/Parser/cxx1z-fold-expressions.cpp
+++ test/Parser/cxx1z-fold-expressions.cpp
@@ -43,3 +43,8 @@
 (int)(undeclared_junk + ...) + // expected-error {{undeclared}}
 (int)(a + ...); // expected-error {{does not contain any unexpanded}}
 }
+
+// fold-operator can be '>' or '>>'.
+template bool greater_than() { return (N > ...); }
+template bool right_shift() { return (N >> ...); }
+
Index: lib/Parse/ParseExpr.cpp
===
--- lib/Parse/ParseExpr.cpp
+++ lib/Parse/ParseExpr.cpp
@@ -266,11 +266,12 @@
   return false;
 }
 
-static bool isFoldOperator(prec::Level Level) {
+bool Parser::isFoldOperator(prec::Level Level) const {
   return Level > prec::Unknown && Level != prec::Conditional;
 }
-static bool isFoldOperator(tok::TokenKind Kind) {
-  return isFoldOperator(getBinOpPrecedence(Kind, false, true));
+
+bool Parser::isFoldOperator(tok::TokenKind Kind) const {
+  return isFoldOperator(getBinOpPrecedence(Kind, GreaterThanIsOperator, true));
 }
 
 /// \brief Parse a binary expression that starts with \p LHS and has a
Index: include/clang/Parse/Parser.h
===
--- include/clang/Parse/Parser.h
+++ include/clang/Parse/Parser.h
@@ -506,6 +506,12 @@
Kind == tok::annot_module_end || Kind == tok::annot_module_include;
   }
 
+  /// \brief Checks if the \p Level is valid for use in a fold expression.
+  bool isFoldOperator(prec::Level Level) const;
+
+  /// \brief Checks if the \p Kind is a valid operator for fold expressions.
+  bool isFoldOperator(tok::TokenKind Kind) const;
+
   /// \brief Initialize all pragma handlers.
   void initializePragmaHandlers();
 


Index: test/Parser/cxx1z-fold-expressions.cpp
===
--- test/Parser/cxx1z-fold-expressions.cpp
+++ test/Parser/cxx1z-fold-expressions.cpp
@@ -43,3 +43,8 @@
 (int)(undeclared_junk + ...) + // expected-error {{undeclared}}
 (int)(a + ...); // expected-error {{does not contain any unexpanded}}
 }
+
+// fold-operator can be '>' or '>>'.
+template bool greater_than() { return (N > ...); }
+template bool right_shift() { return (N >> ...); }
+
Index: lib/Parse/ParseExpr.cpp
===
--- lib/Parse/ParseExpr.cpp
+++ lib/Parse/ParseExpr.cpp
@@ -266,11 +266,12 @@
   return false;
 }
 
-static bool isFoldOperator(prec::Level Level) {
+bool Parser::isFoldOperator(prec::Level Level) const {
   return Level > prec::Unknown && Level != prec::Conditional;
 }
-static bool isFoldOperator(tok::TokenKind Kind) {
-  return isFoldOperator(getBinOpPrecedence(Kind, false, true));
+
+bool Parser::isFoldOperator(tok::TokenKind Kind) const {
+  return isFoldOperator(getBinOpPrecedence(Kind, GreaterThanIsOperator, true));
 }
 
 /// \brief Parse a binary expression that starts with \p LHS and has a
Index: include/clang/Parse/Parser.h
===
--- include/clang/Parse/Parser.h
+++ include/clang/Parse/Parser.h
@@ -506,6 +506,12 @@
Kind == tok::annot_module_end || Kind == tok::annot_module_include;
   }
 
+  /// \brief Checks if the \p Level is valid for use in a fold expression.
+  bool isFoldOperator(prec::Level Level) const;
+
+  /// \brief Checks if the \p Kind is a valid operator for fold expressions.
+  bool isFoldOperator(tok::TokenKind Kind) const;
+
   /// \brief Initialize all pragma handlers.
   void initializePragmaHandlers();
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D39239: [AST] Incorrectly qualified unscoped enumeration as template actual parameter.

2017-10-31 Thread Carlos Alberto Enciso via Phabricator via cfe-commits
CarlosAlbertoEnciso added a comment.

Hi Tamas,

Thanks very much for your message.

In https://reviews.llvm.org/D39239#910797, @tberghammer wrote:

> - Can you do a diff of the debug_info dump before and after your change? 
> Understanding what have changed should give us a pretty good clue about the 
> issue.


For this specific case, the debug_info is the same before and after my change, 
as the patch affects only unscoped enums.

  DW_TAG_compile_unit "main.cpp"
DW_AT_producer "clang version 6.0.0 (trunk 316983)"
DW_AT_comp_dir 
"/home/carlos/llvm-root/llvm/tools/lldb/packages/Python/lldbsuite/test/lang/cpp/template"
...
DW_TAG_enumeration_type "EnumType"
  DW_AT_enum_class DW_FORM_flag_present
  DW_TAG_enumerator "Member"
  DW_TAG_enumerator "Subclass"
  ...
DW_TAG_class_type "EnumTemplate"
  ...
DW_TAG_class_type "EnumTemplate"
  ...

The DW_AT_name string for the templates are correctly generated, including the 
scoped information.

> - My first guess is that after your change we emit DW_TAG_enumeration_type 
> for scoped enums (what seems to be the correct thing to do) instead of 
> something else (not sure what) and you have to update 
> https://github.com/llvm-mirror/lldb/blob/master/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp#L1512
>  to handle it correctly.

Thanks for the link.

Looking at:
https://github.com/llvm-mirror/lldb/blob/master/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp#L1512

  const char *DWARFDebugInfoEntry::GetQualifiedName(
  SymbolFileDWARF *dwarf2Data, DWARFCompileUnit *cu,
  const DWARFAttributes &attributes, std::string &storage) const {
  
const char *name = GetName(dwarf2Data, cu);
...
return storage.c_str();
  }

The values for 'name' and 'storage' are correct and include the full qualified 
name: 'EnumTemplate'.

https://github.com/llvm-mirror/lldb/blob/master/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp#L926

During the processing of DW_TAG_enumeration_type, it seems that 
'DW_AT_enum_class' is not processed.

  DW_TAG_enumeration_type "EnumType"
...
DW_AT_enum_class DW_FORM_flag_present  
...
DW_TAG_enumerator "Member"
DW_TAG_enumerator "Subclass"

which at the end can have an impact on the name generated for the enumerators 
to be:

"EnumTemplate"

or

"EnumTemplate"

Thanks.


https://reviews.llvm.org/D39239



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


[PATCH] D36101: Fix usage of right shift operator in fold expressions

2017-10-31 Thread Nicolas Lesser via Phabricator via cfe-commits
Rakete updated this revision to Diff 120977.
Rakete added a comment.

Added some more tests.
If this patch is still ok can you please commit it @rsmith ? Thanks!


https://reviews.llvm.org/D36101

Files:
  include/clang/Parse/Parser.h
  lib/Parse/ParseExpr.cpp
  test/Parser/cxx1z-fold-expressions.cpp


Index: test/Parser/cxx1z-fold-expressions.cpp
===
--- test/Parser/cxx1z-fold-expressions.cpp
+++ test/Parser/cxx1z-fold-expressions.cpp
@@ -43,3 +43,20 @@
 (int)(undeclared_junk + ...) + // expected-error {{undeclared}}
 (int)(a + ...); // expected-error {{does not contain any unexpanded}}
 }
+
+// fold-operator can be '>' or '>>'.
+template  constexpr bool greaterThan() { return (N > ...); }
+template  constexpr int rightShift() { return (N >> ...); }
+
+static_assert(greaterThan<2, 1>());
+static_assert(rightShift<10, 1>() == 5);
+
+template  constexpr auto Identity = V;
+
+// Support fold operators within templates.
+template  constexpr int nestedFoldOperator() {
+  return Identity<(Identity<0> >> ... >> N)> +
+Identity<(N >> ... >> Identity<0>)>;
+}
+
+static_assert(nestedFoldOperator<3, 1>() == 1);
Index: lib/Parse/ParseExpr.cpp
===
--- lib/Parse/ParseExpr.cpp
+++ lib/Parse/ParseExpr.cpp
@@ -266,11 +266,12 @@
   return false;
 }
 
-static bool isFoldOperator(prec::Level Level) {
+bool Parser::isFoldOperator(prec::Level Level) const {
   return Level > prec::Unknown && Level != prec::Conditional;
 }
-static bool isFoldOperator(tok::TokenKind Kind) {
-  return isFoldOperator(getBinOpPrecedence(Kind, false, true));
+
+bool Parser::isFoldOperator(tok::TokenKind Kind) const {
+  return isFoldOperator(getBinOpPrecedence(Kind, GreaterThanIsOperator, true));
 }
 
 /// \brief Parse a binary expression that starts with \p LHS and has a
Index: include/clang/Parse/Parser.h
===
--- include/clang/Parse/Parser.h
+++ include/clang/Parse/Parser.h
@@ -506,6 +506,12 @@
Kind == tok::annot_module_end || Kind == tok::annot_module_include;
   }
 
+  /// \brief Checks if the \p Level is valid for use in a fold expression.
+  bool isFoldOperator(prec::Level Level) const;
+
+  /// \brief Checks if the \p Kind is a valid operator for fold expressions.
+  bool isFoldOperator(tok::TokenKind Kind) const;
+
   /// \brief Initialize all pragma handlers.
   void initializePragmaHandlers();
 


Index: test/Parser/cxx1z-fold-expressions.cpp
===
--- test/Parser/cxx1z-fold-expressions.cpp
+++ test/Parser/cxx1z-fold-expressions.cpp
@@ -43,3 +43,20 @@
 (int)(undeclared_junk + ...) + // expected-error {{undeclared}}
 (int)(a + ...); // expected-error {{does not contain any unexpanded}}
 }
+
+// fold-operator can be '>' or '>>'.
+template  constexpr bool greaterThan() { return (N > ...); }
+template  constexpr int rightShift() { return (N >> ...); }
+
+static_assert(greaterThan<2, 1>());
+static_assert(rightShift<10, 1>() == 5);
+
+template  constexpr auto Identity = V;
+
+// Support fold operators within templates.
+template  constexpr int nestedFoldOperator() {
+  return Identity<(Identity<0> >> ... >> N)> +
+Identity<(N >> ... >> Identity<0>)>;
+}
+
+static_assert(nestedFoldOperator<3, 1>() == 1);
Index: lib/Parse/ParseExpr.cpp
===
--- lib/Parse/ParseExpr.cpp
+++ lib/Parse/ParseExpr.cpp
@@ -266,11 +266,12 @@
   return false;
 }
 
-static bool isFoldOperator(prec::Level Level) {
+bool Parser::isFoldOperator(prec::Level Level) const {
   return Level > prec::Unknown && Level != prec::Conditional;
 }
-static bool isFoldOperator(tok::TokenKind Kind) {
-  return isFoldOperator(getBinOpPrecedence(Kind, false, true));
+
+bool Parser::isFoldOperator(tok::TokenKind Kind) const {
+  return isFoldOperator(getBinOpPrecedence(Kind, GreaterThanIsOperator, true));
 }
 
 /// \brief Parse a binary expression that starts with \p LHS and has a
Index: include/clang/Parse/Parser.h
===
--- include/clang/Parse/Parser.h
+++ include/clang/Parse/Parser.h
@@ -506,6 +506,12 @@
Kind == tok::annot_module_end || Kind == tok::annot_module_include;
   }
 
+  /// \brief Checks if the \p Level is valid for use in a fold expression.
+  bool isFoldOperator(prec::Level Level) const;
+
+  /// \brief Checks if the \p Kind is a valid operator for fold expressions.
+  bool isFoldOperator(tok::TokenKind Kind) const;
+
   /// \brief Initialize all pragma handlers.
   void initializePragmaHandlers();
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D37437: [analyzer] Fix some checker's output plist not containing the checker name

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

In https://reviews.llvm.org/D37437#909537, @zaks.anna wrote:

> Just to be clear, since this leads to regression to the checker API, I am 
> asking to look into other ways of solving this problem. For example, is there 
> a way to ensure that the checker names are set at construction?


Checkers are instantiated here: 
https://github.com/llvm-mirror/clang/blob/master/include/clang/StaticAnalyzer/Core/CheckerManager.h#L142
Checkers are created using the default constructor. After the constructor was 
run we set the name. If we want the checkers to be able to create the BugType 
with the correct name in the constructor (and not using mutable fields for the 
BugTypes), we need to add a new constructor parameter to CheckerBase and all 
the Checkers will need to forward a CheckerName to their base classes. So we 
need to break the API for every checkers basically. But if you prefer that 
solution I can rewrite this patch.


https://reviews.llvm.org/D37437



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


[PATCH] D39121: [clang-tidy] Misplaced Operator in Strlen in Alloc

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

In https://reviews.llvm.org/D39121#910802, @baloghadamsoftware wrote:

> I thought on something like this, but I still do not like my phrasing:
>
> "Addition operator is applied to the argument of strlen(). instead of its 
> result; move the '+ 1' outside of the call. (Or, if it is intentional then 
> surround the addition subexpression with parentheses to silence this 
> warning)."
>
> Any better ideas?


Unfortunately, that is way too long of a diagnostic. We don't have hard and 
fast rules about diagnostic lengths, but (a) we don't use complete sentences 
for diagnostics, and (b) I would guesstimate that we usually try to keep them 
80 characters or less (excluding expanded identifiers) and this one is 219 
characters long (not counting `strlen()`).

Once we have some concrete numbers about how often this diagnostic triggers 
(true and false positives), that may help us pick a better approach. For 
instance, if this doesn't trigger any diagnostics across several large code 
bases, we may decide to not have any fix-it and simply tell the user `addition 
operator is applied to the argument of 'strlen()' instead of its result`. It'd 
be unfortunate not to tell the user what to do about it, but since it likely 
doesn't come up in practice all that often we can point any confused users to 
the documentation. However, if the numbers show that this comes up frequently 
(with true or false positives), we may go a different route.


https://reviews.llvm.org/D39121



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


[PATCH] D38844: [analyzer] Make issue hash related tests more concise

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

Hey, i just recalled that we have documentation for `ExprInspection` functions 
in `docs/analyzer/DebugChecks.rst`, you may want to add your function there as 
well :)


Repository:
  rL LLVM

https://reviews.llvm.org/D38844



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


[PATCH] D39121: [clang-tidy] Misplaced Operator in Strlen in Alloc

2017-10-31 Thread Balogh , Ádám via Phabricator via cfe-commits
baloghadamsoftware added a comment.

Can you give me please an example where `malloc(strlen(s+1))` is intentional. 
It allocates `2` byte less than needed to store `s`. If it is really the goal 
(e.g. `s` has a `2` character prefix which we do not want to copy) then the 
correct solution is to use `malloc(strlen(s+2)+1)` instead of putting `s+1` 
into extra parentheses. So I think that we are overcomplicating things here. I 
would simply delete the suggestion about the extra parentheses from the error 
message and leave them only in the documentation, at least until no real 
example comes to my mind where taking the length of `s+1` and not adding `+1` 
is the fully correct solution. (Please note the `malloc(strlen(s+1)+1)` is 
already ignored.


https://reviews.llvm.org/D39121



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


[PATCH] D39416: [modules] Correctly overload getModule in the MultiplexExternalSemaSource

2017-10-31 Thread Vassil Vassilev via Phabricator via cfe-commits
v.g.vassilev accepted this revision.
v.g.vassilev added a comment.
This revision is now accepted and ready to land.

LGTM!


https://reviews.llvm.org/D39416



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


[PATCH] D39121: [clang-tidy] Misplaced Operator in Strlen in Alloc

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

In https://reviews.llvm.org/D39121#911736, @baloghadamsoftware wrote:

> Can you give me please an example where `malloc(strlen(s+1))` is intentional. 
> It allocates `2` byte less than needed to store `s`. If it is really the goal 
> (e.g. `s` has a `2` character prefix which we do not want to copy) then the 
> correct solution is to use `malloc(strlen(s+2)+1)` instead of putting `s+1` 
> into extra parentheses. So I think that we are overcomplicating things here. 
> I would simply delete the suggestion about the extra parentheses from the 
> error message and leave them only in the documentation, at least until no 
> real example comes to my mind where taking the length of `s+1` and not adding 
> `+1` is the fully correct solution. (Please note the `malloc(strlen(s+1)+1)` 
> is already ignored.


As I pointed out earlier in the thread, it is common to have 
double-null-terminated strings in Win32 APIs. This is a case where strlen(s + 
N) is valid. Since 1-byte strings would also be a valid value of N, strlen(s + 
1) is feasible, though unlikely. If you're okay dropping the fixit from your 
check and rewording the diagnostic to remove the "surround with parens" bit, I 
think the check would be fine. However, fix-its are generally only used when we 
know the transformation is correct. We have no way to know that in this case.


https://reviews.llvm.org/D39121



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


[PATCH] D39121: [clang-tidy] Misplaced Operator in Strlen in Alloc

2017-10-31 Thread Balogh , Ádám via Phabricator via cfe-commits
baloghadamsoftware added a comment.

In https://reviews.llvm.org/D39121#911741, @aaron.ballman wrote:

> As I pointed out earlier in the thread, it is common to have 
> double-null-terminated strings in Win32 APIs. This is a case where strlen(s + 
> N) is valid. Since 1-byte strings would also be a valid value of N, strlen(s 
> + 1) is feasible, though unlikely. If you're okay dropping the fixit from 
> your check and rewording the diagnostic to remove the "surround with parens" 
> bit, I think the check would be fine. However, fix-its are generally only 
> used when we know the transformation is correct. We have no way to know that 
> in this case.


Yes, you pointed it out, but even in the example you wrote a `+1` to the result 
as well. I a double-null terminated string in Win32 you must have at least 
1-byte strings, which are 2-bytes long together with their null terminator. So 
the minimum offset is 2, since 1 would mean 0-byte string, but then we have two 
null terminators after each other which is impossible since double null is the 
terminator of the whole list. So `s+1` cannot be valid. Furthermore, even if it 
would be valid, we must also allocate memory for the zero terminator of the 
string list item at the given offest, so we have an extra +1 outside of 
`strlen` as well.


https://reviews.llvm.org/D39121



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


[PATCH] D39121: [clang-tidy] Misplaced Operator in Strlen in Alloc

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

In https://reviews.llvm.org/D39121#911744, @baloghadamsoftware wrote:

> In https://reviews.llvm.org/D39121#911741, @aaron.ballman wrote:
>
> > As I pointed out earlier in the thread, it is common to have 
> > double-null-terminated strings in Win32 APIs. This is a case where strlen(s 
> > + N) is valid. Since 1-byte strings would also be a valid value of N, 
> > strlen(s + 1) is feasible, though unlikely. If you're okay dropping the 
> > fixit from your check and rewording the diagnostic to remove the "surround 
> > with parens" bit, I think the check would be fine. However, fix-its are 
> > generally only used when we know the transformation is correct. We have no 
> > way to know that in this case.
>
>
> Yes, you pointed it out, but even in the example you wrote a `+1` to the 
> result as well. I a double-null terminated string in Win32 you must have at 
> least 1-byte strings, which are 2-bytes long together with their null 
> terminator. So the minimum offset is 2, since 1 would mean 0-byte string, but 
> then we have two null terminators after each other which is impossible since 
> double null is the terminator of the whole list. So `s+1` cannot be valid. 
> Furthermore, even if it would be valid, we must also allocate memory for the 
> zero terminator of the string list item at the given offest, so we have an 
> extra +1 outside of `strlen` as well.


Hmm, this is a good point -- I was thinking of the generic +N case with the 
original example, but with an explicit +1, you can't run into that situation 
with Win32 APIs. I will think on this a bit further and report back when I have 
a spare moment.


https://reviews.llvm.org/D39121



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


[PATCH] D39438: [analyzer] Diagnose stack leaks via block captures

2017-10-31 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added inline comments.



Comment at: lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp:128
+  !Call.isGlobalCFunction("dispatch_async") &&
+  !Call.isGlobalCFunction("dispatch_once"))
+return;

`dispatch_once` isn't really asynchronous; i think it's out of place here.

Also we model it in the body farm, so i guess any errors inside its block would 
be caught anyway.



Comment at: lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp:136-139
+BlockDataRegion::referenced_vars_iterator I =
+Block->referenced_vars_begin();
+BlockDataRegion::referenced_vars_iterator E = Block->referenced_vars_end();
+for (; I != E; ++I) {

If you like, feel free to add support for `for (const auto &Item: 
Block->referenced_vars())` loops into `BlockDataRegion` :)



Comment at: lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp:144
+return;
+  if (dyn_cast_or_null(Region->getMemorySpace())) {
+ExplodedNode *N = C.generateErrorNode();

`getMemorySpace()` is never null. Every region resides in a memory space.



Comment at: lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp:153
+llvm::raw_svector_ostream Out(Buf);
+genName(Out, Region, C.getASTContext());
+Out << " was captured by the block which will be executed "

Not sure - the rest of the checker's code seems to be making use of the 
returned `SourceRange` by adding to the report, do we need that here?



Comment at: test/Analysis/stack-async-leak.m:1
+// RUN: %clang_analyze_cc1 -triple x86_64-apple-darwin10 
-analyzer-checker=core -analyzer-store=region -fblocks -verify %s
+

We don't add `-analyzer-store=region` nowadays; i don't think it's useful 
(though it doesn't hurt).



Comment at: test/Analysis/stack-async-leak.m:60
+  void (^b)(void) = ^void(void) {
+*p = 1; 
+  };

You may enjoy adding an extra note piece (as in D24278) to the offending 
statement within the block. It might be helpful if it's not obvious which block 
is being executed or which pointer points to the leaking variable.

Also it might be a good idea to think about a visitor that would track the 
block pointer to highlight where it was initialized with a concrete block code.

Though probably it's not super useful because we're most likely staying within 
a single function with this checker.

By the way, do we warn (or want to warn) on returning a block from a function, 
when this block captures a local variable?


Repository:
  rL LLVM

https://reviews.llvm.org/D39438



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


[PATCH] D39438: [analyzer] Diagnose stack leaks via block captures

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

What i was trying to say is - Hey this check looks useful!~ Great idea.


Repository:
  rL LLVM

https://reviews.llvm.org/D39438



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


[PATCH] D39455: [CodeGen] Add initial support for union members in TBAA

2017-10-31 Thread Ivan Kosarev via Phabricator via cfe-commits
kosarev created this revision.
kosarev added a project: clang.

The basic idea behind this patch is that since in strict aliasing mode all 
accesses to union members require their outermost enclosing union objects to be 
specified explicitly, then for a couple given accesses to union members of the 
form

  p->a.b.c...
  q->x.y.z...

it is known they can only alias if both p and q point to the same union type 
and offset ranges of members ##a.b.c...## and ##x.y.z..## overlap. Note that 
the actual types of the members do not matter.

Specifically, in this patch we do the following:

- Make unions to be valid TBAA base access types. This enables generation of 
TBAA type descriptors for unions.
- Encode union types as structures with a single member of a special "union 
member" type. Currently we do not encode information about sizes of types, but 
conceptually such union members are considered to be of the size of the whole 
union.
- Encode accesses to direct and indirect union members, including member 
arrays, as accesses to these special members. All accesses to members of a 
union thus get the same offset, which is the offset of the union they are part 
of. This means the existing LLVM TBAA machinery is able to handle such accesses 
with no changes.

While this is already an improvement comparing to the current situation, that 
is, representing all union accesses as may-alias ones, there are further 
changes planned to complete the support for unions. One of them is storing 
information about access sizes so we can distinct accesses to non-overlapping 
union members, including accesses to different elements of member arrays. 
Another change is encoding type sizes in order to make it possible to compute 
offsets within constant-indexed array elements. These enhancements will be 
addressed with separate patches.


Repository:
  rL LLVM

https://reviews.llvm.org/D39455

Files:
  lib/CodeGen/CGExpr.cpp
  lib/CodeGen/CodeGenModule.h
  lib/CodeGen/CodeGenTBAA.cpp
  lib/CodeGen/CodeGenTBAA.h
  test/CodeGen/tbaa-union.cpp
  test/CodeGen/union-tbaa1.c

Index: test/CodeGen/union-tbaa1.c
===
--- test/CodeGen/union-tbaa1.c
+++ test/CodeGen/union-tbaa1.c
@@ -15,30 +15,32 @@
 // But no tbaa for the two stores:
 // CHECK: %uw[[UW1:[0-9]*]] = getelementptr
 // CHECK: store{{.*}}%uw[[UW1]]
-// CHECK: tbaa ![[OCPATH:[0-9]+]]
+// CHECK: tbaa [[TAG_vect32_union_member:![0-9]+]]
 // There will be a load after the store, and it will use tbaa. Make sure
 // the check-not above doesn't find it:
 // CHECK: load
   Tmp[*Index][0].uw = Arr[*Index][0] * Num;
 // CHECK: %uw[[UW2:[0-9]*]] = getelementptr
 // CHECK: store{{.*}}%uw[[UW2]]
-// CHECK: tbaa ![[OCPATH]]
+// CHECK: tbaa [[TAG_vect32_union_member]]
   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: tbaa ![[OCPATH]]
+// CHECK: tbaa [[TAG_vect32_union_member]]
 // CHECK: store
   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: tbaa ![[OCPATH]]
+// CHECK: tbaa [[TAG_vect32_union_member]]
 // CHECK: store
   Vec[1] = Tmp[*Index][1].uh[1];
   bar(Tmp);
 }
 
-// CHECK-DAG: ![[CHAR:[0-9]+]] = !{!"omnipotent char"
-// CHECK-DAG: ![[OCPATH]] = !{![[CHAR]], ![[CHAR]], i64 0}
+// CHECK-DAG: [[TAG_vect32_union_member]] = !{[[TYPE_vect32:!.*]], [[TYPE_union_member:!.*]], i64 0}
+// CHECK-DAG: [[TYPE_vect32]] = !{!"", [[TYPE_union_member]], i64 0}
+// CHECK-DAG: [[TYPE_union_member]] = !{!"union member", [[TYPE_char:!.*]], i64 0}
+// CHECK-DAG: [[TYPE_char]] = !{!"omnipotent char", {{.*}}}
Index: test/CodeGen/tbaa-union.cpp
===
--- test/CodeGen/tbaa-union.cpp
+++ test/CodeGen/tbaa-union.cpp
@@ -0,0 +1,74 @@
+// RUN: %clang_cc1 -triple x86_64-linux -O1 -disable-llvm-passes %s -emit-llvm -o - | FileCheck %s
+//
+// Check that we generate correct TBAA information for accesses to union
+// members.
+
+struct X {
+  int a, b;
+  int arr[3];
+  int c, d;
+};
+
+union U {
+  int i;
+  X x;
+  int j;
+};
+
+struct S {
+  U u, v;
+};
+
+int f1(U *p) {
+// CHECK-LABEL: _Z2f1P1U
+// CHECK: load i32, i32* {{.*}}, !tbaa [[TAG_U_j:!.*]]
+  return p->j;
+}
+
+int f2(S *p) {
+// CHECK-LABEL: _Z2f2P1S
+// CHECK: load i32, i32* {{.*}}, !tbaa [[TAG_S_u_i:!.*]]
+  return p->u.i;
+}
+
+int f3(S *p) {
+// CHECK-LABEL: _Z2f3P1S
+// CHECK: load i32, i32* {{.*}}, !tbaa [[TAG_S_v_j:!.*]]
+  return p->v.j;
+}
+
+int f4(S *p) {
+// CHECK-LABEL: _Z2f4P1S
+// CHECK: load i32, i32* {{.*}}, !tbaa [[TAG_S_u_x_b:!.*]]
+  return p->u.x.b;
+}
+
+int f5(S *p) {
+// CHECK-LABEL: _Z2f5P1S
+// CHECK: load i32, i32* {{.*}}, !tbaa [[TA

[PATCH] D39121: [clang-tidy] Misplaced Operator in Strlen in Alloc

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

In https://reviews.llvm.org/D39121#911745, @aaron.ballman wrote:

> Hmm, this is a good point -- I was thinking of the generic +N case with the 
> original example, but with an explicit +1, you can't run into that situation 
> with Win32 APIs. I will think on this a bit further and report back when I 
> have a spare moment.


I think I've convinced myself that because we're limiting this check to just +1 
and not +N, the current approach is fine. We should leave in the 
parens-to-silence behavior and the existing fixit to move the addition to the 
result, but we don't need to call it out in the diagnostic text (the 
documentation should be sufficient).

I would still appreciate verification that this doesn't have a high fp rate 
against some real world code bases just to be sure of my intuition.


https://reviews.llvm.org/D39121



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


[PATCH] D39438: [analyzer] Diagnose stack leaks via block captures

2017-10-31 Thread Alexander Shaposhnikov via Phabricator via cfe-commits
alexshap added inline comments.



Comment at: lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp:144
+return;
+  if (dyn_cast_or_null(Region->getMemorySpace())) {
+ExplodedNode *N = C.generateErrorNode();

NoQ wrote:
> `getMemorySpace()` is never null. Every region resides in a memory space.
i was looking at StackAddrEscapeChecker::checkPreStmt - should it be fixed 
there as well, or that one is different ?



Comment at: lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp:145
+  if (dyn_cast_or_null(Region->getMemorySpace())) {
+ExplodedNode *N = C.generateErrorNode();
+if (!N)

xazax.hun wrote:
> This will stop the analysis on this execution path. Is this desired? Usually, 
> we stop the execution when there is no way to model the program state after 
> the error, e.g.: after a division by zero. In this case the stack address 
> escaped but it wasn't dereferenced (yet), so I think it might be safe to 
> continue the analysis on this path.  What do you think?
I think you are right, would be better to make it non-fatal


Repository:
  rL LLVM

https://reviews.llvm.org/D39438



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


[PATCH] D39445: [clang-fuzzer] Fix incremental builds of the fuzzer

2017-10-31 Thread Matt Morehouse via Phabricator via cfe-commits
morehouse accepted this revision.
morehouse added a comment.
This revision is now accepted and ready to land.

LGTM.


https://reviews.llvm.org/D39445



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


[PATCH] D39446: [PGO] Detect more structural changes with the stable hash

2017-10-31 Thread Alex Lorenz via Phabricator via cfe-commits
arphaman added inline comments.



Comment at: lib/CodeGen/CodeGenPGO.cpp:186
+if (Hash.getHashVersion() != PGO_HASH_V1)
+  Type = getHashType(Hash.getHashVersion(), S);
+

Am I missing something or will this call always return the same type as before 
since the first `if` will weed out statements which have hash only in v2 (since 
`getHashType(PGO_HASH_V1, S)` will return `None` for the new statements)?


https://reviews.llvm.org/D39446



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


[PATCH] D39204: [CodeGen] __builtin_sqrt should map to the compiler's intrinsic sqrt function

2017-10-31 Thread Sanjay Patel via Phabricator via cfe-commits
spatel added a comment.

In https://reviews.llvm.org/D39204#911316, @efriedma wrote:

> > I was going to include the builtins too, but that exposes another bug 
> > (marked here with FIXME) - the builtins are all defined 'const'.
>
> Probably just need to change c->e in Builtins.def?


Yes - at least that made sqrt behave like I expected. So I think it's really 
just a question of what order and combination that we want to fix this in:

1. Just the sqrt libcalls in this patch.
2. Fix both sqrt libcalls and __builtin_sqrt in this patch.
3. Fix all libm libcalls and builtins simultaneously.


https://reviews.llvm.org/D39204



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


[PATCH] D39446: [PGO] Detect more structural changes with the stable hash

2017-10-31 Thread Bob Wilson via Phabricator via cfe-commits
bob.wilson added a comment.

I'm excited to see some progress on this, but since there is overhead to adding 
a new hashing scheme, I think we should do more before introducing a new 
scheme. One of the problems with the previous scheme is that is did not take 
into account nesting. Distinguishing an if-statement from an if-else statement 
is good but we also need to distinguish what code is inside the then-block, 
else-block, and the code afterward. As it stands, I believe the following are 
all hashed the same, even with this patch:

Loop after the if-else:

  if (condition1())
x = 1;
  else
x = 2;
  while (condition2()) body();

Loop in the else-block:

  if (condition1())
x = 1;
  else
while (condition2()) body();

Loop in the then-block:

  if (condition1()) {
while (condition2()) body();
  } else
x = 2

It would be good to fix that.


https://reviews.llvm.org/D39446



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


[PATCH] D39446: [PGO] Detect more structural changes with the stable hash

2017-10-31 Thread Vedant Kumar via Phabricator via cfe-commits
vsk planned changes to this revision.
vsk added a comment.

Apart from Alex's point, this patch is missing a compatibility test for v5 of 
the profile format, and is missing coverage for the new entries in `HashType`.




Comment at: lib/CodeGen/CodeGenPGO.cpp:186
+if (Hash.getHashVersion() != PGO_HASH_V1)
+  Type = getHashType(Hash.getHashVersion(), S);
+

arphaman wrote:
> Am I missing something or will this call always return the same type as 
> before since the first `if` will weed out statements which have hash only in 
> v2 (since `getHashType(PGO_HASH_V1, S)` will return `None` for the new 
> statements)?
You're right, I need to rethink this. At the moment, the hash only changes for 
IfStmts which have Else blocks.


https://reviews.llvm.org/D39446



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


[PATCH] D39457: [OPENMP] Current status of OpenMP support.

2017-10-31 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev created this revision.

Some info about supported features of OpenMP 4.5-5.0.


https://reviews.llvm.org/D39457

Files:
  docs/OpenMPSupport.rst
  docs/index.rst


Index: docs/index.rst
===
--- docs/index.rst
+++ docs/index.rst
@@ -39,6 +39,7 @@
SourceBasedCodeCoverage
Modules
MSVCCompatibility
+   OpenMPSupport
ThinLTO
CommandGuide/index
FAQ
Index: docs/OpenMPSupport.rst
===
--- /dev/null
+++ docs/OpenMPSupport.rst
@@ -0,0 +1,70 @@
+.. raw:: html
+
+  
+.none { background-color: #FF }
+.partial { background-color: #99 }
+.good { background-color: #CCFF99 }
+  
+
+.. role:: none
+.. role:: partial
+.. role:: good
+
+==
+OpenMP Support
+==
+
+Clang fully supports OpenMP 3.5 + some elements of OpenMP 4.5.
+The status of major OpenMP 4.5 features support in Clang.
+
+Standalone directives
+=
+
+* #pragma omp [for] simd: :good:`Complete`.
+
+* #pragma omp declare simd: :partial:`Partial`.  We support parsing/semantic
+  analysis + generation of special attributes for X86 target, but still
+  missing the LLVM pass for vectorization.
+
+* #pragma omp taskloop [simd]: :good:`Complete`.
+
+* #pragma omp target [enter|exit] data: :good:`Mostly complete`.  Some rework 
is
+  required for better stability.
+
+* #pragma omp target update: :good:`Mostly complete`.  Some rework is
+  required for better stability.
+
+* #pragma omp target: :partial:`Partial`.  No support for the `reduction`,
+  `nowait` and `depend` clauses.
+
+* #pragma omp declare target: :partial:`Partial`.  No full codegen support.
+
+* #pragma omp teams: :good:`Complete`.
+
+* #pragma omp distribute [simd]: :good:`Complete`.
+
+* #pragma omp distribute parallel for [simd]: :partial:`Partial`. No full 
codegen support.
+
+Combined directives
+===
+
+* #pragma omp parallel for simd: :good:`Complete`.
+
+* #pragma omp target parallel: :good:`Complete`.
+
+* #pragma omp target parallel for [simd]: :partial:`Partial`.  No full codegen 
support.
+
+* #pragma omp target simd: :partial:`Partial`.  No full codegen support.
+
+* #pragma omp target teams: :partial:`Partial`.  No full codegen support.
+
+* #pragma omp teams distribute [simd]: :partial:`Partial`.  No full codegen 
support.
+
+* #pragma omp target teams distribute [simd]: :partial:`Partial`.  No full 
codegen support.
+
+* #pragma omp teams distribute parallel for [simd]: :partial:`Partial`.  No 
full codegen support.
+
+* #pragma omp target teams distribute parallel for [simd]: :partial:`Partial`. 
 No full codegen support.
+
+Clang does not support any constructs/updates from upcoming OpenMP 5.0 except 
for `reduction`-based clauses in the `task`-based directives.
+


Index: docs/index.rst
===
--- docs/index.rst
+++ docs/index.rst
@@ -39,6 +39,7 @@
SourceBasedCodeCoverage
Modules
MSVCCompatibility
+   OpenMPSupport
ThinLTO
CommandGuide/index
FAQ
Index: docs/OpenMPSupport.rst
===
--- /dev/null
+++ docs/OpenMPSupport.rst
@@ -0,0 +1,70 @@
+.. raw:: html
+
+  
+.none { background-color: #FF }
+.partial { background-color: #99 }
+.good { background-color: #CCFF99 }
+  
+
+.. role:: none
+.. role:: partial
+.. role:: good
+
+==
+OpenMP Support
+==
+
+Clang fully supports OpenMP 3.5 + some elements of OpenMP 4.5.
+The status of major OpenMP 4.5 features support in Clang.
+
+Standalone directives
+=
+
+* #pragma omp [for] simd: :good:`Complete`.
+
+* #pragma omp declare simd: :partial:`Partial`.  We support parsing/semantic
+  analysis + generation of special attributes for X86 target, but still
+  missing the LLVM pass for vectorization.
+
+* #pragma omp taskloop [simd]: :good:`Complete`.
+
+* #pragma omp target [enter|exit] data: :good:`Mostly complete`.  Some rework is
+  required for better stability.
+
+* #pragma omp target update: :good:`Mostly complete`.  Some rework is
+  required for better stability.
+
+* #pragma omp target: :partial:`Partial`.  No support for the `reduction`,
+  `nowait` and `depend` clauses.
+
+* #pragma omp declare target: :partial:`Partial`.  No full codegen support.
+
+* #pragma omp teams: :good:`Complete`.
+
+* #pragma omp distribute [simd]: :good:`Complete`.
+
+* #pragma omp distribute parallel for [simd]: :partial:`Partial`. No full codegen support.
+
+Combined directives
+===
+
+* #pragma omp parallel for simd: :good:`Complete`.
+
+* #pragma omp target parallel: :good:`Complete`.
+
+* #pragma omp target parallel for [simd]: :partial:`Partial`.  No full codegen support.
+
+* #pragma omp target simd: :partial:`Partial`.  No full codegen support.
+
+* #pragma omp target teams: :partial:`Part

[PATCH] D35295: [docs] Add section 'Half-Precision Floating Point'

2017-10-31 Thread Sjoerd Meijer via Phabricator via cfe-commits
SjoerdMeijer updated this revision to Diff 121003.
SjoerdMeijer added a comment.

Addressed the comments about portability, and added a note that Float16 is 
available in both C and C++ mode.


https://reviews.llvm.org/D35295

Files:
  docs/LanguageExtensions.rst


Index: docs/LanguageExtensions.rst
===
--- docs/LanguageExtensions.rst
+++ docs/LanguageExtensions.rst
@@ -436,6 +436,48 @@
 
 See also :ref:`langext-__builtin_shufflevector`, 
:ref:`langext-__builtin_convertvector`.
 
+Half-Precision Floating Point
+=
+
+Clang supports two half-precision (16-bit) floating point types: ``__fp16`` and
+``_Float16``. ``__fp16`` is defined in the ARM C Language Extensions (`ACLE
+`_
+and ``_Float16`` in ISO/IEC TS 18661-3:2015.
+
+``__fp16`` is a storage and interchange format only. This means that values of
+``__fp16`` promote to (at least) float when used in arithmetic operations.
+There are two ``__fp16`` formats. Clang supports the IEEE 754-2008 format and
+not the ARM alternative format.
+
+ISO/IEC TS 18661-3:2015 defines C support for additional floating point types.
+``_FloatN`` is defined as a binary floating type, where the N suffix denotes
+the number of bits and is 16, 32, 64, or greater and equal to 128 and a
+multiple of 32. Clang supports ``_Float16``. The difference from ``__fp16`` is
+that arithmetic on ``_Float16`` is performed in half-precision, thus it is not
+a storage-only format. ``_Float16`` is available as a source language type in
+both C and C++ mode.
+
+It is recommended that portable code use the ``_Float16`` type because
+``__fp16`` is a ARM C-Language Extension (ACLE) and ``_Float16`` is defined by
+the C standards committee, which should help portability between entire
+architectures. Also, ``_Float16`` arithmetic and operations will directly map
+on half-precision instructions when they are available (e.g. Armv8.2-A),
+avoiding conversions to/from single-precision, and thus will result in more
+performant code. If half-precision instructions are unavailable, values will be
+promoted to single-precision, similar to the semantics of ``__fp16`` except
+that the results will be stored in single-precision.
+
+In an arithmetic operation where one operand is of ``__fp16`` type and the
+other is of ``_Float16`` type, the ``_Float16`` type is first converted to
+``__fp16`` type and then the operation is completed as if both operands were of
+``__fp16`` type.
+
+To define a ``_Float16`` literal, suffix ``f16`` can be appended to the 
compile-time
+constant declaration. There is no default argument promotion for ``_Float16``; 
this
+applies to the standard floating types only. As a consequence, for example, an
+explicit cast is required for printing a ``_Float16`` value (there is no string
+format specifier for ``_Float16``).
+
 Messages on ``deprecated`` and ``unavailable`` Attributes
 =
 


Index: docs/LanguageExtensions.rst
===
--- docs/LanguageExtensions.rst
+++ docs/LanguageExtensions.rst
@@ -436,6 +436,48 @@
 
 See also :ref:`langext-__builtin_shufflevector`, :ref:`langext-__builtin_convertvector`.
 
+Half-Precision Floating Point
+=
+
+Clang supports two half-precision (16-bit) floating point types: ``__fp16`` and
+``_Float16``. ``__fp16`` is defined in the ARM C Language Extensions (`ACLE
+`_
+and ``_Float16`` in ISO/IEC TS 18661-3:2015.
+
+``__fp16`` is a storage and interchange format only. This means that values of
+``__fp16`` promote to (at least) float when used in arithmetic operations.
+There are two ``__fp16`` formats. Clang supports the IEEE 754-2008 format and
+not the ARM alternative format.
+
+ISO/IEC TS 18661-3:2015 defines C support for additional floating point types.
+``_FloatN`` is defined as a binary floating type, where the N suffix denotes
+the number of bits and is 16, 32, 64, or greater and equal to 128 and a
+multiple of 32. Clang supports ``_Float16``. The difference from ``__fp16`` is
+that arithmetic on ``_Float16`` is performed in half-precision, thus it is not
+a storage-only format. ``_Float16`` is available as a source language type in
+both C and C++ mode.
+
+It is recommended that portable code use the ``_Float16`` type because
+``__fp16`` is a ARM C-Language Extension (ACLE) and ``_Float16`` is defined by
+the C standards committee, which should help portability between entire
+architectures. Also, ``_Float16`` arithmetic and operations will directly map
+on half-precision instructions when they are available (e.g. Armv8.2-A),
+avoiding conversions to/from single-precision, and thus will result in more
+performant code. If half-precision instructions are unava

[PATCH] D37808: [clang-tidy] Add new hicpp-multiway-paths-covered check for missing branches

2017-10-31 Thread Jonas Toth via Phabricator via cfe-commits
JonasToth updated this revision to Diff 121009.
JonasToth added a comment.

- improved docs and comments
- remove some newlines
- use ternary operator instead of smallvec


https://reviews.llvm.org/D37808

Files:
  clang-tidy/hicpp/CMakeLists.txt
  clang-tidy/hicpp/HICPPTidyModule.cpp
  clang-tidy/hicpp/MultiwayPathsCoveredCheck.cpp
  clang-tidy/hicpp/MultiwayPathsCoveredCheck.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/hicpp-multiway-paths-covered.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/hicpp-multiway-paths-covered-else.cpp
  test/clang-tidy/hicpp-multiway-paths-covered.cpp

Index: test/clang-tidy/hicpp-multiway-paths-covered.cpp
===
--- /dev/null
+++ test/clang-tidy/hicpp-multiway-paths-covered.cpp
@@ -0,0 +1,445 @@
+// RUN: %check_clang_tidy %s hicpp-multiway-paths-covered %t
+
+enum OS { Mac,
+  Windows,
+  Linux };
+
+struct Bitfields {
+  unsigned UInt : 3;
+  int SInt : 1;
+};
+
+int return_integer() { return 42; }
+
+void bad_switch(int i) {
+  switch (i) {
+// CHECK-MESSAGES: [[@LINE-1]]:3: warning: switch with only one case; use if statement
+  case 0:
+break;
+  }
+  // No default in this switch
+  switch (i) {
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: potential uncovered codepath; add a default case
+  case 0:
+break;
+  case 1:
+break;
+  case 2:
+break;
+  }
+
+  // degenerate, maybe even warning
+  switch (i) {
+// CHECK-MESSAGES: [[@LINE-1]]:3: warning: degenerated switch without labels
+  }
+
+  switch (int j = return_integer()) {
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: potential uncovered codepath; add a default case
+  case 0:
+  case 1:
+  case 2:
+break;
+  }
+
+  // Degenerated, only default case.
+  switch (i) {
+// CHECK-MESSAGES: [[@LINE-1]]:3: warning: degenerated switch with default label only
+  default:
+break;
+  }
+
+  // Degenerated, only one case label and default case -> Better as if-stmt.
+  switch (i) {
+// CHECK-MESSAGES: [[@LINE-1]]:3: warning: switch could be better written as if/else statement
+  case 0:
+break;
+  default:
+break;
+  }
+
+  unsigned long long BigNumber = 0;
+  switch (BigNumber) {
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: potential uncovered codepath; add a default case
+  case 0:
+  case 1:
+break;
+  }
+
+  const int &IntRef = i;
+  switch (IntRef) {
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: potential uncovered codepath; add a default case
+  case 0:
+  case 1:
+break;
+  }
+
+  char C = 'A';
+  switch (C) {
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: potential uncovered codepath; add a default case
+  case 'A':
+break;
+  case 'B':
+break;
+  }
+
+  Bitfields Bf;
+  // UInt has 3 bits size.
+  switch (Bf.UInt) {
+// CHECK-MESSAGES: [[@LINE-1]]:3: warning: potential uncovered codepath; add a default case
+  case 0:
+  case 1:
+break;
+  }
+  // All paths explicitly covered.
+  switch (Bf.UInt) {
+  case 0:
+  case 1:
+  case 2:
+  case 3:
+  case 4:
+  case 5:
+  case 6:
+  case 7:
+break;
+  }
+  // SInt has 1 bit size, so this is somewhat degenerated.
+  switch (Bf.SInt) {
+// CHECK-MESSAGES: [[@LINE-1]]:3: warning: switch with only one case; use if statement
+  case 0:
+break;
+  }
+  // All paths explicitly covered.
+  switch (Bf.SInt) {
+  case 0:
+  case 1:
+break;
+  }
+}
+
+void unproblematic_switch(unsigned char c) {
+  switch (c) {
+  case 0:
+  case 1:
+  case 2:
+  case 3:
+  case 4:
+  case 5:
+  case 6:
+  case 7:
+  case 8:
+  case 9:
+  case 10:
+  case 11:
+  case 12:
+  case 13:
+  case 14:
+  case 15:
+  case 16:
+  case 17:
+  case 18:
+  case 19:
+  case 20:
+  case 21:
+  case 22:
+  case 23:
+  case 24:
+  case 25:
+  case 26:
+  case 27:
+  case 28:
+  case 29:
+  case 30:
+  case 31:
+  case 32:
+  case 33:
+  case 34:
+  case 35:
+  case 36:
+  case 37:
+  case 38:
+  case 39:
+  case 40:
+  case 41:
+  case 42:
+  case 43:
+  case 44:
+  case 45:
+  case 46:
+  case 47:
+  case 48:
+  case 49:
+  case 50:
+  case 51:
+  case 52:
+  case 53:
+  case 54:
+  case 55:
+  case 56:
+  case 57:
+  case 58:
+  case 59:
+  case 60:
+  case 61:
+  case 62:
+  case 63:
+  case 64:
+  case 65:
+  case 66:
+  case 67:
+  case 68:
+  case 69:
+  case 70:
+  case 71:
+  case 72:
+  case 73:
+  case 74:
+  case 75:
+  case 76:
+  case 77:
+  case 78:
+  case 79:
+  case 80:
+  case 81:
+  case 82:
+  case 83:
+  case 84:
+  case 85:
+  case 86:
+  case 87:
+  case 88:
+  case 89:
+  case 90:
+  case 91:
+  case 92:
+  case 93:
+  case 94:
+  case 95:
+  case 96:
+  case 97:
+  case 98:
+  case 99:
+  case 100:
+  case 101:
+  case 102:
+  case 103:
+  case 104:
+  case 105:
+  case 106:
+  case 107:
+  case 108:
+  case 109:
+  case 110:
+  case 111:
+  case 112:
+  case 113:
+  case 114:
+  case 115:
+  case 116:
+  case 117:
+  case 118:
+  case 119:
+  case 120:
+  case 121:
+  case 122:
+  case 123:
+  case 124:
+  case 125:

[PATCH] D37808: [clang-tidy] Add new hicpp-multiway-paths-covered check for missing branches

2017-10-31 Thread Jonas Toth via Phabricator via cfe-commits
JonasToth updated this revision to Diff 121011.
JonasToth added a comment.

- fix rebasing issues in docs


https://reviews.llvm.org/D37808

Files:
  clang-tidy/hicpp/CMakeLists.txt
  clang-tidy/hicpp/HICPPTidyModule.cpp
  clang-tidy/hicpp/MultiwayPathsCoveredCheck.cpp
  clang-tidy/hicpp/MultiwayPathsCoveredCheck.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/hicpp-multiway-paths-covered.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/hicpp-multiway-paths-covered-else.cpp
  test/clang-tidy/hicpp-multiway-paths-covered.cpp

Index: test/clang-tidy/hicpp-multiway-paths-covered.cpp
===
--- /dev/null
+++ test/clang-tidy/hicpp-multiway-paths-covered.cpp
@@ -0,0 +1,445 @@
+// RUN: %check_clang_tidy %s hicpp-multiway-paths-covered %t
+
+enum OS { Mac,
+  Windows,
+  Linux };
+
+struct Bitfields {
+  unsigned UInt : 3;
+  int SInt : 1;
+};
+
+int return_integer() { return 42; }
+
+void bad_switch(int i) {
+  switch (i) {
+// CHECK-MESSAGES: [[@LINE-1]]:3: warning: switch with only one case; use if statement
+  case 0:
+break;
+  }
+  // No default in this switch
+  switch (i) {
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: potential uncovered codepath; add a default case
+  case 0:
+break;
+  case 1:
+break;
+  case 2:
+break;
+  }
+
+  // degenerate, maybe even warning
+  switch (i) {
+// CHECK-MESSAGES: [[@LINE-1]]:3: warning: degenerated switch without labels
+  }
+
+  switch (int j = return_integer()) {
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: potential uncovered codepath; add a default case
+  case 0:
+  case 1:
+  case 2:
+break;
+  }
+
+  // Degenerated, only default case.
+  switch (i) {
+// CHECK-MESSAGES: [[@LINE-1]]:3: warning: degenerated switch with default label only
+  default:
+break;
+  }
+
+  // Degenerated, only one case label and default case -> Better as if-stmt.
+  switch (i) {
+// CHECK-MESSAGES: [[@LINE-1]]:3: warning: switch could be better written as if/else statement
+  case 0:
+break;
+  default:
+break;
+  }
+
+  unsigned long long BigNumber = 0;
+  switch (BigNumber) {
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: potential uncovered codepath; add a default case
+  case 0:
+  case 1:
+break;
+  }
+
+  const int &IntRef = i;
+  switch (IntRef) {
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: potential uncovered codepath; add a default case
+  case 0:
+  case 1:
+break;
+  }
+
+  char C = 'A';
+  switch (C) {
+  // CHECK-MESSAGES: [[@LINE-1]]:3: warning: potential uncovered codepath; add a default case
+  case 'A':
+break;
+  case 'B':
+break;
+  }
+
+  Bitfields Bf;
+  // UInt has 3 bits size.
+  switch (Bf.UInt) {
+// CHECK-MESSAGES: [[@LINE-1]]:3: warning: potential uncovered codepath; add a default case
+  case 0:
+  case 1:
+break;
+  }
+  // All paths explicitly covered.
+  switch (Bf.UInt) {
+  case 0:
+  case 1:
+  case 2:
+  case 3:
+  case 4:
+  case 5:
+  case 6:
+  case 7:
+break;
+  }
+  // SInt has 1 bit size, so this is somewhat degenerated.
+  switch (Bf.SInt) {
+// CHECK-MESSAGES: [[@LINE-1]]:3: warning: switch with only one case; use if statement
+  case 0:
+break;
+  }
+  // All paths explicitly covered.
+  switch (Bf.SInt) {
+  case 0:
+  case 1:
+break;
+  }
+}
+
+void unproblematic_switch(unsigned char c) {
+  switch (c) {
+  case 0:
+  case 1:
+  case 2:
+  case 3:
+  case 4:
+  case 5:
+  case 6:
+  case 7:
+  case 8:
+  case 9:
+  case 10:
+  case 11:
+  case 12:
+  case 13:
+  case 14:
+  case 15:
+  case 16:
+  case 17:
+  case 18:
+  case 19:
+  case 20:
+  case 21:
+  case 22:
+  case 23:
+  case 24:
+  case 25:
+  case 26:
+  case 27:
+  case 28:
+  case 29:
+  case 30:
+  case 31:
+  case 32:
+  case 33:
+  case 34:
+  case 35:
+  case 36:
+  case 37:
+  case 38:
+  case 39:
+  case 40:
+  case 41:
+  case 42:
+  case 43:
+  case 44:
+  case 45:
+  case 46:
+  case 47:
+  case 48:
+  case 49:
+  case 50:
+  case 51:
+  case 52:
+  case 53:
+  case 54:
+  case 55:
+  case 56:
+  case 57:
+  case 58:
+  case 59:
+  case 60:
+  case 61:
+  case 62:
+  case 63:
+  case 64:
+  case 65:
+  case 66:
+  case 67:
+  case 68:
+  case 69:
+  case 70:
+  case 71:
+  case 72:
+  case 73:
+  case 74:
+  case 75:
+  case 76:
+  case 77:
+  case 78:
+  case 79:
+  case 80:
+  case 81:
+  case 82:
+  case 83:
+  case 84:
+  case 85:
+  case 86:
+  case 87:
+  case 88:
+  case 89:
+  case 90:
+  case 91:
+  case 92:
+  case 93:
+  case 94:
+  case 95:
+  case 96:
+  case 97:
+  case 98:
+  case 99:
+  case 100:
+  case 101:
+  case 102:
+  case 103:
+  case 104:
+  case 105:
+  case 106:
+  case 107:
+  case 108:
+  case 109:
+  case 110:
+  case 111:
+  case 112:
+  case 113:
+  case 114:
+  case 115:
+  case 116:
+  case 117:
+  case 118:
+  case 119:
+  case 120:
+  case 121:
+  case 122:
+  case 123:
+  case 124:
+  case 125:
+  case 126:
+  case 127:
+  case 128:
+  case 129:
+  case 130:

[PATCH] D37808: [clang-tidy] Add new hicpp-multiway-paths-covered check for missing branches

2017-10-31 Thread Jonas Toth via Phabricator via cfe-commits
JonasToth added a comment.

@aaron.ballman could you take a (i think) finishing look on the check? Most 
issues should be resolved and i think its ready for the finishing line :)


https://reviews.llvm.org/D37808



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


[PATCH] D39457: [OPENMP] Current status of OpenMP support.

2017-10-31 Thread Jonas Hahnfeld via Phabricator via cfe-commits
Hahnfeld added a comment.

Do we want to add documentation about which target devices Clang can generate 
code for?




Comment at: docs/OpenMPSupport.rst:46
+
+* #pragma omp distribute parallel for [simd]: :partial:`Partial`. No full 
codegen support.
+

I think that's also a combined directive?


https://reviews.llvm.org/D39457



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


Fwd: [PATCH] D39462: [Sema] Implement -Wmaybe-tautological-constant-compare for when the tautologicalness is data model dependent

2017-10-31 Thread Roman Lebedev via cfe-commits
And i have again forgot to add the appropriate -commits list from the start.
Is there any reason at all why phab does not/should not do that automatically?

-- Forwarded message --
From: Roman Lebedev via Phabricator 
Date: Tue, Oct 31, 2017 at 8:44 PM
Subject: [PATCH] D39462: [Sema] Implement
-Wmaybe-tautological-constant-compare for when the tautologicalness is
data model dependent
To: lebedev...@gmail.com, rich...@metafoo.co.uk, rjmcc...@gmail.com,
dblai...@gmail.com
Cc: mclow.li...@gmail.com, aaron.ball...@gmail.com,
bc...@codeaurora.org, smee...@fb.com, jkor...@apple.com,
shen...@google.com


lebedev.ri created this revision.
lebedev.ri added a project: clang.

As brought up in https://reviews.llvm.org/D39149, and post-review
mails for some other commits,
the current `-Wtautological-constant-compare` is dumb, much like
unreachable code diagnostic.

The common complaint is that it diagnoses the comparisons between an `int` and
`long` when compiling for a 32-bit target as tautological, but not when
compiling for 64-bit targets. The underlying problem is obvious: data model.
In most cases, 64-bit target is `LP64` (`int` is 32-bit, `long` and pointer are
64-bit), and the 32-bit target is `ILP32` (`int`, `long`, and pointer
are 32-bit).

I.e. the common pattern is: (pseudocode)

  #include 
  #include 
  int main() {
using T1 = long;
using T2 = int;

T1 r;
if (r < std::numeric_limits::min()) {}
if (r > std::numeric_limits::max()) {}
  }

The fix is simple: if the types of the values being compared are different, but
are of the same size, then we issue `-Wmaybe-tautological-constant-compare`
instead of `-Wtautological-constant-compare`.
That new diagnostic is *not* enabled by default/-Wall/-Wextra.

Caveat: i did not actually verify that ^ pseudocode actually triggers
the new diag.
Looking at AST, it should.


Repository:
  rL LLVM

https://reviews.llvm.org/D39462

Files:
  docs/ReleaseNotes.rst
  include/clang/Basic/DiagnosticGroups.td
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Sema/SemaChecking.cpp
  test/Sema/maybe-tautological-constant-compare.c
Index: test/Sema/maybe-tautological-constant-compare.c
===
--- /dev/null
+++ test/Sema/maybe-tautological-constant-compare.c
@@ -0,0 +1,342 @@
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -fsyntax-only -DLP64 -Wmaybe-tautological-constant-compare -DTEST  -verify %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -fsyntax-only -DLP64 -verify %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -fsyntax-only -DLP64 -Wmaybe-tautological-constant-compare -DTEST -verify -x c++ %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -fsyntax-only -DLP64 -verify -x c++ %s
+// RUN: %clang_cc1 -triple i386-linux-gnu -fsyntax-only -DILP32 -Wmaybe-tautological-constant-compare -DTEST -verify %s
+// RUN: %clang_cc1 -triple i386-linux-gnu -fsyntax-only -DILP32 -verify %s
+// R1UN: %clang_cc1 -triple i386-linux-gnu -fsyntax-only -DILP32 -Wmaybe-tautological-constant-compare -DTEST -verify -x c++ %s
+// R1UN: %clang_cc1 -triple i386-linux-gnu -fsyntax-only -DILP32 -verify -x c++ %s
+
+int value(void);
+
+int main() {
+  unsigned long ul = value();
+
+#if defined(LP64)
+#if __SIZEOF_INT__ != 4
+#error Expecting 32-bit int
+#endif
+#if __SIZEOF_LONG__ != 8
+#error Expecting 64-bit int
+#endif
+#elif defined(ILP32)
+#if __SIZEOF_INT__ != 4
+#error Expecting 32-bit int
+#endif
+#if __SIZEOF_LONG__ != 4
+#error Expecting 32-bit int
+#endif
+#else
+#error LP64 or ILP32 should be defined
+#endif
+
+#if defined(LP64)
+  // expected-no-diagnostics
+
+  if (ul < 4294967295)
+return 0;
+  if (4294967295 >= ul)
+return 0;
+  if (ul > 4294967295)
+return 0;
+  if (4294967295 <= ul)
+return 0;
+  if (ul <= 4294967295)
+return 0;
+  if (4294967295 > ul)
+return 0;
+  if (ul >= 4294967295)
+return 0;
+  if (4294967295 < ul)
+return 0;
+  if (ul == 4294967295)
+return 0;
+  if (4294967295 != ul)
+return 0;
+  if (ul != 4294967295)
+return 0;
+  if (4294967295 == ul)
+return 0;
+
+  if (ul < 4294967295U)
+return 0;
+  if (4294967295U >= ul)
+return 0;
+  if (ul > 4294967295U)
+return 0;
+  if (4294967295U <= ul)
+return 0;
+  if (ul <= 4294967295U)
+return 0;
+  if (4294967295U > ul)
+return 0;
+  if (ul >= 4294967295U)
+return 0;
+  if (4294967295U < ul)
+return 0;
+  if (ul == 4294967295U)
+return 0;
+  if (4294967295U != ul)
+return 0;
+  if (ul != 4294967295U)
+return 0;
+  if (4294967295U == ul)
+return 0;
+
+  if (ul < 4294967295L)
+return 0;
+  if (4294967295L >= ul)
+return 0;
+  if (ul > 4294967295L)
+return 0;
+  if (4294967295L <= ul)
+return 0;
+  if (ul <= 4294967295L)
+return 0;
+  if (4294967295L > ul)
+return 0;
+  if (ul >= 4294967295L)
+return 0;
+  if (4294967295L < ul)
+return 0;
+  if (ul == 4294967295L)
+return 0;
+  if (4294967295L != ul)
+return 0

[PATCH] D39457: [OPENMP] Current status of OpenMP support.

2017-10-31 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

In https://reviews.llvm.org/D39457#911950, @Hahnfeld wrote:

> Do we want to add documentation about which target devices Clang can generate 
> code for?


Ok




Comment at: docs/OpenMPSupport.rst:46
+
+* #pragma omp distribute parallel for [simd]: :partial:`Partial`. No full 
codegen support.
+

Hahnfeld wrote:
> I think that's also a combined directive?
No, it is not. It is part of device constructs


https://reviews.llvm.org/D39457



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


[PATCH] D39457: [OPENMP] Current status of OpenMP support.

2017-10-31 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev updated this revision to Diff 121018.
ABataev added a comment.

Added info about supported devices.


https://reviews.llvm.org/D39457

Files:
  docs/OpenMPSupport.rst
  docs/index.rst


Index: docs/index.rst
===
--- docs/index.rst
+++ docs/index.rst
@@ -39,6 +39,7 @@
SourceBasedCodeCoverage
Modules
MSVCCompatibility
+   OpenMPSupport
ThinLTO
CommandGuide/index
FAQ
Index: docs/OpenMPSupport.rst
===
--- /dev/null
+++ docs/OpenMPSupport.rst
@@ -0,0 +1,70 @@
+.. raw:: html
+
+  
+.none { background-color: #FF }
+.partial { background-color: #99 }
+.good { background-color: #CCFF99 }
+  
+
+.. role:: none
+.. role:: partial
+.. role:: good
+
+==
+OpenMP Support
+==
+
+Clang fully supports OpenMP 3.5 + some elements of OpenMP 4.5. Clang supports 
offloading to X86_64, AArch64, PPC64[LE] and Cuda devices.
+The status of major OpenMP 4.5 features support in Clang.
+
+Standalone directives
+=
+
+* #pragma omp [for] simd: :good:`Complete`.
+
+* #pragma omp declare simd: :partial:`Partial`.  We support parsing/semantic
+  analysis + generation of special attributes for X86 target, but still
+  missing the LLVM pass for vectorization.
+
+* #pragma omp taskloop [simd]: :good:`Complete`.
+
+* #pragma omp target [enter|exit] data: :good:`Mostly complete`.  Some rework 
is
+  required for better stability.
+
+* #pragma omp target update: :good:`Mostly complete`.  Some rework is
+  required for better stability.
+
+* #pragma omp target: :partial:`Partial`.  No support for the `reduction`,
+  `nowait` and `depend` clauses.
+
+* #pragma omp declare target: :partial:`Partial`.  No full codegen support.
+
+* #pragma omp teams: :good:`Complete`.
+
+* #pragma omp distribute [simd]: :good:`Complete`.
+
+* #pragma omp distribute parallel for [simd]: :partial:`Partial`. No full 
codegen support.
+
+Combined directives
+===
+
+* #pragma omp parallel for simd: :good:`Complete`.
+
+* #pragma omp target parallel: :good:`Complete`.
+
+* #pragma omp target parallel for [simd]: :partial:`Partial`.  No full codegen 
support.
+
+* #pragma omp target simd: :partial:`Partial`.  No full codegen support.
+
+* #pragma omp target teams: :partial:`Partial`.  No full codegen support.
+
+* #pragma omp teams distribute [simd]: :partial:`Partial`.  No full codegen 
support.
+
+* #pragma omp target teams distribute [simd]: :partial:`Partial`.  No full 
codegen support.
+
+* #pragma omp teams distribute parallel for [simd]: :partial:`Partial`.  No 
full codegen support.
+
+* #pragma omp target teams distribute parallel for [simd]: :partial:`Partial`. 
 No full codegen support.
+
+Clang does not support any constructs/updates from upcoming OpenMP 5.0 except 
for `reduction`-based clauses in the `task`-based directives.
+


Index: docs/index.rst
===
--- docs/index.rst
+++ docs/index.rst
@@ -39,6 +39,7 @@
SourceBasedCodeCoverage
Modules
MSVCCompatibility
+   OpenMPSupport
ThinLTO
CommandGuide/index
FAQ
Index: docs/OpenMPSupport.rst
===
--- /dev/null
+++ docs/OpenMPSupport.rst
@@ -0,0 +1,70 @@
+.. raw:: html
+
+  
+.none { background-color: #FF }
+.partial { background-color: #99 }
+.good { background-color: #CCFF99 }
+  
+
+.. role:: none
+.. role:: partial
+.. role:: good
+
+==
+OpenMP Support
+==
+
+Clang fully supports OpenMP 3.5 + some elements of OpenMP 4.5. Clang supports offloading to X86_64, AArch64, PPC64[LE] and Cuda devices.
+The status of major OpenMP 4.5 features support in Clang.
+
+Standalone directives
+=
+
+* #pragma omp [for] simd: :good:`Complete`.
+
+* #pragma omp declare simd: :partial:`Partial`.  We support parsing/semantic
+  analysis + generation of special attributes for X86 target, but still
+  missing the LLVM pass for vectorization.
+
+* #pragma omp taskloop [simd]: :good:`Complete`.
+
+* #pragma omp target [enter|exit] data: :good:`Mostly complete`.  Some rework is
+  required for better stability.
+
+* #pragma omp target update: :good:`Mostly complete`.  Some rework is
+  required for better stability.
+
+* #pragma omp target: :partial:`Partial`.  No support for the `reduction`,
+  `nowait` and `depend` clauses.
+
+* #pragma omp declare target: :partial:`Partial`.  No full codegen support.
+
+* #pragma omp teams: :good:`Complete`.
+
+* #pragma omp distribute [simd]: :good:`Complete`.
+
+* #pragma omp distribute parallel for [simd]: :partial:`Partial`. No full codegen support.
+
+Combined directives
+===
+
+* #pragma omp parallel for simd: :good:`Complete`.
+
+* #pragma omp target parallel: :good:`Complete`.
+
+* #pragma omp target parallel for [sim

[PATCH] D39149: [libc++] Prevent tautological comparisons

2017-10-31 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

In https://reviews.llvm.org/D39149#910825, @mclow.lists wrote:

> I dislike this change fairly strongly.
>  I would much rather pursue a clang-based solution (since clang is being 
> unhelpful here)
>  Don't know if we can get one, though.


@smeenai  
https://reviews.llvm.org/D39462 *should* render this 
(https://reviews.llvm.org/D39149) differential unnecessary, *please* try it.


https://reviews.llvm.org/D39149



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


[PATCH] D39462: [Sema] Implement -Wmaybe-tautological-constant-compare for when the tautologicalness is data model dependent

2017-10-31 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

The actual choice of integer type is not stable across targets any more than 
the size is.  In practice, people often don't use int and long, they use 
standard typedefs like size_t and uint64_t, but the actual type chosen for 
size_t is arbitrary when there are multiple types at that bit-width.  So I'm 
concerned that you're suppressing more than you think here and still not going 
to satisfy people.

Also, "data model" is not a term in use.  Use "target" or "target platform".


Repository:
  rL LLVM

https://reviews.llvm.org/D39462



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


[PATCH] D39079: New clang option -fno-plt to avoid PLT for external calls

2017-10-31 Thread Sriraman Tallam via Phabricator via cfe-commits
tmsriram added a comment.

Ping.  How do we take this forward?


https://reviews.llvm.org/D39079



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


[PATCH] D39079: New clang option -fno-plt to avoid PLT for external calls

2017-10-31 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added a comment.

I'd also like to highlight that LLVM has many users with different needs. 
Sometimes we need to "disagree and commit". Flags are one of the primary ways 
that we have to do that.


https://reviews.llvm.org/D39079



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


[PATCH] D39204: [CodeGen] __builtin_sqrt should map to the compiler's intrinsic sqrt function

2017-10-31 Thread Eli Friedman via Phabricator via cfe-commits
efriedma accepted this revision.
efriedma added a comment.
This revision is now accepted and ready to land.

Let's do this one step at a time; first this patch, then fix the __builtin_* 
functions to use "e", then add all the missing cases 
CodeGenFunction::EmitBuiltinExpr.

This patch LGTM, assuming you fix the commit message (and the title on 
Phabricator) to properly describe the change.


https://reviews.llvm.org/D39204



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


[PATCH] D35109: [Analyzer] SValBuilder Comparison Rearrangement

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

In https://reviews.llvm.org/D35109#837723, @NoQ wrote:

> It's something similar to assuming that the string length is within range [0, 
> INT_MAX/4] in CStringChecker: we can easily assume that no overflow is 
> happening in computations involving string lengths or iterator positions, but 
> not on generic integers. Which lead me to believing that we could maintain a 
> no-overflow variant of evalBinOp (questionable).
>
> Would anything go wrong if we only enable this code when both symbols are 
> known to be within range [-max/4, max/4]? And in the checker, add the 
> respective assumption. I believe it's a very clear way to express that no 
> overflow is happening. In fact, in the program state we can add an API 
> `ProgramStateRef assumeNoOverflow(SVal, QualType)`, which tries to assume 
> that the value is within range [-max/4, max/4] for signed types or [0, max/4] 
> for unsigned types (and fails when such assumption is known be violated), so 
> that to avoid duplicating similar trick in every checker.


I had a quick look into actually implementing this solution, and i generally 
liked how it looks. Instead of the checker saying "I know that these symbols 
won't overflow on any operations, so let me do whatever I want", it says "I 
know that these symbols are small" and the core handles the rest.

I managed to get this patch and https://reviews.llvm.org/D35110 and 
https://reviews.llvm.org/D32642 running on top of my solution in a fairly 
straightforward manner. I did not see if there is any impact on performance; if 
there is, in the worst case we may want to expose the "unsafe" functions to the 
checkers to optimize out repeated checks. A bit of cleanup may be necessary 
after me (eg. turn static functions into methods where appropriate).

Unsigned integers are not supported, because their overflows are harder to 
avoid; however, as far as i understand you are only interested in signed 
integers. For signed integers, rearrangement only kicks in when all symbols and 
concrete integers are of the same type `T` and are constrained within `[-max/4, 
max/4]`, where `max` is the maximum value of `T`.

Here are my patches:

- On top of https://reviews.llvm.org/D35109: F5459988: Max4Rearrangements.patch 

- On top of https://reviews.llvm.org/D35110: F5459990: Max4Negations.patch 

- On top of https://reviews.llvm.org/D35110: F5459991: Max4Iterators.patch 


All tests should pass when all 6 patches are applied.

Could you see if this works for you?


https://reviews.llvm.org/D35109



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


[PATCH] D39428: [Analyzer] As suggested, use value storage for BodyFarm

2017-10-31 Thread George Karpenkov via Phabricator via cfe-commits
george.karpenkov added a comment.

@xazax.hun I'm really not convinced:

  george@/Volumes/Transcend/code/llvm (master)≻ rg "\w+\&" 
tools/clang/include/clang/StaticAnalyzer
  tools/clang/include/clang/StaticAnalyzer/Core/Checker.h
  31:  static void _checkDecl(void *checker, const Decl *D, AnalysisManager& 
mgr,
  50:  static void _checkBody(void *checker, const Decl *D, AnalysisManager& 
mgr,
  67: AnalysisManager& mgr,
  489:raw_ostream& operator<<(raw_ostream &Out, const CheckerBase &Checker);
  554:  /*implicit*/ operator bool&() { return val; }
  555:  /*implicit*/ operator const bool&() const { return val; }
  
  tools/clang/include/clang/StaticAnalyzer/Core/CheckerManager.h
  170:  void runCheckersOnASTDecl(const Decl *D, AnalysisManager& mgr,
  174:  void runCheckersOnASTBody(const Decl *D, AnalysisManager& mgr,
  400:  typedef CheckerFn
  469:  AnalysisManager&, BugReporter &)>
  ...

On top of that, reference is part of the type, not part of the variable name,


https://reviews.llvm.org/D39428



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


[PATCH] D39204: [CodeGen] __builtin_sqrt should map to the compiler's intrinsic sqrt function

2017-10-31 Thread Sanjay Patel via Phabricator via cfe-commits
spatel added a comment.

In https://reviews.llvm.org/D39204#912084, @efriedma wrote:

> Let's do this one step at a time; first this patch, then fix the __builtin_* 
> functions to use "e", then add all the missing cases 
> CodeGenFunction::EmitBuiltinExpr.


Sounds good.

> This patch LGTM, assuming you fix the commit message (and the title on 
> Phabricator) to properly describe the change.

Sure - I didn't know if we prefer to leave the title for the sake of email 
thread continuity on the list or not, but I'll update that now.


https://reviews.llvm.org/D39204



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


[PATCH] D39204: [CodeGen] map sqrt libcalls to llvm.sqrt when errno is not set

2017-10-31 Thread Sanjay Patel via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL317031: [CodeGen] map sqrt libcalls to llvm.sqrt when errno 
is not set (authored by spatel).

Changed prior to commit:
  https://reviews.llvm.org/D39204?vs=120902&id=121042#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D39204

Files:
  cfe/trunk/lib/CodeGen/CGBuiltin.cpp
  cfe/trunk/test/CodeGen/2005-07-20-SqrtNoErrno.c
  cfe/trunk/test/CodeGen/builtin-sqrt.c
  cfe/trunk/test/CodeGen/libcalls.c

Index: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
===
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp
@@ -2072,24 +2072,21 @@
 return RValue::get(nullptr);
   }
 
-// Library functions with special handling.
   case Builtin::BIsqrt:
   case Builtin::BIsqrtf:
-  case Builtin::BIsqrtl: {
-// Transform a call to sqrt* into a @llvm.sqrt.* intrinsic call, but only
-// in finite- or unsafe-math mode (the intrinsic has different semantics
-// for handling negative numbers compared to the library function, so
-// -fmath-errno=0 is not enough).
-if (!FD->hasAttr())
-  break;
-if (!(CGM.getCodeGenOpts().UnsafeFPMath ||
-  CGM.getCodeGenOpts().NoNaNsFPMath))
-  break;
-Value *Arg0 = EmitScalarExpr(E->getArg(0));
-llvm::Type *ArgType = Arg0->getType();
-Value *F = CGM.getIntrinsic(Intrinsic::sqrt, ArgType);
-return RValue::get(Builder.CreateCall(F, Arg0));
-  }
+  case Builtin::BIsqrtl:
+// Builtins have the same semantics as library functions. The LLVM intrinsic
+// has the same semantics as the library function except it does not set
+// errno. Thus, we can transform either sqrt or __builtin_sqrt to @llvm.sqrt
+// if the call is 'const' (the call must not set errno).
+//
+// FIXME: The builtin cases are not here because they are marked 'const' in
+// Builtins.def. So that means they are wrongly defined to have different
+// semantics than the library functions. If we included them here, we would
+// turn them into LLVM intrinsics regardless of whether -fmath-errno was on.
+if (FD->hasAttr())
+  return RValue::get(emitUnaryBuiltin(*this, E, Intrinsic::sqrt));
+break;
 
   case Builtin::BI__builtin_pow:
   case Builtin::BI__builtin_powf:
Index: cfe/trunk/test/CodeGen/builtin-sqrt.c
===
--- cfe/trunk/test/CodeGen/builtin-sqrt.c
+++ cfe/trunk/test/CodeGen/builtin-sqrt.c
@@ -0,0 +1,19 @@
+// RUN: %clang_cc1 -fmath-errno -triple x86_64-apple-darwin %s -emit-llvm -o - | FileCheck %s --check-prefix=HAS_ERRNO
+// RUN: %clang_cc1  -triple x86_64-apple-darwin %s -emit-llvm -o - | FileCheck %s --check-prefix=NO_ERRNO
+
+// FIXME: If a builtin is supposed to have identical semantics to its libm twin, then it
+// should not be marked "constant" in Builtins.def because that means it can't set errno.
+// Note that both runs have 'readnone' on the libcall here.
+
+float foo(float X) {
+  // HAS_ERRNO: call float @sqrtf(float
+  // NO_ERRNO: call float @sqrtf(float
+  return __builtin_sqrtf(X);
+}
+
+// HAS_ERRNO: declare float @sqrtf(float) [[ATTR:#[0-9]+]]
+// HAS_ERRNO: attributes [[ATTR]] = { nounwind readnone {{.*}}}
+
+// NO_ERRNO: declare float @sqrtf(float) [[ATTR:#[0-9]+]]
+// NO_ERRNO: attributes [[ATTR]] = { nounwind readnone {{.*}}}
+
Index: cfe/trunk/test/CodeGen/libcalls.c
===
--- cfe/trunk/test/CodeGen/libcalls.c
+++ cfe/trunk/test/CodeGen/libcalls.c
@@ -6,29 +6,28 @@
 // CHECK-NO-LABEL: define void @test_sqrt
 // CHECK-FAST-LABEL: define void @test_sqrt
 void test_sqrt(float a0, double a1, long double a2) {
-  // Following llvm-gcc's lead, we never emit these as intrinsics;
-  // no-math-errno isn't good enough.  We could probably use intrinsics
-  // with appropriate guards if it proves worthwhile.
-
   // CHECK-YES: call float @sqrtf
-  // CHECK-NO: call float @sqrtf
+  // CHECK-NO: call float @llvm.sqrt.f32(float
+  // CHECK-FAST: call float @llvm.sqrt.f32(float
   float l0 = sqrtf(a0);
 
   // CHECK-YES: call double @sqrt
-  // CHECK-NO: call double @sqrt
+  // CHECK-NO: call double @llvm.sqrt.f64(double
+  // CHECK-FAST: call double @llvm.sqrt.f64(double
   double l1 = sqrt(a1);
 
   // CHECK-YES: call x86_fp80 @sqrtl
-  // CHECK-NO: call x86_fp80 @sqrtl
+  // CHECK-NO: call x86_fp80 @llvm.sqrt.f80(x86_fp80
+  // CHECK-FAST: call x86_fp80 @llvm.sqrt.f80(x86_fp80
   long double l2 = sqrtl(a2);
 }
 
 // CHECK-YES: declare float @sqrtf(float)
 // CHECK-YES: declare double @sqrt(double)
 // CHECK-YES: declare x86_fp80 @sqrtl(x86_fp80)
-// CHECK-NO: declare float @sqrtf(float) [[NUW_RN:#[0-9]+]]
-// CHECK-NO: declare double @sqrt(double) [[NUW_RN]]
-// CHECK-NO: declare x86_fp80 @sqrtl(x86_fp80) [[NUW_RN]]
+// CHECK-NO: declare float @llvm.sqrt.f32(float)
+// CHECK-NO: declare double @llvm.sqr

r317031 - [CodeGen] map sqrt libcalls to llvm.sqrt when errno is not set

2017-10-31 Thread Sanjay Patel via cfe-commits
Author: spatel
Date: Tue Oct 31 13:19:39 2017
New Revision: 317031

URL: http://llvm.org/viewvc/llvm-project?rev=317031&view=rev
Log:
[CodeGen] map sqrt libcalls to llvm.sqrt when errno is not set

The LLVM sqrt intrinsic definition changed with:
D28797
...so we don't have to use any relaxed FP settings other than errno handling.

This patch sidesteps a question raised in PR27435:
https://bugs.llvm.org/show_bug.cgi?id=27435

Is a programmer using __builtin_sqrt() invoking the compiler's intrinsic 
definition of sqrt or the mathlib definition of sqrt?

But we have an answer now: the builtin should match the behavior of the libm 
function including errno handling.

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

Added:
cfe/trunk/test/CodeGen/builtin-sqrt.c
  - copied, changed from r317030, 
cfe/trunk/test/CodeGen/2005-07-20-SqrtNoErrno.c
Removed:
cfe/trunk/test/CodeGen/2005-07-20-SqrtNoErrno.c
Modified:
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/test/CodeGen/libcalls.c

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=317031&r1=317030&r2=317031&view=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Tue Oct 31 13:19:39 2017
@@ -2072,24 +2072,21 @@ RValue CodeGenFunction::EmitBuiltinExpr(
 return RValue::get(nullptr);
   }
 
-// Library functions with special handling.
   case Builtin::BIsqrt:
   case Builtin::BIsqrtf:
-  case Builtin::BIsqrtl: {
-// Transform a call to sqrt* into a @llvm.sqrt.* intrinsic call, but only
-// in finite- or unsafe-math mode (the intrinsic has different semantics
-// for handling negative numbers compared to the library function, so
-// -fmath-errno=0 is not enough).
-if (!FD->hasAttr())
-  break;
-if (!(CGM.getCodeGenOpts().UnsafeFPMath ||
-  CGM.getCodeGenOpts().NoNaNsFPMath))
-  break;
-Value *Arg0 = EmitScalarExpr(E->getArg(0));
-llvm::Type *ArgType = Arg0->getType();
-Value *F = CGM.getIntrinsic(Intrinsic::sqrt, ArgType);
-return RValue::get(Builder.CreateCall(F, Arg0));
-  }
+  case Builtin::BIsqrtl:
+// Builtins have the same semantics as library functions. The LLVM 
intrinsic
+// has the same semantics as the library function except it does not set
+// errno. Thus, we can transform either sqrt or __builtin_sqrt to 
@llvm.sqrt
+// if the call is 'const' (the call must not set errno).
+//
+// FIXME: The builtin cases are not here because they are marked 'const' in
+// Builtins.def. So that means they are wrongly defined to have different
+// semantics than the library functions. If we included them here, we would
+// turn them into LLVM intrinsics regardless of whether -fmath-errno was 
on.
+if (FD->hasAttr())
+  return RValue::get(emitUnaryBuiltin(*this, E, Intrinsic::sqrt));
+break;
 
   case Builtin::BI__builtin_pow:
   case Builtin::BI__builtin_powf:

Removed: cfe/trunk/test/CodeGen/2005-07-20-SqrtNoErrno.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/2005-07-20-SqrtNoErrno.c?rev=317030&view=auto
==
--- cfe/trunk/test/CodeGen/2005-07-20-SqrtNoErrno.c (original)
+++ cfe/trunk/test/CodeGen/2005-07-20-SqrtNoErrno.c (removed)
@@ -1,10 +0,0 @@
-// RUN: %clang_cc1 -triple x86_64-apple-darwin %s -emit-llvm -o - | FileCheck 
%s
-// llvm.sqrt has undefined behavior on negative inputs, so it is
-// inappropriate to translate C/C++ sqrt to this.
-float sqrtf(float x);
-float foo(float X) {
-  // CHECK: foo
-  // CHECK: call float @sqrtf(float %
-  // Check that this is marked readonly when errno is ignored.
-  return sqrtf(X);
-}

Copied: cfe/trunk/test/CodeGen/builtin-sqrt.c (from r317030, 
cfe/trunk/test/CodeGen/2005-07-20-SqrtNoErrno.c)
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/builtin-sqrt.c?p2=cfe/trunk/test/CodeGen/builtin-sqrt.c&p1=cfe/trunk/test/CodeGen/2005-07-20-SqrtNoErrno.c&r1=317030&r2=317031&rev=317031&view=diff
==
--- cfe/trunk/test/CodeGen/2005-07-20-SqrtNoErrno.c (original)
+++ cfe/trunk/test/CodeGen/builtin-sqrt.c Tue Oct 31 13:19:39 2017
@@ -1,10 +1,19 @@
-// RUN: %clang_cc1 -triple x86_64-apple-darwin %s -emit-llvm -o - | FileCheck 
%s
-// llvm.sqrt has undefined behavior on negative inputs, so it is
-// inappropriate to translate C/C++ sqrt to this.
-float sqrtf(float x);
+// RUN: %clang_cc1 -fmath-errno -triple x86_64-apple-darwin %s -emit-llvm -o - 
| FileCheck %s --check-prefix=HAS_ERRNO
+// RUN: %clang_cc1  -triple x86_64-apple-darwin %s -emit-llvm -o - 
| FileCheck %s --check-prefix=NO_ERRNO
+
+// FIXME: If a builtin is supposed to have identical semantics to its libm 
twin, then it
+// should not be marked "cons

[PATCH] D39428: [Analyzer] As suggested, use value storage for BodyFarm

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

In https://reviews.llvm.org/D39428#912126, @george.karpenkov wrote:

> @xazax.hun I'm really not convinced:


Unfortunately, the LLVM codebase right now does not strictly follow the style 
guide. But clang-format puts the references next to the variable (or function 
in case of return type) names. Also if you check the code snippets in the 
coding standard: 
https://llvm.org/docs/CodingStandards.html#beware-unnecessary-copies-with-auto 
you can see that where we officially put the references.


https://reviews.llvm.org/D39428



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


r317032 - Fix usage of right shift operator in fold expressions

2017-10-31 Thread Richard Smith via cfe-commits
Author: rsmith
Date: Tue Oct 31 13:29:22 2017
New Revision: 317032

URL: http://llvm.org/viewvc/llvm-project?rev=317032&view=rev
Log:
Fix usage of right shift operator in fold expressions

The right shift operator was not seen as a valid operator in a fold expression, 
which is PR32563.

Patch by Nicolas Lesser ("Blitz Rakete")!

Modified:
cfe/trunk/include/clang/Parse/Parser.h
cfe/trunk/lib/Parse/ParseExpr.cpp
cfe/trunk/test/Parser/cxx1z-fold-expressions.cpp

Modified: cfe/trunk/include/clang/Parse/Parser.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Parse/Parser.h?rev=317032&r1=317031&r2=317032&view=diff
==
--- cfe/trunk/include/clang/Parse/Parser.h (original)
+++ cfe/trunk/include/clang/Parse/Parser.h Tue Oct 31 13:29:22 2017
@@ -506,6 +506,12 @@ private:
Kind == tok::annot_module_end || Kind == tok::annot_module_include;
   }
 
+  /// \brief Checks if the \p Level is valid for use in a fold expression.
+  bool isFoldOperator(prec::Level Level) const;
+
+  /// \brief Checks if the \p Kind is a valid operator for fold expressions.
+  bool isFoldOperator(tok::TokenKind Kind) const;
+
   /// \brief Initialize all pragma handlers.
   void initializePragmaHandlers();
 

Modified: cfe/trunk/lib/Parse/ParseExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseExpr.cpp?rev=317032&r1=317031&r2=317032&view=diff
==
--- cfe/trunk/lib/Parse/ParseExpr.cpp (original)
+++ cfe/trunk/lib/Parse/ParseExpr.cpp Tue Oct 31 13:29:22 2017
@@ -266,11 +266,12 @@ bool Parser::diagnoseUnknownTemplateId(E
   return false;
 }
 
-static bool isFoldOperator(prec::Level Level) {
+bool Parser::isFoldOperator(prec::Level Level) const {
   return Level > prec::Unknown && Level != prec::Conditional;
 }
-static bool isFoldOperator(tok::TokenKind Kind) {
-  return isFoldOperator(getBinOpPrecedence(Kind, false, true));
+
+bool Parser::isFoldOperator(tok::TokenKind Kind) const {
+  return isFoldOperator(getBinOpPrecedence(Kind, GreaterThanIsOperator, true));
 }
 
 /// \brief Parse a binary expression that starts with \p LHS and has a

Modified: cfe/trunk/test/Parser/cxx1z-fold-expressions.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Parser/cxx1z-fold-expressions.cpp?rev=317032&r1=317031&r2=317032&view=diff
==
--- cfe/trunk/test/Parser/cxx1z-fold-expressions.cpp (original)
+++ cfe/trunk/test/Parser/cxx1z-fold-expressions.cpp Tue Oct 31 13:29:22 2017
@@ -43,3 +43,20 @@ template void as_operand_
 (int)(undeclared_junk + ...) + // expected-error {{undeclared}}
 (int)(a + ...); // expected-error {{does not contain any unexpanded}}
 }
+
+// fold-operator can be '>' or '>>'.
+template  constexpr bool greaterThan() { return (N > ...); }
+template  constexpr int rightShift() { return (N >> ...); }
+
+static_assert(greaterThan<2, 1>());
+static_assert(rightShift<10, 1>() == 5);
+
+template  constexpr auto Identity = V;
+
+// Support fold operators within templates.
+template  constexpr int nestedFoldOperator() {
+  return Identity<(Identity<0> >> ... >> N)> +
+Identity<(N >> ... >> Identity<0>)>;
+}
+
+static_assert(nestedFoldOperator<3, 1>() == 1);


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


[PATCH] D36101: Fix usage of right shift operator in fold expressions

2017-10-31 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith closed this revision.
rsmith added a comment.

Committed as r317032, thanks!


https://reviews.llvm.org/D36101



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


[PATCH] D39428: [Analyzer] As suggested, use value storage for BodyFarm

2017-10-31 Thread Anna Zaks via Phabricator via cfe-commits
zaks.anna added a comment.

> Also if you check the code snippets in the coding standard: 
> https://llvm.org/docs/CodingStandards.html#beware-unnecessary-copies-with-auto
>  you can see that where we officially put the references.

Correct! The reference should not go with the type name.
George, please, address the comments before committing.


https://reviews.llvm.org/D39428



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


[PATCH] D39462: [Sema] Implement -Wmaybe-tautological-constant-compare for when the tautologicalness is data model dependent

2017-10-31 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri updated this revision to Diff 121044.
lebedev.ri added a comment.

In https://reviews.llvm.org/D39462#912011, @rjmccall wrote:

> The actual choice of integer type is not stable across targets any more than 
> the size is.  In practice, people often don't use int and long, they use 
> standard typedefs like size_t and uint64_t, but the actual type chosen for 
> size_t is arbitrary when there are multiple types at that bit-width.


The internal canonical types are compared, so all this `typedef` sugar will be 
silently ignored.

> So I'm concerned that you're suppressing more than you think here and still 
> not going to satisfy people.

Possibly...
But it will at least make it easier to deal with the most common pattern "that 
obviously should not warn".
I'd love to hear better ideas

In https://reviews.llvm.org/D39462#912011, @rjmccall wrote:

> Also, "data model" is not a term in use.  Use "target" or "target platform".


Changed to `for the current target platform, ...`


Repository:
  rL LLVM

https://reviews.llvm.org/D39462

Files:
  docs/ReleaseNotes.rst
  include/clang/Basic/DiagnosticGroups.td
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Sema/SemaChecking.cpp
  test/Sema/maybe-tautological-constant-compare.c

Index: test/Sema/maybe-tautological-constant-compare.c
===
--- /dev/null
+++ test/Sema/maybe-tautological-constant-compare.c
@@ -0,0 +1,342 @@
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -fsyntax-only -DLP64 -Wmaybe-tautological-constant-compare -DTEST  -verify %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -fsyntax-only -DLP64 -verify %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -fsyntax-only -DLP64 -Wmaybe-tautological-constant-compare -DTEST -verify -x c++ %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -fsyntax-only -DLP64 -verify -x c++ %s
+// RUN: %clang_cc1 -triple i386-linux-gnu -fsyntax-only -DILP32 -Wmaybe-tautological-constant-compare -DTEST -verify %s
+// RUN: %clang_cc1 -triple i386-linux-gnu -fsyntax-only -DILP32 -verify %s
+// R1UN: %clang_cc1 -triple i386-linux-gnu -fsyntax-only -DILP32 -Wmaybe-tautological-constant-compare -DTEST -verify -x c++ %s
+// R1UN: %clang_cc1 -triple i386-linux-gnu -fsyntax-only -DILP32 -verify -x c++ %s
+
+int value(void);
+
+int main() {
+  unsigned long ul = value();
+
+#if defined(LP64)
+#if __SIZEOF_INT__ != 4
+#error Expecting 32-bit int
+#endif
+#if __SIZEOF_LONG__ != 8
+#error Expecting 64-bit int
+#endif
+#elif defined(ILP32)
+#if __SIZEOF_INT__ != 4
+#error Expecting 32-bit int
+#endif
+#if __SIZEOF_LONG__ != 4
+#error Expecting 32-bit int
+#endif
+#else
+#error LP64 or ILP32 should be defined
+#endif
+
+#if defined(LP64)
+  // expected-no-diagnostics
+
+  if (ul < 4294967295)
+return 0;
+  if (4294967295 >= ul)
+return 0;
+  if (ul > 4294967295)
+return 0;
+  if (4294967295 <= ul)
+return 0;
+  if (ul <= 4294967295)
+return 0;
+  if (4294967295 > ul)
+return 0;
+  if (ul >= 4294967295)
+return 0;
+  if (4294967295 < ul)
+return 0;
+  if (ul == 4294967295)
+return 0;
+  if (4294967295 != ul)
+return 0;
+  if (ul != 4294967295)
+return 0;
+  if (4294967295 == ul)
+return 0;
+
+  if (ul < 4294967295U)
+return 0;
+  if (4294967295U >= ul)
+return 0;
+  if (ul > 4294967295U)
+return 0;
+  if (4294967295U <= ul)
+return 0;
+  if (ul <= 4294967295U)
+return 0;
+  if (4294967295U > ul)
+return 0;
+  if (ul >= 4294967295U)
+return 0;
+  if (4294967295U < ul)
+return 0;
+  if (ul == 4294967295U)
+return 0;
+  if (4294967295U != ul)
+return 0;
+  if (ul != 4294967295U)
+return 0;
+  if (4294967295U == ul)
+return 0;
+
+  if (ul < 4294967295L)
+return 0;
+  if (4294967295L >= ul)
+return 0;
+  if (ul > 4294967295L)
+return 0;
+  if (4294967295L <= ul)
+return 0;
+  if (ul <= 4294967295L)
+return 0;
+  if (4294967295L > ul)
+return 0;
+  if (ul >= 4294967295L)
+return 0;
+  if (4294967295L < ul)
+return 0;
+  if (ul == 4294967295L)
+return 0;
+  if (4294967295L != ul)
+return 0;
+  if (ul != 4294967295L)
+return 0;
+  if (4294967295L == ul)
+return 0;
+
+  if (ul < 4294967295UL)
+return 0;
+  if (4294967295UL >= ul)
+return 0;
+  if (ul > 4294967295UL)
+return 0;
+  if (4294967295UL <= ul)
+return 0;
+  if (ul <= 4294967295UL)
+return 0;
+  if (4294967295UL > ul)
+return 0;
+  if (ul >= 4294967295UL)
+return 0;
+  if (4294967295UL < ul)
+return 0;
+  if (ul == 4294967295UL)
+return 0;
+  if (4294967295UL != ul)
+return 0;
+  if (ul != 4294967295UL)
+return 0;
+  if (4294967295UL == ul)
+return 0;
+#elif defined(ILP32)
+#if defined(TEST)
+  if (ul < 4294967295)
+return 0;
+  if (4294967295 >= ul) // expected-warning {{comparison 4294967295 >= 'unsigned long' is always true}}
+return 0;
+  if (ul > 4294967295) // expected-warning {{comparison 'unsigned long' > 4294967295 is 

[PATCH] D39445: [clang-fuzzer] Fix incremental builds of the fuzzer

2017-10-31 Thread Vitaly Buka via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL317035: [clang-fuzzer] Fix incremental builds of the fuzzer 
(authored by vitalybuka).

Changed prior to commit:
  https://reviews.llvm.org/D39445?vs=120926&id=121045#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D39445

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


Index: cfe/trunk/cmake/modules/ProtobufMutator.cmake
===
--- cfe/trunk/cmake/modules/ProtobufMutator.cmake
+++ cfe/trunk/cmake/modules/ProtobufMutator.cmake
@@ -1,23 +1,18 @@
 set(PBM_PREFIX protobuf_mutator)
 set(PBM_PATH ${CMAKE_CURRENT_BINARY_DIR}/${PBM_PREFIX}/src/${PBM_PREFIX})
-set(PBM_LIB_PATH ${PBM_PATH}/src/libprotobuf-mutator.a)
-set(PBM_FUZZ_LIB_PATH 
${PBM_PATH}/src/libfuzzer/libprotobuf-mutator-libfuzzer.a)
+set(PBM_LIB_PATH ${PBM_PATH}-build/src/libprotobuf-mutator.a)
+set(PBM_FUZZ_LIB_PATH 
${PBM_PATH}-build/src/libfuzzer/libprotobuf-mutator-libfuzzer.a)
 
 ExternalProject_Add(${PBM_PREFIX}
   PREFIX ${PBM_PREFIX}
   GIT_REPOSITORY https://github.com/google/libprotobuf-mutator.git
   GIT_TAG master
-  CONFIGURE_COMMAND ${CMAKE_COMMAND} -G${CMAKE_GENERATOR}
--DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
--DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}
--DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-  BUILD_COMMAND ${CMAKE_MAKE_PROGRAM}
+  CMAKE_ARGS -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
+  CMAKE_CACHE_ARGS -DCMAKE_C_COMPILER:FILEPATH=${CMAKE_C_COMPILER}
+   -DCMAKE_CXX_COMPILER:FILEPATH=${CMAKE_CXX_COMPILER}
   BUILD_BYPRODUCTS ${PBM_LIB_PATH} ${PBM_FUZZ_LIB_PATH}
-  BUILD_IN_SOURCE 1
+  UPDATE_COMMAND ""
   INSTALL_COMMAND ""
-  LOG_DOWNLOAD 1
-  LOG_CONFIGURE 1
-  LOG_BUILD 1
   )
 
 set(ProtobufMutator_INCLUDE_DIRS ${PBM_PATH})


Index: cfe/trunk/cmake/modules/ProtobufMutator.cmake
===
--- cfe/trunk/cmake/modules/ProtobufMutator.cmake
+++ cfe/trunk/cmake/modules/ProtobufMutator.cmake
@@ -1,23 +1,18 @@
 set(PBM_PREFIX protobuf_mutator)
 set(PBM_PATH ${CMAKE_CURRENT_BINARY_DIR}/${PBM_PREFIX}/src/${PBM_PREFIX})
-set(PBM_LIB_PATH ${PBM_PATH}/src/libprotobuf-mutator.a)
-set(PBM_FUZZ_LIB_PATH ${PBM_PATH}/src/libfuzzer/libprotobuf-mutator-libfuzzer.a)
+set(PBM_LIB_PATH ${PBM_PATH}-build/src/libprotobuf-mutator.a)
+set(PBM_FUZZ_LIB_PATH ${PBM_PATH}-build/src/libfuzzer/libprotobuf-mutator-libfuzzer.a)
 
 ExternalProject_Add(${PBM_PREFIX}
   PREFIX ${PBM_PREFIX}
   GIT_REPOSITORY https://github.com/google/libprotobuf-mutator.git
   GIT_TAG master
-  CONFIGURE_COMMAND ${CMAKE_COMMAND} -G${CMAKE_GENERATOR}
--DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
--DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}
--DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-  BUILD_COMMAND ${CMAKE_MAKE_PROGRAM}
+  CMAKE_ARGS -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
+  CMAKE_CACHE_ARGS -DCMAKE_C_COMPILER:FILEPATH=${CMAKE_C_COMPILER}
+   -DCMAKE_CXX_COMPILER:FILEPATH=${CMAKE_CXX_COMPILER}
   BUILD_BYPRODUCTS ${PBM_LIB_PATH} ${PBM_FUZZ_LIB_PATH}
-  BUILD_IN_SOURCE 1
+  UPDATE_COMMAND ""
   INSTALL_COMMAND ""
-  LOG_DOWNLOAD 1
-  LOG_CONFIGURE 1
-  LOG_BUILD 1
   )
 
 set(ProtobufMutator_INCLUDE_DIRS ${PBM_PATH})
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r317035 - [clang-fuzzer] Fix incremental builds of the fuzzer

2017-10-31 Thread Vitaly Buka via cfe-commits
Author: vitalybuka
Date: Tue Oct 31 13:49:57 2017
New Revision: 317035

URL: http://llvm.org/viewvc/llvm-project?rev=317035&view=rev
Log:
[clang-fuzzer] Fix incremental builds of the fuzzer

Summary:
Don't use BUILD_IN_SOURCE keep git checkout clean
Don't forward CMAKE_GENERATOR as ExternalProject_Add should do it already
Reset UPDATE_COMMAND to avoid git checkout updates on each build

Reviewers: kcc, morehouse

Subscribers: cfe-commits, mgorny

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

Modified:
cfe/trunk/cmake/modules/ProtobufMutator.cmake

Modified: cfe/trunk/cmake/modules/ProtobufMutator.cmake
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/modules/ProtobufMutator.cmake?rev=317035&r1=317034&r2=317035&view=diff
==
--- cfe/trunk/cmake/modules/ProtobufMutator.cmake (original)
+++ cfe/trunk/cmake/modules/ProtobufMutator.cmake Tue Oct 31 13:49:57 2017
@@ -1,23 +1,18 @@
 set(PBM_PREFIX protobuf_mutator)
 set(PBM_PATH ${CMAKE_CURRENT_BINARY_DIR}/${PBM_PREFIX}/src/${PBM_PREFIX})
-set(PBM_LIB_PATH ${PBM_PATH}/src/libprotobuf-mutator.a)
-set(PBM_FUZZ_LIB_PATH 
${PBM_PATH}/src/libfuzzer/libprotobuf-mutator-libfuzzer.a)
+set(PBM_LIB_PATH ${PBM_PATH}-build/src/libprotobuf-mutator.a)
+set(PBM_FUZZ_LIB_PATH 
${PBM_PATH}-build/src/libfuzzer/libprotobuf-mutator-libfuzzer.a)
 
 ExternalProject_Add(${PBM_PREFIX}
   PREFIX ${PBM_PREFIX}
   GIT_REPOSITORY https://github.com/google/libprotobuf-mutator.git
   GIT_TAG master
-  CONFIGURE_COMMAND ${CMAKE_COMMAND} -G${CMAKE_GENERATOR}
--DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
--DCMAKE_CXX_COMPILER=${CMAKE_CXX_COMPILER}
--DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
-  BUILD_COMMAND ${CMAKE_MAKE_PROGRAM}
+  CMAKE_ARGS -DCMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE}
+  CMAKE_CACHE_ARGS -DCMAKE_C_COMPILER:FILEPATH=${CMAKE_C_COMPILER}
+   -DCMAKE_CXX_COMPILER:FILEPATH=${CMAKE_CXX_COMPILER}
   BUILD_BYPRODUCTS ${PBM_LIB_PATH} ${PBM_FUZZ_LIB_PATH}
-  BUILD_IN_SOURCE 1
+  UPDATE_COMMAND ""
   INSTALL_COMMAND ""
-  LOG_DOWNLOAD 1
-  LOG_CONFIGURE 1
-  LOG_BUILD 1
   )
 
 set(ProtobufMutator_INCLUDE_DIRS ${PBM_PATH})


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


[PATCH] D39438: [analyzer] Diagnose stack leaks via block captures

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

Address the comments, add more tests


https://reviews.llvm.org/D39438

Files:
  lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp
  test/Analysis/stack-async-leak.m

Index: test/Analysis/stack-async-leak.m
===
--- test/Analysis/stack-async-leak.m
+++ test/Analysis/stack-async-leak.m
@@ -0,0 +1,113 @@
+// RUN: %clang_analyze_cc1 -triple x86_64-apple-darwin10 -analyzer-checker=core -fblocks -fobjc-arc -verify %s
+
+typedef struct dispatch_queue_s *dispatch_queue_t;
+typedef void (^dispatch_block_t)(void);
+void dispatch_async(dispatch_queue_t queue, dispatch_block_t block);
+typedef long dispatch_once_t;
+void dispatch_once(dispatch_once_t *predicate, dispatch_block_t block);
+typedef long dispatch_time_t;
+void dispatch_after(dispatch_time_t when, dispatch_queue_t queue, dispatch_block_t block);
+
+extern dispatch_queue_t queue;
+extern dispatch_once_t *predicate;
+extern dispatch_time_t when;
+
+void test_block_expr_async() {
+  int x = 123;
+  int *p = &x;
+
+  dispatch_async(queue, ^{
+*p = 321;
+  });
+  // expected-warning@-3 {{Address of stack memory associated with local variable 'x' \
+might leak via the block capture}}
+}
+
+void test_block_expr_once_no_leak() {
+  int x = 123;
+  int *p = &x;
+  // synchronous, no warning
+  dispatch_once(predicate, ^{
+*p = 321;
+  });
+}
+
+void test_block_expr_after() {
+  int x = 123;
+  int *p = &x;
+  dispatch_after(when, queue, ^{
+*p = 321;
+  });
+  // expected-warning@-3 {{Address of stack memory associated with local variable 'x' \
+might leak via the block capture}}
+}
+
+void test_block_expr_async_no_leak() {
+  int x = 123;
+  int *p = &x;
+  // no leak
+  dispatch_async(queue, ^{
+int y = x;
+++y;
+  });
+}
+
+void test_block_var_async() {
+  int x = 123;
+  int *p = &x;
+  void (^b)(void) = ^void(void) {
+*p = 1; 
+  };
+  dispatch_async(queue, b);
+  // expected-warning@-1 {{Address of stack memory associated with local variable 'x' \
+might leak via the block capture}}
+}
+
+dispatch_block_t get_leaking_block() {
+  int leaked_x = 791;
+  int *p = &leaked_x;
+  return ^void(void) {
+*p = 1; 
+  };
+  // expected-warning@-3 {{Address of stack memory associated with local variable 'leaked_x' \
+might leak via the block capture}}
+}
+
+void test_returned_from_func_block_async() {
+  dispatch_async(queue, get_leaking_block());
+  // expected-warning@-1 {{Address of stack memory associated with local variable 'leaked_x' \
+might leak via the block capture}}
+}
+
+// synchronous, no leak
+void test_block_var_once() {
+  int x = 123;
+  int *p = &x;
+  void (^b)(void) = ^void(void) {
+*p = 1; 
+  };
+  // no leak
+  dispatch_once(predicate, b);
+}
+
+void test_block_var_after() {
+  int x = 123;
+  int *p = &x;
+  void (^b)(void) = ^void(void) {
+*p = 1; 
+  };
+  dispatch_after(when, queue, b);
+  // expected-warning@-1 {{Address of stack memory associated with local variable 'x' \
+might leak via the block capture}}
+}
+
+void test_block_var_async_no_leak() {
+  int x = 123;
+  int *p = &x;
+  void (^b)(void) = ^void(void) {
+int y = x;
+++y; 
+  };
+  // no leak
+  dispatch_async(queue, b);
+}
Index: lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp
+++ lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp
@@ -18,23 +18,28 @@
 #include "clang/StaticAnalyzer/Core/BugReporter/BugType.h"
 #include "clang/StaticAnalyzer/Core/Checker.h"
 #include "clang/StaticAnalyzer/Core/CheckerManager.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/Support/raw_ostream.h"
 using namespace clang;
 using namespace ento;
 
 namespace {
-class StackAddrEscapeChecker : public Checker< check::PreStmt,
+class StackAddrEscapeChecker : public Checker< check::PreCall,
+   check::PreStmt,
check::EndFunction > {
   mutable std::unique_ptr BT_stackleak;
   mutable std::unique_ptr BT_returnstack;
+  mutable std::unique_ptr BT_capturestackleak;
 
 public:
+  void checkPreCall(const CallEvent &Call, CheckerContext &C) const;
   void checkPreStmt(const ReturnStmt *RS, CheckerContext &C) const;
   void checkEndFunction(CheckerContext &Ctx) const;
 private:
+  void checkBlockCaptures(const BlockDataRegion &B, CheckerContext &C) const;
   void EmitStackError(CheckerContext &C, const MemRegion *R,
   const Expr *RetE) const;
   static SourceRange genName(raw_ostream &os, const MemRegion *R,
@@ -84,17 +89,17 @@
 Ty.print(os, Ctx.getPrintingPolicy());
 os <<

[PATCH] D39149: [libc++] Prevent tautological comparisons

2017-10-31 Thread Shoaib Meenai via Phabricator via cfe-commits
smeenai abandoned this revision.
smeenai added a comment.

I confirmed that these warnings go away with https://reviews.llvm.org/D39462 
applied, and they reappear if I manually specify 
`-Wmaybe-tautological-constant-compare`. Thank you!


https://reviews.llvm.org/D39149



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


[PATCH] D39462: [Sema] Implement -Wmaybe-tautological-constant-compare for when the tautologicalness is data model dependent

2017-10-31 Thread Shoaib Meenai via Phabricator via cfe-commits
smeenai added a comment.

This solves the issue in https://reviews.llvm.org/D39149, at least.


Repository:
  rL LLVM

https://reviews.llvm.org/D39462



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


[PATCH] D39438: [analyzer] Diagnose stack leaks via block captures

2017-10-31 Thread Alexander Shaposhnikov via Phabricator via cfe-commits
alexshap added inline comments.



Comment at: test/Analysis/stack-async-leak.m:60
+  void (^b)(void) = ^void(void) {
+*p = 1; 
+  };

NoQ wrote:
> You may enjoy adding an extra note piece (as in D24278) to the offending 
> statement within the block. It might be helpful if it's not obvious which 
> block is being executed or which pointer points to the leaking variable.
> 
> Also it might be a good idea to think about a visitor that would track the 
> block pointer to highlight where it was initialized with a concrete block 
> code.
> 
> Though probably it's not super useful because we're most likely staying 
> within a single function with this checker.
> 
> By the way, do we warn (or want to warn) on returning a block from a 
> function, when this block captures a local variable?
regarding tracking - yeah, i agree, that would be good, although i would prefer 
to make progress incrementally and add this part later.

>By the way, do we warn (or want to warn) on returning a block from a function, 
>when this >block captures a local variable?
good question - yeah, now we do 


https://reviews.llvm.org/D39438



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


[PATCH] D39478: [clang-format] Handle leading comments in using declaration

2017-10-31 Thread Igor Sugak via Phabricator via cfe-commits
sugak created this revision.

This fixes clang-format internal assertion for the following code:

  /* override */ using std::string;

Added add a unit test.


https://reviews.llvm.org/D39478

Files:
  lib/Format/UsingDeclarationsSorter.cpp
  unittests/Format/UsingDeclarationsSorterTest.cpp


Index: unittests/Format/UsingDeclarationsSorterTest.cpp
===
--- unittests/Format/UsingDeclarationsSorterTest.cpp
+++ unittests/Format/UsingDeclarationsSorterTest.cpp
@@ -328,6 +328,13 @@
   {tooling::Range(19, 1)}));
 }
 
+TEST_F(UsingDeclarationsSorterTest, 
SortsUsingDeclarationsWithLeadingkComments) {
+  EXPECT_EQ("/* comment */ using a;\n"
+"/* comment */ using b;",
+sortUsingDeclarations("/* comment */ using b;\n"
+  "/* comment */ using a;"));
+}
+
 } // end namespace
 } // end namespace format
 } // end namespace clang
Index: lib/Format/UsingDeclarationsSorter.cpp
===
--- lib/Format/UsingDeclarationsSorter.cpp
+++ lib/Format/UsingDeclarationsSorter.cpp
@@ -133,15 +133,18 @@
   tooling::Replacements Fixes;
   SmallVector UsingDeclarations;
   for (size_t I = 0, E = AnnotatedLines.size(); I != E; ++I) {
+auto FirstTok = AnnotatedLines[I]->First;
 if (AnnotatedLines[I]->InPPDirective ||
-!AnnotatedLines[I]->startsWith(tok::kw_using) ||
-AnnotatedLines[I]->First->Finalized) {
+!AnnotatedLines[I]->startsWith(tok::kw_using) || FirstTok->Finalized) {
   endUsingDeclarationBlock(&UsingDeclarations, SourceMgr, &Fixes);
   continue;
 }
-if (AnnotatedLines[I]->First->NewlinesBefore > 1)
+if (FirstTok->NewlinesBefore > 1) {
   endUsingDeclarationBlock(&UsingDeclarations, SourceMgr, &Fixes);
-std::string Label = computeUsingDeclarationLabel(AnnotatedLines[I]->First);
+}
+auto UsingTok =
+FirstTok->is(tok::comment) ? FirstTok->getNextNonComment() : FirstTok;
+std::string Label = computeUsingDeclarationLabel(UsingTok);
 if (Label.empty()) {
   endUsingDeclarationBlock(&UsingDeclarations, SourceMgr, &Fixes);
   continue;


Index: unittests/Format/UsingDeclarationsSorterTest.cpp
===
--- unittests/Format/UsingDeclarationsSorterTest.cpp
+++ unittests/Format/UsingDeclarationsSorterTest.cpp
@@ -328,6 +328,13 @@
   {tooling::Range(19, 1)}));
 }
 
+TEST_F(UsingDeclarationsSorterTest, SortsUsingDeclarationsWithLeadingkComments) {
+  EXPECT_EQ("/* comment */ using a;\n"
+"/* comment */ using b;",
+sortUsingDeclarations("/* comment */ using b;\n"
+  "/* comment */ using a;"));
+}
+
 } // end namespace
 } // end namespace format
 } // end namespace clang
Index: lib/Format/UsingDeclarationsSorter.cpp
===
--- lib/Format/UsingDeclarationsSorter.cpp
+++ lib/Format/UsingDeclarationsSorter.cpp
@@ -133,15 +133,18 @@
   tooling::Replacements Fixes;
   SmallVector UsingDeclarations;
   for (size_t I = 0, E = AnnotatedLines.size(); I != E; ++I) {
+auto FirstTok = AnnotatedLines[I]->First;
 if (AnnotatedLines[I]->InPPDirective ||
-!AnnotatedLines[I]->startsWith(tok::kw_using) ||
-AnnotatedLines[I]->First->Finalized) {
+!AnnotatedLines[I]->startsWith(tok::kw_using) || FirstTok->Finalized) {
   endUsingDeclarationBlock(&UsingDeclarations, SourceMgr, &Fixes);
   continue;
 }
-if (AnnotatedLines[I]->First->NewlinesBefore > 1)
+if (FirstTok->NewlinesBefore > 1) {
   endUsingDeclarationBlock(&UsingDeclarations, SourceMgr, &Fixes);
-std::string Label = computeUsingDeclarationLabel(AnnotatedLines[I]->First);
+}
+auto UsingTok =
+FirstTok->is(tok::comment) ? FirstTok->getNextNonComment() : FirstTok;
+std::string Label = computeUsingDeclarationLabel(UsingTok);
 if (Label.empty()) {
   endUsingDeclarationBlock(&UsingDeclarations, SourceMgr, &Fixes);
   continue;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D39478: [clang-format] Handle leading comments in using declaration

2017-10-31 Thread Igor Sugak via Phabricator via cfe-commits
sugak added inline comments.



Comment at: lib/Format/UsingDeclarationsSorter.cpp:50
 std::string computeUsingDeclarationLabel(const FormatToken *UsingTok) {
   assert(UsingTok && UsingTok->is(tok::kw_using) && "Expecting a using token");
   std::string Label;

and this is the assertions that fails for the code referenced in the summary.


https://reviews.llvm.org/D39478



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


[PATCH] D39481: [CodeGen] fix const-ness of builtin equivalents of and functions that might set errno

2017-10-31 Thread Sanjay Patel via Phabricator via cfe-commits
spatel created this revision.
Herald added a subscriber: mcrosier.

As the description in Builtins.def says: "e = const, but only when 
-fmath-errno=0".

This is step 2 of 3 to fix builtins and math calls as discussed in 
https://reviews.llvm.org/D39204.

I went through the lists at:
http://en.cppreference.com/w/c/numeric/math
http://en.cppreference.com/w/c/numeric/complex
...and changed all of the builtins that correspond to functions that could set 
errno.

The math.h functions that are specified to never set errno are:
fmax
fmin
nearbyint

And for complex.h:
creal
cimag
conj
cproj

powi is not a standard libm function, so that's also left as "Fnc".


https://reviews.llvm.org/D39481

Files:
  include/clang/Basic/Builtins.def
  lib/CodeGen/CGBuiltin.cpp
  test/CodeGen/builtin-sqrt.c

Index: test/CodeGen/builtin-sqrt.c
===
--- test/CodeGen/builtin-sqrt.c
+++ test/CodeGen/builtin-sqrt.c
@@ -1,18 +1,16 @@
 // RUN: %clang_cc1 -fmath-errno -triple x86_64-apple-darwin %s -emit-llvm -o - | FileCheck %s --check-prefix=HAS_ERRNO
 // RUN: %clang_cc1  -triple x86_64-apple-darwin %s -emit-llvm -o - | FileCheck %s --check-prefix=NO_ERRNO
 
-// FIXME: If a builtin is supposed to have identical semantics to its libm twin, then it
-// should not be marked "constant" in Builtins.def because that means it can't set errno.
-// Note that both runs have 'readnone' on the libcall here.
+// FIXME: If the builtin does not set errno, it should be converted to an LLVM intrinsic.
 
 float foo(float X) {
   // HAS_ERRNO: call float @sqrtf(float
   // NO_ERRNO: call float @sqrtf(float
   return __builtin_sqrtf(X);
 }
 
 // HAS_ERRNO: declare float @sqrtf(float) [[ATTR:#[0-9]+]]
-// HAS_ERRNO: attributes [[ATTR]] = { nounwind readnone {{.*}}}
+// HAS_ERRNO-NOT: attributes [[ATTR]] = {{{.*}} readnone
 
 // NO_ERRNO: declare float @sqrtf(float) [[ATTR:#[0-9]+]]
 // NO_ERRNO: attributes [[ATTR]] = { nounwind readnone {{.*}}}
Index: lib/CodeGen/CGBuiltin.cpp
===
--- lib/CodeGen/CGBuiltin.cpp
+++ lib/CodeGen/CGBuiltin.cpp
@@ -2080,10 +2080,7 @@
 // errno. Thus, we can transform either sqrt or __builtin_sqrt to @llvm.sqrt
 // if the call is 'const' (the call must not set errno).
 //
-// FIXME: The builtin cases are not here because they are marked 'const' in
-// Builtins.def. So that means they are wrongly defined to have different
-// semantics than the library functions. If we included them here, we would
-// turn them into LLVM intrinsics regardless of whether -fmath-errno was on.
+// FIXME: The cases for __builtin_sqrt* should be here too.
 if (FD->hasAttr())
   return RValue::get(emitUnaryBuiltin(*this, E, Intrinsic::sqrt));
 break;
Index: include/clang/Basic/Builtins.def
===
--- include/clang/Basic/Builtins.def
+++ include/clang/Basic/Builtins.def
@@ -103,19 +103,19 @@
 #endif
 
 // Standard libc/libm functions:
-BUILTIN(__builtin_atan2 , "ddd"  , "Fnc")
-BUILTIN(__builtin_atan2f, "fff"  , "Fnc")
-BUILTIN(__builtin_atan2l, "LdLdLd", "Fnc")
+BUILTIN(__builtin_atan2 , "ddd"  , "Fne")
+BUILTIN(__builtin_atan2f, "fff"  , "Fne")
+BUILTIN(__builtin_atan2l, "LdLdLd", "Fne")
 BUILTIN(__builtin_abs  , "ii"  , "ncF")
 BUILTIN(__builtin_copysign, "ddd", "ncF")
 BUILTIN(__builtin_copysignf, "fff", "ncF")
 BUILTIN(__builtin_copysignl, "LdLdLd", "ncF")
 BUILTIN(__builtin_fabs , "dd"  , "ncF")
 BUILTIN(__builtin_fabsf, "ff"  , "ncF")
 BUILTIN(__builtin_fabsl, "LdLd", "ncF")
-BUILTIN(__builtin_fmod , "ddd"  , "Fnc")
-BUILTIN(__builtin_fmodf, "fff"  , "Fnc")
-BUILTIN(__builtin_fmodl, "LdLdLd", "Fnc")
+BUILTIN(__builtin_fmod , "ddd"  , "Fne")
+BUILTIN(__builtin_fmodf, "fff"  , "Fne")
+BUILTIN(__builtin_fmodl, "LdLdLd", "Fne")
 BUILTIN(__builtin_frexp , "ddi*"  , "Fn")
 BUILTIN(__builtin_frexpf, "ffi*"  , "Fn")
 BUILTIN(__builtin_frexpl, "LdLdi*", "Fn")
@@ -127,9 +127,9 @@
 BUILTIN(__builtin_infl , "Ld"  , "nc")
 BUILTIN(__builtin_labs , "LiLi"  , "Fnc")
 BUILTIN(__builtin_llabs, "LLiLLi", "Fnc")
-BUILTIN(__builtin_ldexp , "ddi"  , "Fnc")
-BUILTIN(__builtin_ldexpf, "ffi"  , "Fnc")
-BUILTIN(__builtin_ldexpl, "LdLdi", "Fnc")
+BUILTIN(__builtin_ldexp , "ddi"  , "Fne")
+BUILTIN(__builtin_ldexpf, "ffi"  , "Fne")
+BUILTIN(__builtin_ldexpl, "LdLdi", "Fne")
 BUILTIN(__builtin_modf , "ddd*"  , "Fn")
 BUILTIN(__builtin_modff, "fff*"  , "Fn")
 BUILTIN(__builtin_modfl, "LdLdLd*", "Fn")
@@ -142,223 +142,223 @@
 BUILTIN(__builtin_powi , "ddi"  , "Fnc")
 BUILTIN(__builtin_powif, "ffi"  , "Fnc")
 BUILTIN(__builtin_powil, "LdLdi", "Fnc")
-BUILTIN(__builtin_pow , "ddd"  , "Fnc")
-BUILTIN(__builtin_powf, "fff"  , "Fnc")
-BUILTIN(__builtin_powl, "LdLdLd", "Fnc")
+BUILTIN(__builtin_pow , "ddd"  , "Fne")
+BUILTIN(__builtin_powf, "fff"  , "Fne")
+BUILTIN(__builtin_powl, "LdLdLd", "Fne")
 
 // Standard unary libc/libm functions with 

r317044 - [CFI] Add CFI-icall pointer type generalization

2017-10-31 Thread Vlad Tsyrklevich via cfe-commits
Author: vlad.tsyrklevich
Date: Tue Oct 31 15:39:44 2017
New Revision: 317044

URL: http://llvm.org/viewvc/llvm-project?rev=317044&view=rev
Log:
[CFI] Add CFI-icall pointer type generalization

Summary:
This change allows generalizing pointers in type signatures used for
cfi-icall by enabling the -fsanitize-cfi-icall-generalize-pointers flag.
This works by 1) emitting an additional generalized type signature
metadata node for functions and 2) llvm.type.test()ing for the
generalized type for translation units with the flag specified.

This flag is incompatible with -fsanitize-cfi-cross-dso because it would
require emitting twice as many type hashes which would increase artifact
size.

Reviewers: pcc, eugenis

Reviewed By: pcc

Subscribers: kcc

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

Added:
cfe/trunk/test/CodeGen/cfi-icall-generalize.c
Modified:
cfe/trunk/docs/ClangCommandLineReference.rst
cfe/trunk/docs/ControlFlowIntegrity.rst
cfe/trunk/docs/UsersManual.rst
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/include/clang/Driver/SanitizerArgs.h
cfe/trunk/include/clang/Frontend/CodeGenOptions.def
cfe/trunk/lib/CodeGen/CGExpr.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.h
cfe/trunk/lib/Driver/SanitizerArgs.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/CodeGen/cfi-icall-cross-dso.c
cfe/trunk/test/CodeGen/cfi-icall.c
cfe/trunk/test/CodeGenCXX/cfi-icall.cpp
cfe/trunk/test/Driver/fsanitize.c

Modified: cfe/trunk/docs/ClangCommandLineReference.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ClangCommandLineReference.rst?rev=317044&r1=317043&r2=317044&view=diff
==
--- cfe/trunk/docs/ClangCommandLineReference.rst (original)
+++ cfe/trunk/docs/ClangCommandLineReference.rst Tue Oct 31 15:39:44 2017
@@ -740,6 +740,10 @@ Path to blacklist file for sanitizers
 
 Enable control flow integrity (CFI) checks for cross-DSO calls.
 
+.. option:: -fsanitize-cfi-icall-generalize-pointers
+
+Generalize pointers in function type signatures used for Control Flow 
Integrity (CFI) indirect call checking
+
 .. option:: -fsanitize-coverage=,..., 
-fno-sanitize-coverage=,...
 
 Specify the type of coverage instrumentation for Sanitizers

Modified: cfe/trunk/docs/ControlFlowIntegrity.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ControlFlowIntegrity.rst?rev=317044&r1=317043&r2=317044&view=diff
==
--- cfe/trunk/docs/ControlFlowIntegrity.rst (original)
+++ cfe/trunk/docs/ControlFlowIntegrity.rst Tue Oct 31 15:39:44 2017
@@ -215,6 +215,23 @@ shared library boundaries are handled as
 
 This scheme is currently only supported on the x86 and x86_64 architectures.
 
+``-fsanitize-cfi-icall-generalize-pointers``
+
+
+Mismatched pointer types are a common cause of cfi-icall check failures.
+Translation units compiled with the 
``-fsanitize-cfi-icall-generalize-pointers``
+flag relax pointer type checking for call sites in that translation unit,
+applied across all functions compiled with ``-fsanitize=cfi-icall``.
+
+Specifically, pointers in return and argument types are treated as equivalent 
as
+long as the qualifiers for the type they point to match. For example, ``char*``
+``char**`, and ``int*`` are considered equivalent types. However, ``char*`` and
+``const char*`` are considered separate types.
+
+``-fsanitize-cfi-icall-generalize-pointers`` is not compatible with
+``-fsanitize-cfi-cross-dso``.
+
+
 ``-fsanitize=cfi-icall`` and ``-fsanitize=function``
 
 

Modified: cfe/trunk/docs/UsersManual.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=317044&r1=317043&r2=317044&view=diff
==
--- cfe/trunk/docs/UsersManual.rst (original)
+++ cfe/trunk/docs/UsersManual.rst Tue Oct 31 15:39:44 2017
@@ -1147,6 +1147,11 @@ are listed below.
the behavior of sanitizers in the ``cfi`` group to allow checking
of cross-DSO virtual and indirect calls.
 
+.. option:: -fsanitize-cfi-icall-generalize-pointers
+
+   Generalize pointers in return and argument types in function type signatures
+   checked by Control Flow Integrity indirect call checking. See
+   :doc:`ControlFlowIntegrity` for more details.
 
 .. option:: -fstrict-vtable-pointers
 

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=317044&r1=317043&r2=317044&view=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Tue Oct 31 15:39:44 2017
@@ -914,6 +914,9 @@ def 

r317047 - Fix for PR33930. Short-circuit metadata mapping when cloning a varargs thunk.

2017-10-31 Thread Wolfgang Pieb via cfe-commits
Author: wolfgangp
Date: Tue Oct 31 15:49:48 2017
New Revision: 317047

URL: http://llvm.org/viewvc/llvm-project?rev=317047&view=rev
Log:
Fix for PR33930. Short-circuit metadata mapping when cloning a varargs thunk.
The cloning happens before all metadata nodes are resolved. Prevent the value
mapper from running into unresolved or temporary MD nodes.

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

Added:
cfe/trunk/test/CodeGenCXX/tmp-md-nodes1.cpp
cfe/trunk/test/CodeGenCXX/tmp-md-nodes2.cpp
Modified:
cfe/trunk/lib/CodeGen/CGVTables.cpp

Modified: cfe/trunk/lib/CodeGen/CGVTables.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGVTables.cpp?rev=317047&r1=317046&r2=317047&view=diff
==
--- cfe/trunk/lib/CodeGen/CGVTables.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGVTables.cpp Tue Oct 31 15:49:48 2017
@@ -14,11 +14,12 @@
 #include "CGCXXABI.h"
 #include "CodeGenFunction.h"
 #include "CodeGenModule.h"
-#include "clang/CodeGen/ConstantInitBuilder.h"
 #include "clang/AST/CXXInheritance.h"
 #include "clang/AST/RecordLayout.h"
 #include "clang/CodeGen/CGFunctionInfo.h"
+#include "clang/CodeGen/ConstantInitBuilder.h"
 #include "clang/Frontend/CodeGenOptions.h"
+#include "llvm/IR/IntrinsicInst.h"
 #include "llvm/Support/Format.h"
 #include "llvm/Transforms/Utils/Cloning.h"
 #include 
@@ -122,6 +123,33 @@ static RValue PerformReturnAdjustment(Co
   return RValue::get(ReturnValue);
 }
 
+/// This function clones a function's DISubprogram node and enters it into 
+/// a value map with the intent that the map can be utilized by the cloner
+/// to short-circuit Metadata node mapping.
+/// Furthermore, the function resolves any DILocalVariable nodes referenced
+/// by dbg.value intrinsics so they can be properly mapped during cloning.
+static void resolveTopLevelMetadata(llvm::Function *Fn,
+llvm::ValueToValueMapTy &VMap) {
+  // Clone the DISubprogram node and put it into the Value map.
+  auto *DIS = Fn->getSubprogram();
+  if (!DIS)
+return;
+  auto *NewDIS = DIS->replaceWithDistinct(DIS->clone());
+  VMap.MD()[DIS].reset(NewDIS);
+
+  // Find all llvm.dbg.declare intrinsics and resolve the DILocalVariable nodes
+  // they are referencing.
+  for (auto &BB : Fn->getBasicBlockList()) {
+for (auto &I : BB) {
+  if (auto *DII = dyn_cast(&I)) {
+auto *DILocal = DII->getVariable();
+if (!DILocal->isResolved())
+  DILocal->resolve();
+  }
+}
+  }
+}
+
 // This function does roughly the same thing as GenerateThunk, but in a
 // very different way, so that va_start and va_end work correctly.
 // FIXME: This function assumes "this" is the first non-sret LLVM argument of
@@ -154,6 +182,10 @@ CodeGenFunction::GenerateVarArgsThunk(ll
 
   // Clone to thunk.
   llvm::ValueToValueMapTy VMap;
+
+  // We are cloning a function while some Metadata nodes are still unresolved.
+  // Ensure that the value mapper does not encounter any of them.
+  resolveTopLevelMetadata(BaseFn, VMap);
   llvm::Function *NewFn = llvm::CloneFunction(BaseFn, VMap);
   Fn->replaceAllUsesWith(NewFn);
   NewFn->takeName(Fn);

Added: cfe/trunk/test/CodeGenCXX/tmp-md-nodes1.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/tmp-md-nodes1.cpp?rev=317047&view=auto
==
--- cfe/trunk/test/CodeGenCXX/tmp-md-nodes1.cpp (added)
+++ cfe/trunk/test/CodeGenCXX/tmp-md-nodes1.cpp Tue Oct 31 15:49:48 2017
@@ -0,0 +1,18 @@
+// REQUIRES: asserts
+// RUN: %clang_cc1 -O0 -triple %itanium_abi_triple -debug-info-kind=limited -S 
-emit-llvm %s -o - | \
+// RUN: FileCheck %s
+
+// This test simply checks that the varargs thunk is created. The failing test
+// case asserts.
+
+struct Alpha {
+  virtual void bravo(...);
+};
+struct Charlie {
+  virtual ~Charlie() {}
+};
+struct CharlieImpl : Charlie, Alpha {
+  void bravo(...) {}
+} delta;
+
+// CHECK: define {{.*}} void @_ZThn8_N11CharlieImpl5bravoEz(

Added: cfe/trunk/test/CodeGenCXX/tmp-md-nodes2.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/tmp-md-nodes2.cpp?rev=317047&view=auto
==
--- cfe/trunk/test/CodeGenCXX/tmp-md-nodes2.cpp (added)
+++ cfe/trunk/test/CodeGenCXX/tmp-md-nodes2.cpp Tue Oct 31 15:49:48 2017
@@ -0,0 +1,33 @@
+// REQUIRES: asserts
+// RUN: %clang_cc1 -O0 -triple %itanium_abi_triple -debug-info-kind=limited -S 
-emit-llvm %s -o - | \
+// RUN: FileCheck %s
+
+// This test simply checks that the varargs thunk is created. The failing test
+// case asserts.
+
+typedef signed char __int8_t;
+typedef int BOOL;
+class CMsgAgent;
+
+class CFs {
+public:
+  typedef enum {} CACHE_HINT;
+  virtual BOOL ReqCacheHint( CMsgAgent* p_ma, CACHE_HINT hint, ... ) ;
+};
+
+typedef struct {} _Lldiv_t;
+
+class CBdVfs {
+public:
+  virtual ~CBdVfs( ) {}
+

[PATCH] D39396: Fix for PR33930. Short-circuit metadata mapping when cloning a varargs thunk.

2017-10-31 Thread Wolfgang Pieb via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL317047: Fix for PR33930. Short-circuit metadata mapping when 
cloning a varargs thunk. (authored by wolfgangp).

Changed prior to commit:
  https://reviews.llvm.org/D39396?vs=120876&id=121078#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D39396

Files:
  cfe/trunk/lib/CodeGen/CGVTables.cpp
  cfe/trunk/test/CodeGenCXX/tmp-md-nodes1.cpp
  cfe/trunk/test/CodeGenCXX/tmp-md-nodes2.cpp

Index: cfe/trunk/test/CodeGenCXX/tmp-md-nodes2.cpp
===
--- cfe/trunk/test/CodeGenCXX/tmp-md-nodes2.cpp
+++ cfe/trunk/test/CodeGenCXX/tmp-md-nodes2.cpp
@@ -0,0 +1,33 @@
+// REQUIRES: asserts
+// RUN: %clang_cc1 -O0 -triple %itanium_abi_triple -debug-info-kind=limited -S -emit-llvm %s -o - | \
+// RUN: FileCheck %s
+
+// This test simply checks that the varargs thunk is created. The failing test
+// case asserts.
+
+typedef signed char __int8_t;
+typedef int BOOL;
+class CMsgAgent;
+
+class CFs {
+public:
+  typedef enum {} CACHE_HINT;
+  virtual BOOL ReqCacheHint( CMsgAgent* p_ma, CACHE_HINT hint, ... ) ;
+};
+
+typedef struct {} _Lldiv_t;
+
+class CBdVfs {
+public:
+  virtual ~CBdVfs( ) {}
+};
+
+class CBdVfsImpl : public CBdVfs, public CFs {
+  BOOL ReqCacheHint( CMsgAgent* p_ma, CACHE_HINT hint, ... );
+};
+
+BOOL CBdVfsImpl::ReqCacheHint( CMsgAgent* p_ma, CACHE_HINT hint, ... ) {
+  return true;
+}
+
+// CHECK: define {{.*}} @_ZThn8_N10CBdVfsImpl12ReqCacheHintEP9CMsgAgentN3CFs10CACHE_HINTEz(
Index: cfe/trunk/test/CodeGenCXX/tmp-md-nodes1.cpp
===
--- cfe/trunk/test/CodeGenCXX/tmp-md-nodes1.cpp
+++ cfe/trunk/test/CodeGenCXX/tmp-md-nodes1.cpp
@@ -0,0 +1,18 @@
+// REQUIRES: asserts
+// RUN: %clang_cc1 -O0 -triple %itanium_abi_triple -debug-info-kind=limited -S -emit-llvm %s -o - | \
+// RUN: FileCheck %s
+
+// This test simply checks that the varargs thunk is created. The failing test
+// case asserts.
+
+struct Alpha {
+  virtual void bravo(...);
+};
+struct Charlie {
+  virtual ~Charlie() {}
+};
+struct CharlieImpl : Charlie, Alpha {
+  void bravo(...) {}
+} delta;
+
+// CHECK: define {{.*}} void @_ZThn8_N11CharlieImpl5bravoEz(
Index: cfe/trunk/lib/CodeGen/CGVTables.cpp
===
--- cfe/trunk/lib/CodeGen/CGVTables.cpp
+++ cfe/trunk/lib/CodeGen/CGVTables.cpp
@@ -14,11 +14,12 @@
 #include "CGCXXABI.h"
 #include "CodeGenFunction.h"
 #include "CodeGenModule.h"
-#include "clang/CodeGen/ConstantInitBuilder.h"
 #include "clang/AST/CXXInheritance.h"
 #include "clang/AST/RecordLayout.h"
 #include "clang/CodeGen/CGFunctionInfo.h"
+#include "clang/CodeGen/ConstantInitBuilder.h"
 #include "clang/Frontend/CodeGenOptions.h"
+#include "llvm/IR/IntrinsicInst.h"
 #include "llvm/Support/Format.h"
 #include "llvm/Transforms/Utils/Cloning.h"
 #include 
@@ -122,6 +123,33 @@
   return RValue::get(ReturnValue);
 }
 
+/// This function clones a function's DISubprogram node and enters it into 
+/// a value map with the intent that the map can be utilized by the cloner
+/// to short-circuit Metadata node mapping.
+/// Furthermore, the function resolves any DILocalVariable nodes referenced
+/// by dbg.value intrinsics so they can be properly mapped during cloning.
+static void resolveTopLevelMetadata(llvm::Function *Fn,
+llvm::ValueToValueMapTy &VMap) {
+  // Clone the DISubprogram node and put it into the Value map.
+  auto *DIS = Fn->getSubprogram();
+  if (!DIS)
+return;
+  auto *NewDIS = DIS->replaceWithDistinct(DIS->clone());
+  VMap.MD()[DIS].reset(NewDIS);
+
+  // Find all llvm.dbg.declare intrinsics and resolve the DILocalVariable nodes
+  // they are referencing.
+  for (auto &BB : Fn->getBasicBlockList()) {
+for (auto &I : BB) {
+  if (auto *DII = dyn_cast(&I)) {
+auto *DILocal = DII->getVariable();
+if (!DILocal->isResolved())
+  DILocal->resolve();
+  }
+}
+  }
+}
+
 // This function does roughly the same thing as GenerateThunk, but in a
 // very different way, so that va_start and va_end work correctly.
 // FIXME: This function assumes "this" is the first non-sret LLVM argument of
@@ -154,6 +182,10 @@
 
   // Clone to thunk.
   llvm::ValueToValueMapTy VMap;
+
+  // We are cloning a function while some Metadata nodes are still unresolved.
+  // Ensure that the value mapper does not encounter any of them.
+  resolveTopLevelMetadata(BaseFn, VMap);
   llvm::Function *NewFn = llvm::CloneFunction(BaseFn, VMap);
   Fn->replaceAllUsesWith(NewFn);
   NewFn->takeName(Fn);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D39050: Add index-while-building support to Clang

2017-10-31 Thread Alex Lorenz via Phabricator via cfe-commits
arphaman added inline comments.



Comment at: include/clang/Index/IndexDataStoreSymbolUtils.h:13
+
+#include "indexstore/indexstore.h"
+#include "clang/Index/IndexSymbol.h"

It looks to me like this header, `"indexstore/indexstore.h"`, and 
`IndexDataStoreUtils.cpp` are utilities just for the C API, so could we take it 
out of here as well?



Comment at: lib/Driver/ToolChains/Clang.cpp:3597
+
+  if (const char *IdxStorePath = ::getenv("CLANG_PROJECT_INDEX_PATH")) {
+CmdArgs.push_back("-index-store-path");

What is this environment variable used for? And why does it imply the other two 
flags? 



Comment at: lib/Frontend/CompilerInstance.cpp:1153
+  // Pass along the GenModuleActionWrapper callback
+  auto wrapGenModuleAction = ImportingInstance.getGenModuleActionWrapper();
+  Instance.setGenModuleActionWrapper(wrapGenModuleAction);

Please start your variable names with uppercase 
(http://llvm.org/docs/CodingStandards.html#name-types-functions-variables-and-enumerators-properly).



Comment at: lib/Index/IndexRecordHasher.cpp:103
+  COMBINE_HASH(Hasher.hash(param->getType()));
+}
+return Hash;

Should you hash the return type as well?



Comment at: lib/Index/IndexRecordHasher.cpp:137
+Loc = SM.getFileLoc(Loc);
+const std::pair &Decomposed = SM.getDecomposedLoc(Loc);
+const FileEntry *FE = SM.getFileEntryForID(Decomposed.first);

No need to use a reference type here.



Comment at: lib/Index/IndexRecordHasher.cpp:146
+if (IncludeOffset) {
+  // Use the offest into the FileID to represent the location.  Using
+  // a line/column can cause us to look back at the original source file,

offset



Comment at: lib/Index/IndexRecordHasher.cpp:204
+if (Q.hasConst())
+  qVal |= 0x1;
+if (Q.hasVolatile())

You can use `Qualifiers::Const` here or make your own enum instead of raw 
constants.



Comment at: lib/Index/IndexRecordHasher.cpp:255
+  continue;
+}
+

There are other types in Clang which aren't hashed it seems. Can you add a 
general FIXME for them here?



Comment at: lib/Index/IndexRecordWriter.cpp:278
+  // Write the record header.
+  auto *State = new RecordState(RecordPath.str());
+  Record = State;

It might be better to forward declare `RecordState` in the header, use 
`unique_ptr` field instead of `void *` in the class and use 
`llvm::make_unique` here. Then you can remove the `ScopedDelete` RAII struct in 
the next function.



Comment at: lib/Index/IndexUnitWriter.cpp:30
+
+class IndexUnitWriter::PathStorage {
+  std::string WorkDir;

What is this class responsible for?



Comment at: lib/Index/IndexingAction.cpp:686
+if (RecordWriter.writeRecord(FE->getName(), Rec, Error, &RecordFile)) {
+  unsigned DiagID = Diag.getCustomDiagID(DiagnosticsEngine::Error,
+ "failed writing record '%0': %1");

We might want to start using a new diagnostic group for index-while-building 
errors instead of the custom ones.



Comment at: lib/Index/IndexingContext.cpp:162
+  // treated as system one.
+  if (path == "/")
+path = StringRef();

It might be worth investigating if you can use any of the LLVM's path APIs here 
instead of doing a UNIX-specific check.


https://reviews.llvm.org/D39050



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


[PATCH] D39481: [CodeGen] fix const-ness of builtin equivalents of and functions that might set errno

2017-10-31 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added a comment.

Please make these consistent with the non-__builtin versions.

Granted, I'm not sure all of those are right... I'm pretty sure, for example, 
cbrt can't set errno, and carg can.  But I'd prefer to deal with that in a 
separate patch.


https://reviews.llvm.org/D39481



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


r317052 - Make helper function static. NFC.

2017-10-31 Thread Benjamin Kramer via cfe-commits
Author: d0k
Date: Tue Oct 31 16:23:36 2017
New Revision: 317052

URL: http://llvm.org/viewvc/llvm-project?rev=317052&view=rev
Log:
Make helper function static. NFC.

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

Modified: cfe/trunk/lib/AST/Type.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Type.cpp?rev=317052&r1=317051&r2=317052&view=diff
==
--- cfe/trunk/lib/AST/Type.cpp (original)
+++ cfe/trunk/lib/AST/Type.cpp Tue Oct 31 16:23:36 2017
@@ -2182,7 +2182,7 @@ bool QualType::unionHasUniqueObjectRepre
   return true;
 }
 
-bool isStructEmpty(QualType Ty) {
+static bool isStructEmpty(QualType Ty) {
   assert(Ty.getTypePtr()->isStructureOrClassType() &&
  "Must be struct or class");
   const RecordDecl *RD = Ty.getTypePtr()->getAs()->getDecl();


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


[PATCH] D39462: [Sema] Implement -Wmaybe-tautological-constant-compare for when the tautologicalness is data model dependent

2017-10-31 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added a comment.

> The internal canonical types are compared, so all this typedef sugar will be 
> silently ignored.

Yes, and that's precisely the problem.  On many 32-bit platforms, both "size_t" 
and "uint32_t" are typedefs for "unsigned int"; on some 32-bit platforms, 
"size_t" is an "unsigned long".  So whether this patch suppresses the warning 
for a comparison between size_t and uint32_t depends on the target ABI.


Repository:
  rL LLVM

https://reviews.llvm.org/D39462



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


[PATCH] D39050: Add index-while-building support to Clang

2017-10-31 Thread Nathan Hawes via Phabricator via cfe-commits
nathawes planned changes to this revision.
nathawes added a comment.

Thanks @arphaman! I'll work through your comments and update.




Comment at: include/clang/Index/IndexDataStoreSymbolUtils.h:13
+
+#include "indexstore/indexstore.h"
+#include "clang/Index/IndexSymbol.h"

arphaman wrote:
> It looks to me like this header, `"indexstore/indexstore.h"`, and 
> `IndexDataStoreUtils.cpp` are utilities just for the C API, so could we take 
> it out of here as well?
They're used by IndexRecordWriter below to convert from libIndex's 
representation of things to the index store's.


https://reviews.llvm.org/D39050



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


r317053 - Making a couple of tests a bit more flexible wrt thunk mangling. Fixes checkin for r317047.

2017-10-31 Thread Wolfgang Pieb via cfe-commits
Author: wolfgangp
Date: Tue Oct 31 17:01:20 2017
New Revision: 317053

URL: http://llvm.org/viewvc/llvm-project?rev=317053&view=rev
Log:
Making a couple of tests a bit more flexible wrt thunk mangling. Fixes checkin 
for r317047.

Modified:
cfe/trunk/test/CodeGenCXX/tmp-md-nodes1.cpp
cfe/trunk/test/CodeGenCXX/tmp-md-nodes2.cpp

Modified: cfe/trunk/test/CodeGenCXX/tmp-md-nodes1.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/tmp-md-nodes1.cpp?rev=317053&r1=317052&r2=317053&view=diff
==
--- cfe/trunk/test/CodeGenCXX/tmp-md-nodes1.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/tmp-md-nodes1.cpp Tue Oct 31 17:01:20 2017
@@ -15,4 +15,4 @@ struct CharlieImpl : Charlie, Alpha {
   void bravo(...) {}
 } delta;
 
-// CHECK: define {{.*}} void @_ZThn8_N11CharlieImpl5bravoEz(
+// CHECK: define {{.*}} void @_ZThn{{[48]}}_N11CharlieImpl5bravoEz(

Modified: cfe/trunk/test/CodeGenCXX/tmp-md-nodes2.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/tmp-md-nodes2.cpp?rev=317053&r1=317052&r2=317053&view=diff
==
--- cfe/trunk/test/CodeGenCXX/tmp-md-nodes2.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/tmp-md-nodes2.cpp Tue Oct 31 17:01:20 2017
@@ -30,4 +30,4 @@ BOOL CBdVfsImpl::ReqCacheHint( CMsgAgent
   return true;
 }
 
-// CHECK: define {{.*}} 
@_ZThn8_N10CBdVfsImpl12ReqCacheHintEP9CMsgAgentN3CFs10CACHE_HINTEz(
+// CHECK: define {{.*}} 
@_ZThn{{[48]}}_N10CBdVfsImpl12ReqCacheHintEP9CMsgAgentN3CFs10CACHE_HINTEz(


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


r317054 - [refactor][selection] code ranges can be selected in objc methods

2017-10-31 Thread Alex Lorenz via cfe-commits
Author: arphaman
Date: Tue Oct 31 17:07:12 2017
New Revision: 317054

URL: http://llvm.org/viewvc/llvm-project?rev=317054&view=rev
Log:
[refactor][selection] code ranges can be selected in objc methods

Modified:
cfe/trunk/lib/Tooling/Refactoring/ASTSelection.cpp
cfe/trunk/unittests/Tooling/ASTSelectionTest.cpp

Modified: cfe/trunk/lib/Tooling/Refactoring/ASTSelection.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Tooling/Refactoring/ASTSelection.cpp?rev=317054&r1=317053&r2=317054&view=diff
==
--- cfe/trunk/lib/Tooling/Refactoring/ASTSelection.cpp (original)
+++ cfe/trunk/lib/Tooling/Refactoring/ASTSelection.cpp Tue Oct 31 17:07:12 2017
@@ -347,6 +347,11 @@ CodeRangeASTSelection::create(SourceRang
/*AreChildrenSelected=*/true);
 }
 
+static bool isFunctionLikeDeclaration(const Decl *D) {
+  // FIXME (Alex L): Test for BlockDecl.
+  return isa(D) || isa(D);
+}
+
 bool CodeRangeASTSelection::isInFunctionLikeBodyOfCode() const {
   bool IsPrevCompound = false;
   // Scan through the parents (bottom-to-top) and check if the selection is
@@ -355,8 +360,7 @@ bool CodeRangeASTSelection::isInFunction
   for (const auto &Parent : llvm::reverse(Parents)) {
 const DynTypedNode &Node = Parent.get().Node;
 if (const auto *D = Node.get()) {
-  // FIXME (Alex L): Test for BlockDecl && ObjCMethodDecl.
-  if (isa(D))
+  if (isFunctionLikeDeclaration(D))
 return IsPrevCompound;
   // FIXME (Alex L): We should return false on top-level decls in functions
   // e.g. we don't want to extract:
@@ -372,8 +376,7 @@ const Decl *CodeRangeASTSelection::getFu
   for (const auto &Parent : llvm::reverse(Parents)) {
 const DynTypedNode &Node = Parent.get().Node;
 if (const auto *D = Node.get()) {
-  // FIXME (Alex L): Test for BlockDecl && ObjCMethodDecl.
-  if (isa(D))
+  if (isFunctionLikeDeclaration(D))
 return D;
 }
   }

Modified: cfe/trunk/unittests/Tooling/ASTSelectionTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Tooling/ASTSelectionTest.cpp?rev=317054&r1=317053&r2=317054&view=diff
==
--- cfe/trunk/unittests/Tooling/ASTSelectionTest.cpp (original)
+++ cfe/trunk/unittests/Tooling/ASTSelectionTest.cpp Tue Oct 31 17:07:12 2017
@@ -896,4 +896,80 @@ void f(int x, int y) {
   });
 }
 
+TEST(ASTSelectionFinder, SimpleCodeRangeASTSelectionInObjCMethod) {
+  StringRef Source = R"(@interface I @end
+@implementation I
+- (void) f:(int)x with:(int) y {
+  int z = x;
+  [self f: 2 with: 3];
+  if (x == 0) {
+return;
+  }
+  x = 1;
+  return;
+}
+- (void)f2 {
+  int m = 0;
+}
+@end
+)";
+  // Range that spans multiple methods is an invalid code range.
+  findSelectedASTNodesWithRange(
+  Source, {9, 2}, FileRange{{9, 2}, {13, 1}},
+  [](SourceRange SelectionRange, Optional Node) {
+EXPECT_TRUE(Node);
+Optional SelectedCode =
+CodeRangeASTSelection::create(SelectionRange, std::move(*Node));
+EXPECT_FALSE(SelectedCode);
+  },
+  SelectionFinderVisitor::Lang_OBJC);
+  // Just 'z = x;':
+  findSelectedASTNodesWithRange(
+  Source, {4, 2}, FileRange{{4, 2}, {4, 13}},
+  [](SourceRange SelectionRange, Optional Node) {
+EXPECT_TRUE(Node);
+Optional SelectedCode =
+CodeRangeASTSelection::create(SelectionRange, std::move(*Node));
+EXPECT_TRUE(SelectedCode);
+EXPECT_EQ(SelectedCode->size(), 1u);
+EXPECT_TRUE(isa((*SelectedCode)[0]));
+ArrayRef Parents =
+SelectedCode->getParents();
+EXPECT_EQ(Parents.size(), 4u);
+EXPECT_TRUE(
+isa(Parents[0].get().Node.get()));
+// 'I' @implementation.
+EXPECT_TRUE(isa(Parents[1].get().Node.get()));
+// Function 'f' definition.
+EXPECT_TRUE(isa(Parents[2].get().Node.get()));
+// Function body of function 'F'.
+EXPECT_TRUE(isa(Parents[3].get().Node.get()));
+  },
+  SelectionFinderVisitor::Lang_OBJC);
+  // From '[self f: 2 with: 3]' until just before 'x = 1;':
+  findSelectedASTNodesWithRange(
+  Source, {5, 2}, FileRange{{5, 2}, {9, 1}},
+  [](SourceRange SelectionRange, Optional Node) {
+EXPECT_TRUE(Node);
+Optional SelectedCode =
+CodeRangeASTSelection::create(SelectionRange, std::move(*Node));
+EXPECT_TRUE(SelectedCode);
+EXPECT_EQ(SelectedCode->size(), 2u);
+EXPECT_TRUE(isa((*SelectedCode)[0]));
+EXPECT_TRUE(isa((*SelectedCode)[1]));
+ArrayRef Parents =
+SelectedCode->getParents();
+EXPECT_EQ(Parents.size(), 4u);
+EXPECT_TRUE(
+isa(Parents[0].get().Node.get()));
+// 'I' @implementation.
+EXPECT_TRUE(isa(Parents[1].get().Node.get()));
+// Function 'f' definition.
+ 

r317056 - [refactor][extract] prohibit extraction of ObjC property setters

2017-10-31 Thread Alex Lorenz via cfe-commits
Author: arphaman
Date: Tue Oct 31 17:20:55 2017
New Revision: 317056

URL: http://llvm.org/viewvc/llvm-project?rev=317056&view=rev
Log:
[refactor][extract] prohibit extraction of ObjC property setters

Added:
cfe/trunk/test/Refactor/Extract/ObjCProperty.m
Modified:
cfe/trunk/include/clang/Basic/DiagnosticRefactoringKinds.td
cfe/trunk/lib/Tooling/Refactoring/Extract.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticRefactoringKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticRefactoringKinds.td?rev=317056&r1=317055&r2=317056&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticRefactoringKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticRefactoringKinds.td Tue Oct 31 
17:20:55 2017
@@ -26,6 +26,8 @@ def err_refactor_code_outside_of_functio
   "part of a function's / method's body">;
 def err_refactor_extract_simple_expression : Error<"the selected expression "
   "is too simple to extract">;
+def err_refactor_extract_prohibited_expression : Error<"the selected "
+  "expression can't be extracted">;
 
 }
 

Modified: cfe/trunk/lib/Tooling/Refactoring/Extract.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Tooling/Refactoring/Extract.cpp?rev=317056&r1=317055&r2=317056&view=diff
==
--- cfe/trunk/lib/Tooling/Refactoring/Extract.cpp (original)
+++ cfe/trunk/lib/Tooling/Refactoring/Extract.cpp Tue Oct 31 17:20:55 2017
@@ -16,6 +16,7 @@
 #include "clang/Tooling/Refactoring/Extract/Extract.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/Expr.h"
+#include "clang/AST/ExprObjC.h"
 #include "clang/Rewrite/Core/Rewriter.h"
 
 namespace clang {
@@ -70,12 +71,20 @@ ExtractFunction::initiate(RefactoringRul
 return Context.createDiagnosticError(
 diag::err_refactor_code_outside_of_function);
 
-  // Avoid extraction of simple literals and references.
-  if (Code.size() == 1 && isSimpleExpression(dyn_cast(Code[0])))
-return Context.createDiagnosticError(
-diag::err_refactor_extract_simple_expression);
+  if (Code.size() == 1) {
+// Avoid extraction of simple literals and references.
+if (isSimpleExpression(dyn_cast(Code[0])))
+  return Context.createDiagnosticError(
+  diag::err_refactor_extract_simple_expression);
+
+// Property setters can't be extracted.
+if (const auto *PRE = dyn_cast(Code[0])) {
+  if (!PRE->isMessagingGetter())
+return Context.createDiagnosticError(
+diag::err_refactor_extract_prohibited_expression);
+}
+  }
 
-  // FIXME (Alex L): Prohibit extraction of Objective-C property setters.
   return ExtractFunction(std::move(Code), DeclName);
 }
 

Added: cfe/trunk/test/Refactor/Extract/ObjCProperty.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Refactor/Extract/ObjCProperty.m?rev=317056&view=auto
==
--- cfe/trunk/test/Refactor/Extract/ObjCProperty.m (added)
+++ cfe/trunk/test/Refactor/Extract/ObjCProperty.m Tue Oct 31 17:20:55 2017
@@ -0,0 +1,41 @@
+// RUN: clang-refactor extract -selection=test:%s %s -- 2>&1 | grep -v CHECK | 
FileCheck %s
+
+@interface HasProperty
+
+@property (strong) HasProperty *item;
+
+- (HasProperty *)implicitProp;
+
+- (void)setImplicitSetter:(HasProperty *)value;
+
+@end
+
+@implementation HasProperty
+
+- (void)allowGetterExtraction {
+  /*range allow_getter=->+0:42*/self.item;
+  /*range allow_imp_getter=->+0:54*/self.implicitProp;
+}
+// CHECK: 1 'allow_getter' results:
+// CHECK:  extracted() {
+// CHECK-NEXT: return self.item;{{$}}
+// CHECK-NEXT: }{{[[:space:]].*}}
+// CHECK-NEXT: - (void)allowGetterExtraction {
+// CHECK-NEXT: extracted();
+
+// CHECK: 1 'allow_imp_getter' results:
+// CHECK:  extracted() {
+// CHECK-NEXT: return self.implicitProp;{{$}}
+// CHECK-NEXT: }{{[[:space:]].*}}
+// CHECK-NEXT: - (void)allowGetterExtraction {
+// CHECK-NEXT: self.item;
+// CHECK-NEXT: extracted();
+
+- (void)prohibitSetterExtraction {
+  /*range prohibit_setter=->+0:45*/self.item = 0;
+  /*range prohibit_setter=->+0:55*/self.implicitSetter = 0;
+}
+// CHECK: 2 'prohibit_setter' results:
+// CHECK: the selected expression can't be extracted
+
+@end


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


[PATCH] D39428: [Analyzer] As suggested, use value storage for BodyFarm

2017-10-31 Thread Devin Coughlin via Phabricator via cfe-commits
dcoughlin accepted this revision.
dcoughlin added a comment.

Looks good to me with the comments by Gabor addressed.

In https://reviews.llvm.org/D39428#912126, @george.karpenkov wrote:

> On top of that, reference is part of the type, not part of the variable name,


The reference is parsed as part of the declarator (associated with the variable 
name) rather than as part of the type.

Where this rears its ugly head is when declaring multiple variables in the same 
statement:

  int g = 7;
  void foo() {
int& p = g, q = 7;
  }

Here p has type 'int &' but q has type 'int'. The same holds for '*' for 
pointer types in C.


https://reviews.llvm.org/D39428



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


r317062 - [refactor][extract] code extracted from inline method should be placed

2017-10-31 Thread Alex Lorenz via cfe-commits
Author: arphaman
Date: Tue Oct 31 18:12:56 2017
New Revision: 317062

URL: http://llvm.org/viewvc/llvm-project?rev=317062&view=rev
Log:
[refactor][extract] code extracted from inline method should be placed
in a function defined before the outer class

Added:
cfe/trunk/test/Refactor/Extract/FromMethodToFunction.cpp
Modified:
cfe/trunk/lib/Tooling/Refactoring/Extract.cpp

Modified: cfe/trunk/lib/Tooling/Refactoring/Extract.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Tooling/Refactoring/Extract.cpp?rev=317062&r1=317061&r2=317062&view=diff
==
--- cfe/trunk/lib/Tooling/Refactoring/Extract.cpp (original)
+++ cfe/trunk/lib/Tooling/Refactoring/Extract.cpp Tue Oct 31 18:12:56 2017
@@ -15,6 +15,7 @@
 
 #include "clang/Tooling/Refactoring/Extract/Extract.h"
 #include "clang/AST/ASTContext.h"
+#include "clang/AST/DeclCXX.h"
 #include "clang/AST/Expr.h"
 #include "clang/AST/ExprObjC.h"
 #include "clang/Rewrite/Core/Rewriter.h"
@@ -44,8 +45,12 @@ bool isSimpleExpression(const Expr *E) {
 }
 
 SourceLocation computeFunctionExtractionLocation(const Decl *D) {
-  // FIXME (Alex L): Method -> function extraction should place function before
-  // C++ record if the method is defined inside the record.
+  if (isa(D)) {
+// Code from method that is defined in class body should be extracted to a
+// function defined just before the class.
+while (const auto *RD = 
dyn_cast(D->getLexicalDeclContext()))
+  D = RD;
+  }
   return D->getLocStart();
 }
 

Added: cfe/trunk/test/Refactor/Extract/FromMethodToFunction.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Refactor/Extract/FromMethodToFunction.cpp?rev=317062&view=auto
==
--- cfe/trunk/test/Refactor/Extract/FromMethodToFunction.cpp (added)
+++ cfe/trunk/test/Refactor/Extract/FromMethodToFunction.cpp Tue Oct 31 
18:12:56 2017
@@ -0,0 +1,42 @@
+// RUN: clang-refactor extract -selection=test:%s %s -- -std=c++11 2>&1 | grep 
-v CHECK | FileCheck --check-prefixes=CHECK,CHECK-INNER %s
+// RUN: clang-refactor extract -selection=test:%s %s -- -std=c++11 -DMULTIPLE 
2>&1 | grep -v CHECK | FileCheck --check-prefixes=CHECK,CHECK-OUTER %s
+
+#ifdef MULTIPLE
+class OuterClass {
+#define PREFIX OuterClass ::
+#else
+#define PREFIX
+#endif
+
+class AClass {
+
+  int method(int x) {
+return /*range inner=->+0:38*/1 + 2 * 2;
+  }
+// CHECK-INNER: 1 'inner' results:
+// CHECK-INNER:  static int extracted() {
+// CHECK-INNER-NEXT: return 1 + 2 * 2;{{$}}
+// CHECK-INNER-NEXT: }{{[[:space:]].*}}
+// CHECK-INNER-NEXT: class AClass {
+
+// CHECK-OUTER: 1 'inner' results:
+// CHECK-OUTER:  static int extracted() {
+// CHECK-OUTER-NEXT: return 1 + 2 * 2;{{$}}
+// CHECK-OUTER-NEXT: }{{[[:space:]].*}}
+// CHECK-OUTER-NEXT: class OuterClass {
+
+  int otherMethod(int x);
+};
+
+#ifdef MULTIPLE
+};
+#endif
+
+int PREFIX AClass::otherMethod(int x) {
+  return /*range outofline=->+0:46*/2 * 2 - 1;
+}
+// CHECK: 1 'outofline' results:
+// CHECK:  static int extracted() {
+// CHECK-NEXT: return 2 * 2 - 1;{{$}}
+// CHECK-NEXT: }{{[[:space:]].*}}
+// CHECK-NEXT: int PREFIX AClass::otherMethod


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


[libcxx] r317063 - Update the synopsis to match the P/R of 2945. No code changes.

2017-10-31 Thread Marshall Clow via cfe-commits
Author: marshall
Date: Tue Oct 31 18:27:25 2017
New Revision: 317063

URL: http://llvm.org/viewvc/llvm-project?rev=317063&view=rev
Log:
Update the synopsis to match the P/R of 2945. No code changes.


Modified:
libcxx/trunk/include/optional

Modified: libcxx/trunk/include/optional
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/optional?rev=317063&r1=317062&r2=317063&view=diff
==
--- libcxx/trunk/include/optional (original)
+++ libcxx/trunk/include/optional Tue Oct 31 18:27:25 2017
@@ -57,17 +57,17 @@ namespace std {
 
   // 23.6.8, comparison with T
   template  constexpr bool operator==(const optional&, 
const U&);
-  template  constexpr bool operator==(const U&, const 
optional&);
+  template  constexpr bool operator==(const T&, const 
optional&);
   template  constexpr bool operator!=(const optional&, 
const U&);
-  template  constexpr bool operator!=(const U&, const 
optional&);
+  template  constexpr bool operator!=(const T&, const 
optional&);
   template  constexpr bool operator<(const optional&, 
const U&);
-  template  constexpr bool operator<(const U&, const 
optional&);
+  template  constexpr bool operator<(const T&, const 
optional&);
   template  constexpr bool operator<=(const optional&, 
const U&);
-  template  constexpr bool operator<=(const U&, const 
optional&);
+  template  constexpr bool operator<=(const T&, const 
optional&);
   template  constexpr bool operator>(const optional&, 
const U&);
-  template  constexpr bool operator>(const U&, const 
optional&);
+  template  constexpr bool operator>(const T&, const 
optional&);
   template  constexpr bool operator>=(const optional&, 
const U&);
-  template  constexpr bool operator>=(const U&, const 
optional&);
+  template  constexpr bool operator>=(const T&, const 
optional&);
 
   // 23.6.9, specialized algorithms
   template  void swap(optional&, optional&) noexcept(see below 
);


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


[PATCH] D39428: [Analyzer] As suggested, use value storage for BodyFarm

2017-10-31 Thread George Karpenkov via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL317065: [Analyzer] Use value storage for BodyFarm (authored 
by george.karpenkov).

Changed prior to commit:
  https://reviews.llvm.org/D39428?vs=120861&id=121098#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D39428

Files:
  cfe/trunk/include/clang/Analysis/AnalysisDeclContext.h
  cfe/trunk/include/clang/Analysis/BodyFarm.h
  cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp


Index: cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp
===
--- cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp
+++ cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp
@@ -68,7 +68,8 @@
 bool addInitializers, bool addTemporaryDtors, bool addLifetime,
 bool addLoopExit, bool synthesizeBodies, bool addStaticInitBranch,
 bool addCXXNewAllocator, CodeInjector *injector)
-: ASTCtx(ASTCtx), Injector(injector), SynthesizeBodies(synthesizeBodies) {
+: ASTCtx(ASTCtx), Injector(injector), FunctionBodyFarm(ASTCtx, injector),
+  SynthesizeBodies(synthesizeBodies) {
   cfgBuildOptions.PruneTriviallyFalseEdges = !useUnoptimizedCFG;
   cfgBuildOptions.AddImplicitDtors = addImplicitDtors;
   cfgBuildOptions.AddInitializers = addInitializers;
@@ -88,7 +89,7 @@
 if (auto *CoroBody = dyn_cast_or_null(Body))
   Body = CoroBody->getBody();
 if (Manager && Manager->synthesizeBodies()) {
-  Stmt *SynthesizedBody = Manager->getBodyFarm()->getBody(FD);
+  Stmt *SynthesizedBody = Manager->getBodyFarm().getBody(FD);
   if (SynthesizedBody) {
 Body = SynthesizedBody;
 IsAutosynthesized = true;
@@ -99,7 +100,7 @@
   else if (const ObjCMethodDecl *MD = dyn_cast(D)) {
 Stmt *Body = MD->getBody();
 if (Manager && Manager->synthesizeBodies()) {
-  Stmt *SynthesizedBody = Manager->getBodyFarm()->getBody(MD);
+  Stmt *SynthesizedBody = Manager->getBodyFarm().getBody(MD);
   if (SynthesizedBody) {
 Body = SynthesizedBody;
 IsAutosynthesized = true;
@@ -304,11 +305,7 @@
   return AC.get();
 }
 
-BodyFarm *AnalysisDeclContextManager::getBodyFarm() {
-  if (!FunctionBodyFarm)
-FunctionBodyFarm = llvm::make_unique(ASTCtx, Injector.get());
-  return FunctionBodyFarm.get();
-}
+BodyFarm &AnalysisDeclContextManager::getBodyFarm() { return FunctionBodyFarm; 
}
 
 const StackFrameContext *
 AnalysisDeclContext::getStackFrame(LocationContext const *Parent, const Stmt 
*S,
Index: cfe/trunk/include/clang/Analysis/AnalysisDeclContext.h
===
--- cfe/trunk/include/clang/Analysis/AnalysisDeclContext.h
+++ cfe/trunk/include/clang/Analysis/AnalysisDeclContext.h
@@ -419,9 +419,9 @@
   /// declarations from external source.
   std::unique_ptr Injector;
 
-  /// Pointer to a factory for creating and caching implementations for common
+  /// A factory for creating and caching implementations for common
   /// methods during the analysis.
-  std::unique_ptr FunctionBodyFarm;
+  BodyFarm FunctionBodyFarm;
 
   /// Flag to indicate whether or not bodies should be synthesized
   /// for well-known functions.
@@ -475,8 +475,8 @@
 return LocContexts.getStackFrame(getContext(D), Parent, S, Blk, Idx);
   }
 
-  /// Get and lazily create a {@code BodyFarm} instance.
-  BodyFarm *getBodyFarm();
+  /// Get a reference to {@code BodyFarm} instance.
+  BodyFarm &getBodyFarm();
 
   /// Discard all previously created AnalysisDeclContexts.
   void clear();
Index: cfe/trunk/include/clang/Analysis/BodyFarm.h
===
--- cfe/trunk/include/clang/Analysis/BodyFarm.h
+++ cfe/trunk/include/clang/Analysis/BodyFarm.h
@@ -39,6 +39,9 @@
   /// Factory method for creating bodies for Objective-C properties.
   Stmt *getBody(const ObjCMethodDecl *D);
 
+  /// Remove copy constructor to avoid accidental copying.
+  BodyFarm(const BodyFarm &other) = delete;
+
 private:
   typedef llvm::DenseMap> BodyMap;
 


Index: cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp
===
--- cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp
+++ cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp
@@ -68,7 +68,8 @@
 bool addInitializers, bool addTemporaryDtors, bool addLifetime,
 bool addLoopExit, bool synthesizeBodies, bool addStaticInitBranch,
 bool addCXXNewAllocator, CodeInjector *injector)
-: ASTCtx(ASTCtx), Injector(injector), SynthesizeBodies(synthesizeBodies) {
+: ASTCtx(ASTCtx), Injector(injector), FunctionBodyFarm(ASTCtx, injector),
+  SynthesizeBodies(synthesizeBodies) {
   cfgBuildOptions.PruneTriviallyFalseEdges = !useUnoptimizedCFG;
   cfgBuildOptions.AddImplicitDtors = addImplicitDtors;
   cfgBuildOptions.AddInitializers = addInitializers;
@@ -88,7 +89,7 @@
 if (auto *CoroBody = dyn_cast_or_null(Body))
   Body = CoroBody->getBody();
 if (Manager && Manager->synth

r317065 - [Analyzer] Use value storage for BodyFarm

2017-10-31 Thread George Karpenkov via cfe-commits
Author: george.karpenkov
Date: Tue Oct 31 18:36:01 2017
New Revision: 317065

URL: http://llvm.org/viewvc/llvm-project?rev=317065&view=rev
Log:
[Analyzer] Use value storage for BodyFarm

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

Modified:
cfe/trunk/include/clang/Analysis/AnalysisDeclContext.h
cfe/trunk/include/clang/Analysis/BodyFarm.h
cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp

Modified: cfe/trunk/include/clang/Analysis/AnalysisDeclContext.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Analysis/AnalysisDeclContext.h?rev=317065&r1=317064&r2=317065&view=diff
==
--- cfe/trunk/include/clang/Analysis/AnalysisDeclContext.h (original)
+++ cfe/trunk/include/clang/Analysis/AnalysisDeclContext.h Tue Oct 31 18:36:01 
2017
@@ -419,9 +419,9 @@ class AnalysisDeclContextManager {
   /// declarations from external source.
   std::unique_ptr Injector;
 
-  /// Pointer to a factory for creating and caching implementations for common
+  /// A factory for creating and caching implementations for common
   /// methods during the analysis.
-  std::unique_ptr FunctionBodyFarm;
+  BodyFarm FunctionBodyFarm;
 
   /// Flag to indicate whether or not bodies should be synthesized
   /// for well-known functions.
@@ -475,8 +475,8 @@ public:
 return LocContexts.getStackFrame(getContext(D), Parent, S, Blk, Idx);
   }
 
-  /// Get and lazily create a {@code BodyFarm} instance.
-  BodyFarm *getBodyFarm();
+  /// Get a reference to {@code BodyFarm} instance.
+  BodyFarm &getBodyFarm();
 
   /// Discard all previously created AnalysisDeclContexts.
   void clear();

Modified: cfe/trunk/include/clang/Analysis/BodyFarm.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Analysis/BodyFarm.h?rev=317065&r1=317064&r2=317065&view=diff
==
--- cfe/trunk/include/clang/Analysis/BodyFarm.h (original)
+++ cfe/trunk/include/clang/Analysis/BodyFarm.h Tue Oct 31 18:36:01 2017
@@ -39,6 +39,9 @@ public:
   /// Factory method for creating bodies for Objective-C properties.
   Stmt *getBody(const ObjCMethodDecl *D);
 
+  /// Remove copy constructor to avoid accidental copying.
+  BodyFarm(const BodyFarm &other) = delete;
+
 private:
   typedef llvm::DenseMap> BodyMap;
 

Modified: cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp?rev=317065&r1=317064&r2=317065&view=diff
==
--- cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp (original)
+++ cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp Tue Oct 31 18:36:01 2017
@@ -68,7 +68,8 @@ AnalysisDeclContextManager::AnalysisDecl
 bool addInitializers, bool addTemporaryDtors, bool addLifetime,
 bool addLoopExit, bool synthesizeBodies, bool addStaticInitBranch,
 bool addCXXNewAllocator, CodeInjector *injector)
-: ASTCtx(ASTCtx), Injector(injector), SynthesizeBodies(synthesizeBodies) {
+: ASTCtx(ASTCtx), Injector(injector), FunctionBodyFarm(ASTCtx, injector),
+  SynthesizeBodies(synthesizeBodies) {
   cfgBuildOptions.PruneTriviallyFalseEdges = !useUnoptimizedCFG;
   cfgBuildOptions.AddImplicitDtors = addImplicitDtors;
   cfgBuildOptions.AddInitializers = addInitializers;
@@ -88,7 +89,7 @@ Stmt *AnalysisDeclContext::getBody(bool
 if (auto *CoroBody = dyn_cast_or_null(Body))
   Body = CoroBody->getBody();
 if (Manager && Manager->synthesizeBodies()) {
-  Stmt *SynthesizedBody = Manager->getBodyFarm()->getBody(FD);
+  Stmt *SynthesizedBody = Manager->getBodyFarm().getBody(FD);
   if (SynthesizedBody) {
 Body = SynthesizedBody;
 IsAutosynthesized = true;
@@ -99,7 +100,7 @@ Stmt *AnalysisDeclContext::getBody(bool
   else if (const ObjCMethodDecl *MD = dyn_cast(D)) {
 Stmt *Body = MD->getBody();
 if (Manager && Manager->synthesizeBodies()) {
-  Stmt *SynthesizedBody = Manager->getBodyFarm()->getBody(MD);
+  Stmt *SynthesizedBody = Manager->getBodyFarm().getBody(MD);
   if (SynthesizedBody) {
 Body = SynthesizedBody;
 IsAutosynthesized = true;
@@ -304,11 +305,7 @@ AnalysisDeclContext *AnalysisDeclContext
   return AC.get();
 }
 
-BodyFarm *AnalysisDeclContextManager::getBodyFarm() {
-  if (!FunctionBodyFarm)
-FunctionBodyFarm = llvm::make_unique(ASTCtx, Injector.get());
-  return FunctionBodyFarm.get();
-}
+BodyFarm &AnalysisDeclContextManager::getBodyFarm() { return FunctionBodyFarm; 
}
 
 const StackFrameContext *
 AnalysisDeclContext::getStackFrame(LocationContext const *Parent, const Stmt 
*S,


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


r317066 - [c++17] Refine resolution of constructor / conversion function disambiguation.

2017-10-31 Thread Richard Smith via cfe-commits
Author: rsmith
Date: Tue Oct 31 18:37:11 2017
New Revision: 317066

URL: http://llvm.org/viewvc/llvm-project?rev=317066&view=rev
Log:
[c++17] Refine resolution of constructor / conversion function disambiguation.

Given a choice between a constructor call and a conversion function in C++17,
we prefer the constructor for direct-initialization and the conversion function
for copy-initialization, matching the behavior in C++14 and before. The
guaranteed copy elision rules were not intended to change the meaning of such
code (other than by removing unnecessary copy constructor calls).

This tweak will be raised with CWG.

Modified:
cfe/trunk/lib/Sema/SemaOverload.cpp
cfe/trunk/test/SemaCXX/cxx1z-copy-omission.cpp

Modified: cfe/trunk/lib/Sema/SemaOverload.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOverload.cpp?rev=317066&r1=317065&r2=317066&view=diff
==
--- cfe/trunk/lib/Sema/SemaOverload.cpp (original)
+++ cfe/trunk/lib/Sema/SemaOverload.cpp Tue Oct 31 18:37:11 2017
@@ -8977,6 +8977,18 @@ bool clang::isBetterOverloadCandidate(
 // C++14 [over.match.best]p1 section 2 bullet 3.
   }
 
+  // FIXME: Work around a defect in the C++17 guaranteed copy elision wording,
+  // as combined with the resolution to CWG issue 243.
+  //
+  // When the context is initialization by constructor ([over.match.ctor] or
+  // either phase of [over.match.list]), a constructor is preferred over
+  // a conversion function.
+  if (Kind == OverloadCandidateSet::CSK_InitByConstructor && NumArgs == 1 &&
+  Cand1.Function && Cand2.Function &&
+  isa(Cand1.Function) !=
+  isa(Cand2.Function))
+return isa(Cand1.Function);
+
   //-- F1 is a non-template function and F2 is a function template
   //   specialization, or, if not that,
   bool Cand1IsSpecialization = Cand1.Function &&
@@ -9035,20 +9047,6 @@ bool clang::isBetterOverloadCandidate(
 return true;
 }
   }
-  
-
-
-  // FIXME: Work around a defect in the C++17 guaranteed copy elision wording,
-  // as combined with the resolution to CWG issue 243.
-  //
-  // When the context is initialization by constructor ([over.match.ctor] or
-  // either phase of [over.match.list]), a constructor is preferred over
-  // a conversion function.
-  if (Kind == OverloadCandidateSet::CSK_InitByConstructor && NumArgs == 1 &&
-  Cand1.Function && Cand2.Function &&
-  isa(Cand1.Function) !=
-  isa(Cand2.Function))
-return isa(Cand1.Function);
 
   // Check for enable_if value-based overload resolution.
   if (Cand1.Function && Cand2.Function) {

Modified: cfe/trunk/test/SemaCXX/cxx1z-copy-omission.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/cxx1z-copy-omission.cpp?rev=317066&r1=317065&r2=317066&view=diff
==
--- cfe/trunk/test/SemaCXX/cxx1z-copy-omission.cpp (original)
+++ cfe/trunk/test/SemaCXX/cxx1z-copy-omission.cpp Tue Oct 31 18:37:11 2017
@@ -160,3 +160,12 @@ struct AsDelegating final {
   // classes?
   AsDelegating(int n) : AsDelegating(make(n)) {} // expected-error {{deleted}}
 };
+
+namespace CtorTemplateBeatsNonTemplateConversionFn {
+  struct Foo { template  Foo(const Derived &); };
+  template  struct Base { operator Foo() const = delete; }; 
// expected-note {{deleted}}
+  struct Derived : Base {};
+
+  Foo f(Derived d) { return d; } // expected-error {{invokes a deleted 
function}}
+  Foo g(Derived d) { return Foo(d); } // ok, calls constructor
+}


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


r317069 - [X86] Define i586 and pentium preprocessor defines for -march=lakemont to match GCC

2017-10-31 Thread Craig Topper via cfe-commits
Author: ctopper
Date: Tue Oct 31 19:18:49 2017
New Revision: 317069

URL: http://llvm.org/viewvc/llvm-project?rev=317069&view=rev
Log:
[X86] Define i586 and pentium preprocessor defines for -march=lakemont to match 
GCC

Modified:
cfe/trunk/lib/Basic/Targets/X86.cpp
cfe/trunk/test/Preprocessor/predefined-arch-macros.c

Modified: cfe/trunk/lib/Basic/Targets/X86.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/X86.cpp?rev=317069&r1=317068&r2=317069&view=diff
==
--- cfe/trunk/lib/Basic/Targets/X86.cpp (original)
+++ cfe/trunk/lib/Basic/Targets/X86.cpp Tue Oct 31 19:18:49 2017
@@ -852,6 +852,8 @@ void X86TargetInfo::getTargetDefines(con
   case CK_KNM:
 break;
   case CK_Lakemont:
+defineCPUMacros(Builder, "i586", /*Tuning*/false);
+defineCPUMacros(Builder, "pentium", /*Tuning*/false);
 Builder.defineMacro("__tune_lakemont__");
 break;
   case CK_K6_2:

Modified: cfe/trunk/test/Preprocessor/predefined-arch-macros.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Preprocessor/predefined-arch-macros.c?rev=317069&r1=317068&r2=317069&view=diff
==
--- cfe/trunk/test/Preprocessor/predefined-arch-macros.c (original)
+++ cfe/trunk/test/Preprocessor/predefined-arch-macros.c Tue Oct 31 19:18:49 
2017
@@ -1158,15 +1158,19 @@
 //
 // RUN: %clang -march=lakemont -m32 -E -dM %s -o - 2>&1 \
 // RUN: -target i386-unknown-linux \
-// RUN:   | FileCheck %s -check-prefix=CHECK_LMT_M32
-// CHECK_LMT_M32: #define __i386 1
-// CHECK_LMT_M32: #define __i386__ 1
-// CHECK_LMT_M32: #define __tune_lakemont__ 1
-// CHECK_LMT_M32: #define i386 1
+// RUN:   | FileCheck %s -check-prefix=CHECK_LAKEMONT_M32
+// CHECK_LAKEMONT_M32: #define __i386 1
+// CHECK_LAKEMONT_M32: #define __i386__ 1
+// CHECK_LAKEMONT_M32: #define __i586 1
+// CHECK_LAKEMONT_M32: #define __i586__ 1
+// CHECK_LAKEMONT_M32: #define __pentium 1
+// CHECK_LAKEMONT_M32: #define __pentium__ 1
+// CHECK_LAKEMONT_M32: #define __tune_lakemont__ 1
+// CHECK_LAKEMONT_M32: #define i386 1
 // RUN: not %clang -march=lakemont -m64 -E -dM %s -o - 2>&1 \
 // RUN: -target i386-unknown-linux \
-// RUN:   | FileCheck %s -check-prefix=CHECK_LMT_M64
-// CHECK_LMT_M64: error:
+// RUN:   | FileCheck %s -check-prefix=CHECK_LAKEMONT_M64
+// CHECK_LAKEMONT_M64: error:
 //
 // RUN: %clang -march=geode -m32 -E -dM %s -o - 2>&1 \
 // RUN: -target i386-unknown-linux \


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


r317070 - [analyzer] Removing unused stored field.

2017-10-31 Thread George Karpenkov via cfe-commits
Author: george.karpenkov
Date: Tue Oct 31 19:29:04 2017
New Revision: 317070

URL: http://llvm.org/viewvc/llvm-project?rev=317070&view=rev
Log:
[analyzer] Removing unused stored field.

Modified:
cfe/trunk/include/clang/Analysis/AnalysisDeclContext.h
cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp

Modified: cfe/trunk/include/clang/Analysis/AnalysisDeclContext.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Analysis/AnalysisDeclContext.h?rev=317070&r1=317069&r2=317070&view=diff
==
--- cfe/trunk/include/clang/Analysis/AnalysisDeclContext.h (original)
+++ cfe/trunk/include/clang/Analysis/AnalysisDeclContext.h Tue Oct 31 19:29:04 
2017
@@ -410,7 +410,6 @@ class AnalysisDeclContextManager {
   typedef llvm::DenseMap>
   ContextMap;
 
-  ASTContext &ASTCtx;
   ContextMap Contexts;
   LocationContextManager LocContexts;
   CFG::BuildOptions cfgBuildOptions;

Modified: cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp?rev=317070&r1=317069&r2=317070&view=diff
==
--- cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp (original)
+++ cfe/trunk/lib/Analysis/AnalysisDeclContext.cpp Tue Oct 31 19:29:04 2017
@@ -68,7 +68,7 @@ AnalysisDeclContextManager::AnalysisDecl
 bool addInitializers, bool addTemporaryDtors, bool addLifetime,
 bool addLoopExit, bool synthesizeBodies, bool addStaticInitBranch,
 bool addCXXNewAllocator, CodeInjector *injector)
-: ASTCtx(ASTCtx), Injector(injector), FunctionBodyFarm(ASTCtx, injector),
+: Injector(injector), FunctionBodyFarm(ASTCtx, injector),
   SynthesizeBodies(synthesizeBodies) {
   cfgBuildOptions.PruneTriviallyFalseEdges = !useUnoptimizedCFG;
   cfgBuildOptions.AddImplicitDtors = addImplicitDtors;


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


[PATCH] D39438: [analyzer] Diagnose stack leaks via block captures

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

more tests


Repository:
  rL LLVM

https://reviews.llvm.org/D39438

Files:
  lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp
  test/Analysis/stack-async-leak.m

Index: test/Analysis/stack-async-leak.m
===
--- test/Analysis/stack-async-leak.m
+++ test/Analysis/stack-async-leak.m
@@ -0,0 +1,132 @@
+// RUN: %clang_analyze_cc1 -triple x86_64-apple-darwin10 -analyzer-checker=core -fblocks -fobjc-arc -verify %s
+
+typedef struct dispatch_queue_s *dispatch_queue_t;
+typedef void (^dispatch_block_t)(void);
+void dispatch_async(dispatch_queue_t queue, dispatch_block_t block);
+typedef long dispatch_once_t;
+void dispatch_once(dispatch_once_t *predicate, dispatch_block_t block);
+typedef long dispatch_time_t;
+void dispatch_after(dispatch_time_t when, dispatch_queue_t queue, dispatch_block_t block);
+
+extern dispatch_queue_t queue;
+extern dispatch_once_t *predicate;
+extern dispatch_time_t when;
+
+void test_block_expr_async() {
+  int x = 123;
+  int *p = &x;
+
+  dispatch_async(queue, ^{
+*p = 321;
+  });
+  // expected-warning@-3 {{Address of stack memory associated with local variable 'x' \
+might leak via the block capture}}
+}
+
+void test_block_expr_once_no_leak() {
+  int x = 123;
+  int *p = &x;
+  // synchronous, no warning
+  dispatch_once(predicate, ^{
+*p = 321;
+  });
+}
+
+void test_block_expr_after() {
+  int x = 123;
+  int *p = &x;
+  dispatch_after(when, queue, ^{
+*p = 321;
+  });
+  // expected-warning@-3 {{Address of stack memory associated with local variable 'x' \
+might leak via the block capture}}
+}
+
+void test_block_expr_async_no_leak() {
+  int x = 123;
+  int *p = &x;
+  // no leak
+  dispatch_async(queue, ^{
+int y = x;
+++y;
+  });
+}
+
+void test_block_var_async() {
+  int x = 123;
+  int *p = &x;
+  void (^b)(void) = ^void(void) {
+*p = 1; 
+  };
+  dispatch_async(queue, b);
+  // expected-warning@-1 {{Address of stack memory associated with local variable 'x' \
+might leak via the block capture}}
+}
+
+dispatch_block_t get_leaking_block() {
+  int leaked_x = 791;
+  int *p = &leaked_x;
+  return ^void(void) {
+*p = 1; 
+  };
+  // expected-warning@-3 {{Address of stack memory associated with local variable 'leaked_x' \
+might leak via the block capture}}
+}
+
+void test_returned_from_func_block_async() {
+  dispatch_async(queue, get_leaking_block());
+  // expected-warning@-1 {{Address of stack memory associated with local variable 'leaked_x' \
+might leak via the block capture}}
+}
+
+// synchronous, no leak
+void test_block_var_once() {
+  int x = 123;
+  int *p = &x;
+  void (^b)(void) = ^void(void) {
+*p = 1; 
+  };
+  // no leak
+  dispatch_once(predicate, b);
+}
+
+void test_block_var_after() {
+  int x = 123;
+  int *p = &x;
+  void (^b)(void) = ^void(void) {
+*p = 1; 
+  };
+  dispatch_after(when, queue, b);
+  // expected-warning@-1 {{Address of stack memory associated with local variable 'x' \
+might leak via the block capture}}
+}
+
+void test_block_var_async_no_leak() {
+  int x = 123;
+  int *p = &x;
+  void (^b)(void) = ^void(void) {
+int y = x;
+++y; 
+  };
+  // no leak
+  dispatch_async(queue, b);
+}
+
+void test_block_inside_block_async_no_leak() {
+  int x = 123;
+  int *p = &x;
+  void (^inner)(void) = ^void(void) {
+int y = x;
+++y; 
+  };
+  void (^outer)(void) = ^void(void) {
+int z = x;
+++z;
+inner(); 
+  };
+  // no leak
+  dispatch_async(queue, outer);
+}
+
+
+
Index: lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp
+++ lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp
@@ -18,23 +18,28 @@
 #include "clang/StaticAnalyzer/Core/BugReporter/BugType.h"
 #include "clang/StaticAnalyzer/Core/Checker.h"
 #include "clang/StaticAnalyzer/Core/CheckerManager.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/Support/raw_ostream.h"
 using namespace clang;
 using namespace ento;
 
 namespace {
-class StackAddrEscapeChecker : public Checker< check::PreStmt,
+class StackAddrEscapeChecker : public Checker< check::PreCall,
+   check::PreStmt,
check::EndFunction > {
   mutable std::unique_ptr BT_stackleak;
   mutable std::unique_ptr BT_returnstack;
+  mutable std::unique_ptr BT_capturestackleak;
 
 public:
+  void checkPreCall(const CallEvent &Call, CheckerContext &C) const;
   void checkPreStmt(const ReturnStmt *RS, CheckerContext &C) const;
   void checkEndFunction(CheckerContext &Ctx) const;
 private:
+  void checkBlockCaptures(const Bloc

[PATCH] D39438: [analyzer] Diagnose stack leaks via block captures

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

cleanup


Repository:
  rL LLVM

https://reviews.llvm.org/D39438

Files:
  lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp
  test/Analysis/stack-async-leak.m

Index: test/Analysis/stack-async-leak.m
===
--- test/Analysis/stack-async-leak.m
+++ test/Analysis/stack-async-leak.m
@@ -0,0 +1,130 @@
+// RUN: %clang_analyze_cc1 -triple x86_64-apple-darwin10 -analyzer-checker=core -fblocks -fobjc-arc -verify %s
+
+typedef struct dispatch_queue_s *dispatch_queue_t;
+typedef void (^dispatch_block_t)(void);
+void dispatch_async(dispatch_queue_t queue, dispatch_block_t block);
+typedef long dispatch_once_t;
+void dispatch_once(dispatch_once_t *predicate, dispatch_block_t block);
+typedef long dispatch_time_t;
+void dispatch_after(dispatch_time_t when, dispatch_queue_t queue, dispatch_block_t block);
+
+extern dispatch_queue_t queue;
+extern dispatch_once_t *predicate;
+extern dispatch_time_t when;
+
+void test_block_expr_async() {
+  int x = 123;
+  int *p = &x;
+
+  dispatch_async(queue, ^{
+*p = 321;
+  });
+  // expected-warning@-3 {{Address of stack memory associated with local variable 'x' \
+might leak via the block capture}}
+}
+
+void test_block_expr_once_no_leak() {
+  int x = 123;
+  int *p = &x;
+  // synchronous, no warning
+  dispatch_once(predicate, ^{
+*p = 321;
+  });
+}
+
+void test_block_expr_after() {
+  int x = 123;
+  int *p = &x;
+  dispatch_after(when, queue, ^{
+*p = 321;
+  });
+  // expected-warning@-3 {{Address of stack memory associated with local variable 'x' \
+might leak via the block capture}}
+}
+
+void test_block_expr_async_no_leak() {
+  int x = 123;
+  int *p = &x;
+  // no leak
+  dispatch_async(queue, ^{
+int y = x;
+++y;
+  });
+}
+
+void test_block_var_async() {
+  int x = 123;
+  int *p = &x;
+  void (^b)(void) = ^void(void) {
+*p = 1; 
+  };
+  dispatch_async(queue, b);
+  // expected-warning@-1 {{Address of stack memory associated with local variable 'x' \
+might leak via the block capture}}
+}
+
+dispatch_block_t get_leaking_block() {
+  int leaked_x = 791;
+  int *p = &leaked_x;
+  return ^void(void) {
+*p = 1; 
+  };
+  // expected-warning@-3 {{Address of stack memory associated with local variable 'leaked_x' \
+might leak via the block capture}}
+}
+
+void test_returned_from_func_block_async() {
+  dispatch_async(queue, get_leaking_block());
+  // expected-warning@-1 {{Address of stack memory associated with local variable 'leaked_x' \
+might leak via the block capture}}
+}
+
+// synchronous, no leak
+void test_block_var_once() {
+  int x = 123;
+  int *p = &x;
+  void (^b)(void) = ^void(void) {
+*p = 1; 
+  };
+  // no leak
+  dispatch_once(predicate, b);
+}
+
+void test_block_var_after() {
+  int x = 123;
+  int *p = &x;
+  void (^b)(void) = ^void(void) {
+*p = 1; 
+  };
+  dispatch_after(when, queue, b);
+  // expected-warning@-1 {{Address of stack memory associated with local variable 'x' \
+might leak via the block capture}}
+}
+
+void test_block_var_async_no_leak() {
+  int x = 123;
+  int *p = &x;
+  void (^b)(void) = ^void(void) {
+int y = x;
+++y; 
+  };
+  // no leak
+  dispatch_async(queue, b);
+}
+
+void test_block_inside_block_async_no_leak() {
+  int x = 123;
+  int *p = &x;
+  void (^inner)(void) = ^void(void) {
+int y = x;
+++y; 
+  };
+  void (^outer)(void) = ^void(void) {
+int z = x;
+++z;
+inner(); 
+  };
+  // no leak
+  dispatch_async(queue, outer);
+}
+
Index: lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp
+++ lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp
@@ -18,23 +18,28 @@
 #include "clang/StaticAnalyzer/Core/BugReporter/BugType.h"
 #include "clang/StaticAnalyzer/Core/Checker.h"
 #include "clang/StaticAnalyzer/Core/CheckerManager.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h"
 #include "llvm/ADT/SmallString.h"
 #include "llvm/Support/raw_ostream.h"
 using namespace clang;
 using namespace ento;
 
 namespace {
-class StackAddrEscapeChecker : public Checker< check::PreStmt,
+class StackAddrEscapeChecker : public Checker< check::PreCall,
+   check::PreStmt,
check::EndFunction > {
   mutable std::unique_ptr BT_stackleak;
   mutable std::unique_ptr BT_returnstack;
+  mutable std::unique_ptr BT_capturestackleak;
 
 public:
+  void checkPreCall(const CallEvent &Call, CheckerContext &C) const;
   void checkPreStmt(const ReturnStmt *RS, CheckerContext &C) const;
   void checkEndFunction(CheckerContext &Ctx) const;
 private:
+  void checkBlockCaptures(const BlockDataRe

r317073 - Change assertion to quick exit from checking function.

2017-10-31 Thread Richard Trieu via cfe-commits
Author: rtrieu
Date: Tue Oct 31 20:57:27 2017
New Revision: 317073

URL: http://llvm.org/viewvc/llvm-project?rev=317073&view=rev
Log:
Change assertion to quick exit from checking function.

Remove the assertion that could be triggered by invalid code.  Replace it with
an early exit from the checking function.

Modified:
cfe/trunk/lib/Sema/SemaDeclCXX.cpp
cfe/trunk/test/SemaCXX/missing-members.cpp

Modified: cfe/trunk/lib/Sema/SemaDeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclCXX.cpp?rev=317073&r1=317072&r2=317073&view=diff
==
--- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Tue Oct 31 20:57:27 2017
@@ -2555,9 +2555,8 @@ Sema::CheckDerivedToBaseConversion(QualT
   CXXBasePaths Paths(/*FindAmbiguities=*/true, /*RecordPaths=*/true,
  /*DetectVirtual=*/false);
   bool DerivationOkay = IsDerivedFrom(Loc, Derived, Base, Paths);
-  assert(DerivationOkay &&
- "Can only be used with a derived-to-base conversion");
-  (void)DerivationOkay;
+  if (!DerivationOkay)
+return true;
 
   const CXXBasePath *Path = nullptr;
   if (!Paths.isAmbiguous(Context.getCanonicalType(Base).getUnqualifiedType()))

Modified: cfe/trunk/test/SemaCXX/missing-members.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/missing-members.cpp?rev=317073&r1=317072&r2=317073&view=diff
==
--- cfe/trunk/test/SemaCXX/missing-members.cpp (original)
+++ cfe/trunk/test/SemaCXX/missing-members.cpp Tue Oct 31 20:57:27 2017
@@ -37,3 +37,17 @@ struct S : A::B::C {
   using A::B::C::f; // expected-error {{no member named 'f' in 'A::B::C'}}
   
 };
+
+struct S1 {};
+
+struct S2 : S1 {};
+
+struct S3 : S2 {
+  void run();
+};
+
+struct S4: S3 {};
+
+void test(S4 *ptr) {
+  ptr->S1::run();  // expected-error {{no member named 'run' in 'S1'}}
+}


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


[libcxx] r317074 - More statuses, a new patch, too

2017-10-31 Thread Marshall Clow via cfe-commits
Author: marshall
Date: Tue Oct 31 21:03:35 2017
New Revision: 317074

URL: http://llvm.org/viewvc/llvm-project?rev=317074&view=rev
Log:
More statuses, a new patch, too

Modified:
libcxx/trunk/www/upcoming_meeting.html

Modified: libcxx/trunk/www/upcoming_meeting.html
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/www/upcoming_meeting.html?rev=317074&r1=317073&r2=317074&view=diff
==
--- libcxx/trunk/www/upcoming_meeting.html (original)
+++ libcxx/trunk/www/upcoming_meeting.html Tue Oct 31 21:03:35 2017
@@ -32,11 +32,11 @@
 
 
   
-  libc++ Issaquah Status
+  libc++ Upcoming Metting Status
   
 
   This is a temporary page; please check the c++1z status here
-  This page shows the status of the papers and issues that are expected to 
be adopted in Toronto.
+  This page shows the status of the papers and issues that are expected to 
be adopted in the next WG21 Meeting.
 
   The groups that have contributed papers:
   
@@ -62,12 +62,12 @@
https://wg21.link/LWG2779";>2779[networking.ts] Relax 
requirements on buffer sequence iteratorsAlbuquerque
https://wg21.link/LWG2870";>2870Default 
value of parameter theta of polar should be 
dependentAlbuquerque
https://wg21.link/LWG2935";>2935What 
should create_directories do when p already exists but is not a 
directory?Albuquerque
-   https://wg21.link/LWG2941";>2941§[thread.req.timing] wording 
should apply to both member and namespace-level 
functionsAlbuquerque
-   https://wg21.link/LWG2944";>2944LWG 2905 
accidentally removed requirement that construction of the deleter doesn't throw 
an exceptionAlbuquerque
-   https://wg21.link/LWG2945";>2945Order of 
template parameters in optional 
comparisonsAlbuquerque
+   https://wg21.link/LWG2941";>2941[thread.req.timing] wording 
should apply to both member and namespace-level 
functionsAlbuquerqueNothing to do
+   https://wg21.link/LWG2944";>2944LWG 2905 
accidentally removed requirement that construction of the deleter doesn't throw 
an exceptionAlbuquerqueNothing to do
+   https://wg21.link/LWG2945";>2945Order of 
template parameters in optional 
comparisonsAlbuquerqueComplete
https://wg21.link/LWG2948";>2948unique_ptr 
does not define operator<< for stream 
outputAlbuquerque
https://wg21.link/LWG2950";>2950std::byte 
operations are misspecifiedAlbuquerquePatch Ready
-   https://wg21.link/LWG2952";>2952iterator_traits should work 
for pointers to cv TAlbuquerque
+   https://wg21.link/LWG2952";>2952iterator_traits should work 
for pointers to cv TAlbuquerquePatch ready
https://wg21.link/LWG2953";>2953LWG 2853 
should apply to deque::erase tooAlbuquerque
https://wg21.link/LWG2964";>2964Apparently 
redundant requirement for 
dynamic_pointer_castAlbuquerque
https://wg21.link/LWG2965";>2965Non-existing 
path::native_string() in filesystem_error::what() 
specificationAlbuquerque
@@ -81,7 +81,7 @@
https://wg21.link/LWG2982";>2982Making 
size_type consistent in associative container deduction 
guidesAlbuquerque
https://wg21.link/LWG2988";>2988Clause 32 
cleanup missed one typenameAlbuquerque
https://wg21.link/LWG2993";>2993reference_wrapper 
conversion from T&&Albuquerque
-   https://wg21.link/LWG2998";>2998Requirements on function 
objects passed to {forward_,}list-specific 
algorithmsAlbuquerqueComplete
+   https://wg21.link/LWG2998";>2998Requirements on function 
objects passed to {forward_,}list-specific 
algorithmsAlbuquerqueNothing to do
https://wg21.link/LWG3001";>3001weak_ptr::element_type needs 
remove_extent_tAlbuquerque
https://wg21.link/LWG3024";>3024variant's 
copies must be deleted instead of disabled via 
SFINAEAlbuquerque
 
@@ -92,12 +92,12 @@
 2779 - 
 2870 - We already default to T(0); but the PR says T(). 
Later - this makes no difference at all; since T has to be float/double/long 
double
 2935 - Eric? 
-2941 - Looks like wording changes; need to check to be sure.
-2944 - Definitely just wording changes. 
-2945 - Looks like we already do it; needs a close look to be sure.
+2941 - Wording cleanup; nothing to do.
+2944 - Wording cleanup; nothing to do. 
+2945 - Synopsis was wrong; code was fine. Fixed in r317063
 2948 - 
 2950 - Patch ready
-2952 - 
+2952 - Patch ready
 2953 - Probably just wording; check to be sure.
 2964 - At the very least, it needs a test.
 2965 - Eric? 


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


[PATCH] D39438: [analyzer] Diagnose stack leaks via block captures

2017-10-31 Thread Devin Coughlin via Phabricator via cfe-commits
dcoughlin added a reviewer: george.karpenkov.
dcoughlin added a comment.

I think this is a great idea, and I expect it to find some nasty bugs!

However, I'm worried about false positives in the following not-too-uncommon 
idiom:

  dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);
  dispatch_async(some_queue, ^{
  
// Do some work
  
dispatch_semaphore_signal(semaphore);
  });
  
  // Do some other work concurrently with the asynchronous work
  
  // Wait for the asynchronous work to finish
  dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);

What do you think about suppressing the diagnostic when the block captures a 
variable with type 'dispatch_semaphore_t'? This isn't a perfect suppression, 
but it will catch most of the cases that I have seen.

Also, does this checker diagnose when a block captures a C++ reference? If so, 
it would be great to add a test for that!

Some additional comments inline.




Comment at: lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp:124
 
+void StackAddrEscapeChecker::checkBlockCaptures(const BlockDataRegion &B,
+CheckerContext &C) const {

Could we break with tradition and add a oxygen comment describing what this 
method does?



Comment at: lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp:133
+  continue;
+if (C.getASTContext().getLangOpts().ObjCAutoRefCount &&
+isa(Region))

Can you factor this logic out with the logic it duplicates in checkPreStmt()?



Comment at: lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp:136
+  continue;
+if (dyn_cast(Region->getMemorySpace())) {
+  ExplodedNode *N = C.generateNonFatalErrorNode();

Stylistically we use isa<> for cases like these where the result of dyn_cast<> 
is not used.



Comment at: lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp:146
+  SourceRange Range = genName(Out, Region, C.getASTContext());
+  Out << " might leak via the block capture";
+  auto Report =

Instead of "might leak ... " I would suggest " is captured by an 
asynchronously-executed block". In the context of the analyzer we use "leak" to 
mean "resource that is not freed" rather than in the sense of exposing 
information.

You'll need to make a different variant of the diagnostic text for when the 
block is returned rather than asynchronously executed.



Comment at: lib/StaticAnalyzer/Checkers/StackAddrEscapeChecker.cpp:185
+  if (const BlockDataRegion *B = dyn_cast(R))
+checkBlockCaptures(*B, C); 
+

Will this have a false positive if I create a block in a caller, pass it to a 
callee, and then the callee returns it? You may want to factor out and reuse 
the logic from below that compares the StackFrameContext for the current frame 
to the frame of the captured addresses in checkBlockCaptures().



Comment at: test/Analysis/stack-async-leak.m:1
+// RUN: %clang_analyze_cc1 -triple x86_64-apple-darwin10 
-analyzer-checker=core -fblocks -fobjc-arc -verify %s
+

Can you add an additional run line testing the expected behavior when ARC is 
not enabled? You can pass a -DARC_ENABLED=1 or similar to distinguish between 
the two (for example, to test to make sure that a diagnostic is emitted under 
MRR but not ARC).


Repository:
  rL LLVM

https://reviews.llvm.org/D39438



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


r317075 - clang/lib/Format/Format.cpp: Fix warnings introduced in rL316903. [-Wpedantic]

2017-10-31 Thread NAKAMURA Takumi via cfe-commits
Author: chapuni
Date: Tue Oct 31 21:43:22 2017
New Revision: 317075

URL: http://llvm.org/viewvc/llvm-project?rev=317075&view=rev
Log:
clang/lib/Format/Format.cpp: Fix warnings introduced in rL316903. [-Wpedantic]

Modified:
cfe/trunk/lib/Format/Format.cpp

Modified: cfe/trunk/lib/Format/Format.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/Format.cpp?rev=317075&r1=317074&r2=317075&view=diff
==
--- cfe/trunk/lib/Format/Format.cpp (original)
+++ cfe/trunk/lib/Format/Format.cpp Tue Oct 31 21:43:22 2017
@@ -45,8 +45,8 @@
 
 using clang::format::FormatStyle;
 
-LLVM_YAML_IS_SEQUENCE_VECTOR(clang::format::FormatStyle::IncludeCategory);
-LLVM_YAML_IS_SEQUENCE_VECTOR(clang::format::FormatStyle::RawStringFormat);
+LLVM_YAML_IS_SEQUENCE_VECTOR(clang::format::FormatStyle::IncludeCategory)
+LLVM_YAML_IS_SEQUENCE_VECTOR(clang::format::FormatStyle::RawStringFormat)
 
 namespace llvm {
 namespace yaml {


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


r317076 - Fix -Wunused-private-field to fire regardless of which implicit special members have been implicitly declared.

2017-10-31 Thread Richard Smith via cfe-commits
Author: rsmith
Date: Tue Oct 31 21:52:12 2017
New Revision: 317076

URL: http://llvm.org/viewvc/llvm-project?rev=317076&view=rev
Log:
Fix -Wunused-private-field to fire regardless of which implicit special members 
have been implicitly declared.

Modified:
cfe/trunk/lib/Sema/Sema.cpp
cfe/trunk/lib/Sema/SemaExprMember.cpp
cfe/trunk/test/SemaCXX/unused.cpp
cfe/trunk/test/SemaCXX/warn-unused-private-field.cpp

Modified: cfe/trunk/lib/Sema/Sema.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/Sema.cpp?rev=317076&r1=317075&r2=317076&view=diff
==
--- cfe/trunk/lib/Sema/Sema.cpp (original)
+++ cfe/trunk/lib/Sema/Sema.cpp Tue Oct 31 21:52:12 2017
@@ -737,7 +737,8 @@ static bool MethodsAndNestedClassesCompl
   E = RD->decls_end();
I != E && Complete; ++I) {
 if (const CXXMethodDecl *M = dyn_cast(*I))
-  Complete = M->isDefined() || (M->isPure() && !isa(M));
+  Complete = M->isDefined() || M->isDefaulted() ||
+ (M->isPure() && !isa(M));
 else if (const FunctionTemplateDecl *F = 
dyn_cast(*I))
   // If the template function is marked as late template parsed at this
   // point, it has not been instantiated and therefore we have not

Modified: cfe/trunk/lib/Sema/SemaExprMember.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExprMember.cpp?rev=317076&r1=317075&r2=317076&view=diff
==
--- cfe/trunk/lib/Sema/SemaExprMember.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExprMember.cpp Tue Oct 31 21:52:12 2017
@@ -1791,7 +1791,9 @@ Sema::BuildFieldReferenceExpr(Expr *Base
   MemberType = Context.getQualifiedType(MemberType, Combined);
   }
 
-  UnusedPrivateFields.remove(Field);
+  auto *CurMethod = dyn_cast(CurContext);
+  if (!(CurMethod && CurMethod->isDefaulted()))
+UnusedPrivateFields.remove(Field);
 
   ExprResult Base = PerformObjectMemberConversion(BaseExpr, SS.getScopeRep(),
   FoundDecl, Field);

Modified: cfe/trunk/test/SemaCXX/unused.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/unused.cpp?rev=317076&r1=317075&r2=317076&view=diff
==
--- cfe/trunk/test/SemaCXX/unused.cpp (original)
+++ cfe/trunk/test/SemaCXX/unused.cpp Tue Oct 31 21:52:12 2017
@@ -6,7 +6,7 @@
 // PR4103 : Make sure we don't get a bogus unused expression warning
 namespace PR4103 {
   class APInt {
-char foo;
+char foo; // expected-warning {{private field 'foo' is not used}}
   };
   class APSInt : public APInt {
 char bar; // expected-warning {{private field 'bar' is not used}}

Modified: cfe/trunk/test/SemaCXX/warn-unused-private-field.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/warn-unused-private-field.cpp?rev=317076&r1=317075&r2=317076&view=diff
==
--- cfe/trunk/test/SemaCXX/warn-unused-private-field.cpp (original)
+++ cfe/trunk/test/SemaCXX/warn-unused-private-field.cpp Tue Oct 31 21:52:12 
2017
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -fsyntax-only -Wunused-private-field 
-Wused-but-marked-unused -Wno-uninitialized -verify -std=c++11 %s
+// RUN: %clang_cc1 -fsyntax-only -Wunused-private-field 
-Wused-but-marked-unused -Wno-uninitialized -verify -std=c++17 %s
 
 class NotFullyDefined {
  public:
@@ -246,3 +247,19 @@ namespace pr13543 {
 X x[4]; // no-warning
   };
 }
+
+class implicit_special_member {
+public:
+  static implicit_special_member make() { return implicit_special_member(); }
+
+private:
+  int n; // expected-warning{{private field 'n' is not used}}
+};
+
+class defaulted_special_member {
+public:
+  defaulted_special_member(const defaulted_special_member&) = default;
+
+private:
+  int n; // expected-warning{{private field 'n' is not used}}
+};


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