[PATCH] D36728: Switch to consumeError(), since this can crash otherwise.

2017-08-14 Thread Stephen Hines via Phabricator via cfe-commits
srhines added a comment.

https://reviews.llvm.org/D36729 similarly fixes a few more instances of this 
problem (discovered while running tests for this configuration).


https://reviews.llvm.org/D36728



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


[PATCH] D36580: [OpenCL] Support variable memory scope in atomic builtins

2017-08-14 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl marked 6 inline comments as done.
yaxunl added inline comments.



Comment at: include/clang/Basic/SyncScope.h:92
+/// \brief Defines the synch scope ABI for OpenCL.
+class AtomicScopeOpenCLABI : public AtomicScopeABI {
+public:

rjmccall wrote:
> yaxunl wrote:
> > rjmccall wrote:
> > > yaxunl wrote:
> > > > rjmccall wrote:
> > > > > Please correct me if I'm wrong, but I believe you don't get to define 
> > > > > the "ABI for OpenCL" any more than I get to define the "ABI for C".  
> > > > > You're defining the ABI for your specific OpenCL implementation, but 
> > > > > Clang might reasonably support other implementations with their own 
> > > > > ABIs.  So this name is inappropriate.
> > > > > 
> > > > > Now, if I understand how SPIR works, SPIR does require some sort of 
> > > > > stable lowering of these atomic operations in order to ensure that 
> > > > > the resulting LLVM IR can be ingested into an arbitrary 
> > > > > implementation.  (Ot at least that was true prior to SPIR V?)  
> > > > > Therefore, SPIR needs to specify a lowering for these atomic 
> > > > > operations, and that probably includes ABI values for specific 
> > > > > sync-scopes.  But the appropriate name for that would be the "SPIR 
> > > > > ABI", not the "OpenCL ABI".  And, of course, you would need to be 
> > > > > sure that you're implementing the lowering that SPIR actually wants.
> > > > The ABI is not intended for a specific OpenCL implementation, but for 
> > > > extending to other languages. For example, we have a downstream C++ 
> > > > based language called HCC, which may support atomic scope with an ABI 
> > > > different than OpenCL atomic scope ABI.
> > > By "ABI" you mean that it might present a different model of 
> > > synchronization scopes to the source language?  Okay, that's great, and 
> > > it explains a lot of things that were very murky about some of our 
> > > previous conversations.
> > > 
> > > In that case, I think the appropriate design for these builtins is:
> > > 
> > >   - They don't need to be in the __builtin_opencl namespace.
> > >   - They *do* need to be enabled only in language modes with well-defined 
> > > sync-scope models, which for now just means OpenCL. 
> > >   - The language mode's sync-scope model should determine everything 
> > > about the scope argument, including its type.  Sema-level validation 
> > > requires first determining the language's sync-scope model.
> > >   - There is no meaningful way to "default" the scope argument on the 
> > > non-scoped builtins the way that we are now.  Instead, the scope argument 
> > > should only exist for the scoped builtins.
> > > 
> > > Alternatively, if you potentially want the opencl-model builtins to be 
> > > usable from non-opencl languages, the right design is for HCC to use its 
> > > own set of builtins with their own type-checking rules.
> > > 
> > > In either case, I don't think it's a good idea to call this "ABI", which 
> > > is associated too strongly with target-lowering concepts.  You're really 
> > > talking about a source-language concept.
> > We could introduce __builtin_hcc_atomic_* in downstream HCC.
> > 
> > We need a generic approach to represent atomic scope values for different 
> > languages and associated semantic/codegen needs, and AtomicScopeABI seems 
> > generic enough to serve the purpose. It has interface for semantic checking 
> > (isValid), and the interface to map to LLVM sync scope for both constant 
> > and variable arguments. If the name is not proper, we could rename it to 
> > just `AtomicScope`.
> > 
> > I can remove the default atomic scope for atomic expressions without scope 
> > originally. For them I just emit LLVM atomic instructions with default LLVM 
> > synch scope.
> I agree that there's value in having a generic approach even if you're going 
> to have different builtins for different scope models.  However, if you do 
> use different builtins for different scope models, you need to make sure that 
> you pick the appropriate model for the builtin being used, not according to 
> the current language mode.  That is, there should be some way to map a 
> builtin ID to an AtomicScopeModelKind (values: None, OpenCL, (future) HCC), 
> and then you can use that to create an AtomicScopeModel, which can have all 
> these methods on it.
> 
> I would encourage you to go ahead and give AtomicScopeModel an implementation 
> file and move more of these method definitions into that.
Thanks. Will do.



Comment at: include/clang/Basic/SyncScope.h:105
+
+  AtomicScopeOpenCLABI() {}
+

rjmccall wrote:
> I would call this OpenCLAtomicScopeModel.
Will do.



Comment at: include/clang/Basic/SyncScope.h:128
+static_assert(Last == SubGroup, "Does not include all synch scopes");
+static unsigned Scopes[] = {
+static_cast(WorkGroup), static_cast(Device),

rjmccall wrote:
> Make this const, please.

[PATCH] D22189: llvm.noalias - Clang CodeGen - check restrict variable map only for restrict-qualified lvalues

2017-08-14 Thread Hal Finkel via Phabricator via cfe-commits
hfinkel updated this revision to Diff 30.
hfinkel added a comment.
Herald added a subscriber: jholewinski.

Rebased.


https://reviews.llvm.org/D22189

Files:
  lib/CodeGen/CGDeclCXX.cpp
  lib/CodeGen/CGExpr.cpp
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
  lib/CodeGen/CGStmtOpenMP.cpp
  lib/CodeGen/CodeGenFunction.h

Index: lib/CodeGen/CodeGenFunction.h
===
--- lib/CodeGen/CodeGenFunction.h
+++ lib/CodeGen/CodeGenFunction.h
@@ -3150,7 +3150,7 @@
   /// care to appropriately convert from the memory representation to
   /// the LLVM value representation.
   void EmitStoreOfScalar(llvm::Value *Value, Address Addr,
- bool Volatile, QualType Ty,
+ bool Volatile, bool Restrict, QualType Ty,
  LValueBaseInfo BaseInfo =
  LValueBaseInfo(AlignmentSource::Type),
  llvm::MDNode *TBAAInfo = nullptr, bool isInit = false,
Index: lib/CodeGen/CGStmtOpenMP.cpp
===
--- lib/CodeGen/CGStmtOpenMP.cpp
+++ lib/CodeGen/CGStmtOpenMP.cpp
@@ -364,7 +364,8 @@
 Address RefAddr = CGF.CreateMemTemp(
 CurVD->getType(), CGM.getPointerAlign(), ".materialized_ref");
 CGF.EmitStoreOfScalar(LocalAddr.getPointer(), RefAddr,
-  /*Volatile=*/false, CurVD->getType());
+  /*Volatile=*/false, /*Restrict=*/false,
+  CurVD->getType());
 LocalAddr = RefAddr;
   }
   if (!FO.RegisterCastedArgsOnly)
@@ -2964,7 +2965,8 @@
   const auto *VD = cast(cast(E)->getDecl());
   CGF.EmitVarDecl(*VD);
   CGF.EmitStoreOfScalar(ReductionDesc, CGF.GetAddrOfLocalVar(VD),
-/*Volatile=*/false, E->getType());
+/*Volatile=*/false, /*Restrict=*/false,
+E->getType());
 }
 CGF.EmitStmt(cast(S.getAssociatedStmt())->getCapturedStmt());
   };
Index: lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
===
--- lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
+++ lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
@@ -1180,7 +1180,7 @@
 
 // Store the source element value to the dest element address.
 CGF.EmitStoreOfScalar(Elem, DestElementAddr, /*Volatile=*/false,
-  Private->getType());
+  /*Restrict=*/false, Private->getType());
 
 // Step 3.1: Modify reference in dest Reduce list as needed.
 // Modifying the reference in Reduce list to point to the newly
@@ -1191,7 +1191,7 @@
   CGF.EmitStoreOfScalar(Bld.CreatePointerBitCastOrAddrSpaceCast(
 DestElementAddr.getPointer(), CGF.VoidPtrTy),
 DestElementPtrAddr, /*Volatile=*/false,
-C.VoidPtrTy);
+/*Restrict=*/false, C.VoidPtrTy);
 }
 
 // Step 4.1: Increment SrcBase/DestBase so that it points to the starting
@@ -1618,7 +1618,7 @@
 
 // *TargetElemPtr = SrcMediumVal;
 CGF.EmitStoreOfScalar(SrcMediumValue, TargetElemPtr, /*Volatile=*/false,
-  Private->getType());
+  /*Restrict=*/false, Private->getType());
 Bld.CreateBr(W0MergeBB);
 
 CGF.EmitBlock(W0ElseBB);
@@ -2287,7 +2287,7 @@
   NativePointeeAddrSpace));
   Address NativeParamAddr = CGF.CreateMemTemp(NativeParamType);
   CGF.EmitStoreOfScalar(TargetAddr, NativeParamAddr, /*Volatile=*/false,
-NativeParam->getType());
+/*Restrict=*/false, NativeParam->getType());
   return NativeParamAddr;
 }
 
Index: lib/CodeGen/CGOpenMPRuntime.cpp
===
--- lib/CodeGen/CGOpenMPRuntime.cpp
+++ lib/CodeGen/CGOpenMPRuntime.cpp
@@ -7741,7 +7741,8 @@
  CounterVal->getType(), Int64Ty,
  CounterVal->getExprLoc());
   Address CntAddr = CGF.CreateMemTemp(Int64Ty, ".cnt.addr");
-  CGF.EmitStoreOfScalar(CntVal, CntAddr, /*Volatile=*/false, Int64Ty);
+  CGF.EmitStoreOfScalar(CntVal, CntAddr, /*Volatile=*/false, /*Restrict=*/false,
+Int64Ty);
   llvm::Value *Args[] = {emitUpdateLocation(CGF, C->getLocStart()),
  getThreadID(CGF, C->getLocStart()),
  CntAddr.getPointer()};
Index: lib/CodeGen/CGExpr.cpp
===
--- lib/CodeGen/CGExpr.cpp
+++ lib/CodeGen/CGExpr.cpp
@@ -1540,8 +1540,8 @@
 }
 
 void CodeGenFunction::EmitStoreOfScalar(llvm::Value *Value, Address Addr,
-bool Volatile, QualType Ty,
-

[PATCH] D9403: llvm.noalias - Clang CodeGen for local restrict-qualified pointers

2017-08-14 Thread Hal Finkel via Phabricator via cfe-commits
hfinkel updated this revision to Diff 29.
hfinkel added a comment.
Herald added a subscriber: javed.absar.

Rebased and addressing review comments.


https://reviews.llvm.org/D9403

Files:
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGExpr.cpp
  lib/CodeGen/CGStmt.cpp
  lib/CodeGen/CodeGenFunction.cpp
  lib/CodeGen/CodeGenFunction.h
  test/CodeGen/arm_neon_intrinsics.c
  test/CodeGen/noalias.c
  test/OpenMP/taskloop_firstprivate_codegen.cpp
  test/OpenMP/taskloop_lastprivate_codegen.cpp
  test/OpenMP/taskloop_private_codegen.cpp
  test/OpenMP/taskloop_simd_firstprivate_codegen.cpp
  test/OpenMP/taskloop_simd_lastprivate_codegen.cpp
  test/OpenMP/taskloop_simd_private_codegen.cpp

Index: test/OpenMP/taskloop_simd_private_codegen.cpp
===
--- test/OpenMP/taskloop_simd_private_codegen.cpp
+++ test/OpenMP/taskloop_simd_private_codegen.cpp
@@ -222,7 +222,8 @@
 // CHECK: [[PRIV_S_ARR_ADDR:%.+]] = alloca [2 x [[S_DOUBLE_TY]]]*,
 // CHECK: [[PRIV_VEC_ADDR:%.+]] = alloca [2 x i32]*,
 // CHECK: [[PRIV_SIVAR_ADDR:%.+]] = alloca i32*,
-// CHECK: store void (i8*, ...)* bitcast (void ([[PRIVATES_MAIN_TY]]*, [[S_DOUBLE_TY]]**, i32**, [2 x [[S_DOUBLE_TY]]]**, [2 x i32]**, i32**)* [[PRIVATES_MAP_FN]] to void (i8*, ...)*), void (i8*, ...)** [[MAP_FN_ADDR:%.+]],
+// CHECK: [[PRIV_NAFP:%.+]] = call void (i8*, ...)* @llvm.noalias.p0f_isVoidp0i8varargf(void (i8*, ...)* bitcast (void ([[PRIVATES_MAIN_TY]]*, [[S_DOUBLE_TY]]**, i32**, [2 x [[S_DOUBLE_TY]]]**, [2 x i32]**, i32**)* [[PRIVATES_MAP_FN]] to void (i8*, ...)*),
+// CHECK: store void (i8*, ...)* [[PRIV_NAFP]], void (i8*, ...)** [[MAP_FN_ADDR:%.+]],
 // CHECK: [[MAP_FN:%.+]] = load void (i8*, ...)*, void (i8*, ...)** [[MAP_FN_ADDR]],
 // CHECK: call void (i8*, ...) [[MAP_FN]](i8* %{{.+}}, [[S_DOUBLE_TY]]** [[PRIV_VAR_ADDR]], i32** [[PRIV_T_VAR_ADDR]], [2 x [[S_DOUBLE_TY]]]** [[PRIV_S_ARR_ADDR]], [2 x i32]** [[PRIV_VEC_ADDR]], i32** [[PRIV_SIVAR_ADDR]])
 // CHECK: [[PRIV_VAR:%.+]] = load [[S_DOUBLE_TY]]*, [[S_DOUBLE_TY]]** [[PRIV_VAR_ADDR]],
@@ -350,7 +351,8 @@
 // CHECK-DAG: [[PRIV_VEC_ADDR:%.+]] = alloca [2 x i32]*,
 // CHECK-DAG: [[PRIV_S_ARR_ADDR:%.+]] = alloca [2 x [[S_INT_TY]]]*,
 // CHECK-DAG: [[PRIV_VAR_ADDR:%.+]] = alloca [[S_INT_TY]]*,
-// CHECK: store void (i8*, ...)* bitcast (void ([[PRIVATES_TMAIN_TY]]*, i32**, [2 x i32]**, [2 x [[S_INT_TY]]]**, [[S_INT_TY]]**)* [[PRIVATES_MAP_FN]] to void (i8*, ...)*), void (i8*, ...)** [[MAP_FN_ADDR:%.+]],
+// CHECK: [[PRIV_NAFP:%.+]] = call void (i8*, ...)* @llvm.noalias.p0f_isVoidp0i8varargf(void (i8*, ...)* bitcast (void ([[PRIVATES_TMAIN_TY]]*, i32**, [2 x i32]**, [2 x [[S_INT_TY]]]**, [[S_INT_TY]]**)* [[PRIVATES_MAP_FN]] to void (i8*, ...)*),
+// CHECK: store void (i8*, ...)* [[PRIV_NAFP]], void (i8*, ...)** [[MAP_FN_ADDR:%.+]],
 // CHECK: [[MAP_FN:%.+]] = load void (i8*, ...)*, void (i8*, ...)** [[MAP_FN_ADDR]],
 // CHECK: call void (i8*, ...) [[MAP_FN]](i8* %{{.+}}, i32** [[PRIV_T_VAR_ADDR]], [2 x i32]** [[PRIV_VEC_ADDR]], [2 x [[S_INT_TY]]]** [[PRIV_S_ARR_ADDR]], [[S_INT_TY]]** [[PRIV_VAR_ADDR]])
 // CHECK: [[PRIV_T_VAR:%.+]] = load i32*, i32** [[PRIV_T_VAR_ADDR]],
Index: test/OpenMP/taskloop_simd_lastprivate_codegen.cpp
===
--- test/OpenMP/taskloop_simd_lastprivate_codegen.cpp
+++ test/OpenMP/taskloop_simd_lastprivate_codegen.cpp
@@ -257,7 +257,8 @@
 // CHECK: [[PRIV_S_ARR_ADDR:%.+]] = alloca [2 x [[S_DOUBLE_TY]]]*,
 // CHECK: [[PRIV_VEC_ADDR:%.+]] = alloca [2 x i32]*,
 // CHECK: [[PRIV_SIVAR_ADDR:%.+]] = alloca i32*,
-// CHECK: store void (i8*, ...)* bitcast (void ([[PRIVATES_MAIN_TY]]*, [[S_DOUBLE_TY]]**, i32**, [2 x [[S_DOUBLE_TY]]]**, [2 x i32]**, i32**)* [[PRIVATES_MAP_FN]] to void (i8*, ...)*), void (i8*, ...)** [[MAP_FN_ADDR:%.+]],
+// CHECK: [[PRIV_NAFP:%.+]] = call void (i8*, ...)* @llvm.noalias.p0f_isVoidp0i8varargf(void (i8*, ...)* bitcast (void ([[PRIVATES_MAIN_TY]]*, [[S_DOUBLE_TY]]**, i32**, [2 x [[S_DOUBLE_TY]]]**, [2 x i32]**, i32**)* [[PRIVATES_MAP_FN]] to void (i8*, ...)*),
+// CHECK: store void (i8*, ...)* [[PRIV_NAFP]], void (i8*, ...)** [[MAP_FN_ADDR:%.+]],
 // CHECK: [[MAP_FN:%.+]] = load void (i8*, ...)*, void (i8*, ...)** [[MAP_FN_ADDR]],
 
 // CHECK: call void (i8*, ...) [[MAP_FN]](i8* %{{.+}}, [[S_DOUBLE_TY]]** [[PRIV_VAR_ADDR]], i32** [[PRIV_T_VAR_ADDR]], [2 x [[S_DOUBLE_TY]]]** [[PRIV_S_ARR_ADDR]], [2 x i32]** [[PRIV_VEC_ADDR]], i32** [[PRIV_SIVAR_ADDR]])
@@ -425,7 +426,8 @@
 // CHECK-DAG: [[PRIV_VEC_ADDR:%.+]] = alloca [2 x i32]*,
 // CHECK-DAG: [[PRIV_S_ARR_ADDR:%.+]] = alloca [2 x [[S_INT_TY]]]*,
 // CHECK-DAG: [[PRIV_VAR_ADDR:%.+]] = alloca [[S_INT_TY]]*,
-// CHECK: store void (i8*, ...)* bitcast (void ([[PRIVATES_TMAIN_TY]]*, i32**, [2 x i32]**, [2 x [[S_INT_TY]]]**, [[S_INT_TY]]**)* [[PRIVATES_MAP_FN]] to void (i8*, ...)*), void (i8*, ...)** [[MAP_FN_ADDR:%.+]],
+// CHECK: [[PRIV_NAFP:%.+]] = call void (i8*, ...)* @llvm.noalias.p0f_isVoidp0i8varargf(void 

[PATCH] D9403: llvm.noalias - Clang CodeGen for local restrict-qualified pointers

2017-08-14 Thread Hal Finkel via Phabricator via cfe-commits
hfinkel added inline comments.



Comment at: lib/CodeGen/CGDecl.cpp:1291
+// where the pointer to the local variable is the key in the map.
+void CodeGenFunction::EmitAutoVarNoAlias(const AutoVarEmission ) {
+  assert(emission.Variable && "emission was not valid!");

rjmccall wrote:
> This should really be a subroutine of EmitAutoVarAlloca; that will implicitly 
> pick this logic up for a bunch of less standard places in IRGen that create 
> local variables.  Please make it a static function (if possible) called 
> EmitNoAliasScope and call it immediately after EmitVarAnnotations.
Done (I didn't make it static, which is certainly possible, but didn't look 
much cleaner to me - let me know if you want it static anyway).



Comment at: lib/CodeGen/CGStmt.cpp:537
+  llvm::LLVMContext::MD_noalias),
+  NewScopeList));
+

rjmccall wrote:
> rjmccall wrote:
> > hfinkel wrote:
> > > rjmccall wrote:
> > > > This is a very strange representation.  Every memory operation in the 
> > > > lexical block is annotated with a list of all of the scopes that were 
> > > > entered within the block, even if they were entered after the 
> > > > operation.  But for some reason, not with nested scopes?
> > > > 
> > > > What's the right patch for me to read about this representation?
> > > Perhaps unfortunately, this is an artifact of the way that restrict is 
> > > defined in C. It applies to all accesses in the block in which the 
> > > variable is declared, even those before the declaration of the 
> > > restrict-qualified local itself.
> > > 
> > > It should work with nested scopes, in the sense that we add these things 
> > > as we complete each scope. So we add things to the inner scope, and then 
> > > when we complete the outer scope, we go back over the instructions 
> > > (including those in the inner scope because the scope recording recurses 
> > > up the scope hierarchy), and adds the outer scopes - it concatenates them 
> > > to any added by the inner (nested) scopes.
> > > 
> > > The noalias intrinsic's LangRef updates are in D9375.
> > Ah, I see the recursion now.  Please add a comment explaining that 
> > expectation here.
> I would still like this comment.  It should be enough to explain how 
> MemoryInsts actually gets filled: there's a callback from inserting an 
> instruction which adds all memory instructions to every active lexical scope 
> that's recording them.
Added.



Comment at: lib/CodeGen/CodeGenFunction.cpp:1986
+  if (I->mayReadOrWriteMemory())
+recordMemoryInstruction(I);
 }

rjmccall wrote:
> This condition will include calls, which I assume is unnecessary (except 
> maybe memory intrinsics?).  More seriously, it will also include loads and 
> stores into allocas, which will sweep in all sorts of bookkeeping temporaries 
> that IRGen uses in more complex code-generation situations.  You might want 
> to consider ways to avoid recording this kind of instruction that are very 
> likely to just get immediately optimized away by e.g. mem2reg.
> 
> Please also modify LexicalScope so that it records whether there's any active 
> recording scope in the CodeGenFunction.  Lexical scopes are nested, so that 
> should be as easy as saving the current state when you enter a scope and 
> restoring it when you leave.  That will allow you to optimize this code by 
> completely bypassing the recursion and even the check for whether the 
> instruction is a memory instruction in the extremely common case of a 
> function with no restrict variables.
> 
> In general, a lot of things about this approach seem to have worryingly poor 
> asymptotic performance in the face of large functions or (especially) many 
> restrict variables.  (You could, for example, have chosen to have each memory 
> instruction link to its enclosing noalias scope, which would contain a link 
> to its enclosing scope and a list of the variables it directly declares.  
> This would be a more complex representation to consume, but it would not 
> require inherently quadratic frontend work building all these lists.)  The 
> only saving grace is that we expect very little code to using restrict, so it 
> becomes vital to ensure that your code is immediately short-circuited when 
> nothing is using restrict.
> This condition will include calls, which I assume is unnecessary (except 
> maybe memory intrinsics?). 

No, getting calls here was intentional. The AA implementation can specifically 
deal with calls (especially those that are known only to access memory given by 
their arguments).

> More seriously, it will also include loads and stores into allocas, which 
> will sweep in all sorts of bookkeeping temporaries that IRGen uses in more 
> complex code-generation situations. You might want to consider ways to avoid 
> recording this kind of instruction that are very likely 

[PATCH] D36642: [Lexer] Report more precise skipped regions (PR34166)

2017-08-14 Thread Vedant Kumar via Phabricator via cfe-commits
vsk updated this revision to Diff 13.
vsk added a comment.

Thanks for the review. I've updated the patch so that we do better with "#\" 
directives.


https://reviews.llvm.org/D36642

Files:
  include/clang/Lex/Preprocessor.h
  lib/Lex/PPDirectives.cpp
  test/CoverageMapping/preprocessor.c
  test/Index/skipped-ranges.c

Index: test/Index/skipped-ranges.c
===
--- test/Index/skipped-ranges.c
+++ test/Index/skipped-ranges.c
@@ -20,6 +20,6 @@
 #endif // cool
 
 // RUN: env CINDEXTEST_SHOW_SKIPPED_RANGES=1 c-index-test -test-annotate-tokens=%s:1:1:16:1 %s | FileCheck %s
-// CHECK: Skipping: [5:2 - 6:7]
-// CHECK: Skipping: [8:2 - 12:7]
-// CHECK: Skipping: [14:2 - 20:7]
+// CHECK: Skipping: [5:1 - 6:22]
+// CHECK: Skipping: [8:1 - 12:27]
+// CHECK: Skipping: [14:1 - 20:15]
Index: test/CoverageMapping/preprocessor.c
===
--- test/CoverageMapping/preprocessor.c
+++ test/CoverageMapping/preprocessor.c
@@ -3,7 +3,7 @@
  // CHECK: func
 void func() {// CHECK: File 0, [[@LINE]]:13 -> [[@LINE+5]]:2 = #0
   int i = 0;
-#ifdef MACRO // CHECK-NEXT: Skipped,File 0, [[@LINE]]:2 -> [[@LINE+2]]:2 = 0
+#ifdef MACRO // CHECK-NEXT: Skipped,File 0, [[@LINE]]:1 -> [[@LINE+2]]:7 = 0
   int x = i;
 #endif
 }
@@ -17,22 +17,53 @@
  // CHECK: main
 int main() { // CHECK-NEXT: File 0, [[@LINE]]:12 -> {{[0-9]+}}:2 = #0
   int i = 0;
-#if 0// CHECK-NEXT: Skipped,File 0, [[@LINE]]:2 -> [[@LINE+4]]:2 = 0
+#  if 0// CHECK-NEXT: Skipped,File 0, [[@LINE]]:1 -> [[@LINE+4]]:29 = 0
   if(i == 0) {
 i = 1;
   }
-#endif
+#  endif // Mark me skipped!
 
 #if 1
  // CHECK-NEXT: File 0, [[@LINE+1]]:6 -> [[@LINE+1]]:12 = #0
   if(i == 0) {   // CHECK-NEXT: File 0, [[@LINE]]:14 -> [[@LINE+2]]:4 = #1
 i = 1;
   }
-#else// CHECK-NEXT: Skipped,File 0, [[@LINE]]:2 -> [[@LINE+5]]:2 = 0
+#else// CHECK-NEXT: Skipped,File 0, [[@LINE]]:1 -> [[@LINE+5]]:7 = 0
   if(i == 1) {
 i = 0;
   }
 }
 #endif
+
+  // CHECK-NEXT: Skipped,File 0, [[@LINE+1]]:1 -> [[@LINE+4]]:24
+#\
+  if 0
+#\
+  endif // also skipped
+
+#if 1
+  // CHECK-NEXT: Skipped,File 0, [[@LINE+1]]:1 -> [[@LINE+3]]:7
+#\
+  elif 0
+#endif
+
+#if 1
+  // CHECK-NEXT: Skipped,File 0, [[@LINE+1]]:1 -> [[@LINE+3]]:7
+#\
+  else
+#endif
+
+  // CHECK-NEXT: Skipped,File 0, [[@LINE+1]]:1 -> [[@LINE+4]]:8
+#\
+  ifdef NOT_DEFINED
+#\
+  endif
+
+  // CHECK-NEXT: Skipped,File 0, [[@LINE+1]]:1 -> [[@LINE+4]]:8
+#\
+  ifndef __FILE__
+#\
+  endif
+
   return 0;
 }
Index: lib/Lex/PPDirectives.cpp
===
--- lib/Lex/PPDirectives.cpp
+++ lib/Lex/PPDirectives.cpp
@@ -350,7 +350,8 @@
 /// If ElseOk is true, then \#else directives are ok, if not, then we have
 /// already seen one so a \#else directive is a duplicate.  When this returns,
 /// the caller can lex the first valid token.
-void Preprocessor::SkipExcludedConditionalBlock(SourceLocation IfTokenLoc,
+void Preprocessor::SkipExcludedConditionalBlock(SourceLocation HashTokenLoc,
+SourceLocation IfTokenLoc,
 bool FoundNonSkipPortion,
 bool FoundElse,
 SourceLocation ElseLoc) {
@@ -559,8 +560,21 @@
   CurPPLexer->LexingRawMode = false;
 
   if (Callbacks) {
-SourceLocation BeginLoc = ElseLoc.isValid() ? ElseLoc : IfTokenLoc;
-Callbacks->SourceRangeSkipped(SourceRange(BeginLoc, Tok.getLocation()));
+// We want to skip the entire line containing the closing directive.
+const auto  = getSourceManager();
+const char *TokStart = SM.getCharacterData(Tok.getLocation());
+const char *EndOfLine = TokStart;
+while (true) {
+  char C = *EndOfLine;
+  // We'll warn about reaching the end of file later.
+  if (C == '\0' || C == '\r' || C == '\n')
+break;
+  ++EndOfLine;
+}
+SourceLocation DirectiveEndLoc =
+Tok.getLocation().getLocWithOffset(EndOfLine - TokStart);
+
+Callbacks->SourceRangeSkipped(SourceRange(HashTokenLoc, DirectiveEndLoc));
   }
 }
 
@@ -949,15 +963,18 @@
 default: break;
 // C99 6.10.1 - Conditional Inclusion.
 case tok::pp_if:
-  return HandleIfDirective(Result, ReadAnyTokensBeforeDirective);
+  return HandleIfDirective(Result, SavedHash.getLocation(),
+   ReadAnyTokensBeforeDirective);
 case tok::pp_ifdef:
-  return HandleIfdefDirective(Result, false, true/*not valid for miopt*/);
+  return HandleIfdefDirective(Result, SavedHash.getLocation(), false,
+  true /*not valid for miopt*/);
 case tok::pp_ifndef:
-  return HandleIfdefDirective(Result, true, ReadAnyTokensBeforeDirective);
+  

[PATCH] D32199: [TySan] A Type Sanitizer (Clang)

2017-08-14 Thread Hal Finkel via Phabricator via cfe-commits
hfinkel updated this revision to Diff 09.
hfinkel added a comment.

Rebased.


https://reviews.llvm.org/D32199

Files:
  include/clang/Basic/Sanitizers.def
  include/clang/Driver/SanitizerArgs.h
  lib/CodeGen/BackendUtil.cpp
  lib/CodeGen/CGDecl.cpp
  lib/CodeGen/CGDeclCXX.cpp
  lib/CodeGen/CodeGenFunction.cpp
  lib/CodeGen/CodeGenModule.cpp
  lib/CodeGen/CodeGenTBAA.cpp
  lib/CodeGen/SanitizerMetadata.cpp
  lib/CodeGen/SanitizerMetadata.h
  lib/Driver/SanitizerArgs.cpp
  lib/Driver/ToolChains/CommonArgs.cpp
  lib/Driver/ToolChains/Linux.cpp
  lib/Lex/PPMacroExpansion.cpp
  test/CodeGen/sanitize-type-attr.cpp
  test/Driver/sanitizer-ld.c

Index: test/Driver/sanitizer-ld.c
===
--- test/Driver/sanitizer-ld.c
+++ test/Driver/sanitizer-ld.c
@@ -181,6 +181,18 @@
 
 // RUN: %clangxx -no-canonical-prefixes %s -### -o %t.o 2>&1 \
 // RUN: -target x86_64-unknown-linux -fuse-ld=ld -stdlib=platform -lstdc++ \
+// RUN: -fsanitize=type \
+// RUN: -resource-dir=%S/Inputs/resource_dir \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-TYSAN-LINUX-CXX %s
+//
+// CHECK-TYSAN-LINUX-CXX: "{{(.*[^-.0-9A-Z_a-z])?}}ld{{(.exe)?}}"
+// CHECK-TYSAN-LINUX-CXX-NOT: stdc++
+// CHECK-TYSAN-LINUX-CXX: "-whole-archive" "{{.*}}libclang_rt.tysan-x86_64.a" "-no-whole-archive"
+// CHECK-TYSAN-LINUX-CXX: stdc++
+
+// RUN: %clangxx -no-canonical-prefixes %s -### -o %t.o 2>&1 \
+// RUN: -target x86_64-unknown-linux -fuse-ld=ld -stdlib=platform -lstdc++ \
 // RUN: -fsanitize=memory \
 // RUN: -resource-dir=%S/Inputs/resource_dir \
 // RUN: --sysroot=%S/Inputs/basic_linux_tree \
Index: test/CodeGen/sanitize-type-attr.cpp
===
--- /dev/null
+++ test/CodeGen/sanitize-type-attr.cpp
@@ -0,0 +1,75 @@
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -o - %s | FileCheck -check-prefix=WITHOUT %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -o - %s -fsanitize=type | FileCheck -check-prefix=TYSAN %s
+// RUN: echo "src:%s" | sed -e 's/\\//g' > %t
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm -o - %s -fsanitize=type -fsanitize-blacklist=%t | FileCheck -check-prefix=BL %s
+
+// The sanitize_type attribute should be attached to functions
+// when TypeSanitizer is enabled, unless no_sanitize("type") attribute
+// is present.
+
+// WITHOUT:  NoTYSAN1{{.*}}) [[NOATTR:#[0-9]+]]
+// BL:  NoTYSAN1{{.*}}) [[NOATTR:#[0-9]+]]
+// TYSAN:  NoTYSAN1{{.*}}) [[NOATTR:#[0-9]+]]
+__attribute__((no_sanitize("type")))
+int NoTYSAN1(int *a) { return *a; }
+
+// WITHOUT:  NoTYSAN2{{.*}}) [[NOATTR]]
+// BL:  NoTYSAN2{{.*}}) [[NOATTR]]
+// TYSAN:  NoTYSAN2{{.*}}) [[NOATTR]]
+__attribute__((no_sanitize("type")))
+int NoTYSAN2(int *a);
+int NoTYSAN2(int *a) { return *a; }
+
+// WITHOUT:  NoTYSAN3{{.*}}) [[NOATTR:#[0-9]+]]
+// BL:  NoTYSAN3{{.*}}) [[NOATTR:#[0-9]+]]
+// TYSAN:  NoTYSAN3{{.*}}) [[NOATTR:#[0-9]+]]
+__attribute__((no_sanitize("type")))
+int NoTYSAN3(int *a) { return *a; }
+
+// WITHOUT:  TYSANOk{{.*}}) [[NOATTR]]
+// BL:  TYSANOk{{.*}}) [[NOATTR]]
+// TYSAN: TYSANOk{{.*}}) [[WITH:#[0-9]+]]
+int TYSANOk(int *a) { return *a; }
+
+// WITHOUT:  TemplateTYSANOk{{.*}}) [[NOATTR]]
+// BL:  TemplateTYSANOk{{.*}}) [[NOATTR]]
+// TYSAN: TemplateTYSANOk{{.*}}) [[WITH]]
+template
+int TemplateTYSANOk() { return i; }
+
+// WITHOUT:  TemplateNoTYSAN{{.*}}) [[NOATTR]]
+// BL:  TemplateNoTYSAN{{.*}}) [[NOATTR]]
+// TYSAN: TemplateNoTYSAN{{.*}}) [[NOATTR]]
+template
+__attribute__((no_sanitize("type")))
+int TemplateNoTYSAN() { return i; }
+
+int force_instance = TemplateTYSANOk<42>()
+   + TemplateNoTYSAN<42>();
+
+// Check that __cxx_global_var_init* get the sanitize_type attribute.
+int global1 = 0;
+int global2 = *(int*)((char*)+1);
+// WITHOUT: @__cxx_global_var_init{{.*}}[[NOATTR:#[0-9]+]]
+// BL: @__cxx_global_var_init{{.*}}[[NOATTR:#[0-9]+]]
+// TYSAN: @__cxx_global_var_init{{.*}}[[WITH:#[0-9]+]]
+
+// Make sure that we don't add globals to the list for which we don't have a
+// specific type description.
+struct SX { int a, b; };
+SX sx;
+
+// WITHOUT: attributes [[NOATTR]] = { noinline nounwind{{.*}} }
+
+// BL: attributes [[NOATTR]] = { noinline nounwind{{.*}} }
+
+// TYSAN: attributes [[NOATTR]] = { noinline nounwind{{.*}} }
+// TYSAN: attributes [[WITH]] = { noinline nounwind sanitize_type{{.*}} }
+
+// TYSAN-DAG: !llvm.tysan.globals = !{[[G1MD:![0-9]+]], [[G2MD:![0-9]+]], [[G3MD:![0-9]+]]}
+// TYSAN-DAG: [[G1MD]] = !{i32* @force_instance, [[INTMD:![0-9]+]]}
+// TYSAN-DAG: [[INTMD]] = !{!"int",
+// TYSAN-DAG: [[G2MD]] = !{i32* @global1, [[INTMD]]}
+// TYSAN-DAG: [[G3MD]] = !{i32* @global2, [[INTMD]]}
+// TYSAN-DAG: Simple C++ TBAA
+
Index: lib/Lex/PPMacroExpansion.cpp
===
--- lib/Lex/PPMacroExpansion.cpp
+++ lib/Lex/PPMacroExpansion.cpp
@@ -1138,6 +1138,7 @@
   

[PATCH] D34873: Fix miscompiled 32bit binaries by mingw

2017-08-14 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added a comment.

This shouldn't be necessary after https://reviews.llvm.org/rL310905.


https://reviews.llvm.org/D34873



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


r310905 - Avoid PointerIntPair of constexpr EvalInfo structs

2017-08-14 Thread Reid Kleckner via cfe-commits
Author: rnk
Date: Mon Aug 14 18:17:47 2017
New Revision: 310905

URL: http://llvm.org/viewvc/llvm-project?rev=310905=rev
Log:
Avoid PointerIntPair of constexpr EvalInfo structs

They are stack allocated, so their alignment is not to be trusted.
32-bit MSVC only guarantees 4 byte stack alignment, even though alignof
would tell you otherwise. I tried fixing this with __declspec align, but
that apparently upsets GCC. Hopefully this version will satisfy all
compilers.

See PR32018 for some info about the mingw issues.

Should supercede https://reviews.llvm.org/D34873

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

Modified: cfe/trunk/lib/AST/ExprConstant.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprConstant.cpp?rev=310905=310904=310905=diff
==
--- cfe/trunk/lib/AST/ExprConstant.cpp (original)
+++ cfe/trunk/lib/AST/ExprConstant.cpp Mon Aug 14 18:17:47 2017
@@ -537,7 +537,7 @@ namespace {
   /// rules.  For example, the RHS of (0 && foo()) is not evaluated.  We can
   /// evaluate the expression regardless of what the RHS is, but C only allows
   /// certain things in certain situations.
-  struct LLVM_ALIGNAS(/*alignof(uint64_t)*/ 8) EvalInfo {
+  struct EvalInfo {
 ASTContext 
 
 /// EvalStatus - Contains information about the evaluation.
@@ -977,24 +977,22 @@ namespace {
   /// RAII object used to optionally suppress diagnostics and side-effects from
   /// a speculative evaluation.
   class SpeculativeEvaluationRAII {
-/// Pair of EvalInfo, and a bit that stores whether or not we were
-/// speculatively evaluating when we created this RAII.
-llvm::PointerIntPair InfoAndOldSpecEval;
-Expr::EvalStatus Old;
+EvalInfo *Info;
+Expr::EvalStatus OldStatus;
+bool OldIsSpeculativelyEvaluating;
 
 void moveFromAndCancel(SpeculativeEvaluationRAII &) {
-  InfoAndOldSpecEval = Other.InfoAndOldSpecEval;
-  Old = Other.Old;
-  Other.InfoAndOldSpecEval.setPointer(nullptr);
+  Info = Other.Info;
+  OldStatus = Other.OldStatus;
+  Other.Info = nullptr;
 }
 
 void maybeRestoreState() {
-  EvalInfo *Info = InfoAndOldSpecEval.getPointer();
   if (!Info)
 return;
 
-  Info->EvalStatus = Old;
-  Info->IsSpeculativelyEvaluating = InfoAndOldSpecEval.getInt();
+  Info->EvalStatus = OldStatus;
+  Info->IsSpeculativelyEvaluating = OldIsSpeculativelyEvaluating;
 }
 
   public:
@@ -1002,8 +1000,8 @@ namespace {
 
 SpeculativeEvaluationRAII(
 EvalInfo , SmallVectorImpl *NewDiag = 
nullptr)
-: InfoAndOldSpecEval(, Info.IsSpeculativelyEvaluating),
-  Old(Info.EvalStatus) {
+: Info(), OldStatus(Info.EvalStatus),
+  OldIsSpeculativelyEvaluating(Info.IsSpeculativelyEvaluating) {
   Info.EvalStatus.Diag = NewDiag;
   Info.IsSpeculativelyEvaluating = true;
 }


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


[PATCH] D34873: Fix miscompiled 32bit binaries by mingw

2017-08-14 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added a subscriber: gbiv.
rnk added a comment.

I looked at the blame, and I added this alignment thing in 
https://reviews.llvm.org/rL289575 to deal with some PointerIntPair assertions. 
Those probably started in @gbiv's https://reviews.llvm.org/rL270781, which 
introduced a `PointerIntPair` field. I think we can just fix 
this problem by not being so clever. We can unpack the boolean and the pointer, 
and everything will work fine.

In https://reviews.llvm.org/D34873#831698, @martell wrote:

> @rnk isn't this related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78936
>  Assuming this is in fact a gcc bug this will most likely cause a regression 
> with the standalone clang mingw toolchains we are on the verge of having.
>  This is of course assuming clang does not have the same regression gcc does.


It's possible, but nobody has debugged any of these crashes and shown the same 
`ret $imm` inconsistencies that I was pointing out in that bug. This seems 
unrelated at first.


https://reviews.llvm.org/D34873



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


r310903 - Revert "Fix LLVMgold plugin name/path for non-Linux."

2017-08-14 Thread Dan Albert via cfe-commits
Author: danalbert
Date: Mon Aug 14 17:31:44 2017
New Revision: 310903

URL: http://llvm.org/viewvc/llvm-project?rev=310903=rev
Log:
Revert "Fix LLVMgold plugin name/path for non-Linux."

Broke a test. Will fix the test and re-land later.

Modified:
cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp

Modified: cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp?rev=310903=310902=310903=diff
==
--- cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp Mon Aug 14 17:31:44 2017
@@ -376,20 +376,8 @@ void tools::AddGoldPlugin(const ToolChai
   // as gold requires -plugin to come before any -plugin-opt that -Wl might
   // forward.
   CmdArgs.push_back("-plugin");
-
-#if defined(LLVM_ON_WIN32)
-  const char *Suffix = ".dll";
-#elif defined(__APPLE__)
-  const char *Suffix = ".dylib";
-#else
-  const char *Suffix = ".so";
-#endif
-
-  SmallString<1024> Plugin;
-  llvm::sys::path::native(Twine(ToolChain.getDriver().Dir) +
-  "/../lib" CLANG_LIBDIR_SUFFIX "/LLVMgold" +
-  Suffix,
-  Plugin);
+  std::string Plugin =
+  ToolChain.getDriver().Dir + "/../lib" CLANG_LIBDIR_SUFFIX "/LLVMgold.so";
   CmdArgs.push_back(Args.MakeArgString(Plugin));
 
   // Try to pass driver level flags relevant to LTO code generation down to


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


Re: r310706 - [modules] Set the lexical DC for dummy tag decls that refer to hidden

2017-08-14 Thread Hans Wennborg via cfe-commits
Merged in r310902.

Thanks,
Hans

On Mon, Aug 14, 2017 at 4:03 AM, Alex L  wrote:
> Sure, I committed r310829 which moves the lexical decl adjustment.
>
> Hans, can you please merge r310706 with r310829.
>
> Cheers,
> Alex
>
> On 12 August 2017 at 01:29, Richard Smith  wrote:
>>
>> On 11 August 2017 at 17:20, Bruno Cardoso Lopes via cfe-commits
>>  wrote:
>>>
>>> Hi Alex,
>>>
>>> On Fri, Aug 11, 2017 at 9:06 AM, Alex Lorenz via cfe-commits
>>>  wrote:
>>> > Author: arphaman
>>> > Date: Fri Aug 11 05:06:52 2017
>>> > New Revision: 310706
>>> >
>>> > URL: http://llvm.org/viewvc/llvm-project?rev=310706=rev
>>> > Log:
>>> > [modules] Set the lexical DC for dummy tag decls that refer to hidden
>>> > declarations that are made visible after the dummy is parsed and ODR
>>> > verified
>>> >
>>> > Prior to this commit the
>>> > "(getContainingDC(DC) == CurContext && "The next DeclContext should be
>>> > lexically contained in the current one."),"
>>> > assertion failure was triggered during semantic analysis of the dummy
>>> > tag declaration that was declared in another tag declaration because
>>> > its
>>> > lexical context did not point to the outer tag decl.
>>> >
>>> > rdar://32292196
>>> >
>>> > Added:
>>> > cfe/trunk/test/Modules/Inputs/innerstructredef.h
>>> > cfe/trunk/test/Modules/inner-struct-redefines-invisible.m
>>> > Modified:
>>> > cfe/trunk/lib/Sema/SemaDecl.cpp
>>> > cfe/trunk/test/Modules/Inputs/module.map
>>> >
>>> > Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
>>> > URL:
>>> > http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=310706=310705=310706=diff
>>> >
>>> > ==
>>> > --- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
>>> > +++ cfe/trunk/lib/Sema/SemaDecl.cpp Fri Aug 11 05:06:52 2017
>>> > @@ -13722,6 +13722,7 @@ Decl *Sema::ActOnTag(Scope *S, unsigned
>>> >// comparison.
>>> >SkipBody->CheckSameAsPrevious = true;
>>> >SkipBody->New = createTagFromNewDecl();
>>> > +  SkipBody->New->setLexicalDeclContext(CurContext);
>>>
>>> I think it would be cleaner to do this inside "createTagFromNewDecl" than
>>> here.
>>
>>
>> I agree. Either before or after that change, this seems sufficiently
>> isolated and low-risk that it makes sense to take it for Clang 5.
>>
>>>
>>> >SkipBody->Previous = Hidden;
>>> >  } else {
>>> >SkipBody->ShouldSkip = true;
>>> >
>>> > Added: cfe/trunk/test/Modules/Inputs/innerstructredef.h
>>> > URL:
>>> > http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/innerstructredef.h?rev=310706=auto
>>> >
>>> > ==
>>> > --- cfe/trunk/test/Modules/Inputs/innerstructredef.h (added)
>>> > +++ cfe/trunk/test/Modules/Inputs/innerstructredef.h Fri Aug 11
>>> > 05:06:52 2017
>>> > @@ -0,0 +1,6 @@
>>> > +struct Outer {
>>> > +// This definition is actually hidden since only submodule 'one' is
>>> > imported.
>>> > +struct Inner {
>>> > +  int x;
>>> > +} field;
>>> > +};
>>> >
>>> > Modified: cfe/trunk/test/Modules/Inputs/module.map
>>> > URL:
>>> > http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/module.map?rev=310706=310705=310706=diff
>>> >
>>> > ==
>>> > --- cfe/trunk/test/Modules/Inputs/module.map (original)
>>> > +++ cfe/trunk/test/Modules/Inputs/module.map Fri Aug 11 05:06:52 2017
>>> > @@ -451,3 +451,12 @@ module DebugNestedB {
>>> >  module objcAtKeywordMissingEnd {
>>> >header "objcAtKeywordMissingEnd.h"
>>> >  }
>>> > +
>>> > +module innerstructredef {
>>> > +  module one {
>>> > +header "empty.h"
>>> > +  }
>>> > +  module two {
>>> > +   header "innerstructredef.h"
>>> > +  }
>>> > +}
>>> >
>>> > Added: cfe/trunk/test/Modules/inner-struct-redefines-invisible.m
>>> > URL:
>>> > http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/inner-struct-redefines-invisible.m?rev=310706=auto
>>> >
>>> > ==
>>> > --- cfe/trunk/test/Modules/inner-struct-redefines-invisible.m (added)
>>> > +++ cfe/trunk/test/Modules/inner-struct-redefines-invisible.m Fri Aug
>>> > 11 05:06:52 2017
>>> > @@ -0,0 +1,12 @@
>>> > +// RUN: rm -rf %t
>>> > +// RUN: %clang_cc1 -fsyntax-only -I%S/Inputs -fmodules
>>> > -fimplicit-module-maps -fmodules-cache-path=%t -verify %s
>>> > +// expected-no-diagnostics
>>> > +
>>> > +@import innerstructredef.one;
>>> > +
>>> > +struct Outer {
>>> > +// Should set lexical context when parsing 'Inner' here, otherwise
>>> > there's a crash:
>>> > +struct Inner {
>>> > +  int x;
>>> > +} field;
>>> > +};
>>> >
>>> >
>>> > ___
>>> > 

[PATCH] D36541: [CMake] Include LLVMFuzzer in Fuchsia toolchain

2017-08-14 Thread Petr Hosek via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL310901: [CMake] Include LLVMFuzzer in Fuchsia toolchain 
(authored by phosek).

Changed prior to commit:
  https://reviews.llvm.org/D36541?vs=110452=03#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D36541

Files:
  cfe/trunk/cmake/caches/Fuchsia-stage2.cmake


Index: cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
===
--- cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
+++ cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
@@ -81,6 +81,7 @@
   lld
   lldb
   liblldb
+  LLVMFuzzer
   LTO
   clang-format
   clang-headers


Index: cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
===
--- cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
+++ cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
@@ -81,6 +81,7 @@
   lld
   lldb
   liblldb
+  LLVMFuzzer
   LTO
   clang-format
   clang-headers
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r310901 - [CMake] Include LLVMFuzzer in Fuchsia toolchain

2017-08-14 Thread Petr Hosek via cfe-commits
Author: phosek
Date: Mon Aug 14 17:22:00 2017
New Revision: 310901

URL: http://llvm.org/viewvc/llvm-project?rev=310901=rev
Log:
[CMake] Include LLVMFuzzer in Fuchsia toolchain

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

Modified:
cfe/trunk/cmake/caches/Fuchsia-stage2.cmake

Modified: cfe/trunk/cmake/caches/Fuchsia-stage2.cmake
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/caches/Fuchsia-stage2.cmake?rev=310901=310900=310901=diff
==
--- cfe/trunk/cmake/caches/Fuchsia-stage2.cmake (original)
+++ cfe/trunk/cmake/caches/Fuchsia-stage2.cmake Mon Aug 14 17:22:00 2017
@@ -81,6 +81,7 @@ set(LLVM_DISTRIBUTION_COMPONENTS
   lld
   lldb
   liblldb
+  LLVMFuzzer
   LTO
   clang-format
   clang-headers


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


[PATCH] D36713: [libc++] Add a persistent way to disable availability

2017-08-14 Thread Shoaib Meenai via Phabricator via cfe-commits
smeenai added a comment.

In https://reviews.llvm.org/D36713#841478, @mclow.lists wrote:

> What's the use case here?  What are you trying to accomplish?


The `_LIBCPP_DISABLE_AVAILABILITY` macro already exists, but since it 
influences headers, it's a lot more useful to have it as a site config option, 
so that it can be set consistently.

I have an internal codebase where the availability macros cause issues, for 
complicated reasons that I unfortunately can't go into detail about. Rather 
than having to add `_LIBCPP_DISABLE_AVAILABILITY` to every single build using 
the libc++ headers, it would be really nice to be able to do the disabling via 
the site config. I know that's not a very satisfying explanation, but this 
seemed like a small and generally useful change, and it's consistent with how 
we're handling other macros that influence headers.


https://reviews.llvm.org/D36713



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


Re: r310401 - PR19668, PR23034: Fix handling of move constructors and deleted copy

2017-08-14 Thread Richard Smith via cfe-commits
On 14 August 2017 at 03:27, Diana Picus via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Hi,
>
> Strangely enough, it turns out that if I run
> Asan-armhf-with-calls-Noinst-Test on the command line it fails,
> although it doesn't fail when run with lit.


Looks like the crash is within the "use_colors == true" portion of
ColoredPrintf, so this would make sense if running the test within lit
turns off color support (perhaps because the output is not a terminal).


> I've attached the stack
> trace from gdb. It looks like some trouble passing down va_arg
> parameters, but I haven't looked into too much details. The segfault
> happens when we try to do a   ldrb   r3, [r0, r1], with r1 set to 0 by
> the current function and r0 passed down from the caller. I'm not sure
> if this is the exact same problem as the other tests, but feel free to
> have a look at that code.
>

Have you tried running Asan-armhf-with-calls-Noinst-Test on the command
line without this patch applied? (It's possible that this is a pre-existing
bug in ARM varargs call lowering, and is unrelated to the bug we're trying
to track down. This code path performs an unrelated varargs call between a
va_start / va_end pair, which seems like quite a rare situation, and I
could easily believe there's something wrong with our lowering that allows
some portion of the outer va_list state to be clobbered in that scenario.)

Meanwhile, I've removed some clutter from Asan-armhf-with-calls-Test
> (which is the original failure that we were seeing) and left only one
> failing test that seemed small enough. I'll try to look at the
> disassembly before/after the patch and maybe even run valgrind on it
> (running it on the original binary naturally takes forever).
>
> Let me know if there's anything else I could try. I can also send you
> disassembly or even LLVM IR for the Asan-armhf-with-calls-Noinst-Test
> if you think it helps.
>
> Cheers,
> Diana
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D35739: Fix LLVMgold plugin name/path for non-Linux.

2017-08-14 Thread Dan Albert via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL310895: Fix LLVMgold plugin name/path for non-Linux. 
(authored by danalbert).

Repository:
  rL LLVM

https://reviews.llvm.org/D35739

Files:
  cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp


Index: cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
+++ cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
@@ -376,8 +376,20 @@
   // as gold requires -plugin to come before any -plugin-opt that -Wl might
   // forward.
   CmdArgs.push_back("-plugin");
-  std::string Plugin =
-  ToolChain.getDriver().Dir + "/../lib" CLANG_LIBDIR_SUFFIX "/LLVMgold.so";
+
+#if defined(LLVM_ON_WIN32)
+  const char *Suffix = ".dll";
+#elif defined(__APPLE__)
+  const char *Suffix = ".dylib";
+#else
+  const char *Suffix = ".so";
+#endif
+
+  SmallString<1024> Plugin;
+  llvm::sys::path::native(Twine(ToolChain.getDriver().Dir) +
+  "/../lib" CLANG_LIBDIR_SUFFIX "/LLVMgold" +
+  Suffix,
+  Plugin);
   CmdArgs.push_back(Args.MakeArgString(Plugin));
 
   // Try to pass driver level flags relevant to LTO code generation down to


Index: cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
+++ cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
@@ -376,8 +376,20 @@
   // as gold requires -plugin to come before any -plugin-opt that -Wl might
   // forward.
   CmdArgs.push_back("-plugin");
-  std::string Plugin =
-  ToolChain.getDriver().Dir + "/../lib" CLANG_LIBDIR_SUFFIX "/LLVMgold.so";
+
+#if defined(LLVM_ON_WIN32)
+  const char *Suffix = ".dll";
+#elif defined(__APPLE__)
+  const char *Suffix = ".dylib";
+#else
+  const char *Suffix = ".so";
+#endif
+
+  SmallString<1024> Plugin;
+  llvm::sys::path::native(Twine(ToolChain.getDriver().Dir) +
+  "/../lib" CLANG_LIBDIR_SUFFIX "/LLVMgold" +
+  Suffix,
+  Plugin);
   CmdArgs.push_back(Args.MakeArgString(Plugin));
 
   // Try to pass driver level flags relevant to LTO code generation down to
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r310895 - Fix LLVMgold plugin name/path for non-Linux.

2017-08-14 Thread Dan Albert via cfe-commits
Author: danalbert
Date: Mon Aug 14 16:19:38 2017
New Revision: 310895

URL: http://llvm.org/viewvc/llvm-project?rev=310895=rev
Log:
Fix LLVMgold plugin name/path for non-Linux.

Summary:
It's only named LLVMgold.so on Linux. Fix the name for Windows and
Darwin.

Also fix the path for Windows so binutils doesn't have to.

Reviewers: srhines, pirama

Reviewed By: srhines

Subscribers: cfe-commits

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

Modified:
cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp

Modified: cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp?rev=310895=310894=310895=diff
==
--- cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/CommonArgs.cpp Mon Aug 14 16:19:38 2017
@@ -376,8 +376,20 @@ void tools::AddGoldPlugin(const ToolChai
   // as gold requires -plugin to come before any -plugin-opt that -Wl might
   // forward.
   CmdArgs.push_back("-plugin");
-  std::string Plugin =
-  ToolChain.getDriver().Dir + "/../lib" CLANG_LIBDIR_SUFFIX "/LLVMgold.so";
+
+#if defined(LLVM_ON_WIN32)
+  const char *Suffix = ".dll";
+#elif defined(__APPLE__)
+  const char *Suffix = ".dylib";
+#else
+  const char *Suffix = ".so";
+#endif
+
+  SmallString<1024> Plugin;
+  llvm::sys::path::native(Twine(ToolChain.getDriver().Dir) +
+  "/../lib" CLANG_LIBDIR_SUFFIX "/LLVMgold" +
+  Suffix,
+  Plugin);
   CmdArgs.push_back(Args.MakeArgString(Plugin));
 
   // Try to pass driver level flags relevant to LTO code generation down to


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


[PATCH] D36719: [libc++] Add site config option for ABI macros

2017-08-14 Thread Shoaib Meenai via Phabricator via cfe-commits
smeenai added a comment.

There should probably be some documentation for this, but I couldn't think of 
the right place; the Using libc++ documentation only mentions the actual 
configuration macros, not their corresponding cmake defines. Any suggestions?


https://reviews.llvm.org/D36719



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


[PATCH] D36720: [libc++] Prevent stale site configuration headers

2017-08-14 Thread Shoaib Meenai via Phabricator via cfe-commits
smeenai created this revision.
Herald added a subscriber: mgorny.

If we define cmake macros that require a site config, and then undefine
all such macros, a stale site config header will be left behind.
Explicitly delete any generate site config if we don't need one to avoid
this.


https://reviews.llvm.org/D36720

Files:
  CMakeLists.txt


Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -615,9 +615,10 @@
   config_define(ON _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
 endif()
 
+set(site_config_path "${LIBCXX_BINARY_DIR}/__config_site")
 if (LIBCXX_NEEDS_SITE_CONFIG)
   configure_file("include/__config_site.in"
- "${LIBCXX_BINARY_DIR}/__config_site"
+ "${site_config_path}"
  @ONLY)
 
   # Provide the config definitions by included the generated __config_site
@@ -627,6 +628,10 @@
   else()
 add_compile_flags("-include ${LIBCXX_BINARY_DIR}/__config_site")
   endif()
+else()
+  if (EXISTS "${site_config_path}")
+file(REMOVE "${site_config_path}")
+  endif()
 endif()
 
 
#===


Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -615,9 +615,10 @@
   config_define(ON _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS)
 endif()
 
+set(site_config_path "${LIBCXX_BINARY_DIR}/__config_site")
 if (LIBCXX_NEEDS_SITE_CONFIG)
   configure_file("include/__config_site.in"
- "${LIBCXX_BINARY_DIR}/__config_site"
+ "${site_config_path}"
  @ONLY)
 
   # Provide the config definitions by included the generated __config_site
@@ -627,6 +628,10 @@
   else()
 add_compile_flags("-include ${LIBCXX_BINARY_DIR}/__config_site")
   endif()
+else()
+  if (EXISTS "${site_config_path}")
+file(REMOVE "${site_config_path}")
+  endif()
 endif()
 
 #===
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D36555: Move x86-specific sources to x86-specific source lists.

2017-08-14 Thread Sterling Augustine via Phabricator via cfe-commits
saugustine added a comment.

I've cleaned up this patch a bit. Now the only files that are in the x86_ARCH 
group are those that require 80 bits floats and cpu_model.c. Tests for all of 
these were already disabled on arm and powerpc (because neither has 80-bit 
floats), so we knew these library functions don't work on arm, but we compiled 
them anyway. It makes more sense to just not compile them at all if we know 
they require something the target architecture doesn't support.

I'm cc'ing some relevant people on this. The arm folks can comment on this 
patch (and I will add them to review) if there is a problem.

In https://reviews.llvm.org/D36555#839829, @mgorny wrote:

> Also, I think that if you're splitting them up, it'd also logical to move 
> them into a subdirectory, `x86-common` maybe.


I'm reluctant to do this because that would require adding another layer to the 
file the filtering code around line 526, and that already has some special 
casing and is a bit hard to follow. Nevertheless, if you insist, I will.


https://reviews.llvm.org/D36555



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


[PATCH] D36719: [libc++] Add site config option for ABI macros

2017-08-14 Thread Shoaib Meenai via Phabricator via cfe-commits
smeenai created this revision.
Herald added a subscriber: mgorny.

Some ABI macros affect headers, so it's nice to have a site config
option for them. Add a LIBCXX_ABI_DEFINES cmake macro to allow
specifying a list of ABI macros to define in the site config.

The primary design constraint (as discussed with Eric on IRC a while
back) was to not have to repeat the ABI macro names in cmake, which only
leaves a free-form cmake list as an option. A somewhat unfortunate
consequence is that we can't verify that the ABI macros being defined
actually exist, though we can at least perform some basic sanity
checking, since all the ABI macros begin with _LIBCPP_ABI_.


https://reviews.llvm.org/D36719

Files:
  CMakeLists.txt
  include/__config_site.in
  utils/libcxx/test/config.py


Index: utils/libcxx/test/config.py
===
--- utils/libcxx/test/config.py
+++ utils/libcxx/test/config.py
@@ -658,7 +658,7 @@
 self.config.available_features.add('libcpp-abi-version-v%s'
 % feature_macros[m])
 continue
-assert m.startswith('_LIBCPP_HAS_') or m == '_LIBCPP_ABI_UNSTABLE'
+assert m.startswith('_LIBCPP_HAS_') or m.startswith('_LIBCPP_ABI_')
 m = m.lower()[1:].replace('_', '-')
 self.config.available_features.add(m)
 return feature_macros
Index: include/__config_site.in
===
--- include/__config_site.in
+++ include/__config_site.in
@@ -24,4 +24,6 @@
 #cmakedefine _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL
 #cmakedefine _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
 
+@_LIBCPP_ABI_DEFINES@
+
 #endif // _LIBCPP_CONFIG_SITE
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -607,6 +607,18 @@
 config_define_if(LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY 
_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL)
 config_define_if(LIBCXX_HAS_MUSL_LIBC _LIBCPP_HAS_MUSL_LIBC)
 
+if (LIBCXX_ABI_DEFINES)
+  set(abi_defines)
+  foreach (abi_define ${LIBCXX_ABI_DEFINES})
+if (NOT abi_define MATCHES "^_LIBCPP_ABI_")
+  message(SEND_ERROR "Invalid ABI macro ${abi_define} in 
LIBCXX_ABI_DEFINES")
+endif()
+list(APPEND abi_defines "#define ${abi_define}")
+  endforeach()
+  string(REPLACE ";" "\n" abi_defines "${abi_defines}")
+  config_define(${abi_defines} _LIBCPP_ABI_DEFINES)
+endif()
+
 # By default libc++ on Windows expects to use a shared library, which requires
 # the headers to use DLL import/export semantics. However when building a
 # static library only we modify the headers to disable DLL import/export.


Index: utils/libcxx/test/config.py
===
--- utils/libcxx/test/config.py
+++ utils/libcxx/test/config.py
@@ -658,7 +658,7 @@
 self.config.available_features.add('libcpp-abi-version-v%s'
 % feature_macros[m])
 continue
-assert m.startswith('_LIBCPP_HAS_') or m == '_LIBCPP_ABI_UNSTABLE'
+assert m.startswith('_LIBCPP_HAS_') or m.startswith('_LIBCPP_ABI_')
 m = m.lower()[1:].replace('_', '-')
 self.config.available_features.add(m)
 return feature_macros
Index: include/__config_site.in
===
--- include/__config_site.in
+++ include/__config_site.in
@@ -24,4 +24,6 @@
 #cmakedefine _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL
 #cmakedefine _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
 
+@_LIBCPP_ABI_DEFINES@
+
 #endif // _LIBCPP_CONFIG_SITE
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -607,6 +607,18 @@
 config_define_if(LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL)
 config_define_if(LIBCXX_HAS_MUSL_LIBC _LIBCPP_HAS_MUSL_LIBC)
 
+if (LIBCXX_ABI_DEFINES)
+  set(abi_defines)
+  foreach (abi_define ${LIBCXX_ABI_DEFINES})
+if (NOT abi_define MATCHES "^_LIBCPP_ABI_")
+  message(SEND_ERROR "Invalid ABI macro ${abi_define} in LIBCXX_ABI_DEFINES")
+endif()
+list(APPEND abi_defines "#define ${abi_define}")
+  endforeach()
+  string(REPLACE ";" "\n" abi_defines "${abi_defines}")
+  config_define(${abi_defines} _LIBCPP_ABI_DEFINES)
+endif()
+
 # By default libc++ on Windows expects to use a shared library, which requires
 # the headers to use DLL import/export semantics. However when building a
 # static library only we modify the headers to disable DLL import/export.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D36713: [libc++] Add a persistent way to disable availability

2017-08-14 Thread Marshall Clow via Phabricator via cfe-commits
mclow.lists added a comment.

What's the use case here?  What are you trying to accomplish?


https://reviews.llvm.org/D36713



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


[PATCH] D36713: [libc++] Add a persistent way to disable availability

2017-08-14 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith accepted this revision.
dexonsmith added a comment.
This revision is now accepted and ready to land.

LGTM.


https://reviews.llvm.org/D36713



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


[PATCH] D36713: [libc++] Add a persistent way to disable availability

2017-08-14 Thread Mehdi AMINI via Phabricator via cfe-commits
mehdi_amini added a comment.

Seems fine to me. Adding @dexonsmith (I don't know who maintain libc++ at Apple 
right now)


https://reviews.llvm.org/D36713



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


[PATCH] D36712: Emit section information for extern variables

2017-08-14 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added inline comments.



Comment at: docs/LangRef.rst:629
+corresponding to the LLVM module, section information specified in the 
+declaration is retained in LLVM IR to enable OpenCL processes.
+

This doesn't really explain the part that matters. For LangRef, it doesn't 
matter how the frontend decides to generate declarations (and it might be 
different for frontends other than clang).  And OpenCL might motivate this, but 
it has nothing to do with the semantics.

The key question here is what it actually means.  Is it a promise the that a 
definition will exist for the given symbol in the given section?  If so, what 
happens if the symbol is actually in a different section?  ("Undefined 
behavior" is probably an acceptable answer, but it needs to be stated 
explicitly.)


https://reviews.llvm.org/D36712



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


[PATCH] D36715: [clang] minor cleanup in clang/tooling/refactoring

2017-08-14 Thread Alexander Shaposhnikov via Phabricator via cfe-commits
alexshap created this revision.

1. Add missing explicit.
2. Add missing std::move

(return type is Expected but we return 
std::vector, so cast to && is necessary).

Test plan: make check-all


Repository:
  rL LLVM

https://reviews.llvm.org/D36715

Files:
  include/clang/Tooling/Refactoring/Rename/SymbolName.h
  lib/Tooling/Refactoring/Rename/RenamingAction.cpp


Index: lib/Tooling/Refactoring/Rename/RenamingAction.cpp
===
--- lib/Tooling/Refactoring/Rename/RenamingAction.cpp
+++ lib/Tooling/Refactoring/Rename/RenamingAction.cpp
@@ -53,7 +53,7 @@
 }
 Changes.push_back(std::move(Change));
   }
-  return Changes;
+  return std::move(Changes);
 }
 
 /// Takes each atomic change and inserts its replacements into the set of
Index: include/clang/Tooling/Refactoring/Rename/SymbolName.h
===
--- include/clang/Tooling/Refactoring/Rename/SymbolName.h
+++ include/clang/Tooling/Refactoring/Rename/SymbolName.h
@@ -29,7 +29,7 @@
 /// \endcode
 class SymbolName {
 public:
-  SymbolName(StringRef Name) {
+  explicit SymbolName(StringRef Name) {
 // While empty symbol names are valid (Objective-C selectors can have empty
 // name pieces), occurrences Objective-C selectors are created using an
 // array of strings instead of just one string.


Index: lib/Tooling/Refactoring/Rename/RenamingAction.cpp
===
--- lib/Tooling/Refactoring/Rename/RenamingAction.cpp
+++ lib/Tooling/Refactoring/Rename/RenamingAction.cpp
@@ -53,7 +53,7 @@
 }
 Changes.push_back(std::move(Change));
   }
-  return Changes;
+  return std::move(Changes);
 }
 
 /// Takes each atomic change and inserts its replacements into the set of
Index: include/clang/Tooling/Refactoring/Rename/SymbolName.h
===
--- include/clang/Tooling/Refactoring/Rename/SymbolName.h
+++ include/clang/Tooling/Refactoring/Rename/SymbolName.h
@@ -29,7 +29,7 @@
 /// \endcode
 class SymbolName {
 public:
-  SymbolName(StringRef Name) {
+  explicit SymbolName(StringRef Name) {
 // While empty symbol names are valid (Objective-C selectors can have empty
 // name pieces), occurrences Objective-C selectors are created using an
 // array of strings instead of just one string.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D36441: Add Support for Reference Counting of Parameters on the Callee Side in RetainCountChecker

2017-08-14 Thread Devin Coughlin via Phabricator via cfe-commits
dcoughlin added a comment.

Thanks! This looks good to me, with the note about factoring out the duplicated 
logic addressed, Would you factor out that logic into a static function and 
update phabricator summary to be a commit message. Then I will commit!




Comment at: lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp:3971
+const ArgEffect *AE = CalleeSideArgEffects.lookup(idx);
+if (AE && *AE == DecRef && Ty.getAsString().substr(0, 4) == "isl_")
+  state = setRefBinding(state, Sym, 
RefVal::makeOwned(RetEffect::ObjKind::Generalized, Ty));

Can you factor out the logic that looks whether the type name starts with 
"isl_" to a static function that types a type and is called something 
'isGeneralizedObjectRef"? This will avoid duplicating the logic twice here and 
will also give us a single place to update when we add an attribute indicating 
that a type is reference counted.


Repository:
  rL LLVM

https://reviews.llvm.org/D36441



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


[PATCH] D36713: [libc++] Add a persistent way to disable availability

2017-08-14 Thread Shoaib Meenai via Phabricator via cfe-commits
smeenai created this revision.
Herald added a subscriber: mgorny.

Add _LIBCPP_DISABLE_AVAILABILITY to the site config options, and add a
cmake option LIBCXX_DISABLE_AVAILABILITY to control the site config.
This is similar to other options which influence headers and therefore
shold have some way to be set persistently.


https://reviews.llvm.org/D36713

Files:
  CMakeLists.txt
  docs/UsingLibcxx.rst
  include/__config_site.in
  utils/libcxx/test/config.py


Index: utils/libcxx/test/config.py
===
--- utils/libcxx/test/config.py
+++ utils/libcxx/test/config.py
@@ -652,6 +652,10 @@
 if feature_macros[m]:
 define += '=%s' % (feature_macros[m])
 self.cxx.compile_flags += [define]
+if m == '_LIBCPP_DISABLE_AVAILABILITY':
+assert not self.with_availability, \
+'Availability is disabled in the site configuration'
+continue
 if m == '_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS':
 continue
 if m == '_LIBCPP_ABI_VERSION':
Index: include/__config_site.in
===
--- include/__config_site.in
+++ include/__config_site.in
@@ -22,6 +22,7 @@
 #cmakedefine _LIBCPP_HAS_THREAD_API_PTHREAD
 #cmakedefine _LIBCPP_HAS_THREAD_API_EXTERNAL
 #cmakedefine _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL
+#cmakedefine _LIBCPP_DISABLE_AVAILABILITY
 #cmakedefine _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
 
 #endif // _LIBCPP_CONFIG_SITE
Index: docs/UsingLibcxx.rst
===
--- docs/UsingLibcxx.rst
+++ docs/UsingLibcxx.rst
@@ -185,6 +185,9 @@
 * Giving `set`, `map`, `multiset`, `multimap` a comparator which is not
   const callable.
 
+**LIBCXX_DISABLE_AVAILABILITY**:
+  This macro disables availability annotations in the libc++ headers.
+
 C++17 Specific Configuration Macros
 ---
 **_LIBCPP_ENABLE_CXX17_REMOVED_FEATURES**:
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -606,6 +606,7 @@
 config_define_if(LIBCXX_HAS_EXTERNAL_THREAD_API 
_LIBCPP_HAS_THREAD_API_EXTERNAL)
 config_define_if(LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY 
_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL)
 config_define_if(LIBCXX_HAS_MUSL_LIBC _LIBCPP_HAS_MUSL_LIBC)
+config_define_if(LIBCXX_DISABLE_AVAILABILITY _LIBCPP_DISABLE_AVAILABILITY)
 
 # By default libc++ on Windows expects to use a shared library, which requires
 # the headers to use DLL import/export semantics. However when building a


Index: utils/libcxx/test/config.py
===
--- utils/libcxx/test/config.py
+++ utils/libcxx/test/config.py
@@ -652,6 +652,10 @@
 if feature_macros[m]:
 define += '=%s' % (feature_macros[m])
 self.cxx.compile_flags += [define]
+if m == '_LIBCPP_DISABLE_AVAILABILITY':
+assert not self.with_availability, \
+'Availability is disabled in the site configuration'
+continue
 if m == '_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS':
 continue
 if m == '_LIBCPP_ABI_VERSION':
Index: include/__config_site.in
===
--- include/__config_site.in
+++ include/__config_site.in
@@ -22,6 +22,7 @@
 #cmakedefine _LIBCPP_HAS_THREAD_API_PTHREAD
 #cmakedefine _LIBCPP_HAS_THREAD_API_EXTERNAL
 #cmakedefine _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL
+#cmakedefine _LIBCPP_DISABLE_AVAILABILITY
 #cmakedefine _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS
 
 #endif // _LIBCPP_CONFIG_SITE
Index: docs/UsingLibcxx.rst
===
--- docs/UsingLibcxx.rst
+++ docs/UsingLibcxx.rst
@@ -185,6 +185,9 @@
 * Giving `set`, `map`, `multiset`, `multimap` a comparator which is not
   const callable.
 
+**LIBCXX_DISABLE_AVAILABILITY**:
+  This macro disables availability annotations in the libc++ headers.
+
 C++17 Specific Configuration Macros
 ---
 **_LIBCPP_ENABLE_CXX17_REMOVED_FEATURES**:
Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -606,6 +606,7 @@
 config_define_if(LIBCXX_HAS_EXTERNAL_THREAD_API _LIBCPP_HAS_THREAD_API_EXTERNAL)
 config_define_if(LIBCXX_BUILD_EXTERNAL_THREAD_LIBRARY _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL)
 config_define_if(LIBCXX_HAS_MUSL_LIBC _LIBCPP_HAS_MUSL_LIBC)
+config_define_if(LIBCXX_DISABLE_AVAILABILITY _LIBCPP_DISABLE_AVAILABILITY)
 
 # By default libc++ on Windows expects to use a shared library, which requires
 # the headers to use DLL import/export semantics. However when building a
___
cfe-commits 

[PATCH] D36564: [analyzer] Fix SimpleSValBuilder::simplifySVal

2017-08-14 Thread Alexander Shaposhnikov via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL310887: [analyzer] Fix SimpleSValBuilder::simplifySVal 
(authored by alexshap).

Changed prior to commit:
  https://reviews.llvm.org/D36564?vs=110502=111073#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D36564

Files:
  cfe/trunk/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
  cfe/trunk/test/Analysis/ptr-arith.cpp


Index: cfe/trunk/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
===
--- cfe/trunk/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
+++ cfe/trunk/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
@@ -1016,7 +1016,8 @@
   SVB.getKnownValue(State, nonloc::SymbolVal(S)))
 return Loc::isLocType(S->getType()) ? (SVal)SVB.makeIntLocVal(*I)
 : (SVal)SVB.makeIntVal(*I);
-  return nonloc::SymbolVal(S);
+  return Loc::isLocType(S->getType()) ? (SVal)SVB.makeLoc(S) 
+  : nonloc::SymbolVal(S);
 }
 
 // TODO: Support SymbolCast. Support IntSymExpr when/if we actually
Index: cfe/trunk/test/Analysis/ptr-arith.cpp
===
--- cfe/trunk/test/Analysis/ptr-arith.cpp
+++ cfe/trunk/test/Analysis/ptr-arith.cpp
@@ -98,3 +98,10 @@
   int a[5][5];
*(*(a+1)+2) = 2;
 }
+
+unsigned ptrSubtractionNoCrash(char *Begin, char *End) {
+  auto N = End - Begin;
+  if (Begin)
+return 0;
+  return N;
+}


Index: cfe/trunk/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
===
--- cfe/trunk/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
+++ cfe/trunk/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
@@ -1016,7 +1016,8 @@
   SVB.getKnownValue(State, nonloc::SymbolVal(S)))
 return Loc::isLocType(S->getType()) ? (SVal)SVB.makeIntLocVal(*I)
 : (SVal)SVB.makeIntVal(*I);
-  return nonloc::SymbolVal(S);
+  return Loc::isLocType(S->getType()) ? (SVal)SVB.makeLoc(S) 
+  : nonloc::SymbolVal(S);
 }
 
 // TODO: Support SymbolCast. Support IntSymExpr when/if we actually
Index: cfe/trunk/test/Analysis/ptr-arith.cpp
===
--- cfe/trunk/test/Analysis/ptr-arith.cpp
+++ cfe/trunk/test/Analysis/ptr-arith.cpp
@@ -98,3 +98,10 @@
   int a[5][5];
*(*(a+1)+2) = 2;
 }
+
+unsigned ptrSubtractionNoCrash(char *Begin, char *End) {
+  auto N = End - Begin;
+  if (Begin)
+return 0;
+  return N;
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r310887 - [analyzer] Fix SimpleSValBuilder::simplifySVal

2017-08-14 Thread Alexander Shaposhnikov via cfe-commits
Author: alexshap
Date: Mon Aug 14 14:23:08 2017
New Revision: 310887

URL: http://llvm.org/viewvc/llvm-project?rev=310887=rev
Log:
[analyzer] Fix SimpleSValBuilder::simplifySVal

This diff fixes a crash (triggered assert) on the newly added test case.
In the method Simplifier::VisitSymbolData we check the type of S and return
Loc/NonLoc accordingly.

Differential revision: https://reviews.llvm.org/D36564

Modified:
cfe/trunk/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
cfe/trunk/test/Analysis/ptr-arith.cpp

Modified: cfe/trunk/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp?rev=310887=310886=310887=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp Mon Aug 14 14:23:08 
2017
@@ -1016,7 +1016,8 @@ SVal SimpleSValBuilder::simplifySVal(Pro
   SVB.getKnownValue(State, nonloc::SymbolVal(S)))
 return Loc::isLocType(S->getType()) ? (SVal)SVB.makeIntLocVal(*I)
 : (SVal)SVB.makeIntVal(*I);
-  return nonloc::SymbolVal(S);
+  return Loc::isLocType(S->getType()) ? (SVal)SVB.makeLoc(S) 
+  : nonloc::SymbolVal(S);
 }
 
 // TODO: Support SymbolCast. Support IntSymExpr when/if we actually

Modified: cfe/trunk/test/Analysis/ptr-arith.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/ptr-arith.cpp?rev=310887=310886=310887=diff
==
--- cfe/trunk/test/Analysis/ptr-arith.cpp (original)
+++ cfe/trunk/test/Analysis/ptr-arith.cpp Mon Aug 14 14:23:08 2017
@@ -98,3 +98,10 @@ void checkMultiDimansionalArray() {
   int a[5][5];
*(*(a+1)+2) = 2;
 }
+
+unsigned ptrSubtractionNoCrash(char *Begin, char *End) {
+  auto N = End - Begin;
+  if (Begin)
+return 0;
+  return N;
+}


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


[PATCH] D36371: [Clang][x86][Inline Asm] support for GCC style inline asm - Y constraints

2017-08-14 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added a comment.

tests?


Repository:
  rL LLVM

https://reviews.llvm.org/D36371



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


[PATCH] D36487: Emit section information for extern variables.

2017-08-14 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

@efriedma : LangRef changed in this review: https://reviews.llvm.org/D36712


https://reviews.llvm.org/D36487



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


[PATCH] D36712: Emit section information for extern variables

2017-08-14 Thread Elizabeth Andrews via Phabricator via cfe-commits
eandrews created this revision.

Update IR generated to retain section information for external declarations. 
This is related to https://reviews.llvm.org/D36487


https://reviews.llvm.org/D36712

Files:
  docs/LangRef.rst


Index: docs/LangRef.rst
===
--- docs/LangRef.rst
+++ docs/LangRef.rst
@@ -622,6 +622,12 @@
 Additionally, the global can placed in a comdat if the target has the necessary
 support.
 
+External declarations may have an explicit section specified. When generating 
+LLVM IR, external declarations are ignored and the variables are emitted on 
+their first use. While sections are not generated in the object file 
+corresponding to the LLVM module, section information specified in the 
+declaration is retained in LLVM IR to enable OpenCL processes.
+
 By default, global initializers are optimized by assuming that global
 variables defined within the module are not modified from their
 initial values before the start of the global initializer. This is


Index: docs/LangRef.rst
===
--- docs/LangRef.rst
+++ docs/LangRef.rst
@@ -622,6 +622,12 @@
 Additionally, the global can placed in a comdat if the target has the necessary
 support.
 
+External declarations may have an explicit section specified. When generating 
+LLVM IR, external declarations are ignored and the variables are emitted on 
+their first use. While sections are not generated in the object file 
+corresponding to the LLVM module, section information specified in the 
+declaration is retained in LLVM IR to enable OpenCL processes.
+
 By default, global initializers are optimized by assuming that global
 variables defined within the module are not modified from their
 initial values before the start of the global initializer. This is
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D36487: Emit section information for extern variables.

2017-08-14 Thread Elizabeth Andrews via Phabricator via cfe-commits
eandrews updated this revision to Diff 111064.
eandrews added a comment.

As per review comments, removed extra RUNS in lit test.


https://reviews.llvm.org/D36487

Files:
  lib/CodeGen/CodeGenModule.cpp
  test/CodeGenCXX/extern-section-attribute.cpp


Index: test/CodeGenCXX/extern-section-attribute.cpp
===
--- /dev/null
+++ test/CodeGenCXX/extern-section-attribute.cpp
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -emit-llvm %s -o - -ffreestanding 
-triple=x86_64-pc-linux-gnu | FileCheck %s 
+
+extern int aa __attribute__((section(".sdata")));
+// CHECK-DAG: @aa = external global i32, section ".sdata", align 4
+
+extern int bb __attribute__((section(".sdata"))) = 1;
+// CHECK-DAG: @bb = global i32 1, section ".sdata", align 4
+
+int foo() {
+  return aa + bb;
+}
Index: lib/CodeGen/CodeGenModule.cpp
===
--- lib/CodeGen/CodeGenModule.cpp
+++ lib/CodeGen/CodeGenModule.cpp
@@ -2430,6 +2430,12 @@
   EmitGlobalVarDefinition(D);
 }
 
+// Emit section information for extern variables.
+if (D->hasExternalStorage() && !D->isThisDeclarationADefinition()) {
+  if (const SectionAttr *SA = D->getAttr())
+GV->setSection(SA->getName());
+}
+
 // Handle XCore specific ABI requirements.
 if (getTriple().getArch() == llvm::Triple::xcore &&
 D->getLanguageLinkage() == CLanguageLinkage &&


Index: test/CodeGenCXX/extern-section-attribute.cpp
===
--- /dev/null
+++ test/CodeGenCXX/extern-section-attribute.cpp
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -emit-llvm %s -o - -ffreestanding -triple=x86_64-pc-linux-gnu | FileCheck %s 
+
+extern int aa __attribute__((section(".sdata")));
+// CHECK-DAG: @aa = external global i32, section ".sdata", align 4
+
+extern int bb __attribute__((section(".sdata"))) = 1;
+// CHECK-DAG: @bb = global i32 1, section ".sdata", align 4
+
+int foo() {
+  return aa + bb;
+}
Index: lib/CodeGen/CodeGenModule.cpp
===
--- lib/CodeGen/CodeGenModule.cpp
+++ lib/CodeGen/CodeGenModule.cpp
@@ -2430,6 +2430,12 @@
   EmitGlobalVarDefinition(D);
 }
 
+// Emit section information for extern variables.
+if (D->hasExternalStorage() && !D->isThisDeclarationADefinition()) {
+  if (const SectionAttr *SA = D->getAttr())
+GV->setSection(SA->getName());
+}
+
 // Handle XCore specific ABI requirements.
 if (getTriple().getArch() == llvm::Triple::xcore &&
 D->getLanguageLinkage() == CLanguageLinkage &&
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D36707: [CodeGen]Refactor CpuSupports/CPUIs Builtin Code Gen to better work with "target" implementation

2017-08-14 Thread Erich Keane via Phabricator via cfe-commits
erichkeane updated this revision to Diff 111061.
erichkeane added a comment.

Thinking about it further, the emit functions should be private in this case.


https://reviews.llvm.org/D36707

Files:
  lib/CodeGen/CGBuiltin.cpp
  lib/CodeGen/CodeGenFunction.h

Index: lib/CodeGen/CodeGenFunction.h
===
--- lib/CodeGen/CodeGenFunction.h
+++ lib/CodeGen/CodeGenFunction.h
@@ -3852,6 +3852,10 @@
   void AddObjCARCExceptionMetadata(llvm::Instruction *Inst);
 
   llvm::Value *GetValueForARMHint(unsigned BuiltinID);
+  llvm::Value *EmitX86CpuIs(const CallExpr *E);
+  llvm::Value *EmitX86CpuIs(StringRef CPUStr);
+  llvm::Value *EmitX86CpuSupports(const CallExpr *E);
+  llvm::Value *EmitX86CpuSupports(StringRef FeatureStr);
 };
 
 /// Helper class with most of the code for saving a value for a
Index: lib/CodeGen/CGBuiltin.cpp
===
--- lib/CodeGen/CGBuiltin.cpp
+++ lib/CodeGen/CGBuiltin.cpp
@@ -7287,9 +7287,13 @@
   return CGF.Builder.CreateSExt(Mask, DstTy, "vpmovm2");
 }
 
-static Value *EmitX86CpuIs(CodeGenFunction , const CallExpr *E) {
+Value *CodeGenFunction::EmitX86CpuIs(const CallExpr *E) {
   const Expr *CPUExpr = E->getArg(0)->IgnoreParenCasts();
   StringRef CPUStr = cast(CPUExpr)->getString();
+  return EmitX86CpuIs(CPUStr);
+}
+
+Value *CodeGenFunction::EmitX86CpuIs(StringRef CPUStr) {
 
   // This enum contains the vendor, type, and subtype enums from the
   // runtime library concatenated together. The _START labels mark
@@ -7359,7 +7363,7 @@
   .Case("westmere", INTEL_COREI7_WESTMERE)
   .Case("znver1", AMDFAM17H_ZNVER1);
 
-  llvm::Type *Int32Ty = CGF.Builder.getInt32Ty();
+  llvm::Type *Int32Ty = Builder.getInt32Ty();
 
   // Matching the struct layout from the compiler-rt/libgcc structure that is
   // filled in:
@@ -7371,7 +7375,7 @@
   llvm::ArrayType::get(Int32Ty, 1));
 
   // Grab the global __cpu_model.
-  llvm::Constant *CpuModel = CGF.CGM.CreateRuntimeVariable(STy, "__cpu_model");
+  llvm::Constant *CpuModel = CGM.CreateRuntimeVariable(STy, "__cpu_model");
 
   // Calculate the index needed to access the correct field based on the
   // range. Also adjust the expected value.
@@ -7393,18 +7397,127 @@
 ConstantInt::get(Int32Ty, 0),
 ConstantInt::get(Int32Ty, Index)
   };
-  llvm::Value *CpuValue = CGF.Builder.CreateGEP(STy, CpuModel, Idxs);
-  CpuValue = CGF.Builder.CreateAlignedLoad(CpuValue, CharUnits::fromQuantity(4));
+  llvm::Value *CpuValue = Builder.CreateGEP(STy, CpuModel, Idxs);
+  CpuValue = Builder.CreateAlignedLoad(CpuValue, CharUnits::fromQuantity(4));
 
   // Check the value of the field against the requested value.
-  return CGF.Builder.CreateICmpEQ(CpuValue,
+  return Builder.CreateICmpEQ(CpuValue,
   llvm::ConstantInt::get(Int32Ty, Value));
 }
 
+Value *CodeGenFunction::EmitX86CpuSupports(const CallExpr *E) {
+  const Expr *FeatureExpr = E->getArg(0)->IgnoreParenCasts();
+  StringRef FeatureStr = cast(FeatureExpr)->getString();
+  return EmitX86CpuSupports(FeatureStr);
+}
+
+Value *CodeGenFunction::EmitX86CpuSupports(StringRef FeatureStr) {
+  // TODO: When/if this becomes more than x86 specific then use a TargetInfo
+  // based mapping.
+  // Processor features and mapping to processor feature value.
+  enum X86Features {
+CMOV = 0,
+MMX,
+POPCNT,
+SSE,
+SSE2,
+SSE3,
+SSSE3,
+SSE4_1,
+SSE4_2,
+AVX,
+AVX2,
+SSE4_A,
+FMA4,
+XOP,
+FMA,
+AVX512F,
+BMI,
+BMI2,
+AES,
+PCLMUL,
+AVX512VL,
+AVX512BW,
+AVX512DQ,
+AVX512CD,
+AVX512ER,
+AVX512PF,
+AVX512VBMI,
+AVX512IFMA,
+AVX5124VNNIW,
+AVX5124FMAPS,
+AVX512VPOPCNTDQ,
+MAX
+  };
+
+  X86Features Feature =
+  StringSwitch(FeatureStr)
+  .Case("cmov", X86Features::CMOV)
+  .Case("mmx", X86Features::MMX)
+  .Case("popcnt", X86Features::POPCNT)
+  .Case("sse", X86Features::SSE)
+  .Case("sse2", X86Features::SSE2)
+  .Case("sse3", X86Features::SSE3)
+  .Case("ssse3", X86Features::SSSE3)
+  .Case("sse4.1", X86Features::SSE4_1)
+  .Case("sse4.2", X86Features::SSE4_2)
+  .Case("avx", X86Features::AVX)
+  .Case("avx2", X86Features::AVX2)
+  .Case("sse4a", X86Features::SSE4_A)
+  .Case("fma4", X86Features::FMA4)
+  .Case("xop", X86Features::XOP)
+  .Case("fma", X86Features::FMA)
+  .Case("avx512f", X86Features::AVX512F)
+  .Case("bmi", X86Features::BMI)
+  .Case("bmi2", X86Features::BMI2)
+  .Case("aes", X86Features::AES)
+  .Case("pclmul", X86Features::PCLMUL)
+  .Case("avx512vl", X86Features::AVX512VL)
+  .Case("avx512bw", X86Features::AVX512BW)
+  .Case("avx512dq", X86Features::AVX512DQ)
+  .Case("avx512cd", 

[PATCH] D36642: [Lexer] Report more precise skipped regions (PR34166)

2017-08-14 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added a comment.

I'm not sure this produces the right locations in general.  Consider the 
following slightly evil testcase:

  #\
  if 0
  #elif \
  11\
  
  int a;
  #endif




https://reviews.llvm.org/D36642



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


[PATCH] D36200: [Sema] Improve some -Wunguarded-availability diagnostic messages

2017-08-14 Thread Phabricator via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL310874: [Sema] Improve some -Wunguarded-availability 
diagnostics (authored by epilk).

Changed prior to commit:
  https://reviews.llvm.org/D36200?vs=109252=111051#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D36200

Files:
  cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
  cfe/trunk/lib/Sema/SemaDeclAttr.cpp
  cfe/trunk/test/SemaObjC/attr-availability.m
  cfe/trunk/test/SemaObjC/unguarded-availability-new.m
  cfe/trunk/test/SemaObjC/unguarded-availability.m

Index: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
===
--- cfe/trunk/lib/Sema/SemaDeclAttr.cpp
+++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp
@@ -7128,7 +7128,83 @@
   if (!ShouldDiagnoseAvailabilityInContext(S, K, DeclVersion, Ctx))
 return;
 
+  // The declaration can have multiple availability attributes, we are looking
+  // at one of them.
+  const AvailabilityAttr *A = getAttrForPlatform(S.Context, OffendingDecl);
+  if (A && A->isInherited()) {
+for (const Decl *Redecl = OffendingDecl->getMostRecentDecl(); Redecl;
+ Redecl = Redecl->getPreviousDecl()) {
+  const AvailabilityAttr *AForRedecl =
+  getAttrForPlatform(S.Context, Redecl);
+  if (AForRedecl && !AForRedecl->isInherited()) {
+// If D is a declaration with inherited attributes, the note should
+// point to the declaration with actual attributes.
+NoteLocation = Redecl->getLocation();
+break;
+  }
+}
+  }
+
   switch (K) {
+  case AR_NotYetIntroduced: {
+// We would like to emit the diagnostic even if -Wunguarded-availability is
+// not specified for deployment targets >= to iOS 11 or equivalent or
+// for declarations that were introduced in iOS 11 (macOS 10.13, ...) or
+// later.
+const AvailabilityAttr *AA =
+getAttrForPlatform(S.getASTContext(), OffendingDecl);
+VersionTuple Introduced = AA->getIntroduced();
+
+bool UseNewWarning = shouldDiagnoseAvailabilityByDefault(
+S.Context, S.Context.getTargetInfo().getPlatformMinVersion(),
+Introduced);
+unsigned Warning = UseNewWarning ? diag::warn_unguarded_availability_new
+ : diag::warn_unguarded_availability;
+
+S.Diag(Loc, Warning)
+<< OffendingDecl
+<< AvailabilityAttr::getPrettyPlatformName(
+   S.getASTContext().getTargetInfo().getPlatformName())
+<< Introduced.getAsString();
+
+S.Diag(OffendingDecl->getLocation(), diag::note_availability_specified_here)
+<< OffendingDecl << /* partial */ 3;
+
+if (const auto *Enclosing = findEnclosingDeclToAnnotate(Ctx)) {
+  if (auto *TD = dyn_cast(Enclosing))
+if (TD->getDeclName().isEmpty()) {
+  S.Diag(TD->getLocation(),
+ diag::note_decl_unguarded_availability_silence)
+  << /*Anonymous*/ 1 << TD->getKindName();
+  return;
+}
+  auto FixitNoteDiag =
+  S.Diag(Enclosing->getLocation(),
+ diag::note_decl_unguarded_availability_silence)
+  << /*Named*/ 0 << Enclosing;
+  // Don't offer a fixit for declarations with availability attributes.
+  if (Enclosing->hasAttr())
+return;
+  if (!S.getPreprocessor().isMacroDefined("API_AVAILABLE"))
+return;
+  Optional Insertion = createAttributeInsertion(
+  Enclosing, S.getSourceManager(), S.getLangOpts());
+  if (!Insertion)
+return;
+  std::string PlatformName =
+  AvailabilityAttr::getPlatformNameSourceSpelling(
+  S.getASTContext().getTargetInfo().getPlatformName())
+  .lower();
+  std::string Introduced =
+  OffendingDecl->getVersionIntroduced().getAsString();
+  FixitNoteDiag << FixItHint::CreateInsertion(
+  Insertion->Loc,
+  (llvm::Twine(Insertion->Prefix) + "API_AVAILABLE(" + PlatformName +
+   "(" + Introduced + "))" + Insertion->Suffix)
+  .str());
+}
+return;
+  }
   case AR_Deprecated:
 diag = !ObjCPropertyAccess ? diag::warn_deprecated
: diag::warn_property_method_deprecated;
@@ -7193,28 +7269,6 @@
 }
 break;
 
-  case AR_NotYetIntroduced: {
-// We would like to emit the diagnostic even if -Wunguarded-availability is
-// not specified for deployment targets >= to iOS 11 or equivalent or
-// for declarations that were introduced in iOS 11 (macOS 10.13, ...) or
-// later.
-const AvailabilityAttr *AA =
-getAttrForPlatform(S.getASTContext(), OffendingDecl);
-VersionTuple Introduced = AA->getIntroduced();
-bool NewWarning = shouldDiagnoseAvailabilityByDefault(
-S.Context, S.Context.getTargetInfo().getPlatformMinVersion(),
-Introduced);
-diag = NewWarning ? diag::warn_partial_availability_new
-  : 

r310874 - [Sema] Improve some -Wunguarded-availability diagnostics

2017-08-14 Thread Erik Pilkington via cfe-commits
Author: epilk
Date: Mon Aug 14 12:49:12 2017
New Revision: 310874

URL: http://llvm.org/viewvc/llvm-project?rev=310874=rev
Log:
[Sema] Improve some -Wunguarded-availability diagnostics

rdar://33543523
Differential revision: https://reviews.llvm.org/D36200

Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Sema/SemaDeclAttr.cpp
cfe/trunk/test/SemaObjC/attr-availability.m
cfe/trunk/test/SemaObjC/unguarded-availability-new.m
cfe/trunk/test/SemaObjC/unguarded-availability.m

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=310874=310873=310874=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Mon Aug 14 12:49:12 
2017
@@ -2896,25 +2896,11 @@ def warn_unguarded_availability :
 def warn_unguarded_availability_new :
   Warning,
   InGroup;
-def warn_partial_availability : Warning<"%0 is only available conditionally">,
-InGroup, DefaultIgnore;
-def warn_partial_availability_new : Warning,
-  InGroup;
-def note_partial_availability_silence : Note<
-  "annotate %select{%1|anonymous %1}0 with an availability attribute to 
silence">;
+def note_decl_unguarded_availability_silence : Note<
+  "annotate %select{%1|anonymous %1}0 with an availability attribute to 
silence this warning">;
 def note_unguarded_available_silence : Note<
   "enclose %0 in %select{an @available|a __builtin_available}1 check to 
silence"
   " this warning">;
-def warn_partial_message : Warning<"%0 is partial: %1">,
-InGroup, DefaultIgnore;
-def warn_partial_message_new : Warning,
-  InGroup;
-def warn_partial_fwdclass_message : Warning<
-"%0 may be partial because the receiver type is unknown">,
-InGroup, DefaultIgnore;
-def warn_partial_fwdclass_message_new :
-  Warning,
-  InGroup;
 def warn_at_available_unchecked_use : Warning<
   "%select{@available|__builtin_available}0 does not guard availability here; "
   "use if (%select{@available|__builtin_available}0) instead">,

Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=310874=310873=310874=diff
==
--- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Mon Aug 14 12:49:12 2017
@@ -7128,7 +7128,83 @@ static void DoEmitAvailabilityWarning(Se
   if (!ShouldDiagnoseAvailabilityInContext(S, K, DeclVersion, Ctx))
 return;
 
+  // The declaration can have multiple availability attributes, we are looking
+  // at one of them.
+  const AvailabilityAttr *A = getAttrForPlatform(S.Context, OffendingDecl);
+  if (A && A->isInherited()) {
+for (const Decl *Redecl = OffendingDecl->getMostRecentDecl(); Redecl;
+ Redecl = Redecl->getPreviousDecl()) {
+  const AvailabilityAttr *AForRedecl =
+  getAttrForPlatform(S.Context, Redecl);
+  if (AForRedecl && !AForRedecl->isInherited()) {
+// If D is a declaration with inherited attributes, the note should
+// point to the declaration with actual attributes.
+NoteLocation = Redecl->getLocation();
+break;
+  }
+}
+  }
+
   switch (K) {
+  case AR_NotYetIntroduced: {
+// We would like to emit the diagnostic even if -Wunguarded-availability is
+// not specified for deployment targets >= to iOS 11 or equivalent or
+// for declarations that were introduced in iOS 11 (macOS 10.13, ...) or
+// later.
+const AvailabilityAttr *AA =
+getAttrForPlatform(S.getASTContext(), OffendingDecl);
+VersionTuple Introduced = AA->getIntroduced();
+
+bool UseNewWarning = shouldDiagnoseAvailabilityByDefault(
+S.Context, S.Context.getTargetInfo().getPlatformMinVersion(),
+Introduced);
+unsigned Warning = UseNewWarning ? diag::warn_unguarded_availability_new
+ : diag::warn_unguarded_availability;
+
+S.Diag(Loc, Warning)
+<< OffendingDecl
+<< AvailabilityAttr::getPrettyPlatformName(
+   S.getASTContext().getTargetInfo().getPlatformName())
+<< Introduced.getAsString();
+
+S.Diag(OffendingDecl->getLocation(), 
diag::note_availability_specified_here)
+<< OffendingDecl << /* partial */ 3;
+
+if (const auto *Enclosing = findEnclosingDeclToAnnotate(Ctx)) {
+  if (auto *TD = dyn_cast(Enclosing))
+if (TD->getDeclName().isEmpty()) {
+  S.Diag(TD->getLocation(),
+ diag::note_decl_unguarded_availability_silence)
+  << /*Anonymous*/ 1 << TD->getKindName();
+  return;
+}
+  auto FixitNoteDiag =
+  S.Diag(Enclosing->getLocation(),
+ diag::note_decl_unguarded_availability_silence)
+ 

[PATCH] D36707: [CodeGen]Refactor CpuSupports/CPUIs Builtin Code Gen to better work with "target" implementation

2017-08-14 Thread Erich Keane via Phabricator via cfe-commits
erichkeane created this revision.

A small set of refactors that'll make it easier for me to implement 'target' 
support.

First, extract the CPUSupports functionality into its own function.  THis has 
the advantage of not wasting time in this builtin to deal with arguments.  
Second, pulls both CPUSupports and CPUIs implementation into a member-function, 
so that it can be called from the resolver generation that I'm working on.
Third, creates an overload that takes simply the feature/cpu name (rather than 
extracting it from a callexpr), since that info isn't available later.

Note that despite how the 'diff' looks, the EmitX86CPUSupports function simply 
takes the implementation out of the 'switch'.


https://reviews.llvm.org/D36707

Files:
  lib/CodeGen/CGBuiltin.cpp
  lib/CodeGen/CodeGenFunction.h

Index: lib/CodeGen/CodeGenFunction.h
===
--- lib/CodeGen/CodeGenFunction.h
+++ lib/CodeGen/CodeGenFunction.h
@@ -3841,6 +3841,12 @@
 
   void EmitSanitizerStatReport(llvm::SanitizerStatKind SSK);
 
+
+  llvm::Value *EmitX86CpuIs(const CallExpr *E);
+  llvm::Value *EmitX86CpuIs(StringRef CPUStr);
+  llvm::Value *EmitX86CpuSupports(const CallExpr *E);
+  llvm::Value *EmitX86CpuSupports(StringRef FeatureStr);
+
 private:
   QualType getVarArgType(const Expr *Arg);
 
Index: lib/CodeGen/CGBuiltin.cpp
===
--- lib/CodeGen/CGBuiltin.cpp
+++ lib/CodeGen/CGBuiltin.cpp
@@ -7287,9 +7287,13 @@
   return CGF.Builder.CreateSExt(Mask, DstTy, "vpmovm2");
 }
 
-static Value *EmitX86CpuIs(CodeGenFunction , const CallExpr *E) {
+Value *CodeGenFunction::EmitX86CpuIs(const CallExpr *E) {
   const Expr *CPUExpr = E->getArg(0)->IgnoreParenCasts();
   StringRef CPUStr = cast(CPUExpr)->getString();
+  return EmitX86CpuIs(CPUStr);
+}
+
+Value *CodeGenFunction::EmitX86CpuIs(StringRef CPUStr) {
 
   // This enum contains the vendor, type, and subtype enums from the
   // runtime library concatenated together. The _START labels mark
@@ -7359,7 +7363,7 @@
   .Case("westmere", INTEL_COREI7_WESTMERE)
   .Case("znver1", AMDFAM17H_ZNVER1);
 
-  llvm::Type *Int32Ty = CGF.Builder.getInt32Ty();
+  llvm::Type *Int32Ty = Builder.getInt32Ty();
 
   // Matching the struct layout from the compiler-rt/libgcc structure that is
   // filled in:
@@ -7371,7 +7375,7 @@
   llvm::ArrayType::get(Int32Ty, 1));
 
   // Grab the global __cpu_model.
-  llvm::Constant *CpuModel = CGF.CGM.CreateRuntimeVariable(STy, "__cpu_model");
+  llvm::Constant *CpuModel = CGM.CreateRuntimeVariable(STy, "__cpu_model");
 
   // Calculate the index needed to access the correct field based on the
   // range. Also adjust the expected value.
@@ -7393,18 +7397,127 @@
 ConstantInt::get(Int32Ty, 0),
 ConstantInt::get(Int32Ty, Index)
   };
-  llvm::Value *CpuValue = CGF.Builder.CreateGEP(STy, CpuModel, Idxs);
-  CpuValue = CGF.Builder.CreateAlignedLoad(CpuValue, CharUnits::fromQuantity(4));
+  llvm::Value *CpuValue = Builder.CreateGEP(STy, CpuModel, Idxs);
+  CpuValue = Builder.CreateAlignedLoad(CpuValue, CharUnits::fromQuantity(4));
 
   // Check the value of the field against the requested value.
-  return CGF.Builder.CreateICmpEQ(CpuValue,
+  return Builder.CreateICmpEQ(CpuValue,
   llvm::ConstantInt::get(Int32Ty, Value));
 }
 
+Value *CodeGenFunction::EmitX86CpuSupports(const CallExpr *E) {
+  const Expr *FeatureExpr = E->getArg(0)->IgnoreParenCasts();
+  StringRef FeatureStr = cast(FeatureExpr)->getString();
+  return EmitX86CpuSupports(FeatureStr);
+}
+
+Value *CodeGenFunction::EmitX86CpuSupports(StringRef FeatureStr) {
+  // TODO: When/if this becomes more than x86 specific then use a TargetInfo
+  // based mapping.
+  // Processor features and mapping to processor feature value.
+  enum X86Features {
+CMOV = 0,
+MMX,
+POPCNT,
+SSE,
+SSE2,
+SSE3,
+SSSE3,
+SSE4_1,
+SSE4_2,
+AVX,
+AVX2,
+SSE4_A,
+FMA4,
+XOP,
+FMA,
+AVX512F,
+BMI,
+BMI2,
+AES,
+PCLMUL,
+AVX512VL,
+AVX512BW,
+AVX512DQ,
+AVX512CD,
+AVX512ER,
+AVX512PF,
+AVX512VBMI,
+AVX512IFMA,
+AVX5124VNNIW,
+AVX5124FMAPS,
+AVX512VPOPCNTDQ,
+MAX
+  };
+
+  X86Features Feature =
+  StringSwitch(FeatureStr)
+  .Case("cmov", X86Features::CMOV)
+  .Case("mmx", X86Features::MMX)
+  .Case("popcnt", X86Features::POPCNT)
+  .Case("sse", X86Features::SSE)
+  .Case("sse2", X86Features::SSE2)
+  .Case("sse3", X86Features::SSE3)
+  .Case("ssse3", X86Features::SSSE3)
+  .Case("sse4.1", X86Features::SSE4_1)
+  .Case("sse4.2", X86Features::SSE4_2)
+  .Case("avx", X86Features::AVX)
+  .Case("avx2", X86Features::AVX2)
+  .Case("sse4a", X86Features::SSE4_A)
+  .Case("fma4", X86Features::FMA4)
+  

[PATCH] D36580: [OpenCL] Support variable memory scope in atomic builtins

2017-08-14 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: include/clang/Basic/SyncScope.h:92
+/// \brief Defines the synch scope ABI for OpenCL.
+class AtomicScopeOpenCLABI : public AtomicScopeABI {
+public:

yaxunl wrote:
> rjmccall wrote:
> > yaxunl wrote:
> > > rjmccall wrote:
> > > > Please correct me if I'm wrong, but I believe you don't get to define 
> > > > the "ABI for OpenCL" any more than I get to define the "ABI for C".  
> > > > You're defining the ABI for your specific OpenCL implementation, but 
> > > > Clang might reasonably support other implementations with their own 
> > > > ABIs.  So this name is inappropriate.
> > > > 
> > > > Now, if I understand how SPIR works, SPIR does require some sort of 
> > > > stable lowering of these atomic operations in order to ensure that the 
> > > > resulting LLVM IR can be ingested into an arbitrary implementation.  
> > > > (Ot at least that was true prior to SPIR V?)  Therefore, SPIR needs to 
> > > > specify a lowering for these atomic operations, and that probably 
> > > > includes ABI values for specific sync-scopes.  But the appropriate name 
> > > > for that would be the "SPIR ABI", not the "OpenCL ABI".  And, of 
> > > > course, you would need to be sure that you're implementing the lowering 
> > > > that SPIR actually wants.
> > > The ABI is not intended for a specific OpenCL implementation, but for 
> > > extending to other languages. For example, we have a downstream C++ based 
> > > language called HCC, which may support atomic scope with an ABI different 
> > > than OpenCL atomic scope ABI.
> > By "ABI" you mean that it might present a different model of 
> > synchronization scopes to the source language?  Okay, that's great, and it 
> > explains a lot of things that were very murky about some of our previous 
> > conversations.
> > 
> > In that case, I think the appropriate design for these builtins is:
> > 
> >   - They don't need to be in the __builtin_opencl namespace.
> >   - They *do* need to be enabled only in language modes with well-defined 
> > sync-scope models, which for now just means OpenCL. 
> >   - The language mode's sync-scope model should determine everything about 
> > the scope argument, including its type.  Sema-level validation requires 
> > first determining the language's sync-scope model.
> >   - There is no meaningful way to "default" the scope argument on the 
> > non-scoped builtins the way that we are now.  Instead, the scope argument 
> > should only exist for the scoped builtins.
> > 
> > Alternatively, if you potentially want the opencl-model builtins to be 
> > usable from non-opencl languages, the right design is for HCC to use its 
> > own set of builtins with their own type-checking rules.
> > 
> > In either case, I don't think it's a good idea to call this "ABI", which is 
> > associated too strongly with target-lowering concepts.  You're really 
> > talking about a source-language concept.
> We could introduce __builtin_hcc_atomic_* in downstream HCC.
> 
> We need a generic approach to represent atomic scope values for different 
> languages and associated semantic/codegen needs, and AtomicScopeABI seems 
> generic enough to serve the purpose. It has interface for semantic checking 
> (isValid), and the interface to map to LLVM sync scope for both constant and 
> variable arguments. If the name is not proper, we could rename it to just 
> `AtomicScope`.
> 
> I can remove the default atomic scope for atomic expressions without scope 
> originally. For them I just emit LLVM atomic instructions with default LLVM 
> synch scope.
I agree that there's value in having a generic approach even if you're going to 
have different builtins for different scope models.  However, if you do use 
different builtins for different scope models, you need to make sure that you 
pick the appropriate model for the builtin being used, not according to the 
current language mode.  That is, there should be some way to map a builtin ID 
to an AtomicScopeModelKind (values: None, OpenCL, (future) HCC), and then you 
can use that to create an AtomicScopeModel, which can have all these methods on 
it.

I would encourage you to go ahead and give AtomicScopeModel an implementation 
file and move more of these method definitions into that.



Comment at: include/clang/Basic/SyncScope.h:105
+
+  AtomicScopeOpenCLABI() {}
+

I would call this OpenCLAtomicScopeModel.



Comment at: include/clang/Basic/SyncScope.h:128
+static_assert(Last == SubGroup, "Does not include all synch scopes");
+static unsigned Scopes[] = {
+static_cast(WorkGroup), static_cast(Device),

Make this const, please.


https://reviews.llvm.org/D36580



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


Re: r310379 - Revert "[OPENMP][DEBUG] Set proper address space info if required by target."

2017-08-14 Thread David Blaikie via cfe-commits
It's helpful to mention why a patch is reverted in the commit message that
reverts. Thought for next time! :)

On Tue, Aug 8, 2017 at 9:46 AM Alexey Bataev via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: abataev
> Date: Tue Aug  8 09:45:36 2017
> New Revision: 310379
>
> URL: http://llvm.org/viewvc/llvm-project?rev=310379=rev
> Log:
> Revert "[OPENMP][DEBUG] Set proper address space info if required by
> target."
>
> This reverts commit r310377.
>
> Removed:
> cfe/trunk/test/OpenMP/target_parallel_debug_codegen.cpp
> Modified:
> cfe/trunk/include/clang/Basic/Attr.td
> cfe/trunk/include/clang/Sema/Sema.h
> cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h
> cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
> cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.h
> cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
> cfe/trunk/lib/Sema/SemaExpr.cpp
> cfe/trunk/lib/Sema/SemaOpenMP.cpp
> cfe/trunk/test/OpenMP/nvptx_target_firstprivate_codegen.cpp
>
> Modified: cfe/trunk/include/clang/Basic/Attr.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=310379=310378=310379=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/Attr.td (original)
> +++ cfe/trunk/include/clang/Basic/Attr.td Tue Aug  8 09:45:36 2017
> @@ -2685,14 +2685,6 @@ def OMPCaptureNoInit : InheritableAttr {
>let Documentation = [Undocumented];
>  }
>
> -def OMPCaptureKind : Attr {
> -  // This attribute has no spellings as it is only ever created
> implicitly.
> -  let Spellings = [];
> -  let SemaHandler = 0;
> -  let Args = [UnsignedArgument<"CaptureKind">];
> -  let Documentation = [Undocumented];
> -}
> -
>  def OMPDeclareSimdDecl : Attr {
>let Spellings = [Pragma<"omp", "declare simd">];
>let Subjects = SubjectList<[Function]>;
>
> Modified: cfe/trunk/include/clang/Sema/Sema.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=310379=310378=310379=diff
>
> ==
> --- cfe/trunk/include/clang/Sema/Sema.h (original)
> +++ cfe/trunk/include/clang/Sema/Sema.h Tue Aug  8 09:45:36 2017
> @@ -8527,11 +8527,6 @@ public:
>/// is performed.
>bool isOpenMPPrivateDecl(ValueDecl *D, unsigned Level);
>
> -  /// Sets OpenMP capture kind (OMPC_private, OMPC_firstprivate, OMPC_map
> etc.)
> -  /// for \p FD based on DSA for the provided corresponding captured
> declaration
> -  /// \p D.
> -  void setOpenMPCaptureKind(FieldDecl *FD, ValueDecl *D, unsigned Level);
> -
>/// \brief Check if the specified variable is captured  by 'target'
> directive.
>/// \param Level Relative level of nested OpenMP construct for that the
> check
>/// is performed.
>
> Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h?rev=310379=310378=310379=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h (original)
> +++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h Tue Aug  8 09:45:36 2017
> @@ -1325,32 +1325,6 @@ public:
>virtual void emitDoacrossOrdered(CodeGenFunction ,
> const OMPDependClause *C);
>
> -  /// Translates the native parameter of outlined function if this is
> required
> -  /// for target.
> -  /// \param FD Field decl from captured record for the paramater.
> -  /// \param NativeParam Parameter itself.
> -  virtual const VarDecl *translateParameter(const FieldDecl *FD,
> -const VarDecl *NativeParam)
> const {
> -return NativeParam;
> -  }
> -
> -  typedef llvm::function_ref Address)>
> -  MappingFnType;
> -  /// Maps the native argument to the address of the corresponding
> -  /// target-specific argument.
> -  /// \param FD Field decl from captured record for the paramater.
> -  /// \param NativeParam Parameter itself.
> -  /// \param TargetParam Corresponding target-specific parameter.
> -  /// \param MapFn Function that maps the native parameter to the address
> of the
> -  /// target-specific.
> -  virtual void mapParameterAddress(CodeGenFunction , const FieldDecl
> *FD,
> -   const VarDecl *NativeParam,
> -   const VarDecl *TargetParam,
> -   const MappingFnType) const {
> -assert(NativeParam == TargetParam &&
> -   "native and target args must be the same");
> -  }
> -
>/// Emits call of the outlined function with the provided arguments,
>/// translating these arguments to correct target-specific arguments.
>virtual void
>
> Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
> URL:
> 

[PATCH] D36686: [clang-diff] Add option to compare files across git revisions

2017-08-14 Thread Johannes Altmanninger via Phabricator via cfe-commits
johannes added a comment.

In https://reviews.llvm.org/D36686#840827, @arphaman wrote:

> It might be useful to have both source and destination in a different 
> revision. Maybe something like `-src-git-rev` and `-dst-git-rev`?


Then I'd rather have a revision range such as `-git-revs ..`
and if there is only one specified, then ..HEAD is implied
maybe a different name for the argument

The whole thing is a bit of a hack - if the HEAD is dirty then the checkout 
fails and the program exits.

I want to change it so it does not interfere with the state of the repository. 
I can checkout the revisions in a temporary repository and then patch the paths 
in the compilation database.


https://reviews.llvm.org/D36686



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


[PATCH] D35743: [clang-format] Handle Structured binding declaration in C++17

2017-08-14 Thread Chih-Hung Hsieh via Phabricator via cfe-commits
chh added a comment.

Daniel, Manuel, I will take over this CL since Yan has finished his internship 
at Google.,
Yan's latest patch to tryToParseLambda looks acceptable to me.
I think it should take care of new kw_auto in additional to kw_new, ke_delete, 
etc.

Could you suggest if there is any better way to handle the new syntax?
Thanks.


https://reviews.llvm.org/D35743



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


[PATCH] D36580: [OpenCL] Support variable memory scope in atomic builtins

2017-08-14 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl marked 4 inline comments as done.
yaxunl added inline comments.



Comment at: include/clang/Basic/SyncScope.h:92
+/// \brief Defines the synch scope ABI for OpenCL.
+class AtomicScopeOpenCLABI : public AtomicScopeABI {
+public:

rjmccall wrote:
> yaxunl wrote:
> > rjmccall wrote:
> > > Please correct me if I'm wrong, but I believe you don't get to define the 
> > > "ABI for OpenCL" any more than I get to define the "ABI for C".  You're 
> > > defining the ABI for your specific OpenCL implementation, but Clang might 
> > > reasonably support other implementations with their own ABIs.  So this 
> > > name is inappropriate.
> > > 
> > > Now, if I understand how SPIR works, SPIR does require some sort of 
> > > stable lowering of these atomic operations in order to ensure that the 
> > > resulting LLVM IR can be ingested into an arbitrary implementation.  (Ot 
> > > at least that was true prior to SPIR V?)  Therefore, SPIR needs to 
> > > specify a lowering for these atomic operations, and that probably 
> > > includes ABI values for specific sync-scopes.  But the appropriate name 
> > > for that would be the "SPIR ABI", not the "OpenCL ABI".  And, of course, 
> > > you would need to be sure that you're implementing the lowering that SPIR 
> > > actually wants.
> > The ABI is not intended for a specific OpenCL implementation, but for 
> > extending to other languages. For example, we have a downstream C++ based 
> > language called HCC, which may support atomic scope with an ABI different 
> > than OpenCL atomic scope ABI.
> By "ABI" you mean that it might present a different model of synchronization 
> scopes to the source language?  Okay, that's great, and it explains a lot of 
> things that were very murky about some of our previous conversations.
> 
> In that case, I think the appropriate design for these builtins is:
> 
>   - They don't need to be in the __builtin_opencl namespace.
>   - They *do* need to be enabled only in language modes with well-defined 
> sync-scope models, which for now just means OpenCL. 
>   - The language mode's sync-scope model should determine everything about 
> the scope argument, including its type.  Sema-level validation requires first 
> determining the language's sync-scope model.
>   - There is no meaningful way to "default" the scope argument on the 
> non-scoped builtins the way that we are now.  Instead, the scope argument 
> should only exist for the scoped builtins.
> 
> Alternatively, if you potentially want the opencl-model builtins to be usable 
> from non-opencl languages, the right design is for HCC to use its own set of 
> builtins with their own type-checking rules.
> 
> In either case, I don't think it's a good idea to call this "ABI", which is 
> associated too strongly with target-lowering concepts.  You're really talking 
> about a source-language concept.
We could introduce __builtin_hcc_atomic_* in downstream HCC.

We need a generic approach to represent atomic scope values for different 
languages and associated semantic/codegen needs, and AtomicScopeABI seems 
generic enough to serve the purpose. It has interface for semantic checking 
(isValid), and the interface to map to LLVM sync scope for both constant and 
variable arguments. If the name is not proper, we could rename it to just 
`AtomicScope`.

I can remove the default atomic scope for atomic expressions without scope 
originally. For them I just emit LLVM atomic instructions with default LLVM 
synch scope.


https://reviews.llvm.org/D36580



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


[PATCH] D35670: [StaticAnalyzer] Handle LoopExit CFGElement in the analyzer

2017-08-14 Thread Devin Coughlin via Phabricator via cfe-commits
dcoughlin added a comment.

Also, please mention in the commit message that tests will be added in a 
following commit.


https://reviews.llvm.org/D35670



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


[PATCH] D36572: Implemented P0409R2 - Allow lambda capture [=, this]

2017-08-14 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: test/FixIt/fixit-cxx0x.cpp:57
   (void)[&, , ]{}; // expected-error 2{{'&' cannot precede a capture when 
the capture default is '&'}}
-  (void)[=, this]{ this->g(5); }; // expected-error{{'this' cannot be 
explicitly captured}}
   (void)[i, i]{ }; // expected-error{{'i' can appear only once in a capture 
list}}

hamzasood wrote:
> rjmccall wrote:
> > rjmccall wrote:
> > > hamzasood wrote:
> > > > rjmccall wrote:
> > > > > hamzasood wrote:
> > > > > > rjmccall wrote:
> > > > > > > hamzasood wrote:
> > > > > > > > rjmccall wrote:
> > > > > > > > > Shouldn't you only be accepting this in C++2a mode?
> > > > > > > > I'm not sure what the system is with allowing future language 
> > > > > > > > features as extensions, but I noticed that [*this] capture is 
> > > > > > > > allowed as an extension pre-C++17 so I figured it would make 
> > > > > > > > sense for [=, this] to also be allowed as an extension (since 
> > > > > > > > the proposal mentions how it's meant to increase code clarify 
> > > > > > > > in the presence of [*this]).
> > > > > > > Surely there should at least be an on-by-default extension 
> > > > > > > warning?  The behavior we're using sounds a lot more like we're 
> > > > > > > treating this as a bug-fix in the standard than a new feature.  
> > > > > > > Richard, can you weigh in here?
> > > > > > The extension warning for this 
> > > > > > (ext_equals_this_lambda_capture_cxx2a) is on by default.
> > > > > Why did the diagnostic disappear from this file, then?
> > > > That file is for FixIt hints, which I don't think make much sense for 
> > > > an extension warning (and I couldn't find any other extension warnings 
> > > > that offer FixIt hints)
> > > Sure, it's reasonable for this specific test to not test the warning.  
> > > However, since I don't see anything in this test that actually turns off 
> > > the warning, and since you have not in fact added any tests that verify 
> > > that the warning is ever turned on, I suspect that it is actually not 
> > > being emitted.
> > I'm sorry, I see that you've added an explicit test for the warning, but I 
> > still don't understand why the warning is not emitted in this file.  
> > -verify normally verifies all diagnostics, and this file is tested with 
> > -std=c++11.  Is there some special behavior of -fixit that disables 
> > warnings, or ignores them in -verify mode?
> Ah okay, now I know what you mean. The line you’re talking about has actually 
> been removed completely from the fixit test.
Oh, of course, I should've realized that right away.  Sorry for the run-around.

In that case, this all LGTM.


https://reviews.llvm.org/D36572



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


[PATCH] D35670: [StaticAnalyzer] Handle LoopExit CFGElement in the analyzer

2017-08-14 Thread Devin Coughlin via Phabricator via cfe-commits
dcoughlin accepted this revision.
dcoughlin added a comment.
This revision is now accepted and ready to land.

Looks good to me! (Please expand the comment, though.)




Comment at: include/clang/Analysis/ProgramPoint.h:658
 
+class LoopExit : public ProgramPoint {
+public:

szepet wrote:
> dcoughlin wrote:
> > Can you add a comment explaining what meaning of this program point is.
> Can you help me with that? I am not sure what is important to say about this 
> point to understand it better than from its name.
My recommendation would be to think about it from the perspective of someone 
new to the codebase trying to understand when the analyzer will reach such a 
program point. What additional context will they need that is not conveyed in 
the name alone?

At a minimum, I think it is worth mentioning that a LoopExit point can arise 
even when a loop is not entered and that not all loop exits will result in a 
LoopExit program point.


https://reviews.llvm.org/D35670



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


[PATCH] D36580: [OpenCL] Support variable memory scope in atomic builtins

2017-08-14 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: include/clang/Basic/SyncScope.h:92
+/// \brief Defines the synch scope ABI for OpenCL.
+class AtomicScopeOpenCLABI : public AtomicScopeABI {
+public:

yaxunl wrote:
> rjmccall wrote:
> > Please correct me if I'm wrong, but I believe you don't get to define the 
> > "ABI for OpenCL" any more than I get to define the "ABI for C".  You're 
> > defining the ABI for your specific OpenCL implementation, but Clang might 
> > reasonably support other implementations with their own ABIs.  So this name 
> > is inappropriate.
> > 
> > Now, if I understand how SPIR works, SPIR does require some sort of stable 
> > lowering of these atomic operations in order to ensure that the resulting 
> > LLVM IR can be ingested into an arbitrary implementation.  (Ot at least 
> > that was true prior to SPIR V?)  Therefore, SPIR needs to specify a 
> > lowering for these atomic operations, and that probably includes ABI values 
> > for specific sync-scopes.  But the appropriate name for that would be the 
> > "SPIR ABI", not the "OpenCL ABI".  And, of course, you would need to be 
> > sure that you're implementing the lowering that SPIR actually wants.
> The ABI is not intended for a specific OpenCL implementation, but for 
> extending to other languages. For example, we have a downstream C++ based 
> language called HCC, which may support atomic scope with an ABI different 
> than OpenCL atomic scope ABI.
By "ABI" you mean that it might present a different model of synchronization 
scopes to the source language?  Okay, that's great, and it explains a lot of 
things that were very murky about some of our previous conversations.

In that case, I think the appropriate design for these builtins is:

  - They don't need to be in the __builtin_opencl namespace.
  - They *do* need to be enabled only in language modes with well-defined 
sync-scope models, which for now just means OpenCL. 
  - The language mode's sync-scope model should determine everything about the 
scope argument, including its type.  Sema-level validation requires first 
determining the language's sync-scope model.
  - There is no meaningful way to "default" the scope argument on the 
non-scoped builtins the way that we are now.  Instead, the scope argument 
should only exist for the scoped builtins.

Alternatively, if you potentially want the opencl-model builtins to be usable 
from non-opencl languages, the right design is for HCC to use its own set of 
builtins with their own type-checking rules.

In either case, I don't think it's a good idea to call this "ABI", which is 
associated too strongly with target-lowering concepts.  You're really talking 
about a source-language concept.


https://reviews.llvm.org/D36580



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


[PATCH] D36702: Make Parser::Consume*Token methods public.

2017-08-14 Thread Frederich Munch via Phabricator via cfe-commits
marsupial created this revision.

The fix in r303372 exposed a problem when using **Parser::ConsumeToken** from 
client code in DEBUG.
**ConsumeToken** will assert for all **isTokenSpecial()** cases, but there is 
no way to call the proper method.

The isToken methods are just convenient.


https://reviews.llvm.org/D36702

Files:
  include/clang/Parse/Parser.h


Index: include/clang/Parse/Parser.h
===
--- include/clang/Parse/Parser.h
+++ include/clang/Parse/Parser.h
@@ -348,11 +348,6 @@
 return Actions.getNullabilityKeyword(nullability);
   }
 
-private:
-  
//======//
-  // Low-Level token peeking and consumption methods.
-  //
-
   /// isTokenParen - Return true if the cur token is '(' or ')'.
   bool isTokenParen() const {
 return Tok.isOneOf(tok::l_paren, tok::r_paren);
@@ -375,19 +370,6 @@
isTokenBrace() || Tok.is(tok::code_completion) || 
Tok.isAnnotation();
   }
 
-  /// \brief Returns true if the current token is '=' or is a type of '='.
-  /// For typos, give a fixit to '='
-  bool isTokenEqualOrEqualTypo();
-
-  /// \brief Return the current token to the token stream and make the given
-  /// token the current token.
-  void UnconsumeToken(Token ) {
-  Token Next = Tok;
-  PP.EnterToken(Consumed);
-  PP.Lex(Tok);
-  PP.EnterToken(Next);
-  }
-
   /// ConsumeAnyToken - Dispatch to the right Consume* method based on the
   /// current token type.  This should only be used in cases where the type of
   /// the token really isn't known, e.g. in error recovery.
@@ -481,6 +463,24 @@
 return PrevTokLocation;
   }
 
+private:
+  
//======//
+  // Low-Level token peeking and consumption methods.
+  //
+
+  /// \brief Returns true if the current token is '=' or is a type of '='.
+  /// For typos, give a fixit to '='
+  bool isTokenEqualOrEqualTypo();
+
+  /// \brief Return the current token to the token stream and make the given
+  /// token the current token.
+  void UnconsumeToken(Token ) {
+  Token Next = Tok;
+  PP.EnterToken(Consumed);
+  PP.Lex(Tok);
+  PP.EnterToken(Next);
+  }
+
   ///\ brief When we are consuming a code-completion token without having
   /// matched specific position in the grammar, provide code-completion results
   /// based on context.


Index: include/clang/Parse/Parser.h
===
--- include/clang/Parse/Parser.h
+++ include/clang/Parse/Parser.h
@@ -348,11 +348,6 @@
 return Actions.getNullabilityKeyword(nullability);
   }
 
-private:
-  //======//
-  // Low-Level token peeking and consumption methods.
-  //
-
   /// isTokenParen - Return true if the cur token is '(' or ')'.
   bool isTokenParen() const {
 return Tok.isOneOf(tok::l_paren, tok::r_paren);
@@ -375,19 +370,6 @@
isTokenBrace() || Tok.is(tok::code_completion) || Tok.isAnnotation();
   }
 
-  /// \brief Returns true if the current token is '=' or is a type of '='.
-  /// For typos, give a fixit to '='
-  bool isTokenEqualOrEqualTypo();
-
-  /// \brief Return the current token to the token stream and make the given
-  /// token the current token.
-  void UnconsumeToken(Token ) {
-  Token Next = Tok;
-  PP.EnterToken(Consumed);
-  PP.Lex(Tok);
-  PP.EnterToken(Next);
-  }
-
   /// ConsumeAnyToken - Dispatch to the right Consume* method based on the
   /// current token type.  This should only be used in cases where the type of
   /// the token really isn't known, e.g. in error recovery.
@@ -481,6 +463,24 @@
 return PrevTokLocation;
   }
 
+private:
+  //======//
+  // Low-Level token peeking and consumption methods.
+  //
+
+  /// \brief Returns true if the current token is '=' or is a type of '='.
+  /// For typos, give a fixit to '='
+  bool isTokenEqualOrEqualTypo();
+
+  /// \brief Return the current token to the token stream and make the given
+  /// token the current token.
+  void UnconsumeToken(Token ) {
+  Token Next = Tok;
+  PP.EnterToken(Consumed);
+  PP.Lex(Tok);
+  PP.EnterToken(Next);
+  }
+
   ///\ brief When we are consuming a code-completion token without having
   /// matched specific position in the grammar, provide code-completion results
   /// based on context.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D36572: Implemented P0409R2 - Allow lambda capture [=, this]

2017-08-14 Thread Hamza Sood via Phabricator via cfe-commits
hamzasood added inline comments.



Comment at: test/FixIt/fixit-cxx0x.cpp:57
   (void)[&, , ]{}; // expected-error 2{{'&' cannot precede a capture when 
the capture default is '&'}}
-  (void)[=, this]{ this->g(5); }; // expected-error{{'this' cannot be 
explicitly captured}}
   (void)[i, i]{ }; // expected-error{{'i' can appear only once in a capture 
list}}

rjmccall wrote:
> rjmccall wrote:
> > hamzasood wrote:
> > > rjmccall wrote:
> > > > hamzasood wrote:
> > > > > rjmccall wrote:
> > > > > > hamzasood wrote:
> > > > > > > rjmccall wrote:
> > > > > > > > Shouldn't you only be accepting this in C++2a mode?
> > > > > > > I'm not sure what the system is with allowing future language 
> > > > > > > features as extensions, but I noticed that [*this] capture is 
> > > > > > > allowed as an extension pre-C++17 so I figured it would make 
> > > > > > > sense for [=, this] to also be allowed as an extension (since the 
> > > > > > > proposal mentions how it's meant to increase code clarify in the 
> > > > > > > presence of [*this]).
> > > > > > Surely there should at least be an on-by-default extension warning? 
> > > > > >  The behavior we're using sounds a lot more like we're treating 
> > > > > > this as a bug-fix in the standard than a new feature.  Richard, can 
> > > > > > you weigh in here?
> > > > > The extension warning for this (ext_equals_this_lambda_capture_cxx2a) 
> > > > > is on by default.
> > > > Why did the diagnostic disappear from this file, then?
> > > That file is for FixIt hints, which I don't think make much sense for an 
> > > extension warning (and I couldn't find any other extension warnings that 
> > > offer FixIt hints)
> > Sure, it's reasonable for this specific test to not test the warning.  
> > However, since I don't see anything in this test that actually turns off 
> > the warning, and since you have not in fact added any tests that verify 
> > that the warning is ever turned on, I suspect that it is actually not being 
> > emitted.
> I'm sorry, I see that you've added an explicit test for the warning, but I 
> still don't understand why the warning is not emitted in this file.  -verify 
> normally verifies all diagnostics, and this file is tested with -std=c++11.  
> Is there some special behavior of -fixit that disables warnings, or ignores 
> them in -verify mode?
Ah okay, now I know what you mean. The line you’re talking about has actually 
been removed completely from the fixit test.


https://reviews.llvm.org/D36572



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


[PATCH] D36701: Use Token::isOneOf method in Parser.

2017-08-14 Thread Frederich Munch via Phabricator via cfe-commits
marsupial created this revision.

Easier to read and possibly optimize.


https://reviews.llvm.org/D36701

Files:
  include/clang/Parse/Parser.h


Index: include/clang/Parse/Parser.h
===
--- include/clang/Parse/Parser.h
+++ include/clang/Parse/Parser.h
@@ -355,15 +355,15 @@
 
   /// isTokenParen - Return true if the cur token is '(' or ')'.
   bool isTokenParen() const {
-return Tok.getKind() == tok::l_paren || Tok.getKind() == tok::r_paren;
+return Tok.isOneOf(tok::l_paren, tok::r_paren);
   }
   /// isTokenBracket - Return true if the cur token is '[' or ']'.
   bool isTokenBracket() const {
-return Tok.getKind() == tok::l_square || Tok.getKind() == tok::r_square;
+return Tok.isOneOf(tok::l_square, tok::r_square);
   }
   /// isTokenBrace - Return true if the cur token is '{' or '}'.
   bool isTokenBrace() const {
-return Tok.getKind() == tok::l_brace || Tok.getKind() == tok::r_brace;
+return Tok.isOneOf(tok::l_brace, tok::r_brace);
   }
   /// isTokenStringLiteral - True if this token is a string-literal.
   bool isTokenStringLiteral() const {


Index: include/clang/Parse/Parser.h
===
--- include/clang/Parse/Parser.h
+++ include/clang/Parse/Parser.h
@@ -355,15 +355,15 @@
 
   /// isTokenParen - Return true if the cur token is '(' or ')'.
   bool isTokenParen() const {
-return Tok.getKind() == tok::l_paren || Tok.getKind() == tok::r_paren;
+return Tok.isOneOf(tok::l_paren, tok::r_paren);
   }
   /// isTokenBracket - Return true if the cur token is '[' or ']'.
   bool isTokenBracket() const {
-return Tok.getKind() == tok::l_square || Tok.getKind() == tok::r_square;
+return Tok.isOneOf(tok::l_square, tok::r_square);
   }
   /// isTokenBrace - Return true if the cur token is '{' or '}'.
   bool isTokenBrace() const {
-return Tok.getKind() == tok::l_brace || Tok.getKind() == tok::r_brace;
+return Tok.isOneOf(tok::l_brace, tok::r_brace);
   }
   /// isTokenStringLiteral - True if this token is a string-literal.
   bool isTokenStringLiteral() const {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D36580: [OpenCL] Support variable memory scope in atomic builtins

2017-08-14 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl marked 7 inline comments as done.
yaxunl added inline comments.



Comment at: include/clang/Basic/SyncScope.h:89
+  static std::unique_ptr create(LangOptions );
+};
+

rjmccall wrote:
> The previous design of this header seems more appropriate to me.  Clang 
> defines a builtin with standardized argument values for all targets; we're 
> not trying to allow targets to customize the arguments taken by this builtin, 
> at least not yet.  The sync-scope argument values are the values from this 
> enum. Because they are potentially exposed in source programs, they cannot be 
> lightly changed and re-ordered; that is, they are ABI.  There is a second 
> level of ABI, which is the set of values demanded by target runtime 
> functions.  It is IRGen's responsibility to turn the SyncScope values into 
> those values when generating a call to the runtime; that mapping does not 
> need to be exposed here in the AST.
This function is not intended to create ABI's for different targets, but to 
create ABI's for different languages. Currently only OpenCL supports atomic 
scope, but in the future there may be other languages which support atomic 
scope with a different ABI.



Comment at: include/clang/Basic/SyncScope.h:92
+/// \brief Defines the synch scope ABI for OpenCL.
+class AtomicScopeOpenCLABI : public AtomicScopeABI {
+public:

rjmccall wrote:
> Please correct me if I'm wrong, but I believe you don't get to define the 
> "ABI for OpenCL" any more than I get to define the "ABI for C".  You're 
> defining the ABI for your specific OpenCL implementation, but Clang might 
> reasonably support other implementations with their own ABIs.  So this name 
> is inappropriate.
> 
> Now, if I understand how SPIR works, SPIR does require some sort of stable 
> lowering of these atomic operations in order to ensure that the resulting 
> LLVM IR can be ingested into an arbitrary implementation.  (Ot at least that 
> was true prior to SPIR V?)  Therefore, SPIR needs to specify a lowering for 
> these atomic operations, and that probably includes ABI values for specific 
> sync-scopes.  But the appropriate name for that would be the "SPIR ABI", not 
> the "OpenCL ABI".  And, of course, you would need to be sure that you're 
> implementing the lowering that SPIR actually wants.
The ABI is not intended for a specific OpenCL implementation, but for extending 
to other languages. For example, we have a downstream C++ based language called 
HCC, which may support atomic scope with an ABI different than OpenCL atomic 
scope ABI.


https://reviews.llvm.org/D36580



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


r310865 - [OPENMP] Fix for PR33922: New ident_t flags for

2017-08-14 Thread Alexey Bataev via cfe-commits
Author: abataev
Date: Mon Aug 14 10:56:13 2017
New Revision: 310865

URL: http://llvm.org/viewvc/llvm-project?rev=310865=rev
Log:
[OPENMP] Fix for PR33922: New ident_t flags for
__kmpc_for_static_init().

OpenMP 5.0 will include OpenMP Tools interface that requires distinguishing 
different worksharing constructs.

Since the same entry point (__kmp_for_static_init(ident_t *loc,
kmp_int32 global_tid,)) is called in case static
loop/sections/distribute it is suggested using 'flags' field of the
ident_t structure to pass the type of the construct.

Modified:
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h
cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
cfe/trunk/test/OpenMP/distribute_codegen.cpp
cfe/trunk/test/OpenMP/for_codegen.cpp
cfe/trunk/test/OpenMP/parallel_for_codegen.cpp
cfe/trunk/test/OpenMP/sections_codegen.cpp

Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp?rev=310865=310864=310865=diff
==
--- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp Mon Aug 14 10:56:13 2017
@@ -19,6 +19,7 @@
 #include "clang/AST/Decl.h"
 #include "clang/AST/StmtOpenMP.h"
 #include "llvm/ADT/ArrayRef.h"
+#include "llvm/ADT/BitmaskEnum.h"
 #include "llvm/Bitcode/BitcodeReader.h"
 #include "llvm/IR/CallSite.h"
 #include "llvm/IR/DerivedTypes.h"
@@ -420,7 +421,7 @@ public:
 /// \brief Values for bit flags used in the ident_t to describe the fields.
 /// All enumeric elements are named and described in accordance with the code
 /// from http://llvm.org/svn/llvm-project/openmp/trunk/runtime/src/kmp.h
-enum OpenMPLocationFlags {
+enum OpenMPLocationFlags : unsigned {
   /// \brief Use trampoline for internal microtask.
   OMP_IDENT_IMD = 0x01,
   /// \brief Use c-style ident structure.
@@ -436,7 +437,14 @@ enum OpenMPLocationFlags {
   /// \brief Implicit barrier in 'sections' directive.
   OMP_IDENT_BARRIER_IMPL_SECTIONS = 0xC0,
   /// \brief Implicit barrier in 'single' directive.
-  OMP_IDENT_BARRIER_IMPL_SINGLE = 0x140
+  OMP_IDENT_BARRIER_IMPL_SINGLE = 0x140,
+  /// Call of __kmp_for_static_init for static loop.
+  OMP_IDENT_WORK_LOOP = 0x200,
+  /// Call of __kmp_for_static_init for sections.
+  OMP_IDENT_WORK_SECTIONS = 0x400,
+  /// Call of __kmp_for_static_init for distribute.
+  OMP_IDENT_WORK_DISTRIBUTE = 0x800,
+  LLVM_MARK_AS_BITMASK_ENUM(/*LargestValue=*/OMP_IDENT_WORK_DISTRIBUTE)
 };
 
 /// \brief Describes ident structure that describes a source location.
@@ -2956,79 +2964,85 @@ static void emitForStaticInitCall(
 CodeGenFunction , llvm::Value *UpdateLocation, llvm::Value *ThreadId,
 llvm::Constant *ForStaticInitFunction, OpenMPSchedType Schedule,
 OpenMPScheduleClauseModifier M1, OpenMPScheduleClauseModifier M2,
-unsigned IVSize, bool Ordered, Address IL, Address LB, Address UB,
-Address ST, llvm::Value *Chunk) {
+const CGOpenMPRuntime::StaticRTInput ) {
   if (!CGF.HaveInsertPoint())
- return;
+return;
 
-   assert(!Ordered);
-   assert(Schedule == OMP_sch_static || Schedule == OMP_sch_static_chunked ||
-  Schedule == OMP_sch_static_balanced_chunked ||
-  Schedule == OMP_ord_static || Schedule == OMP_ord_static_chunked ||
-  Schedule == OMP_dist_sch_static ||
-  Schedule == OMP_dist_sch_static_chunked);
-
-   // Call __kmpc_for_static_init(
-   //  ident_t *loc, kmp_int32 tid, kmp_int32 schedtype,
-   //  kmp_int32 *p_lastiter, kmp_int[32|64] *p_lower,
-   //  kmp_int[32|64] *p_upper, kmp_int[32|64] *p_stride,
-   //  kmp_int[32|64] incr, kmp_int[32|64] chunk);
-   if (Chunk == nullptr) {
- assert((Schedule == OMP_sch_static || Schedule == OMP_ord_static ||
- Schedule == OMP_dist_sch_static) &&
-"expected static non-chunked schedule");
- // If the Chunk was not specified in the clause - use default value 1.
-   Chunk = CGF.Builder.getIntN(IVSize, 1);
-   } else {
- assert((Schedule == OMP_sch_static_chunked ||
- Schedule == OMP_sch_static_balanced_chunked ||
- Schedule == OMP_ord_static_chunked ||
- Schedule == OMP_dist_sch_static_chunked) &&
-"expected static chunked schedule");
-   }
-   llvm::Value *Args[] = {
-   UpdateLocation, ThreadId, CGF.Builder.getInt32(addMonoNonMonoModifier(
- Schedule, M1, M2)), // Schedule type
-   IL.getPointer(),  // 
-   LB.getPointer(),  // 
-   UB.getPointer(),  // 
-   ST.getPointer(),  // 
-   CGF.Builder.getIntN(IVSize, 1),   // Incr
-   Chunk // Chunk
-   };
-   

[PATCH] D36572: Implemented P0409R2 - Allow lambda capture [=, this]

2017-08-14 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: lib/Sema/SemaLambda.cpp:959
+ ? diag::ext_equals_this_lambda_capture_cxx2a
+ : diag::warn_cxx1z_compat_equals_this_lambda_capture);
 

hamzasood wrote:
> faisalv wrote:
> > Shouldn't we try and hit the 'continue' (that u deleted) if warnings (and 
> > extension warnings) are turned into errors? 
> That's an interesting scenario which admittedly I hadn't considered.
> 
> I based this implementation on the [[ 
> https://github.com/llvm-mirror/clang/blob/7602b13a8e8b5656afd6327d112b76b39f836e5b/lib/Sema/SemaLambda.cpp#L935
>  | '*this' capture handling ]] from the same loop. When a '*this' capture is 
> seen pre-C++1z, an extension warning is emitted and then the capture is 
> processed as normal (i.e. without consideration of that warning potentially 
> becoming an error).
> 
> I also looked at other places where extension warnings are emitted and I 
> couldn't find any special handling for warnings becoming errors.
Yeah, I doubt there's a single place in the compiler where we stop processing 
code when warnings are turned into errors.



Comment at: test/FixIt/fixit-cxx0x.cpp:57
   (void)[&, , ]{}; // expected-error 2{{'&' cannot precede a capture when 
the capture default is '&'}}
-  (void)[=, this]{ this->g(5); }; // expected-error{{'this' cannot be 
explicitly captured}}
   (void)[i, i]{ }; // expected-error{{'i' can appear only once in a capture 
list}}

rjmccall wrote:
> hamzasood wrote:
> > rjmccall wrote:
> > > hamzasood wrote:
> > > > rjmccall wrote:
> > > > > hamzasood wrote:
> > > > > > rjmccall wrote:
> > > > > > > Shouldn't you only be accepting this in C++2a mode?
> > > > > > I'm not sure what the system is with allowing future language 
> > > > > > features as extensions, but I noticed that [*this] capture is 
> > > > > > allowed as an extension pre-C++17 so I figured it would make sense 
> > > > > > for [=, this] to also be allowed as an extension (since the 
> > > > > > proposal mentions how it's meant to increase code clarify in the 
> > > > > > presence of [*this]).
> > > > > Surely there should at least be an on-by-default extension warning?  
> > > > > The behavior we're using sounds a lot more like we're treating this 
> > > > > as a bug-fix in the standard than a new feature.  Richard, can you 
> > > > > weigh in here?
> > > > The extension warning for this (ext_equals_this_lambda_capture_cxx2a) 
> > > > is on by default.
> > > Why did the diagnostic disappear from this file, then?
> > That file is for FixIt hints, which I don't think make much sense for an 
> > extension warning (and I couldn't find any other extension warnings that 
> > offer FixIt hints)
> Sure, it's reasonable for this specific test to not test the warning.  
> However, since I don't see anything in this test that actually turns off the 
> warning, and since you have not in fact added any tests that verify that the 
> warning is ever turned on, I suspect that it is actually not being emitted.
I'm sorry, I see that you've added an explicit test for the warning, but I 
still don't understand why the warning is not emitted in this file.  -verify 
normally verifies all diagnostics, and this file is tested with -std=c++11.  Is 
there some special behavior of -fixit that disables warnings, or ignores them 
in -verify mode?


https://reviews.llvm.org/D36572



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


[PATCH] D35368: [clang-tidy] Add a close-on-exec check on inotify_init1() in Android module.

2017-08-14 Thread Chih-Hung Hsieh via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL310863: [clang-tidy] Add a close-on-exec check on 
inotify_init1() in Android module. (authored by chh).

Changed prior to commit:
  https://reviews.llvm.org/D35368?vs=110750=111033#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D35368

Files:
  clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp
  clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt
  clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInit1Check.cpp
  clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInit1Check.h
  clang-tools-extra/trunk/docs/ReleaseNotes.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/android-cloexec-inotify-init1.rst
  clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst
  clang-tools-extra/trunk/test/clang-tidy/android-cloexec-inotify-init1.cpp

Index: clang-tools-extra/trunk/docs/ReleaseNotes.rst
===
--- clang-tools-extra/trunk/docs/ReleaseNotes.rst
+++ clang-tools-extra/trunk/docs/ReleaseNotes.rst
@@ -98,6 +98,12 @@
   Ensures that all exception will be instances of ``std::exception`` and classes 
   that are derived from it.
 
+- New `android-cloexec-inotify-init1
+  `_ check
+
+  Checks if the required file flag ``IN_CLOEXEC`` is present in the argument of
+  ``inotify_init1()``.
+
 - New `readability-static-accessed-through-instance
   `_ check
 
Index: clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst
@@ -8,6 +8,7 @@
android-cloexec-dup
android-cloexec-fopen
android-cloexec-inotify-init
+   android-cloexec-inotify-init1
android-cloexec-memfd-create
android-cloexec-open
android-cloexec-socket
Index: clang-tools-extra/trunk/docs/clang-tidy/checks/android-cloexec-inotify-init1.rst
===
--- clang-tools-extra/trunk/docs/clang-tidy/checks/android-cloexec-inotify-init1.rst
+++ clang-tools-extra/trunk/docs/clang-tidy/checks/android-cloexec-inotify-init1.rst
@@ -0,0 +1,18 @@
+.. title:: clang-tidy - android-cloexec-inotify-init1
+
+android-cloexec-inotify-init1
+=
+
+``inotify_init1()`` should include ``IN_CLOEXEC`` in its type argument to avoid the
+file descriptor leakage. Without this flag, an opened sensitive file would
+remain open across a fork+exec to a lower-privileged SELinux domain.
+
+Examples:
+
+.. code-block:: c++
+
+  inotify_init1(IN_NONBLOCK);
+
+  // becomes
+
+  inotify_init1(IN_NONBLOCK | IN_CLOEXEC);
Index: clang-tools-extra/trunk/test/clang-tidy/android-cloexec-inotify-init1.cpp
===
--- clang-tools-extra/trunk/test/clang-tidy/android-cloexec-inotify-init1.cpp
+++ clang-tools-extra/trunk/test/clang-tidy/android-cloexec-inotify-init1.cpp
@@ -0,0 +1,64 @@
+// RUN: %check_clang_tidy %s android-cloexec-inotify-init1 %t
+
+#define IN_NONBLOCK 1
+#define __O_CLOEXEC 3
+#define IN_CLOEXEC __O_CLOEXEC
+#define TEMP_FAILURE_RETRY(exp) \
+  ({\
+int _rc;\
+do {\
+  _rc = (exp);  \
+} while (_rc == -1);\
+  })
+
+extern "C" int inotify_init1(int flags);
+
+void a() {
+  inotify_init1(IN_NONBLOCK);
+  // CHECK-MESSAGES: :[[@LINE-1]]:28: warning: 'inotify_init1' should use IN_CLOEXEC where possible [android-cloexec-inotify-init1]
+  // CHECK-FIXES: inotify_init1(IN_NONBLOCK | IN_CLOEXEC);
+  TEMP_FAILURE_RETRY(inotify_init1(IN_NONBLOCK));
+  // CHECK-MESSAGES: :[[@LINE-1]]:47: warning: 'inotify_init1'
+  // CHECK-FIXES: TEMP_FAILURE_RETRY(inotify_init1(IN_NONBLOCK | IN_CLOEXEC));
+}
+
+void f() {
+  inotify_init1(0);
+  // CHECK-MESSAGES: :[[@LINE-1]]:18: warning: 'inotify_init1'
+  // CHECK-FIXES: inotify_init1(IN_CLOEXEC);
+  TEMP_FAILURE_RETRY(inotify_init1(0));
+  // CHECK-MESSAGES: :[[@LINE-1]]:37: warning: 'inotify_init1'
+  // CHECK-FIXES: TEMP_FAILURE_RETRY(inotify_init1(IN_CLOEXEC));
+
+  int flag = 1;
+  inotify_init1(flag);
+  TEMP_FAILURE_RETRY(inotify_init1(flag));
+}
+
+namespace i {
+int inotify_init1(int flags);
+
+void d() {
+  inotify_init1(IN_NONBLOCK);
+  TEMP_FAILURE_RETRY(inotify_init1(IN_NONBLOCK));
+}
+
+} // namespace i
+
+void e() {
+  inotify_init1(IN_CLOEXEC);
+  TEMP_FAILURE_RETRY(inotify_init1(IN_CLOEXEC));
+  inotify_init1(IN_NONBLOCK | IN_CLOEXEC);
+  TEMP_FAILURE_RETRY(inotify_init1(IN_NONBLOCK | IN_CLOEXEC));
+}
+
+class G {
+public:
+  int inotify_init1(int flags);
+  void d() {
+inotify_init1(IN_CLOEXEC);
+

[clang-tools-extra] r310863 - [clang-tidy] Add a close-on-exec check on inotify_init1() in Android module.

2017-08-14 Thread Chih-Hung Hsieh via cfe-commits
Author: chh
Date: Mon Aug 14 10:45:48 2017
New Revision: 310863

URL: http://llvm.org/viewvc/llvm-project?rev=310863=rev
Log:
[clang-tidy] Add a close-on-exec check on inotify_init1() in Android module.

Summary:
inotify_init1() is better to set IN_CLOEXEC flag to avoid file descriptor 
leakage.

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


Added:
clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInit1Check.cpp
clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInit1Check.h

clang-tools-extra/trunk/docs/clang-tidy/checks/android-cloexec-inotify-init1.rst
clang-tools-extra/trunk/test/clang-tidy/android-cloexec-inotify-init1.cpp
Modified:
clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp
clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt
clang-tools-extra/trunk/docs/ReleaseNotes.rst
clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst

Modified: clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp?rev=310863=310862=310863=diff
==
--- clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp Mon Aug 14 
10:45:48 2017
@@ -13,6 +13,7 @@
 #include "CloexecCreatCheck.h"
 #include "CloexecDupCheck.h"
 #include "CloexecFopenCheck.h"
+#include "CloexecInotifyInit1Check.h"
 #include "CloexecInotifyInitCheck.h"
 #include "CloexecMemfdCreateCheck.h"
 #include "CloexecOpenCheck.h"
@@ -33,6 +34,8 @@ public:
 CheckFactories.registerCheck("android-cloexec-fopen");
 CheckFactories.registerCheck(
 "android-cloexec-inotify-init");
+CheckFactories.registerCheck(
+"android-cloexec-inotify-init1");
 CheckFactories.registerCheck(
 "android-cloexec-memfd-create");
 CheckFactories.registerCheck("android-cloexec-open");

Modified: clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt?rev=310863=310862=310863=diff
==
--- clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt Mon Aug 14 
10:45:48 2017
@@ -6,6 +6,7 @@ add_clang_library(clangTidyAndroidModule
   CloexecCreatCheck.cpp
   CloexecDupCheck.cpp
   CloexecFopenCheck.cpp
+  CloexecInotifyInit1Check.cpp
   CloexecInotifyInitCheck.cpp
   CloexecMemfdCreateCheck.cpp
   CloexecOpenCheck.cpp

Added: clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInit1Check.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInit1Check.cpp?rev=310863=auto
==
--- clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInit1Check.cpp 
(added)
+++ clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInit1Check.cpp Mon 
Aug 14 10:45:48 2017
@@ -0,0 +1,33 @@
+//===--- CloexecInotifyInit1Check.cpp - 
clang-tidy-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "CloexecInotifyInit1Check.h"
+#include "../utils/ASTUtils.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+namespace android {
+
+void CloexecInotifyInit1Check::registerMatchers(MatchFinder *Finder) {
+  registerMatchersImpl(
+  Finder, functionDecl(returns(isInteger()), hasName("inotify_init1"),
+   hasParameter(0, hasType(isInteger();
+}
+
+void CloexecInotifyInit1Check::check(const MatchFinder::MatchResult ) {
+  insertMacroFlag(Result, /*MarcoFlag=*/"IN_CLOEXEC", /*ArgPos=*/0);
+}
+
+} // namespace android
+} // namespace tidy
+} // namespace clang

Added: clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInit1Check.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInit1Check.h?rev=310863=auto
==
--- clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInit1Check.h 
(added)
+++ clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInit1Check.h Mon 
Aug 14 10:45:48 2017
@@ -0,0 +1,35 @@
+//===--- CloexecInotifyInit1Check.h - clang-tidy-*- C++ 
-*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. 

[PATCH] D36580: [OpenCL] Support variable memory scope in atomic builtins

2017-08-14 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: include/clang/Basic/SyncScope.h:59
+return "opencl_subgroup";
+  }
+}

yaxunl wrote:
> rjmccall wrote:
> > t-tye wrote:
> > > Should there be a default/assert/static_assert to allow SyncScope enum to 
> > > grow due to other languages?
> > There will already be a warning from -Wswitch about this, which should be 
> > sufficient.
> > 
> > But we do often add llvm_unreachable after switches like this.
> I tried adding
> 
> ```
> default:
> llvm_unreachable("Invalid sync scope");
> ```
> 
> However, it results in error:
> 
> ```
>  error: default label in switch which covers all enumeration values 
> [-Werror,-Wcovered-switch-default]
> ```
> I guess I'd better leave it as it is since we already have -Wswitch.
Yeah, the idiom is to put the llvm_unreachable after the switch, not in a 
default.  Check out the uses in Type.cpp for examples: some of them are in 
specific cases, saying those cases are illlegal due to some precondition, but 
most of them are just after the switch saying that the switch is covered.  (The 
semantics of switch in C are that switch values with no corresponding case just 
skip the whole switch unless there's a default.)



Comment at: include/clang/Basic/SyncScope.h:89
+  static std::unique_ptr create(LangOptions );
+};
+

The previous design of this header seems more appropriate to me.  Clang defines 
a builtin with standardized argument values for all targets; we're not trying 
to allow targets to customize the arguments taken by this builtin, at least not 
yet.  The sync-scope argument values are the values from this enum. Because 
they are potentially exposed in source programs, they cannot be lightly changed 
and re-ordered; that is, they are ABI.  There is a second level of ABI, which 
is the set of values demanded by target runtime functions.  It is IRGen's 
responsibility to turn the SyncScope values into those values when generating a 
call to the runtime; that mapping does not need to be exposed here in the AST.



Comment at: include/clang/Basic/SyncScope.h:92
+/// \brief Defines the synch scope ABI for OpenCL.
+class AtomicScopeOpenCLABI : public AtomicScopeABI {
+public:

Please correct me if I'm wrong, but I believe you don't get to define the "ABI 
for OpenCL" any more than I get to define the "ABI for C".  You're defining the 
ABI for your specific OpenCL implementation, but Clang might reasonably support 
other implementations with their own ABIs.  So this name is inappropriate.

Now, if I understand how SPIR works, SPIR does require some sort of stable 
lowering of these atomic operations in order to ensure that the resulting LLVM 
IR can be ingested into an arbitrary implementation.  (Ot at least that was 
true prior to SPIR V?)  Therefore, SPIR needs to specify a lowering for these 
atomic operations, and that probably includes ABI values for specific 
sync-scopes.  But the appropriate name for that would be the "SPIR ABI", not 
the "OpenCL ABI".  And, of course, you would need to be sure that you're 
implementing the lowering that SPIR actually wants.


https://reviews.llvm.org/D36580



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


Re: r310401 - PR19668, PR23034: Fix handling of move constructors and deleted copy

2017-08-14 Thread Vassil Vassilev via cfe-commits

Hi,

  Ok that's a progress. Could you figure out which optimizer pass 
breaks it. I bet it is the inliner. I assume we could run a reducer on 
the ll file.


Cheers, Vassil
On 14/08/17 17:21, Diana Picus wrote:

Hi,

I didn't manage to reproduce this at -O0. Yes, I think the version in
1.8.0, slightly modified (see
llvm/utils/unittest/googletest/README.LLVM)

On 14 August 2017 at 17:06, Vassil Vassilev  wrote:

On 14/08/17 15:59, Diana Picus wrote:

No, the buildbots don't build with -O0 (at least not the ones that broke).

The command line for that particular object is:
build/./bin/clang -fPIC -fvisibility-inlines-hidden -Werror=date-time
-std=c++11 -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wmissing-field-initializers -pedantic -Wno-long-long
-Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
-Wstring-conversion -fcolor-diagnostics -ffunction-sections
-fdata-sections -Wall -std=c++11 -Wno-unused-parameter
-Wno-unknown-warning-option -Wno-covered-switch-default
-DGTEST_NO_LLVM_RAW_OSTREAM=1 -DGTEST_HAS_RTTI=0
-I$LLVM_SRC/llvm/utils/unittest/googletest/include
-I/home/diana.picus/linaro-scripts/bisect/llvm/utils/unittest/googletest
-I$LLVM_SRC/llvm/projects/compiler-rt/include
-I$LLVM_SRC/llvm/projects/compiler-rt/lib
-I$LLVM_SRC/llvm/projects/compiler-rt/lib/asan
-I$LLVM_SRC/llvm/projects/compiler-rt/lib/sanitizer_common/tests
-fno-rtti -O2 -Wno-format -Werror=sign-compare -Wno-non-virtual-dtor
-Wno-variadic-macros -gline-tables-only -DASAN_HAS_BLACKLIST=1
-DASAN_HAS_EXCEPTIONS=1 -DASAN_UAR=0 -fsanitize=address

-fsanitize-blacklist=$LLVM_SRC/llvm/projects/compiler-rt/lib/asan/tests/asan_test.ignore
-mllvm -asan-instrumentation-with-call-threshold=0 -march=armv7-a
-mfloat-abi=hard -c -o
ASAN_INST_TEST_OBJECTS.asan_test.cc.armhf-with-calls.o
$LLVM_SRC/compiler-rt/lib/asan/tests/asan_test.cc

   Could you try to reproduce the issue with O0? This would rule out the
optimizer. Could you resend the O0 ll file, maybe I could find something
out. IIUC, the gtest version is 1.8.0?


Why would it contain gtest.cc? It seems to contain gtest.h and a bunch
of other internal gtest headers...


On 14 August 2017 at 16:51, Vassil Vassilev 
wrote:

On 14/08/17 15:08, Vassil Vassilev wrote:

On 14/08/17 13:04, Diana Picus wrote:

See attached.

Thanks! It looks like asan_test.i doesn't have gtest.cc which appears in
the stack trace. Am I missing something?

Could you paste the compiler invocation. Are we building with -O0 (I
see
quite a lot of things inline). Could it be an optimizer problem?


On 14 August 2017 at 13:30, Vassil Vassilev 
wrote:

On 14/08/17 11:27, Diana Picus wrote:

Hi,

Strangely enough, it turns out that if I run
Asan-armhf-with-calls-Noinst-Test on the command line it fails,
although it doesn't fail when run with lit. I've attached the stack
trace from gdb. It looks like some trouble passing down va_arg
parameters, but I haven't looked into too much details. The segfault
happens when we try to do a   ldrb   r3, [r0, r1], with r1 set to 0
by
the current function and r0 passed down from the caller. I'm not sure
if this is the exact same problem as the other tests, but feel free
to
have a look at that code.

Meanwhile, I've removed some clutter from Asan-armhf-with-calls-Test
(which is the original failure that we were seeing) and left only one
failing test that seemed small enough. I'll try to look at the
disassembly before/after the patch and maybe even run valgrind on it
(running it on the original binary naturally takes forever).

Let me know if there's anything else I could try. I can also send you
disassembly or even LLVM IR for the Asan-armhf-with-calls-Noinst-Test
if you think it helps.

 disassembly and LLVM will greatly help as well.


Cheers,
Diana

On 11 August 2017 at 15:34, Diana Picus 
wrote:

Well, these are ASAN tests, I'm not sure how that would interact
with
Valgrind.
Anyway, I'll try to reproduce the environment, I'm guessing it would
be best to catch this in gdb so I can actually see what's going on.

On 11 August 2017 at 15:21, Vassil Vassilev 
wrote:

That's really strange. It looks like some random behavior. Did you
run
some memory checker like valgrind?

Do the environment provided by the test runner and yours match?

Sent from my phone. Please excuse my brevity.


On 11 Aug 2017, at 15:58, Diana Picus 
wrote:

Hi again,

I finally got the debug build, but unfortunately the stack traces
that
the tests print look the same. My suspicion is that this is
because
the addresses printed by the tests are funny (i.e. odd numbers
instead
of divisible by 4). I tried to follow those addresses in an
objdump
of
the executable, but I didn't have much success since most of them
weren't really pointing to call instructions.

When I try to run the tests manually in the shell or in gdb, they
pass.

I'm not sure 

Re: r310804 - Replace remaining user-visible mentions of C++1z with C++17.

2017-08-14 Thread Hans Wennborg via cfe-commits
r310862. Thanks!

On Sun, Aug 13, 2017 at 3:41 PM, Richard Smith  wrote:
> Since we took the -std=c++17 change for Clang 5, we should take this one
> too.
>
> On 13 August 2017 at 15:26, Richard Smith via cfe-commits
>  wrote:
>>
>> Author: rsmith
>> Date: Sun Aug 13 15:26:53 2017
>> New Revision: 310804
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=310804=rev
>> Log:
>> Replace remaining user-visible mentions of C++1z with C++17.
>>
>> Modified:
>> cfe/trunk/include/clang/Basic/DiagnosticGroups.td
>> cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td
>> cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
>> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>> cfe/trunk/test/CXX/dcl.dcl/dcl.attr/dcl.attr.nodiscard/p2.cpp
>> cfe/trunk/test/CXX/dcl.dcl/dcl.attr/dcl.attr.unused/p3.cpp
>> cfe/trunk/test/CXX/drs/dr0xx.cpp
>> cfe/trunk/test/CXX/drs/dr13xx.cpp
>> cfe/trunk/test/CXX/drs/dr1xx.cpp
>> cfe/trunk/test/CXX/drs/dr2xx.cpp
>> cfe/trunk/test/CXX/drs/dr4xx.cpp
>> cfe/trunk/test/CXX/drs/dr5xx.cpp
>> cfe/trunk/test/CXX/stmt.stmt/stmt.iter/stmt.ranged/p1.cpp
>> cfe/trunk/test/FixIt/fixit.cpp
>> cfe/trunk/test/Lexer/hexfloat.cpp
>> cfe/trunk/test/Parser/cxx0x-attributes.cpp
>> cfe/trunk/test/Parser/cxx1z-constexpr-lambdas.cpp
>> cfe/trunk/test/Parser/cxx1z-nested-namespace-definition.cpp
>> cfe/trunk/test/SemaCXX/cxx0x-compat.cpp
>> cfe/trunk/test/SemaCXX/deprecated.cpp
>> cfe/trunk/test/SemaCXX/inline.cpp
>> cfe/trunk/test/SemaCXX/static-assert.cpp
>> cfe/trunk/test/SemaCXX/warn-c++1z-extensions.cpp
>> cfe/trunk/test/SemaTemplate/temp_arg_nontype_cxx11.cpp
>>
>> Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticGroups.td?rev=310804=310803=310804=diff
>>
>> ==
>> --- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
>> +++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Sun Aug 13 15:26:53
>> 2017
>> @@ -156,9 +156,10 @@ def FormatZeroLength : DiagGroup<"format
>>
>>  def InvalidIOSDeploymentTarget :
>> DiagGroup<"invalid-ios-deployment-target">;
>>
>> -def CXX1zCompatMangling : DiagGroup<"c++1z-compat-mangling">;
>> +def CXX17CompatMangling : DiagGroup<"c++17-compat-mangling">;
>> +def : DiagGroup<"c++1z-compat-mangling", [CXX17CompatMangling]>;
>>  // Name of this warning in GCC.
>> -def NoexceptType : DiagGroup<"noexcept-type", [CXX1zCompatMangling]>;
>> +def NoexceptType : DiagGroup<"noexcept-type", [CXX17CompatMangling]>;
>>
>>  // Warnings for C++1y code which is not compatible with prior C++
>> standards.
>>  def CXXPre14Compat : DiagGroup<"c++98-c++11-compat">;
>> @@ -220,9 +221,10 @@ def CXX14Compat : DiagGroup<"c++14-compa
>>  def CXX14CompatPedantic : DiagGroup<"c++14-compat-pedantic",
>>  [CXXPre1zCompatPedantic]>;
>>
>> -def CXX1zCompat : DiagGroup<"c++1z-compat", [DeprecatedRegister,
>> +def CXX17Compat : DiagGroup<"c++17-compat", [DeprecatedRegister,
>>   DeprecatedIncrementBool,
>> - CXX1zCompatMangling]>;
>> + CXX17CompatMangling]>;
>> +def : DiagGroup<"c++1z-compat", [CXX17Compat]>;
>>
>>  def CXX2aCompat : DiagGroup<"c++2a-compat">;
>>
>> @@ -780,10 +782,11 @@ def CXX14 : DiagGroup<"c++14-extensions"
>>
>>  // A warning group for warnings about using C++1z features as extensions
>> in
>>  // earlier C++ versions.
>> -def CXX1z : DiagGroup<"c++1z-extensions">;
>> +def CXX17 : DiagGroup<"c++17-extensions">;
>>
>>  def : DiagGroup<"c++0x-extensions", [CXX11]>;
>>  def : DiagGroup<"c++1y-extensions", [CXX14]>;
>> +def : DiagGroup<"c++1z-extensions", [CXX17]>;
>>
>>  def DelegatingCtorCycles :
>>DiagGroup<"delegating-ctor-cycles">;
>>
>> Modified: cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td?rev=310804=310803=310804=diff
>>
>> ==
>> --- cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td (original)
>> +++ cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td Sun Aug 13
>> 15:26:53 2017
>> @@ -181,10 +181,10 @@ def err_hex_constant_requires : Error<
>>  def ext_hex_constant_invalid : Extension<
>>"hexadecimal floating constants are a C99 feature">, InGroup;
>>  def ext_hex_literal_invalid : Extension<
>> -  "hexadecimal floating literals are a C++1z feature">, InGroup;
>> +  "hexadecimal floating literals are a C++17 feature">, InGroup;
>>  def warn_cxx1z_hex_literal : Warning<
>>"hexadecimal floating literals are incompatible with "
>> -  "C++ standards before C++1z">,
>> +  "C++ standards before C++17">,

[clang-tools-extra] r310861 - [clang-tidy] Add a close-on-exec check on inotify_init() in Android module.

2017-08-14 Thread Chih-Hung Hsieh via cfe-commits
Author: chh
Date: Mon Aug 14 10:25:41 2017
New Revision: 310861

URL: http://llvm.org/viewvc/llvm-project?rev=310861=rev
Log:
[clang-tidy] Add a close-on-exec check on inotify_init() in Android module.

Summary:
inotify_init() is better to be replaced by inotify_init1() with IN_CLOEXEC flag 
to avoid file descriptor leakage.

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


Added:
clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInitCheck.cpp
clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInitCheck.h

clang-tools-extra/trunk/docs/clang-tidy/checks/android-cloexec-inotify-init.rst
clang-tools-extra/trunk/test/clang-tidy/android-cloexec-inotify-init.cpp
Modified:
clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp
clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt
clang-tools-extra/trunk/docs/ReleaseNotes.rst
clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst

Modified: clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp?rev=310861=310860=310861=diff
==
--- clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp Mon Aug 14 
10:25:41 2017
@@ -13,6 +13,7 @@
 #include "CloexecCreatCheck.h"
 #include "CloexecDupCheck.h"
 #include "CloexecFopenCheck.h"
+#include "CloexecInotifyInitCheck.h"
 #include "CloexecMemfdCreateCheck.h"
 #include "CloexecOpenCheck.h"
 #include "CloexecSocketCheck.h"
@@ -30,6 +31,8 @@ public:
 CheckFactories.registerCheck("android-cloexec-creat");
 CheckFactories.registerCheck("android-cloexec-dup");
 CheckFactories.registerCheck("android-cloexec-fopen");
+CheckFactories.registerCheck(
+"android-cloexec-inotify-init");
 CheckFactories.registerCheck(
 "android-cloexec-memfd-create");
 CheckFactories.registerCheck("android-cloexec-open");

Modified: clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt?rev=310861=310860=310861=diff
==
--- clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt Mon Aug 14 
10:25:41 2017
@@ -6,6 +6,7 @@ add_clang_library(clangTidyAndroidModule
   CloexecCreatCheck.cpp
   CloexecDupCheck.cpp
   CloexecFopenCheck.cpp
+  CloexecInotifyInitCheck.cpp
   CloexecMemfdCreateCheck.cpp
   CloexecOpenCheck.cpp
   CloexecSocketCheck.cpp

Added: clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInitCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInitCheck.cpp?rev=310861=auto
==
--- clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInitCheck.cpp 
(added)
+++ clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInitCheck.cpp Mon 
Aug 14 10:25:41 2017
@@ -0,0 +1,34 @@
+//===--- CloexecInotifyInitCheck.cpp - 
clang-tidy--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "CloexecInotifyInitCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+namespace android {
+
+void CloexecInotifyInitCheck::registerMatchers(MatchFinder *Finder) {
+  registerMatchersImpl(
+  Finder, functionDecl(returns(isInteger()), hasName("inotify_init")));
+}
+
+void CloexecInotifyInitCheck::check(const MatchFinder::MatchResult ) {
+  replaceFunc(Result, /*WarningMsg=*/
+  "prefer inotify_init() to inotify_init1() "
+  "because inotify_init1() allows IN_CLOEXEC",
+  /*FixMsg=*/"inotify_init1(IN_CLOEXEC)");
+}
+
+} // namespace android
+} // namespace tidy
+} // namespace clang

Added: clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInitCheck.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInitCheck.h?rev=310861=auto
==
--- clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInitCheck.h (added)
+++ clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInitCheck.h Mon 
Aug 14 10:25:41 2017
@@ -0,0 +1,35 @@
+//===--- CloexecInotifyInitCheck.h - clang-tidy--*- C++ 
-*-===//
+//
+// The LLVM Compiler Infrastructure
+//

[PATCH] D35370: [clang-tidy] Add a close-on-exec check on inotify_init() in Android module.

2017-08-14 Thread Chih-Hung Hsieh via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL310861: [clang-tidy] Add a close-on-exec check on 
inotify_init() in Android module. (authored by chh).

Changed prior to commit:
  https://reviews.llvm.org/D35370?vs=110749=111028#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D35370

Files:
  clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp
  clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt
  clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInitCheck.cpp
  clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInitCheck.h
  clang-tools-extra/trunk/docs/ReleaseNotes.rst
  
clang-tools-extra/trunk/docs/clang-tidy/checks/android-cloexec-inotify-init.rst
  clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst
  clang-tools-extra/trunk/test/clang-tidy/android-cloexec-inotify-init.cpp

Index: clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp
===
--- clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp
+++ clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp
@@ -13,6 +13,7 @@
 #include "CloexecCreatCheck.h"
 #include "CloexecDupCheck.h"
 #include "CloexecFopenCheck.h"
+#include "CloexecInotifyInitCheck.h"
 #include "CloexecMemfdCreateCheck.h"
 #include "CloexecOpenCheck.h"
 #include "CloexecSocketCheck.h"
@@ -30,6 +31,8 @@
 CheckFactories.registerCheck("android-cloexec-creat");
 CheckFactories.registerCheck("android-cloexec-dup");
 CheckFactories.registerCheck("android-cloexec-fopen");
+CheckFactories.registerCheck(
+"android-cloexec-inotify-init");
 CheckFactories.registerCheck(
 "android-cloexec-memfd-create");
 CheckFactories.registerCheck("android-cloexec-open");
Index: clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInitCheck.h
===
--- clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInitCheck.h
+++ clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInitCheck.h
@@ -0,0 +1,35 @@
+//===--- CloexecInotifyInitCheck.h - clang-tidy--*- C++ -*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_ANDROID_CLOEXEC_INOTIFY_INIT_H
+#define LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_ANDROID_CLOEXEC_INOTIFY_INIT_H
+
+#include "CloexecCheck.h"
+
+namespace clang {
+namespace tidy {
+namespace android {
+
+/// inotify_init() is better to be replaced by inotify_init1().
+///
+/// For the user-facing documentation see:
+/// http://clang.llvm.org/extra/clang-tidy/checks/android-cloexec-inotify-init.html
+class CloexecInotifyInitCheck : public CloexecCheck {
+public:
+  CloexecInotifyInitCheck(StringRef Name, ClangTidyContext *Context)
+  : CloexecCheck(Name, Context) {}
+  void registerMatchers(ast_matchers::MatchFinder *Finder) override;
+  void check(const ast_matchers::MatchFinder::MatchResult ) override;
+};
+
+} // namespace android
+} // namespace tidy
+} // namespace clang
+
+#endif // LLVM_CLANG_TOOLS_EXTRA_CLANG_TIDY_ANDROID_CLOEXEC_INOTIFY_INIT_H
Index: clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInitCheck.cpp
===
--- clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInitCheck.cpp
+++ clang-tools-extra/trunk/clang-tidy/android/CloexecInotifyInitCheck.cpp
@@ -0,0 +1,34 @@
+//===--- CloexecInotifyInitCheck.cpp - clang-tidy--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "CloexecInotifyInitCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+namespace android {
+
+void CloexecInotifyInitCheck::registerMatchers(MatchFinder *Finder) {
+  registerMatchersImpl(
+  Finder, functionDecl(returns(isInteger()), hasName("inotify_init")));
+}
+
+void CloexecInotifyInitCheck::check(const MatchFinder::MatchResult ) {
+  replaceFunc(Result, /*WarningMsg=*/
+  "prefer inotify_init() to inotify_init1() "
+  "because inotify_init1() allows IN_CLOEXEC",
+  /*FixMsg=*/"inotify_init1(IN_CLOEXEC)");
+}
+
+} // namespace android
+} // namespace tidy
+} // namespace clang
Index: clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt
===
--- clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt

[PATCH] D36423: [libc++] Introsort based sorting function

2017-08-14 Thread DIVYA SHANMUGHAN via Phabricator via cfe-commits
DIVYA added a comment.

Added benchmark from Aditya's repo into the libcxx benchmark code base


https://reviews.llvm.org/D36423



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


[PATCH] D36423: [libc++] Introsort based sorting function

2017-08-14 Thread DIVYA SHANMUGHAN via Phabricator via cfe-commits
DIVYA updated this revision to Diff 111027.

https://reviews.llvm.org/D36423

Files:
  benchmarks/algorithms.bench.cpp
  include/algorithm
  include/rng_utils.h
  include/test_configs.h
  include/test_utils.h

Index: include/test_utils.h
===
--- /dev/null
+++ include/test_utils.h
@@ -0,0 +1,270 @@
+#ifndef TEST_UTILS_H
+#define TEST_UTILS_H
+
+#include "rng_utils.h"
+#include
+#include
+
+// TODO: Add more aggregates.
+struct aggregate {
+  int first;
+  int second;
+  int third;
+  int fourth;
+  aggregate() : first(0), second(0), third(0), fourth(0)
+  {}
+  // This is a hacky constructor for ::find on associative containers to work.
+  aggregate(int i)
+: first(i), second(i), third(i), fourth(i)
+  {}
+  aggregate(int i, int j, int k, int l)
+: first(i), second(j), third(k), fourth(l)
+  {}
+
+  aggregate& operator++() {
+++first;
+++second;
+++third;
+++fourth;
+return *this;
+  }
+  aggregate operator++(int) {
+aggregate N(*this);
+++(*this);
+return N;
+  }
+
+  bool operator<(const aggregate& i) const {
+return first < i.first;
+  }
+
+  bool operator>(const aggregate& i) const {
+return i < *this;
+  }
+
+  bool operator==(const aggregate& i) const {
+return first == i.first;
+  }
+
+  bool operator!=(const aggregate& i) const {
+return !(*this == i);
+  }
+};
+
+// Hasher for aggregate data type.
+namespace std {
+  template <>
+  struct hash
+  {
+std::size_t operator()(const aggregate& k) const
+{
+  using std::hash;
+  // Hash and combine using bit-shift.
+  return ((hash()(k.first)
+   ^ (hash()(k.second) << 1)) >> 1)
+   ^ (hash()(k.third) << 1)
+   ^ (hash()(k.fourth) << 1);
+}
+  };
+}
+
+template
+struct remove_const { typedef T type; };
+
+// value_type of a std::map is std::pair
+template
+struct remove_const { typedef std::pair type; };
+
+template
+T get_rand(random_device , int max) {
+  return r.get_rand(T(0), T(max));
+}
+
+template<>
+std::pair get_rand>(random_device , int max) {
+  return std::make_pair(r.get_rand(0, max), r.get_rand(0, max));
+}
+
+template<>
+aggregate get_rand(random_device , int max) {
+  return aggregate(r.get_rand(0, max));
+}
+
+template<>
+std::pair
+get_rand>(random_device , int max) {
+  return std::make_pair(r.get_rand(0, max), r.get_rand(0, max));
+}
+
+template
+T increment(T ) {
+  return ++i;
+}
+
+// value_type of a std::map is std::pair
+template<>
+std::pair increment>(std::pair ) {
+  return std::make_pair(++i.first, i.second);
+}
+
+template<>
+std::pair
+increment>(std::pair ) {
+  return std::make_pair(++i.first, i.second);
+}
+
+template
+T init() {
+  return T(0);
+}
+
+template<>
+std::pair init>() {
+  return std::make_pair(0, 0);
+}
+
+template<>
+std::pair init>() {
+  return std::make_pair(0, 0);
+}
+
+template  class Container, class value_type>
+void fill_random(Container ,
+int max = RAND_MAX) {
+  random_device r;
+  for (auto  : v)
+e = get_rand(r, max);
+}
+
+template 
+void fill_random(T begin, T end, int max = RAND_MAX) {
+  typedef typename std::iterator_traits::value_type value_type;
+  random_device r;
+  for (auto it = begin; it != end; ++it)
+*it = get_rand(r, max);
+}
+
+// It can work with char* or std::string.
+template
+void fill_random_chars(T begin, T end, bool upper) {
+  char max = upper ? 'Z' : 'z';
+  char min = upper ? 'A' : 'a';
+  auto it = begin;
+  typedef typename std::iterator_traits::value_type value_type;
+  random_device r;
+  for (; it != end -1; ++it) {
+*it = get_rand(r, max) * (max - min) + min;
+assert(*it >= min);
+assert(*it <= max);
+  }
+  *it = '\0';
+}
+
+// TODO: Create a template class such that all the
+// APIs of STL containers can be exercised in a concise way.
+// for example insert, push_back, pop_back, push_front, pop_front, advance
+
+// TODO: Benchmark memory allocated on heap vs. stack.
+template 
+void fill_seq(T begin, T end) {
+  typedef typename std::iterator_traits::value_type value_type;
+  //random_device r;
+  value_type j = init();// = get_rand(r, RAND_MAX);
+  for (auto it = begin; it != end; ++it, increment(j))
+*it = j;
+}
+
+template  class Container, class value_type>
+void fill_seq(Container ) {
+  fill_seq(std::begin(v), std::end(v));
+}
+
+// Size of vector \p v to be constructed is \p size
+template 
+void make_killer(int size, std::vector& v) {
+  int candidate = 0;
+  int num_solid = 0;
+  int gas = size - 1;
+
+  std::vector tmp(size);
+  v.resize(size);
+
+  for (T i = 0; i < size; ++i) {
+   

Re: r310776 - PR34163: Don't cache an incorrect key function for a class if queried between

2017-08-14 Thread Hans Wennborg via cfe-commits
Sounds good to me. Let's give it another day and see how it goes.

On Fri, Aug 11, 2017 at 6:48 PM, Richard Smith  wrote:
> Hi Hans,
>
> I'd like to get this into Clang 5, but it's not entirely risk-free. Perhaps
> we could leave it in the tree for a little while and then merge if it seems
> OK?
>
> On 11 August 2017 at 18:46, Richard Smith via cfe-commits
>  wrote:
>>
>> Author: rsmith
>> Date: Fri Aug 11 18:46:03 2017
>> New Revision: 310776
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=310776=rev
>> Log:
>> PR34163: Don't cache an incorrect key function for a class if queried
>> between
>> the class becoming complete and its inline methods being parsed.
>>
>> This replaces the hack of using the "late parsed template" flag to track
>> member
>> functions with bodies we've not parsed yet; instead we now use the "will
>> have
>> body" flag, which carries the desired implication that the function
>> declaration
>> *is* a definition, and that we've just not parsed its body yet.
>>
>> Added:
>> cfe/trunk/test/CodeGenCXX/pr34163.cpp
>> Modified:
>> cfe/trunk/include/clang/AST/Decl.h
>> cfe/trunk/lib/AST/DeclCXX.cpp
>> cfe/trunk/lib/Parse/ParseCXXInlineMethods.cpp
>> cfe/trunk/lib/Sema/SemaDecl.cpp
>> cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
>> cfe/trunk/test/SemaCUDA/function-overload.cu
>> cfe/trunk/test/SemaCUDA/no-destructor-overload.cu
>>
>> Modified: cfe/trunk/include/clang/AST/Decl.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Decl.h?rev=310776=310775=310776=diff
>>
>> ==
>> --- cfe/trunk/include/clang/AST/Decl.h (original)
>> +++ cfe/trunk/include/clang/AST/Decl.h Fri Aug 11 18:46:03 2017
>> @@ -1666,8 +1666,7 @@ private:
>>unsigned HasSkippedBody : 1;
>>
>>/// Indicates if the function declaration will have a body, once we're
>> done
>> -  /// parsing it.  (We don't set it to false when we're done parsing, in
>> the
>> -  /// hopes this is simpler.)
>> +  /// parsing it.
>>unsigned WillHaveBody : 1;
>>
>>/// \brief End part of this FunctionDecl's source range.
>>
>> Modified: cfe/trunk/lib/AST/DeclCXX.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/DeclCXX.cpp?rev=310776=310775=310776=diff
>>
>> ==
>> --- cfe/trunk/lib/AST/DeclCXX.cpp (original)
>> +++ cfe/trunk/lib/AST/DeclCXX.cpp Fri Aug 11 18:46:03 2017
>> @@ -1837,9 +1837,10 @@ bool CXXMethodDecl::hasInlineBody() cons
>>const FunctionDecl *CheckFn = getTemplateInstantiationPattern();
>>if (!CheckFn)
>>  CheckFn = this;
>> -
>> +
>>const FunctionDecl *fn;
>> -  return CheckFn->hasBody(fn) && !fn->isOutOfLine();
>> +  return CheckFn->isDefined(fn) && !fn->isOutOfLine() &&
>> + (fn->doesThisDeclarationHaveABody() || fn->willHaveBody());
>>  }
>>
>>  bool CXXMethodDecl::isLambdaStaticInvoker() const {
>>
>> Modified: cfe/trunk/lib/Parse/ParseCXXInlineMethods.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseCXXInlineMethods.cpp?rev=310776=310775=310776=diff
>>
>> ==
>> --- cfe/trunk/lib/Parse/ParseCXXInlineMethods.cpp (original)
>> +++ cfe/trunk/lib/Parse/ParseCXXInlineMethods.cpp Fri Aug 11 18:46:03 2017
>> @@ -166,20 +166,11 @@ NamedDecl *Parser::ParseCXXInlineMethodD
>>}
>>
>>if (FnD) {
>> -// If this is a friend function, mark that it's late-parsed so that
>> -// it's still known to be a definition even before we attach the
>> -// parsed body.  Sema needs to treat friend function definitions
>> -// differently during template instantiation, and it's possible for
>> -// the containing class to be instantiated before all its member
>> -// function definitions are parsed.
>> -//
>> -// If you remove this, you can remove the code that clears the flag
>> -// after parsing the member.
>> -if (D.getDeclSpec().isFriendSpecified()) {
>> -  FunctionDecl *FD = FnD->getAsFunction();
>> -  Actions.CheckForFunctionRedefinition(FD);
>> -  FD->setLateTemplateParsed(true);
>> -}
>> +FunctionDecl *FD = FnD->getAsFunction();
>> +// Track that this function will eventually have a body; Sema needs
>> +// to know this.
>> +Actions.CheckForFunctionRedefinition(FD);
>> +FD->setWillHaveBody(true);
>>} else {
>>  // If semantic analysis could not build a function declaration,
>>  // just throw away the late-parsed declaration.
>> @@ -559,10 +550,6 @@ void Parser::ParseLexedMethodDef(LexedMe
>>
>>ParseFunctionStatementBody(LM.D, FnScope);
>>
>> -  // Clear the late-template-parsed bit if we set it before.
>> -  if (LM.D)
>> -LM.D->getAsFunction()->setLateTemplateParsed(false);
>> -
>>while (Tok.isNot(tok::eof))
>>  

[PATCH] D34158: For Linux/gnu compatibility, preinclude if the file is available

2017-08-14 Thread Melanie Blower via Phabricator via cfe-commits
mibintc updated this revision to Diff 111019.
mibintc added a comment.

@jyknight recommended adding the new option to skipArgs in Job.cpp.  This 
revision makes that change and tests that in crash-report.c; look OK?


https://reviews.llvm.org/D34158

Files:
  include/clang/Driver/CC1Options.td
  include/clang/Lex/PreprocessorOptions.h
  lib/Driver/Job.cpp
  lib/Driver/ToolChains/Linux.cpp
  lib/Driver/ToolChains/Linux.h
  lib/Frontend/CompilerInvocation.cpp
  lib/Frontend/InitPreprocessor.cpp
  test/Driver/Inputs/stdc-predef/usr/include/stdc-predef.h
  test/Driver/clang_cpp.c
  test/Driver/crash-report-header.h
  test/Driver/crash-report-spaces.c
  test/Driver/crash-report.c
  test/Driver/rewrite-legacy-objc.m
  test/Driver/rewrite-map-in-diagnostics.c
  test/Driver/rewrite-objc.m
  test/Driver/stdc-predef.c
  test/Driver/stdc-predef.i
  test/Index/IBOutletCollection.m
  test/Index/annotate-macro-args.m
  test/Index/annotate-tokens-pp.c
  test/Index/annotate-tokens.c
  test/Index/c-index-getCursor-test.m
  test/Index/get-cursor-macro-args.m
  test/Index/get-cursor.cpp
  test/Preprocessor/ignore-pragmas.c
  unittests/Tooling/TestVisitor.h

Index: lib/Driver/ToolChains/Linux.h
===
--- lib/Driver/ToolChains/Linux.h
+++ lib/Driver/ToolChains/Linux.h
@@ -31,6 +31,8 @@
   void addLibStdCxxIncludePaths(
   const llvm::opt::ArgList ,
   llvm::opt::ArgStringList ) const override;
+  void AddGnuIncludeArgs(const llvm::opt::ArgList ,
+  llvm::opt::ArgStringList ) const;
   void AddCudaIncludeArgs(const llvm::opt::ArgList ,
   llvm::opt::ArgStringList ) const override;
   void AddIAMCUIncludeArgs(const llvm::opt::ArgList ,
Index: lib/Driver/ToolChains/Linux.cpp
===
--- lib/Driver/ToolChains/Linux.cpp
+++ lib/Driver/ToolChains/Linux.cpp
@@ -705,6 +705,8 @@
   addExternCSystemInclude(DriverArgs, CC1Args, SysRoot + "/include");
 
   addExternCSystemInclude(DriverArgs, CC1Args, SysRoot + "/usr/include");
+
+  AddGnuIncludeArgs(DriverArgs, CC1Args);
 }
 
 static std::string DetectLibcxxIncludePath(StringRef base) {
@@ -743,6 +745,17 @@
   return "";
 }
 
+void Linux::AddGnuIncludeArgs(const llvm::opt::ArgList ,
+  llvm::opt::ArgStringList ) const {
+  if (!DriverArgs.hasArg(options::OPT_ffreestanding)) {
+// For gcc compatibility, clang will preinclude 
+// -ffreestanding suppresses this behavior.
+CC1Args.push_back("-fsystem-include-if-exists");
+CC1Args.push_back("stdc-predef.h");
+  }
+}
+
+
 void Linux::addLibStdCxxIncludePaths(const llvm::opt::ArgList ,
  llvm::opt::ArgStringList ) const {
   // We need a detected GCC installation on Linux to provide libstdc++'s
Index: lib/Driver/Job.cpp
===
--- lib/Driver/Job.cpp
+++ lib/Driver/Job.cpp
@@ -63,7 +63,7 @@
 .Cases("-internal-externc-isystem", "-iprefix", true)
 .Cases("-iwithprefixbefore", "-isystem", "-iquote", true)
 .Cases("-isysroot", "-I", "-F", "-resource-dir", true)
-.Cases("-iframework", "-include-pch", true)
+.Cases("-iframework", "-include-pch", "-fsystem-include-if-exists", true)
 .Default(false);
   if (IsInclude)
 return HaveCrashVFS ? false : true;
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -2517,6 +2517,10 @@
   for (const Arg *A : Args.filtered(OPT_chain_include))
 Opts.ChainedIncludes.emplace_back(A->getValue());
 
+  // Add the ordered list of -fsystem-include-if-exists.
+  for (const Arg *A : Args.filtered(OPT_fsystem_include_if_exists))
+Opts.FSystemIncludeIfExists.emplace_back(A->getValue());
+
   for (const Arg *A : Args.filtered(OPT_remap_file)) {
 std::pair Split = StringRef(A->getValue()).split(';');
 
Index: lib/Frontend/InitPreprocessor.cpp
===
--- lib/Frontend/InitPreprocessor.cpp
+++ lib/Frontend/InitPreprocessor.cpp
@@ -70,6 +70,15 @@
   Builder.append(Twine("#include \"") + File + "\"");
 }
 
+/// AddImplicitSystemIncludeIfExists - Add an implicit system \#include of the 
+/// specified file to the predefines buffer: precheck with __has_include.
+static void AddImplicitSystemIncludeIfExists(MacroBuilder , 
+ StringRef File) {
+  Builder.append(Twine("#if __has_include( <") + File + ">)");
+  Builder.append(Twine("#include <") + File + ">");
+  Builder.append(Twine("#endif"));
+}
+
 static void AddImplicitIncludeMacros(MacroBuilder , StringRef File) {
   Builder.append(Twine("#__include_macros \"") + File + "\"");
   // Marker token to stop the __include_macros fetch loop.
@@ -1105,6 +1114,13 @@
   // 

[PATCH] D35364: [clang-tidy] Add a close-on-exec check on dup() in Android module.

2017-08-14 Thread Chih-Hung Hsieh via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL310858: [clang-tidy] Add a close-on-exec check on dup() in 
Android module. (authored by chh).

Changed prior to commit:
  https://reviews.llvm.org/D35364?vs=110753=111021#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D35364

Files:
  clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp
  clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt
  clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.cpp
  clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.h
  clang-tools-extra/trunk/clang-tidy/android/CloexecDupCheck.cpp
  clang-tools-extra/trunk/clang-tidy/android/CloexecDupCheck.h
  clang-tools-extra/trunk/docs/ReleaseNotes.rst
  clang-tools-extra/trunk/docs/clang-tidy/checks/android-cloexec-dup.rst
  clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst
  clang-tools-extra/trunk/test/clang-tidy/android-cloexec-dup.cpp

Index: clang-tools-extra/trunk/docs/ReleaseNotes.rst
===
--- clang-tools-extra/trunk/docs/ReleaseNotes.rst
+++ clang-tools-extra/trunk/docs/ReleaseNotes.rst
@@ -70,6 +70,11 @@
   ``AllowConditionalIntegerCasts`` -> ``AllowIntegerConditions``,
   ``AllowConditionalPointerCasts`` -> ``AllowPointerConditions``.
 
+- New `android-cloexec-dup
+  `_ check
+
+  Detects usage of ``dup()``.
+
 - New `android-cloexec-memfd_create
   `_ check
 
Index: clang-tools-extra/trunk/docs/clang-tidy/checks/android-cloexec-dup.rst
===
--- clang-tools-extra/trunk/docs/clang-tidy/checks/android-cloexec-dup.rst
+++ clang-tools-extra/trunk/docs/clang-tidy/checks/android-cloexec-dup.rst
@@ -0,0 +1,18 @@
+.. title:: clang-tidy - android-cloexec-dup
+
+android-cloexec-dup
+===
+
+The usage of ``dup()`` is not recommended, it's better to use ``fcntl()``,
+which can set the close-on-exec flag. Otherwise, an opened sensitive file would
+remain open across a fork+exec to a lower-privileged SELinux domain.
+
+Examples:
+
+.. code-block:: c++
+
+  int fd = dup(oldfd);
+
+  // becomes
+
+  int fd = fcntl(oldfd, F_DUPFD_CLOEXEC);
Index: clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst
@@ -5,6 +5,7 @@
 
 .. toctree::
android-cloexec-creat
+   android-cloexec-dup
android-cloexec-fopen
android-cloexec-memfd-create
android-cloexec-open
Index: clang-tools-extra/trunk/test/clang-tidy/android-cloexec-dup.cpp
===
--- clang-tools-extra/trunk/test/clang-tidy/android-cloexec-dup.cpp
+++ clang-tools-extra/trunk/test/clang-tidy/android-cloexec-dup.cpp
@@ -0,0 +1,31 @@
+// RUN: %check_clang_tidy %s android-cloexec-dup %t
+
+extern "C" int dup(int oldfd);
+void f() {
+  dup(1);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: prefer fcntl() to dup() because fcntl() allows F_DUPFD_CLOEXEC [android-cloexec-dup]
+  // CHECK-FIXES: fcntl(1, F_DUPFD_CLOEXEC);
+  int oldfd = 0;
+  dup(oldfd);
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: prefer
+  // CHECK-FIXES: fcntl(oldfd, F_DUPFD_CLOEXEC);
+}
+
+namespace i {
+int dup(int oldfd);
+void g() {
+  dup(0);
+  int oldfd = 1;
+  dup(oldfd);
+}
+} // namespace i
+
+class C {
+public:
+  int dup(int oldfd);
+  void h() {
+dup(0);
+int oldfd = 1;
+dup(oldfd);
+  }
+};
Index: clang-tools-extra/trunk/clang-tidy/android/CloexecDupCheck.cpp
===
--- clang-tools-extra/trunk/clang-tidy/android/CloexecDupCheck.cpp
+++ clang-tools-extra/trunk/clang-tidy/android/CloexecDupCheck.cpp
@@ -0,0 +1,38 @@
+//===--- CloexecDupCheck.cpp - clang-tidy--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "CloexecDupCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+namespace android {
+
+void CloexecDupCheck::registerMatchers(MatchFinder *Finder) {
+  registerMatchersImpl(Finder,
+   functionDecl(returns(isInteger()), hasName("dup"),
+hasParameter(0, hasType(isInteger();
+}
+
+void CloexecDupCheck::check(const MatchFinder::MatchResult ) {
+  const std::string  =
+  (Twine("fcntl(") + getSpellingArg(Result, 0) + ", 

[clang-tools-extra] r310858 - [clang-tidy] Add a close-on-exec check on dup() in Android module.

2017-08-14 Thread Chih-Hung Hsieh via cfe-commits
Author: chh
Date: Mon Aug 14 10:04:16 2017
New Revision: 310858

URL: http://llvm.org/viewvc/llvm-project?rev=310858=rev
Log:
[clang-tidy] Add a close-on-exec check on dup() in Android module.

Summary:
dup() is better to be replaced by fcntl() to avoid file descriptor leakage.

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


Added:
clang-tools-extra/trunk/clang-tidy/android/CloexecDupCheck.cpp
clang-tools-extra/trunk/clang-tidy/android/CloexecDupCheck.h
clang-tools-extra/trunk/docs/clang-tidy/checks/android-cloexec-dup.rst
clang-tools-extra/trunk/test/clang-tidy/android-cloexec-dup.cpp
Modified:
clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp
clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt
clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.cpp
clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.h
clang-tools-extra/trunk/docs/ReleaseNotes.rst
clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst

Modified: clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp?rev=310858=310857=310858=diff
==
--- clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/android/AndroidTidyModule.cpp Mon Aug 14 
10:04:16 2017
@@ -11,6 +11,7 @@
 #include "../ClangTidyModule.h"
 #include "../ClangTidyModuleRegistry.h"
 #include "CloexecCreatCheck.h"
+#include "CloexecDupCheck.h"
 #include "CloexecFopenCheck.h"
 #include "CloexecMemfdCreateCheck.h"
 #include "CloexecOpenCheck.h"
@@ -27,6 +28,7 @@ class AndroidModule : public ClangTidyMo
 public:
   void addCheckFactories(ClangTidyCheckFactories ) override {
 CheckFactories.registerCheck("android-cloexec-creat");
+CheckFactories.registerCheck("android-cloexec-dup");
 CheckFactories.registerCheck("android-cloexec-fopen");
 CheckFactories.registerCheck(
 "android-cloexec-memfd-create");

Modified: clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt?rev=310858=310857=310858=diff
==
--- clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clang-tidy/android/CMakeLists.txt Mon Aug 14 
10:04:16 2017
@@ -4,6 +4,7 @@ add_clang_library(clangTidyAndroidModule
   AndroidTidyModule.cpp
   CloexecCheck.cpp
   CloexecCreatCheck.cpp
+  CloexecDupCheck.cpp
   CloexecFopenCheck.cpp
   CloexecMemfdCreateCheck.cpp
   CloexecOpenCheck.cpp

Modified: clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.cpp?rev=310858=310857=310858=diff
==
--- clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.cpp Mon Aug 14 
10:04:16 2017
@@ -100,6 +100,15 @@ void CloexecCheck::insertStringFlag(
   ReplacementText);
 }
 
+StringRef CloexecCheck::getSpellingArg(const MatchFinder::MatchResult ,
+   int N) const {
+  const auto *MatchedCall = Result.Nodes.getNodeAs(FuncBindingStr);
+  const SourceManager  = *Result.SourceManager;
+  return Lexer::getSourceText(
+  CharSourceRange::getTokenRange(MatchedCall->getArg(N)->getSourceRange()),
+  SM, Result.Context->getLangOpts());
+}
+
 } // namespace android
 } // namespace tidy
 } // namespace clang

Modified: clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.h?rev=310858=310857=310858=diff
==
--- clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.h (original)
+++ clang-tools-extra/trunk/clang-tidy/android/CloexecCheck.h Mon Aug 14 
10:04:16 2017
@@ -86,6 +86,10 @@ protected:
   /// \param ArgPos The 0-based position of the flag argument.
   void insertStringFlag(const ast_matchers::MatchFinder::MatchResult ,
 const char Mode, const int ArgPos);
+
+  /// Helper function to get the spelling of a particular argument.
+  StringRef getSpellingArg(const ast_matchers::MatchFinder::MatchResult 
,
+   int N) const;
 };
 
 } // namespace android

Added: clang-tools-extra/trunk/clang-tidy/android/CloexecDupCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/android/CloexecDupCheck.cpp?rev=310858=auto
==
--- 

[PATCH] D36200: [Sema] Improve some -Wunguarded-availability diagnostic messages

2017-08-14 Thread Alex Lorenz via Phabricator via cfe-commits
arphaman accepted this revision.
arphaman added a comment.
This revision is now accepted and ready to land.

Sorry for the delay, LGTM


https://reviews.llvm.org/D36200



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


[PATCH] D36200: [Sema] Improve some -Wunguarded-availability diagnostic messages

2017-08-14 Thread Erik Pilkington via Phabricator via cfe-commits
erik.pilkington added a comment.

Ping!


https://reviews.llvm.org/D36200



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


Re: r310401 - PR19668, PR23034: Fix handling of move constructors and deleted copy

2017-08-14 Thread Diana Picus via cfe-commits
Hi,

I didn't manage to reproduce this at -O0. Yes, I think the version in
1.8.0, slightly modified (see
llvm/utils/unittest/googletest/README.LLVM)

On 14 August 2017 at 17:06, Vassil Vassilev  wrote:
> On 14/08/17 15:59, Diana Picus wrote:
>>
>> No, the buildbots don't build with -O0 (at least not the ones that broke).
>>
>> The command line for that particular object is:
>> build/./bin/clang -fPIC -fvisibility-inlines-hidden -Werror=date-time
>> -std=c++11 -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual
>> -Wmissing-field-initializers -pedantic -Wno-long-long
>> -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
>> -Wstring-conversion -fcolor-diagnostics -ffunction-sections
>> -fdata-sections -Wall -std=c++11 -Wno-unused-parameter
>> -Wno-unknown-warning-option -Wno-covered-switch-default
>> -DGTEST_NO_LLVM_RAW_OSTREAM=1 -DGTEST_HAS_RTTI=0
>> -I$LLVM_SRC/llvm/utils/unittest/googletest/include
>> -I/home/diana.picus/linaro-scripts/bisect/llvm/utils/unittest/googletest
>> -I$LLVM_SRC/llvm/projects/compiler-rt/include
>> -I$LLVM_SRC/llvm/projects/compiler-rt/lib
>> -I$LLVM_SRC/llvm/projects/compiler-rt/lib/asan
>> -I$LLVM_SRC/llvm/projects/compiler-rt/lib/sanitizer_common/tests
>> -fno-rtti -O2 -Wno-format -Werror=sign-compare -Wno-non-virtual-dtor
>> -Wno-variadic-macros -gline-tables-only -DASAN_HAS_BLACKLIST=1
>> -DASAN_HAS_EXCEPTIONS=1 -DASAN_UAR=0 -fsanitize=address
>>
>> -fsanitize-blacklist=$LLVM_SRC/llvm/projects/compiler-rt/lib/asan/tests/asan_test.ignore
>> -mllvm -asan-instrumentation-with-call-threshold=0 -march=armv7-a
>> -mfloat-abi=hard -c -o
>> ASAN_INST_TEST_OBJECTS.asan_test.cc.armhf-with-calls.o
>> $LLVM_SRC/compiler-rt/lib/asan/tests/asan_test.cc
>
>   Could you try to reproduce the issue with O0? This would rule out the
> optimizer. Could you resend the O0 ll file, maybe I could find something
> out. IIUC, the gtest version is 1.8.0?
>
>>
>> Why would it contain gtest.cc? It seems to contain gtest.h and a bunch
>> of other internal gtest headers...
>>
>>
>> On 14 August 2017 at 16:51, Vassil Vassilev 
>> wrote:
>>>
>>> On 14/08/17 15:08, Vassil Vassilev wrote:

 On 14/08/17 13:04, Diana Picus wrote:
>
> See attached.

 Thanks! It looks like asan_test.i doesn't have gtest.cc which appears in
 the stack trace. Am I missing something?
>>>
>>>Could you paste the compiler invocation. Are we building with -O0 (I
>>> see
>>> quite a lot of things inline). Could it be an optimizer problem?
>>>
> On 14 August 2017 at 13:30, Vassil Vassilev 
> wrote:
>>
>> On 14/08/17 11:27, Diana Picus wrote:
>>>
>>> Hi,
>>>
>>> Strangely enough, it turns out that if I run
>>> Asan-armhf-with-calls-Noinst-Test on the command line it fails,
>>> although it doesn't fail when run with lit. I've attached the stack
>>> trace from gdb. It looks like some trouble passing down va_arg
>>> parameters, but I haven't looked into too much details. The segfault
>>> happens when we try to do a   ldrb   r3, [r0, r1], with r1 set to 0
>>> by
>>> the current function and r0 passed down from the caller. I'm not sure
>>> if this is the exact same problem as the other tests, but feel free
>>> to
>>> have a look at that code.
>>>
>>> Meanwhile, I've removed some clutter from Asan-armhf-with-calls-Test
>>> (which is the original failure that we were seeing) and left only one
>>> failing test that seemed small enough. I'll try to look at the
>>> disassembly before/after the patch and maybe even run valgrind on it
>>> (running it on the original binary naturally takes forever).
>>>
>>> Let me know if there's anything else I could try. I can also send you
>>> disassembly or even LLVM IR for the Asan-armhf-with-calls-Noinst-Test
>>> if you think it helps.
>>
>> disassembly and LLVM will greatly help as well.
>>
>>> Cheers,
>>> Diana
>>>
>>> On 11 August 2017 at 15:34, Diana Picus 
>>> wrote:

 Well, these are ASAN tests, I'm not sure how that would interact
 with
 Valgrind.
 Anyway, I'll try to reproduce the environment, I'm guessing it would
 be best to catch this in gdb so I can actually see what's going on.

 On 11 August 2017 at 15:21, Vassil Vassilev 
 wrote:
>
> That's really strange. It looks like some random behavior. Did you
> run
> some memory checker like valgrind?
>
> Do the environment provided by the test runner and yours match?
>
> Sent from my phone. Please excuse my brevity.
>
>> On 11 Aug 2017, at 15:58, Diana Picus 
>> wrote:
>>
>> Hi again,
>>
>> I finally got the debug build, but 

Re: r310853 - [rename] Introduce symbol occurrences

2017-08-14 Thread Alex L via cfe-commits
It's an NFC, thus untested.

On 14 August 2017 at 17:19, Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: arphaman
> Date: Mon Aug 14 09:19:24 2017
> New Revision: 310853
>
> URL: http://llvm.org/viewvc/llvm-project?rev=310853=rev
> Log:
> [rename] Introduce symbol occurrences
>
> Symbol occurrences store the results of local rename and will also be used
> for
> the global, indexed rename results. Their kind is used to determine
> whether they
> should be renamed automatically or not. They can be converted to a set of
> AtomicChanges as well.
>
> Differential Revision: https://reviews.llvm.org/D36156
>
> Added:
> cfe/trunk/include/clang/Tooling/Refactoring/Rename/SymbolName.h
> cfe/trunk/include/clang/Tooling/Refactoring/Rename/SymbolOccurrences.h
> cfe/trunk/lib/Tooling/Refactoring/Rename/SymbolOccurrences.cpp
> Modified:
> cfe/trunk/include/clang/Tooling/Refactoring/Rename/RenamingAction.h
> cfe/trunk/include/clang/Tooling/Refactoring/Rename/USRLocFinder.h
> cfe/trunk/lib/Tooling/Refactoring/CMakeLists.txt
> cfe/trunk/lib/Tooling/Refactoring/Rename/RenamingAction.cpp
> cfe/trunk/lib/Tooling/Refactoring/Rename/USRLocFinder.cpp
>
> Modified: cfe/trunk/include/clang/Tooling/Refactoring/Rename/
> RenamingAction.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Tooling/Refactoring/Rename/RenamingAction.h?rev=
> 310853=310852=310853=diff
> 
> ==
> --- cfe/trunk/include/clang/Tooling/Refactoring/Rename/RenamingAction.h
> (original)
> +++ cfe/trunk/include/clang/Tooling/Refactoring/Rename/RenamingAction.h
> Mon Aug 14 09:19:24 2017
> @@ -16,6 +16,9 @@
>  #define LLVM_CLANG_TOOLING_REFACTOR_RENAME_RENAMING_ACTION_H
>
>  #include "clang/Tooling/Refactoring.h"
> +#include "clang/Tooling/Refactoring/AtomicChange.h"
> +#include "clang/Tooling/Refactoring/Rename/SymbolOccurrences.h"
> +#include "llvm/Support/Error.h"
>
>  namespace clang {
>  class ASTConsumer;
> @@ -42,6 +45,13 @@ private:
>bool PrintLocations;
>  };
>
> +/// Returns source replacements that correspond to the rename of the given
> +/// symbol occurrences.
> +llvm::Expected
> +createRenameReplacements(const SymbolOccurrences ,
> + const SourceManager ,
> + ArrayRef NewNameStrings);
> +
>  /// Rename all symbols identified by the given USRs.
>  class QualifiedRenamingAction {
>  public:
>
> Added: cfe/trunk/include/clang/Tooling/Refactoring/Rename/SymbolName.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Tooling/Refactoring/Rename/SymbolName.h?rev=310853=auto
> 
> ==
> --- cfe/trunk/include/clang/Tooling/Refactoring/Rename/SymbolName.h
> (added)
> +++ cfe/trunk/include/clang/Tooling/Refactoring/Rename/SymbolName.h Mon
> Aug 14 09:19:24 2017
> @@ -0,0 +1,49 @@
> +//===--- SymbolName.h - Clang refactoring library
> -===//
> +//
> +// The LLVM Compiler Infrastructure
> +//
> +// This file is distributed under the University of Illinois Open Source
> +// License. See LICENSE.TXT for details.
> +//
> +//===--
> ===//
> +
> +#ifndef LLVM_CLANG_TOOLING_REFACTOR_RENAME_SYMBOL_NAME_H
> +#define LLVM_CLANG_TOOLING_REFACTOR_RENAME_SYMBOL_NAME_H
> +
> +#include "clang/Basic/LLVM.h"
> +#include "llvm/ADT/ArrayRef.h"
> +#include "llvm/ADT/SmallVector.h"
> +#include "llvm/ADT/StringRef.h"
> +
> +namespace clang {
> +namespace tooling {
> +
> +/// A name of a symbol.
> +///
> +/// Symbol's name can be composed of multiple strings. For example,
> Objective-C
> +/// methods can contain multiple argument lables:
> +///
> +/// \code
> +/// - (void) myMethodNamePiece: (int)x anotherNamePieces:(int)y;
> +/// //   ^~ string 0 ~ ^~ string 1 ~
> +/// \endcode
> +class SymbolName {
> +public:
> +  SymbolName(StringRef Name) {
> +// While empty symbol names are valid (Objective-C selectors can have
> empty
> +// name pieces), occurrences Objective-C selectors are created using
> an
> +// array of strings instead of just one string.
> +assert(!Name.empty() && "Invalid symbol name!");
> +this->Name.push_back(Name.str());
> +  }
> +
> +  ArrayRef getNamePieces() const { return Name; }
> +
> +private:
> +  llvm::SmallVector Name;
> +};
> +
> +} // end namespace tooling
> +} // end namespace clang
> +
> +#endif // LLVM_CLANG_TOOLING_REFACTOR_RENAME_SYMBOL_NAME_H
>
> Added: cfe/trunk/include/clang/Tooling/Refactoring/Rename/
> SymbolOccurrences.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/
> clang/Tooling/Refactoring/Rename/SymbolOccurrences.h?rev=310853=auto
> 
> ==
> --- 

[PATCH] D36156: [rename] Introduce symbol occurrences

2017-08-14 Thread Alex Lorenz via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL310853: [rename] Introduce symbol occurrences (authored by 
arphaman).

Changed prior to commit:
  https://reviews.llvm.org/D36156?vs=110964=110999#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D36156

Files:
  cfe/trunk/include/clang/Tooling/Refactoring/Rename/RenamingAction.h
  cfe/trunk/include/clang/Tooling/Refactoring/Rename/SymbolName.h
  cfe/trunk/include/clang/Tooling/Refactoring/Rename/SymbolOccurrences.h
  cfe/trunk/include/clang/Tooling/Refactoring/Rename/USRLocFinder.h
  cfe/trunk/lib/Tooling/Refactoring/CMakeLists.txt
  cfe/trunk/lib/Tooling/Refactoring/Rename/RenamingAction.cpp
  cfe/trunk/lib/Tooling/Refactoring/Rename/SymbolOccurrences.cpp
  cfe/trunk/lib/Tooling/Refactoring/Rename/USRLocFinder.cpp

Index: cfe/trunk/lib/Tooling/Refactoring/CMakeLists.txt
===
--- cfe/trunk/lib/Tooling/Refactoring/CMakeLists.txt
+++ cfe/trunk/lib/Tooling/Refactoring/CMakeLists.txt
@@ -3,6 +3,7 @@
 add_clang_library(clangToolingRefactor
   AtomicChange.cpp
   Rename/RenamingAction.cpp
+  Rename/SymbolOccurrences.cpp
   Rename/USRFinder.cpp
   Rename/USRFindingAction.cpp
   Rename/USRLocFinder.cpp
Index: cfe/trunk/lib/Tooling/Refactoring/Rename/SymbolOccurrences.cpp
===
--- cfe/trunk/lib/Tooling/Refactoring/Rename/SymbolOccurrences.cpp
+++ cfe/trunk/lib/Tooling/Refactoring/Rename/SymbolOccurrences.cpp
@@ -0,0 +1,37 @@
+//===--- SymbolOccurrences.cpp - Clang refactoring library ===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "clang/Tooling/Refactoring/Rename/SymbolOccurrences.h"
+#include "clang/Tooling/Refactoring/Rename/SymbolName.h"
+#include "llvm/ADT/STLExtras.h"
+
+using namespace clang;
+using namespace tooling;
+
+SymbolOccurrence::SymbolOccurrence(const SymbolName , OccurrenceKind Kind,
+   ArrayRef Locations)
+: Kind(Kind) {
+  ArrayRef NamePieces = Name.getNamePieces();
+  assert(Locations.size() == NamePieces.size() &&
+ "mismatching number of locations and lengths");
+  assert(!Locations.empty() && "no locations");
+  if (Locations.size() == 1) {
+RangeOrNumRanges = SourceRange(
+Locations[0], Locations[0].getLocWithOffset(NamePieces[0].size()));
+return;
+  }
+  MultipleRanges = llvm::make_unique(Locations.size());
+  RangeOrNumRanges.setBegin(
+  SourceLocation::getFromRawEncoding(Locations.size()));
+  for (const auto  : llvm::enumerate(Locations)) {
+MultipleRanges[Loc.index()] = SourceRange(
+Loc.value(),
+Loc.value().getLocWithOffset(NamePieces[Loc.index()].size()));
+  }
+}
Index: cfe/trunk/lib/Tooling/Refactoring/Rename/USRLocFinder.cpp
===
--- cfe/trunk/lib/Tooling/Refactoring/Rename/USRLocFinder.cpp
+++ cfe/trunk/lib/Tooling/Refactoring/Rename/USRLocFinder.cpp
@@ -23,6 +23,7 @@
 #include "clang/Lex/Lexer.h"
 #include "clang/Tooling/Core/Lookup.h"
 #include "clang/Tooling/Refactoring/RecursiveSymbolVisitor.h"
+#include "clang/Tooling/Refactoring/Rename/SymbolName.h"
 #include "clang/Tooling/Refactoring/Rename/USRFinder.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Support/Casting.h"
@@ -68,11 +69,9 @@
 
   // Non-visitors:
 
-  // \brief Returns a list of unique locations. Duplicate or overlapping
-  // locations are erroneous and should be reported!
-  const std::vector () const {
-return LocationsFound;
-  }
+  /// \brief Returns a set of unique symbol occurrences. Duplicate or
+  /// overlapping occurrences are erroneous and should be reported!
+  SymbolOccurrences takeOccurrences() { return std::move(Occurrences); }
 
 private:
   void checkAndAddLocation(SourceLocation Loc) {
@@ -82,17 +81,18 @@
 StringRef TokenName =
 Lexer::getSourceText(CharSourceRange::getTokenRange(BeginLoc, EndLoc),
  Context.getSourceManager(), Context.getLangOpts());
-size_t Offset = TokenName.find(PrevName);
+size_t Offset = TokenName.find(PrevName.getNamePieces()[0]);
 
 // The token of the source location we find actually has the old
 // name.
 if (Offset != StringRef::npos)
-  LocationsFound.push_back(BeginLoc.getLocWithOffset(Offset));
+  Occurrences.emplace_back(PrevName, SymbolOccurrence::MatchingSymbol,
+   BeginLoc.getLocWithOffset(Offset));
   }
 
   const std::set USRSet;
-  const std::string PrevName;
-  std::vector LocationsFound;
+  const SymbolName PrevName;
+  SymbolOccurrences Occurrences;
   const ASTContext 
 };
 
@@ -391,12 +391,11 @@
 
 } // namespace
 

r310853 - [rename] Introduce symbol occurrences

2017-08-14 Thread Alex Lorenz via cfe-commits
Author: arphaman
Date: Mon Aug 14 09:19:24 2017
New Revision: 310853

URL: http://llvm.org/viewvc/llvm-project?rev=310853=rev
Log:
[rename] Introduce symbol occurrences

Symbol occurrences store the results of local rename and will also be used for
the global, indexed rename results. Their kind is used to determine whether they
should be renamed automatically or not. They can be converted to a set of
AtomicChanges as well.

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

Added:
cfe/trunk/include/clang/Tooling/Refactoring/Rename/SymbolName.h
cfe/trunk/include/clang/Tooling/Refactoring/Rename/SymbolOccurrences.h
cfe/trunk/lib/Tooling/Refactoring/Rename/SymbolOccurrences.cpp
Modified:
cfe/trunk/include/clang/Tooling/Refactoring/Rename/RenamingAction.h
cfe/trunk/include/clang/Tooling/Refactoring/Rename/USRLocFinder.h
cfe/trunk/lib/Tooling/Refactoring/CMakeLists.txt
cfe/trunk/lib/Tooling/Refactoring/Rename/RenamingAction.cpp
cfe/trunk/lib/Tooling/Refactoring/Rename/USRLocFinder.cpp

Modified: cfe/trunk/include/clang/Tooling/Refactoring/Rename/RenamingAction.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Tooling/Refactoring/Rename/RenamingAction.h?rev=310853=310852=310853=diff
==
--- cfe/trunk/include/clang/Tooling/Refactoring/Rename/RenamingAction.h 
(original)
+++ cfe/trunk/include/clang/Tooling/Refactoring/Rename/RenamingAction.h Mon Aug 
14 09:19:24 2017
@@ -16,6 +16,9 @@
 #define LLVM_CLANG_TOOLING_REFACTOR_RENAME_RENAMING_ACTION_H
 
 #include "clang/Tooling/Refactoring.h"
+#include "clang/Tooling/Refactoring/AtomicChange.h"
+#include "clang/Tooling/Refactoring/Rename/SymbolOccurrences.h"
+#include "llvm/Support/Error.h"
 
 namespace clang {
 class ASTConsumer;
@@ -42,6 +45,13 @@ private:
   bool PrintLocations;
 };
 
+/// Returns source replacements that correspond to the rename of the given
+/// symbol occurrences.
+llvm::Expected
+createRenameReplacements(const SymbolOccurrences ,
+ const SourceManager ,
+ ArrayRef NewNameStrings);
+
 /// Rename all symbols identified by the given USRs.
 class QualifiedRenamingAction {
 public:

Added: cfe/trunk/include/clang/Tooling/Refactoring/Rename/SymbolName.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Tooling/Refactoring/Rename/SymbolName.h?rev=310853=auto
==
--- cfe/trunk/include/clang/Tooling/Refactoring/Rename/SymbolName.h (added)
+++ cfe/trunk/include/clang/Tooling/Refactoring/Rename/SymbolName.h Mon Aug 14 
09:19:24 2017
@@ -0,0 +1,49 @@
+//===--- SymbolName.h - Clang refactoring library 
-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_TOOLING_REFACTOR_RENAME_SYMBOL_NAME_H
+#define LLVM_CLANG_TOOLING_REFACTOR_RENAME_SYMBOL_NAME_H
+
+#include "clang/Basic/LLVM.h"
+#include "llvm/ADT/ArrayRef.h"
+#include "llvm/ADT/SmallVector.h"
+#include "llvm/ADT/StringRef.h"
+
+namespace clang {
+namespace tooling {
+
+/// A name of a symbol.
+///
+/// Symbol's name can be composed of multiple strings. For example, Objective-C
+/// methods can contain multiple argument lables:
+///
+/// \code
+/// - (void) myMethodNamePiece: (int)x anotherNamePieces:(int)y;
+/// //   ^~ string 0 ~ ^~ string 1 ~
+/// \endcode
+class SymbolName {
+public:
+  SymbolName(StringRef Name) {
+// While empty symbol names are valid (Objective-C selectors can have empty
+// name pieces), occurrences Objective-C selectors are created using an
+// array of strings instead of just one string.
+assert(!Name.empty() && "Invalid symbol name!");
+this->Name.push_back(Name.str());
+  }
+
+  ArrayRef getNamePieces() const { return Name; }
+
+private:
+  llvm::SmallVector Name;
+};
+
+} // end namespace tooling
+} // end namespace clang
+
+#endif // LLVM_CLANG_TOOLING_REFACTOR_RENAME_SYMBOL_NAME_H

Added: cfe/trunk/include/clang/Tooling/Refactoring/Rename/SymbolOccurrences.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Tooling/Refactoring/Rename/SymbolOccurrences.h?rev=310853=auto
==
--- cfe/trunk/include/clang/Tooling/Refactoring/Rename/SymbolOccurrences.h 
(added)
+++ cfe/trunk/include/clang/Tooling/Refactoring/Rename/SymbolOccurrences.h Mon 
Aug 14 09:19:24 2017
@@ -0,0 +1,91 @@
+//===--- SymbolOccurrences.h - Clang refactoring library 
--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source

[PATCH] D36672: [clang-tidy] readability-non-const-parameter: fixit on all function declarations

2017-08-14 Thread Daniel Marjamäki via Phabricator via cfe-commits
danielmarjamaki added a comment.

LGTM. But others should approve.


Repository:
  rL LLVM

https://reviews.llvm.org/D36672



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


[PATCH] D36686: [clang-diff] Add option to compare files across git revisions

2017-08-14 Thread Alex Lorenz via Phabricator via cfe-commits
arphaman added a comment.

It might be useful to have both source and destination in a different revision. 
Maybe something like `-src-git-rev` and `-dst-git-rev`?


https://reviews.llvm.org/D36686



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


[PATCH] D36684: clang-format: [JS] wrap optional properties in type aliases.

2017-08-14 Thread Martin Probst via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL310852: clang-format: [JS] wrap optional properties in type 
aliases. (authored by mprobst).

Repository:
  rL LLVM

https://reviews.llvm.org/D36684

Files:
  cfe/trunk/lib/Format/TokenAnnotator.cpp
  cfe/trunk/unittests/Format/FormatTestJS.cpp


Index: cfe/trunk/lib/Format/TokenAnnotator.cpp
===
--- cfe/trunk/lib/Format/TokenAnnotator.cpp
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp
@@ -459,6 +459,8 @@
 updateParameterCount(Left, CurrentToken);
 if (CurrentToken->isOneOf(tok::colon, tok::l_brace, tok::less)) {
   FormatToken *Previous = CurrentToken->getPreviousNonComment();
+  if (Previous->is(TT_JsTypeOptionalQuestion))
+Previous = Previous->getPreviousNonComment();
   if (((CurrentToken->is(tok::colon) &&
 (!Contexts.back().ColonIsDictLiteral || !Style.isCpp())) ||
Style.Language == FormatStyle::LK_Proto ||
@@ -1601,7 +1603,7 @@
   if (Current->is(TT_ConditionalExpr))
 return prec::Conditional;
   if (NextNonComment && Current->is(TT_SelectorName) &&
-  (NextNonComment->is(TT_DictLiteral) ||
+  (NextNonComment->isOneOf(TT_DictLiteral, TT_JsTypeColon) ||
((Style.Language == FormatStyle::LK_Proto ||
  Style.Language == FormatStyle::LK_TextProto) &&
 NextNonComment->is(tok::less
Index: cfe/trunk/unittests/Format/FormatTestJS.cpp
===
--- cfe/trunk/unittests/Format/FormatTestJS.cpp
+++ cfe/trunk/unittests/Format/FormatTestJS.cpp
@@ -1561,6 +1561,10 @@
"  y: number\n"
"};\n"
"class C {}");
+  verifyFormat("export type X = {\n"
+   "  a: string,\n"
+   "  b?: string,\n"
+   "};\n");
 }
 
 TEST_F(FormatTestJS, TypeInterfaceLineWrapping) {


Index: cfe/trunk/lib/Format/TokenAnnotator.cpp
===
--- cfe/trunk/lib/Format/TokenAnnotator.cpp
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp
@@ -459,6 +459,8 @@
 updateParameterCount(Left, CurrentToken);
 if (CurrentToken->isOneOf(tok::colon, tok::l_brace, tok::less)) {
   FormatToken *Previous = CurrentToken->getPreviousNonComment();
+  if (Previous->is(TT_JsTypeOptionalQuestion))
+Previous = Previous->getPreviousNonComment();
   if (((CurrentToken->is(tok::colon) &&
 (!Contexts.back().ColonIsDictLiteral || !Style.isCpp())) ||
Style.Language == FormatStyle::LK_Proto ||
@@ -1601,7 +1603,7 @@
   if (Current->is(TT_ConditionalExpr))
 return prec::Conditional;
   if (NextNonComment && Current->is(TT_SelectorName) &&
-  (NextNonComment->is(TT_DictLiteral) ||
+  (NextNonComment->isOneOf(TT_DictLiteral, TT_JsTypeColon) ||
((Style.Language == FormatStyle::LK_Proto ||
  Style.Language == FormatStyle::LK_TextProto) &&
 NextNonComment->is(tok::less
Index: cfe/trunk/unittests/Format/FormatTestJS.cpp
===
--- cfe/trunk/unittests/Format/FormatTestJS.cpp
+++ cfe/trunk/unittests/Format/FormatTestJS.cpp
@@ -1561,6 +1561,10 @@
"  y: number\n"
"};\n"
"class C {}");
+  verifyFormat("export type X = {\n"
+   "  a: string,\n"
+   "  b?: string,\n"
+   "};\n");
 }
 
 TEST_F(FormatTestJS, TypeInterfaceLineWrapping) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r310852 - clang-format: [JS] wrap optional properties in type aliases.

2017-08-14 Thread Martin Probst via cfe-commits
Author: mprobst
Date: Mon Aug 14 09:09:08 2017
New Revision: 310852

URL: http://llvm.org/viewvc/llvm-project?rev=310852=rev
Log:
clang-format: [JS] wrap optional properties in type aliases.

Summary:
clang-format wraps object literal keys in an object literal if they are
marked as `TT_SelectorName`s and/or the colon is marked as
`TT_DictLiteral`. Previously, clang-format would accidentally work
because colons in type aliases were marked as `TT_DictLiteral`. r310367
fixed this to assing `TT_JsTypeColon`, which broke wrapping in certain
situations. However the root cause was that clang-format incorrectly
didn't skip questionmarks when detecting selector name.

This change fixes both locations to (1) assign `TT_SelectorName` and (2)
treat `TT_JsTypeColon` like `TT_DictLiteral`.

Previously:

type X = {
  a: string, b?: string,
};

Now:

type X = {
  a: string,
  b?: string,
};

Reviewers: djasper, sammccall

Subscribers: cfe-commits, klimek

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

Modified:
cfe/trunk/lib/Format/TokenAnnotator.cpp
cfe/trunk/unittests/Format/FormatTestJS.cpp

Modified: cfe/trunk/lib/Format/TokenAnnotator.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/TokenAnnotator.cpp?rev=310852=310851=310852=diff
==
--- cfe/trunk/lib/Format/TokenAnnotator.cpp (original)
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp Mon Aug 14 09:09:08 2017
@@ -459,6 +459,8 @@ private:
 updateParameterCount(Left, CurrentToken);
 if (CurrentToken->isOneOf(tok::colon, tok::l_brace, tok::less)) {
   FormatToken *Previous = CurrentToken->getPreviousNonComment();
+  if (Previous->is(TT_JsTypeOptionalQuestion))
+Previous = Previous->getPreviousNonComment();
   if (((CurrentToken->is(tok::colon) &&
 (!Contexts.back().ColonIsDictLiteral || !Style.isCpp())) ||
Style.Language == FormatStyle::LK_Proto ||
@@ -1601,7 +1603,7 @@ private:
   if (Current->is(TT_ConditionalExpr))
 return prec::Conditional;
   if (NextNonComment && Current->is(TT_SelectorName) &&
-  (NextNonComment->is(TT_DictLiteral) ||
+  (NextNonComment->isOneOf(TT_DictLiteral, TT_JsTypeColon) ||
((Style.Language == FormatStyle::LK_Proto ||
  Style.Language == FormatStyle::LK_TextProto) &&
 NextNonComment->is(tok::less

Modified: cfe/trunk/unittests/Format/FormatTestJS.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTestJS.cpp?rev=310852=310851=310852=diff
==
--- cfe/trunk/unittests/Format/FormatTestJS.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTestJS.cpp Mon Aug 14 09:09:08 2017
@@ -1561,6 +1561,10 @@ TEST_F(FormatTestJS, TypeAliases) {
"  y: number\n"
"};\n"
"class C {}");
+  verifyFormat("export type X = {\n"
+   "  a: string,\n"
+   "  b?: string,\n"
+   "};\n");
 }
 
 TEST_F(FormatTestJS, TypeInterfaceLineWrapping) {


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


[PATCH] D36142: clang-format: [JS] do not insert whitespace in call positions.

2017-08-14 Thread Martin Probst via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL310851: clang-format: [JS] do not insert whitespace in call 
positions. (authored by mprobst).

Repository:
  rL LLVM

https://reviews.llvm.org/D36142

Files:
  cfe/trunk/lib/Format/TokenAnnotator.cpp
  cfe/trunk/unittests/Format/FormatTestJS.cpp


Index: cfe/trunk/lib/Format/TokenAnnotator.cpp
===
--- cfe/trunk/lib/Format/TokenAnnotator.cpp
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp
@@ -2367,13 +2367,20 @@
 Left.isOneOf(Keywords.kw_function, Keywords.kw_yield,
  Keywords.kw_extends, Keywords.kw_implements))
   return true;
-// JS methods can use some keywords as names (e.g. `delete()`).
-if (Right.is(tok::l_paren) && Line.MustBeDeclaration &&
-Left.Tok.getIdentifierInfo())
-  return false;
-if (Right.is(tok::l_paren) &&
-Left.isOneOf(tok::kw_throw, Keywords.kw_await, Keywords.kw_typeof, 
tok::kw_void))
-  return true;
+if (Right.is(tok::l_paren)) {
+  // JS methods can use some keywords as names (e.g. `delete()`).
+  if (Line.MustBeDeclaration && Left.Tok.getIdentifierInfo())
+return false;
+  // Valid JS method names can include keywords, e.g. `foo.delete()` or
+  // `bar.instanceof()`. Recognize call positions by preceding period.
+  if (Left.Previous && Left.Previous->is(tok::period) &&
+  Left.Tok.getIdentifierInfo())
+return false;
+  // Additional unary JavaScript operators that need a space after.
+  if (Left.isOneOf(tok::kw_throw, Keywords.kw_await, Keywords.kw_typeof,
+   tok::kw_void))
+return true;
+}
 if ((Left.isOneOf(Keywords.kw_let, Keywords.kw_var, Keywords.kw_in,
   tok::kw_const) ||
  // "of" is only a keyword if it appears after another identifier
Index: cfe/trunk/unittests/Format/FormatTestJS.cpp
===
--- cfe/trunk/unittests/Format/FormatTestJS.cpp
+++ cfe/trunk/unittests/Format/FormatTestJS.cpp
@@ -271,14 +271,21 @@
   verifyFormat("x.case = 1;");
   verifyFormat("x.interface = 1;");
   verifyFormat("x.for = 1;");
-  verifyFormat("x.of() = 1;");
+  verifyFormat("x.of();");
   verifyFormat("of(null);");
   verifyFormat("import {of} from 'x';");
-  verifyFormat("x.in() = 1;");
-  verifyFormat("x.let() = 1;");
-  verifyFormat("x.var() = 1;");
-  verifyFormat("x.for() = 1;");
-  verifyFormat("x.as() = 1;");
+  verifyFormat("x.in();");
+  verifyFormat("x.let();");
+  verifyFormat("x.var();");
+  verifyFormat("x.for();");
+  verifyFormat("x.as();");
+  verifyFormat("x.instanceof();");
+  verifyFormat("x.switch();");
+  verifyFormat("x.case();");
+  verifyFormat("x.delete();");
+  verifyFormat("x.throw();");
+  verifyFormat("x.throws();");
+  verifyFormat("x.if();");
   verifyFormat("x = {\n"
"  a: 12,\n"
"  interface: 1,\n"
@@ -1228,7 +1235,6 @@
   // But, of course, "catch" is a perfectly fine function name in JavaScript.
   verifyFormat("someObject.catch();");
   verifyFormat("someObject.new();");
-  verifyFormat("someObject.delete();");
 }
 
 TEST_F(FormatTestJS, StringLiteralConcatenation) {


Index: cfe/trunk/lib/Format/TokenAnnotator.cpp
===
--- cfe/trunk/lib/Format/TokenAnnotator.cpp
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp
@@ -2367,13 +2367,20 @@
 Left.isOneOf(Keywords.kw_function, Keywords.kw_yield,
  Keywords.kw_extends, Keywords.kw_implements))
   return true;
-// JS methods can use some keywords as names (e.g. `delete()`).
-if (Right.is(tok::l_paren) && Line.MustBeDeclaration &&
-Left.Tok.getIdentifierInfo())
-  return false;
-if (Right.is(tok::l_paren) &&
-Left.isOneOf(tok::kw_throw, Keywords.kw_await, Keywords.kw_typeof, tok::kw_void))
-  return true;
+if (Right.is(tok::l_paren)) {
+  // JS methods can use some keywords as names (e.g. `delete()`).
+  if (Line.MustBeDeclaration && Left.Tok.getIdentifierInfo())
+return false;
+  // Valid JS method names can include keywords, e.g. `foo.delete()` or
+  // `bar.instanceof()`. Recognize call positions by preceding period.
+  if (Left.Previous && Left.Previous->is(tok::period) &&
+  Left.Tok.getIdentifierInfo())
+return false;
+  // Additional unary JavaScript operators that need a space after.
+  if (Left.isOneOf(tok::kw_throw, Keywords.kw_await, Keywords.kw_typeof,
+   tok::kw_void))
+return true;
+}
 if ((Left.isOneOf(Keywords.kw_let, Keywords.kw_var, Keywords.kw_in,
   tok::kw_const) ||
  // "of" is only a keyword if it appears after another identifier
Index: cfe/trunk/unittests/Format/FormatTestJS.cpp

r310851 - clang-format: [JS] do not insert whitespace in call positions.

2017-08-14 Thread Martin Probst via cfe-commits
Author: mprobst
Date: Mon Aug 14 09:08:16 2017
New Revision: 310851

URL: http://llvm.org/viewvc/llvm-project?rev=310851=rev
Log:
clang-format: [JS] do not insert whitespace in call positions.

Summary:
In JavaScript, may keywords can be used in method names and thus call sites:

foo.delete();
foo.instanceof();

clang-format would previously insert whitespace after the `instanceof`. This
change generically skips inserting whitespace between a keyword and a
parenthesis if preceded by a dot, i.e. in a callsite.

Reviewers: djasper

Subscribers: klimek, cfe-commits

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

Modified:
cfe/trunk/lib/Format/TokenAnnotator.cpp
cfe/trunk/unittests/Format/FormatTestJS.cpp

Modified: cfe/trunk/lib/Format/TokenAnnotator.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/TokenAnnotator.cpp?rev=310851=310850=310851=diff
==
--- cfe/trunk/lib/Format/TokenAnnotator.cpp (original)
+++ cfe/trunk/lib/Format/TokenAnnotator.cpp Mon Aug 14 09:08:16 2017
@@ -2367,13 +2367,20 @@ bool TokenAnnotator::spaceRequiredBefore
 Left.isOneOf(Keywords.kw_function, Keywords.kw_yield,
  Keywords.kw_extends, Keywords.kw_implements))
   return true;
-// JS methods can use some keywords as names (e.g. `delete()`).
-if (Right.is(tok::l_paren) && Line.MustBeDeclaration &&
-Left.Tok.getIdentifierInfo())
-  return false;
-if (Right.is(tok::l_paren) &&
-Left.isOneOf(tok::kw_throw, Keywords.kw_await, Keywords.kw_typeof, 
tok::kw_void))
-  return true;
+if (Right.is(tok::l_paren)) {
+  // JS methods can use some keywords as names (e.g. `delete()`).
+  if (Line.MustBeDeclaration && Left.Tok.getIdentifierInfo())
+return false;
+  // Valid JS method names can include keywords, e.g. `foo.delete()` or
+  // `bar.instanceof()`. Recognize call positions by preceding period.
+  if (Left.Previous && Left.Previous->is(tok::period) &&
+  Left.Tok.getIdentifierInfo())
+return false;
+  // Additional unary JavaScript operators that need a space after.
+  if (Left.isOneOf(tok::kw_throw, Keywords.kw_await, Keywords.kw_typeof,
+   tok::kw_void))
+return true;
+}
 if ((Left.isOneOf(Keywords.kw_let, Keywords.kw_var, Keywords.kw_in,
   tok::kw_const) ||
  // "of" is only a keyword if it appears after another identifier

Modified: cfe/trunk/unittests/Format/FormatTestJS.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTestJS.cpp?rev=310851=310850=310851=diff
==
--- cfe/trunk/unittests/Format/FormatTestJS.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTestJS.cpp Mon Aug 14 09:08:16 2017
@@ -271,14 +271,21 @@ TEST_F(FormatTestJS, ReservedWords) {
   verifyFormat("x.case = 1;");
   verifyFormat("x.interface = 1;");
   verifyFormat("x.for = 1;");
-  verifyFormat("x.of() = 1;");
+  verifyFormat("x.of();");
   verifyFormat("of(null);");
   verifyFormat("import {of} from 'x';");
-  verifyFormat("x.in() = 1;");
-  verifyFormat("x.let() = 1;");
-  verifyFormat("x.var() = 1;");
-  verifyFormat("x.for() = 1;");
-  verifyFormat("x.as() = 1;");
+  verifyFormat("x.in();");
+  verifyFormat("x.let();");
+  verifyFormat("x.var();");
+  verifyFormat("x.for();");
+  verifyFormat("x.as();");
+  verifyFormat("x.instanceof();");
+  verifyFormat("x.switch();");
+  verifyFormat("x.case();");
+  verifyFormat("x.delete();");
+  verifyFormat("x.throw();");
+  verifyFormat("x.throws();");
+  verifyFormat("x.if();");
   verifyFormat("x = {\n"
"  a: 12,\n"
"  interface: 1,\n"
@@ -1228,7 +1235,6 @@ TEST_F(FormatTestJS, TryCatch) {
   // But, of course, "catch" is a perfectly fine function name in JavaScript.
   verifyFormat("someObject.catch();");
   verifyFormat("someObject.new();");
-  verifyFormat("someObject.delete();");
 }
 
 TEST_F(FormatTestJS, StringLiteralConcatenation) {


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


[PATCH] D36688: [clang-diff] Fix matching for unnamed NamedDecs

2017-08-14 Thread Johannes Altmanninger via Phabricator via cfe-commits
johannes created this revision.
Herald added a subscriber: klimek.

This makes Node::getIdentifier return a valid value for special
NamedDecl nodes that do not have a name, such as ctors, dtors
and unnamed classes / namespaces.


https://reviews.llvm.org/D36688

Files:
  lib/Tooling/ASTDiff/ASTDiff.cpp
  test/Tooling/clang-diff-heuristics.cpp


Index: test/Tooling/clang-diff-heuristics.cpp
===
--- test/Tooling/clang-diff-heuristics.cpp
+++ test/Tooling/clang-diff-heuristics.cpp
@@ -10,6 +10,8 @@
 
 void f2(int) {;}
 
+class C3 { C3(); };
+
 #else
 
 // same parents, same value
@@ -22,4 +24,8 @@
 // CHECK: Match CompoundStmt
 void f2() {}
 
+// same parents, same identifier
+// CHECK: Match CXXConstructorDecl: :C3(void ())(9) to CXXConstructorDecl: 
:C3(void (int))(6)
+class C3 { C3(int); };
+
 #endif
Index: lib/Tooling/ASTDiff/ASTDiff.cpp
===
--- lib/Tooling/ASTDiff/ASTDiff.cpp
+++ lib/Tooling/ASTDiff/ASTDiff.cpp
@@ -384,8 +384,7 @@
   // Strip the qualifier, if Val refers to somthing in the current scope.
   // But leave one leading ':' in place, so that we know that this is a
   // relative path.
-  if (!ContextPrefix.empty() &&
-  StringRef(Val).startswith(ContextPrefix))
+  if (!ContextPrefix.empty() && StringRef(Val).startswith(ContextPrefix))
 Val = Val.substr(ContextPrefix.size() + 1);
   return Val;
 }
@@ -715,14 +714,18 @@
   if (auto *ND = ASTNode.get()) {
 if (ND->getDeclName().isIdentifier())
   return ND->getQualifiedNameAsString();
+else
+  return std::string();
   }
   return llvm::None;
 }
 
 llvm::Optional Node::getIdentifier() const {
   if (auto *ND = ASTNode.get()) {
 if (ND->getDeclName().isIdentifier())
   return ND->getName();
+else
+  return StringRef();
   }
   return llvm::None;
 }


Index: test/Tooling/clang-diff-heuristics.cpp
===
--- test/Tooling/clang-diff-heuristics.cpp
+++ test/Tooling/clang-diff-heuristics.cpp
@@ -10,6 +10,8 @@
 
 void f2(int) {;}
 
+class C3 { C3(); };
+
 #else
 
 // same parents, same value
@@ -22,4 +24,8 @@
 // CHECK: Match CompoundStmt
 void f2() {}
 
+// same parents, same identifier
+// CHECK: Match CXXConstructorDecl: :C3(void ())(9) to CXXConstructorDecl: :C3(void (int))(6)
+class C3 { C3(int); };
+
 #endif
Index: lib/Tooling/ASTDiff/ASTDiff.cpp
===
--- lib/Tooling/ASTDiff/ASTDiff.cpp
+++ lib/Tooling/ASTDiff/ASTDiff.cpp
@@ -384,8 +384,7 @@
   // Strip the qualifier, if Val refers to somthing in the current scope.
   // But leave one leading ':' in place, so that we know that this is a
   // relative path.
-  if (!ContextPrefix.empty() &&
-  StringRef(Val).startswith(ContextPrefix))
+  if (!ContextPrefix.empty() && StringRef(Val).startswith(ContextPrefix))
 Val = Val.substr(ContextPrefix.size() + 1);
   return Val;
 }
@@ -715,14 +714,18 @@
   if (auto *ND = ASTNode.get()) {
 if (ND->getDeclName().isIdentifier())
   return ND->getQualifiedNameAsString();
+else
+  return std::string();
   }
   return llvm::None;
 }
 
 llvm::Optional Node::getIdentifier() const {
   if (auto *ND = ASTNode.get()) {
 if (ND->getDeclName().isIdentifier())
   return ND->getName();
+else
+  return StringRef();
   }
   return llvm::None;
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D36687: [clang-diff] Match nodes with the same parent and same value

2017-08-14 Thread Johannes Altmanninger via Phabricator via cfe-commits
johannes created this revision.

This adds another pass to the matching algorithm that tries to match nodes with
common parents, if they have similar values.


https://reviews.llvm.org/D36687

Files:
  include/clang/Tooling/ASTDiff/ASTDiff.h
  lib/Tooling/ASTDiff/ASTDiff.cpp
  test/Tooling/clang-diff-bottomup.cpp
  test/Tooling/clang-diff-heuristics.cpp
  test/Tooling/clang-diff-opt.cpp
  tools/clang-diff/ClangDiff.cpp

Index: tools/clang-diff/ClangDiff.cpp
===
--- tools/clang-diff/ClangDiff.cpp
+++ tools/clang-diff/ClangDiff.cpp
@@ -535,7 +535,9 @@
   if (!StopAfter.empty()) {
 if (StopAfter == "topdown")
   Options.StopAfterTopDown = true;
-else if (StopAfter != "bottomup") {
+else if (StopAfter == "bottomup")
+  Options.StopAfterBottomUp = true;
+else {
   llvm::errs() << "Error: Invalid argument for -stop-after\n";
   return 1;
 }
Index: test/Tooling/clang-diff-opt.cpp
===
--- test/Tooling/clang-diff-opt.cpp
+++ test/Tooling/clang-diff-opt.cpp
@@ -1,6 +1,6 @@
 // RUN: %clang_cc1 -E %s > %t.src.cpp
 // RUN: %clang_cc1 -E %s > %t.dst.cpp -DDEST
-// RUN: clang-diff -dump-matches -s=10 %t.src.cpp %t.dst.cpp -- | FileCheck %s
+// RUN: clang-diff -dump-matches -s=10 -stop-after=bottomup %t.src.cpp %t.dst.cpp -- | FileCheck %s
 //
 // Test the behaviour of the matching according to the optimal tree edit
 // distance, implemented with Zhang and Shasha's algorithm.
@@ -41,5 +41,5 @@
   // CHECK: Delete NullStmt(22)
   ;; {{;;}}
 }
- 
+
 #endif
Index: test/Tooling/clang-diff-heuristics.cpp
===
--- /dev/null
+++ test/Tooling/clang-diff-heuristics.cpp
@@ -0,0 +1,25 @@
+// RUN: %clang_cc1 -E %s > %t.src.cpp
+// RUN: %clang_cc1 -E %s > %t.dst.cpp -DDEST
+// RUN: clang-diff -dump-matches -s=0 %t.src.cpp %t.dst.cpp -- | FileCheck %s
+//
+// Test the heuristics, with maxsize set to 0, so that the optimal matching will never be applied.
+
+#ifndef DEST
+
+void f1() {;}
+
+void f2(int) {;}
+
+#else
+
+// same parents, same value
+// CHECK: Match FunctionDecl: f1(void ())(1) to FunctionDecl: f1(void ())(1)
+// CHECK: Match CompoundStmt
+void f1() {}
+
+// same parents, same identifier
+// CHECK: Match FunctionDecl: f2(void (int))(4) to FunctionDecl: f2(void ())(3)
+// CHECK: Match CompoundStmt
+void f2() {}
+
+#endif
Index: test/Tooling/clang-diff-bottomup.cpp
===
--- test/Tooling/clang-diff-bottomup.cpp
+++ test/Tooling/clang-diff-bottomup.cpp
@@ -1,6 +1,6 @@
 // RUN: %clang_cc1 -E %s > %t.src.cpp
 // RUN: %clang_cc1 -E %s > %t.dst.cpp -DDEST
-// RUN: clang-diff -dump-matches -s=0 %t.src.cpp %t.dst.cpp -- | FileCheck %s
+// RUN: clang-diff -dump-matches -s=0 -stop-after=bottomup %t.src.cpp %t.dst.cpp -- | FileCheck %s
 //
 // Test the bottom-up matching, with maxsize set to 0, so that the optimal matching will never be applied.
 
Index: lib/Tooling/ASTDiff/ASTDiff.cpp
===
--- lib/Tooling/ASTDiff/ASTDiff.cpp
+++ lib/Tooling/ASTDiff/ASTDiff.cpp
@@ -94,15 +94,23 @@
   // Descendants are only considered to be equal when they are mapped in M.
   double getJaccardSimilarity(const Mapping , NodeId Id1, NodeId Id2) const;
 
+  double getNodeSimilarity(const Mapping , NodeId Id1, NodeId Id2) const;
+
   // Returns the node that has the highest degree of similarity.
   NodeId findCandidate(const Mapping , NodeId Id1) const;
 
+  NodeId findCandidateFromChildren(const Mapping , NodeId Id1,
+   NodeId P2) const;
+
   // Returns a mapping of identical subtrees.
   Mapping matchTopDown() const;
 
   // Tries to match any yet unmapped nodes, in a bottom-up fashion.
   void matchBottomUp(Mapping ) const;
 
+  // Matches nodes, whose parents are matched.
+  void matchChildren(Mapping );
+
   const ComparisonOptions 
 
   friend class ZhangShashaMatcher;
@@ -828,6 +836,23 @@
   return CommonDescendants / Denominator;
 }
 
+double ASTDiff::Impl::getNodeSimilarity(const Mapping , NodeId Id1,
+NodeId Id2) const {
+  const Node  = T1.getNode(Id1);
+  const Node  = T2.getNode(Id2);
+  auto Ident1 = N1.getIdentifier(), Ident2 = N2.getIdentifier();
+
+  bool SameValue = T1.getNodeValue(Id1) == T2.getNodeValue(Id2);
+  auto SameIdent = Ident1 && Ident2 && *Ident1 == *Ident2;
+
+  double NodeSimilarity = 0;
+  NodeSimilarity += SameValue;
+  NodeSimilarity += SameIdent;
+
+  assert(haveSameParents(M, Id1, Id2));
+  return NodeSimilarity * Options.MinSimilarity;
+}
+
 NodeId ASTDiff::Impl::findCandidate(const Mapping , NodeId Id1) const {
   NodeId Candidate;
   double HighestSimilarity = 0.0;
@@ -845,6 +870,25 @@
   return Candidate;
 }
 
+NodeId ASTDiff::Impl::findCandidateFromChildren(const Mapping , NodeId Id1,
+

[PATCH] D36686: [clang-diff] Add option to compare files across git revisions

2017-08-14 Thread Johannes Altmanninger via Phabricator via cfe-commits
johannes created this revision.

This adds a command line option "-git-rev=".
When it is used, only one filename is accepted.  The file in its version
in the specified revision is compared against the current version. Note
that this calls `git checkout` in the current directory.


https://reviews.llvm.org/D36686

Files:
  tools/clang-diff/ClangDiff.cpp

Index: tools/clang-diff/ClangDiff.cpp
===
--- tools/clang-diff/ClangDiff.cpp
+++ tools/clang-diff/ClangDiff.cpp
@@ -16,6 +16,7 @@
 #include "clang/Tooling/CommonOptionsParser.h"
 #include "clang/Tooling/Tooling.h"
 #include "llvm/Support/CommandLine.h"
+#include "llvm/Support/Program.h"
 
 using namespace llvm;
 using namespace clang;
@@ -33,9 +34,9 @@
 cl::desc("Print the internal representation of the AST as JSON."),
 cl::init(false), cl::cat(ClangDiffCategory));
 
-static cl::opt
-PrintMatches("dump-matches", cl::desc("Print the matched nodes."),
- cl::init(false), cl::cat(ClangDiffCategory));
+static cl::opt PrintMatches("dump-matches",
+  cl::desc("Print the matched nodes."),
+  cl::init(false), cl::cat(ClangDiffCategory));
 
 static cl::opt HtmlDiff("html",
   cl::desc("Output a side-by-side diff in HTML."),
@@ -55,6 +56,11 @@
   cl::Optional, cl::init(""),
   cl::cat(ClangDiffCategory));
 
+static cl::opt
+GitRevision("git-rev", cl::desc("Compare the file from a checkout of this "
+"revision with the current version."),
+cl::Optional, cl::init(""), cl::cat(ClangDiffCategory));
+
 static cl::opt MaxSize("s", cl::desc(""), cl::Optional,
 cl::init(-1), cl::cat(ClangDiffCategory));
 
@@ -438,6 +444,19 @@
   }
 }
 
+std::string Exec(const char *Command) {
+  char Buffer[128];
+  std::string Result;
+  std::shared_ptr Pipe(popen(Command, "r"), pclose);
+  if (!Pipe)
+return Result;
+  while (!feof(Pipe.get())) {
+if (fgets(Buffer, 128, Pipe.get()) != nullptr)
+  Result += Buffer;
+  }
+  return Result;
+}
+
 int main(int argc, const char **argv) {
   std::string ErrorMessage;
   std::unique_ptr CommonCompilations =
@@ -473,13 +492,40 @@
 return 0;
   }
 
-  if (DestinationPath.empty()) {
+  if (DestinationPath.empty() && GitRevision.empty()) {
 llvm::errs() << "Error: Exactly two paths are required.\n";
 return 1;
   }
 
-  std::unique_ptr Src = getAST(CommonCompilations, SourcePath);
-  std::unique_ptr Dst = getAST(CommonCompilations, DestinationPath);
+  std::unique_ptr Src, Dst;
+
+  if (!GitRevision.empty()) {
+std::string CurrentRevision, Git;
+auto ErrorOrGit = llvm::sys::findProgramByName("git");
+if (!ErrorOrGit) {
+  llvm::errs() << "Error: Could not find git executable.\n";
+  return 1;
+}
+Git = ErrorOrGit.get();
+CurrentRevision = Exec("git rev-parse HEAD");
+*std::find(CurrentRevision.begin(), CurrentRevision.end(), '\n') = '\0';
+const char *Checkout[] = {"git", "checkout", GitRevision.data(), nullptr};
+if (llvm::sys::ExecuteAndWait(Git, Checkout)) {
+  llvm::errs() << "Error: Failed to checkout " << GitRevision << "\n";
+  return 1;
+}
+Src = getAST(CommonCompilations, SourcePath);
+Checkout[2] = CurrentRevision.data();
+if (llvm::sys::ExecuteAndWait(Git, Checkout)) {
+  llvm::errs() << "Error: Failed to checkout " << CurrentRevision << "\n";
+  return 1;
+}
+Dst = getAST(CommonCompilations, SourcePath);
+  } else {
+Src = getAST(CommonCompilations, SourcePath);
+Dst = getAST(CommonCompilations, DestinationPath);
+  }
+
   if (!Src || !Dst)
 return 1;
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D36142: clang-format: [JS] do not insert whitespace in call positions.

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

Looks good.


https://reviews.llvm.org/D36142



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


[PATCH] D36684: clang-format: [JS] wrap optional properties in type aliases.

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

Looks good.


https://reviews.llvm.org/D36684



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


r310850 - [OPENMP][DEBUG] Fix for PR33676: Debug info for OpenMP region is broken.

2017-08-14 Thread Alexey Bataev via cfe-commits
Author: abataev
Date: Mon Aug 14 09:03:47 2017
New Revision: 310850

URL: http://llvm.org/viewvc/llvm-project?rev=310850=rev
Log:
[OPENMP][DEBUG] Fix for PR33676: Debug info for OpenMP region is broken.

After some changes in clang/LLVM debug info for task-based regions was
not generated at all. Patch fixes this problem.

Modified:
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
cfe/trunk/test/OpenMP/taskloop_reduction_codegen.cpp

Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp?rev=310850=310849=310850=diff
==
--- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp Mon Aug 14 09:03:47 2017
@@ -3790,7 +3790,6 @@ emitProxyTaskFunction(CodeGenModule 
  ".omp_task_entry.", ());
   CGM.SetInternalFunctionAttributes(/*D=*/nullptr, TaskEntry, TaskEntryFnInfo);
   CodeGenFunction CGF(CGM);
-  CGF.disableDebugInfo();
   CGF.StartFunction(GlobalDecl(), KmpInt32Ty, TaskEntry, TaskEntryFnInfo, 
Args);
 
   // TaskFunction(gtid, tt->task_data.part_id, >privates, 
task_privates_map,

Modified: cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp?rev=310850=310849=310850=diff
==
--- cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp Mon Aug 14 09:03:47 2017
@@ -342,8 +342,8 @@ static llvm::Function *emitOutlinedFunct
 F->setDoesNotThrow();
 
   // Generate the function.
-  CGF.StartFunction(CD, Ctx.VoidTy, F, FuncInfo, TargetArgs, CD->getLocation(),
-CD->getBody()->getLocStart());
+  CGF.StartFunction(CD, Ctx.VoidTy, F, FuncInfo, TargetArgs,
+FO.S->getLocStart(), CD->getBody()->getLocStart());
   unsigned Cnt = CD->getContextParamPosition();
   I = FO.S->captures().begin();
   for (auto *FD : RD->fields()) {

Modified: cfe/trunk/test/OpenMP/taskloop_reduction_codegen.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/taskloop_reduction_codegen.cpp?rev=310850=310849=310850=diff
==
--- cfe/trunk/test/OpenMP/taskloop_reduction_codegen.cpp (original)
+++ cfe/trunk/test/OpenMP/taskloop_reduction_codegen.cpp Mon Aug 14 09:03:47 
2017
@@ -143,7 +143,7 @@ sum = 0.0;
 // CHECK:[[DIV:%.*]] = sdiv i32 [[ADD11]], 1
 // CHECK:[[SUB12:%.*]] = sub nsw i32 [[DIV]], 1
 // CHECK:store i32 [[SUB12]], i32* [[DOTCAPTURE_EXPR_9]],
-// CHECK:[[TMP65:%.*]] = call i8* @__kmpc_omp_task_alloc(%ident_t* 
%{{.+}}, i32 [[TMP0]], i32 1, i64 888, i64 72, i32 (i32, i8*)* bitcast (i32 
(i32, %struct.kmp_task_t_with_privates*)* @{{.+}} to i32 (i32, i8*)*))
+// CHECK:[[TMP65:%.*]] = call i8* @__kmpc_omp_task_alloc(%ident_t* 
%{{.+}}, i32 [[TMP0]], i32 1, i64 888, i64 72, i32 (i32, i8*)* bitcast (i32 
(i32, %struct.kmp_task_t_with_privates*)* @[[TASK:.+]] to i32 (i32, i8*)*))
 // CHECK:call void @__kmpc_taskloop(%ident_t* %{{.+}}, i32 [[TMP0]], i8* 
[[TMP65]], i32 1, i64* %{{.+}}, i64* %{{.+}}, i64 %{{.+}}, i32 0, i32 0, i64 0, 
i8* null)
 // CHECK:call void @__kmpc_end_taskgroup(%ident_t*
 
@@ -195,3 +195,4 @@ sum = 0.0;
 // CHECK: store float %{{.+}}, float* %
 // CHECK: ret void
 
+// CHECK: distinct !DISubprogram(linkageName: "[[TASK]]", scope: !


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


[PATCH] D36685: [clang-diff] HTML diff navigation

2017-08-14 Thread Johannes Altmanninger via Phabricator via cfe-commits
johannes created this revision.

This adds shortcuts j and k to jump between changes.
It is especially useful in diffs with few changes.


https://reviews.llvm.org/D36685

Files:
  tools/clang-diff/ClangDiff.cpp


Index: tools/clang-diff/ClangDiff.cpp
===
--- tools/clang-diff/ClangDiff.cpp
+++ tools/clang-diff/ClangDiff.cpp
@@ -145,34 +145,79 @@
 highlightStack = []
 function clearHighlight() {
   while (highlightStack.length) {
-let [l, r] = highlightStack.pop()
+var [l, r] = highlightStack.pop()
 document.getElementById(l).style.backgroundColor = 'white'
-document.getElementById(r).style.backgroundColor = 'white'
+if (r[1] != '-')
+  document.getElementById(r).style.backgroundColor = 'white'
   }
 }
 function highlight(event) {
-  id = event.target['id']
+  var id = event.target['id']
   doHighlight(id)
 }
 function doHighlight(id) {
   clearHighlight()
   source = document.getElementById(id)
   if (!source.attributes['tid'])
 return
-  tid = source.attributes['tid'].value
-  target = document.getElementById(tid)
-  if (!target || source.parentElement && 
source.parentElement.classList.contains('code'))
+  var mapped = source
+  while (mapped && mapped.parentElement && 
mapped.attributes['tid'].value.substr(1) === '-1')
+mapped = mapped.parentElement
+  var tid = null, target = null
+  if (mapped) {
+tid = mapped.attributes['tid'].value
+target = document.getElementById(tid)
+  }
+  if (source.parentElement && source.parentElement.classList.contains('code'))
 return
-  source.style.backgroundColor = target.style.backgroundColor = 'lightgrey'
-  highlightStack.push([id, tid])
+  source.style.backgroundColor = 'lightgrey'
   source.scrollIntoView()
-  target.scrollIntoView()
+  if (target) {
+if (mapped === source)
+  target.style.backgroundColor = 'lightgrey'
+target.scrollIntoView()
+  }
+  highlightStack.push([id, tid])
   location.hash = '#' + id
 }
 function scrollToBoth() {
   doHighlight(location.hash.substr(1))
 }
+function nextWithoutClass(prefix, increment, number) {
+  do {
+number += increment
+var elem = document.getElementById(prefix + number)
+  } while(elem && elem.classList.length == 0)
+  return elem ? number : null
+}
+function handleKey(e) {
+  var down = e.code === "KeyJ"
+  var up = e.code === "KeyK"
+  if (!down && !up)
+return
+  var id = highlightStack[0] ? highlightStack[0][0] : 'R0'
+  var oldelem = document.getElementById(id)
+  var number = parseInt(id.substr(1))
+  var increment = down ? 1 : -1
+  var lastnumber = number
+  var prefix = id[0]
+  do {
+number = nextWithoutClass(prefix, increment, number)
+var elem = document.getElementById(prefix + number)
+if (up && elem) {
+  while (elem.parentElement && elem.parentElement.classList.length != 0) {
+elem = elem.parentElement
+number = elem.id.substr(1)
+  }
+}
+  } while ((down && id !== 'R0' && oldelem.contains(elem)))
+  if (!number)
+number = lastnumber
+  elem = document.getElementById(prefix + number)
+  doHighlight(prefix + number)
+}
 window.onload = scrollToBoth
+window.onkeydown = handleKey
 
 
 


Index: tools/clang-diff/ClangDiff.cpp
===
--- tools/clang-diff/ClangDiff.cpp
+++ tools/clang-diff/ClangDiff.cpp
@@ -145,34 +145,79 @@
 highlightStack = []
 function clearHighlight() {
   while (highlightStack.length) {
-let [l, r] = highlightStack.pop()
+var [l, r] = highlightStack.pop()
 document.getElementById(l).style.backgroundColor = 'white'
-document.getElementById(r).style.backgroundColor = 'white'
+if (r[1] != '-')
+  document.getElementById(r).style.backgroundColor = 'white'
   }
 }
 function highlight(event) {
-  id = event.target['id']
+  var id = event.target['id']
   doHighlight(id)
 }
 function doHighlight(id) {
   clearHighlight()
   source = document.getElementById(id)
   if (!source.attributes['tid'])
 return
-  tid = source.attributes['tid'].value
-  target = document.getElementById(tid)
-  if (!target || source.parentElement && source.parentElement.classList.contains('code'))
+  var mapped = source
+  while (mapped && mapped.parentElement && mapped.attributes['tid'].value.substr(1) === '-1')
+mapped = mapped.parentElement
+  var tid = null, target = null
+  if (mapped) {
+tid = mapped.attributes['tid'].value
+target = document.getElementById(tid)
+  }
+  if (source.parentElement && source.parentElement.classList.contains('code'))
 return
-  source.style.backgroundColor = target.style.backgroundColor = 'lightgrey'
-  highlightStack.push([id, tid])
+  source.style.backgroundColor = 'lightgrey'
   source.scrollIntoView()
-  target.scrollIntoView()
+  if (target) {
+if (mapped === source)
+  target.style.backgroundColor = 'lightgrey'
+target.scrollIntoView()
+  }
+  highlightStack.push([id, tid])
   location.hash = 

Re: r310516 - Make -std=c++17 an alias of -std=c++1z

2017-08-14 Thread Hans Wennborg via cfe-commits
Merged in r310848.

On Wed, Aug 9, 2017 at 1:12 PM, Hans Wennborg via cfe-commits
 wrote:
> Author: hans
> Date: Wed Aug  9 13:12:53 2017
> New Revision: 310516
>
> URL: http://llvm.org/viewvc/llvm-project?rev=310516=rev
> Log:
> Make -std=c++17 an alias of -std=c++1z
>
> As suggested on PR33912.
>
> Trying to keep this small to make it easy to merge to the 5.0 branch. We
> can do a follow-up with more thorough renaming (diagnostic text,
> options, ids, etc.) later.
>
> (For C++14 this was done in r215982, and I think a smaller patch for the
> 3.5 branch:
> http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20140818/113013.html)
>
> Differential Revision: https://reviews.llvm.org/D36532
>
> Modified:
> cfe/trunk/include/clang/Frontend/LangStandards.def
> cfe/trunk/test/Driver/unknown-std.cpp
> cfe/trunk/test/SemaCXX/cxx1z-init-statement.cpp
>
> Modified: cfe/trunk/include/clang/Frontend/LangStandards.def
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/LangStandards.def?rev=310516=310515=310516=diff
> ==
> --- cfe/trunk/include/clang/Frontend/LangStandards.def (original)
> +++ cfe/trunk/include/clang/Frontend/LangStandards.def Wed Aug  9 13:12:53 
> 2017
> @@ -109,15 +109,17 @@ LANGSTANDARD(gnucxx14, "gnu++14",
>   GNUMode)
>  LANGSTANDARD_ALIAS_DEPR(gnucxx14, "gnu++1y")
>
> -LANGSTANDARD(cxx1z, "c++1z",
> - CXX, "Working draft for ISO C++ 2017",
> +LANGSTANDARD(cxx17, "c++17",
> + CXX, "ISO C++ 2017 with amendments",
>   LineComment | CPlusPlus | CPlusPlus11 | CPlusPlus14 | 
> CPlusPlus1z |
>   Digraphs | HexFloat)
> +LANGSTANDARD_ALIAS_DEPR(cxx17, "c++1z")
>
> -LANGSTANDARD(gnucxx1z, "gnu++1z",
> - CXX, "Working draft for ISO C++ 2017 with GNU extensions",
> +LANGSTANDARD(gnucxx17, "gnu++17",
> + CXX, "ISO C++ 2017 with amendments and GNU extensions",
>   LineComment | CPlusPlus | CPlusPlus11 | CPlusPlus14 | 
> CPlusPlus1z |
>   Digraphs | HexFloat | GNUMode)
> +LANGSTANDARD_ALIAS_DEPR(gnucxx17, "gnu++1z")
>
>  LANGSTANDARD(cxx2a, "c++2a",
>   CXX, "Working draft for ISO C++ 2020",
>
> Modified: cfe/trunk/test/Driver/unknown-std.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/unknown-std.cpp?rev=310516=310515=310516=diff
> ==
> --- cfe/trunk/test/Driver/unknown-std.cpp (original)
> +++ cfe/trunk/test/Driver/unknown-std.cpp Wed Aug  9 13:12:53 2017
> @@ -13,8 +13,8 @@
>  // CHECK-NEXT: note: use 'gnu++11' for 'ISO C++ 2011 with amendments and GNU 
> extensions' standard
>  // CHECK-NEXT: note: use 'c++14' for 'ISO C++ 2014 with amendments' standard
>  // CHECK-NEXT: note: use 'gnu++14' for 'ISO C++ 2014 with amendments and GNU 
> extensions' standard
> -// CHECK-NEXT: note: use 'c++1z' for 'Working draft for ISO C++ 2017' 
> standard
> -// CHECK-NEXT: note: use 'gnu++1z' for 'Working draft for ISO C++ 2017 with 
> GNU extensions' standard
> +// CHECK-NEXT: note: use 'c++17' for 'ISO C++ 2017 with amendments' standard
> +// CHECK-NEXT: note: use 'gnu++17' for 'ISO C++ 2017 with amendments and GNU 
> extensions' standard
>  // CHECK-NEXT: note: use 'c++2a' for 'Working draft for ISO C++ 2020' 
> standard
>  // CHECK-NEXT: note: use 'gnu++2a' for 'Working draft for ISO C++ 2020 with 
> GNU extensions' standard
>  // CUDA-NEXT: note: use 'cuda' for 'NVIDIA CUDA(tm)' standard
>
> Modified: cfe/trunk/test/SemaCXX/cxx1z-init-statement.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/cxx1z-init-statement.cpp?rev=310516=310515=310516=diff
> ==
> --- cfe/trunk/test/SemaCXX/cxx1z-init-statement.cpp (original)
> +++ cfe/trunk/test/SemaCXX/cxx1z-init-statement.cpp Wed Aug  9 13:12:53 2017
> @@ -1,4 +1,5 @@
>  // RUN: %clang_cc1 -std=c++1z -verify %s
> +// RUN: %clang_cc1 -std=c++17 -verify %s
>
>  void testIf() {
>int x = 0;
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D36684: clang-format: [JS] wrap optional properties in type aliases.

2017-08-14 Thread Martin Probst via Phabricator via cfe-commits
mprobst created this revision.
Herald added a subscriber: klimek.

clang-format wraps object literal keys in an object literal if they are
marked as `TT_SelectorName`s and/or the colon is marked as
`TT_DictLiteral`. Previously, clang-format would accidentally work
because colons in type aliases were marked as `TT_DictLiteral`. r310367
fixed this to assing `TT_JsTypeColon`, which broke wrapping in certain
situations. However the root cause was that clang-format incorrectly
didn't skip questionmarks when detecting selector name.

This change fixes both locations to (1) assign `TT_SelectorName` and (2)
treat `TT_JsTypeColon` like `TT_DictLiteral`.

Previously:

  type X = {
a: string, b?: string,
  };

Now:

  type X = {
a: string,
b?: string,
  };


https://reviews.llvm.org/D36684

Files:
  lib/Format/TokenAnnotator.cpp
  unittests/Format/FormatTestJS.cpp


Index: unittests/Format/FormatTestJS.cpp
===
--- unittests/Format/FormatTestJS.cpp
+++ unittests/Format/FormatTestJS.cpp
@@ -1555,6 +1555,10 @@
"  y: number\n"
"};\n"
"class C {}");
+  verifyFormat("export type X = {\n"
+   "  a: string,\n"
+   "  b?: string,\n"
+   "};\n");
 }
 
 TEST_F(FormatTestJS, TypeInterfaceLineWrapping) {
Index: lib/Format/TokenAnnotator.cpp
===
--- lib/Format/TokenAnnotator.cpp
+++ lib/Format/TokenAnnotator.cpp
@@ -459,6 +459,8 @@
 updateParameterCount(Left, CurrentToken);
 if (CurrentToken->isOneOf(tok::colon, tok::l_brace, tok::less)) {
   FormatToken *Previous = CurrentToken->getPreviousNonComment();
+  if (Previous->is(TT_JsTypeOptionalQuestion))
+Previous = Previous->getPreviousNonComment();
   if (((CurrentToken->is(tok::colon) &&
 (!Contexts.back().ColonIsDictLiteral || !Style.isCpp())) ||
Style.Language == FormatStyle::LK_Proto ||
@@ -1601,7 +1603,7 @@
   if (Current->is(TT_ConditionalExpr))
 return prec::Conditional;
   if (NextNonComment && Current->is(TT_SelectorName) &&
-  (NextNonComment->is(TT_DictLiteral) ||
+  (NextNonComment->isOneOf(TT_DictLiteral, TT_JsTypeColon) ||
((Style.Language == FormatStyle::LK_Proto ||
  Style.Language == FormatStyle::LK_TextProto) &&
 NextNonComment->is(tok::less


Index: unittests/Format/FormatTestJS.cpp
===
--- unittests/Format/FormatTestJS.cpp
+++ unittests/Format/FormatTestJS.cpp
@@ -1555,6 +1555,10 @@
"  y: number\n"
"};\n"
"class C {}");
+  verifyFormat("export type X = {\n"
+   "  a: string,\n"
+   "  b?: string,\n"
+   "};\n");
 }
 
 TEST_F(FormatTestJS, TypeInterfaceLineWrapping) {
Index: lib/Format/TokenAnnotator.cpp
===
--- lib/Format/TokenAnnotator.cpp
+++ lib/Format/TokenAnnotator.cpp
@@ -459,6 +459,8 @@
 updateParameterCount(Left, CurrentToken);
 if (CurrentToken->isOneOf(tok::colon, tok::l_brace, tok::less)) {
   FormatToken *Previous = CurrentToken->getPreviousNonComment();
+  if (Previous->is(TT_JsTypeOptionalQuestion))
+Previous = Previous->getPreviousNonComment();
   if (((CurrentToken->is(tok::colon) &&
 (!Contexts.back().ColonIsDictLiteral || !Style.isCpp())) ||
Style.Language == FormatStyle::LK_Proto ||
@@ -1601,7 +1603,7 @@
   if (Current->is(TT_ConditionalExpr))
 return prec::Conditional;
   if (NextNonComment && Current->is(TT_SelectorName) &&
-  (NextNonComment->is(TT_DictLiteral) ||
+  (NextNonComment->isOneOf(TT_DictLiteral, TT_JsTypeColon) ||
((Style.Language == FormatStyle::LK_Proto ||
  Style.Language == FormatStyle::LK_TextProto) &&
 NextNonComment->is(tok::less
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D36327: [OpenCL] Allow targets emit optimized pipe functions for power of 2 type sizes

2017-08-14 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

In https://reviews.llvm.org/D36327#840658, @bader wrote:

> In https://reviews.llvm.org/D36327#840616, @yaxunl wrote:
>
> > In https://reviews.llvm.org/D36327#839809, @rjmccall wrote:
> >
> > > Could you just implement this in SimplifyLibCalls?  I assume there's some 
> > > way to fill in TargetLibraryInfo appropriately for a platform.  Is that 
> > > too late for your linking requirements?
> >
> >
> > Both the optimized and generic versions of __read_pipe function contains 
> > call of other library functions and are complicate enough not to be 
> > generated programmatically. amdgpu target does not have the capability to 
> > link in library code after LLVM codegen. The linking has to be done before 
> > SimplifyLibCalls.
>
>
> If I understand correctly, SimplifyLibCalls is LLVM IR transformation, so it 
> works before linking and LLVM codegen (e.g. InstCombine passes run this 
> transformation). This pass is doing something similar to what you are trying 
> to achieve for __read_pipe builti-ins: pow(2.0, x) -> llvm.exp2(x).


Thanks. I will take a look.


https://reviews.llvm.org/D36327



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


[PATCH] D35670: [StaticAnalyzer] Handle LoopExit CFGElement in the analyzer

2017-08-14 Thread Peter Szecsi via Phabricator via cfe-commits
szepet added inline comments.



Comment at: include/clang/Analysis/ProgramPoint.h:658
 
+class LoopExit : public ProgramPoint {
+public:

dcoughlin wrote:
> Can you add a comment explaining what meaning of this program point is.
Can you help me with that? I am not sure what is important to say about this 
point to understand it better than from its name.



Comment at: lib/StaticAnalyzer/Core/CoreEngine.cpp:586
 
+  if ((*Block)[Idx].getKind() == CFGElement::LoopExit) {
+WList->enqueue(N, Block, Idx+1);

dcoughlin wrote:
> I'm surprised both this and the checks for N's location above are needed. How 
> does this arise?
We don't need both of the checks, I just left it by mistake.


https://reviews.llvm.org/D35670



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


[PATCH] D35670: [StaticAnalyzer] Handle LoopExit CFGElement in the analyzer

2017-08-14 Thread Peter Szecsi via Phabricator via cfe-commits
szepet updated this revision to Diff 110981.
szepet marked an inline comment as done.
szepet added a comment.

Updates based on comments.


https://reviews.llvm.org/D35670

Files:
  include/clang/Analysis/ProgramPoint.h
  include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
  lib/StaticAnalyzer/Core/CoreEngine.cpp
  lib/StaticAnalyzer/Core/ExprEngine.cpp

Index: lib/StaticAnalyzer/Core/ExprEngine.cpp
===
--- lib/StaticAnalyzer/Core/ExprEngine.cpp
+++ lib/StaticAnalyzer/Core/ExprEngine.cpp
@@ -364,8 +364,10 @@
 case CFGElement::TemporaryDtor:
   ProcessImplicitDtor(E.castAs(), Pred);
   return;
-case CFGElement::LifetimeEnds:
 case CFGElement::LoopExit:
+  ProcessLoopExit(E.castAs().getLoopStmt(), Pred);
+  return;
+case CFGElement::LifetimeEnds:
   return;
   }
 }
@@ -510,6 +512,21 @@
   Engine.enqueue(Dst, currBldrCtx->getBlock(), currStmtIdx);
 }
 
+void ExprEngine::ProcessLoopExit(const Stmt* S, ExplodedNode *Pred) {
+  PrettyStackTraceLoc CrashInfo(getContext().getSourceManager(),
+S->getLocStart(),
+"Error evaluating end of the loop");
+  ExplodedNodeSet Dst;
+  Dst.Add(Pred);
+  NodeBuilder Bldr(Pred, Dst, *currBldrCtx);
+
+  LoopExit PP(S, Pred->getLocationContext());
+  Bldr.generateNode(PP, Pred->getState(), Pred);
+
+  // Enqueue the new nodes onto the work list.
+  Engine.enqueue(Dst, currBldrCtx->getBlock(), currStmtIdx);
+}
+
 void ExprEngine::ProcessInitializer(const CFGInitializer Init,
 ExplodedNode *Pred) {
   const CXXCtorInitializer *BMI = Init.getInitializer();
@@ -2689,6 +2706,12 @@
 Out << "Epsilon Point";
 break;
 
+  case ProgramPoint::LoopExitKind: {
+LoopExit LE = Loc.castAs();
+Out << "LoopExit: " << LE.getLoopStmt()->getStmtClassName();
+break;
+  }
+
   case ProgramPoint::PreImplicitCallKind: {
 ImplicitCallPoint PC = Loc.castAs();
 Out << "PreCall: ";
Index: lib/StaticAnalyzer/Core/CoreEngine.cpp
===
--- lib/StaticAnalyzer/Core/CoreEngine.cpp
+++ lib/StaticAnalyzer/Core/CoreEngine.cpp
@@ -274,7 +274,8 @@
   assert(Loc.getAs() ||
  Loc.getAs() ||
  Loc.getAs() ||
- Loc.getAs());
+ Loc.getAs() ||
+ Loc.getAs());
   HandlePostStmt(WU.getBlock(), WU.getIndex(), Pred);
   break;
   }
@@ -566,7 +567,8 @@
 
   // Do not create extra nodes. Move to the next CFG element.
   if (N->getLocation().getAs() ||
-  N->getLocation().getAs()) {
+  N->getLocation().getAs()||
+  N->getLocation().getAs()) {
 WList->enqueue(N, Block, Idx+1);
 return;
   }
Index: include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
===
--- include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
+++ include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
@@ -196,6 +196,8 @@
 
   void ProcessStmt(const CFGStmt S, ExplodedNode *Pred);
 
+  void ProcessLoopExit(const Stmt* S, ExplodedNode *Pred);
+
   void ProcessInitializer(const CFGInitializer I, ExplodedNode *Pred);
 
   void ProcessImplicitDtor(const CFGImplicitDtor D, ExplodedNode *Pred);
Index: include/clang/Analysis/ProgramPoint.h
===
--- include/clang/Analysis/ProgramPoint.h
+++ include/clang/Analysis/ProgramPoint.h
@@ -83,6 +83,7 @@
   PostImplicitCallKind,
   MinImplicitCallKind = PreImplicitCallKind,
   MaxImplicitCallKind = PostImplicitCallKind,
+  LoopExitKind,
   EpsilonKind};
 
 private:
@@ -654,6 +655,24 @@
   }
 };
 
+/// Represents a point when we exit a loop.
+class LoopExit : public ProgramPoint {
+public:
+LoopExit(const Stmt *LoopStmt, const LocationContext *LC)
+: ProgramPoint(LoopStmt, nullptr, LoopExitKind, LC) {}
+
+const Stmt *getLoopStmt() const {
+  return static_cast(getData1());
+}
+
+private:
+friend class ProgramPoint;
+LoopExit() {}
+static bool isKind(const ProgramPoint ) {
+  return Location.getKind() == LoopExitKind;
+}
+};
+
 /// This is a meta program point, which should be skipped by all the diagnostic
 /// reasoning etc.
 class EpsilonPoint : public ProgramPoint {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D36156: [rename] Introduce symbol occurrences

2017-08-14 Thread Haojian Wu via Phabricator via cfe-commits
hokein accepted this revision.
hokein added a comment.
This revision is now accepted and ready to land.

LGTM.




Comment at: include/clang/Tooling/Refactoring/Rename/SymbolName.h:19
+namespace clang {
+namespace tooling {
+

arphaman wrote:
> hokein wrote:
> > An off-topic thought: currently we put everything into `clang::tooling`, I 
> > think we might need a separate namespace e.g. `clang::tooling::refactoring` 
> > in the future? 
> That would be nice, I agree. Don't think it's in scope for this patch though, 
> maybe for https://reviews.llvm.org/D36075?
Sounds good. No need to do it in this patch.


Repository:
  rL LLVM

https://reviews.llvm.org/D36156



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


[PATCH] D36458: Fix crash when current lexer is nullptr

2017-08-14 Thread Ivan Donchevskii via Phabricator via cfe-commits
yvvan updated this revision to Diff 110978.
yvvan added a comment.

I have minimized the crash case and added simple test for it.


https://reviews.llvm.org/D36458

Files:
  lib/Parse/Parser.cpp
  test/Index/std-begin-error.cpp


Index: test/Index/std-begin-error.cpp
===
--- test/Index/std-begin-error.cpp
+++ test/Index/std-begin-error.cpp
@@ -0,0 +1,9 @@
+#ifndef RC_INVOKED
+#include 
+_STD_BEGIN
+}
+#endif /* RC_INVOKED */
+
+// RUN: env CINDEXTEST_EDITING=1 c-index-test -test-load-source-reparse 5 
local -std=c++14 %S\std-begin-error.cpp 2> %t.err
+// RUN: not FileCheck < %t.err %s
+// CHECK: Failure: libclang crashed
Index: lib/Parse/Parser.cpp
===
--- lib/Parse/Parser.cpp
+++ lib/Parse/Parser.cpp
@@ -516,8 +516,8 @@
 
   // Prime the lexer look-ahead.
   ConsumeToken();
-
-  PP.replayPreambleConditionalStack();
+  if (!PP.isCurrentLexer(nullptr))
+PP.replayPreambleConditionalStack();
 }
 
 void Parser::LateTemplateParserCleanupCallback(void *P) {


Index: test/Index/std-begin-error.cpp
===
--- test/Index/std-begin-error.cpp
+++ test/Index/std-begin-error.cpp
@@ -0,0 +1,9 @@
+#ifndef RC_INVOKED
+#include 
+_STD_BEGIN
+}
+#endif /* RC_INVOKED */
+
+// RUN: env CINDEXTEST_EDITING=1 c-index-test -test-load-source-reparse 5 local -std=c++14 %S\std-begin-error.cpp 2> %t.err
+// RUN: not FileCheck < %t.err %s
+// CHECK: Failure: libclang crashed
Index: lib/Parse/Parser.cpp
===
--- lib/Parse/Parser.cpp
+++ lib/Parse/Parser.cpp
@@ -516,8 +516,8 @@
 
   // Prime the lexer look-ahead.
   ConsumeToken();
-
-  PP.replayPreambleConditionalStack();
+  if (!PP.isCurrentLexer(nullptr))
+PP.replayPreambleConditionalStack();
 }
 
 void Parser::LateTemplateParserCleanupCallback(void *P) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D36156: [rename] Introduce symbol occurrences

2017-08-14 Thread Alex Lorenz via Phabricator via cfe-commits
arphaman updated this revision to Diff 110964.
arphaman marked an inline comment as done.
arphaman added a comment.

Use `takeOccurrences`


Repository:
  rL LLVM

https://reviews.llvm.org/D36156

Files:
  include/clang/Tooling/Refactoring/Rename/RenamingAction.h
  include/clang/Tooling/Refactoring/Rename/SymbolName.h
  include/clang/Tooling/Refactoring/Rename/SymbolOccurrences.h
  include/clang/Tooling/Refactoring/Rename/USRLocFinder.h
  lib/Tooling/Refactoring/CMakeLists.txt
  lib/Tooling/Refactoring/Rename/RenamingAction.cpp
  lib/Tooling/Refactoring/Rename/SymbolOccurrences.cpp
  lib/Tooling/Refactoring/Rename/USRLocFinder.cpp

Index: lib/Tooling/Refactoring/Rename/USRLocFinder.cpp
===
--- lib/Tooling/Refactoring/Rename/USRLocFinder.cpp
+++ lib/Tooling/Refactoring/Rename/USRLocFinder.cpp
@@ -23,6 +23,7 @@
 #include "clang/Lex/Lexer.h"
 #include "clang/Tooling/Core/Lookup.h"
 #include "clang/Tooling/Refactoring/RecursiveSymbolVisitor.h"
+#include "clang/Tooling/Refactoring/Rename/SymbolName.h"
 #include "clang/Tooling/Refactoring/Rename/USRFinder.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Support/Casting.h"
@@ -68,11 +69,9 @@
 
   // Non-visitors:
 
-  // \brief Returns a list of unique locations. Duplicate or overlapping
-  // locations are erroneous and should be reported!
-  const std::vector () const {
-return LocationsFound;
-  }
+  /// \brief Returns a set of unique symbol occurrences. Duplicate or
+  /// overlapping occurrences are erroneous and should be reported!
+  SymbolOccurrences takeOccurrences() { return std::move(Occurrences); }
 
 private:
   void checkAndAddLocation(SourceLocation Loc) {
@@ -82,17 +81,18 @@
 StringRef TokenName =
 Lexer::getSourceText(CharSourceRange::getTokenRange(BeginLoc, EndLoc),
  Context.getSourceManager(), Context.getLangOpts());
-size_t Offset = TokenName.find(PrevName);
+size_t Offset = TokenName.find(PrevName.getNamePieces()[0]);
 
 // The token of the source location we find actually has the old
 // name.
 if (Offset != StringRef::npos)
-  LocationsFound.push_back(BeginLoc.getLocWithOffset(Offset));
+  Occurrences.emplace_back(PrevName, SymbolOccurrence::MatchingSymbol,
+   BeginLoc.getLocWithOffset(Offset));
   }
 
   const std::set USRSet;
-  const std::string PrevName;
-  std::vector LocationsFound;
+  const SymbolName PrevName;
+  SymbolOccurrences Occurrences;
   const ASTContext 
 };
 
@@ -391,12 +391,11 @@
 
 } // namespace
 
-std::vector
-getLocationsOfUSRs(const std::vector , StringRef PrevName,
-   Decl *Decl) {
+SymbolOccurrences getOccurrencesOfUSRs(ArrayRef USRs,
+   StringRef PrevName, Decl *Decl) {
   USRLocFindingASTVisitor Visitor(USRs, PrevName, Decl->getASTContext());
   Visitor.TraverseDecl(Decl);
-  return Visitor.getLocationsFound();
+  return Visitor.takeOccurrences();
 }
 
 std::vector
Index: lib/Tooling/Refactoring/Rename/SymbolOccurrences.cpp
===
--- /dev/null
+++ lib/Tooling/Refactoring/Rename/SymbolOccurrences.cpp
@@ -0,0 +1,37 @@
+//===--- SymbolOccurrences.cpp - Clang refactoring library ===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "clang/Tooling/Refactoring/Rename/SymbolOccurrences.h"
+#include "clang/Tooling/Refactoring/Rename/SymbolName.h"
+#include "llvm/ADT/STLExtras.h"
+
+using namespace clang;
+using namespace tooling;
+
+SymbolOccurrence::SymbolOccurrence(const SymbolName , OccurrenceKind Kind,
+   ArrayRef Locations)
+: Kind(Kind) {
+  ArrayRef NamePieces = Name.getNamePieces();
+  assert(Locations.size() == NamePieces.size() &&
+ "mismatching number of locations and lengths");
+  assert(!Locations.empty() && "no locations");
+  if (Locations.size() == 1) {
+RangeOrNumRanges = SourceRange(
+Locations[0], Locations[0].getLocWithOffset(NamePieces[0].size()));
+return;
+  }
+  MultipleRanges = llvm::make_unique(Locations.size());
+  RangeOrNumRanges.setBegin(
+  SourceLocation::getFromRawEncoding(Locations.size()));
+  for (const auto  : llvm::enumerate(Locations)) {
+MultipleRanges[Loc.index()] = SourceRange(
+Loc.value(),
+Loc.value().getLocWithOffset(NamePieces[Loc.index()].size()));
+  }
+}
Index: lib/Tooling/Refactoring/Rename/RenamingAction.cpp
===
--- lib/Tooling/Refactoring/Rename/RenamingAction.cpp
+++ lib/Tooling/Refactoring/Rename/RenamingAction.cpp
@@ -24,14 +24,54 @@
 #include "clang/Tooling/Refactoring.h"
 

[PATCH] D36156: [rename] Introduce symbol occurrences

2017-08-14 Thread Alex Lorenz via Phabricator via cfe-commits
arphaman marked an inline comment as done.
arphaman added inline comments.



Comment at: lib/Tooling/Refactoring/Rename/USRLocFinder.cpp:398
   Visitor.TraverseDecl(Decl);
-  return Visitor.getLocationsFound();
+  return std::move(Visitor.getOccurrences());
 }

hokein wrote:
> arphaman wrote:
> > hokein wrote:
> > > I think just returning `Visitor.getOccurrences()` is sufficient -- 
> > > compiler can handle it well, also using std::move would prevent copy 
> > > elision.
> > I'm returning by non-const reference from `getOccurrences`, so the compiler 
> > copies by default. I have to move either here or return by value from 
> > `getOccurrences` and move there. We also have warnings for redundant 
> > `std::move`, and they don't fire here.
> Ok, didn't notice that `getOccurance()` returns non-const reference.
> 
> I think the method `getOccurances` may have potential effect -- the clients 
> could change the Occurences member variable of USRLocFindingASTVisitor, after 
> getting the non-const reference.
> 
> Another option is to rename `getOccurances` to `takeOccurrences` and return 
> by value:
> 
> ```
> SymbolOccurrences takeOccurrences() { return std::move(Occurrences); }
> ```
> 
> What do you think?
Yeah, `takeOccurrences` would be better I think. I'll update.


Repository:
  rL LLVM

https://reviews.llvm.org/D36156



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


Re: r310401 - PR19668, PR23034: Fix handling of move constructors and deleted copy

2017-08-14 Thread Vassil Vassilev via cfe-commits

On 14/08/17 15:59, Diana Picus wrote:

No, the buildbots don't build with -O0 (at least not the ones that broke).

The command line for that particular object is:
build/./bin/clang -fPIC -fvisibility-inlines-hidden -Werror=date-time
-std=c++11 -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wmissing-field-initializers -pedantic -Wno-long-long
-Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
-Wstring-conversion -fcolor-diagnostics -ffunction-sections
-fdata-sections -Wall -std=c++11 -Wno-unused-parameter
-Wno-unknown-warning-option -Wno-covered-switch-default
-DGTEST_NO_LLVM_RAW_OSTREAM=1 -DGTEST_HAS_RTTI=0
-I$LLVM_SRC/llvm/utils/unittest/googletest/include
-I/home/diana.picus/linaro-scripts/bisect/llvm/utils/unittest/googletest
-I$LLVM_SRC/llvm/projects/compiler-rt/include
-I$LLVM_SRC/llvm/projects/compiler-rt/lib
-I$LLVM_SRC/llvm/projects/compiler-rt/lib/asan
-I$LLVM_SRC/llvm/projects/compiler-rt/lib/sanitizer_common/tests
-fno-rtti -O2 -Wno-format -Werror=sign-compare -Wno-non-virtual-dtor
-Wno-variadic-macros -gline-tables-only -DASAN_HAS_BLACKLIST=1
-DASAN_HAS_EXCEPTIONS=1 -DASAN_UAR=0 -fsanitize=address
-fsanitize-blacklist=$LLVM_SRC/llvm/projects/compiler-rt/lib/asan/tests/asan_test.ignore
-mllvm -asan-instrumentation-with-call-threshold=0 -march=armv7-a
-mfloat-abi=hard -c -o
ASAN_INST_TEST_OBJECTS.asan_test.cc.armhf-with-calls.o
$LLVM_SRC/compiler-rt/lib/asan/tests/asan_test.cc
  Could you try to reproduce the issue with O0? This would rule out the 
optimizer. Could you resend the O0 ll file, maybe I could find something 
out. IIUC, the gtest version is 1.8.0?


Why would it contain gtest.cc? It seems to contain gtest.h and a bunch
of other internal gtest headers...


On 14 August 2017 at 16:51, Vassil Vassilev  wrote:

On 14/08/17 15:08, Vassil Vassilev wrote:

On 14/08/17 13:04, Diana Picus wrote:

See attached.

Thanks! It looks like asan_test.i doesn't have gtest.cc which appears in
the stack trace. Am I missing something?

   Could you paste the compiler invocation. Are we building with -O0 (I see
quite a lot of things inline). Could it be an optimizer problem?


On 14 August 2017 at 13:30, Vassil Vassilev 
wrote:

On 14/08/17 11:27, Diana Picus wrote:

Hi,

Strangely enough, it turns out that if I run
Asan-armhf-with-calls-Noinst-Test on the command line it fails,
although it doesn't fail when run with lit. I've attached the stack
trace from gdb. It looks like some trouble passing down va_arg
parameters, but I haven't looked into too much details. The segfault
happens when we try to do a   ldrb   r3, [r0, r1], with r1 set to 0 by
the current function and r0 passed down from the caller. I'm not sure
if this is the exact same problem as the other tests, but feel free to
have a look at that code.

Meanwhile, I've removed some clutter from Asan-armhf-with-calls-Test
(which is the original failure that we were seeing) and left only one
failing test that seemed small enough. I'll try to look at the
disassembly before/after the patch and maybe even run valgrind on it
(running it on the original binary naturally takes forever).

Let me know if there's anything else I could try. I can also send you
disassembly or even LLVM IR for the Asan-armhf-with-calls-Noinst-Test
if you think it helps.

disassembly and LLVM will greatly help as well.


Cheers,
Diana

On 11 August 2017 at 15:34, Diana Picus  wrote:

Well, these are ASAN tests, I'm not sure how that would interact with
Valgrind.
Anyway, I'll try to reproduce the environment, I'm guessing it would
be best to catch this in gdb so I can actually see what's going on.

On 11 August 2017 at 15:21, Vassil Vassilev 
wrote:

That's really strange. It looks like some random behavior. Did you
run
some memory checker like valgrind?

Do the environment provided by the test runner and yours match?

Sent from my phone. Please excuse my brevity.


On 11 Aug 2017, at 15:58, Diana Picus 
wrote:

Hi again,

I finally got the debug build, but unfortunately the stack traces
that
the tests print look the same. My suspicion is that this is because
the addresses printed by the tests are funny (i.e. odd numbers
instead
of divisible by 4). I tried to follow those addresses in an objdump
of
the executable, but I didn't have much success since most of them
weren't really pointing to call instructions.

When I try to run the tests manually in the shell or in gdb, they
pass.

I'm not sure what else to try. Thoughts?

Thanks,
Diana


On 11 August 2017 at 11:14, Diana Picus 
wrote:
Hi guys,

I'm SO sorry about the delays. I've been having all sorts of
trouble
getting that debug build on the board (from ld running out of
memory
to the board just crashing on me, in which case I need to ask
someone
else to reboot it because I can't power cycle it remotely). I can
assure you this is one of my top 

Re: r310401 - PR19668, PR23034: Fix handling of move constructors and deleted copy

2017-08-14 Thread Diana Picus via cfe-commits
On 14 August 2017 at 16:59, Diana Picus  wrote:
> No, the buildbots don't build with -O0 (at least not the ones that broke).
>
> The command line for that particular object is:
> build/./bin/clang -fPIC -fvisibility-inlines-hidden -Werror=date-time
> -std=c++11 -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual
> -Wmissing-field-initializers -pedantic -Wno-long-long
> -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
> -Wstring-conversion -fcolor-diagnostics -ffunction-sections
> -fdata-sections -Wall -std=c++11 -Wno-unused-parameter
> -Wno-unknown-warning-option -Wno-covered-switch-default
> -DGTEST_NO_LLVM_RAW_OSTREAM=1 -DGTEST_HAS_RTTI=0
> -I$LLVM_SRC/llvm/utils/unittest/googletest/include
> -I/home/diana.picus/linaro-scripts/bisect/llvm/utils/unittest/googletest
> -I$LLVM_SRC/llvm/projects/compiler-rt/include
> -I$LLVM_SRC/llvm/projects/compiler-rt/lib
> -I$LLVM_SRC/llvm/projects/compiler-rt/lib/asan
> -I$LLVM_SRC/llvm/projects/compiler-rt/lib/sanitizer_common/tests
> -fno-rtti -O2 -Wno-format -Werror=sign-compare -Wno-non-virtual-dtor
> -Wno-variadic-macros -gline-tables-only -DASAN_HAS_BLACKLIST=1
> -DASAN_HAS_EXCEPTIONS=1 -DASAN_UAR=0 -fsanitize=address
> -fsanitize-blacklist=$LLVM_SRC/llvm/projects/compiler-rt/lib/asan/tests/asan_test.ignore
> -mllvm -asan-instrumentation-with-call-threshold=0 -march=armv7-a
> -mfloat-abi=hard -c -o
> ASAN_INST_TEST_OBJECTS.asan_test.cc.armhf-with-calls.o
> $LLVM_SRC/compiler-rt/lib/asan/tests/asan_test.cc
>
> Why would it contain gtest.cc? It seems to contain gtest.h and a bunch
> of other internal gtest headers...
>

In particular, gtest.cc is included into gtest_all.cc, which compiled
to ASAN_INST_TEST_OBJECTS.gtest_all.cc.armhf-with-calls.o and then
added to the link line, which looks like this:
build/./bin/clang
ASAN_INST_TEST_OBJECTS.gtest-all.cc.armhf-with-calls.o
ASAN_INST_TEST_OBJECTS.asan_asm_test.cc.armhf-with-calls.o
ASAN_INST_TEST_OBJECTS.asan_globals_test.cc.armhf-with-calls.o
ASAN_INST_TEST_OBJECTS.asan_interface_test.cc.armhf-with-calls.o
ASAN_INST_TEST_OBJECTS.asan_internal_interface_test.cc.armhf-with-calls.o
ASAN_INST_TEST_OBJECTS.asan_test.cc.armhf-with-calls.o
ASAN_INST_TEST_OBJECTS.asan_oob_test.cc.armhf-with-calls.o
ASAN_INST_TEST_OBJECTS.asan_mem_test.cc.armhf-with-calls.o
ASAN_INST_TEST_OBJECTS.asan_str_test.cc.armhf-with-calls.o
ASAN_INST_TEST_OBJECTS.asan_test_main.cc.armhf-with-calls.o -o
build/projects/compiler-rt/lib/asan/tests/default/Asan-armhf-with-calls-Test
-Wl,-allow-shlib-undefined -g --driver-mode=g++ -fsanitize=address
-march=armv7-a -mfloat-abi=hard

>
> On 14 August 2017 at 16:51, Vassil Vassilev  wrote:
>> On 14/08/17 15:08, Vassil Vassilev wrote:
>>>
>>> On 14/08/17 13:04, Diana Picus wrote:

 See attached.
>>>
>>> Thanks! It looks like asan_test.i doesn't have gtest.cc which appears in
>>> the stack trace. Am I missing something?
>>
>>   Could you paste the compiler invocation. Are we building with -O0 (I see
>> quite a lot of things inline). Could it be an optimizer problem?
>>

 On 14 August 2017 at 13:30, Vassil Vassilev 
 wrote:
>
> On 14/08/17 11:27, Diana Picus wrote:
>>
>> Hi,
>>
>> Strangely enough, it turns out that if I run
>> Asan-armhf-with-calls-Noinst-Test on the command line it fails,
>> although it doesn't fail when run with lit. I've attached the stack
>> trace from gdb. It looks like some trouble passing down va_arg
>> parameters, but I haven't looked into too much details. The segfault
>> happens when we try to do a   ldrb   r3, [r0, r1], with r1 set to 0 by
>> the current function and r0 passed down from the caller. I'm not sure
>> if this is the exact same problem as the other tests, but feel free to
>> have a look at that code.
>>
>> Meanwhile, I've removed some clutter from Asan-armhf-with-calls-Test
>> (which is the original failure that we were seeing) and left only one
>> failing test that seemed small enough. I'll try to look at the
>> disassembly before/after the patch and maybe even run valgrind on it
>> (running it on the original binary naturally takes forever).
>>
>> Let me know if there's anything else I could try. I can also send you
>> disassembly or even LLVM IR for the Asan-armhf-with-calls-Noinst-Test
>> if you think it helps.
>
>disassembly and LLVM will greatly help as well.
>
>> Cheers,
>> Diana
>>
>> On 11 August 2017 at 15:34, Diana Picus  wrote:
>>>
>>> Well, these are ASAN tests, I'm not sure how that would interact with
>>> Valgrind.
>>> Anyway, I'll try to reproduce the environment, I'm guessing it would
>>> be best to catch this in gdb so I can actually see what's going on.
>>>
>>> On 11 August 2017 at 15:21, Vassil Vassilev 
>>> wrote:


r310840 - [OPENMP] Generalization of calls of the outlined functions.

2017-08-14 Thread Alexey Bataev via cfe-commits
Author: abataev
Date: Mon Aug 14 08:01:03 2017
New Revision: 310840

URL: http://llvm.org/viewvc/llvm-project?rev=310840=rev
Log:
[OPENMP] Generalization of calls of the outlined functions.

General improvement of the outlined functions calls.

Modified:
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntime.h
cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp
cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.h
cfe/trunk/lib/CodeGen/CGStmtOpenMP.cpp
cfe/trunk/test/OpenMP/parallel_codegen.cpp

Modified: cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp?rev=310840=310839=310840=diff
==
--- cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp Mon Aug 14 08:01:03 2017
@@ -2447,7 +2447,7 @@ void CGOpenMPRuntime::emitParallelCall(C
 OutlinedFnArgs.push_back(ThreadIDAddr.getPointer());
 OutlinedFnArgs.push_back(ZeroAddr.getPointer());
 OutlinedFnArgs.append(CapturedVars.begin(), CapturedVars.end());
-RT.emitOutlinedFunctionCall(CGF, OutlinedFn, OutlinedFnArgs);
+RT.emitOutlinedFunctionCall(CGF, Loc, OutlinedFn, OutlinedFnArgs);
 
 // __kmpc_end_serialized_parallel(, GTid);
 llvm::Value *EndArgs[] = {RT.emitUpdateLocation(CGF, Loc), ThreadID};
@@ -3348,14 +3348,14 @@ CGOpenMPRuntime::createOffloadingBinaryD
   auto *UnRegFn = createOffloadingBinaryDescriptorFunction(
   CGM, ".omp_offloading.descriptor_unreg",
   [&](CodeGenFunction , PrePostActionTy &) {
-CGF.EmitCallOrInvoke(createRuntimeFunction(OMPRTL__tgt_unregister_lib),
- Desc);
+CGF.EmitRuntimeCall(createRuntimeFunction(OMPRTL__tgt_unregister_lib),
+Desc);
   });
   auto *RegFn = createOffloadingBinaryDescriptorFunction(
   CGM, ".omp_offloading.descriptor_reg",
   [&](CodeGenFunction , PrePostActionTy &) {
-CGF.EmitCallOrInvoke(createRuntimeFunction(OMPRTL__tgt_register_lib),
- Desc);
+CGF.EmitRuntimeCall(createRuntimeFunction(OMPRTL__tgt_register_lib),
+Desc);
 CGM.getCXXABI().registerGlobalDtor(CGF, RegUnregVar, UnRegFn, Desc);
   });
   if (CGM.supportsCOMDAT()) {
@@ -3859,7 +3859,8 @@ emitProxyTaskFunction(CodeGenModule 
   }
   CallArgs.push_back(SharedsParam);
 
-  CGM.getOpenMPRuntime().emitOutlinedFunctionCall(CGF, TaskFunction, CallArgs);
+  CGM.getOpenMPRuntime().emitOutlinedFunctionCall(CGF, Loc, TaskFunction,
+  CallArgs);
   CGF.EmitStoreThroughLValue(
   RValue::get(CGF.Builder.getInt32(/*C=*/0)),
   CGF.MakeAddrLValue(CGF.ReturnValue, KmpInt32Ty));
@@ -4534,8 +4535,8 @@ void CGOpenMPRuntime::emitTaskCall(CodeG
 DepWaitTaskArgs[5] = llvm::ConstantPointerNull::get(CGF.VoidPtrTy);
   }
   auto & = [, ThreadID, NewTaskNewTaskTTy, TaskEntry,
-NumDependencies, ](CodeGenFunction 
,
-   PrePostActionTy &) {
+NumDependencies, ,
+Loc](CodeGenFunction , PrePostActionTy &) {
 auto  = CGF.CGM.getOpenMPRuntime();
 CodeGenFunction::RunCleanupsScope LocalScope(CGF);
 // Build void __kmpc_omp_wait_deps(ident_t *, kmp_int32 gtid,
@@ -4546,11 +4547,11 @@ void CGOpenMPRuntime::emitTaskCall(CodeG
   CGF.EmitRuntimeCall(RT.createRuntimeFunction(OMPRTL__kmpc_omp_wait_deps),
   DepWaitTaskArgs);
 // Call proxy_task_entry(gtid, new_task);
-auto & = [TaskEntry, ThreadID, NewTaskNewTaskTTy](
-CodeGenFunction , PrePostActionTy ) {
+auto & = [TaskEntry, ThreadID, NewTaskNewTaskTTy,
+  Loc](CodeGenFunction , PrePostActionTy ) {
   Action.Enter(CGF);
   llvm::Value *OutlinedFnArgs[] = {ThreadID, NewTaskNewTaskTTy};
-  CGF.CGM.getOpenMPRuntime().emitOutlinedFunctionCall(CGF, TaskEntry,
+  CGF.CGM.getOpenMPRuntime().emitOutlinedFunctionCall(CGF, Loc, TaskEntry,
   OutlinedFnArgs);
 };
 
@@ -7035,7 +7036,7 @@ void CGOpenMPRuntime::emitTargetCall(Cod
   CGF.Builder.CreateCondBr(Failed, OffloadFailedBlock, OffloadContBlock);
 
   CGF.EmitBlock(OffloadFailedBlock);
-  emitOutlinedFunctionCall(CGF, OutlinedFn, KernelArgs);
+  emitOutlinedFunctionCall(CGF, D.getLocStart(), OutlinedFn, KernelArgs);
   CGF.EmitBranch(OffloadContBlock);
 
   CGF.EmitBlock(OffloadContBlock, /*IsFinished=*/true);
@@ -7755,16 +7756,25 @@ void CGOpenMPRuntime::emitDoacrossOrdere
   CGF.EmitRuntimeCall(RTLFn, Args);
 }
 
-void CGOpenMPRuntime::emitOutlinedFunctionCall(
-CodeGenFunction , llvm::Value *OutlinedFn,
-ArrayRef Args) const {
-  if (auto *Fn = dyn_cast(OutlinedFn)) {
+void CGOpenMPRuntime::emitCall(CodeGenFunction , 

Re: r310401 - PR19668, PR23034: Fix handling of move constructors and deleted copy

2017-08-14 Thread Diana Picus via cfe-commits
No, the buildbots don't build with -O0 (at least not the ones that broke).

The command line for that particular object is:
build/./bin/clang -fPIC -fvisibility-inlines-hidden -Werror=date-time
-std=c++11 -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wmissing-field-initializers -pedantic -Wno-long-long
-Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
-Wstring-conversion -fcolor-diagnostics -ffunction-sections
-fdata-sections -Wall -std=c++11 -Wno-unused-parameter
-Wno-unknown-warning-option -Wno-covered-switch-default
-DGTEST_NO_LLVM_RAW_OSTREAM=1 -DGTEST_HAS_RTTI=0
-I$LLVM_SRC/llvm/utils/unittest/googletest/include
-I/home/diana.picus/linaro-scripts/bisect/llvm/utils/unittest/googletest
-I$LLVM_SRC/llvm/projects/compiler-rt/include
-I$LLVM_SRC/llvm/projects/compiler-rt/lib
-I$LLVM_SRC/llvm/projects/compiler-rt/lib/asan
-I$LLVM_SRC/llvm/projects/compiler-rt/lib/sanitizer_common/tests
-fno-rtti -O2 -Wno-format -Werror=sign-compare -Wno-non-virtual-dtor
-Wno-variadic-macros -gline-tables-only -DASAN_HAS_BLACKLIST=1
-DASAN_HAS_EXCEPTIONS=1 -DASAN_UAR=0 -fsanitize=address
-fsanitize-blacklist=$LLVM_SRC/llvm/projects/compiler-rt/lib/asan/tests/asan_test.ignore
-mllvm -asan-instrumentation-with-call-threshold=0 -march=armv7-a
-mfloat-abi=hard -c -o
ASAN_INST_TEST_OBJECTS.asan_test.cc.armhf-with-calls.o
$LLVM_SRC/compiler-rt/lib/asan/tests/asan_test.cc

Why would it contain gtest.cc? It seems to contain gtest.h and a bunch
of other internal gtest headers...


On 14 August 2017 at 16:51, Vassil Vassilev  wrote:
> On 14/08/17 15:08, Vassil Vassilev wrote:
>>
>> On 14/08/17 13:04, Diana Picus wrote:
>>>
>>> See attached.
>>
>> Thanks! It looks like asan_test.i doesn't have gtest.cc which appears in
>> the stack trace. Am I missing something?
>
>   Could you paste the compiler invocation. Are we building with -O0 (I see
> quite a lot of things inline). Could it be an optimizer problem?
>
>>>
>>> On 14 August 2017 at 13:30, Vassil Vassilev 
>>> wrote:

 On 14/08/17 11:27, Diana Picus wrote:
>
> Hi,
>
> Strangely enough, it turns out that if I run
> Asan-armhf-with-calls-Noinst-Test on the command line it fails,
> although it doesn't fail when run with lit. I've attached the stack
> trace from gdb. It looks like some trouble passing down va_arg
> parameters, but I haven't looked into too much details. The segfault
> happens when we try to do a   ldrb   r3, [r0, r1], with r1 set to 0 by
> the current function and r0 passed down from the caller. I'm not sure
> if this is the exact same problem as the other tests, but feel free to
> have a look at that code.
>
> Meanwhile, I've removed some clutter from Asan-armhf-with-calls-Test
> (which is the original failure that we were seeing) and left only one
> failing test that seemed small enough. I'll try to look at the
> disassembly before/after the patch and maybe even run valgrind on it
> (running it on the original binary naturally takes forever).
>
> Let me know if there's anything else I could try. I can also send you
> disassembly or even LLVM IR for the Asan-armhf-with-calls-Noinst-Test
> if you think it helps.

disassembly and LLVM will greatly help as well.

> Cheers,
> Diana
>
> On 11 August 2017 at 15:34, Diana Picus  wrote:
>>
>> Well, these are ASAN tests, I'm not sure how that would interact with
>> Valgrind.
>> Anyway, I'll try to reproduce the environment, I'm guessing it would
>> be best to catch this in gdb so I can actually see what's going on.
>>
>> On 11 August 2017 at 15:21, Vassil Vassilev 
>> wrote:
>>>
>>> That's really strange. It looks like some random behavior. Did you
>>> run
>>> some memory checker like valgrind?
>>>
>>> Do the environment provided by the test runner and yours match?
>>>
>>> Sent from my phone. Please excuse my brevity.
>>>
 On 11 Aug 2017, at 15:58, Diana Picus 
 wrote:

 Hi again,

 I finally got the debug build, but unfortunately the stack traces
 that
 the tests print look the same. My suspicion is that this is because
 the addresses printed by the tests are funny (i.e. odd numbers
 instead
 of divisible by 4). I tried to follow those addresses in an objdump
 of
 the executable, but I didn't have much success since most of them
 weren't really pointing to call instructions.

 When I try to run the tests manually in the shell or in gdb, they
 pass.

 I'm not sure what else to try. Thoughts?

 Thanks,
 Diana

> On 11 August 2017 at 11:14, Diana Picus 
> wrote:

  1   2   >