Re: r261552 - [VFS] Add 'overlay-relative' field to YAML files

2016-02-22 Thread Bruno Cardoso Lopes via cfe-commits
Reverted r261552 & r261556 in r261613. Waiting for next win bot
results to see if it's necessary to revert r261551 as well.

On Mon, Feb 22, 2016 at 7:16 PM, Bruno Cardoso Lopes
 wrote:
> Yes, but because of a related but different issue. The same as here:
> http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/10026
>
> I've been trying to figure it out but it's been hard without a Unix
> system available. I'll keep investigating and revert later tonight in
> case I can't guess it.
>
> On Mon, Feb 22, 2016 at 7:08 PM, Sean Silva  wrote:
>> The bot is still red:
>> http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast
>>
>> On Mon, Feb 22, 2016 at 6:48 PM, Bruno Cardoso Lopes
>>  wrote:
>>>
>>> Hi Sean,
>>>
>>> This is hopefully fixed in r261556.
>>>
>>> On Mon, Feb 22, 2016 at 5:45 PM, Sean Silva  wrote:
>>> > This or r261551 seem to be causing a build failure:
>>> >
>>> > http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/527
>>> >
>>> > -- Sean SIlva
>>> >
>>> > On Mon, Feb 22, 2016 at 10:41 AM, Bruno Cardoso Lopes via cfe-commits
>>> >  wrote:
>>> >>
>>> >> Author: bruno
>>> >> Date: Mon Feb 22 12:41:09 2016
>>> >> New Revision: 261552
>>> >>
>>> >> URL: http://llvm.org/viewvc/llvm-project?rev=261552=rev
>>> >> Log:
>>> >> [VFS] Add 'overlay-relative' field to YAML files
>>> >>
>>> >> The VFS overlay mapping between virtual paths and real paths is done
>>> >> through
>>> >> the 'external-contents' entries in YAML files, which contains hardcoded
>>> >> paths
>>> >> to the real files.
>>> >>
>>> >> When a module compilation crashes, headers are dumped into
>>> >> .cache/vfs
>>> >> directory and are mapped via the .cache/vfs/vfs.yaml. The script
>>> >> generated for reproduction uses -ivfsoverlay pointing to file to gather
>>> >> the
>>> >> mapping between virtual paths and files inside .cache/vfs.
>>> >> Currently, we
>>> >> are only capable of reproducing such crashes in the same machine as
>>> >> they
>>> >> happen, because of the hardcoded paths in 'external-contents'.
>>> >>
>>> >> To be able to reproduce a crash in another machine, this patch
>>> >> introduces
>>> >> a new
>>> >> option in the VFS yaml file called 'overlay-relative'. When it's equal
>>> >> to
>>> >> 'true' it means that the provided path to the YAML file through the
>>> >> -ivfsoverlay option should also be used to prefix the final path for
>>> >> every
>>> >> 'external-contents'.
>>> >>
>>> >> Example, given the invocation snippet "... -ivfsoverlay
>>> >> .cache/vfs/vfs.yaml" and the following entry in the yaml file:
>>> >>
>>> >> "overlay-relative": "true",
>>> >> "roots": [
>>> >> ...
>>> >>   "type": "directory",
>>> >>   "name": "/usr/include",
>>> >>   "contents": [
>>> >> {
>>> >>   "type": "file",
>>> >>   "name": "stdio.h",
>>> >>   "external-contents": "/usr/include/stdio.h"
>>> >> },
>>> >> ...
>>> >>
>>> >> Here, a file manager request for virtual "/usr/include/stdio.h", that
>>> >> will
>>> >> map
>>> >> into real path
>>> >> "//.cache/vfs/usr/include/stdio.h.
>>> >>
>>> >> This is a useful feature for debugging module crashes in machines other
>>> >> than
>>> >> the one where the error happened.
>>> >>
>>> >> Differential Revision: http://reviews.llvm.org/D17457
>>> >>
>>> >> rdar://problem/24499339
>>> >>
>>> >> Added:
>>> >> cfe/trunk/test/Modules/crash-vfs-relative-overlay.m
>>> >>   - copied, changed from r261551,
>>> >> cfe/trunk/test/Modules/crash-vfs-path-traversal.m
>>> >> Modified:
>>> >> cfe/trunk/include/clang/Basic/VirtualFileSystem.h
>>> >> cfe/trunk/lib/Basic/VirtualFileSystem.cpp
>>> >> cfe/trunk/lib/Frontend/CompilerInvocation.cpp
>>> >> cfe/trunk/lib/Frontend/ModuleDependencyCollector.cpp
>>> >> cfe/trunk/test/Modules/crash-vfs-path-symlink-component.m
>>> >> cfe/trunk/test/Modules/crash-vfs-path-traversal.m
>>> >>
>>> >> Modified: cfe/trunk/include/clang/Basic/VirtualFileSystem.h
>>> >> URL:
>>> >>
>>> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/VirtualFileSystem.h?rev=261552=261551=261552=diff
>>> >>
>>> >>
>>> >> ==
>>> >> --- cfe/trunk/include/clang/Basic/VirtualFileSystem.h (original)
>>> >> +++ cfe/trunk/include/clang/Basic/VirtualFileSystem.h Mon Feb 22
>>> >> 12:41:09
>>> >> 2016
>>> >> @@ -310,6 +310,7 @@ llvm::sys::fs::UniqueID getNextVirtualUn
>>> >>  IntrusiveRefCntPtr
>>> >>  getVFSFromYAML(std::unique_ptr Buffer,
>>> >> llvm::SourceMgr::DiagHandlerTy DiagHandler,
>>> >> +   StringRef YAMLFilePath,
>>> >> void *DiagContext = nullptr,
>>> >> IntrusiveRefCntPtr ExternalFS =
>>> >> getRealFileSystem());
>>> >>
>>> >> @@ -323,6 +324,8 @@ struct YAMLVFSEntry {
>>> >>  class YAMLVFSWriter 

Re: [PATCH] D17092: [X86] Add -mseparate-stack-seg

2016-02-22 Thread Elena Demikhovsky via cfe-commits
delena added a subscriber: delena.


Comment at: lib/CodeGen/TargetInfo.cpp:1569
@@ +1568,3 @@
+CGF.getTarget().getTargetOpts().Features;
+  if (std::find(TargetFeatures.begin(), TargetFeatures.end(),
+"+separate-stack-seg") != TargetFeatures.end()) {

Hi,
I'm not clang reviewer at all and you can ignore my comment.

Searching string looks strange for me. I suppose that this string should be 
defined in another form. Something like
options::OPT_separate_stack_seg.



Comment at: lib/CodeGen/TargetInfo.cpp:1577
@@ +1576,3 @@
+  CGF.Builder.CreatePtrToInt(Addr.getPointer(), CGF.IntPtrTy);
+llvm::Value *PtrInStackSeg = CGF.Builder.CreateIntToPtr(PtrAsInt,
+   
DirectTy->getPointerTo(258));

You should not use 258 as a constant. It should be defined somewhere as address 
space enum.


Comment at: lib/CodeGen/TargetInfo.cpp:1578
@@ +1577,3 @@
+llvm::Value *PtrInStackSeg = CGF.Builder.CreateIntToPtr(PtrAsInt,
+   
DirectTy->getPointerTo(258));
+return Address(PtrInStackSeg, Addr.getAlignment());

This line alignment does not match LLVM style.


Comment at: lib/CodeGen/TargetInfo.cpp:1580
@@ +1579,3 @@
+return Address(PtrInStackSeg, Addr.getAlignment());
+  }
+

Again, not sure that I'm right. You are trying to create addressspacecast. Is 
it the right way to create ptrtoint + inttoptr?


http://reviews.llvm.org/D17092



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


r261613 - Revert "[VFS] Add 'overlay-relative' field to YAML files" and "[VFS] Fix call to getVFSFromYAML in unittests"

2016-02-22 Thread Bruno Cardoso Lopes via cfe-commits
Author: bruno
Date: Tue Feb 23 01:06:12 2016
New Revision: 261613

URL: http://llvm.org/viewvc/llvm-project?rev=261613=rev
Log:
Revert "[VFS] Add 'overlay-relative' field to YAML files" and "[VFS] Fix call 
to getVFSFromYAML in unittests"

This reverts commit r261552 and r261556 because of failing unittests on
windows:

Failing Tests (4):
Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.CaseInsensitive
Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.DirectoryIteration
Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.MappedFiles
Clang-Unit :: Basic/BasicTests.exe/VFSFromYAMLTest.UseExternalName

Removed:
cfe/trunk/test/Modules/crash-vfs-relative-overlay.m
Modified:
cfe/trunk/include/clang/Basic/VirtualFileSystem.h
cfe/trunk/lib/Basic/VirtualFileSystem.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/lib/Frontend/ModuleDependencyCollector.cpp
cfe/trunk/test/Modules/crash-vfs-path-symlink-component.m
cfe/trunk/test/Modules/crash-vfs-path-traversal.m
cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp

Modified: cfe/trunk/include/clang/Basic/VirtualFileSystem.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/VirtualFileSystem.h?rev=261613=261612=261613=diff
==
--- cfe/trunk/include/clang/Basic/VirtualFileSystem.h (original)
+++ cfe/trunk/include/clang/Basic/VirtualFileSystem.h Tue Feb 23 01:06:12 2016
@@ -310,7 +310,6 @@ llvm::sys::fs::UniqueID getNextVirtualUn
 IntrusiveRefCntPtr
 getVFSFromYAML(std::unique_ptr Buffer,
llvm::SourceMgr::DiagHandlerTy DiagHandler,
-   StringRef YAMLFilePath,
void *DiagContext = nullptr,
IntrusiveRefCntPtr ExternalFS = 
getRealFileSystem());
 
@@ -324,8 +323,6 @@ struct YAMLVFSEntry {
 class YAMLVFSWriter {
   std::vector Mappings;
   Optional IsCaseSensitive;
-  Optional IsOverlayRelative;
-  std::string OverlayDir;
 
 public:
   YAMLVFSWriter() {}
@@ -333,11 +330,6 @@ public:
   void setCaseSensitivity(bool CaseSensitive) {
 IsCaseSensitive = CaseSensitive;
   }
-  void setOverlayDir(StringRef OverlayDirectory) {
-IsOverlayRelative = true;
-OverlayDir.assign(OverlayDirectory.str());
-  }
-
   void write(llvm::raw_ostream );
 };
 

Modified: cfe/trunk/lib/Basic/VirtualFileSystem.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/VirtualFileSystem.cpp?rev=261613=261612=261613=diff
==
--- cfe/trunk/lib/Basic/VirtualFileSystem.cpp (original)
+++ cfe/trunk/lib/Basic/VirtualFileSystem.cpp Tue Feb 23 01:06:12 2016
@@ -790,7 +790,6 @@ public:
 /// All configuration options are optional.
 ///   'case-sensitive': 
 ///   'use-external-names': 
-///   'overlay-relative': 
 ///
 /// Virtual directories are represented as
 /// \verbatim
@@ -833,10 +832,6 @@ class RedirectingFileSystem : public vfs
   std::vector Roots;
   /// \brief The file system to use for external references.
   IntrusiveRefCntPtr ExternalFS;
-  /// If IsRelativeOverlay is set, this represents the directory
-  /// path that should be prefixed to each 'external-contents' entry
-  /// when reading from YAML files.
-  std::string ExternalContentsPrefixDir;
 
   /// @name Configuration
   /// @{
@@ -846,10 +841,6 @@ class RedirectingFileSystem : public vfs
   /// Currently, case-insensitive matching only works correctly with ASCII.
   bool CaseSensitive;
 
-  /// IsRelativeOverlay marks whether a IsExternalContentsPrefixDir path must
-  /// be prefixed in every 'external-contents' when reading from YAML files.
-  bool IsRelativeOverlay = false;
-
   /// \brief Whether to use to use the value of 'external-contents' for the
   /// names of files.  This global value is overridable on a per-file basis.
   bool UseExternalNames;
@@ -877,8 +868,8 @@ public:
   /// returns a virtual file system representing its contents.
   static RedirectingFileSystem *
   create(std::unique_ptr Buffer,
- SourceMgr::DiagHandlerTy DiagHandler, StringRef YAMLFilePath,
- void *DiagContext, IntrusiveRefCntPtr ExternalFS);
+ SourceMgr::DiagHandlerTy DiagHandler, void *DiagContext,
+ IntrusiveRefCntPtr ExternalFS);
 
   ErrorOr status(const Twine ) override;
   ErrorOr openFileForRead(const Twine ) override;
@@ -911,15 +902,6 @@ public:
 return directory_iterator(std::make_shared(Dir,
 *this, D->contents_begin(), D->contents_end(), EC));
   }
-
-  void setExternalContentsPrefixDir(StringRef PrefixDir) {
-ExternalContentsPrefixDir = PrefixDir.str();
-  }
-
-  StringRef getExternalContentsPrefixDir() const {
-return ExternalContentsPrefixDir;
-  }
-
 };
 
 /// \brief A helper class to hold the common YAML parsing state.
@@ -999,7 +981,7 @@ class RedirectingFileSystemParser {
  

Re: [PATCH] D17436: [OpenCL] Add Sema checks for OpenCL 2.0 block

2016-02-22 Thread Xiuli PAN via cfe-commits
pxli168 added inline comments.


Comment at: lib/Sema/SemaDecl.cpp:6714
@@ +6713,3 @@
+  if (LangOpts.OpenCLVersion >= 200 && T->isBlockPointerType()) {
+const BlockPointerType *BlkTy = T->getAs();
+const FunctionProtoType *FTy =

Anastasia wrote:
> Yes, but you have to diagnose blocks correctly in all CL versions in which we 
> accept blocks. When you come to this point here you should only care about 
> checking whether blocks have variadic prototype or not. You should assume the 
> parser did the right job to either accept or reject the block declaration 
> earlier and also gave the right diagnostic.
> 
> It will be responsibility of a parser to correctly accept or reject blocks 
> depending on a version. I will prepare a patch for it later on. Please see my 
> related comment on the review: http://reviews.llvm.org/D16928 
I will change these, if we can restrict -fblock with -cl-std=CL2.x then there 
will be no problem by only checking LangOpts.OpenCL


Comment at: lib/Sema/SemaExpr.cpp:6509
@@ +6508,3 @@
+  return QualType();
+  }
+

Anastasia wrote:
> What is the implication of that? Will we get errors in different order then?
I think we should put operands check after condition check to keep the original 
logic.


http://reviews.llvm.org/D17436



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


Re: [PATCH] D17436: [OpenCL] Add Sema checks for OpenCL 2.0 block

2016-02-22 Thread Xiuli PAN via cfe-commits
pxli168 updated this revision to Diff 48774.

http://reviews.llvm.org/D17436

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaType.cpp
  test/SemaOpenCL/invalid-block.cl

Index: test/SemaOpenCL/invalid-block.cl
===
--- /dev/null
+++ test/SemaOpenCL/invalid-block.cl
@@ -0,0 +1,20 @@
+// RUN: %clang_cc1 -verify -fblocks -cl-std=CL2.0 %s
+
+int (^BlkVariadic)(int, ...) = ^int(int I, ...) { // expected-error {{invalid block prototype, variadic arguments are not allowed in OpenCL}}
+  return 0;
+};
+
+typedef int (^BlkInt)(int);
+void f1(int i) {
+  BlkInt B1 = ^int(int I) {return 1;};
+  BlkInt B2 = ^int(int I) {return 2;};
+  BlkInt Arr[] = {B1, B2}; // expected-error {{array of 'BlkInt' (aka 'int (^)(int)') type is invalid in OpenCL}}
+  int tmp = i ? B1(i)  // expected-error {{block type cannot be used as expression in ternary expression in OpenCL}}
+  : B2(i); // expected-error {{block type cannot be used as expression in ternary expression in OpenCL}}
+}
+
+void f2(BlkInt *BlockPtr) {
+  BlkInt B = ^int(int I) {return 1;};
+  BlkInt *P =  // expected-error {{invalid argument type 'BlkInt' (aka 'int (^)(int)') to unary expression}}
+  B = *BlockPtr;  // expected-error {{dereferencing pointer of type '__generic BlkInt *' (aka 'int (^__generic *)(int)') is not allowed in OpenCL}}
+}
Index: lib/Sema/SemaType.cpp
===
--- lib/Sema/SemaType.cpp
+++ lib/Sema/SemaType.cpp
@@ -2175,6 +2175,15 @@
 Diag(Loc, diag::warn_vla_used);
   }
 
+  // OpenCL v2.0 s6.12.5 - Arrays of blocks are not supported.
+  if (getLangOpts().OpenCL) {
+const QualType ArrType = Context.getBaseElementType(T);
+if (ArrType->isBlockPointerType()) {
+  Diag(Loc, diag::err_opencl_invalid_type_array) << ArrType;
+  return QualType();
+}
+  }
+
   return T;
 }
 
Index: lib/Sema/SemaExpr.cpp
===
--- lib/Sema/SemaExpr.cpp
+++ lib/Sema/SemaExpr.cpp
@@ -6440,6 +6440,18 @@
   return OpenCLConvertScalarsToVectors(S, LHS, RHS, CondTy, QuestionLoc);
 }
 
+/// \brief Return true if the Expr is block type
+static bool checkBlockType(Sema , const Expr *E) {
+  if (const CallExpr *CE = dyn_cast(E)) {
+QualType Ty = CE->getCallee()->getType();
+if (Ty->isBlockPointerType()) {
+  S.Diag(E->getExprLoc(), diag::err_opencl_ternary_with_block);
+  return true;
+}
+  }
+  return false;
+}
+
 /// Note that LHS is not null here, even if this is the gnu "x ?: y" extension.
 /// In that case, LHS = cond.
 /// C99 6.5.15
@@ -6489,6 +6501,13 @@
   QualType LHSTy = LHS.get()->getType();
   QualType RHSTy = RHS.get()->getType();
 
+  // OpenCL v2.0 s6.12.5 - Blocks cannot be used as expressions of the ternary
+  // selection operator (?:).
+  if (getLangOpts().OpenCL &&
+  (checkBlockType(*this, LHS.get()) | checkBlockType(*this, RHS.get( {
+return QualType();
+  }
+
   // If both operands have arithmetic type, do the usual arithmetic conversions
   // to find a common type: C99 6.5.15p3,5.
   if (LHSTy->isArithmeticType() && RHSTy->isArithmeticType()) {
@@ -10237,6 +10256,14 @@
   // If the operand has type "type", the result has type "pointer to type".
   if (op->getType()->isObjCObjectType())
 return Context.getObjCObjectPointerType(op->getType());
+
+  // OpenCL v2.0 s6.12.5 - The unary operators & cannot be used with a block.
+  if (getLangOpts().OpenCL && OrigOp.get()->getType()->isBlockPointerType()) {
+Diag(OpLoc, diag::err_typecheck_unary_expr) << OrigOp.get()->getType()
+<< op->getSourceRange();
+return QualType();
+  }
+
   return Context.getPointerType(op->getType());
 }
 
@@ -10278,7 +10305,15 @@
   }
 
   if (const PointerType *PT = OpTy->getAs())
+  {
 Result = PT->getPointeeType();
+// OpenCL v2.0 s6.12.5 - The unary operators * cannot be used with a block.
+if (S.getLangOpts().OpenCLVersion >= 200 && Result->isBlockPointerType()) {
+  S.Diag(OpLoc, diag::err_opencl_dereferencing) << OpTy
+<< Op->getSourceRange();
+  return QualType();
+}
+  }
   else if (const ObjCObjectPointerType *OPT =
  OpTy->getAs())
 Result = OPT->getPointeeType();
Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -6708,6 +6708,19 @@
 NewVD->setInvalidDecl();
 return;
   }
+
+  // OpenCL v2.0 s6.12.5 - Blocks with variadic arguments are not supported.
+  if (LangOpts.OpenCL && T->isBlockPointerType()) {
+const BlockPointerType *BlkTy = T->getAs();
+const FunctionProtoType *FTy =
+BlkTy->getPointeeType()->getAs();
+if (FTy->isVariadic()) {
+  Diag(NewVD->getLocation(), 

Re: [PATCH] D17437: [OpenCL] Add Sema checks for types

2016-02-22 Thread Xiuli PAN via cfe-commits
pxli168 updated this revision to Diff 48773.
pxli168 added a comment.

Add array check for types.


http://reviews.llvm.org/D17437

Files:
  include/clang/Basic/DiagnosticSemaKinds.td
  lib/Sema/SemaDecl.cpp
  lib/Sema/SemaType.cpp
  test/CodeGenOpenCL/opencl_types.cl
  test/SemaOpenCL/invalid-image.cl
  test/SemaOpenCL/invalid-pipes-cl2.0.cl
  test/SemaOpenCL/sampler_t.cl

Index: test/SemaOpenCL/sampler_t.cl
===
--- test/SemaOpenCL/sampler_t.cl
+++ test/SemaOpenCL/sampler_t.cl
@@ -10,4 +10,7 @@
   foo(glb_smp);
   foo(const_smp);
   foo(5); // expected-error {{sampler_t variable required - got 'int'}}
+  sampler_t sa[] = {argsmp,const_smp}; // expected-error {{array of 'sampler_t' type is invalid in OpenCL}}
 }
+
+void bad(sampler_t*); // expected-error {{pointer to type 'sampler_t' is invalid in OpenCL}}
Index: test/SemaOpenCL/invalid-pipes-cl2.0.cl
===
--- test/SemaOpenCL/invalid-pipes-cl2.0.cl
+++ test/SemaOpenCL/invalid-pipes-cl2.0.cl
@@ -6,3 +6,6 @@
 }
 void test3(int pipe p){// expected-error {{cannot combine with previous 'int' declaration specifier}}
 }
+void test4() {
+  pipe int p; // expected-error {{type 'pipe' can only be used as a function parameter}}
+}
Index: test/SemaOpenCL/invalid-image.cl
===
--- /dev/null
+++ test/SemaOpenCL/invalid-image.cl
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -verify %s
+
+void test1(image1d_t *i){} // expected-error {{pointer to type 'image1d_t' is invalid in OpenCL}}
+
+void test2(image1d_t i) {
+  image1d_t ti; // expected-error {{type 'image1d_t' can only be used as a function parameter}}
+  image1d_t ai[] = {i,i};// expected-error {{array of 'image1d_t' type is invalid in OpenCL}}
+}
Index: test/CodeGenOpenCL/opencl_types.cl
===
--- test/CodeGenOpenCL/opencl_types.cl
+++ test/CodeGenOpenCL/opencl_types.cl
@@ -36,5 +36,5 @@
 // CHECK: call {{.*}}void @fnc4smp(i32
 }
 
-void __attribute__((overloadable)) bad1(image1d_t *b, image2d_t *c, image2d_t *d) {}
-// CHECK-LABEL: @{{_Z4bad1P11ocl_image1dP11ocl_image2dS2_|"\\01\?bad1@@\$\$J0YAXPE?APAUocl_image1d@@PE?APAUocl_image2d@@1@Z"}}
+void __attribute__((overloadable)) bad1(image1d_t b, image2d_t c, image2d_t d) {}
+// CHECK-LABEL: @{{_Z4bad111ocl_image1d11ocl_image2dS0_|"\\01\?bad1@@\$\$J0YAXPAUocl_image1d@@PAUocl_image2d@@1@Z"}}
Index: lib/Sema/SemaType.cpp
===
--- lib/Sema/SemaType.cpp
+++ lib/Sema/SemaType.cpp
@@ -2176,9 +2176,12 @@
   }
 
   // OpenCL v2.0 s6.12.5 - Arrays of blocks are not supported.
+  // OpenCL v2.0 s6.16.13.1 - Arrays of pipe type are not supported.
+  //  OpenCL v2.0 s6.9.b - Arrays of image/sampler type are not supported.
   if (getLangOpts().OpenCL) {
 const QualType ArrType = Context.getBaseElementType(T);
-if (ArrType->isBlockPointerType()) {
+if (ArrType->isBlockPointerType() || ArrType->isPipeType() ||
+ArrType->isSamplerT() || ArrType->isImageType()) {
   Diag(Loc, diag::err_opencl_invalid_type_array) << ArrType;
   return QualType();
 }
Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -5710,6 +5710,17 @@
   QualType R = TInfo->getType();
   DeclarationName Name = GetNameForDeclarator(D).getName();
 
+  // OpenCL v2.0 s6.9.b - Image type can only be used as a function argument.
+  // OpenCL v2.0 s6.13.16.1 - Pipe type can only be used as a function
+  // argument.
+  if (getLangOpts().OpenCL && (R->isImageType() || R->isPipeType())) {
+Diag(D.getIdentifierLoc(),
+ diag::err_opencl_type_can_only_be_used_as_function_parameter)
+<< R;
+D.setInvalidType();
+return nullptr;
+  }
+
   DeclSpec::SCS SCSpec = D.getDeclSpec().getStorageClassSpec();
   StorageClass SC = StorageClassSpecToVarDeclStorageClass(D.getDeclSpec());
 
@@ -10737,7 +10748,17 @@
   Diag(NameLoc, diag::err_arg_with_address_space);
   New->setInvalidDecl();
 }
-  }   
+  }
+
+  // OpenCL v2.0 s6.9b - Pointer to image/sampler cannot be used.
+  // OpenCL v2.0 s6.13.16.1 - Pointer to pipe cannot be used.
+  if (getLangOpts().OpenCL && T->isPointerType()) {
+const QualType PTy = T->getPointeeType();
+if (PTy->isImageType() || PTy->isSamplerT() || PTy->isPipeType()) {
+  Diag(NameLoc, diag::err_opencl_pointer_to_type) << PTy;
+  New->setInvalidDecl();
+}
+  }
 
   return New;
 }
Index: include/clang/Basic/DiagnosticSemaKinds.td
===
--- include/clang/Basic/DiagnosticSemaKinds.td
+++ include/clang/Basic/DiagnosticSemaKinds.td
@@ -7703,6 +7703,10 @@
   "array of %0 type is invalid in OpenCL">;
 def err_opencl_ternary_with_block : Error<
   "block type cannot be 

LLVM buildmaster restarted in few minutes

2016-02-22 Thread Galina Kistanova via cfe-commits
Hello everyone,

LLVM buildmaster will be updated and restarted in few minutes.
Thank you for understanding.

Thanks

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


Re: r261552 - [VFS] Add 'overlay-relative' field to YAML files

2016-02-22 Thread Bruno Cardoso Lopes via cfe-commits
Yes, but because of a related but different issue. The same as here:
http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/10026

I've been trying to figure it out but it's been hard without a Unix
system available. I'll keep investigating and revert later tonight in
case I can't guess it.

On Mon, Feb 22, 2016 at 7:08 PM, Sean Silva  wrote:
> The bot is still red:
> http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast
>
> On Mon, Feb 22, 2016 at 6:48 PM, Bruno Cardoso Lopes
>  wrote:
>>
>> Hi Sean,
>>
>> This is hopefully fixed in r261556.
>>
>> On Mon, Feb 22, 2016 at 5:45 PM, Sean Silva  wrote:
>> > This or r261551 seem to be causing a build failure:
>> >
>> > http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/527
>> >
>> > -- Sean SIlva
>> >
>> > On Mon, Feb 22, 2016 at 10:41 AM, Bruno Cardoso Lopes via cfe-commits
>> >  wrote:
>> >>
>> >> Author: bruno
>> >> Date: Mon Feb 22 12:41:09 2016
>> >> New Revision: 261552
>> >>
>> >> URL: http://llvm.org/viewvc/llvm-project?rev=261552=rev
>> >> Log:
>> >> [VFS] Add 'overlay-relative' field to YAML files
>> >>
>> >> The VFS overlay mapping between virtual paths and real paths is done
>> >> through
>> >> the 'external-contents' entries in YAML files, which contains hardcoded
>> >> paths
>> >> to the real files.
>> >>
>> >> When a module compilation crashes, headers are dumped into
>> >> .cache/vfs
>> >> directory and are mapped via the .cache/vfs/vfs.yaml. The script
>> >> generated for reproduction uses -ivfsoverlay pointing to file to gather
>> >> the
>> >> mapping between virtual paths and files inside .cache/vfs.
>> >> Currently, we
>> >> are only capable of reproducing such crashes in the same machine as
>> >> they
>> >> happen, because of the hardcoded paths in 'external-contents'.
>> >>
>> >> To be able to reproduce a crash in another machine, this patch
>> >> introduces
>> >> a new
>> >> option in the VFS yaml file called 'overlay-relative'. When it's equal
>> >> to
>> >> 'true' it means that the provided path to the YAML file through the
>> >> -ivfsoverlay option should also be used to prefix the final path for
>> >> every
>> >> 'external-contents'.
>> >>
>> >> Example, given the invocation snippet "... -ivfsoverlay
>> >> .cache/vfs/vfs.yaml" and the following entry in the yaml file:
>> >>
>> >> "overlay-relative": "true",
>> >> "roots": [
>> >> ...
>> >>   "type": "directory",
>> >>   "name": "/usr/include",
>> >>   "contents": [
>> >> {
>> >>   "type": "file",
>> >>   "name": "stdio.h",
>> >>   "external-contents": "/usr/include/stdio.h"
>> >> },
>> >> ...
>> >>
>> >> Here, a file manager request for virtual "/usr/include/stdio.h", that
>> >> will
>> >> map
>> >> into real path
>> >> "//.cache/vfs/usr/include/stdio.h.
>> >>
>> >> This is a useful feature for debugging module crashes in machines other
>> >> than
>> >> the one where the error happened.
>> >>
>> >> Differential Revision: http://reviews.llvm.org/D17457
>> >>
>> >> rdar://problem/24499339
>> >>
>> >> Added:
>> >> cfe/trunk/test/Modules/crash-vfs-relative-overlay.m
>> >>   - copied, changed from r261551,
>> >> cfe/trunk/test/Modules/crash-vfs-path-traversal.m
>> >> Modified:
>> >> cfe/trunk/include/clang/Basic/VirtualFileSystem.h
>> >> cfe/trunk/lib/Basic/VirtualFileSystem.cpp
>> >> cfe/trunk/lib/Frontend/CompilerInvocation.cpp
>> >> cfe/trunk/lib/Frontend/ModuleDependencyCollector.cpp
>> >> cfe/trunk/test/Modules/crash-vfs-path-symlink-component.m
>> >> cfe/trunk/test/Modules/crash-vfs-path-traversal.m
>> >>
>> >> Modified: cfe/trunk/include/clang/Basic/VirtualFileSystem.h
>> >> URL:
>> >>
>> >> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/VirtualFileSystem.h?rev=261552=261551=261552=diff
>> >>
>> >>
>> >> ==
>> >> --- cfe/trunk/include/clang/Basic/VirtualFileSystem.h (original)
>> >> +++ cfe/trunk/include/clang/Basic/VirtualFileSystem.h Mon Feb 22
>> >> 12:41:09
>> >> 2016
>> >> @@ -310,6 +310,7 @@ llvm::sys::fs::UniqueID getNextVirtualUn
>> >>  IntrusiveRefCntPtr
>> >>  getVFSFromYAML(std::unique_ptr Buffer,
>> >> llvm::SourceMgr::DiagHandlerTy DiagHandler,
>> >> +   StringRef YAMLFilePath,
>> >> void *DiagContext = nullptr,
>> >> IntrusiveRefCntPtr ExternalFS =
>> >> getRealFileSystem());
>> >>
>> >> @@ -323,6 +324,8 @@ struct YAMLVFSEntry {
>> >>  class YAMLVFSWriter {
>> >>std::vector Mappings;
>> >>Optional IsCaseSensitive;
>> >> +  Optional IsOverlayRelative;
>> >> +  std::string OverlayDir;
>> >>
>> >>  public:
>> >>YAMLVFSWriter() {}
>> >> @@ -330,6 +333,11 @@ public:
>> >>void setCaseSensitivity(bool CaseSensitive) {
>> >>  IsCaseSensitive = CaseSensitive;
>> >>}
>> >> +  

Re: r261552 - [VFS] Add 'overlay-relative' field to YAML files

2016-02-22 Thread Sean Silva via cfe-commits
The bot is still red:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast

On Mon, Feb 22, 2016 at 6:48 PM, Bruno Cardoso Lopes <
bruno.card...@gmail.com> wrote:

> Hi Sean,
>
> This is hopefully fixed in r261556.
>
> On Mon, Feb 22, 2016 at 5:45 PM, Sean Silva  wrote:
> > This or r261551 seem to be causing a build failure:
> >
> http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/527
> >
> > -- Sean SIlva
> >
> > On Mon, Feb 22, 2016 at 10:41 AM, Bruno Cardoso Lopes via cfe-commits
> >  wrote:
> >>
> >> Author: bruno
> >> Date: Mon Feb 22 12:41:09 2016
> >> New Revision: 261552
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=261552=rev
> >> Log:
> >> [VFS] Add 'overlay-relative' field to YAML files
> >>
> >> The VFS overlay mapping between virtual paths and real paths is done
> >> through
> >> the 'external-contents' entries in YAML files, which contains hardcoded
> >> paths
> >> to the real files.
> >>
> >> When a module compilation crashes, headers are dumped into
> >> .cache/vfs
> >> directory and are mapped via the .cache/vfs/vfs.yaml. The script
> >> generated for reproduction uses -ivfsoverlay pointing to file to gather
> >> the
> >> mapping between virtual paths and files inside .cache/vfs.
> >> Currently, we
> >> are only capable of reproducing such crashes in the same machine as they
> >> happen, because of the hardcoded paths in 'external-contents'.
> >>
> >> To be able to reproduce a crash in another machine, this patch
> introduces
> >> a new
> >> option in the VFS yaml file called 'overlay-relative'. When it's equal
> to
> >> 'true' it means that the provided path to the YAML file through the
> >> -ivfsoverlay option should also be used to prefix the final path for
> every
> >> 'external-contents'.
> >>
> >> Example, given the invocation snippet "... -ivfsoverlay
> >> .cache/vfs/vfs.yaml" and the following entry in the yaml file:
> >>
> >> "overlay-relative": "true",
> >> "roots": [
> >> ...
> >>   "type": "directory",
> >>   "name": "/usr/include",
> >>   "contents": [
> >> {
> >>   "type": "file",
> >>   "name": "stdio.h",
> >>   "external-contents": "/usr/include/stdio.h"
> >> },
> >> ...
> >>
> >> Here, a file manager request for virtual "/usr/include/stdio.h", that
> will
> >> map
> >> into real path
> "//.cache/vfs/usr/include/stdio.h.
> >>
> >> This is a useful feature for debugging module crashes in machines other
> >> than
> >> the one where the error happened.
> >>
> >> Differential Revision: http://reviews.llvm.org/D17457
> >>
> >> rdar://problem/24499339
> >>
> >> Added:
> >> cfe/trunk/test/Modules/crash-vfs-relative-overlay.m
> >>   - copied, changed from r261551,
> >> cfe/trunk/test/Modules/crash-vfs-path-traversal.m
> >> Modified:
> >> cfe/trunk/include/clang/Basic/VirtualFileSystem.h
> >> cfe/trunk/lib/Basic/VirtualFileSystem.cpp
> >> cfe/trunk/lib/Frontend/CompilerInvocation.cpp
> >> cfe/trunk/lib/Frontend/ModuleDependencyCollector.cpp
> >> cfe/trunk/test/Modules/crash-vfs-path-symlink-component.m
> >> cfe/trunk/test/Modules/crash-vfs-path-traversal.m
> >>
> >> Modified: cfe/trunk/include/clang/Basic/VirtualFileSystem.h
> >> URL:
> >>
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/VirtualFileSystem.h?rev=261552=261551=261552=diff
> >>
> >>
> ==
> >> --- cfe/trunk/include/clang/Basic/VirtualFileSystem.h (original)
> >> +++ cfe/trunk/include/clang/Basic/VirtualFileSystem.h Mon Feb 22
> 12:41:09
> >> 2016
> >> @@ -310,6 +310,7 @@ llvm::sys::fs::UniqueID getNextVirtualUn
> >>  IntrusiveRefCntPtr
> >>  getVFSFromYAML(std::unique_ptr Buffer,
> >> llvm::SourceMgr::DiagHandlerTy DiagHandler,
> >> +   StringRef YAMLFilePath,
> >> void *DiagContext = nullptr,
> >> IntrusiveRefCntPtr ExternalFS =
> >> getRealFileSystem());
> >>
> >> @@ -323,6 +324,8 @@ struct YAMLVFSEntry {
> >>  class YAMLVFSWriter {
> >>std::vector Mappings;
> >>Optional IsCaseSensitive;
> >> +  Optional IsOverlayRelative;
> >> +  std::string OverlayDir;
> >>
> >>  public:
> >>YAMLVFSWriter() {}
> >> @@ -330,6 +333,11 @@ public:
> >>void setCaseSensitivity(bool CaseSensitive) {
> >>  IsCaseSensitive = CaseSensitive;
> >>}
> >> +  void setOverlayDir(StringRef OverlayDirectory) {
> >> +IsOverlayRelative = true;
> >> +OverlayDir.assign(OverlayDirectory.str());
> >> +  }
> >> +
> >>void write(llvm::raw_ostream );
> >>  };
> >>
> >>
> >> Modified: cfe/trunk/lib/Basic/VirtualFileSystem.cpp
> >> URL:
> >>
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/VirtualFileSystem.cpp?rev=261552=261551=261552=diff
> >>
> >>
> ==
> >> --- cfe/trunk/lib/Basic/VirtualFileSystem.cpp 

Re: r261552 - [VFS] Add 'overlay-relative' field to YAML files

2016-02-22 Thread Bruno Cardoso Lopes via cfe-commits
Hi Sean,

This is hopefully fixed in r261556.

On Mon, Feb 22, 2016 at 5:45 PM, Sean Silva  wrote:
> This or r261551 seem to be causing a build failure:
> http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/527
>
> -- Sean SIlva
>
> On Mon, Feb 22, 2016 at 10:41 AM, Bruno Cardoso Lopes via cfe-commits
>  wrote:
>>
>> Author: bruno
>> Date: Mon Feb 22 12:41:09 2016
>> New Revision: 261552
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=261552=rev
>> Log:
>> [VFS] Add 'overlay-relative' field to YAML files
>>
>> The VFS overlay mapping between virtual paths and real paths is done
>> through
>> the 'external-contents' entries in YAML files, which contains hardcoded
>> paths
>> to the real files.
>>
>> When a module compilation crashes, headers are dumped into
>> .cache/vfs
>> directory and are mapped via the .cache/vfs/vfs.yaml. The script
>> generated for reproduction uses -ivfsoverlay pointing to file to gather
>> the
>> mapping between virtual paths and files inside .cache/vfs.
>> Currently, we
>> are only capable of reproducing such crashes in the same machine as they
>> happen, because of the hardcoded paths in 'external-contents'.
>>
>> To be able to reproduce a crash in another machine, this patch introduces
>> a new
>> option in the VFS yaml file called 'overlay-relative'. When it's equal to
>> 'true' it means that the provided path to the YAML file through the
>> -ivfsoverlay option should also be used to prefix the final path for every
>> 'external-contents'.
>>
>> Example, given the invocation snippet "... -ivfsoverlay
>> .cache/vfs/vfs.yaml" and the following entry in the yaml file:
>>
>> "overlay-relative": "true",
>> "roots": [
>> ...
>>   "type": "directory",
>>   "name": "/usr/include",
>>   "contents": [
>> {
>>   "type": "file",
>>   "name": "stdio.h",
>>   "external-contents": "/usr/include/stdio.h"
>> },
>> ...
>>
>> Here, a file manager request for virtual "/usr/include/stdio.h", that will
>> map
>> into real path "//.cache/vfs/usr/include/stdio.h.
>>
>> This is a useful feature for debugging module crashes in machines other
>> than
>> the one where the error happened.
>>
>> Differential Revision: http://reviews.llvm.org/D17457
>>
>> rdar://problem/24499339
>>
>> Added:
>> cfe/trunk/test/Modules/crash-vfs-relative-overlay.m
>>   - copied, changed from r261551,
>> cfe/trunk/test/Modules/crash-vfs-path-traversal.m
>> Modified:
>> cfe/trunk/include/clang/Basic/VirtualFileSystem.h
>> cfe/trunk/lib/Basic/VirtualFileSystem.cpp
>> cfe/trunk/lib/Frontend/CompilerInvocation.cpp
>> cfe/trunk/lib/Frontend/ModuleDependencyCollector.cpp
>> cfe/trunk/test/Modules/crash-vfs-path-symlink-component.m
>> cfe/trunk/test/Modules/crash-vfs-path-traversal.m
>>
>> Modified: cfe/trunk/include/clang/Basic/VirtualFileSystem.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/VirtualFileSystem.h?rev=261552=261551=261552=diff
>>
>> ==
>> --- cfe/trunk/include/clang/Basic/VirtualFileSystem.h (original)
>> +++ cfe/trunk/include/clang/Basic/VirtualFileSystem.h Mon Feb 22 12:41:09
>> 2016
>> @@ -310,6 +310,7 @@ llvm::sys::fs::UniqueID getNextVirtualUn
>>  IntrusiveRefCntPtr
>>  getVFSFromYAML(std::unique_ptr Buffer,
>> llvm::SourceMgr::DiagHandlerTy DiagHandler,
>> +   StringRef YAMLFilePath,
>> void *DiagContext = nullptr,
>> IntrusiveRefCntPtr ExternalFS =
>> getRealFileSystem());
>>
>> @@ -323,6 +324,8 @@ struct YAMLVFSEntry {
>>  class YAMLVFSWriter {
>>std::vector Mappings;
>>Optional IsCaseSensitive;
>> +  Optional IsOverlayRelative;
>> +  std::string OverlayDir;
>>
>>  public:
>>YAMLVFSWriter() {}
>> @@ -330,6 +333,11 @@ public:
>>void setCaseSensitivity(bool CaseSensitive) {
>>  IsCaseSensitive = CaseSensitive;
>>}
>> +  void setOverlayDir(StringRef OverlayDirectory) {
>> +IsOverlayRelative = true;
>> +OverlayDir.assign(OverlayDirectory.str());
>> +  }
>> +
>>void write(llvm::raw_ostream );
>>  };
>>
>>
>> Modified: cfe/trunk/lib/Basic/VirtualFileSystem.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/VirtualFileSystem.cpp?rev=261552=261551=261552=diff
>>
>> ==
>> --- cfe/trunk/lib/Basic/VirtualFileSystem.cpp (original)
>> +++ cfe/trunk/lib/Basic/VirtualFileSystem.cpp Mon Feb 22 12:41:09 2016
>> @@ -790,6 +790,7 @@ public:
>>  /// All configuration options are optional.
>>  ///   'case-sensitive': 
>>  ///   'use-external-names': 
>> +///   'overlay-relative': 
>>  ///
>>  /// Virtual directories are represented as
>>  /// \verbatim
>> @@ -832,6 +833,10 @@ class RedirectingFileSystem : public vfs
>>

Re: [PATCH] D17438: [OpenCL] Add Sema checks for atomics and implicit declaration

2016-02-22 Thread Xiuli PAN via cfe-commits
pxli168 added a comment.

It seems this patch is useless.
The spec does not tell about implicit declaration of function, but now clang 
with -triple spir will output err if there is implicit declaration of function.
I have read about spir and opencl spec but could not find anything talk about 
that.
If this is a clang bug then this patch is useless.

What do you think?



Comment at: lib/Sema/SemaDecl.cpp:3900
@@ -3899,1 +3899,3 @@
   if (!DeclaresAnything) {
+// OpenCL C doesn't support bit-field, so declaration with no declarator
+// has no use.

Anastasia wrote:
> I am still not convinced about this change? Could you give reference to spec 
> or an example? I don't understand why you are trying to change default C 
> behavior.
Just removed.


Comment at: lib/Sema/SemaDecl.cpp:7283
@@ -7276,3 +7282,3 @@
   return PtrPtrKernelParam;
-return PointeeType.getAddressSpace() == 0 ? PrivatePtrKernelParam
-  : PtrKernelParam;
+// Now generice address space is added, we need to handle like this
+unsigned addrSpace = PointeeType.getAddressSpace();

Anastasia wrote:
> Why this code?
Removed.


http://reviews.llvm.org/D17438



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


Re: [PATCH] SemaCXX: Support templates in availability attributes

2016-02-22 Thread Duncan P. N. Exon Smith via cfe-commits

> On 2016-Feb-22, at 17:24, Manman Ren  wrote:
> 
> 
> 
>> On Feb 8, 2016, at 8:17 PM, Duncan P. N. Exon Smith  
>> wrote:
>> 
>> This patch adds support for templates in availability attributes.
>> - If the context for an availability diagnostic is a
>>   `FunctionTemplateDecl`, look through it to the `FunctionDecl`.
> 
>> AvailabilityResult Decl::getAvailability(std::string *Message) const {
>> +  if (auto *FTD = dyn_cast(this))
>> +return FTD->getTemplatedDecl()->getAvailability(Message);
>> +
>>   AvailabilityResult Result = AR_Available;
> 
> This looks generally correct to me.
> The UnavailableAttr is attached to the FunctionDecl, not the 
> FunctionTemplateDecl, so looking through sounds right.
> 
>> - Add `__has_feature(attribute_availability_in_templates)`.
>> 
>> Is there anything else I should be testing to be sure availability
>> works correctly in templates?
> 
> Maybe
> test()
> calling unavailable function from an unavailable template function
> calling an unavailable template function
> 
> I think these all work with the current compiler. But I am not sure if we 
> have existing test coverage.

Thanks for the ideas; let me know if you have any others.

Can you have a look at the new patch?

> Cheers,
> Manman
> 
>> I'm working on a patch to add
>> availability markup to the libc++ headers, and this is the only
>> problem I've hit so far.  Anyone have thoughts on other things I
>> should test?



0001-SemaCXX-Support-templates-in-availability-attributes.patch
Description: Binary data
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D16928: [OpenCL] Apply missing restrictions for Blocks in OpenCL v2.0

2016-02-22 Thread Xiuli PAN via cfe-commits
pxli168 accepted this revision.
pxli168 added a comment.
This revision is now accepted and ready to land.

Then there will be no problem.
I will change my patches as well.
LGTM!
Thanks.


http://reviews.llvm.org/D16928



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


Re: r261552 - [VFS] Add 'overlay-relative' field to YAML files

2016-02-22 Thread Sean Silva via cfe-commits
This or r261551 seem to be causing a build failure:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/527

-- Sean SIlva

On Mon, Feb 22, 2016 at 10:41 AM, Bruno Cardoso Lopes via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: bruno
> Date: Mon Feb 22 12:41:09 2016
> New Revision: 261552
>
> URL: http://llvm.org/viewvc/llvm-project?rev=261552=rev
> Log:
> [VFS] Add 'overlay-relative' field to YAML files
>
> The VFS overlay mapping between virtual paths and real paths is done
> through
> the 'external-contents' entries in YAML files, which contains hardcoded
> paths
> to the real files.
>
> When a module compilation crashes, headers are dumped into .cache/vfs
> directory and are mapped via the .cache/vfs/vfs.yaml. The script
> generated for reproduction uses -ivfsoverlay pointing to file to gather the
> mapping between virtual paths and files inside .cache/vfs.
> Currently, we
> are only capable of reproducing such crashes in the same machine as they
> happen, because of the hardcoded paths in 'external-contents'.
>
> To be able to reproduce a crash in another machine, this patch introduces
> a new
> option in the VFS yaml file called 'overlay-relative'. When it's equal to
> 'true' it means that the provided path to the YAML file through the
> -ivfsoverlay option should also be used to prefix the final path for every
> 'external-contents'.
>
> Example, given the invocation snippet "... -ivfsoverlay
> .cache/vfs/vfs.yaml" and the following entry in the yaml file:
>
> "overlay-relative": "true",
> "roots": [
> ...
>   "type": "directory",
>   "name": "/usr/include",
>   "contents": [
> {
>   "type": "file",
>   "name": "stdio.h",
>   "external-contents": "/usr/include/stdio.h"
> },
> ...
>
> Here, a file manager request for virtual "/usr/include/stdio.h", that will
> map
> into real path "//.cache/vfs/usr/include/stdio.h.
>
> This is a useful feature for debugging module crashes in machines other
> than
> the one where the error happened.
>
> Differential Revision: http://reviews.llvm.org/D17457
>
> rdar://problem/24499339
>
> Added:
> cfe/trunk/test/Modules/crash-vfs-relative-overlay.m
>   - copied, changed from r261551,
> cfe/trunk/test/Modules/crash-vfs-path-traversal.m
> Modified:
> cfe/trunk/include/clang/Basic/VirtualFileSystem.h
> cfe/trunk/lib/Basic/VirtualFileSystem.cpp
> cfe/trunk/lib/Frontend/CompilerInvocation.cpp
> cfe/trunk/lib/Frontend/ModuleDependencyCollector.cpp
> cfe/trunk/test/Modules/crash-vfs-path-symlink-component.m
> cfe/trunk/test/Modules/crash-vfs-path-traversal.m
>
> Modified: cfe/trunk/include/clang/Basic/VirtualFileSystem.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/VirtualFileSystem.h?rev=261552=261551=261552=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/VirtualFileSystem.h (original)
> +++ cfe/trunk/include/clang/Basic/VirtualFileSystem.h Mon Feb 22 12:41:09
> 2016
> @@ -310,6 +310,7 @@ llvm::sys::fs::UniqueID getNextVirtualUn
>  IntrusiveRefCntPtr
>  getVFSFromYAML(std::unique_ptr Buffer,
> llvm::SourceMgr::DiagHandlerTy DiagHandler,
> +   StringRef YAMLFilePath,
> void *DiagContext = nullptr,
> IntrusiveRefCntPtr ExternalFS =
> getRealFileSystem());
>
> @@ -323,6 +324,8 @@ struct YAMLVFSEntry {
>  class YAMLVFSWriter {
>std::vector Mappings;
>Optional IsCaseSensitive;
> +  Optional IsOverlayRelative;
> +  std::string OverlayDir;
>
>  public:
>YAMLVFSWriter() {}
> @@ -330,6 +333,11 @@ public:
>void setCaseSensitivity(bool CaseSensitive) {
>  IsCaseSensitive = CaseSensitive;
>}
> +  void setOverlayDir(StringRef OverlayDirectory) {
> +IsOverlayRelative = true;
> +OverlayDir.assign(OverlayDirectory.str());
> +  }
> +
>void write(llvm::raw_ostream );
>  };
>
>
> Modified: cfe/trunk/lib/Basic/VirtualFileSystem.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/VirtualFileSystem.cpp?rev=261552=261551=261552=diff
>
> ==
> --- cfe/trunk/lib/Basic/VirtualFileSystem.cpp (original)
> +++ cfe/trunk/lib/Basic/VirtualFileSystem.cpp Mon Feb 22 12:41:09 2016
> @@ -790,6 +790,7 @@ public:
>  /// All configuration options are optional.
>  ///   'case-sensitive': 
>  ///   'use-external-names': 
> +///   'overlay-relative': 
>  ///
>  /// Virtual directories are represented as
>  /// \verbatim
> @@ -832,6 +833,10 @@ class RedirectingFileSystem : public vfs
>std::vector Roots;
>/// \brief The file system to use for external references.
>IntrusiveRefCntPtr ExternalFS;
> +  /// If IsRelativeOverlay is set, this represents the directory
> +  /// path that should be prefixed to each 'external-contents' 

Re: r259975 - Fix a crash when emitting dbeug info for forward-declared scoped enums.

2016-02-22 Thread Eric Christopher via cfe-commits
Hi Adrian,

On Sat, Feb 20, 2016 at 1:18 PM Adrian Prantl  wrote:

> This had me puzzled for a second, but then I figured out what happened :-)
> The “crash” I quoted in the commit message really was an assertion
> failure, to be precise, the very assertion I relaxed in LLVM r259973 in
> order to be able to defer the building of the DeclContext implemented by
> this commit. Even with the assertion removed, I still believe that
> implementing it this way preferable, as it avoids creating the enum a
> second time.
>
> > On Feb 19, 2016, at 7:05 PM, Eric Christopher 
> wrote:
> >
> > Hi Adrian,
> >
> > I'm taking a look at this and can't duplicate using the testcase you
> gave without your patch(es) applied. It's also causing asserts in other
> code as you can have the forward decl left around and the CU isn't a valid
> context.
>
> Do you happen to have an example handy? I don’t quite understand the
> problem from the description — shouldn’t the temporary fwddecl be RAUWed
> unconditionally after the DeclContext is created?
>
>
I'd think so. It appears to get through to code generation unreplaced
though and...


> If you’re blocked on this we can definitely revert the change in
> CGDebugInfo (but not the testcase), I just would like to understand what’s
> going on.
>
>
I am a bit. I don't have a reduction at the moment small enough to debug
what's wrong with this and the current patch doesn't appear necessary so
I'm unable to debug the original problem at this point to try to help more.

-eric


> -- adrian
>
> > Can you take a look/revert until you've got a different testcase?
> There's not enough information in the commit to construct one up for you.
> >
> > Thanks!
> >
> > -eric
> >
> > On Fri, Feb 5, 2016 at 6:03 PM Adrian Prantl via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
> > Author: adrian
> > Date: Fri Feb  5 19:59:09 2016
> > New Revision: 259975
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=259975=rev
> > Log:
> > Fix a crash when emitting dbeug info for forward-declared scoped enums.
> > It is possible for enums to be created as part of their own
> > declcontext. We need to cache a placeholder to avoid the type being
> > created twice before hitting the cache.
> >
> > 
> >
> > Added:
> > cfe/trunk/test/CodeGenCXX/debug-info-scoped-class.cpp
> > Modified:
> > cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> >
> > Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=259975=259974=259975=diff
> >
> ==
> > --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
> > +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Fri Feb  5 19:59:09 2016
> > @@ -2051,13 +2051,25 @@ llvm::DIType *CGDebugInfo::CreateEnumTyp
> >// If this is just a forward declaration, construct an appropriately
> >// marked node and just return it.
> >if (isImportedFromModule || !ED->getDefinition()) {
> > -llvm::DIScope *EDContext = getDeclContextDescriptor(ED);
> >  llvm::DIFile *DefUnit = getOrCreateFile(ED->getLocation());
> > +
> > +// It is possible for enums to be created as part of their own
> > +// declcontext. We need to cache a placeholder to avoid the type
> being
> > +// created twice before hitting the cache.
> > +llvm::DIScope *EDContext = DBuilder.createReplaceableCompositeType(
> > +  llvm::dwarf::DW_TAG_enumeration_type, "", TheCU, DefUnit, 0);
> > +
> >  unsigned Line = getLineNumber(ED->getLocation());
> >  StringRef EDName = ED->getName();
> >  llvm::DIType *RetTy = DBuilder.createReplaceableCompositeType(
> >  llvm::dwarf::DW_TAG_enumeration_type, EDName, EDContext,
> DefUnit, Line,
> >  0, Size, Align, llvm::DINode::FlagFwdDecl, FullName);
> > +
> > +// Cache the enum type so it is available when building the
> declcontext
> > +// and replace the declcontect with the real thing.
> > +TypeCache[Ty].reset(RetTy);
> > +EDContext->replaceAllUsesWith(getDeclContextDescriptor(ED));
> > +
> >  ReplaceMap.emplace_back(
> >  std::piecewise_construct, std::make_tuple(Ty),
> >  std::make_tuple(static_cast(RetTy)));
> >
> > Added: cfe/trunk/test/CodeGenCXX/debug-info-scoped-class.cpp
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-scoped-class.cpp?rev=259975=auto
> >
> ==
> > --- cfe/trunk/test/CodeGenCXX/debug-info-scoped-class.cpp (added)
> > +++ cfe/trunk/test/CodeGenCXX/debug-info-scoped-class.cpp Fri Feb  5
> 19:59:09 2016
> > @@ -0,0 +1,15 @@
> > +// RUN: %clang_cc1 -emit-llvm -debug-info-kind=standalone -std=c++11 \
> > +// RUN:   -triple thumbv7-apple-ios %s -o - | FileCheck %s
> > +
> > +// This forward-declared scoped enum will be created while building its
> own
> > +// declcontext. Make sure it is 

Re: [PATCH] SemaCXX: Support templates in availability attributes

2016-02-22 Thread Manman Ren via cfe-commits


> On Feb 8, 2016, at 8:17 PM, Duncan P. N. Exon Smith  
> wrote:
> 
> This patch adds support for templates in availability attributes.
>  - If the context for an availability diagnostic is a
>`FunctionTemplateDecl`, look through it to the `FunctionDecl`.

>  AvailabilityResult Decl::getAvailability(std::string *Message) const {
> +  if (auto *FTD = dyn_cast(this))
> +return FTD->getTemplatedDecl()->getAvailability(Message);
> +
>AvailabilityResult Result = AR_Available;

This looks generally correct to me.
The UnavailableAttr is attached to the FunctionDecl, not the 
FunctionTemplateDecl, so looking through sounds right.

>  - Add `__has_feature(attribute_availability_in_templates)`.
> 
> Is there anything else I should be testing to be sure availability
> works correctly in templates?

Maybe
test()
calling unavailable function from an unavailable template function
calling an unavailable template function

I think these all work with the current compiler. But I am not sure if we have 
existing test coverage.

Cheers,
Manman

>  I'm working on a patch to add
> availability markup to the libc++ headers, and this is the only
> problem I've hit so far.  Anyone have thoughts on other things I
> should test?
> 
> <0001-SemaCXX-Support-templates-in-availability-attributes.patch>

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


Re: [PATCH] D17511: [analyzer] Make ObjCDeallocChecker path sensitive.

2016-02-22 Thread Anna Zaks via cfe-commits
zaks.anna added inline comments.


Comment at: lib/StaticAnalyzer/Checkers/CheckObjCDealloc.cpp:89
@@ -109,7 +88,3 @@
 
-static bool synthesizedPropertyRequiresRelease(const ObjCPropertyDecl *PD) {
-  // A synthesized property must be released if and only if the kind of setter
-  // was neither 'assign' or 'weak'.
-  ObjCPropertyDecl::SetterKind SK = PD->getSetterKind();
-  return (SK != ObjCPropertyDecl::Assign && SK != ObjCPropertyDecl::Weak);
-}
+//===--===//
+// ObjCDeallocChecker

Let's not use these comments blocks. We should use oxygen style comments.


Comment at: lib/StaticAnalyzer/Checkers/CheckObjCDealloc.cpp:161
@@ +160,3 @@
+
+// Diagnose when the class requires a -dealloc method and is missing one.
+void ObjCDeallocChecker::checkASTDecl(const ObjCImplementationDecl *D,

Use doxygen throughout. Please, mention that this is an AST check.


Comment at: lib/StaticAnalyzer/Checkers/CheckObjCDealloc.cpp:184
@@ -144,21 +183,3 @@
 
-  // Determine if the class subclasses NSObject.
-  IdentifierInfo* NSObjectII = ("NSObject");
-  IdentifierInfo* SenTestCaseII = ("SenTestCase");
-
-  for ( ; ID ; ID = ID->getSuperClass()) {
-IdentifierInfo *II = ID->getIdentifier();
-
-if (II == NSObjectII)
-  break;
-
-// FIXME: For now, ignore classes that subclass SenTestCase, as these don't
-// need to implement -dealloc.  They implement tear down in another way,
-// which we should try and catch later.
-//  http://llvm.org/bugs/show_bug.cgi?id=3187
-if (II == SenTestCaseII)
-  return;
-  }
-
-  if (!ID)
+  if (isSuppressedClass(ID))
 return;

Looks like we do not use this for the other checker. Is that the correct 
behavior? Seems like it.

Maybe we should reflect this in the method name.


Comment at: lib/StaticAnalyzer/Checkers/CheckObjCDealloc.cpp:198
@@ -179,2 +197,3 @@
   if (!MD) { // No dealloc found.
+const char* Name = "missing -dealloc";
 

We usually capitalize this.


Comment at: lib/StaticAnalyzer/Checkers/CheckObjCDealloc.cpp:249
@@ +248,3 @@
+// in that location has not changed.
+State = State->bindLoc(LValLoc.getValue(), InitialVal,
+   /*notifyChanges*/false);

I do not understand this.


Comment at: lib/StaticAnalyzer/Checkers/CheckObjCDealloc.cpp:261
@@ -255,4 +260,3 @@
 
-//===--===//
-// ObjCDeallocChecker
-//===--===//
+// If -dealloc is on the stack, handle the call if it is a release or a
+// nilling-out property setter.

I think it's worth adding "If we are in -dealloc or" ...


Comment at: lib/StaticAnalyzer/Checkers/CheckObjCDealloc.cpp:298
@@ +297,3 @@
+// releases.
+void ObjCDeallocChecker::checkPostObjCMessage(
+const ObjCMethodCall , CheckerContext ) const {

Add: "We have to release before a call to [super dealloc]."


Comment at: lib/StaticAnalyzer/Checkers/CheckObjCDealloc.cpp:383
@@ +382,3 @@
+// at, for example, both a return and at the end of of the function.
+State = State->remove(IvarSymbol);
+

Hopefully, this ensures that all symbols added in the function begin call are 
removed! The logic is slightly different than where we were adding these:
  getContainingObjCImpl(LCtx)->property_impls()



Comment at: lib/StaticAnalyzer/Checkers/CheckObjCDealloc.cpp:418
@@ +417,3 @@
+
+OS << " by a synthesized property but was not released in 'dealloc'";
+

This might be too long.. Maybe we could remove "instance variable"?


Comment at: lib/StaticAnalyzer/Checkers/CheckObjCDealloc.cpp:526
@@ +525,3 @@
+  MissingReleaseBugType.reset(
+  new BugType(this, "missing ivar release (leak)",
+  categories::MemoryCoreFoundationObjectiveC));

BugType names should be capitalized.


Comment at: lib/StaticAnalyzer/Checkers/CheckObjCDealloc.cpp:721
@@ +720,3 @@
+/// Returns true if the \param ID is a class in which -dealloc warnings
+/// should be suppressed.
+bool ObjCDeallocChecker::isSuppressedClass(const ObjCInterfaceDecl *ID) const {

We might need an annotation for this as well.


http://reviews.llvm.org/D17511



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


r261596 - Lex: Return "" when HeaderMap::lookupFilename fails

2016-02-22 Thread Duncan P. N. Exon Smith via cfe-commits
Author: dexonsmith
Date: Mon Feb 22 18:48:16 2016
New Revision: 261596

URL: http://llvm.org/viewvc/llvm-project?rev=261596=rev
Log:
Lex: Return "" when HeaderMap::lookupFilename fails

Change getString() to return Optional, and change
lookupFilename() to return an empty string if either one of the prefix
and suffix can't be found.

This is a more robust follow-up to r261461, but it's still not entirely
satisfactory.  Ideally we'd report that the header map is corrupt;
perhaps something for a follow-up.

Modified:
cfe/trunk/include/clang/Lex/HeaderMap.h
cfe/trunk/lib/Lex/HeaderMap.cpp
cfe/trunk/unittests/Lex/HeaderMapTest.cpp

Modified: cfe/trunk/include/clang/Lex/HeaderMap.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/HeaderMap.h?rev=261596=261595=261596=diff
==
--- cfe/trunk/include/clang/Lex/HeaderMap.h (original)
+++ cfe/trunk/include/clang/Lex/HeaderMap.h Mon Feb 22 18:48:16 2016
@@ -15,6 +15,7 @@
 #define LLVM_CLANG_LEX_HEADERMAP_H
 
 #include "clang/Basic/LLVM.h"
+#include "llvm/ADT/Optional.h"
 #include "llvm/Support/Compiler.h"
 #include "llvm/Support/MemoryBuffer.h"
 #include 
@@ -53,7 +54,10 @@ private:
   unsigned getEndianAdjustedWord(unsigned X) const;
   const HMapHeader () const;
   HMapBucket getBucket(unsigned BucketNo) const;
-  StringRef getString(unsigned StrTabIdx) const;
+
+  /// Look up the specified string in the string table.  If the string index is
+  /// not valid, return None.
+  Optional getString(unsigned StrTabIdx) const;
 };
 
 /// This class represents an Apple concept known as a 'header map'.  To the

Modified: cfe/trunk/lib/Lex/HeaderMap.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/HeaderMap.cpp?rev=261596=261595=261596=diff
==
--- cfe/trunk/lib/Lex/HeaderMap.cpp (original)
+++ cfe/trunk/lib/Lex/HeaderMap.cpp Mon Feb 22 18:48:16 2016
@@ -16,6 +16,7 @@
 #include "clang/Basic/CharInfo.h"
 #include "clang/Basic/FileManager.h"
 #include "llvm/ADT/SmallString.h"
+#include "llvm/Support/Compiler.h"
 #include "llvm/Support/DataTypes.h"
 #include "llvm/Support/MathExtras.h"
 #include "llvm/Support/MemoryBuffer.h"
@@ -144,15 +145,13 @@ HMapBucket HeaderMapImpl::getBucket(unsi
   return Result;
 }
 
-/// getString - Look up the specified string in the string table.  If the 
string
-/// index is not valid, it returns an empty string.
-StringRef HeaderMapImpl::getString(unsigned StrTabIdx) const {
+Optional HeaderMapImpl::getString(unsigned StrTabIdx) const {
   // Add the start of the string table to the idx.
   StrTabIdx += getEndianAdjustedWord(getHeader().StringsOffset);
 
   // Check for invalid index.
   if (StrTabIdx >= FileBuffer->getBufferSize())
-return "";
+return None;
 
   const char *Data = FileBuffer->getBufferStart() + StrTabIdx;
   unsigned MaxLen = FileBuffer->getBufferSize() - StrTabIdx;
@@ -160,7 +159,7 @@ StringRef HeaderMapImpl::getString(unsig
 
   // Check whether the buffer is null-terminated.
   if (Len == MaxLen && Data[Len - 1])
-return "";
+return None;
 
   return StringRef(Data, Len);
 }
@@ -177,13 +176,19 @@ LLVM_DUMP_METHOD void HeaderMapImpl::dum
   llvm::dbgs() << "Header Map " << getFileName() << ":\n  " << NumBuckets
<< ", " << getEndianAdjustedWord(Hdr.NumEntries) << "\n";
 
+  auto getStringOrInvalid = [this](unsigned Id) -> StringRef {
+if (Optional S = getString(Id))
+  return *S;
+return "";
+  };
+
   for (unsigned i = 0; i != NumBuckets; ++i) {
 HMapBucket B = getBucket(i);
 if (B.Key == HMAP_EmptyBucketKey) continue;
 
-StringRef Key= getString(B.Key);
-StringRef Prefix = getString(B.Prefix);
-StringRef Suffix = getString(B.Suffix);
+StringRef Key = getStringOrInvalid(B.Key);
+StringRef Prefix = getStringOrInvalid(B.Prefix);
+StringRef Suffix = getStringOrInvalid(B.Suffix);
 llvm::dbgs() << "  " << i << ". " << Key << " -> '" << Prefix << "' '"
  << Suffix << "'\n";
   }
@@ -216,16 +221,22 @@ StringRef HeaderMapImpl::lookupFilename(
 if (B.Key == HMAP_EmptyBucketKey) return StringRef(); // Hash miss.
 
 // See if the key matches.  If not, probe on.
-if (!Filename.equals_lower(getString(B.Key)))
+Optional Key = getString(B.Key);
+if (LLVM_UNLIKELY(!Key))
+  continue;
+if (!Filename.equals_lower(*Key))
   continue;
 
 // If so, we have a match in the hash table.  Construct the destination
 // path.
-StringRef Prefix = getString(B.Prefix);
-StringRef Suffix = getString(B.Suffix);
+Optional Prefix = getString(B.Prefix);
+Optional Suffix = getString(B.Suffix);
+
 DestPath.clear();
-DestPath.append(Prefix.begin(), Prefix.end());
-DestPath.append(Suffix.begin(), Suffix.end());
+if (LLVM_LIKELY(Prefix && Suffix)) {
+  DestPath.append(Prefix->begin(), Prefix->end());
+ 

Re: [PATCH] D17248: [Sema] PR26444 fix crash when alignment value is >= 2**16

2016-02-22 Thread don hinton via cfe-commits
hintonda added a comment.

Thanks David.  Btw, could you commit it for me?  I don't have commit access.


http://reviews.llvm.org/D17248



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


Re: [PATCH] D17248: [Sema] PR26444 fix crash when alignment value is >= 2**16

2016-02-22 Thread David Majnemer via cfe-commits
majnemer accepted this revision.
majnemer added a comment.
This revision is now accepted and ready to land.

LGTM


http://reviews.llvm.org/D17248



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


Re: [PATCH] D16821: Add whole-program vtable optimization feature to Clang.

2016-02-22 Thread Peter Collingbourne via cfe-commits
On Mon, Feb 22, 2016 at 03:59:01PM -0800, Mehdi Amini wrote:
> 
> > On Feb 22, 2016, at 3:47 PM, Peter Collingbourne  wrote:
> > 
> > On Mon, Feb 22, 2016 at 01:38:27PM -0800, Pete Cooper wrote:
> >> 
> >>> On Feb 22, 2016, at 1:30 PM, Peter Collingbourne  wrote:
> >>> 
> >>> One thing that I'd like to do (and this would help CFI as well) is to 
> >>> specifically recognize cases like this:
> >>> 
> >>> ```
> >>> struct B {
> >>> virtual void vf();
> >>> };
> >>> 
> >>> struct D1 {
> >>> };
> >> I assume you meant D1 : B here?
> > 
> > Yes.
> > 
> >>> 
> >>> struct D2 : B {
> >>> virtual void vf();
> >>> };
> >>> 
> >>> void f(D1 *d) {
> >>> d->vf();
> >>> }
> >>> ```
> >>> 
> >>> In this case I'd like to devirtualize the virtual call in `f()` to 
> >>> `B::vf()`. But because the implicit cast to `B` in `f()` removes the 
> >>> information that `d` cannot be of type `D2`, we cannot eliminate 
> >>> `D2::vf()` as a candidate target (see also `test/cfi/sibling.cpp` in the 
> >>> CFI test suite).
> >>> 
> >>> Although this could possibly be emitted and pattern matched at the IR 
> >>> level, it seems simpler (and would probably catch enough cases) to have 
> >>> Clang look through the implicit cast when IR gen'ing for the call.
> >> So my devirtualizer dealt with this by marking each call site with the 
> >> most specific class we know of in the hierarchy.  
> >> 
> >> In this case, then class hierarchy would contain the pairs: (B, B), (D1, 
> >> B), (D2, B).
> >> 
> >> The call site in f() would be tagged with (D1, B) not (B, B).  Then, when 
> >> we are in the pass, we look at the subclasses from (D1, B), see that there 
> >> are none (or that none override vf), and devirtualize to B::vf().
> >> 
> >> If that isn’t possible in the current solution (I didn’t check), then it 
> >> should be easy enough to add.  I certainly don’t think any of the current 
> >> implementation would be hard to adapt to support this use case.
> > 
> > I think it should be possible to do something along those lines. After 
> > looking
> > through the implicit cast we would discover that the most derived type is D1
> > (I guess this is what your implementation is doing?) and perform the check
> > against that class's bitset, but only if the implicit cast did not involve
> > a pointer adjustment.
> 
> The implementation we have (at least the one I have) generates the most 
> precise information directly from the frontend. You have all the informations 
> at the call site in the clang AST when you access the VTable, there is no 
> cast or anything on the way.

This is what the AST dump for my function looks like for my example:

`-FunctionDecl 0x2d05500  line:12:6 f 'void (struct D1 *)'
  |-ParmVarDecl 0x2d05438  col:12 used d 'struct D1 *'
  `-CompoundStmt 0x2d07740 
`-CXXMemberCallExpr 0x2d05668  'void'
  `-MemberExpr 0x2d05630  '' ->vf 
0x2cb8ce0
`-ImplicitCastExpr 0x2d07720  'struct B *' 

  `-ImplicitCastExpr 0x2d05618  'struct D1 *' 
`-DeclRefExpr 0x2d055f0  'struct D1 *' lvalue ParmVar 
0x2d05438 'd' 'struct D1 *'

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


Re: [PATCH] D17511: [analyzer] Make ObjCDeallocChecker path sensitive.

2016-02-22 Thread Devin Coughlin via cfe-commits
dcoughlin added a subscriber: cfe-commits.
dcoughlin updated this revision to Diff 48750.
dcoughlin added a comment.

Provide diff with context. Apologies for leaving that out.


http://reviews.llvm.org/D17511

Files:
  lib/StaticAnalyzer/Checkers/CheckObjCDealloc.cpp
  test/Analysis/DeallocMissingRelease.m
  test/Analysis/MissingDealloc.m
  test/Analysis/PR2978.m
  test/Analysis/properties.m

Index: test/Analysis/properties.m
===
--- test/Analysis/properties.m
+++ test/Analysis/properties.m
@@ -1,5 +1,5 @@
-// RUN: %clang_cc1 -analyze -analyzer-checker=core,osx.cocoa.RetainCount,debug.ExprInspection -analyzer-store=region -verify -Wno-objc-root-class %s
-// RUN: %clang_cc1 -analyze -analyzer-checker=core,osx.cocoa.RetainCount,debug.ExprInspection -analyzer-store=region -verify -Wno-objc-root-class -fobjc-arc %s
+// RUN: %clang_cc1 -analyze -analyzer-checker=core,osx.cocoa.RetainCount,alpha.osx.cocoa.Dealloc,debug.ExprInspection -analyzer-store=region -verify -Wno-objc-root-class %s
+// RUN: %clang_cc1 -analyze -analyzer-checker=core,osx.cocoa.RetainCount,alpha.osx.cocoa.Dealloc,debug.ExprInspection -analyzer-store=region -verify -Wno-objc-root-class -fobjc-arc %s
 
 void clang_analyzer_eval(int);
 
@@ -22,6 +22,7 @@
 -(id)copy;
 -(id)retain;
 -(oneway void)release;
+-(void)dealloc;
 @end
 @interface NSString : NSObject 
 - (NSUInteger)length;
@@ -138,6 +139,14 @@
 
 @implementation Person
 @synthesize name = _name;
+
+-(void)dealloc {
+#if !__has_feature(objc_arc)
+  self.name = [[NSString alloc] init]; // expected-warning {{leak}}
+
+  [super dealloc]; // expected-warning {{The '_name' instance variable in 'Person' was retained by a synthesized property but was not released in 'dealloc'}}
+#endif
+}
 @end
 
 #if !__has_feature(objc_arc)
Index: test/Analysis/PR2978.m
===
--- test/Analysis/PR2978.m
+++ test/Analysis/PR2978.m
@@ -5,7 +5,7 @@
 
 @interface NSObject
 - (void)release;
-- dealloc;
+- (void)dealloc;
 @end
 
 @interface MyClass : NSObject {
@@ -19,55 +19,88 @@
   id _M;
   id _P;
   id _Q;
+  id _R;
+  id _S;
   id _V;
   id _W;
+
+  MyClass *_other;
 }
 @property(retain) id X;
 @property(retain) id Y;
 @property(assign) id Z;
 @property(assign) id K;
 @property(weak) id L;
 @property(readonly) id N;
 @property(retain) id M;
-@property(weak) id P; // expected-warning {{'_P' instance variable in 'MyClass' was not retained by a synthesized property but was released in 'dealloc'}}
+@property(weak) id P;
 @property(weak) id Q;
+@property(retain) id R;
+@property(weak, readonly) id S;
+
+@property(assign, readonly) id T; // Shadowed in class extension
 
 @property(retain) id V;
 @property(retain) id W;
 -(id) O;
 -(void) setO: (id) arg;
 @end
 
+@interface MyClass ()
+// Shadows T to make it readwrite internally but readonly externally.
+@property(assign, readwrite) id T;
+@end
+
 @implementation MyClass
 @synthesize X = _X;
-@synthesize Y = _Y; // expected-warning{{The '_Y' instance variable in 'MyClass' was retained by a synthesized property but was not released in 'dealloc'}}
-@synthesize Z = _Z; // expected-warning{{The '_Z' instance variable in 'MyClass' was not retained by a synthesized property but was released in 'dealloc'}}
+@synthesize Y = _Y;
+@synthesize Z = _Z;
 @synthesize K = _K;
-@synthesize L = _L; // no-warning
-@synthesize N = _N; // no-warning
+@synthesize L = _L;
+@synthesize N = _N;
 @synthesize M = _M;
-@synthesize Q = _Q; // expected-warning {{'_Q' instance variable in 'MyClass' was not retained by a synthesized property but was released in 'dealloc'}}
+@synthesize Q = _Q;
+@synthesize R = _R;
 @synthesize V = _V;
-@synthesize W = _W; // expected-warning{{The '_W' instance variable in 'MyClass' was retained by a synthesized property but was not released in 'dealloc'}}
+@synthesize W = _W;
 
 -(id) O{ return 0; }
 -(void) setO:(id)arg { }
 
-- (id)dealloc
+
+-(void) releaseInHelper {
+  [_R release]; // no-warning
+  _R = @"Hi";
+}
+
+- (void)dealloc
 {
+
   [_X release];
-  [_Z release];
+  [_Z release]; // expected-warning{{The '_Z' instance variable in 'MyClass' was synthesized for an assign, readwrite property but was released in 'dealloc'}}
+  [_T release]; // no-warning
+
+  [_other->_Z release]; // no-warning
   [_N release];
-  
+
   self.M = 0; // This will release '_M'
   [self setV:0]; // This will release '_V'
   [self setW:@"newW"]; // This will release '_W', but retain the new value
-  self.O = 0; // no-warning  
 
-  [_Q release];
+  [_S release]; // expected-warning {{The '_S' instance variable in 'MyClass' was synthesized for a weak property but was released in 'dealloc'}}
+
+  self.O = 0; // no-warning
+
+  [_Q release]; // expected-warning {{The '_Q' instance variable in 'MyClass' was synthesized for a weak property but was released in 'dealloc'}}
+
   self.P = 0;
+
+  [self releaseInHelper];
+
 

Re: [PATCH] D16821: Add whole-program vtable optimization feature to Clang.

2016-02-22 Thread Mehdi Amini via cfe-commits

> On Feb 22, 2016, at 3:47 PM, Peter Collingbourne  wrote:
> 
> On Mon, Feb 22, 2016 at 01:38:27PM -0800, Pete Cooper wrote:
>> 
>>> On Feb 22, 2016, at 1:30 PM, Peter Collingbourne  wrote:
>>> 
>>> One thing that I'd like to do (and this would help CFI as well) is to 
>>> specifically recognize cases like this:
>>> 
>>> ```
>>> struct B {
>>> virtual void vf();
>>> };
>>> 
>>> struct D1 {
>>> };
>> I assume you meant D1 : B here?
> 
> Yes.
> 
>>> 
>>> struct D2 : B {
>>> virtual void vf();
>>> };
>>> 
>>> void f(D1 *d) {
>>> d->vf();
>>> }
>>> ```
>>> 
>>> In this case I'd like to devirtualize the virtual call in `f()` to 
>>> `B::vf()`. But because the implicit cast to `B` in `f()` removes the 
>>> information that `d` cannot be of type `D2`, we cannot eliminate `D2::vf()` 
>>> as a candidate target (see also `test/cfi/sibling.cpp` in the CFI test 
>>> suite).
>>> 
>>> Although this could possibly be emitted and pattern matched at the IR 
>>> level, it seems simpler (and would probably catch enough cases) to have 
>>> Clang look through the implicit cast when IR gen'ing for the call.
>> So my devirtualizer dealt with this by marking each call site with the most 
>> specific class we know of in the hierarchy.  
>> 
>> In this case, then class hierarchy would contain the pairs: (B, B), (D1, B), 
>> (D2, B).
>> 
>> The call site in f() would be tagged with (D1, B) not (B, B).  Then, when we 
>> are in the pass, we look at the subclasses from (D1, B), see that there are 
>> none (or that none override vf), and devirtualize to B::vf().
>> 
>> If that isn’t possible in the current solution (I didn’t check), then it 
>> should be easy enough to add.  I certainly don’t think any of the current 
>> implementation would be hard to adapt to support this use case.
> 
> I think it should be possible to do something along those lines. After looking
> through the implicit cast we would discover that the most derived type is D1
> (I guess this is what your implementation is doing?) and perform the check
> against that class's bitset, but only if the implicit cast did not involve
> a pointer adjustment.

The implementation we have (at least the one I have) generates the most precise 
information directly from the frontend. You have all the informations at the 
call site in the clang AST when you access the VTable, there is no cast or 
anything on the way.

-- 
Mehdi


> 
> This won't be as precise as it could be in the presence of multiple 
> inheritance
> (which I guess must be why your metadata is also tracking base classes),
> but I think that can be a separate metadata enhancement.
> 
> Thanks,
> -- 
> Peter

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


Re: [PATCH] D16821: Add whole-program vtable optimization feature to Clang.

2016-02-22 Thread Peter Collingbourne via cfe-commits
On Mon, Feb 22, 2016 at 01:38:27PM -0800, Pete Cooper wrote:
> 
> > On Feb 22, 2016, at 1:30 PM, Peter Collingbourne  wrote:
> > 
> > One thing that I'd like to do (and this would help CFI as well) is to 
> > specifically recognize cases like this:
> > 
> > ```
> > struct B {
> >  virtual void vf();
> > };
> > 
> > struct D1 {
> > };
> I assume you meant D1 : B here?

Yes.

> > 
> > struct D2 : B {
> >  virtual void vf();
> > };
> > 
> > void f(D1 *d) {
> >  d->vf();
> > }
> > ```
> > 
> > In this case I'd like to devirtualize the virtual call in `f()` to 
> > `B::vf()`. But because the implicit cast to `B` in `f()` removes the 
> > information that `d` cannot be of type `D2`, we cannot eliminate `D2::vf()` 
> > as a candidate target (see also `test/cfi/sibling.cpp` in the CFI test 
> > suite).
> > 
> > Although this could possibly be emitted and pattern matched at the IR 
> > level, it seems simpler (and would probably catch enough cases) to have 
> > Clang look through the implicit cast when IR gen'ing for the call.
> So my devirtualizer dealt with this by marking each call site with the most 
> specific class we know of in the hierarchy.  
> 
> In this case, then class hierarchy would contain the pairs: (B, B), (D1, B), 
> (D2, B).
> 
> The call site in f() would be tagged with (D1, B) not (B, B).  Then, when we 
> are in the pass, we look at the subclasses from (D1, B), see that there are 
> none (or that none override vf), and devirtualize to B::vf().
> 
> If that isn’t possible in the current solution (I didn’t check), then it 
> should be easy enough to add.  I certainly don’t think any of the current 
> implementation would be hard to adapt to support this use case.

I think it should be possible to do something along those lines. After looking
through the implicit cast we would discover that the most derived type is D1
(I guess this is what your implementation is doing?) and perform the check
against that class's bitset, but only if the implicit cast did not involve
a pointer adjustment.

This won't be as precise as it could be in the presence of multiple inheritance
(which I guess must be why your metadata is also tracking base classes),
but I think that can be a separate metadata enhancement.

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


[PATCH] D17528: [analyzer] Warn on use of 'self' after call to to [super dealloc].

2016-02-22 Thread Devin Coughlin via cfe-commits
dcoughlin created this revision.
dcoughlin added a reviewer: zaks.anna.
dcoughlin added a subscriber: cfe-commits.

Referring to 'self' after  a call to [super dealloc] is a use-after-free in 
Objective-C because NSObject's -dealloc frees the memory pointed to by self. 
This patch extends the ObjCSuperDeallocChecker to catch this error.

rdar://problem/6953275



http://reviews.llvm.org/D17528

Files:
  lib/StaticAnalyzer/Checkers/ObjCSuperDeallocChecker.cpp
  test/Analysis/DeallocUseAfterFreeErrors.m

Index: test/Analysis/DeallocUseAfterFreeErrors.m
===
--- test/Analysis/DeallocUseAfterFreeErrors.m
+++ test/Analysis/DeallocUseAfterFreeErrors.m
@@ -35,8 +35,9 @@
   return self;
 }
 - (void)dealloc {
-  [super dealloc];
-  [_ivar release];
+  [super dealloc]; // expected-note {{[super dealloc] called here}}
+  [_ivar release]; // expected-warning {{use of 'self' after it is freed with call to [super dealloc]}}
+  // expected-note@-1 {{use of 'self' after it is freed with call to [super dealloc]}}
 }
 @end
 
@@ -54,8 +55,9 @@
   return self;
 }
 - (void)dealloc {
-  [super dealloc];
-  _delegate = nil;
+  [super dealloc]; // expected-note {{[super dealloc] called here}}
+  _delegate = nil; // expected-warning {{use of 'self' after it is freed with call to [super dealloc]}}
+  // expected-note@-1 {{use of 'self' after it is freed with call to [super dealloc]}}
 }
 @end
 
@@ -72,8 +74,9 @@
   return self;
 }
 - (void)dealloc {
-  [super dealloc];
-  self.ivar = nil;
+  [super dealloc]; // expected-note {{[super dealloc] called here}}
+  self.ivar = nil; // expected-warning {{use of 'self' after it is freed with call to [super dealloc]}}
+  // expected-note@-1 {{use of 'self' after it is freed with call to [super dealloc]}}
 }
 @end
 
@@ -90,8 +93,9 @@
   return self;
 }
 - (void)dealloc {
-  [super dealloc];
-  self.delegate = nil;
+  [super dealloc]; // expected-note {{[super dealloc] called here}}
+  self.delegate = nil; // expected-warning {{use of 'self' after it is freed with call to [super dealloc]}}
+  // expected-note@-1 {{use of 'self' after it is freed with call to [super dealloc]}}
 }
 @end
 
@@ -103,8 +107,9 @@
 - (void)_invalidate {
 }
 - (void)dealloc {
-  [super dealloc];
-  [self _invalidate];
+  [super dealloc]; // expected-note {{[super dealloc] called here}}
+  [self _invalidate]; // expected-warning {{use of 'self' after it is freed with call to [super dealloc]}}
+  // expected-note@-1 {{use of 'self' after it is freed with call to [super dealloc]}}
 }
 @end
 
@@ -117,8 +122,23 @@
 
 @implementation SuperDeallocThenCallNonObjectiveCMethodClass
 - (void)dealloc {
-  [super dealloc];
-  _invalidate(self);
+  [super dealloc]; // expected-note {{[super dealloc] called here}}
+  _invalidate(self); // expected-warning {{use of 'self' after it is freed with call to [super dealloc]}}
+  // expected-note@-1 {{use of 'self' after it is freed with call to [super dealloc]}}
+}
+@end
+
+@interface SuperDeallocThenCallObjectiveClassMethodClass : NSObject { }
+@end
+
+@implementation SuperDeallocThenCallObjectiveClassMethodClass
++ (void) invalidate:(id)arg; {
+}
+
+- (void)dealloc {
+  [super dealloc]; // expected-note {{[super dealloc] called here}}
+  [SuperDeallocThenCallObjectiveClassMethodClass invalidate:self]; // expected-warning {{use of 'self' after it is freed with call to [super dealloc]}}
+  // expected-note@-1 {{use of 'self' after it is freed with call to [super dealloc]}}
 }
 @end
 
@@ -132,13 +152,14 @@
 - (void)_invalidate {
 }
 - (void)dealloc {
-  if (_ivar) {
+  if (_ivar) { // expected-note {{Taking false branch}}
 [_ivar release];
 [super dealloc];
 return;
   }
-  [super dealloc];
-  [self _invalidate];
+  [super dealloc];// expected-note {{[super dealloc] called here}}
+  [self _invalidate]; // expected-warning {{use of 'self' after it is freed with call to [super dealloc]}}
+  // expected-note@-1 {{use of 'self' after it is freed with call to [super dealloc]}}
 }
 @end
 
@@ -244,11 +265,15 @@
 // Do not warn about calling [super dealloc] twice if when the analyzer has
 // inlined the call to its super deallocator.
 
-@interface SuperClassCallingSuperDealloc : NSObject
+@interface SuperClassCallingSuperDealloc : NSObject {
+  NSObject *_ivar;
+}
 @end
 
 @implementation SuperClassCallingSuperDealloc
 - (void)dealloc; {
+  [_ivar release]; // no-warning
+
   [super dealloc];
 }
 @end
@@ -291,8 +316,8 @@
 
 - (void)dealloc; {
   [super dealloc]; // expected-note {{[super dealloc] called here}}
-  [self anotherMethod];
-  [super dealloc]; // expected-warning {{[super dealloc] should not be called multiple times}}
-  // expected-note@-1 {{[super dealloc] should not be called multiple times}}
+  [self anotherMethod]; // expected-warning {{use of 'self' after it is freed with call to [super dealloc]}}
+  // expected-note@-1 {{use of 'self' after it is freed with call to 

Re: [PATCH] D17248: [Sema] PR26444 fix crash when alignment value is >= 2**16

2016-02-22 Thread don hinton via cfe-commits
hintonda updated this revision to Diff 48742.
hintonda added a comment.

Added comment
Added comment to test file.


http://reviews.llvm.org/D17248

Files:
  lib/CodeGen/CGValue.h
  test/Sema/attr-aligned.c

Index: test/Sema/attr-aligned.c
===
--- test/Sema/attr-aligned.c
+++ test/Sema/attr-aligned.c
@@ -3,6 +3,9 @@
 int x __attribute__((aligned(3))); // expected-error {{requested alignment is 
not a power of 2}}
 int y __attribute__((aligned(1 << 29))); // expected-error {{requested 
alignment must be 268435456 bytes or smaller}}
 
+// PR26444
+int y __attribute__((aligned(1 << 28)));
+
 // PR3254
 short g0[3] __attribute__((aligned));
 short g0_chk[__alignof__(g0) == 16 ? 1 : -1]; 
Index: lib/CodeGen/CGValue.h
===
--- lib/CodeGen/CGValue.h
+++ lib/CodeGen/CGValue.h
@@ -445,7 +445,7 @@
   // Qualifiers
   Qualifiers Quals;
 
-  unsigned short Alignment;
+  unsigned Alignment;
 
   /// DestructedFlag - This is set to true if some external code is
   /// responsible for setting up a destructor for the slot.  Otherwise


Index: test/Sema/attr-aligned.c
===
--- test/Sema/attr-aligned.c
+++ test/Sema/attr-aligned.c
@@ -3,6 +3,9 @@
 int x __attribute__((aligned(3))); // expected-error {{requested alignment is not a power of 2}}
 int y __attribute__((aligned(1 << 29))); // expected-error {{requested alignment must be 268435456 bytes or smaller}}
 
+// PR26444
+int y __attribute__((aligned(1 << 28)));
+
 // PR3254
 short g0[3] __attribute__((aligned));
 short g0_chk[__alignof__(g0) == 16 ? 1 : -1]; 
Index: lib/CodeGen/CGValue.h
===
--- lib/CodeGen/CGValue.h
+++ lib/CodeGen/CGValue.h
@@ -445,7 +445,7 @@
   // Qualifiers
   Qualifiers Quals;
 
-  unsigned short Alignment;
+  unsigned Alignment;
 
   /// DestructedFlag - This is set to true if some external code is
   /// responsible for setting up a destructor for the slot.  Otherwise
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Buildbot numbers for week of 2/14/2016 - 2/20/2016

2016-02-22 Thread Galina Kistanova via cfe-commits
Hello everyone,

Below are some buildbot numbers for the last week of 2/14/2016 - 2/20/2016.

Thanks

Galina



"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green):

 buildername   | builds |
changes | status change ratio
---++-+-
 perf-x86_64-penryn-O3-polly   | 78 |
40 |51.3
 sanitizer-x86_64-linux|121 |
31 |25.6
 lldb-x86_64-darwin-13.4   | 88 |
18 |20.5
 libcxx-libcxxabi-x86_64-linux-debian-noexceptions | 10 |
2 |20.0
 lldb-x86_64-ubuntu-14.04-android  |115 |
23 |20.0
 lld-x86_64-win7   |149 |
25 |16.8
 clang-cmake-armv7-a15-selfhost-neon   | 24 |
4 |16.7
 clang-ppc64le-linux-lnt   |148 |
24 |16.2
 clang-cmake-aarch64-full  | 40 |
6 |15.0
 clang-x64-ninja-win7  |174 |
22 |12.6
 clang-x86-win2008-selfhost| 96 |
12 |12.5
 clang-cmake-thumbv7-a15-full-sh   | 24 |
3 |12.5
 lldb-windows7-android |136 |
17 |12.5
 sanitizer-x86_64-linux-bootstrap  | 59 |
7 |11.9
 lldb-x86_64-ubuntu-14.04-cmake|218 |
24 |11.0
 llvm-clang-lld-x86_64-debian-fast |178 |
18 |10.1
 libcxx-libcxxabi-x86_64-linux-ubuntu-gcc49-cxx11  | 11 |
1 | 9.1
 clang-ppc64le-linux-multistage| 60 |
5 | 8.3
 clang-cmake-aarch64-quick |159 |
12 | 7.5
 clang-ppc64le-linux   |239 |
18 | 7.5
 clang-ppc64be-linux-lnt   |241 |
16 | 6.6
 clang-ppc64be-linux   |280 |
18 | 6.4
 clang-x86_64-debian-fast  |128 |
8 | 6.3
 clang-cmake-mips  | 97 |
6 | 6.2
 clang-cmake-armv7-a15-selfhost| 33 |
2 | 6.1
 clang-cmake-aarch64-42vma |166 |
10 | 6.0
 sanitizer-x86_64-linux-fast   |191 |
11 | 5.8
 clang-s390x-linux |279 |
16 | 5.7
 clang-bpf-build   |296 |
16 | 5.4
 clang-hexagon-elf |114 |
6 | 5.3
 clang-atom-d525-fedora-rel|102 |
5 | 4.9
 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast  |343 |
16 | 4.7
 clang-cmake-armv7-a15 |209 |
9 | 4.3
 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast|342 |
14 | 4.1
 clang-cmake-thumbv7-a15   |226 |
9 | 4.0
 llvm-mips-linux   | 50 |
2 | 4.0
 clang-cmake-armv7-a15-full|160 |
5 | 3.1
 perf-x86_64-penryn-O3-polly-unprofitable  |225 |
6 | 2.7
 sanitizer-windows |330 |
9 | 2.7
 perf-x86_64-penryn-O3 | 76 |
2 | 2.6
 sanitizer-ppc64le-linux   |115 |
3 | 2.6
 sanitizer-x86_64-linux-autoconf   |303 |
8 | 2.6
 clang-ppc64be-linux-multistage|210 |
5 | 2.4
 sanitizer-x86_64-linux-fuzzer |201 |
4 | 2.0
 lldb-amd64-ninja-freebsd11|301 |
6 | 2.0
 lldb-x86-windows-msvc2015 |216 |
4 | 1.9
 clang-x86_64-linux-abi-test   |301 |
4 | 1.3
 perf-x86_64-penryn-O3-polly-parallel-fast |230 |
2 | 0.9
 polly-amd64-linux  

Re: [PATCH] D17484: [clang-tidy] introduce modernize-deprecated-headers check

2016-02-22 Thread Alexander Kornienko via cfe-commits
alexfh added inline comments.


Comment at: clang-tidy/modernize/DeprecatedHeadersCheck.cpp:78
@@ +77,3 @@
+  if (LangOpts.CPlusPlus11) {
+std::vector> Cxx11DeprecatedHeaders = {
+{"fenv.h", "cfenv"},

This can be done without STL algorithms and lambdas:

  for (const auto  : {{"fenv.h", "cfenv"}, ...})
CStyledHeaderToCxx.insert(Pair);

(didn't actually try this, so it might need some massaging, e.g. 
`std::pair<>` instead of auto).


Comment at: clang-tidy/modernize/DeprecatedHeadersCheck.cpp:104
@@ +103,3 @@
+  if (CStyledHeaderToCxx.count(FileName) != 0) {
+std::string Replacement = "<" + CStyledHeaderToCxx[FileName] + ">";
+Check.diag(FilenameRange.getBegin(), "including deprecated C++ header")

A usual way to concatenate strings in LLVM is to use `llvm::Twine`:

  std::string Replacement = (llvm::Twine("<") + ... + ...).str();


Comment at: clang-tidy/modernize/DeprecatedHeadersCheck.cpp:105
@@ +104,3 @@
+std::string Replacement = "<" + CStyledHeaderToCxx[FileName] + ">";
+Check.diag(FilenameRange.getBegin(), "including deprecated C++ header")
+<< FixItHint::CreateReplacement(FilenameRange.getAsRange(),

The message should name the header it complains about and suggest the 
replacement (in words, not only by attaching a fix. Something along the lines 
of:

  "inclusion of  a deprecated C++ header '%0'; consider including '%1' instead"


Comment at: test/clang-tidy/modernize-deprecated-headers-cxx03.cpp:32
@@ +31,3 @@
+
+// CHECK-MESSAGES: :[[@LINE-29]]:10: warning: including deprecated C++ header 
[modernize-deprecated-headers]
+// CHECK-MESSAGES: :[[@LINE-29]]:10: warning: including deprecated C++ header 
[modernize-deprecated-headers]

We usually specify each unique diagnostic message completely in one CHECK line 
and truncate repeated parts (e.g. the check name in brackets) in all other 
CHECK lines to make tests easier to read.


http://reviews.llvm.org/D17484



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


Re: [PATCH] D17516: AMDGPU: Verify subtarget specific builtins

2016-02-22 Thread Matt Arsenault via cfe-commits
arsenm added inline comments.


Comment at: lib/Basic/Targets.cpp:2059-2063
@@ +2058,7 @@
+
+  if (Has16BitInsts)
+Features["16-bit-insts"] = true;
+
+  if (hasSMemRealTime)
+Features["s-memrealtime"] = true;
+

echristo wrote:
> This is typically more of the "move the cpu checks down here" area from what 
> you'd have above. Also you're not calling the target independent version of 
> initFeatureMap - is that done on purpose?
Not sure what you mean exactly by "move the cpu checks down here". Do you mean 
setting all of the feature has* member variables should be moved out of the 
AMDGPUTargetInfo constructor + setCPU into here?

That was not done on purpose. I'm pretty confused about what all of these 
functions are for. I kind of expected all of this to automatically work from 
the target's set of defined features known from the backend. There seem to be a 
set of functions for manually parsing user specified features on a function and 
for those implied by the subtarget. Why is initFeatureMap separate from 
handleTargetFeatures? initFeatureMap seems to be almost the same thing with the 
addition of the CPU features. It's not clear to me what the difference between 
hasFeature and validateCpuSupports is supposed to mean, or why 
setFeatureEnabled is virtual.



http://reviews.llvm.org/D17516



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


Re: r261574 - [ASTMatchers] Add matcher hasAnyName.

2016-02-22 Thread Samuel Benzaquen via cfe-commits
On Mon, Feb 22, 2016 at 5:27 PM, Hans Wennborg  wrote:

> On Mon, Feb 22, 2016 at 1:13 PM, Samuel Benzaquen via cfe-commits
>  wrote:
> > Author: sbenza
> > Date: Mon Feb 22 15:13:02 2016
> > New Revision: 261574
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=261574=rev
> > Log:
> > [ASTMatchers] Add matcher hasAnyName.
> >
> > Summary: Add matcher hasAnyName as an optimization over
> anyOf(hasName(),...)
> >
> > Reviewers: alexfh
> >
> > Subscribers: klimek, cfe-commits
> >
> > Differential Revision: http://reviews.llvm.org/D17163
>
> I've tried to fix the Visual Studio build in r261583. Please take a
> look to make sure the fixes seem reasonable.
>

Sorry about that. I always forget that we can't use brace init lists in
LLVM yet.
Yes. That fix is correct. It would be better to move the vector to avoid an
extra copy.


>
>
> > +++ cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h Mon Feb 22
> 15:13:02 2016
> > @@ -1844,11 +1844,24 @@ inline internal::Matcher sizeOfExp
> >  /// \code
> >  ///   namespace a { namespace b { class X; } }
> >  /// \endcode
> > -inline internal::Matcher hasName(std::string Name) {
> > -  return internal::Matcher(
> > -  new internal::HasNameMatcher(std::move(Name)));
> > +inline internal::Matcher hasName(const std::string ) {
> > +  return internal::Matcher(new
> internal::HasNameMatcher({Name}));
>
> That doesn't compile with Visual Studio 2013:
>
>
> C:\b\build\slave\ClangToTWin\build\src\third_party\llvm\tools\clang\include\clang/ASTMatchers/ASTMatchers.h(1848)
> : error C2440: 'initializing' : cannot convert from 'initializer-list'
> to 'clang::ast_matchers::internal::HasNameMatcher'
> Constructor for class
> 'clang::ast_matchers::internal::HasNameMatcher' is declared 'explicit'
>
> > +private:
> > +  struct Pattern {
> > +StringRef Pattern;
>
>
> C:\b\build\slave\ClangToTWin\build\src\third_party\llvm\tools\clang\lib\ASTMatchers\ASTMatchersInternal.cpp(394)
> : error C2380: type(s) preceding 'Pattern' (constructor with return
> type, or illegal redefinition of current class-name?)
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: r261574 - [ASTMatchers] Add matcher hasAnyName.

2016-02-22 Thread Samuel Benzaquen via cfe-commits
On Mon, Feb 22, 2016 at 4:44 PM, Aaron Ballman 
wrote:

> On Mon, Feb 22, 2016 at 4:43 PM, Samuel Benzaquen 
> wrote:
> >
> > On Mon, Feb 22, 2016 at 4:19 PM, Aaron Ballman 
> > wrote:
> >>
> >> On Mon, Feb 22, 2016 at 4:13 PM, Samuel Benzaquen via cfe-commits
> >>  wrote:
> >> > Author: sbenza
> >> > Date: Mon Feb 22 15:13:02 2016
> >> > New Revision: 261574
> >> >
> >> > URL: http://llvm.org/viewvc/llvm-project?rev=261574=rev
> >> > Log:
> >> > [ASTMatchers] Add matcher hasAnyName.
> >> >
> >> > Summary: Add matcher hasAnyName as an optimization over
> >> > anyOf(hasName(),...)
> >>
> >> Does this mean we can get a clang-tidy check to convert
> >> anyOf(hasName(), ...) into hasAnyName()? ;-)
> >>
> >> ~Aaron
> >
> >
> > I would be simple, but I don't think it the cost/benefit is there. =)
> > I changed all the checks manually in 5 minutes.
> > I'll be sending that change soon.
>
> Haha, I was joking about the new check, but am really glad to hear
> we'll be using the new AST matcher right away. Thank you for working
> on this!
>
> ~Aaron
>

Matching the name of the nodes is a notable part of the CPU time of
clang-tidy.
This is why I spent time making it more efficient more than once already.

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


Re: r261448 - Lex: Check buckets on header map construction

2016-02-22 Thread Duncan P. N. Exon Smith via cfe-commits

> On 2016-Feb-22, at 10:39, Adrian Prantl  wrote:
> 
>> 
>> On Feb 20, 2016, at 1:00 PM, Duncan P. N. Exon Smith via cfe-commits 
>>  wrote:
>> 
>> Author: dexonsmith
>> Date: Sat Feb 20 15:00:58 2016
>> New Revision: 261448
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=261448=rev
>> Log:
>> Lex: Check buckets on header map construction
>> 
>> If the number of buckets is not a power of two, immediately recognize
>> the header map as corrupt, rather than waiting for the first lookup.  I
>> converted the later check to an assert.
>> 
>> Modified:
>>   cfe/trunk/lib/Lex/HeaderMap.cpp
>>   cfe/trunk/unittests/Lex/HeaderMapTest.cpp
>> 
>> Modified: cfe/trunk/lib/Lex/HeaderMap.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/HeaderMap.cpp?rev=261448=261447=261448=diff
>> ==
>> --- cfe/trunk/lib/Lex/HeaderMap.cpp (original)
>> +++ cfe/trunk/lib/Lex/HeaderMap.cpp Sat Feb 20 15:00:58 2016
>> @@ -19,6 +19,7 @@
>> #include "llvm/Support/DataTypes.h"
>> #include "llvm/Support/MathExtras.h"
>> #include "llvm/Support/MemoryBuffer.h"
>> +#include "llvm/Support/SwapByteOrder.h"
>> #include 
>> #include 
>> using namespace clang;
>> @@ -82,6 +83,15 @@ bool HeaderMapImpl::checkHeader(const ll
>>  if (Header->Reserved != 0)
>>return false;
>> 
>> +  // Check the number of buckets.
>> +  auto NumBuckets = NeedsByteSwap
>> +? llvm::sys::getSwappedBytes(Header->NumBuckets)
>> +: Header->NumBuckets;
>> +
>> +  // If the number of buckets is not a power of two, the headermap is 
>> corrupt.
> 
> Support/MathExtras.h defines isPowerOf2_32 which is IMHO more readable and 
> also checks for 0 (which may or may not be what we want here).

r261585.  Thanks.

> -- adrian
>> +  if (NumBuckets & (NumBuckets - 1))
>> +return false;
>> +
>>  // Okay, everything looks good.
>>  return true;
>> }
>> @@ -191,10 +201,8 @@ StringRef HeaderMapImpl::lookupFilename(
>>  const HMapHeader  = getHeader();
>>  unsigned NumBuckets = getEndianAdjustedWord(Hdr.NumBuckets);
>> 
>> -  // If the number of buckets is not a power of two, the headermap is 
>> corrupt.
>> -  // Don't probe infinitely.
>> -  if (NumBuckets & (NumBuckets-1))
>> -return StringRef();
>> +  // Don't probe infinitely.  This should be checked before constructing.
>> +  assert(!(NumBuckets & (NumBuckets - 1)) && "Expected power of 2");
>> 
>>  // Linearly probe the hash table.
>>  for (unsigned Bucket = HashHMapKey(Filename);; ++Bucket) {
>> 
>> Modified: cfe/trunk/unittests/Lex/HeaderMapTest.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Lex/HeaderMapTest.cpp?rev=261448=261447=261448=diff
>> ==
>> --- cfe/trunk/unittests/Lex/HeaderMapTest.cpp (original)
>> +++ cfe/trunk/unittests/Lex/HeaderMapTest.cpp Sat Feb 20 15:00:58 2016
>> @@ -91,4 +91,13 @@ TEST(HeaderMapTest, checkHeaderValidButE
>>  ASSERT_TRUE(NeedsSwap);
>> }
>> 
>> +TEST(HeaderMapTest, checkHeader3Buckets) {
>> +  MapFile<3, 1> File;
>> +  ASSERT_EQ(3 * sizeof(HMapBucket), sizeof(File.Buckets));
>> +
>> +  File.init();
>> +  bool NeedsSwap;
>> +  ASSERT_FALSE(HeaderMapImpl::checkHeader(*File.getBuffer(), NeedsSwap));
>> +}
>> +
>> } // end namespace
>> 
>> 
>> ___
>> 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


r261585 - Lex: Check for 0 buckets on header map construction

2016-02-22 Thread Duncan P. N. Exon Smith via cfe-commits
Author: dexonsmith
Date: Mon Feb 22 16:24:22 2016
New Revision: 261585

URL: http://llvm.org/viewvc/llvm-project?rev=261585=rev
Log:
Lex: Check for 0 buckets on header map construction

Switch to using `isPowerOf2_32()` to check whether the buckets are a
power of two, and as a side benefit reject loading a header map with no
buckets.  This is a follow-up to r261448.

Modified:
cfe/trunk/lib/Lex/HeaderMap.cpp
cfe/trunk/unittests/Lex/HeaderMapTest.cpp

Modified: cfe/trunk/lib/Lex/HeaderMap.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/HeaderMap.cpp?rev=261585=261584=261585=diff
==
--- cfe/trunk/lib/Lex/HeaderMap.cpp (original)
+++ cfe/trunk/lib/Lex/HeaderMap.cpp Mon Feb 22 16:24:22 2016
@@ -86,10 +86,10 @@ bool HeaderMapImpl::checkHeader(const ll
 
   // Check the number of buckets.  It should be a power of two, and there
   // should be enough space in the file for all of them.
-  auto NumBuckets = NeedsByteSwap
-? llvm::sys::getSwappedBytes(Header->NumBuckets)
-: Header->NumBuckets;
-  if (NumBuckets & (NumBuckets - 1))
+  uint32_t NumBuckets = NeedsByteSwap
+? llvm::sys::getSwappedBytes(Header->NumBuckets)
+: Header->NumBuckets;
+  if (!llvm::isPowerOf2_32(NumBuckets))
 return false;
   if (File.getBufferSize() <
   sizeof(HMapHeader) + sizeof(HMapBucket) * NumBuckets)
@@ -208,7 +208,7 @@ StringRef HeaderMapImpl::lookupFilename(
   unsigned NumBuckets = getEndianAdjustedWord(Hdr.NumBuckets);
 
   // Don't probe infinitely.  This should be checked before constructing.
-  assert(!(NumBuckets & (NumBuckets - 1)) && "Expected power of 2");
+  assert(llvm::isPowerOf2_32(NumBuckets) && "Expected power of 2");
 
   // Linearly probe the hash table.
   for (unsigned Bucket = HashHMapKey(Filename);; ++Bucket) {

Modified: cfe/trunk/unittests/Lex/HeaderMapTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Lex/HeaderMapTest.cpp?rev=261585=261584=261585=diff
==
--- cfe/trunk/unittests/Lex/HeaderMapTest.cpp (original)
+++ cfe/trunk/unittests/Lex/HeaderMapTest.cpp Mon Feb 22 16:24:22 2016
@@ -143,6 +143,15 @@ TEST(HeaderMapTest, checkHeader3Buckets)
   ASSERT_FALSE(HeaderMapImpl::checkHeader(*File.getBuffer(), NeedsSwap));
 }
 
+TEST(HeaderMapTest, checkHeader0Buckets) {
+  // Create with 1 bucket to avoid 0-sized arrays.
+  MapFile<1, 1> File;
+  File.init();
+  File.Header.NumBuckets = 0;
+  bool NeedsSwap;
+  ASSERT_FALSE(HeaderMapImpl::checkHeader(*File.getBuffer(), NeedsSwap));
+}
+
 TEST(HeaderMapTest, checkHeaderNotEnoughBuckets) {
   MapFile<1, 1> File;
   File.init();


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


Re: r261574 - [ASTMatchers] Add matcher hasAnyName.

2016-02-22 Thread Hans Wennborg via cfe-commits
On Mon, Feb 22, 2016 at 1:13 PM, Samuel Benzaquen via cfe-commits
 wrote:
> Author: sbenza
> Date: Mon Feb 22 15:13:02 2016
> New Revision: 261574
>
> URL: http://llvm.org/viewvc/llvm-project?rev=261574=rev
> Log:
> [ASTMatchers] Add matcher hasAnyName.
>
> Summary: Add matcher hasAnyName as an optimization over anyOf(hasName(),...)
>
> Reviewers: alexfh
>
> Subscribers: klimek, cfe-commits
>
> Differential Revision: http://reviews.llvm.org/D17163

I've tried to fix the Visual Studio build in r261583. Please take a
look to make sure the fixes seem reasonable.


> +++ cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h Mon Feb 22 15:13:02 2016
> @@ -1844,11 +1844,24 @@ inline internal::Matcher sizeOfExp
>  /// \code
>  ///   namespace a { namespace b { class X; } }
>  /// \endcode
> -inline internal::Matcher hasName(std::string Name) {
> -  return internal::Matcher(
> -  new internal::HasNameMatcher(std::move(Name)));
> +inline internal::Matcher hasName(const std::string ) {
> +  return internal::Matcher(new internal::HasNameMatcher({Name}));

That doesn't compile with Visual Studio 2013:

C:\b\build\slave\ClangToTWin\build\src\third_party\llvm\tools\clang\include\clang/ASTMatchers/ASTMatchers.h(1848)
: error C2440: 'initializing' : cannot convert from 'initializer-list'
to 'clang::ast_matchers::internal::HasNameMatcher'
Constructor for class
'clang::ast_matchers::internal::HasNameMatcher' is declared 'explicit'

> +private:
> +  struct Pattern {
> +StringRef Pattern;

C:\b\build\slave\ClangToTWin\build\src\third_party\llvm\tools\clang\lib\ASTMatchers\ASTMatchersInternal.cpp(394)
: error C2380: type(s) preceding 'Pattern' (constructor with return
type, or illegal redefinition of current class-name?)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r261583 - Fix Visual Studio build after r261574

2016-02-22 Thread Hans Wennborg via cfe-commits
Author: hans
Date: Mon Feb 22 16:21:58 2016
New Revision: 261583

URL: http://llvm.org/viewvc/llvm-project?rev=261583=rev
Log:
Fix Visual Studio build after r261574

Modified:
cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
cfe/trunk/lib/ASTMatchers/ASTMatchersInternal.cpp

Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h?rev=261583=261582=261583=diff
==
--- cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h (original)
+++ cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h Mon Feb 22 16:21:58 2016
@@ -1845,7 +1845,9 @@ inline internal::Matcher sizeOfExp
 ///   namespace a { namespace b { class X; } }
 /// \endcode
 inline internal::Matcher hasName(const std::string ) {
-  return internal::Matcher(new internal::HasNameMatcher({Name}));
+  std::vector Names;
+  Names.push_back(Name);
+  return internal::Matcher(new internal::HasNameMatcher(Names));
 }
 
 /// \brief Matches NamedDecl nodes that have any of the specified names.

Modified: cfe/trunk/lib/ASTMatchers/ASTMatchersInternal.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/ASTMatchers/ASTMatchersInternal.cpp?rev=261583=261582=261583=diff
==
--- cfe/trunk/lib/ASTMatchers/ASTMatchersInternal.cpp (original)
+++ cfe/trunk/lib/ASTMatchers/ASTMatchersInternal.cpp Mon Feb 22 16:21:58 2016
@@ -369,7 +369,7 @@ public:
   /// Return true if there are still any patterns left.
   bool consumeNameSuffix(StringRef NodeName, bool CanSkip) {
 for (size_t I = 0; I < Patterns.size();) {
-  if (internal::consumeNameSuffix(Patterns[I].Pattern, NodeName) ||
+  if (internal::consumeNameSuffix(Patterns[I].P, NodeName) ||
   CanSkip) {
 ++I;
   } else {
@@ -384,14 +384,14 @@ public:
   /// 'fully qualified' requirement.
   bool foundMatch(bool AllowFullyQualified) const {
 for (auto& P: Patterns)
-  if (P.Pattern.empty() && (AllowFullyQualified || !P.IsFullyQualified))
+  if (P.P.empty() && (AllowFullyQualified || !P.IsFullyQualified))
 return true;
 return false;
   }
 
 private:
   struct Pattern {
-StringRef Pattern;
+StringRef P;
 bool IsFullyQualified;
   };
   llvm::SmallVector Patterns;


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


Re: r261574 - [ASTMatchers] Add matcher hasAnyName.

2016-02-22 Thread Aaron Ballman via cfe-commits
On Mon, Feb 22, 2016 at 4:43 PM, Samuel Benzaquen  wrote:
>
> On Mon, Feb 22, 2016 at 4:19 PM, Aaron Ballman 
> wrote:
>>
>> On Mon, Feb 22, 2016 at 4:13 PM, Samuel Benzaquen via cfe-commits
>>  wrote:
>> > Author: sbenza
>> > Date: Mon Feb 22 15:13:02 2016
>> > New Revision: 261574
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=261574=rev
>> > Log:
>> > [ASTMatchers] Add matcher hasAnyName.
>> >
>> > Summary: Add matcher hasAnyName as an optimization over
>> > anyOf(hasName(),...)
>>
>> Does this mean we can get a clang-tidy check to convert
>> anyOf(hasName(), ...) into hasAnyName()? ;-)
>>
>> ~Aaron
>
>
> I would be simple, but I don't think it the cost/benefit is there. =)
> I changed all the checks manually in 5 minutes.
> I'll be sending that change soon.

Haha, I was joking about the new check, but am really glad to hear
we'll be using the new AST matcher right away. Thank you for working
on this!

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


Re: r261574 - [ASTMatchers] Add matcher hasAnyName.

2016-02-22 Thread Samuel Benzaquen via cfe-commits
On Mon, Feb 22, 2016 at 4:19 PM, Aaron Ballman 
wrote:

> On Mon, Feb 22, 2016 at 4:13 PM, Samuel Benzaquen via cfe-commits
>  wrote:
> > Author: sbenza
> > Date: Mon Feb 22 15:13:02 2016
> > New Revision: 261574
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=261574=rev
> > Log:
> > [ASTMatchers] Add matcher hasAnyName.
> >
> > Summary: Add matcher hasAnyName as an optimization over
> anyOf(hasName(),...)
>
> Does this mean we can get a clang-tidy check to convert
> anyOf(hasName(), ...) into hasAnyName()? ;-)
>
> ~Aaron
>

I would be simple, but I don't think it the cost/benefit is there. =)
I changed all the checks manually in 5 minutes.
I'll be sending that change soon.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D16821: Add whole-program vtable optimization feature to Clang.

2016-02-22 Thread Pete Cooper via cfe-commits

> On Feb 22, 2016, at 1:30 PM, Peter Collingbourne  wrote:
> 
> One thing that I'd like to do (and this would help CFI as well) is to 
> specifically recognize cases like this:
> 
> ```
> struct B {
>  virtual void vf();
> };
> 
> struct D1 {
> };
I assume you meant D1 : B here?
> 
> struct D2 : B {
>  virtual void vf();
> };
> 
> void f(D1 *d) {
>  d->vf();
> }
> ```
> 
> In this case I'd like to devirtualize the virtual call in `f()` to `B::vf()`. 
> But because the implicit cast to `B` in `f()` removes the information that 
> `d` cannot be of type `D2`, we cannot eliminate `D2::vf()` as a candidate 
> target (see also `test/cfi/sibling.cpp` in the CFI test suite).
> 
> Although this could possibly be emitted and pattern matched at the IR level, 
> it seems simpler (and would probably catch enough cases) to have Clang look 
> through the implicit cast when IR gen'ing for the call.
So my devirtualizer dealt with this by marking each call site with the most 
specific class we know of in the hierarchy.  

In this case, then class hierarchy would contain the pairs: (B, B), (D1, B), 
(D2, B).

The call site in f() would be tagged with (D1, B) not (B, B).  Then, when we 
are in the pass, we look at the subclasses from (D1, B), see that there are 
none (or that none override vf), and devirtualize to B::vf().

If that isn’t possible in the current solution (I didn’t check), then it should 
be easy enough to add.  I certainly don’t think any of the current 
implementation would be hard to adapt to support this use case.

Cheers,
Pete



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


Re: [PATCH] D16821: Add whole-program vtable optimization feature to Clang.

2016-02-22 Thread Peter Collingbourne via cfe-commits
pcc added inline comments.


Comment at: lib/CodeGen/CGVTables.cpp:904-919
@@ -900,5 +903,18 @@
+
+bool CodeGenModule::IsBitSetBlacklistedRecord(const CXXRecordDecl *RD) {
+  std::string TypeName = RD->getQualifiedNameAsString();
+  auto isInBlacklist = [&](const SanitizerBlacklist ) {
+if (RD->hasAttr() && BL.isBlacklistedType("attr:uuid"))
+  return true;
+
+return BL.isBlacklistedType(TypeName);
+  };
 
-  return getContext().getSanitizerBlacklist().isBlacklistedType(
-  RD->getQualifiedNameAsString());
+  return isInBlacklist(WholeProgramVTablesBlacklist) ||
+ ((LangOpts.Sanitize.has(SanitizerKind::CFIVCall) ||
+   LangOpts.Sanitize.has(SanitizerKind::CFINVCall) ||
+   LangOpts.Sanitize.has(SanitizerKind::CFIDerivedCast) ||
+   LangOpts.Sanitize.has(SanitizerKind::CFIUnrelatedCast)) &&
+  isInBlacklist(getContext().getSanitizerBlacklist()));
 }
 

rsmith wrote:
> It looks like putting a class in a sanitizer blacklist turns off the vptr 
> optimizations for the class and putting it in the vptr blacklist turns off 
> CFI checks for it. Can we avoid that, perhaps by using separate bitsets for 
> the vptr checks and CFI?
> It looks like putting a class in a sanitizer blacklist turns off the vptr 
> optimizations for the class and putting it in the vptr blacklist turns off 
> CFI checks for it

This is approximately what we want to do in any case. The blacklists identify 
classes defined outside of the linkage unit, and both CFI checks (modulo the 
cross-DSO feature) and devirtualization both rely on the classes being defined 
in the current linkage unit.

One can imagine adding classes to the blacklist that are somehow incompatible 
with CFI checks, but in general I'd expect that list to be pretty small 
(Chromium's list [1] currently has 18 entries, most of which are 
non-whole-program issues) so it probably isn't a huge loss for 
devirtualization, and we can always try to find some way to improve on that 
later.

Likewise, I think we could be a little smarter about using the correct 
blacklists in cross-DSO mode, but that can probably come later.

> Can we avoid that, perhaps by using separate bitsets for the vptr checks and 
> CFI?

I think we could probably share bitsets for both use cases and filter for 
devirt/CFI at call sites. I suspect it will be important for devirt and CFI to 
share bitsets, as I will want to eliminate CFI checks in devirtualized calls.

[1] 
https://code.google.com/p/chromium/codesearch#chromium/src/tools/cfi/blacklist.txt=cfi/blacklist=package:chromium=cs=2


Comment at: lib/CodeGen/CodeGenModule.h:492
@@ -491,1 +491,3 @@
 
+  SanitizerBlacklist WholeProgramVTablesBlacklist;
+

rsmith wrote:
> Now might be a good time to rename the `SanitizerBlacklist` class to 
> something more general (but not as part of this commit).
Ack.


Comment at: lib/CodeGen/ItaniumCXXABI.cpp:1605
@@ -1604,5 +1604,3 @@
 
-  if (CGF.SanOpts.has(SanitizerKind::CFIVCall))
-CGF.EmitVTablePtrCheckForCall(MethodDecl, VTable,
-  CodeGenFunction::CFITCK_VCall, Loc);
+  CGF.EmitBitSetCodeForVCall(MethodDecl->getParent(), VTable, Loc);
 

rsmith wrote:
> You can be a lot more aggressive than this -- you can make an assumption 
> about the value of the vptr from within `EmitTypeCheck` in every case where 
> the vptr sanitizer would emit a dynamic type check. I'm not sure that doing 
> so will allow you to deduce a lot more vptrs, but it seems like it could help 
> in some cases.
Maybe, but that probably wouldn't help yet. The devirtualization optimization 
pass looks for a very specific IR pattern, and if we generate extra vtable 
loads for casts to assume against, we would need additional machinery to ensure 
the load from the cast is invariant with those from any calls (maybe Piotr's 
work would help here, not sure).

One thing that I'd like to do (and this would help CFI as well) is to 
specifically recognize cases like this:

```
struct B {
  virtual void vf();
};

struct D1 {
};

struct D2 : B {
  virtual void vf();
};

void f(D1 *d) {
  d->vf();
}
```

In this case I'd like to devirtualize the virtual call in `f()` to `B::vf()`. 
But because the implicit cast to `B` in `f()` removes the information that `d` 
cannot be of type `D2`, we cannot eliminate `D2::vf()` as a candidate target 
(see also `test/cfi/sibling.cpp` in the CFI test suite).

Although this could possibly be emitted and pattern matched at the IR level, it 
seems simpler (and would probably catch enough cases) to have Clang look 
through the implicit cast when IR gen'ing for the call.


http://reviews.llvm.org/D16821



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


Re: r261574 - [ASTMatchers] Add matcher hasAnyName.

2016-02-22 Thread Aaron Ballman via cfe-commits
On Mon, Feb 22, 2016 at 4:13 PM, Samuel Benzaquen via cfe-commits
 wrote:
> Author: sbenza
> Date: Mon Feb 22 15:13:02 2016
> New Revision: 261574
>
> URL: http://llvm.org/viewvc/llvm-project?rev=261574=rev
> Log:
> [ASTMatchers] Add matcher hasAnyName.
>
> Summary: Add matcher hasAnyName as an optimization over anyOf(hasName(),...)

Does this mean we can get a clang-tidy check to convert
anyOf(hasName(), ...) into hasAnyName()? ;-)

~Aaron

>
> Reviewers: alexfh
>
> Subscribers: klimek, cfe-commits
>
> Differential Revision: http://reviews.llvm.org/D17163
>
> Modified:
> cfe/trunk/docs/LibASTMatchersReference.html
> cfe/trunk/docs/tools/dump_ast_matchers.py
> cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
> cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
> cfe/trunk/lib/ASTMatchers/ASTMatchersInternal.cpp
> cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp
> cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp
>
> Modified: cfe/trunk/docs/LibASTMatchersReference.html
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LibASTMatchersReference.html?rev=261574=261573=261574=diff
> ==
> --- cfe/trunk/docs/LibASTMatchersReference.html (original)
> +++ cfe/trunk/docs/LibASTMatchersReference.html Mon Feb 22 15:13:02 2016
> @@ -3102,6 +3102,16 @@ expr(nullPointerConstant())
>  
>
>
> +Matcherinternal::Matcher href="http://clang.llvm.org/doxygen/classclang_1_1NamedDecl.html;>NamedDecl  class="name" onclick="toggle('hasAnyName0')"> name="hasAnyName0Anchor">hasAnyNameStringRef, ..., 
> StringRef
> +Matches NamedDecl 
> nodes that have any of the specified names.
> +
> +This matcher is only provided as a performance optimization of hasName.
> +hasAnyName(a, b, c)
> + is equivalent but faster than
> +anyOf(hasName(a), hasName(b), hasName(c))
> +
> +
> +
>  Matcherinternal::Matcher href="http://clang.llvm.org/doxygen/classclang_1_1Stmt.html;>Stmt  class="name" onclick="toggle('isInTemplateInstantiation0')"> name="isInTemplateInstantiation0Anchor">isInTemplateInstantiation
>  Matches 
> statements inside of a template instantiation.
>
>
> Modified: cfe/trunk/docs/tools/dump_ast_matchers.py
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/tools/dump_ast_matchers.py?rev=261574=261573=261574=diff
> ==
> --- cfe/trunk/docs/tools/dump_ast_matchers.py (original)
> +++ cfe/trunk/docs/tools/dump_ast_matchers.py Mon Feb 22 15:13:02 2016
> @@ -264,6 +264,16 @@ def act_on_decl(declaration, comment, al
>add_matcher('*', name, 'Matcher<*>', comment)
>return
>
> +# Parse Variadic functions.
> +m = re.match(
> +r"""^.*llvm::VariadicFunction\s*<\s*([^,]+),\s*([^,]+),\s*[^>]+>\s*
> +  ([a-zA-Z]*)\s*=\s*{.*};$""",
> +declaration, flags=re.X)
> +if m:
> +  result, arg, name = m.groups()[:3]
> +  add_matcher(result, name, '%s, ..., %s' % (arg, arg), comment)
> +  return
> +
>  # Parse Variadic operator matchers.
>  m = re.match(
>  r"""^.*VariadicOperatorMatcherFunc\s*<\s*([^,]+),\s*([^\s>]+)\s*>\s*
>
> Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h?rev=261574=261573=261574=diff
> ==
> --- cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h (original)
> +++ cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h Mon Feb 22 15:13:02 2016
> @@ -1844,11 +1844,24 @@ inline internal::Matcher sizeOfExp
>  /// \code
>  ///   namespace a { namespace b { class X; } }
>  /// \endcode
> -inline internal::Matcher hasName(std::string Name) {
> -  return internal::Matcher(
> -  new internal::HasNameMatcher(std::move(Name)));
> +inline internal::Matcher hasName(const std::string ) {
> +  return internal::Matcher(new internal::HasNameMatcher({Name}));
>  }
>
> +/// \brief Matches NamedDecl nodes that have any of the specified names.
> +///
> +/// This matcher is only provided as a performance optimization of hasName.
> +/// \code
> +/// hasAnyName(a, b, c)
> +/// \endcode
> +///  is equivalent to, but faster than
> +/// \code
> +/// anyOf(hasName(a), hasName(b), hasName(c))
> +/// \endcode
> +const llvm::VariadicFunction + internal::hasAnyNameFunc>
> +hasAnyName = {};
> +
>  /// \brief Matches NamedDecl nodes whose fully qualified names contain
>  /// a substring matched by the given RegExp.
>  ///
>
> Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h?rev=261574=261573=261574=diff
> ==
> 

r261574 - [ASTMatchers] Add matcher hasAnyName.

2016-02-22 Thread Samuel Benzaquen via cfe-commits
Author: sbenza
Date: Mon Feb 22 15:13:02 2016
New Revision: 261574

URL: http://llvm.org/viewvc/llvm-project?rev=261574=rev
Log:
[ASTMatchers] Add matcher hasAnyName.

Summary: Add matcher hasAnyName as an optimization over anyOf(hasName(),...)

Reviewers: alexfh

Subscribers: klimek, cfe-commits

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

Modified:
cfe/trunk/docs/LibASTMatchersReference.html
cfe/trunk/docs/tools/dump_ast_matchers.py
cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
cfe/trunk/lib/ASTMatchers/ASTMatchersInternal.cpp
cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp
cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp

Modified: cfe/trunk/docs/LibASTMatchersReference.html
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/LibASTMatchersReference.html?rev=261574=261573=261574=diff
==
--- cfe/trunk/docs/LibASTMatchersReference.html (original)
+++ cfe/trunk/docs/LibASTMatchersReference.html Mon Feb 22 15:13:02 2016
@@ -3102,6 +3102,16 @@ expr(nullPointerConstant())
 
 
 
+Matcherinternal::Matcherhttp://clang.llvm.org/doxygen/classclang_1_1NamedDecl.html;>NamedDeclhasAnyNameStringRef, ..., 
StringRef
+Matches NamedDecl nodes 
that have any of the specified names.
+
+This matcher is only provided as a performance optimization of hasName.
+hasAnyName(a, b, c)
+ is equivalent but faster than
+anyOf(hasName(a), hasName(b), hasName(c))
+
+
+
 Matcherinternal::Matcherhttp://clang.llvm.org/doxygen/classclang_1_1Stmt.html;>StmtisInTemplateInstantiation
 Matches 
statements inside of a template instantiation.
 

Modified: cfe/trunk/docs/tools/dump_ast_matchers.py
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/tools/dump_ast_matchers.py?rev=261574=261573=261574=diff
==
--- cfe/trunk/docs/tools/dump_ast_matchers.py (original)
+++ cfe/trunk/docs/tools/dump_ast_matchers.py Mon Feb 22 15:13:02 2016
@@ -264,6 +264,16 @@ def act_on_decl(declaration, comment, al
   add_matcher('*', name, 'Matcher<*>', comment)
   return
 
+# Parse Variadic functions.
+m = re.match(
+r"""^.*llvm::VariadicFunction\s*<\s*([^,]+),\s*([^,]+),\s*[^>]+>\s*
+  ([a-zA-Z]*)\s*=\s*{.*};$""",
+declaration, flags=re.X)
+if m:
+  result, arg, name = m.groups()[:3]
+  add_matcher(result, name, '%s, ..., %s' % (arg, arg), comment)
+  return
+
 # Parse Variadic operator matchers.
 m = re.match(
 r"""^.*VariadicOperatorMatcherFunc\s*<\s*([^,]+),\s*([^\s>]+)\s*>\s*

Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h?rev=261574=261573=261574=diff
==
--- cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h (original)
+++ cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h Mon Feb 22 15:13:02 2016
@@ -1844,11 +1844,24 @@ inline internal::Matcher sizeOfExp
 /// \code
 ///   namespace a { namespace b { class X; } }
 /// \endcode
-inline internal::Matcher hasName(std::string Name) {
-  return internal::Matcher(
-  new internal::HasNameMatcher(std::move(Name)));
+inline internal::Matcher hasName(const std::string ) {
+  return internal::Matcher(new internal::HasNameMatcher({Name}));
 }
 
+/// \brief Matches NamedDecl nodes that have any of the specified names.
+///
+/// This matcher is only provided as a performance optimization of hasName.
+/// \code
+/// hasAnyName(a, b, c)
+/// \endcode
+///  is equivalent to, but faster than
+/// \code
+/// anyOf(hasName(a), hasName(b), hasName(c))
+/// \endcode
+const llvm::VariadicFunction
+hasAnyName = {};
+
 /// \brief Matches NamedDecl nodes whose fully qualified names contain
 /// a substring matched by the given RegExp.
 ///

Modified: cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h?rev=261574=261573=261574=diff
==
--- cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h (original)
+++ cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h Mon Feb 22 
15:13:02 2016
@@ -637,10 +637,10 @@ private:
 
 /// \brief Matches named declarations with a specific name.
 ///
-/// See \c hasName() in ASTMatchers.h for details.
+/// See \c hasName() and \c hasAnyName() in ASTMatchers.h for details.
 class HasNameMatcher : public SingleNodeMatcherInterface {
  public:
-  explicit HasNameMatcher(std::string Name);
+  explicit HasNameMatcher(std::vector Names);
 
   bool matchesNode(const NamedDecl ) const override;
 
@@ -667,9 

Re: [PATCH] D17163: [ASTMatchers] Add matcher hasAnyName.

2016-02-22 Thread Samuel Benzaquen via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL261574: [ASTMatchers] Add matcher hasAnyName. (authored by 
sbenza).

Changed prior to commit:
  http://reviews.llvm.org/D17163?vs=47802=48720#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D17163

Files:
  cfe/trunk/docs/LibASTMatchersReference.html
  cfe/trunk/docs/tools/dump_ast_matchers.py
  cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h
  cfe/trunk/include/clang/ASTMatchers/ASTMatchersInternal.h
  cfe/trunk/lib/ASTMatchers/ASTMatchersInternal.cpp
  cfe/trunk/lib/ASTMatchers/Dynamic/Registry.cpp
  cfe/trunk/unittests/ASTMatchers/ASTMatchersTest.cpp

Index: cfe/trunk/lib/ASTMatchers/ASTMatchersInternal.cpp
===
--- cfe/trunk/lib/ASTMatchers/ASTMatchersInternal.cpp
+++ cfe/trunk/lib/ASTMatchers/ASTMatchersInternal.cpp
@@ -14,6 +14,7 @@
 #include "clang/ASTMatchers/ASTMatchers.h"
 #include "clang/ASTMatchers/ASTMatchersInternal.h"
 #include "llvm/ADT/SmallString.h"
+#include "llvm/ADT/SmallVector.h"
 #include "llvm/Support/ManagedStatic.h"
 
 namespace clang {
@@ -293,15 +294,26 @@
   return false;
 }
 
-HasNameMatcher::HasNameMatcher(std::string NameRef)
-: UseUnqualifiedMatch(NameRef.find("::") == NameRef.npos),
-  Name(std::move(NameRef)) {
-  assert(!Name.empty());
+Matcher hasAnyNameFunc(ArrayRef NameRefs) {
+  std::vector Names;
+  for (auto *Name : NameRefs)
+Names.emplace_back(*Name);
+  return internal::Matcher(
+  new internal::HasNameMatcher(std::move(Names)));
+}
+
+HasNameMatcher::HasNameMatcher(std::vector N)
+: UseUnqualifiedMatch(std::all_of(
+  N.begin(), N.end(),
+  [](StringRef Name) { return Name.find("::") == Name.npos; })),
+  Names(std::move(N)) {
+  for (StringRef Name : Names)
+assert(!Name.empty());
 }
 
 namespace {
 
-bool ConsumeNameSuffix(StringRef , StringRef Suffix) {
+bool consumeNameSuffix(StringRef , StringRef Suffix) {
   StringRef Name = FullName;
   if (!Name.endswith(Suffix))
 return false;
@@ -315,79 +327,127 @@
   return true;
 }
 
-bool ConsumeNodeName(StringRef , const NamedDecl ) {
+StringRef getNodeName(const NamedDecl , llvm::SmallString<128> ) {
   // Simple name.
   if (Node.getIdentifier())
-return ConsumeNameSuffix(Name, Node.getName());
+return Node.getName();
 
   if (Node.getDeclName()) {
 // Name needs to be constructed.
-llvm::SmallString<128> NodeName;
-llvm::raw_svector_ostream OS(NodeName);
+Scratch.clear();
+llvm::raw_svector_ostream OS(Scratch);
 Node.printName(OS);
-return ConsumeNameSuffix(Name, OS.str());
+return OS.str();
   }
 
-  return ConsumeNameSuffix(Name, "(anonymous)");
+  return "(anonymous)";
 }
 
+StringRef getNodeName(const RecordDecl , llvm::SmallString<128> ) {
+  if (Node.getIdentifier()) {
+return Node.getName();
+  }
+  Scratch.clear();
+  return ("(anonymous " + Node.getKindName() + ")").toStringRef(Scratch);
+}
+
+StringRef getNodeName(const NamespaceDecl ,
+  llvm::SmallString<128> ) {
+  return Node.isAnonymousNamespace() ? "(anonymous namespace)" : Node.getName();
+}
+
+
+class PatternSet {
+public:
+  PatternSet(ArrayRef Names) {
+for (StringRef Name : Names)
+  Patterns.push_back({Name, Name.startswith("::")});
+  }
+
+  /// Consumes the name suffix from each pattern in the set and removes the ones
+  /// that didn't match.
+  /// Return true if there are still any patterns left.
+  bool consumeNameSuffix(StringRef NodeName, bool CanSkip) {
+for (size_t I = 0; I < Patterns.size();) {
+  if (internal::consumeNameSuffix(Patterns[I].Pattern, NodeName) ||
+  CanSkip) {
+++I;
+  } else {
+Patterns.erase(Patterns.begin() + I);
+  }
+}
+return !Patterns.empty();
+  }
+
+  /// Check if any of the patterns are a match.
+  /// A match will be a pattern that was fully consumed, that also matches the
+  /// 'fully qualified' requirement.
+  bool foundMatch(bool AllowFullyQualified) const {
+for (auto& P: Patterns)
+  if (P.Pattern.empty() && (AllowFullyQualified || !P.IsFullyQualified))
+return true;
+return false;
+  }
+
+private:
+  struct Pattern {
+StringRef Pattern;
+bool IsFullyQualified;
+  };
+  llvm::SmallVector Patterns;
+};
+
 }  // namespace
 
 bool HasNameMatcher::matchesNodeUnqualified(const NamedDecl ) const {
   assert(UseUnqualifiedMatch);
-  StringRef NodeName = Name;
-  return ConsumeNodeName(NodeName, Node) && NodeName.empty();
+  llvm::SmallString<128> Scratch;
+  StringRef NodeName = getNodeName(Node, Scratch);
+  return std::any_of(Names.begin(), Names.end(), [&](StringRef Name) {
+return consumeNameSuffix(Name, NodeName) && Name.empty();
+  });
 }
 
 bool HasNameMatcher::matchesNodeFullFast(const NamedDecl ) const {
+  PatternSet Patterns(Names);
+  llvm::SmallString<128> Scratch;
+
   // This function is copied and adapted from 

Re: [PATCH] D17516: AMDGPU: Verify subtarget specific builtins

2016-02-22 Thread Eric Christopher via cfe-commits
echristo added inline comments.


Comment at: lib/Basic/Targets.cpp:1829
@@ -1820,2 +1828,3 @@
 }
+
 AddrSpaceMap = 

Extra whitespace.


Comment at: lib/Basic/Targets.cpp:2059-2063
@@ +2058,7 @@
+
+  if (Has16BitInsts)
+Features["16-bit-insts"] = true;
+
+  if (hasSMemRealTime)
+Features["s-memrealtime"] = true;
+

This is typically more of the "move the cpu checks down here" area from what 
you'd have above. Also you're not calling the target independent version of 
initFeatureMap - is that done on purpose?


http://reviews.llvm.org/D17516



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


Re: [PATCH] D16993: Add documentation for bitreverse builtins

2016-02-22 Thread Matt Arsenault via cfe-commits
arsenm added a comment.

ping


http://reviews.llvm.org/D16993



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


Re: [modules] PR24954

2016-02-22 Thread Vassil Vassilev via cfe-commits

On 02/02/16 02:52, Richard Smith via cfe-commits wrote:

On Thu, Jan 28, 2016 at 8:23 AM, Vassil Vassilev  wrote:

Would this patch be more reasonable? It follows what
RegisterTemplateSpecialization (introduced in r245779) does. AFAICT this
adds an update record far less often.

It's still adding redundant update records. We'll write the
appropriate update record as part of serializing the declaration
itself, so we only need to ensure that the declaration is emitted, not
actually emit an update record for it. Perhaps you could store a list
of such declarations on the ASTWriter, and call GetDeclRef on each of
them once we start emitting the AST file (or maybe just push them into
UpdatingVisibleDecls). Please also restrict this to the template
friend corner case.
The attached patch fixes the issues more or less in the direction you 
suggest. I am not sure if I expressed well enough the conditions of the 
template friend corner case. Could you have a look?



--Vassil

On 12/12/15 16:13, Vassil Vassilev wrote:

I couldn't find GetDecl routine in the ASTWriter. Could you elaborate?

Assuming you meant ASTWriter::GetDeclRef(D): It seems that the conditions
when calling GetDeclRef differ from the conditions of
AddedCXXTemplateSpecialization. Eg:

ASTWriter::AddedCXXTemplateSpecialization {
   assert(!WritingAST && "Already writing the AST!");
   ...
}
ASTWriter::GetDeclRef {
   assert(WritingAST && "Cannot request a declaration ID before AST
writing");
   ..
}

IIUC this particular instantiation happens *after* module B was built, thus
it needs to be retrospectively added to the serialized namespace. It looks
like even avoiding somehow the asserts of GetDeclRef it wouldn't help much.

Alternatively I could try to reduce the redundant update records by
narrowing down to instantiations coming in the context of friends.

--Vassil

On 12/12/15 01:07, Richard Smith wrote:

Instead of adding an update record directly in this case (which will emit
far more update records than necessary), how about just calling GetDecl(D)
from AddedCXXTemplateSpecialization to ensure that it gets emitted?

On Fri, Dec 4, 2015 at 7:46 AM, Vassil Vassilev  wrote:

Hi,
   Could you review my fix please.
Many thanks,
Vassil

On 08/10/15 15:53, Vassil Vassilev wrote:

Hi Richard,
   I started working on https://llvm.org/bugs/show_bug.cgi?id=24954

   IIUC r228485 introduces an abstraction to deal with
not-really-anonymous friend decls
(serialization::needsAnonymousDeclarationNumber in ASTCommon.cpp).

   A comment explicitly says:
   "// This doesn't apply to friend tag decls; Sema makes those available
to name
// lookup in the surrounding context."

   In the bug reproducer, the friend function (wrt __iom_t10) is forward
declared in the same namespace, where Sema makes the friend available for a
name lookup.

   It seems that the friend operator<< in __iom_t10 (sorry about the names
they come from libcxx) doesn't get registered in the ASTWriter's DeclIDs but
it gets registered in outer namespace's lookup table. Thus, assert is
triggered when finalizing module A, since it rebuilds the lookups of the
updated contexts.

   The issue only appears when building module A deserializes/uses module
B.

   Currently I was assume that something wrong happens in either
needsAnonymousDeclarationNumber or I hit a predicted issue
ASTWriterDecl.cpp:1602
 // FIXME: This is not correct; when we reach an imported declaration
we
 // won't emit its previous declaration.
 (void)Writer.GetDeclRef(D->getPreviousDecl());
 (void)Writer.GetDeclRef(MostRecent);

   The issue seems a fairly complex one and I am a bit stuck.

   Any hints are very very welcome ;)
Many thanks,
Vassil







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


From 4efa41e3cba19d3dc2ac76c60a135a01fbd13380 Mon Sep 17 00:00:00 2001
From: Vassil Vassilev 
Date: Sun, 27 Sep 2015 21:12:39 +0200
Subject: [PATCH] [modules] Fix adding a templated friend functions to a
 namespace from another module.

When clang adds argument dependent lookup candidates, it can perform template
instantiations. For example, it can instantiate a templated friend function and
register it in the enclosing namespace's lookup table.

Fixes https://llvm.org/bugs/show_bug.cgi?id=24954
---
 lib/Serialization/ASTWriter.cpp  |  7 +--
 test/Modules/Inputs/PR24954/A.h  | 10 ++
 test/Modules/Inputs/PR24954/B.h  | 30 
 test/Modules/Inputs/PR24954/module.modulemap |  9 +
 test/Modules/pr24954.cpp |  7 +++
 5 files changed, 61 insertions(+), 2 deletions(-)
 create mode 100644 test/Modules/Inputs/PR24954/A.h
 create mode 100644 test/Modules/Inputs/PR24954/B.h
 create mode 100644 test/Modules/Inputs/PR24954/module.modulemap
 create mode 

[PATCH] D17520: AMDGPU: Fix inconsistent register name for flat_scratch

2016-02-22 Thread Matt Arsenault via cfe-commits
arsenm created this revision.
arsenm added a reviewer: tstellarAMD.
arsenm added a subscriber: cfe-commits.

http://reviews.llvm.org/D17520

Files:
  lib/Basic/Targets.cpp
  test/CodeGenOpenCL/amdgcn-flat-scratch-name.cl

Index: test/CodeGenOpenCL/amdgcn-flat-scratch-name.cl
===
--- /dev/null
+++ test/CodeGenOpenCL/amdgcn-flat-scratch-name.cl
@@ -0,0 +1,15 @@
+// REQUIRES: amdgpu-registered-target
+// RUN: %clang_cc1 -triple amdgcn-unknown-unknown -S -emit-llvm -o - %s | 
FileCheck %s
+
+// CHECK-LABEL: @use_flat_scratch_name
+kernel void use_flat_scratch_name()
+{
+// CHECK: tail call void asm sideeffect "s_mov_b64 flat_scratch, 0", 
"~{flat_scratch}"()
+  __asm__ volatile("s_mov_b64 flat_scratch, 0" : : : "flat_scratch");
+
+// CHECK: tail call void asm sideeffect "s_mov_b32 flat_scratch_lo, 0", 
"~{flat_scratch_lo}"()
+  __asm__ volatile("s_mov_b32 flat_scratch_lo, 0" : : : "flat_scratch_lo");
+
+// CHECK: tail call void asm sideeffect "s_mov_b32 flat_scratch_hi, 0", 
"~{flat_scratch_hi}"()
+  __asm__ volatile("s_mov_b32 flat_scratch_hi, 0" : : : "flat_scratch_hi");
+}
Index: lib/Basic/Targets.cpp
===
--- lib/Basic/Targets.cpp
+++ lib/Basic/Targets.cpp
@@ -2047,8 +2047,8 @@
   "s104", "s105", "s106", "s107", "s108", "s109", "s110", "s111",
   "s112", "s113", "s114", "s115", "s116", "s117", "s118", "s119",
   "s120", "s121", "s122", "s123", "s124", "s125", "s126", "s127"
-  "exec", "vcc", "scc", "m0", "flat_scr", "exec_lo", "exec_hi",
-  "vcc_lo", "vcc_hi", "flat_scr_lo", "flat_scr_hi"
+  "exec", "vcc", "scc", "m0", "flat_scratch", "exec_lo", "exec_hi",
+  "vcc_lo", "vcc_hi", "flat_scratch_lo", "flat_scratch_hi"
 };
 
 ArrayRef AMDGPUTargetInfo::getGCCRegNames() const {


Index: test/CodeGenOpenCL/amdgcn-flat-scratch-name.cl
===
--- /dev/null
+++ test/CodeGenOpenCL/amdgcn-flat-scratch-name.cl
@@ -0,0 +1,15 @@
+// REQUIRES: amdgpu-registered-target
+// RUN: %clang_cc1 -triple amdgcn-unknown-unknown -S -emit-llvm -o - %s | FileCheck %s
+
+// CHECK-LABEL: @use_flat_scratch_name
+kernel void use_flat_scratch_name()
+{
+// CHECK: tail call void asm sideeffect "s_mov_b64 flat_scratch, 0", "~{flat_scratch}"()
+  __asm__ volatile("s_mov_b64 flat_scratch, 0" : : : "flat_scratch");
+
+// CHECK: tail call void asm sideeffect "s_mov_b32 flat_scratch_lo, 0", "~{flat_scratch_lo}"()
+  __asm__ volatile("s_mov_b32 flat_scratch_lo, 0" : : : "flat_scratch_lo");
+
+// CHECK: tail call void asm sideeffect "s_mov_b32 flat_scratch_hi, 0", "~{flat_scratch_hi}"()
+  __asm__ volatile("s_mov_b32 flat_scratch_hi, 0" : : : "flat_scratch_hi");
+}
Index: lib/Basic/Targets.cpp
===
--- lib/Basic/Targets.cpp
+++ lib/Basic/Targets.cpp
@@ -2047,8 +2047,8 @@
   "s104", "s105", "s106", "s107", "s108", "s109", "s110", "s111",
   "s112", "s113", "s114", "s115", "s116", "s117", "s118", "s119",
   "s120", "s121", "s122", "s123", "s124", "s125", "s126", "s127"
-  "exec", "vcc", "scc", "m0", "flat_scr", "exec_lo", "exec_hi",
-  "vcc_lo", "vcc_hi", "flat_scr_lo", "flat_scr_hi"
+  "exec", "vcc", "scc", "m0", "flat_scratch", "exec_lo", "exec_hi",
+  "vcc_lo", "vcc_hi", "flat_scratch_lo", "flat_scratch_hi"
 };
 
 ArrayRef AMDGPUTargetInfo::getGCCRegNames() const {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r261563 - clang-format: [JS] Add @return to the supported JSDoc pragmas in Google

2016-02-22 Thread Daniel Jasper via cfe-commits
Author: djasper
Date: Mon Feb 22 14:24:11 2016
New Revision: 261563

URL: http://llvm.org/viewvc/llvm-project?rev=261563=rev
Log:
clang-format: [JS] Add @return to the supported JSDoc pragmas in Google
style.

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

Modified: cfe/trunk/lib/Format/Format.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/Format.cpp?rev=261563=261562=261563=diff
==
--- cfe/trunk/lib/Format/Format.cpp (original)
+++ cfe/trunk/lib/Format/Format.cpp Mon Feb 22 14:24:11 2016
@@ -587,7 +587,7 @@ FormatStyle getGoogleStyle(FormatStyle::
 GoogleStyle.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_Inline;
 GoogleStyle.AlwaysBreakBeforeMultilineStrings = false;
 GoogleStyle.BreakBeforeTernaryOperators = false;
-GoogleStyle.CommentPragmas = "@(export|see|visibility) ";
+GoogleStyle.CommentPragmas = "@(export|return|see|visibility) ";
 GoogleStyle.MaxEmptyLinesToKeep = 3;
 GoogleStyle.SpacesInContainerLiterals = false;
   } else if (Language == FormatStyle::LK_Proto) {


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


[PATCH] D17519: AMDGPU: Fix broken/confusing predefined macro

2016-02-22 Thread Matt Arsenault via cfe-commits
arsenm created this revision.
arsenm added a reviewer: tstellarAMD.
arsenm added a subscriber: cfe-commits.

amdgcn should not be defining __R600__

http://reviews.llvm.org/D17519

Files:
  lib/Basic/Targets.cpp
  test/Preprocessor/predefined-arch-macros.c

Index: test/Preprocessor/predefined-arch-macros.c
===
--- test/Preprocessor/predefined-arch-macros.c
+++ test/Preprocessor/predefined-arch-macros.c
@@ -1824,3 +1824,17 @@
 // RUN:   | FileCheck %s -check-prefix=CHECK_SYSTEMZ_ZVECTOR
 //
 // CHECK_SYSTEMZ_ZVECTOR: #define __VEC__ 10301
+
+// Begin amdgcn tests 
+//
+// RUN: %clang -march=amdgcn -E -dM %s -o - 2>&1 \
+// RUN: -target amdgcn-unknown-unknown \
+// RUN:   | FileCheck %s -check-prefix=CHECK_AMDGCN
+// CHECK_AMDGCN: #define __AMDGCN__ 1
+
+// Begin r600 tests 
+//
+// RUN: %clang -march=amdgcn -E -dM %s -o - 2>&1 \
+// RUN: -target r600-unknown-unknown \
+// RUN:   | FileCheck %s -check-prefix=CHECK_R600
+// CHECK_R600: #define __R600__ 1
Index: lib/Basic/Targets.cpp
===
--- lib/Basic/Targets.cpp
+++ lib/Basic/Targets.cpp
@@ -1878,7 +1878,11 @@
 
   void getTargetDefines(const LangOptions ,
 MacroBuilder ) const override {
-Builder.defineMacro("__R600__");
+if (getTriple().getArch() == llvm::Triple::amdgcn)
+  Builder.defineMacro("__AMDGCN__");
+else
+  Builder.defineMacro("__R600__");
+
 if (hasFMAF)
   Builder.defineMacro("__HAS_FMAF__");
 if (hasLDEXPF)


Index: test/Preprocessor/predefined-arch-macros.c
===
--- test/Preprocessor/predefined-arch-macros.c
+++ test/Preprocessor/predefined-arch-macros.c
@@ -1824,3 +1824,17 @@
 // RUN:   | FileCheck %s -check-prefix=CHECK_SYSTEMZ_ZVECTOR
 //
 // CHECK_SYSTEMZ_ZVECTOR: #define __VEC__ 10301
+
+// Begin amdgcn tests 
+//
+// RUN: %clang -march=amdgcn -E -dM %s -o - 2>&1 \
+// RUN: -target amdgcn-unknown-unknown \
+// RUN:   | FileCheck %s -check-prefix=CHECK_AMDGCN
+// CHECK_AMDGCN: #define __AMDGCN__ 1
+
+// Begin r600 tests 
+//
+// RUN: %clang -march=amdgcn -E -dM %s -o - 2>&1 \
+// RUN: -target r600-unknown-unknown \
+// RUN:   | FileCheck %s -check-prefix=CHECK_R600
+// CHECK_R600: #define __R600__ 1
Index: lib/Basic/Targets.cpp
===
--- lib/Basic/Targets.cpp
+++ lib/Basic/Targets.cpp
@@ -1878,7 +1878,11 @@
 
   void getTargetDefines(const LangOptions ,
 MacroBuilder ) const override {
-Builder.defineMacro("__R600__");
+if (getTriple().getArch() == llvm::Triple::amdgcn)
+  Builder.defineMacro("__AMDGCN__");
+else
+  Builder.defineMacro("__R600__");
+
 if (hasFMAF)
   Builder.defineMacro("__HAS_FMAF__");
 if (hasLDEXPF)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D15829: [PGO] Clang Option that enables IR level PGO instrumentation

2016-02-22 Thread Rong Xu via cfe-commits
xur marked an inline comment as done.
xur added a comment.

I'll send a revised patch soon.



Comment at: lib/CodeGen/CodeGenModule.cpp:150
@@ -149,2 +149,3 @@
 
-  if (!CodeGenOpts.InstrProfileInput.empty()) {
+  if (!CodeGenOpts.hasProfileIRInstr() &&
+  !CodeGenOpts.InstrProfileInput.empty()) {

davidxl wrote:
> Better to use if (CodeGenOpts.hasProfileClangInstr() && ..)
OK. That would require to insert an extra cc1 option of 
-profile-instrument=clang for profile-use. And possibly some test case option 
changes too.


Comment at: lib/Driver/Tools.cpp:3201
@@ +3200,3 @@
+// Set the profile kind if it's not the default clang kind.
+static void setProfileKindFlag(ArgStringList ,
+   std::string ProfileName) {

davidxl wrote:
> I don't quite like this change in the driver. I think the right thing to do 
> is:
> 
> 1) for profile use case, there is no need to pass -fprofile-instrument=<...> 
> FE option from the driver
> 2) The profileInstrKind determination needs to happen in FE (not driver) by 
> peeking into the passed in profile data.
I'll split off the profile kind detection to a separated patch suggested by 
Sean.


Comment at: test/CodeGen/pgo-instrumentation.c:4
@@ +3,3 @@
+// Ensure Pass PGOInstrumentationGenPass is invoked.
+// RUN: %clang -O2 -c -Xclang -fprofile-instrument=llvm 
-fprofile-instr-generate %s -mllvm -debug-pass=Structure 2>&1 | FileCheck %s 
-check-prefix=CHECK-PGOGENPASS-INVOKED-INSTR-GEN
+// CHECK-PGOGENPASS-INVOKED-INSTR-GEN: PGOInstrumentationGenPass

silvas wrote:
> Use `%clang_cc1` here and elsewhere.
Will do.


http://reviews.llvm.org/D15829



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


r261560 - [WebAssembly] Initial driver support for standard library paths.

2016-02-22 Thread Dan Gohman via cfe-commits
Author: djg
Date: Mon Feb 22 13:26:15 2016
New Revision: 261560

URL: http://llvm.org/viewvc/llvm-project?rev=261560=rev
Log:
[WebAssembly] Initial driver support for standard library paths.

Modified:
cfe/trunk/lib/Driver/ToolChains.cpp
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/test/Driver/wasm-toolchain.c

Modified: cfe/trunk/lib/Driver/ToolChains.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp?rev=261560=261559=261560=diff
==
--- cfe/trunk/lib/Driver/ToolChains.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains.cpp Mon Feb 22 13:26:15 2016
@@ -4468,6 +4468,11 @@ Tool *MyriadToolChain::buildLinker() con
 WebAssembly::WebAssembly(const Driver , const llvm::Triple ,
  const llvm::opt::ArgList )
   : ToolChain(D, Triple, Args) {
+
+  assert(Triple.isArch32Bit() != Triple.isArch64Bit());
+  getFilePaths().push_back(
+  getDriver().SysRoot + "/lib" + (Triple.isArch32Bit() ? "32" : "64"));
+
   // Use LLD by default.
   DefaultLinker = "lld";
 }

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=261560=261559=261560=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Mon Feb 22 13:26:15 2016
@@ -6613,7 +6613,10 @@ void wasm::Linker::ConstructJob(Compilat
 const InputInfoList ,
 const ArgList ,
 const char *LinkingOutput) const {
-  const char *Linker = Args.MakeArgString(getToolChain().GetLinkerPath());
+
+  const ToolChain  = getToolChain();
+  const Driver  = ToolChain.getDriver();
+  const char *Linker = Args.MakeArgString(ToolChain.GetLinkerPath());
   ArgStringList CmdArgs;
   CmdArgs.push_back("-flavor");
   CmdArgs.push_back("ld");
@@ -6625,9 +6628,48 @@ void wasm::Linker::ConstructJob(Compilat
   if (areOptimizationsEnabled(Args))
 CmdArgs.push_back("--gc-sections");
 
-  AddLinkerInputs(getToolChain(), Inputs, Args, CmdArgs);
+  if (Args.hasArg(options::OPT_rdynamic))
+CmdArgs.push_back("-export-dynamic");
+  if (Args.hasArg(options::OPT_s))
+CmdArgs.push_back("--strip-all");
+  if (Args.hasArg(options::OPT_shared))
+CmdArgs.push_back("-shared");
+  if (Args.hasArg(options::OPT_static))
+CmdArgs.push_back("-Bstatic");
+
+  Args.AddAllArgs(CmdArgs, options::OPT_L);
+  ToolChain.AddFilePathLibArgs(Args, CmdArgs);
+
+  if (!Args.hasArg(options::OPT_nostdlib, options::OPT_nostartfiles)) {
+if (Args.hasArg(options::OPT_shared))
+  CmdArgs.push_back(Args.MakeArgString(ToolChain.GetFilePath("rcrt1.o")));
+else if (Args.hasArg(options::OPT_pie))
+  CmdArgs.push_back(Args.MakeArgString(ToolChain.GetFilePath("Scrt1.o")));
+else
+  CmdArgs.push_back(Args.MakeArgString(ToolChain.GetFilePath("crt1.o")));
+
+CmdArgs.push_back(Args.MakeArgString(ToolChain.GetFilePath("crti.o")));
+  }
+
+  AddLinkerInputs(ToolChain, Inputs, Args, CmdArgs);
+
+  if (!Args.hasArg(options::OPT_nostdlib, options::OPT_nodefaultlibs)) {
+if (D.CCCIsCXX())
+  ToolChain.AddCXXStdlibLibArgs(Args, CmdArgs);
+
+if (Args.hasArg(options::OPT_pthread))
+  CmdArgs.push_back("-lpthread");
+
+CmdArgs.push_back("-lc");
+CmdArgs.push_back("-lcompiler_rt");
+  }
+
+  if (!Args.hasArg(options::OPT_nostdlib, options::OPT_nostartfiles))
+CmdArgs.push_back(Args.MakeArgString(ToolChain.GetFilePath("crtn.o")));
+
   CmdArgs.push_back("-o");
   CmdArgs.push_back(Output.getFilename());
+
   C.addCommand(llvm::make_unique(JA, *this, Linker, CmdArgs, Inputs));
 }
 

Modified: cfe/trunk/test/Driver/wasm-toolchain.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/wasm-toolchain.c?rev=261560=261559=261560=diff
==
--- cfe/trunk/test/Driver/wasm-toolchain.c (original)
+++ cfe/trunk/test/Driver/wasm-toolchain.c Mon Feb 22 13:26:15 2016
@@ -25,20 +25,20 @@
 
 // A basic C link command-line.
 
-// RUN: %clang -### -no-canonical-prefixes -target wasm32-unknown-unknown %s 
2>&1 | FileCheck -check-prefix=LINK %s
+// RUN: %clang -### -no-canonical-prefixes -target wasm32-unknown-unknown 
--sysroot=/foo %s 2>&1 | FileCheck -check-prefix=LINK %s
 // LINK: clang{{.*}}" "-cc1" {{.*}} "-o" "[[temp:[^"]*]]"
-// LINK: lld{{.*}}" "-flavor" "ld" "[[temp]]" "-o" "a.out"
+// LINK: lld{{.*}}" "-flavor" "ld" "-L/foo/lib32" "crt1.o" "crti.o" "[[temp]]" 
"-lc" "-lcompiler_rt" "crtn.o" "-o" "a.out"
 
 // A basic C link command-line with optimization. WebAssembly is somewhat
 // special in enabling --gc-sections by default.
 
-// RUN: %clang -### -O2 -no-canonical-prefixes -target wasm32-unknown-unknown 
%s 2>&1 | FileCheck -check-prefix=LINK_OPT %s
+// RUN: %clang -### -O2 -no-canonical-prefixes -target 

r261557 - [WebAssembly] Lower va_arg in clang.

2016-02-22 Thread Dan Gohman via cfe-commits
Author: djg
Date: Mon Feb 22 13:17:40 2016
New Revision: 261557

URL: http://llvm.org/viewvc/llvm-project?rev=261557=rev
Log:
[WebAssembly] Lower va_arg in clang.

This uses the general emitVoidPtrVAArg lowering logic for everything, since
this supports all types, and we don't have any special requirements.

Added:
cfe/trunk/test/CodeGen/wasm-varargs.c
Modified:
cfe/trunk/lib/CodeGen/TargetInfo.cpp

Modified: cfe/trunk/lib/CodeGen/TargetInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp?rev=261557=261556=261557=diff
==
--- cfe/trunk/lib/CodeGen/TargetInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/TargetInfo.cpp Mon Feb 22 13:17:40 2016
@@ -616,6 +616,9 @@ private:
 for (auto  : FI.arguments())
   Arg.info = classifyArgumentType(Arg.type);
   }
+
+  Address EmitVAArg(CodeGenFunction , Address VAListAddr,
+QualType Ty) const override;
 };
 
 class WebAssemblyTargetCodeGenInfo final : public TargetCodeGenInfo {
@@ -667,6 +670,14 @@ ABIArgInfo WebAssemblyABIInfo::classifyR
   return DefaultABIInfo::classifyReturnType(RetTy);
 }
 
+Address WebAssemblyABIInfo::EmitVAArg(CodeGenFunction , Address VAListAddr,
+  QualType Ty) const {
+  return emitVoidPtrVAArg(CGF, VAListAddr, Ty, /*Indirect=*/ false,
+  getContext().getTypeInfoInChars(Ty),
+  CharUnits::fromQuantity(4),
+  /*AllowHigherAlign=*/ true);
+}
+
 
//===--===//
 // le32/PNaCl bitcode ABI Implementation
 //

Added: cfe/trunk/test/CodeGen/wasm-varargs.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/wasm-varargs.c?rev=261557=auto
==
--- cfe/trunk/test/CodeGen/wasm-varargs.c (added)
+++ cfe/trunk/test/CodeGen/wasm-varargs.c Mon Feb 22 13:17:40 2016
@@ -0,0 +1,103 @@
+// RUN: %clang_cc1 -triple wasm32-unknown-unknown -o - -emit-llvm %s | 
FileCheck %s
+
+#include 
+
+int test_i32(char *fmt, ...) {
+  va_list va;
+
+  va_start(va, fmt);
+  int v = va_arg(va, int);
+  va_end(va);
+
+  return v;
+}
+
+// CHECK-LABEL: define i32 @test_i32(i8*{{.*}} %fmt, ...) {{.*}} {
+// CHECK:   [[FMT_ADDR:%[^,=]+]] = alloca i8*, align 4
+// CHECK:   [[VA:%[^,=]+]] = alloca i8*, align 4
+// CHECK:   [[V:%[^,=]+]] = alloca i32, align 4
+// CHECK:   store i8* %fmt, i8** [[FMT_ADDR]], align 4
+// CHECK:   [[VA1:%[^,=]+]] = bitcast i8** [[VA]] to i8*
+// CHECK:   call void @llvm.va_start(i8* [[VA1]])
+// CHECK:   [[ARGP_CUR:%[^,=]+]] = load i8*, i8** [[VA]], align 4
+// CHECK:   [[ARGP_NEXT:%[^,=]+]] = getelementptr inbounds i8, i8* 
[[ARGP_CUR]], i32 4
+// CHECK:   store i8* [[ARGP_NEXT]], i8** [[VA]], align 4
+// CHECK:   [[R3:%[^,=]+]] = bitcast i8* [[ARGP_CUR]] to i32*
+// CHECK:   [[R4:%[^,=]+]] = load i32, i32* [[R3]], align 4
+// CHECK:   store i32 [[R4]], i32* [[V]], align 4
+// CHECK:   [[VA2:%[^,=]+]] = bitcast i8** [[VA]] to i8*
+// CHECK:   call void @llvm.va_end(i8* [[VA2]])
+// CHECK:   [[R5:%[^,=]+]] = load i32, i32* [[V]], align 4
+// CHECK:   ret i32 [[R5]]
+// CHECK: }
+
+long long test_i64(char *fmt, ...) {
+  va_list va;
+
+  va_start(va, fmt);
+  long long v = va_arg(va, long long);
+  va_end(va);
+
+  return v;
+}
+
+// CHECK-LABEL: define i64 @test_i64(i8*{{.*}} %fmt, ...) {{.*}} {
+// CHECK:   [[FMT_ADDR:%[^,=]+]] = alloca i8*, align 4
+// CHECK:   [[VA:%[^,=]+]] = alloca i8*, align 4
+// CHECK:   [[V:%[^,=]+]] = alloca i64, align 8
+// CHECK:   store i8* %fmt, i8** [[FMT_ADDR]], align 4
+// CHECK:   [[VA1:%[^,=]+]] = bitcast i8** [[VA]] to i8*
+// CHECK:   call void @llvm.va_start(i8* [[VA1]])
+// CHECK:   [[ARGP_CUR:%[^,=]+]] = load i8*, i8** [[VA]], align 4
+// CHECK:   [[R0:%[^,=]+]] = ptrtoint i8* [[ARGP_CUR]] to i32
+// CHECK:   [[R1:%[^,=]+]] = add i32 [[R0]], 7
+// CHECK:   [[R2:%[^,=]+]] = and i32 [[R1]], -8
+// CHECK:   [[ARGP_CUR_ALIGNED:%[^,=]+]] = inttoptr i32 [[R2]] to i8*
+// CHECK:   [[ARGP_NEXT:%[^,=]+]] = getelementptr inbounds i8, i8* 
[[ARGP_CUR_ALIGNED]], i32 8
+// CHECK:   store i8* [[ARGP_NEXT]], i8** [[VA]], align 4
+// CHECK:   [[R3:%[^,=]+]] = bitcast i8* [[ARGP_CUR_ALIGNED]] to i64*
+// CHECK:   [[R4:%[^,=]+]] = load i64, i64* [[R3]], align 8
+// CHECK:   store i64 [[R4]], i64* [[V]], align 8
+// CHECK:   [[VA2:%[^,=]+]] = bitcast i8** [[VA]] to i8*
+// CHECK:   call void @llvm.va_end(i8* [[VA2]])
+// CHECK:   [[R5:%[^,=]+]] = load i64, i64* [[V]], align 8
+// CHECK:   ret i64 [[R5]]
+// CHECK: }
+
+struct S {
+int x;
+int y;
+int z;
+};
+
+struct S test_struct(char *fmt, ...) {
+  va_list va;
+
+  va_start(va, fmt);
+  struct S v = va_arg(va, struct S);
+  va_end(va);
+
+  return v;
+}
+
+// CHECK: define void @test_struct([[STRUCT_S:%[^,=]+]]*{{.*}} noalias sret 
%agg.result, i8*{{.*}} %fmt, ...) {{.*}} {

Re: [PATCH] D17484: [clang-tidy] introduce modernize-deprecated-headers check

2016-02-22 Thread Kirill Bobyrev via cfe-commits
omtcyf0 added a comment.

Marked the comments as *done*.



Comment at: test/clang-tidy/modernize-deprecated-headers-cxx03.cpp:1
@@ +1,2 @@
+// RUN: %check_clang_tidy %s modernize-deprecated-headers %t -- -- -std=c++03 
-isystem %S/Inputs/Headers
+

alexfh wrote:
> You seem to have forgotten to add these headers to `Inputs/Headers`. Or 
> doesn't the check care about them actually being present?
Correct. It doesn't care about them being present.


http://reviews.llvm.org/D17484



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


Re: [PATCH] D17457: [VFS] Add 'overlay-relative' field to YAML files

2016-02-22 Thread Bruno Cardoso Lopes via cfe-commits
bruno closed this revision.
bruno added a comment.

Committed r261552 / r261556


http://reviews.llvm.org/D17457



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


Re: [PATCH] D17104: [VFS] Drop path traversal assertion

2016-02-22 Thread Bruno Cardoso Lopes via cfe-commits
bruno closed this revision.
bruno added a comment.

Committed r261551


http://reviews.llvm.org/D17104



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


Re: [PATCH] D17484: [clang-tidy] introduce modernize-deprecated-headers check

2016-02-22 Thread Kirill Bobyrev via cfe-commits
omtcyf0 updated this revision to Diff 48711.
omtcyf0 marked 9 inline comments as done.
omtcyf0 added a comment.

Fixed all the issues @alexfh pointed to.


http://reviews.llvm.org/D17484

Files:
  clang-tidy/modernize/CMakeLists.txt
  clang-tidy/modernize/DeprecatedHeadersCheck.cpp
  clang-tidy/modernize/DeprecatedHeadersCheck.h
  clang-tidy/modernize/ModernizeTidyModule.cpp
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/modernize-deprecated-headers.rst
  test/clang-tidy/modernize-deprecated-headers-cxx03.cpp
  test/clang-tidy/modernize-deprecated-headers-cxx11.cpp

Index: test/clang-tidy/modernize-deprecated-headers-cxx11.cpp
===
--- /dev/null
+++ test/clang-tidy/modernize-deprecated-headers-cxx11.cpp
@@ -0,0 +1,163 @@
+// RUN: %check_clang_tidy %s modernize-deprecated-headers %t -- -- -std=c++11 -isystem %S/Inputs/Headers
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+// CHECK-MESSAGES: :[[@LINE-27]]:10: warning: including deprecated C++ header [modernize-deprecated-headers]
+// CHECK-MESSAGES: :[[@LINE-27]]:10: warning: including deprecated C++ header [modernize-deprecated-headers]
+// CHECK-MESSAGES: :[[@LINE-27]]:10: warning: including deprecated C++ header [modernize-deprecated-headers]
+// CHECK-MESSAGES: :[[@LINE-27]]:10: warning: including deprecated C++ header [modernize-deprecated-headers]
+// CHECK-MESSAGES: :[[@LINE-27]]:10: warning: including deprecated C++ header [modernize-deprecated-headers]
+// CHECK-MESSAGES: :[[@LINE-27]]:10: warning: including deprecated C++ header [modernize-deprecated-headers]
+// CHECK-MESSAGES: :[[@LINE-27]]:10: warning: including deprecated C++ header [modernize-deprecated-headers]
+// CHECK-MESSAGES: :[[@LINE-27]]:10: warning: including deprecated C++ header [modernize-deprecated-headers]
+// CHECK-MESSAGES: :[[@LINE-27]]:10: warning: including deprecated C++ header [modernize-deprecated-headers]
+// CHECK-MESSAGES: :[[@LINE-27]]:10: warning: including deprecated C++ header [modernize-deprecated-headers]
+// CHECK-MESSAGES: :[[@LINE-27]]:10: warning: including deprecated C++ header [modernize-deprecated-headers]
+// CHECK-MESSAGES: :[[@LINE-27]]:10: warning: including deprecated C++ header [modernize-deprecated-headers]
+// CHECK-MESSAGES: :[[@LINE-27]]:10: warning: including deprecated C++ header [modernize-deprecated-headers]
+// CHECK-MESSAGES: :[[@LINE-27]]:10: warning: including deprecated C++ header [modernize-deprecated-headers]
+// CHECK-MESSAGES: :[[@LINE-27]]:10: warning: including deprecated C++ header [modernize-deprecated-headers]
+// CHECK-MESSAGES: :[[@LINE-27]]:10: warning: including deprecated C++ header [modernize-deprecated-headers]
+// CHECK-MESSAGES: :[[@LINE-27]]:10: warning: including deprecated C++ header [modernize-deprecated-headers]
+// CHECK-MESSAGES: :[[@LINE-27]]:10: warning: including deprecated C++ header [modernize-deprecated-headers]
+// CHECK-MESSAGES: :[[@LINE-27]]:10: warning: including deprecated C++ header [modernize-deprecated-headers]
+// CHECK-MESSAGES: :[[@LINE-27]]:10: warning: including deprecated C++ header [modernize-deprecated-headers]
+// CHECK-MESSAGES: :[[@LINE-27]]:10: warning: including deprecated C++ header [modernize-deprecated-headers]
+// CHECK-MESSAGES: :[[@LINE-27]]:10: warning: including deprecated C++ header [modernize-deprecated-headers]
+// CHECK-MESSAGES: :[[@LINE-27]]:10: warning: including deprecated C++ header [modernize-deprecated-headers]
+// CHECK-MESSAGES: :[[@LINE-27]]:10: warning: including deprecated C++ header [modernize-deprecated-headers]
+// CHECK-MESSAGES: :[[@LINE-27]]:10: warning: including deprecated C++ header [modernize-deprecated-headers]
+// CHECK-MESSAGES: :[[@LINE-27]]:10: warning: including deprecated C++ header [modernize-deprecated-headers]
+
+// CHECK-FIXES: #include 
+// CHECK-FIXES: #include 
+// CHECK-FIXES: #include 
+// CHECK-FIXES: #include 
+// CHECK-FIXES: #include 
+// CHECK-FIXES: #include 
+// CHECK-FIXES: #include 
+// CHECK-FIXES: #include 
+// CHECK-FIXES: #include 
+// CHECK-FIXES: #include 
+// CHECK-FIXES: #include 
+// CHECK-FIXES: #include 
+// CHECK-FIXES: #include 
+// CHECK-FIXES: #include 
+// CHECK-FIXES: #include 
+// CHECK-FIXES: #include 
+// CHECK-FIXES: #include 
+// CHECK-FIXES: #include 
+// CHECK-FIXES: #include 
+// CHECK-FIXES: #include 
+// CHECK-FIXES: #include 
+// CHECK-FIXES: #include 
+// CHECK-FIXES: #include 
+// CHECK-FIXES: #include 
+// CHECK-FIXES: #include 
+// CHECK-FIXES: #include 
+
+#include "assert.h"
+#include "complex.h"
+#include "ctype.h"
+#include "errno.h"
+#include "fenv.h"
+#include "float.h"
+#include "inttypes.h"
+#include "iso646.h"
+#include "limits.h"
+#include "locale.h"
+#include "math.h"

Re: r261548 - Add has_feature attribute_availability_with_strict.

2016-02-22 Thread Aaron Ballman via cfe-commits
On Mon, Feb 22, 2016 at 1:57 PM, Manman Ren  wrote:
>
> On Feb 22, 2016, at 10:37 AM, Aaron Ballman via cfe-commits
>  wrote:
>
> On Mon, Feb 22, 2016 at 1:24 PM, Manman Ren via cfe-commits
>  wrote:
>
> Author: mren
> Date: Mon Feb 22 12:24:30 2016
> New Revision: 261548
>
> URL: http://llvm.org/viewvc/llvm-project?rev=261548=rev
> Log:
> Add has_feature attribute_availability_with_strict.
>
> rdar://23791325
>
>
> Please add more context to commit logs; radar reports in commit logs
> don't help those of us who are not at Apple. Also, I don't recall
> seeing this patch go through the review process, can you point me to
> the thread?
>
>
> This is a follow-up to r261163 and r261512. The strict qualifier was added
> in these two revisions.
> Sorry for not putting in the context in the commit message,

Thank you for the context. Since this is a user-facing change, it
probably should have had a separate review so we could discuss things
like __has_feature vs __has_attribute before the commit goes live.
That being said: patch LGTM. :-)

~Aaron

>
> Manman
>
>
>
> Modified:
>cfe/trunk/lib/Lex/PPMacroExpansion.cpp
>cfe/trunk/test/Sema/attr-availability-macosx.c
>
> Modified: cfe/trunk/lib/Lex/PPMacroExpansion.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/PPMacroExpansion.cpp?rev=261548=261547=261548=diff
> ==
> --- cfe/trunk/lib/Lex/PPMacroExpansion.cpp (original)
> +++ cfe/trunk/lib/Lex/PPMacroExpansion.cpp Mon Feb 22 12:24:30 2016
> @@ -1066,6 +1066,7 @@ static bool HasFeature(const Preprocesso
>   .Case("attribute_availability_with_version_underscores", true)
>   .Case("attribute_availability_tvos", true)
>   .Case("attribute_availability_watchos", true)
> +  .Case("attribute_availability_with_strict", true)
>
>
> I wonder if this would actually be better as an attribute feature
> testing macro, instead of bolted on to __has_feature. It's strange to
> have attribute feature testing capabilities and not use them. That
> being said, I'm not opposed to this patch as-is because there are
> other attribute_availability_* feature test.
>
> Thanks!
>
> ~Aaron
>
>   .Case("attribute_cf_returns_not_retained", true)
>   .Case("attribute_cf_returns_retained", true)
>   .Case("attribute_cf_returns_on_parameters", true)
>
> Modified: cfe/trunk/test/Sema/attr-availability-macosx.c
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/attr-availability-macosx.c?rev=261548=261547=261548=diff
> ==
> --- cfe/trunk/test/Sema/attr-availability-macosx.c (original)
> +++ cfe/trunk/test/Sema/attr-availability-macosx.c Mon Feb 22 12:24:30 2016
> @@ -1,5 +1,9 @@
> // RUN: %clang_cc1 "-triple" "x86_64-apple-darwin9.0.0" -fsyntax-only
> -verify %s
>
> +#if !__has_feature(attribute_availability_with_strict)
> +#error "Missing __has_feature"
> +#endif
> +
> void f0(int)
> __attribute__((availability(macosx,introduced=10.4,deprecated=10.6)));
> void f1(int) __attribute__((availability(macosx,introduced=10.5)));
> void f2(int)
> __attribute__((availability(macosx,introduced=10.4,deprecated=10.5))); //
> expected-note {{'f2' has been explicitly marked deprecated here}}
>
>
> ___
> 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
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r261556 - [VFS] Fix call to getVFSFromYAML in unittests

2016-02-22 Thread Bruno Cardoso Lopes via cfe-commits
Author: bruno
Date: Mon Feb 22 13:02:27 2016
New Revision: 261556

URL: http://llvm.org/viewvc/llvm-project?rev=261556=rev
Log:
[VFS] Fix call to getVFSFromYAML in unittests

Follow up from r261552

Modified:
cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp

Modified: cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp?rev=261556=261555=261556=diff
==
--- cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp (original)
+++ cfe/trunk/unittests/Basic/VirtualFileSystemTest.cpp Mon Feb 22 13:02:27 2016
@@ -662,7 +662,7 @@ public:
   getFromYAMLRawString(StringRef Content,
IntrusiveRefCntPtr ExternalFS) {
 std::unique_ptr Buffer = MemoryBuffer::getMemBuffer(Content);
-return getVFSFromYAML(std::move(Buffer), CountingDiagHandler, this,
+return getVFSFromYAML(std::move(Buffer), CountingDiagHandler, "", this,
   ExternalFS);
   }
 


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


Re: r261548 - Add has_feature attribute_availability_with_strict.

2016-02-22 Thread Manman Ren via cfe-commits

> On Feb 22, 2016, at 10:37 AM, Aaron Ballman via cfe-commits 
>  wrote:
> 
> On Mon, Feb 22, 2016 at 1:24 PM, Manman Ren via cfe-commits
> > wrote:
>> Author: mren
>> Date: Mon Feb 22 12:24:30 2016
>> New Revision: 261548
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=261548=rev 
>> 
>> Log:
>> Add has_feature attribute_availability_with_strict.
>> 
>> rdar://23791325 
> 
> Please add more context to commit logs; radar reports in commit logs
> don't help those of us who are not at Apple. Also, I don't recall
> seeing this patch go through the review process, can you point me to
> the thread?

This is a follow-up to r261163 and r261512. The strict qualifier was added in 
these two revisions.
Sorry for not putting in the context in the commit message,

Manman

> 
>> 
>> Modified:
>>cfe/trunk/lib/Lex/PPMacroExpansion.cpp
>>cfe/trunk/test/Sema/attr-availability-macosx.c
>> 
>> Modified: cfe/trunk/lib/Lex/PPMacroExpansion.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/PPMacroExpansion.cpp?rev=261548=261547=261548=diff
>> ==
>> --- cfe/trunk/lib/Lex/PPMacroExpansion.cpp (original)
>> +++ cfe/trunk/lib/Lex/PPMacroExpansion.cpp Mon Feb 22 12:24:30 2016
>> @@ -1066,6 +1066,7 @@ static bool HasFeature(const Preprocesso
>>   .Case("attribute_availability_with_version_underscores", true)
>>   .Case("attribute_availability_tvos", true)
>>   .Case("attribute_availability_watchos", true)
>> +  .Case("attribute_availability_with_strict", true)
> 
> I wonder if this would actually be better as an attribute feature
> testing macro, instead of bolted on to __has_feature. It's strange to
> have attribute feature testing capabilities and not use them. That
> being said, I'm not opposed to this patch as-is because there are
> other attribute_availability_* feature test.
> 
> Thanks!
> 
> ~Aaron
> 
>>   .Case("attribute_cf_returns_not_retained", true)
>>   .Case("attribute_cf_returns_retained", true)
>>   .Case("attribute_cf_returns_on_parameters", true)
>> 
>> Modified: cfe/trunk/test/Sema/attr-availability-macosx.c
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/attr-availability-macosx.c?rev=261548=261547=261548=diff
>> ==
>> --- cfe/trunk/test/Sema/attr-availability-macosx.c (original)
>> +++ cfe/trunk/test/Sema/attr-availability-macosx.c Mon Feb 22 12:24:30 2016
>> @@ -1,5 +1,9 @@
>> // RUN: %clang_cc1 "-triple" "x86_64-apple-darwin9.0.0" -fsyntax-only 
>> -verify %s
>> 
>> +#if !__has_feature(attribute_availability_with_strict)
>> +#error "Missing __has_feature"
>> +#endif
>> +
>> void f0(int) 
>> __attribute__((availability(macosx,introduced=10.4,deprecated=10.6)));
>> void f1(int) __attribute__((availability(macosx,introduced=10.5)));
>> void f2(int) 
>> __attribute__((availability(macosx,introduced=10.4,deprecated=10.5))); // 
>> expected-note {{'f2' has been explicitly marked deprecated here}}
>> 
>> 
>> ___
>> 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 
> 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: r261422 - Fix handling of vaargs on PPC32 when going from regsave to overflow.

2016-02-22 Thread Hans Wennborg via cfe-commits
On Sat, Feb 20, 2016 at 6:29 AM, Hal Finkel  wrote:
>
>
> - Original Message -
>> From: "Dimitry Andric via cfe-commits" 
>> To: "Hans Wennborg" 
>> Cc: "Roman Divacky" , "cfe-commits" 
>> 
>> Sent: Saturday, February 20, 2016 8:24:36 AM
>> Subject: Re: r261422 - Fix handling of vaargs on PPC32 when going from 
>> regsave to overflow.
>>
>> On 20 Feb 2016, at 09:31, Roman Divacky via cfe-commits
>>  wrote:
>> >
>> > Author: rdivacky
>> > Date: Sat Feb 20 02:31:24 2016
>> > New Revision: 261422
>> >
>> > URL: http://llvm.org/viewvc/llvm-project?rev=261422=rev
>> > Log:
>> > Fix handling of vaargs on PPC32 when going from regsave to
>> > overflow.
>> >
>> > It can happen that when we only have 1 more register left in the
>> > regsave
>> > area we need to store a value bigger than 1 register and therefore
>> > we
>> > go to the overflow area. In this case we have to leave the last
>> > slot
>> > in the regsave area unused and keep using overflow area. Do this
>> > by storing a limit value to the used register counter in the
>> > overflow block.
>> >
>> > Issue diagnosed by and solution tested by Mark Millard!
>>
>> Hans, this looks like a nice minor fix to have in 3.8.0.  Can we
>> merge it, please?
>
> Fine by me.

r261553.

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


r261552 - [VFS] Add 'overlay-relative' field to YAML files

2016-02-22 Thread Bruno Cardoso Lopes via cfe-commits
Author: bruno
Date: Mon Feb 22 12:41:09 2016
New Revision: 261552

URL: http://llvm.org/viewvc/llvm-project?rev=261552=rev
Log:
[VFS] Add 'overlay-relative' field to YAML files

The VFS overlay mapping between virtual paths and real paths is done through
the 'external-contents' entries in YAML files, which contains hardcoded paths
to the real files.

When a module compilation crashes, headers are dumped into .cache/vfs
directory and are mapped via the .cache/vfs/vfs.yaml. The script
generated for reproduction uses -ivfsoverlay pointing to file to gather the
mapping between virtual paths and files inside .cache/vfs. Currently, we
are only capable of reproducing such crashes in the same machine as they
happen, because of the hardcoded paths in 'external-contents'.

To be able to reproduce a crash in another machine, this patch introduces a new
option in the VFS yaml file called 'overlay-relative'. When it's equal to
'true' it means that the provided path to the YAML file through the
-ivfsoverlay option should also be used to prefix the final path for every
'external-contents'.

Example, given the invocation snippet "... -ivfsoverlay
.cache/vfs/vfs.yaml" and the following entry in the yaml file:

"overlay-relative": "true",
"roots": [
...
  "type": "directory",
  "name": "/usr/include",
  "contents": [
{
  "type": "file",
  "name": "stdio.h",
  "external-contents": "/usr/include/stdio.h"
},
...

Here, a file manager request for virtual "/usr/include/stdio.h", that will map
into real path "//.cache/vfs/usr/include/stdio.h.

This is a useful feature for debugging module crashes in machines other than
the one where the error happened.

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

rdar://problem/24499339

Added:
cfe/trunk/test/Modules/crash-vfs-relative-overlay.m
  - copied, changed from r261551, 
cfe/trunk/test/Modules/crash-vfs-path-traversal.m
Modified:
cfe/trunk/include/clang/Basic/VirtualFileSystem.h
cfe/trunk/lib/Basic/VirtualFileSystem.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/lib/Frontend/ModuleDependencyCollector.cpp
cfe/trunk/test/Modules/crash-vfs-path-symlink-component.m
cfe/trunk/test/Modules/crash-vfs-path-traversal.m

Modified: cfe/trunk/include/clang/Basic/VirtualFileSystem.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/VirtualFileSystem.h?rev=261552=261551=261552=diff
==
--- cfe/trunk/include/clang/Basic/VirtualFileSystem.h (original)
+++ cfe/trunk/include/clang/Basic/VirtualFileSystem.h Mon Feb 22 12:41:09 2016
@@ -310,6 +310,7 @@ llvm::sys::fs::UniqueID getNextVirtualUn
 IntrusiveRefCntPtr
 getVFSFromYAML(std::unique_ptr Buffer,
llvm::SourceMgr::DiagHandlerTy DiagHandler,
+   StringRef YAMLFilePath,
void *DiagContext = nullptr,
IntrusiveRefCntPtr ExternalFS = 
getRealFileSystem());
 
@@ -323,6 +324,8 @@ struct YAMLVFSEntry {
 class YAMLVFSWriter {
   std::vector Mappings;
   Optional IsCaseSensitive;
+  Optional IsOverlayRelative;
+  std::string OverlayDir;
 
 public:
   YAMLVFSWriter() {}
@@ -330,6 +333,11 @@ public:
   void setCaseSensitivity(bool CaseSensitive) {
 IsCaseSensitive = CaseSensitive;
   }
+  void setOverlayDir(StringRef OverlayDirectory) {
+IsOverlayRelative = true;
+OverlayDir.assign(OverlayDirectory.str());
+  }
+
   void write(llvm::raw_ostream );
 };
 

Modified: cfe/trunk/lib/Basic/VirtualFileSystem.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/VirtualFileSystem.cpp?rev=261552=261551=261552=diff
==
--- cfe/trunk/lib/Basic/VirtualFileSystem.cpp (original)
+++ cfe/trunk/lib/Basic/VirtualFileSystem.cpp Mon Feb 22 12:41:09 2016
@@ -790,6 +790,7 @@ public:
 /// All configuration options are optional.
 ///   'case-sensitive': 
 ///   'use-external-names': 
+///   'overlay-relative': 
 ///
 /// Virtual directories are represented as
 /// \verbatim
@@ -832,6 +833,10 @@ class RedirectingFileSystem : public vfs
   std::vector Roots;
   /// \brief The file system to use for external references.
   IntrusiveRefCntPtr ExternalFS;
+  /// If IsRelativeOverlay is set, this represents the directory
+  /// path that should be prefixed to each 'external-contents' entry
+  /// when reading from YAML files.
+  std::string ExternalContentsPrefixDir;
 
   /// @name Configuration
   /// @{
@@ -841,6 +846,10 @@ class RedirectingFileSystem : public vfs
   /// Currently, case-insensitive matching only works correctly with ASCII.
   bool CaseSensitive;
 
+  /// IsRelativeOverlay marks whether a IsExternalContentsPrefixDir path must
+  /// be prefixed in every 'external-contents' when reading from YAML files.
+  bool IsRelativeOverlay = false;
+
   /// \brief Whether to 

r261551 - [VFS] Add support for handling path traversals

2016-02-22 Thread Bruno Cardoso Lopes via cfe-commits
Author: bruno
Date: Mon Feb 22 12:41:01 2016
New Revision: 261551

URL: http://llvm.org/viewvc/llvm-project?rev=261551=rev
Log:
[VFS] Add support for handling path traversals

Handle ".", ".." and "./" with trailing slashes while collecting files
to be dumped into the vfs overlay directory.

Include the support for symlinks into components. Given the path:

/install-dir/bin/../lib/clang/3.8.0/include/altivec.h, if "bin"
component is a symlink, it's not safe to use `path::remove_dots` here,
and `realpath` is used to get the right answer. Since `realpath`
is expensive, we only do it at collecting time (which only happens
during the crash reproducer) and cache the base directory for fast lookups.

Overall, this makes the input to the VFS YAML file to be canonicalized
to never contain traversal components.

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

rdar://problem/24499339

Added:
cfe/trunk/test/Modules/crash-vfs-path-symlink-component.m
cfe/trunk/test/Modules/crash-vfs-path-traversal.m
Modified:
cfe/trunk/lib/Basic/VirtualFileSystem.cpp
cfe/trunk/lib/Frontend/ModuleDependencyCollector.cpp

Modified: cfe/trunk/lib/Basic/VirtualFileSystem.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/VirtualFileSystem.cpp?rev=261551=261550=261551=diff
==
--- cfe/trunk/lib/Basic/VirtualFileSystem.cpp (original)
+++ cfe/trunk/lib/Basic/VirtualFileSystem.cpp Mon Feb 22 12:41:01 2016
@@ -111,6 +111,20 @@ bool FileSystem::exists(const Twine 
   return Status && Status->exists();
 }
 
+#ifndef NDEBUG
+static bool isTraversalComponent(StringRef Component) {
+  return Component.equals("..") || Component.equals(".");
+}
+
+static bool pathHasTraversal(StringRef Path) {
+  using namespace llvm::sys;
+  for (StringRef Comp : llvm::make_range(path::begin(Path), path::end(Path)))
+if (isTraversalComponent(Comp))
+  return true;
+  return false;
+}
+#endif
+
 
//===---===/
 // RealFileSystem implementation
 
//===---===/
@@ -807,6 +821,9 @@ public:
 ///
 /// and inherit their attributes from the external contents.
 ///
+/// Virtual file paths and external files are expected to be canonicalized
+/// without "..", "." and "./" in their paths.
+///
 /// In both cases, the 'name' field may contain multiple path components (e.g.
 /// /path/to/file). However, any directory that contains more than one child
 /// must be uniquely represented by a directory entry.
@@ -1004,7 +1021,13 @@ class RedirectingFileSystemParser {
   if (Key == "name") {
 if (!parseScalarString(I->getValue(), Value, Buffer))
   return nullptr;
-Name = Value;
+
+SmallString<256> Path(Value);
+// Guarantee that old YAML files containing paths with ".." and "." are
+// properly canonicalized before read into the VFS.
+Path = sys::path::remove_leading_dotslash(Path);
+sys::path::remove_dots(Path, /*remove_dot_dot=*/true);
+Name = Path.str();
   } else if (Key == "type") {
 if (!parseScalarString(I->getValue(), Value, Buffer))
   return nullptr;
@@ -1048,7 +1071,12 @@ class RedirectingFileSystemParser {
 HasContents = true;
 if (!parseScalarString(I->getValue(), Value, Buffer))
   return nullptr;
-ExternalContentsPath = Value;
+SmallString<256> Path(Value);
+// Guarantee that old YAML files containing paths with ".." and "." are
+// properly canonicalized before read into the VFS.
+Path = sys::path::remove_leading_dotslash(Path);
+sys::path::remove_dots(Path, /*remove_dot_dot=*/true);
+ExternalContentsPath = Path.str();
   } else if (Key == "use-external-name") {
 bool Val;
 if (!parseScalarBool(I->getValue(), Val))
@@ -1238,6 +1266,12 @@ ErrorOr RedirectingFileSystem::
   if (std::error_code EC = makeAbsolute(Path))
 return EC;
 
+  // Canonicalize path by removing ".", "..", "./", etc components. This is
+  // a VFS request, do bot bother about symlinks in the path components
+  // but canonicalize in order to perform the correct entry search.
+  Path = sys::path::remove_leading_dotslash(Path);
+  sys::path::remove_dots(Path, /*remove_dot_dot=*/true);
+
   if (Path.empty())
 return make_error_code(llvm::errc::invalid_argument);
 
@@ -1254,10 +1288,10 @@ ErrorOr RedirectingFileSystem::
 ErrorOr
 RedirectingFileSystem::lookupPath(sys::path::const_iterator Start,
   sys::path::const_iterator End, Entry *From) {
-  if (Start->equals("."))
-++Start;
+  assert(!isTraversalComponent(*Start) &&
+ !isTraversalComponent(From->getName()) &&
+ "Paths should not contain traversal components");
 
-  // FIXME: handle ..
   if (CaseSensitive ? !Start->equals(From->getName())
 

Re: r261448 - Lex: Check buckets on header map construction

2016-02-22 Thread Adrian Prantl via cfe-commits

> On Feb 20, 2016, at 1:00 PM, Duncan P. N. Exon Smith via cfe-commits 
>  wrote:
> 
> Author: dexonsmith
> Date: Sat Feb 20 15:00:58 2016
> New Revision: 261448
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=261448=rev
> Log:
> Lex: Check buckets on header map construction
> 
> If the number of buckets is not a power of two, immediately recognize
> the header map as corrupt, rather than waiting for the first lookup.  I
> converted the later check to an assert.
> 
> Modified:
>cfe/trunk/lib/Lex/HeaderMap.cpp
>cfe/trunk/unittests/Lex/HeaderMapTest.cpp
> 
> Modified: cfe/trunk/lib/Lex/HeaderMap.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/HeaderMap.cpp?rev=261448=261447=261448=diff
> ==
> --- cfe/trunk/lib/Lex/HeaderMap.cpp (original)
> +++ cfe/trunk/lib/Lex/HeaderMap.cpp Sat Feb 20 15:00:58 2016
> @@ -19,6 +19,7 @@
> #include "llvm/Support/DataTypes.h"
> #include "llvm/Support/MathExtras.h"
> #include "llvm/Support/MemoryBuffer.h"
> +#include "llvm/Support/SwapByteOrder.h"
> #include 
> #include 
> using namespace clang;
> @@ -82,6 +83,15 @@ bool HeaderMapImpl::checkHeader(const ll
>   if (Header->Reserved != 0)
> return false;
> 
> +  // Check the number of buckets.
> +  auto NumBuckets = NeedsByteSwap
> +? llvm::sys::getSwappedBytes(Header->NumBuckets)
> +: Header->NumBuckets;
> +
> +  // If the number of buckets is not a power of two, the headermap is 
> corrupt.

Support/MathExtras.h defines isPowerOf2_32 which is IMHO more readable and also 
checks for 0 (which may or may not be what we want here).

-- adrian
> +  if (NumBuckets & (NumBuckets - 1))
> +return false;
> +
>   // Okay, everything looks good.
>   return true;
> }
> @@ -191,10 +201,8 @@ StringRef HeaderMapImpl::lookupFilename(
>   const HMapHeader  = getHeader();
>   unsigned NumBuckets = getEndianAdjustedWord(Hdr.NumBuckets);
> 
> -  // If the number of buckets is not a power of two, the headermap is 
> corrupt.
> -  // Don't probe infinitely.
> -  if (NumBuckets & (NumBuckets-1))
> -return StringRef();
> +  // Don't probe infinitely.  This should be checked before constructing.
> +  assert(!(NumBuckets & (NumBuckets - 1)) && "Expected power of 2");
> 
>   // Linearly probe the hash table.
>   for (unsigned Bucket = HashHMapKey(Filename);; ++Bucket) {
> 
> Modified: cfe/trunk/unittests/Lex/HeaderMapTest.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Lex/HeaderMapTest.cpp?rev=261448=261447=261448=diff
> ==
> --- cfe/trunk/unittests/Lex/HeaderMapTest.cpp (original)
> +++ cfe/trunk/unittests/Lex/HeaderMapTest.cpp Sat Feb 20 15:00:58 2016
> @@ -91,4 +91,13 @@ TEST(HeaderMapTest, checkHeaderValidButE
>   ASSERT_TRUE(NeedsSwap);
> }
> 
> +TEST(HeaderMapTest, checkHeader3Buckets) {
> +  MapFile<3, 1> File;
> +  ASSERT_EQ(3 * sizeof(HMapBucket), sizeof(File.Buckets));
> +
> +  File.init();
> +  bool NeedsSwap;
> +  ASSERT_FALSE(HeaderMapImpl::checkHeader(*File.getBuffer(), NeedsSwap));
> +}
> +
> } // end namespace
> 
> 
> ___
> 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


Re: r261548 - Add has_feature attribute_availability_with_strict.

2016-02-22 Thread Aaron Ballman via cfe-commits
On Mon, Feb 22, 2016 at 1:24 PM, Manman Ren via cfe-commits
 wrote:
> Author: mren
> Date: Mon Feb 22 12:24:30 2016
> New Revision: 261548
>
> URL: http://llvm.org/viewvc/llvm-project?rev=261548=rev
> Log:
> Add has_feature attribute_availability_with_strict.
>
> rdar://23791325

Please add more context to commit logs; radar reports in commit logs
don't help those of us who are not at Apple. Also, I don't recall
seeing this patch go through the review process, can you point me to
the thread?

>
> Modified:
> cfe/trunk/lib/Lex/PPMacroExpansion.cpp
> cfe/trunk/test/Sema/attr-availability-macosx.c
>
> Modified: cfe/trunk/lib/Lex/PPMacroExpansion.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/PPMacroExpansion.cpp?rev=261548=261547=261548=diff
> ==
> --- cfe/trunk/lib/Lex/PPMacroExpansion.cpp (original)
> +++ cfe/trunk/lib/Lex/PPMacroExpansion.cpp Mon Feb 22 12:24:30 2016
> @@ -1066,6 +1066,7 @@ static bool HasFeature(const Preprocesso
>.Case("attribute_availability_with_version_underscores", true)
>.Case("attribute_availability_tvos", true)
>.Case("attribute_availability_watchos", true)
> +  .Case("attribute_availability_with_strict", true)

I wonder if this would actually be better as an attribute feature
testing macro, instead of bolted on to __has_feature. It's strange to
have attribute feature testing capabilities and not use them. That
being said, I'm not opposed to this patch as-is because there are
other attribute_availability_* feature test.

Thanks!

~Aaron

>.Case("attribute_cf_returns_not_retained", true)
>.Case("attribute_cf_returns_retained", true)
>.Case("attribute_cf_returns_on_parameters", true)
>
> Modified: cfe/trunk/test/Sema/attr-availability-macosx.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/attr-availability-macosx.c?rev=261548=261547=261548=diff
> ==
> --- cfe/trunk/test/Sema/attr-availability-macosx.c (original)
> +++ cfe/trunk/test/Sema/attr-availability-macosx.c Mon Feb 22 12:24:30 2016
> @@ -1,5 +1,9 @@
>  // RUN: %clang_cc1 "-triple" "x86_64-apple-darwin9.0.0" -fsyntax-only 
> -verify %s
>
> +#if !__has_feature(attribute_availability_with_strict)
> +#error "Missing __has_feature"
> +#endif
> +
>  void f0(int) 
> __attribute__((availability(macosx,introduced=10.4,deprecated=10.6)));
>  void f1(int) __attribute__((availability(macosx,introduced=10.5)));
>  void f2(int) 
> __attribute__((availability(macosx,introduced=10.4,deprecated=10.5))); // 
> expected-note {{'f2' has been explicitly marked deprecated here}}
>
>
> ___
> 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


r261548 - Add has_feature attribute_availability_with_strict.

2016-02-22 Thread Manman Ren via cfe-commits
Author: mren
Date: Mon Feb 22 12:24:30 2016
New Revision: 261548

URL: http://llvm.org/viewvc/llvm-project?rev=261548=rev
Log:
Add has_feature attribute_availability_with_strict.

rdar://23791325

Modified:
cfe/trunk/lib/Lex/PPMacroExpansion.cpp
cfe/trunk/test/Sema/attr-availability-macosx.c

Modified: cfe/trunk/lib/Lex/PPMacroExpansion.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/PPMacroExpansion.cpp?rev=261548=261547=261548=diff
==
--- cfe/trunk/lib/Lex/PPMacroExpansion.cpp (original)
+++ cfe/trunk/lib/Lex/PPMacroExpansion.cpp Mon Feb 22 12:24:30 2016
@@ -1066,6 +1066,7 @@ static bool HasFeature(const Preprocesso
   .Case("attribute_availability_with_version_underscores", true)
   .Case("attribute_availability_tvos", true)
   .Case("attribute_availability_watchos", true)
+  .Case("attribute_availability_with_strict", true)
   .Case("attribute_cf_returns_not_retained", true)
   .Case("attribute_cf_returns_retained", true)
   .Case("attribute_cf_returns_on_parameters", true)

Modified: cfe/trunk/test/Sema/attr-availability-macosx.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/attr-availability-macosx.c?rev=261548=261547=261548=diff
==
--- cfe/trunk/test/Sema/attr-availability-macosx.c (original)
+++ cfe/trunk/test/Sema/attr-availability-macosx.c Mon Feb 22 12:24:30 2016
@@ -1,5 +1,9 @@
 // RUN: %clang_cc1 "-triple" "x86_64-apple-darwin9.0.0" -fsyntax-only -verify 
%s
 
+#if !__has_feature(attribute_availability_with_strict)
+#error "Missing __has_feature"
+#endif
+
 void f0(int) 
__attribute__((availability(macosx,introduced=10.4,deprecated=10.6)));
 void f1(int) __attribute__((availability(macosx,introduced=10.5)));
 void f2(int) 
__attribute__((availability(macosx,introduced=10.4,deprecated=10.5))); // 
expected-note {{'f2' has been explicitly marked deprecated here}}


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


Re: [PATCH] D17484: [clang-tidy] introduce modernize-deprecated-headers check

2016-02-22 Thread Kirill Bobyrev via cfe-commits
omtcyf0 added a comment.

Thank you for a review, Alex!

I'll clean up the parts you mentioned soon!

In http://reviews.llvm.org/D17484#358617, @alexfh wrote:

> The most important question to this check is that the standard doesn't 
> guarantee that the C++ headers declare all the same functions **in the global 
> namespace** (at least, this is how I understand the section of the standard 
> you quoted). This means that the check in its current form can break the code 
> that uses library symbols from the global namespace. The check could add 
> `std::` wherever it's needed (though it may be not completely trivial) to 
> mitigate the risk. It's not what needs to be addressed in the first 
> iteration, but it's definitely worth a look at in order to make the check 
> actually useful. It also could be a separate check or a separate mode 
> (configurable via parameters) of this check, while someone could have reasons 
> to do the migration in two stages (add `std::` qualifiers and then switch to 
> new headers).


Yes, you are correct: the check might cause some troubles in codebases, because 
it is not guaranteed that the functions from the C library headers will occur 
in the global namespace.

I was initially aware of that, but I thought it'd be better to add the initial 
check first and enhance it later. Appropriate FIXME seems great.

In http://reviews.llvm.org/D17484#358757, @LegalizeAdulthood wrote:

> It would be reasonable for this check to insert a `using namespace std;` at 
> the top of the translation unit after all the `#include` lines as a means of 
> preserving meaning without trying to identify every symbol that needs `std` 
> on it.


I'm not sure that's a good option. I would certainly argue about putting using 
namespaces like std anywhere during the vanilla check run. Simply because of 
the collisions caused by some libraries with the functions having analogies in 
STL.

However, I can see it as an option for the further variations of this check.

Say, let it have three options:

- Don't bother about namespaces: in case user already has `using namespace std` 
or doesn't care about implementation-dependend things. Seems like a reasonable 
scenario to me.
- Add `std::` prefix to all functions from these headers in the process of 
migration: generally it seems a bit better to me.
- Put `using namespace std;` somewhere (maybe even specify where: i.e. if user 
wants to put it right to the top of TU or in each source file where a C library 
is used. That's considerably good, too.

//just note for the future//
I also think there might be a good place in clang-tidy for an independent check 
responsible for namespace migrations. Say, user has been using only one library 
and now when he wants to add another one it would be good to put the 
appropriate namespace prefixes where appropriate.

Seems quite sophisticated ATM though.


http://reviews.llvm.org/D17484



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


Re: [PATCH] D17437: [OpenCL] Add Sema checks for types

2016-02-22 Thread Anastasia Stulova via cfe-commits
Anastasia added inline comments.


Comment at: test/SemaOpenCL/invalid-image.cl:3
@@ +2,3 @@
+
+void test1(image1d_t *i){} // expected-error {{pointer to type 'image1d_t' is 
invalid in OpenCL}}
+

Anastasia wrote:
> Could we add similar tests for other types too. I think we could put them in 
> existing cl files.
At least sampler test could go into test/SemaOpenCL/sampler_t.cl


http://reviews.llvm.org/D17437



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


Re: [PATCH] D17446: ASTMatchers: add new statement/decl matchers

2016-02-22 Thread Richard via cfe-commits
LegalizeAdulthood added a subscriber: LegalizeAdulthood.


Comment at: docs/LibASTMatchersReference.html:512
@@ +511,3 @@
+Matcherhttp://clang.llvm.org/doxygen/classclang_1_1Stmt.html;>StmtaddrLabelExprMatcherhttp://clang.llvm.org/doxygen/classclang_1_1AddrLabelExpr.html;>AddrLabelExpr...
+Matches address of 
label statements (GNU extension).
+

Can we put `gnu` in the name of matchers that only match GNU extensions?


Comment at: docs/LibASTMatchersReference.html:544
@@ +543,3 @@
+Matcherhttp://clang.llvm.org/doxygen/classclang_1_1Stmt.html;>StmtatomicExprMatcherhttp://clang.llvm.org/doxygen/classclang_1_1AtomicExpr.html;>AtomicExpr...
+Matches atomic builtins.
+

Please provide an example here.


Comment at: docs/LibASTMatchersReference.html:549
@@ +548,3 @@
+Matcherhttp://clang.llvm.org/doxygen/classclang_1_1Stmt.html;>StmtbinaryConditionalOperatorMatcherhttp://clang.llvm.org/doxygen/classclang_1_1BinaryConditionalOperator.html;>BinaryConditionalOperator...
+Matches 
binary conditional operator expressions (GNU extension).
+

See above re: gnu specific extensions.  When I read the name of this matcher, I 
expected it to be matching `==`, `!=`, `<=`, etc.


Comment at: docs/LibASTMatchersReference.html:1120
@@ +1119,3 @@
+Matcherhttp://clang.llvm.org/doxygen/classclang_1_1Stmt.html;>StmtopaqueValueExprMatcherhttp://clang.llvm.org/doxygen/classclang_1_1OpaqueValueExpr.html;>OpaqueValueExpr...
+Matches opaque 
value expressions.
+

The docs say that OpaqueValueExpr doesn't correspond to concrete syntax, so why 
would we have a matcher for it?


Comment at: docs/LibASTMatchersReference.html:1140
@@ +1139,3 @@
+Given
+  templatetypename T class X { void f() { X x(*this); } };
+parenListExpr()

Can we have a simpler example?  For instance, I can't see that `ParenListExpr` 
has anything to do with templates.


Comment at: docs/LibASTMatchersReference.html:1149
@@ +1148,3 @@
+
+Example: Matches __func__)
+  printf("%s", __func__);

Does it actually match the closing paren?


Comment at: docs/LibASTMatchersReference.html:1175
@@ +1174,3 @@
+Matcherhttp://clang.llvm.org/doxygen/classclang_1_1Stmt.html;>StmtstmtExprMatcherhttp://clang.llvm.org/doxygen/classclang_1_1StmtExpr.html;>StmtExpr...
+Matches GNU statement 
expression.
+

Ditto re: gnu extension


Comment at: docs/LibASTMatchersReference.html:1752
@@ +1751,3 @@
+Matcherhttp://clang.llvm.org/doxygen/classclang_1_1CXXConstructExpr.html;>CXXConstructExprrequiresZeroInitialization
+Matches 
a constructor call expression which requires
+zero initialization.

Please provide an example.


http://reviews.llvm.org/D17446



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


Re: [PATCH] D17437: [OpenCL] Add Sema checks for types

2016-02-22 Thread Anastasia Stulova via cfe-commits
Anastasia added inline comments.


Comment at: test/SemaOpenCL/invalid-image.cl:3
@@ +2,3 @@
+
+void test1(image1d_t *i){} // expected-error {{pointer to type 'image1d_t' is 
invalid in OpenCL}}
+

Could we add similar tests for other types too. I think we could put them in 
existing cl files.


http://reviews.llvm.org/D17437



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


Re: [PATCH] D5238: [analyzer] Detect duplicate [super dealloc] calls

2016-02-22 Thread Devin Coughlin via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL261545: [analyzer] Detect duplicate [super dealloc] calls 
(authored by dcoughlin).

Changed prior to commit:
  http://reviews.llvm.org/D5238?vs=48447=48707#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D5238

Files:
  cfe/trunk/lib/StaticAnalyzer/Checkers/CMakeLists.txt
  cfe/trunk/lib/StaticAnalyzer/Checkers/Checkers.td
  cfe/trunk/lib/StaticAnalyzer/Checkers/ObjCSuperDeallocChecker.cpp
  cfe/trunk/test/Analysis/DeallocUseAfterFreeErrors.m

Index: cfe/trunk/test/Analysis/DeallocUseAfterFreeErrors.m
===
--- cfe/trunk/test/Analysis/DeallocUseAfterFreeErrors.m
+++ cfe/trunk/test/Analysis/DeallocUseAfterFreeErrors.m
@@ -0,0 +1,298 @@
+// RUN: %clang_cc1 -analyze -analyzer-checker=core,alpha.osx.cocoa.SuperDealloc,debug.ExprInspection -analyzer-output=text -verify %s
+
+void clang_analyzer_warnIfReached();
+
+#define nil ((id)0)
+
+typedef unsigned long NSUInteger;
+@protocol NSObject
+- (instancetype)retain;
+- (oneway void)release;
+@end
+
+@interface NSObject  { }
+- (void)dealloc;
+- (instancetype)init;
+@end
+
+typedef struct objc_selector *SEL;
+
+//======
+//  
+//  Check that 'self' is not referenced after calling '[super dealloc]'.
+
+@interface SuperDeallocThenReleaseIvarClass : NSObject {
+  NSObject *_ivar;
+}
+@end
+
+@implementation SuperDeallocThenReleaseIvarClass
+- (instancetype)initWithIvar:(NSObject *)ivar {
+  self = [super init];
+  if (!self)
+return nil;
+  _ivar = [ivar retain];
+  return self;
+}
+- (void)dealloc {
+  [super dealloc];
+  [_ivar release];
+}
+@end
+
+@interface SuperDeallocThenAssignNilToIvarClass : NSObject {
+  NSObject *_delegate;
+}
+@end
+
+@implementation SuperDeallocThenAssignNilToIvarClass
+- (instancetype)initWithDelegate:(NSObject *)delegate {
+  self = [super init];
+  if (!self)
+return nil;
+  _delegate = delegate;
+  return self;
+}
+- (void)dealloc {
+  [super dealloc];
+  _delegate = nil;
+}
+@end
+
+@interface SuperDeallocThenReleasePropertyClass : NSObject { }
+@property (retain) NSObject *ivar;
+@end
+
+@implementation SuperDeallocThenReleasePropertyClass
+- (instancetype)initWithProperty:(NSObject *)ivar {
+  self = [super init];
+  if (!self)
+return nil;
+  self.ivar = ivar;
+  return self;
+}
+- (void)dealloc {
+  [super dealloc];
+  self.ivar = nil;
+}
+@end
+
+@interface SuperDeallocThenAssignNilToPropertyClass : NSObject { }
+@property (assign) NSObject *delegate;
+@end
+
+@implementation SuperDeallocThenAssignNilToPropertyClass
+- (instancetype)initWithDelegate:(NSObject *)delegate {
+  self = [super init];
+  if (!self)
+return nil;
+  self.delegate = delegate;
+  return self;
+}
+- (void)dealloc {
+  [super dealloc];
+  self.delegate = nil;
+}
+@end
+
+@interface SuperDeallocThenCallInstanceMethodClass : NSObject { }
+- (void)_invalidate;
+@end
+
+@implementation SuperDeallocThenCallInstanceMethodClass
+- (void)_invalidate {
+}
+- (void)dealloc {
+  [super dealloc];
+  [self _invalidate];
+}
+@end
+
+@interface SuperDeallocThenCallNonObjectiveCMethodClass : NSObject { }
+@end
+
+static void _invalidate(NSObject *object) {
+  (void)object;
+}
+
+@implementation SuperDeallocThenCallNonObjectiveCMethodClass
+- (void)dealloc {
+  [super dealloc];
+  _invalidate(self);
+}
+@end
+
+@interface TwoSuperDeallocCallsClass : NSObject {
+  NSObject *_ivar;
+}
+- (void)_invalidate;
+@end
+
+@implementation TwoSuperDeallocCallsClass
+- (void)_invalidate {
+}
+- (void)dealloc {
+  if (_ivar) {
+[_ivar release];
+[super dealloc];
+return;
+  }
+  [super dealloc];
+  [self _invalidate];
+}
+@end
+
+//======
+// Warn about calling [super dealloc] twice due to missing return statement.
+
+@interface MissingReturnCausesDoubleSuperDeallocClass : NSObject {
+  NSObject *_ivar;
+}
+@end
+
+@implementation MissingReturnCausesDoubleSuperDeallocClass
+- (void)dealloc {
+  if (_ivar) { // expected-note {{Taking true branch}}
+[_ivar release];
+[super dealloc]; // expected-note {{[super dealloc] called here}}
+// return;
+  }
+  [super dealloc]; // expected-warning{{[super dealloc] should not be called multiple times}}
+  // expected-note@-1{{[super dealloc] should not be called multiple times}}
+}
+@end
+
+//======
+// Warn about calling [super dealloc] twice in two different methods.
+
+@interface SuperDeallocInOtherMethodClass : NSObject {
+  NSObject *_ivar;
+}
+- (void)_cleanup;
+@end
+
+@implementation SuperDeallocInOtherMethodClass
+- (void)_cleanup {
+  [_ivar release];
+  [super dealloc]; // expected-note {{[super dealloc] called here}}
+}
+- (void)dealloc {
+  [self _cleanup]; // expected-note {{Calling '_cleanup'}}
+  //expected-note@-1 

r261545 - [analyzer] Detect duplicate [super dealloc] calls

2016-02-22 Thread Devin Coughlin via cfe-commits
Author: dcoughlin
Date: Mon Feb 22 11:56:24 2016
New Revision: 261545

URL: http://llvm.org/viewvc/llvm-project?rev=261545=rev
Log:
[analyzer] Detect duplicate [super dealloc] calls

Add an alpha path checker that warns about duplicate calls to [super dealloc].
This will form the foundation of a checker that will detect uses of
'self' after calling [super dealloc].

Part of rdar://problem/6953275.

Based on a patch by David Kilzer!

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

Added:
cfe/trunk/lib/StaticAnalyzer/Checkers/ObjCSuperDeallocChecker.cpp
cfe/trunk/test/Analysis/DeallocUseAfterFreeErrors.m
Modified:
cfe/trunk/lib/StaticAnalyzer/Checkers/CMakeLists.txt
cfe/trunk/lib/StaticAnalyzer/Checkers/Checkers.td

Modified: cfe/trunk/lib/StaticAnalyzer/Checkers/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Checkers/CMakeLists.txt?rev=261545=261544=261545=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Checkers/CMakeLists.txt (original)
+++ cfe/trunk/lib/StaticAnalyzer/Checkers/CMakeLists.txt Mon Feb 22 11:56:24 
2016
@@ -56,6 +56,7 @@ add_clang_library(clangStaticAnalyzerChe
   ObjCContainersChecker.cpp
   ObjCMissingSuperCallChecker.cpp
   ObjCSelfInitChecker.cpp
+  ObjCSuperDeallocChecker.cpp
   ObjCUnusedIVarsChecker.cpp
   PaddingChecker.cpp
   PointerArithChecker.cpp

Modified: cfe/trunk/lib/StaticAnalyzer/Checkers/Checkers.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Checkers/Checkers.td?rev=261545=261544=261545=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Checkers/Checkers.td (original)
+++ cfe/trunk/lib/StaticAnalyzer/Checkers/Checkers.td Mon Feb 22 11:56:24 2016
@@ -513,6 +513,10 @@ def ObjCDeallocChecker : Checker<"Deallo
   HelpText<"Warn about Objective-C classes that lack a correct implementation 
of -dealloc">,
   DescFile<"CheckObjCDealloc.cpp">;
 
+def ObjCSuperDeallocChecker : Checker<"SuperDealloc">,
+  HelpText<"Warn about improper use of '[super dealloc]' in Objective-C">,
+  DescFile<"ObjCSuperDeallocChecker.cpp">;
+
 def InstanceVariableInvalidation : Checker<"InstanceVariableInvalidation">,
   HelpText<"Check that the invalidatable instance variables are invalidated in 
the methods annotated with objc_instance_variable_invalidator">,
   DescFile<"IvarInvalidationChecker.cpp">;

Added: cfe/trunk/lib/StaticAnalyzer/Checkers/ObjCSuperDeallocChecker.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Checkers/ObjCSuperDeallocChecker.cpp?rev=261545=auto
==
--- cfe/trunk/lib/StaticAnalyzer/Checkers/ObjCSuperDeallocChecker.cpp (added)
+++ cfe/trunk/lib/StaticAnalyzer/Checkers/ObjCSuperDeallocChecker.cpp Mon Feb 
22 11:56:24 2016
@@ -0,0 +1,197 @@
+//===- ObjCSuperDeallocChecker.cpp - Check correct use of [super dealloc] 
-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+// This defines ObjCSuperDeallocChecker, a builtin check that warns when
+// [super dealloc] is called twice on the same instance in MRR mode.
+//
+//===--===//
+
+#include "ClangSACheckers.h"
+#include "clang/StaticAnalyzer/Core/BugReporter/BugType.h"
+#include "clang/StaticAnalyzer/Core/Checker.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h"
+#include "clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h"
+
+using namespace clang;
+using namespace ento;
+
+namespace {
+class ObjCSuperDeallocChecker
+: public Checker {
+
+  mutable IdentifierInfo *IIdealloc, *IINSObject;
+  mutable Selector SELdealloc;
+
+  std::unique_ptr DoubleSuperDeallocBugType;
+
+  void initIdentifierInfoAndSelectors(ASTContext ) const;
+
+  bool isSuperDeallocMessage(const ObjCMethodCall ) const;
+
+public:
+  ObjCSuperDeallocChecker();
+  void checkPostObjCMessage(const ObjCMethodCall , CheckerContext ) const;
+  void checkPreObjCMessage(const ObjCMethodCall , CheckerContext ) const;
+};
+
+} // End anonymous namespace.
+
+// Remember whether [super dealloc] has previously been called on the
+// a SymbolRef for the receiver.
+REGISTER_SET_WITH_PROGRAMSTATE(CalledSuperDealloc, SymbolRef)
+
+class SuperDeallocBRVisitor final
+: public BugReporterVisitorImpl {
+
+  SymbolRef ReceiverSymbol;
+  bool Satisfied;
+
+public:
+  SuperDeallocBRVisitor(SymbolRef ReceiverSymbol)
+  : ReceiverSymbol(ReceiverSymbol),
+

Re: [PATCH] D17436: [OpenCL] Add Sema checks for OpenCL 2.0 block

2016-02-22 Thread Anastasia Stulova via cfe-commits
Anastasia added inline comments.


Comment at: lib/Sema/SemaDecl.cpp:6714
@@ +6713,3 @@
+  if (LangOpts.OpenCLVersion >= 200 && T->isBlockPointerType()) {
+const BlockPointerType *BlkTy = T->getAs();
+const FunctionProtoType *FTy =

Yes, but you have to diagnose blocks correctly in all CL versions in which we 
accept blocks. When you come to this point here you should only care about 
checking whether blocks have variadic prototype or not. You should assume the 
parser did the right job to either accept or reject the block declaration 
earlier and also gave the right diagnostic.

It will be responsibility of a parser to correctly accept or reject blocks 
depending on a version. I will prepare a patch for it later on. Please see my 
related comment on the review: http://reviews.llvm.org/D16928 


Comment at: lib/Sema/SemaExpr.cpp:6509
@@ +6508,3 @@
+  return QualType();
+  }
+

What is the implication of that? Will we get errors in different order then?


http://reviews.llvm.org/D17436



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


r261537 - Don't enable /GX by default

2016-02-22 Thread David Majnemer via cfe-commits
Author: majnemer
Date: Mon Feb 22 11:44:51 2016
New Revision: 261537

URL: http://llvm.org/viewvc/llvm-project?rev=261537=rev
Log:
Don't enable /GX by default

The /GX flag is disabled unless explicitly specified on the command
line.  This partially addresses PR26698.

Modified:
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/test/Driver/cl-options.c

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=261537=261536=261537=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Mon Feb 22 11:44:51 2016
@@ -5813,8 +5813,10 @@ static EHFlags parseClangCLEHFlags(const
 }
   }
   // The /GX, /GX- flags are only processed if there are not /EH flags.
+  // The default is that /GX is not specified.
   if (EHArgs.empty() &&
-  Args.hasFlag(options::OPT__SLASH_GX, options::OPT__SLASH_GX_)) {
+  Args.hasFlag(options::OPT__SLASH_GX, options::OPT__SLASH_GX_,
+   /*default=*/false)) {
 EH.Synch = true;
 EH.NoUnwindC = true;
   }

Modified: cfe/trunk/test/Driver/cl-options.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/cl-options.c?rev=261537=261536=261537=diff
==
--- cfe/trunk/test/Driver/cl-options.c (original)
+++ cfe/trunk/test/Driver/cl-options.c Mon Feb 22 11:44:51 2016
@@ -211,6 +211,9 @@
 // RUN: %clang_cl /FI asdf.h -### -- %s 2>&1 | FileCheck -check-prefix=FI_ %s
 // FI_: "-include" "asdf.h"
 
+// RUN: %clang_cl /c -### -- %s 2>&1 | FileCheck -check-prefix=NO-GX %s
+// NO-GX-NOT: "-fcxx-exceptions" "-fexceptions"
+
 // RUN: %clang_cl /c /GX -### -- %s 2>&1 | FileCheck -check-prefix=GX %s
 // GX: "-fcxx-exceptions" "-fexceptions"
 


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


Re: [PATCH] D17484: [clang-tidy] introduce modernize-deprecated-headers check

2016-02-22 Thread Richard via cfe-commits
LegalizeAdulthood added a comment.

In http://reviews.llvm.org/D17484#358617, @alexfh wrote:

> Thank you for this check! Mostly looks good, but there are a number of style 
> nits.
>
> The most important question to this check is that the standard doesn't 
> guarantee that the C++ headers declare all the same functions **in the global 
> namespace** (at least, this is how I understand the section of the standard 
> you quoted).


Oh crap, I totally forgot about this.  Yes, I believe the weasel wording in the 
standard is that an implementation may put the symbols in the global namespace 
as well as inside `std` when the C++ header is used, but is not required to put 
them in the global namespace.  They are required to put them in namespace `std` 
when the C++ header form is used.

So if you switch to C++ headers, you code may still compile, but it is 
implementation dependent.

If you use the C headers, you can't prefix symbols with `std` because they 
won't be there.

In other discussions of this topic, it was considered best to make both changes 
at the same time: switch to the C++ header and decorate the symbols with `std` 
prefix.

It would be reasonable for this check to insert a `using namespace std;` at the 
top of the translation unit after all the `#include` lines as a means of 
preserving meaning without trying to identify every symbol that needs `std` on 
it.


http://reviews.llvm.org/D17484



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


[PATCH] D17516: AMDGPU: Verify subtarget specific builtins

2016-02-22 Thread Matt Arsenault via cfe-commits
arsenm created this revision.
arsenm added reviewers: tstellarAMD, echristo.
arsenm added a subscriber: cfe-commits.

Cleanup setup of subtarget features.

http://reviews.llvm.org/D17516

Files:
  include/clang/Basic/BuiltinsAMDGPU.def
  lib/Basic/Targets.cpp
  test/CodeGenOpenCL/builtins-amdgcn-error.cl
  test/CodeGenOpenCL/builtins-amdgcn-vi.cl
  test/CodeGenOpenCL/builtins-amdgcn.cl
  test/SemaOpenCL/builtins-amdgcn.cl

Index: test/SemaOpenCL/builtins-amdgcn.cl
===
--- test/SemaOpenCL/builtins-amdgcn.cl
+++ /dev/null
@@ -1,6 +0,0 @@
-// RUN: %clang_cc1 -triple amdgcn-unknown-amdhsa -fsyntax-only -verify %s
-
-void test_s_sleep(int x)
-{
-  __builtin_amdgcn_s_sleep(x); // expected-error {{argument to '__builtin_amdgcn_s_sleep' must be a constant integer}}
-}
Index: test/CodeGenOpenCL/builtins-amdgcn.cl
===
--- test/CodeGenOpenCL/builtins-amdgcn.cl
+++ test/CodeGenOpenCL/builtins-amdgcn.cl
@@ -178,13 +178,6 @@
   *out = __builtin_amdgcn_s_memtime();
 }
 
-// CHECK-LABEL: @test_s_memrealtime
-// CHECK: call i64 @llvm.amdgcn.s.memrealtime()
-void test_s_memrealtime(global ulong* out)
-{
-  *out = __builtin_amdgcn_s_memrealtime();
-}
-
 // CHECK-LABEL: @test_s_sleep
 // CHECK: call void @llvm.amdgcn.s.sleep(i32 1)
 // CHECK: call void @llvm.amdgcn.s.sleep(i32 15)
Index: test/CodeGenOpenCL/builtins-amdgcn-vi.cl
===
--- /dev/null
+++ test/CodeGenOpenCL/builtins-amdgcn-vi.cl
@@ -0,0 +1,12 @@
+// REQUIRES: amdgpu-registered-target
+// RUN: %clang_cc1 -triple amdgcn-unknown-unknown -target-cpu tonga -S -emit-llvm -o - %s | FileCheck %s
+
+typedef unsigned long ulong;
+
+
+// CHECK-LABEL: @test_s_memrealtime
+// CHECK: call i64 @llvm.amdgcn.s.memrealtime()
+void test_s_memrealtime(global ulong* out)
+{
+  *out = __builtin_amdgcn_s_memrealtime();
+}
Index: test/CodeGenOpenCL/builtins-amdgcn-error.cl
===
--- /dev/null
+++ test/CodeGenOpenCL/builtins-amdgcn-error.cl
@@ -0,0 +1,18 @@
+// REQUIRES: amdgpu-registered-target
+// RUN: %clang_cc1 -triple amdgcn-unknown-amdhsa -target-cpu tahiti -verify -S -o - %s
+
+// FIXME: We only get one error if the functions are the other order in the
+// file.
+
+typedef unsigned long ulong;
+
+ulong test_s_memrealtime()
+{
+  return __builtin_amdgcn_s_memrealtime(); // expected-error {{'__builtin_amdgcn_s_memrealtime' needs target feature s-memrealtime}}
+}
+
+void test_s_sleep(int x)
+{
+  __builtin_amdgcn_s_sleep(x); // expected-error {{argument to '__builtin_amdgcn_s_sleep' must be a constant integer}}
+}
+
Index: lib/Basic/Targets.cpp
===
--- lib/Basic/Targets.cpp
+++ lib/Basic/Targets.cpp
@@ -1801,23 +1801,32 @@
   bool hasFMAF:1;
   bool hasLDEXPF:1;
 
+  bool hasSMemRealTime : 1;
+  bool Has16BitInsts : 1;
+
+  static bool isAMDGCN(const llvm::Triple ) {
+return TT.getArch() == llvm::Triple::amdgcn;
+  }
+
 public:
   AMDGPUTargetInfo(const llvm::Triple )
-: TargetInfo(Triple) {
+: TargetInfo(Triple) ,
+  GPU(isAMDGCN(Triple) ? GK_SOUTHERN_ISLANDS : GK_R600),
+  hasFP64(false),
+  hasFMAF(false),
+  hasLDEXPF(false),
+  hasSMemRealTime(false),
+  Has16BitInsts(false) {
 
 if (Triple.getArch() == llvm::Triple::amdgcn) {
   DataLayoutString = DataLayoutStringSI;
-  GPU = GK_SOUTHERN_ISLANDS;
   hasFP64 = true;
   hasFMAF = true;
   hasLDEXPF = true;
 } else {
   DataLayoutString = DataLayoutStringR600;
-  GPU = GK_R600;
-  hasFP64 = false;
-  hasFMAF = false;
-  hasLDEXPF = false;
 }
+
 AddrSpaceMap = 
 UseAddrSpaceMapMangling = true;
   }
@@ -1858,6 +1867,10 @@
 return false;
   }
 
+  bool initFeatureMap(llvm::StringMap ,
+  DiagnosticsEngine , StringRef CPU,
+  const std::vector ) const override;
+
   ArrayRef getTargetBuiltins() const override {
 return llvm::makeArrayRef(BuiltinInfo,
 clang::AMDGPU::LastTSBuiltin - Builtin::FirstTSBuiltin);
@@ -1929,39 +1942,45 @@
   .Case("carrizo",  GK_VOLCANIC_ISLANDS)
   .Default(GK_NONE);
 
-if (GPU == GK_NONE) {
+if (GPU == GK_NONE)
   return false;
-}
 
 // Set the correct data layout
-switch (GPU) {
-case GK_NONE:
-case GK_R600:
-case GK_R700:
-case GK_EVERGREEN:
-case GK_NORTHERN_ISLANDS:
-  DataLayoutString = DataLayoutStringR600;
-  hasFP64 = false;
-  hasFMAF = false;
-  hasLDEXPF = false;
-  break;
-case GK_R600_DOUBLE_OPS:
-case GK_R700_DOUBLE_OPS:
-case GK_EVERGREEN_DOUBLE_OPS:
-case GK_CAYMAN:
-  DataLayoutString = DataLayoutStringR600DoubleOps;
-  hasFP64 = true;
-  hasFMAF = true;
-  hasLDEXPF = false;
-  break;
-case 

[PATCH] D17515: AMDGPU: Add builtins for recently added intrinsics

2016-02-22 Thread Matt Arsenault via cfe-commits
arsenm created this revision.
arsenm added a reviewer: tstellarAMD.
arsenm added a subscriber: cfe-commits.

http://reviews.llvm.org/D17515

Files:
  include/clang/Basic/BuiltinsAMDGPU.def
  test/CodeGenOpenCL/builtins-amdgcn.cl
  test/SemaOpenCL/builtins-amdgcn.cl

Index: test/SemaOpenCL/builtins-amdgcn.cl
===
--- /dev/null
+++ test/SemaOpenCL/builtins-amdgcn.cl
@@ -0,0 +1,6 @@
+// RUN: %clang_cc1 -triple amdgcn-unknown-amdhsa -fsyntax-only -verify %s
+
+void test_s_sleep(int x)
+{
+  __builtin_amdgcn_s_sleep(x); // expected-error {{argument to 
'__builtin_amdgcn_s_sleep' must be a constant integer}}
+}
Index: test/CodeGenOpenCL/builtins-amdgcn.cl
===
--- test/CodeGenOpenCL/builtins-amdgcn.cl
+++ test/CodeGenOpenCL/builtins-amdgcn.cl
@@ -3,6 +3,8 @@
 
 #pragma OPENCL EXTENSION cl_khr_fp64 : enable
 
+typedef unsigned long ulong;
+
 // CHECK-LABEL: @test_div_scale_f64
 // CHECK: call { double, i1 } @llvm.amdgcn.div.scale.f64(double %a, double %b, 
i1 true)
 // CHECK-DAG: [[FLAG:%.+]] = extractvalue { double, i1 } %{{.+}}, 1
@@ -169,6 +171,29 @@
   __builtin_amdgcn_s_barrier();
 }
 
+// CHECK-LABEL: @test_s_memtime
+// CHECK: call i64 @llvm.amdgcn.s.memtime()
+void test_s_memtime(global ulong* out)
+{
+  *out = __builtin_amdgcn_s_memtime();
+}
+
+// CHECK-LABEL: @test_s_memrealtime
+// CHECK: call i64 @llvm.amdgcn.s.memrealtime()
+void test_s_memrealtime(global ulong* out)
+{
+  *out = __builtin_amdgcn_s_memrealtime();
+}
+
+// CHECK-LABEL: @test_s_sleep
+// CHECK: call void @llvm.amdgcn.s.sleep(i32 1)
+// CHECK: call void @llvm.amdgcn.s.sleep(i32 15)
+void test_s_sleep()
+{
+  __builtin_amdgcn_s_sleep(1);
+  __builtin_amdgcn_s_sleep(15);
+}
+
 // CHECK-LABEL: @test_cubeid(
 // CHECK: call float @llvm.amdgcn.cubeid(float %a, float %b, float %c)
 void test_cubeid(global float* out, float a, float b, float c) {
Index: include/clang/Basic/BuiltinsAMDGPU.def
===
--- include/clang/Basic/BuiltinsAMDGPU.def
+++ include/clang/Basic/BuiltinsAMDGPU.def
@@ -40,8 +40,18 @@
 BUILTIN(__builtin_amdgcn_cubesc, "", "nc")
 BUILTIN(__builtin_amdgcn_cubetc, "", "nc")
 BUILTIN(__builtin_amdgcn_cubema, "", "nc")
+BUILTIN(__builtin_amdgcn_s_memtime, "LUi", "n")
+BUILTIN(__builtin_amdgcn_s_sleep, "vIi", "n")
 
+//===--===//
+// VI+ only builtins.
+//===--===//
+BUILTIN(__builtin_amdgcn_s_memrealtime, "LUi", "n")
+
+//===--===//
 // Legacy names with amdgpu prefix
+//===--===//
+
 BUILTIN(__builtin_amdgpu_rsq, "dd", "nc")
 BUILTIN(__builtin_amdgpu_rsqf, "ff", "nc")
 BUILTIN(__builtin_amdgpu_ldexp, "ddi", "nc")


Index: test/SemaOpenCL/builtins-amdgcn.cl
===
--- /dev/null
+++ test/SemaOpenCL/builtins-amdgcn.cl
@@ -0,0 +1,6 @@
+// RUN: %clang_cc1 -triple amdgcn-unknown-amdhsa -fsyntax-only -verify %s
+
+void test_s_sleep(int x)
+{
+  __builtin_amdgcn_s_sleep(x); // expected-error {{argument to '__builtin_amdgcn_s_sleep' must be a constant integer}}
+}
Index: test/CodeGenOpenCL/builtins-amdgcn.cl
===
--- test/CodeGenOpenCL/builtins-amdgcn.cl
+++ test/CodeGenOpenCL/builtins-amdgcn.cl
@@ -3,6 +3,8 @@
 
 #pragma OPENCL EXTENSION cl_khr_fp64 : enable
 
+typedef unsigned long ulong;
+
 // CHECK-LABEL: @test_div_scale_f64
 // CHECK: call { double, i1 } @llvm.amdgcn.div.scale.f64(double %a, double %b, i1 true)
 // CHECK-DAG: [[FLAG:%.+]] = extractvalue { double, i1 } %{{.+}}, 1
@@ -169,6 +171,29 @@
   __builtin_amdgcn_s_barrier();
 }
 
+// CHECK-LABEL: @test_s_memtime
+// CHECK: call i64 @llvm.amdgcn.s.memtime()
+void test_s_memtime(global ulong* out)
+{
+  *out = __builtin_amdgcn_s_memtime();
+}
+
+// CHECK-LABEL: @test_s_memrealtime
+// CHECK: call i64 @llvm.amdgcn.s.memrealtime()
+void test_s_memrealtime(global ulong* out)
+{
+  *out = __builtin_amdgcn_s_memrealtime();
+}
+
+// CHECK-LABEL: @test_s_sleep
+// CHECK: call void @llvm.amdgcn.s.sleep(i32 1)
+// CHECK: call void @llvm.amdgcn.s.sleep(i32 15)
+void test_s_sleep()
+{
+  __builtin_amdgcn_s_sleep(1);
+  __builtin_amdgcn_s_sleep(15);
+}
+
 // CHECK-LABEL: @test_cubeid(
 // CHECK: call float @llvm.amdgcn.cubeid(float %a, float %b, float %c)
 void test_cubeid(global float* out, float a, float b, float c) {
Index: include/clang/Basic/BuiltinsAMDGPU.def
===
--- include/clang/Basic/BuiltinsAMDGPU.def
+++ include/clang/Basic/BuiltinsAMDGPU.def
@@ -40,8 +40,18 @@
 BUILTIN(__builtin_amdgcn_cubesc, "", "nc")
 

r261535 - [MS ABI] Correctly handle dllimport'd explicit instantiation declaration w/ vbases

2016-02-22 Thread David Majnemer via cfe-commits
Author: majnemer
Date: Mon Feb 22 11:22:08 2016
New Revision: 261535

URL: http://llvm.org/viewvc/llvm-project?rev=261535=rev
Log:
[MS ABI] Correctly handle dllimport'd explicit instantiation declaration w/ 
vbases

We gave a VBTable dllimport storage class and external linkage while
also providing an initializer.  An initializer is only valid if the
VBTable has available_externally linkage.  Fix this by setting the
linkage to available_externally in situ while generating the
initializer.

This fixes PR26686.

Modified:
cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
cfe/trunk/test/CodeGenCXX/PR26569.cpp

Modified: cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp?rev=261535=261534=261535=diff
==
--- cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp (original)
+++ cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp Mon Feb 22 11:22:08 2016
@@ -2039,6 +2039,9 @@ void MicrosoftCXXABI::emitVBTableDefinit
 llvm::ArrayType::get(CGM.IntTy, Offsets.size());
   llvm::Constant *Init = llvm::ConstantArray::get(VBTableType, Offsets);
   GV->setInitializer(Init);
+
+  if (RD->hasAttr())
+GV->setLinkage(llvm::GlobalVariable::AvailableExternallyLinkage);
 }
 
 llvm::Value *MicrosoftCXXABI::performThisAdjustment(CodeGenFunction ,

Modified: cfe/trunk/test/CodeGenCXX/PR26569.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/PR26569.cpp?rev=261535=261534=261535=diff
==
--- cfe/trunk/test/CodeGenCXX/PR26569.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/PR26569.cpp Mon Feb 22 11:22:08 2016
@@ -4,14 +4,17 @@ class A {
   virtual void m_fn1();
 };
 template 
-class B : A {};
+class B : virtual A {};
 
 extern template class __declspec(dllimport) B;
 class __declspec(dllexport) C : B {};
 
-// CHECK: @[[VTABLE_C:.*]] = private unnamed_addr constant [2 x i8*] [i8* 
bitcast (%rtti.CompleteObjectLocator* @"\01??_R4C@@6B@" to i8*), i8* bitcast 
(void (%class.A*)* @"\01?m_fn1@A@@EAEXXZ" to i8*)]
-// CHECK: @[[VTABLE_B:.*]] = private unnamed_addr constant [2 x i8*] [i8* 
bitcast (%rtti.CompleteObjectLocator* @"\01??_R4?$B@H@@6B@" to i8*), i8* 
bitcast (void (%class.A*)* @"\01?m_fn1@A@@EAEXXZ" to i8*)], 
comdat($"\01??_S?$B@H@@6B@")
-// CHECK: @[[VTABLE_A:.*]] = private unnamed_addr constant [2 x i8*] [i8* 
bitcast (%rtti.CompleteObjectLocator* @"\01??_R4A@@6B@" to i8*), i8* bitcast 
(void (%class.A*)* @"\01?m_fn1@A@@EAEXXZ" to i8*)], comdat($"\01??_7A@@6B@")
-// CHECK: @"\01??_7C@@6B@" = dllexport unnamed_addr alias i8*, getelementptr 
inbounds ([2 x i8*], [2 x i8*]* @[[VTABLE_C]], i32 0, i32 1)
-// CHECK: @"\01??_S?$B@H@@6B@" = unnamed_addr alias i8*, getelementptr 
inbounds ([2 x i8*], [2 x i8*]* @[[VTABLE_B]], i32 0, i32 1)
-// CHECK: @"\01??_7A@@6B@" = unnamed_addr alias i8*, getelementptr inbounds 
([2 x i8*], [2 x i8*]* @[[VTABLE_A]], i32 0, i32 1)
+// CHECK-DAG: @[[VTABLE_C:.*]] = private unnamed_addr constant [2 x i8*] [i8* 
bitcast (%rtti.CompleteObjectLocator* @"\01??_R4C@@6B@" to i8*), i8* bitcast 
(void (%class.A*)* @"\01?m_fn1@A@@EAEXXZ" to i8*)]
+// CHECK-DAG: @[[VTABLE_B:.*]] = private unnamed_addr constant [2 x i8*] [i8* 
bitcast (%rtti.CompleteObjectLocator* @"\01??_R4?$B@H@@6B@" to i8*), i8* 
bitcast (void (%class.A*)* @"\01?m_fn1@A@@EAEXXZ" to i8*)], 
comdat($"\01??_S?$B@H@@6B@")
+// CHECK-DAG: @[[VTABLE_A:.*]] = private unnamed_addr constant [2 x i8*] [i8* 
bitcast (%rtti.CompleteObjectLocator* @"\01??_R4A@@6B@" to i8*), i8* bitcast 
(void (%class.A*)* @"\01?m_fn1@A@@EAEXXZ" to i8*)], comdat($"\01??_7A@@6B@")
+
+// CHECK-DAG: @"\01??_7C@@6B@" = dllexport unnamed_addr alias i8*, 
getelementptr inbounds ([2 x i8*], [2 x i8*]* @[[VTABLE_C]], i32 0, i32 1)
+// CHECK-DAG: @"\01??_S?$B@H@@6B@" = unnamed_addr alias i8*, getelementptr 
inbounds ([2 x i8*], [2 x i8*]* @[[VTABLE_B]], i32 0, i32 1)
+// CHECK-DAG: @"\01??_7A@@6B@" = unnamed_addr alias i8*, getelementptr 
inbounds ([2 x i8*], [2 x i8*]* @[[VTABLE_A]], i32 0, i32 1)
+
+// CHECK-DAG: @"\01??_8?$B@H@@7B@" = available_externally dllimport 
unnamed_addr constant [2 x i32] [i32 0, i32 4]


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


Re: [PATCH] D16317: [Analyzer] Fix for PR23790: bind real value returned from strcmp when modelling strcmp.

2016-02-22 Thread Devin Coughlin via cfe-commits
dcoughlin accepted this revision.
dcoughlin added a comment.
This revision is now accepted and ready to land.

Looks great, other than some non-standard indentation.



Comment at: lib/StaticAnalyzer/Checkers/CStringChecker.cpp:1886
@@ +1885,3 @@
+  svalBuilder.evalBinOp(state, op, resultVal, zeroVal,
+  svalBuilder.getConditionType());
+DefinedSVal compareWithZeroVal = compareWithZero.castAs();

Non-standard indentation here.


http://reviews.llvm.org/D16317



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


Re: [PATCH] D15636: Reduce false positives in printf/scanf format checker

2016-02-22 Thread Andy Gibbs via cfe-commits
AndyG added inline comments.


Comment at: lib/Sema/SemaChecking.cpp:3905
@@ -3822,14 +3904,3 @@
 CoveredArgs.flip();
-signed notCoveredArg = CoveredArgs.find_first();
-if (notCoveredArg >= 0) {
-  assert((unsigned)notCoveredArg < NumDataArgs);
-  if (const Expr *E = getDataArg((unsigned) notCoveredArg)) {
-SourceLocation Loc = E->getLocStart();
-if (!S.getSourceManager().isInSystemMacro(Loc)) {
-  EmitFormatDiagnostic(S.PDiag(diag::warn_printf_data_arg_not_used),
-   Loc, /*IsStringLocation*/false,
-   getFormatStringRange());
-}
-  }
-}
+UncoveredArg.Update(CoveredArgs.find_first(), FExpr);
   }

Rather than `FExpr`, I think this should be `OrigFormatExpr`?


http://reviews.llvm.org/D15636



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


r261533 - Add support for Android Vector calling convention for AArch64

2016-02-22 Thread Nirav Dave via cfe-commits
Author: niravd
Date: Mon Feb 22 10:48:42 2016
New Revision: 261533

URL: http://llvm.org/viewvc/llvm-project?rev=261533=rev
Log:
Add support for Android Vector calling convention for AArch64

This modification applies the following Android commit when we have an
Android environment. This is the sole non-renderscript in the Android repo

commit 9212d4fb30a3ca2f4ee966dd2748c35573d9682c
Author: Tim Murray 
Date:   Fri Aug 15 16:00:15 2014 -0700

Update vector calling convention for AArch64.

bug 16846318

Change-Id: I3cfd167758b4bd634d8480ee6ba6bb55d61f82a7

Reviewers: srhines, jyknight

Subscribers: mcrosier, aemerson, rengolin, tberghammer, danalbert, srhines

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

Modified:
cfe/trunk/lib/CodeGen/ABIInfo.h
cfe/trunk/lib/CodeGen/TargetInfo.cpp
cfe/trunk/test/CodeGen/arm64-abi-vector.c

Modified: cfe/trunk/lib/CodeGen/ABIInfo.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/ABIInfo.h?rev=261533=261532=261533=diff
==
--- cfe/trunk/lib/CodeGen/ABIInfo.h (original)
+++ cfe/trunk/lib/CodeGen/ABIInfo.h Mon Feb 22 10:48:42 2016
@@ -85,6 +85,8 @@ namespace clang {
CodeGen::Address VAListAddr,
QualType Ty) const = 0;
 
+bool isAndroid() const;
+
 /// Emit the target dependent code to load a value of
 /// \arg Ty from the \c __builtin_ms_va_list pointed to by \arg VAListAddr.
 virtual CodeGen::Address EmitMSVAArg(CodeGen::CodeGenFunction ,

Modified: cfe/trunk/lib/CodeGen/TargetInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp?rev=261533=261532=261533=diff
==
--- cfe/trunk/lib/CodeGen/TargetInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/TargetInfo.cpp Mon Feb 22 10:48:42 2016
@@ -117,6 +117,8 @@ const TargetInfo ::getTarget() c
   return CGT.getTarget();
 }
 
+bool ABIInfo:: isAndroid() const { return getTarget().getTriple().isAndroid(); 
}
+
 bool ABIInfo::isHomogeneousAggregateBaseType(QualType Ty) const {
   return false;
 }
@@ -4319,6 +4321,11 @@ ABIArgInfo AArch64ABIInfo::classifyArgum
   // Handle illegal vector types here.
   if (isIllegalVectorType(Ty)) {
 uint64_t Size = getContext().getTypeSize(Ty);
+// Android promotes <2 x i8> to i16, not i32
+if(isAndroid() && (Size <= 16)) {
+  llvm::Type *ResType = llvm::Type::getInt16Ty(getVMContext());
+  return ABIArgInfo::getDirect(ResType);
+}
 if (Size <= 32) {
   llvm::Type *ResType = llvm::Type::getInt32Ty(getVMContext());
   return ABIArgInfo::getDirect(ResType);
@@ -4803,11 +4810,6 @@ public:
 }
   }
 
-  bool isAndroid() const {
-return (getTarget().getTriple().getEnvironment() ==
-llvm::Triple::Android);
-  }
-
   ABIKind getABIKind() const { return Kind; }
 
 private:

Modified: cfe/trunk/test/CodeGen/arm64-abi-vector.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/arm64-abi-vector.c?rev=261533=261532=261533=diff
==
--- cfe/trunk/test/CodeGen/arm64-abi-vector.c (original)
+++ cfe/trunk/test/CodeGen/arm64-abi-vector.c Mon Feb 22 10:48:42 2016
@@ -1,7 +1,9 @@
 // RUN: %clang_cc1 -triple arm64-apple-ios7 -target-abi darwinpcs -emit-llvm 
-o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple aarch64-linux-android -emit-llvm -o - %s | 
FileCheck -check-prefix=ANDROID %s
 
 #include 
 
+typedef __attribute__(( ext_vector_type(2) ))  char __char2;
 typedef __attribute__(( ext_vector_type(3) ))  char __char3;
 typedef __attribute__(( ext_vector_type(4) ))  char __char4;
 typedef __attribute__(( ext_vector_type(5) ))  char __char5;
@@ -13,6 +15,26 @@ typedef __attribute__(( ext_vector_type(
 typedef __attribute__(( ext_vector_type(5) ))  int __int5;
 typedef __attribute__(( ext_vector_type(3) ))  double __double3;
 
+// Passing legal vector types as varargs. Check that we've allocated the 
appropriate size
+double varargs_vec_2c(int fixed, ...) {
+// ANDROID: varargs_vec_2c
+// ANDROID: [[VAR:%.*]] = alloca <2 x i8>, align 2
+// ANDROID: [[AP_NEXT:%.*]] = getelementptr inbounds i8, i8* [[AP_CUR:%.*]], 
i64 8
+// ANDROID: bitcast i8* [[AP_CUR]] to <2 x i8>*
+  va_list ap;
+  double sum = fixed;
+  va_start(ap, fixed);
+  __char2 c3 = va_arg(ap, __char2);
+  sum = sum + c3.x + c3.y;
+  va_end(ap);
+  return sum;
+}
+
+double test_2c(__char2 *in) {
+// ANDROID: call double (i32, ...) @varargs_vec_2c(i32 3, i16 {{%.*}})
+  return varargs_vec_2c(3, *in);
+}
+
 double varargs_vec_3c(int fixed, ...) {
 // CHECK: varargs_vec_3c
 // CHECK: alloca <3 x i8>, align 4


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

Re: [PATCH] D17170: [OPENMP] Codegen for distribute directive

2016-02-22 Thread Carlo Bertolli via cfe-commits
carlo.bertolli updated this revision to Diff 48691.
carlo.bertolli added a comment.

Address latest comments.


Repository:
  rL LLVM

http://reviews.llvm.org/D17170

Files:
  include/clang/AST/StmtOpenMP.h
  lib/CodeGen/CGOpenMPRuntime.cpp
  lib/CodeGen/CGOpenMPRuntime.h
  lib/CodeGen/CGStmtOpenMP.cpp
  lib/CodeGen/CodeGenFunction.h
  lib/Serialization/ASTReaderStmt.cpp
  lib/Serialization/ASTWriterStmt.cpp
  test/OpenMP/distribute_codegen.cpp

Index: test/OpenMP/distribute_codegen.cpp
===
--- /dev/null
+++ test/OpenMP/distribute_codegen.cpp
@@ -0,0 +1,239 @@
+// Test host codegen.
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown -omptargets=powerpc64le-ibm-linux-gnu -emit-llvm %s -o - | FileCheck %s --check-prefix CHECK --check-prefix CHECK-64
+// RUN: %clang_cc1 -fopenmp -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -omptargets=powerpc64le-ibm-linux-gnu -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -x c++ -triple powerpc64le-unknown-unknown -omptargets=powerpc64le-ibm-linux-gnu -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s --check-prefix CHECK --check-prefix CHECK-64  --check-prefix HCHECK
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple i386-unknown-unknown -omptargets=i386-pc-linux-gnu -emit-llvm %s -o - | FileCheck %s --check-prefix CHECK --check-prefix CHECK-32  --check-prefix HCHECK
+// RUN: %clang_cc1 -fopenmp -x c++ -std=c++11 -triple i386-unknown-unknown -omptargets=i386-pc-linux-gnu -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -x c++ -triple i386-unknown-unknown -omptargets=i386-pc-linux-gnu -std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s --check-prefix CHECK --check-prefix CHECK-32 --check-prefix HCHECK
+
+// Test target codegen - host bc file has to be created first. (no significant differences with host version of target region)
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown -omptargets=powerpc64le-ibm-linux-gnu -emit-llvm-bc %s -o %t-ppc-host.bc
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple powerpc64le-unknown-unknown -omptargets=powerpc64le-ibm-linux-gnu -emit-llvm %s -fopenmp-is-device -omp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck %s
+// RUN: %clang_cc1 -fopenmp -x c++ -std=c++11 -triple powerpc64le-unknown-unknown -omptargets=powerpc64le-ibm-linux-gnu -emit-pch -fopenmp-is-device -omp-host-ir-file-path %t-ppc-host.bc -o %t %s
+// RUN: %clang_cc1 -fopenmp -x c++ -triple powerpc64le-unknown-unknown -omptargets=powerpc64le-ibm-linux-gnu -std=c++11 -fopenmp-is-device -omp-host-ir-file-path %t-ppc-host.bc -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple i386-unknown-unknown -omptargets=i386-pc-linux-gnu -emit-llvm-bc %s -o %t-x86-host.bc
+// RUN: %clang_cc1 -verify -fopenmp -x c++ -triple i386-unknown-unknown -omptargets=i386-pc-linux-gnu -emit-llvm %s -fopenmp-is-device -omp-host-ir-file-path %t-x86-host.bc -o - | FileCheck %s
+// RUN: %clang_cc1 -fopenmp -x c++ -std=c++11 -triple i386-unknown-unknown -omptargets=i386-pc-linux-gnu -emit-pch -fopenmp-is-device -omp-host-ir-file-path %t-x86-host.bc -o %t %s
+// RUN: %clang_cc1 -fopenmp -x c++ -triple i386-unknown-unknown -omptargets=i386-pc-linux-gnu -std=c++11 -fopenmp-is-device -omp-host-ir-file-path %t-x86-host.bc -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s
+
+// expected-no-diagnostics
+#ifndef HEADER
+#define HEADER
+
+// CHECK-DAG: %ident_t = type { i32, i32, i32, i32, i8* }
+// CHECK-DAG: [[STR:@.+]] = private unnamed_addr constant [23 x i8] c";unknown;unknown;0;0;;\00"
+// CHECK-DAG: [[DEF_LOC_0:@.+]] = private unnamed_addr constant %ident_t { i32 0, i32 2, i32 0, i32 0, i8* getelementptr inbounds ([23 x i8], [23 x i8]* [[STR]], i32 0, i32 0) }
+
+// CHECK-LABEL: define {{.*void}} @{{.*}}without_schedule_clause{{.*}}(float* {{.+}}, float* {{.+}}, float* {{.+}}, float* {{.+}})
+void without_schedule_clause(float *a, float *b, float *c, float *d) {
+  #pragma omp target
+  #pragma omp teams
+  #pragma omp distribute
+  for (int i = 33; i < 3200; i += 7) {
+a[i] = b[i] * c[i] * d[i];
+  }
+}
+
+// CHECK: define {{.*}}void @.omp_outlined.(i32* noalias [[GBL_TIDP:%.+]], i32* noalias [[BND_TID:%.+]], float** dereferenceable({{[0-9]+}}) [[APTR:%.+]], float** dereferenceable({{[0-9]+}}) [[BPTR:%.+]], float** dereferenceable({{[0-9]+}}) [[CPTR:%.+]], float** dereferenceable({{[0-9]+}}) [[DPTR:%.+]])
+// CHECK:  [[TID_ADDR:%.+]] = alloca i32*
+// CHECK:  [[IV:%.+iv]] = alloca i32
+// CHECK:  [[LB:%.+lb]] = alloca i32
+// CHECK:  [[UB:%.+ub]] = alloca i32
+// CHECK:  [[ST:%.+stride]] = alloca i32
+// CHECK:  [[LAST:%.+last]] = alloca i32
+// CHECK-DAG:  store i32* [[GBL_TIDP]], i32** [[TID_ADDR]]
+// CHECK-DAG:  store i32 0, i32* [[LB]]
+// CHECK-DAG:  store i32 4571423, i32* [[UB]]
+// CHECK-DAG:  store i32 1, i32* [[ST]]
+// CHECK-DAG:  store i32 0, i32* [[LAST]]

Re: [PATCH] D17335: [clang-tidy] Fix a crash issue when clang-tidy runs with compilation database.

2016-02-22 Thread Alexander Kornienko via cfe-commits
alexfh added a comment.

In http://reviews.llvm.org/D17335#358613, @hokein wrote:

> - Don't save BuildDirectory for every error in each check.


I think, it's not going to work with multiple files. There's just one Stats 
instance.



Comment at: test/clang-tidy/clang-tidy-run-with-database.cpp:3
@@ +2,3 @@
+// RUN: sed 's|test_dir|%S|g' %S/Inputs/compilation-database/template.json > 
%T/compile_commands.json
+// RUN: clang-tidy --checks=-*,modernize-use-nullptr -p %T %s 
-header-filter=.* | FileCheck %s -implicit-check-not="{{warning:}}"
+

We need to test more stuff here, at least these come to mind:

1. -fix
2. multiple files in one clang-tidy invocation
3. files with the same name in different directories



http://reviews.llvm.org/D17335



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


Re: [PATCH] D17170: [OPENMP] Codegen for distribute directive

2016-02-22 Thread Carlo Bertolli via cfe-commits
carlo.bertolli marked 5 inline comments as done.
carlo.bertolli added a comment.

Updating patch following comments.


Repository:
  rL LLVM

http://reviews.llvm.org/D17170



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


Re: [PATCH] D16928: [OpenCL] Apply missing restrictions for Blocks in OpenCL v2.0

2016-02-22 Thread Anastasia Stulova via cfe-commits
Anastasia added a comment.

Yes, that's right. In this commit I assume parser has already accepted the 
blocks.

We currently accept them if -fblocks is passed. I think we should also accept 
blocks by default with CL2.0. But I am thinking not to restrict passing 
-fblocks with earlier CL version. This way it's possible to enable them with 
earlier standards if whoever does it knows what it's needed for. We could give 
a warning in this case. What do you think?

However, I wouldn't block this patch on it, as I wouldn't commit them together 
anyways. But I am happy to prepare a separate patch.


http://reviews.llvm.org/D16928



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


Re: [PATCH] D17345: [OpenCL] Improve diagnostics of address spaces for variables inside function

2016-02-22 Thread Anastasia Stulova via cfe-commits
Anastasia added a comment.

Yes, that's right. In this commit I assume parser has already accepted the 
blocks.

We currently accept them if -fblocks is passed. I think we should also accept 
blocks by default with CL2.0. But I am thinking not to restrict passing 
-fblocks with earlier CL version. This way it's possible to enable them with 
earlier standards if whoever does it knows what it's needed for. We could give 
a warning in this case. What do you think?

However, I wouldn't block this patch on it, as I wouldn't commit them together 
anyways. But I am happy to prepare a separate patch.


http://reviews.llvm.org/D17345



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


Re: [PATCH] D17456: [libcxx] Reorganize _LIBCPP_LOCALE__L_EXTENSIONS

2016-02-22 Thread Ben Craig via cfe-commits
bcraig updated the summary for this revision.
bcraig added a reviewer: joerg.
bcraig updated this revision to Diff 48687.
bcraig added a comment.

Changed libcxx prefix to libcpp.
Changed BSD forwarding macros to macro functions.


http://reviews.llvm.org/D17456

Files:
  include/__bsd_locale_defaults.h
  include/__bsd_locale_fallbacks.h
  include/locale
  src/locale.cpp

Index: src/locale.cpp
===
--- src/locale.cpp
+++ src/locale.cpp
@@ -1400,33 +1400,21 @@
 wchar_t
 ctype_byname::do_widen(char c) const
 {
-#ifdef _LIBCPP_LOCALE__L_EXTENSIONS
-return btowc_l(c, __l);
-#else
-return __btowc_l(c, __l);
-#endif
+return __libcpp_btowc_l(c, __l);
 }
 
 const char*
 ctype_byname::do_widen(const char* low, const char* high, char_type* dest) const
 {
 for (; low != high; ++low, ++dest)
-#ifdef _LIBCPP_LOCALE__L_EXTENSIONS
-*dest = btowc_l(*low, __l);
-#else
-*dest = __btowc_l(*low, __l);
-#endif
+*dest = __libcpp_btowc_l(*low, __l);
 return low;
 }
 
 char
 ctype_byname::do_narrow(char_type c, char dfault) const
 {
-#ifdef _LIBCPP_LOCALE__L_EXTENSIONS
-int r = wctob_l(c, __l);
-#else
-int r = __wctob_l(c, __l);
-#endif
+int r = __libcpp_wctob_l(c, __l);
 return r != static_cast(WEOF) ? static_cast(r) : dfault;
 }
 
@@ -1435,11 +1423,7 @@
 {
 for (; low != high; ++low, ++dest)
 {
-#ifdef _LIBCPP_LOCALE__L_EXTENSIONS
-int r = wctob_l(*low, __l);
-#else
-int r = __wctob_l(*low, __l);
-#endif
+int r = __libcpp_wctob_l(*low, __l);
 *dest = r != static_cast(WEOF) ? static_cast(r) : dfault;
 }
 return low;
@@ -1549,22 +1533,14 @@
 {
 // save state in case it is needed to recover to_nxt on error
 mbstate_t save_state = st;
-#ifdef _LIBCPP_LOCALE__L_EXTENSIONS
-size_t n = wcsnrtombs_l(to, _nxt, static_cast(fend-frm),
-static_cast(to_end-to), , __l);
-#else
-size_t n = __wcsnrtombs_l(to, _nxt, fend-frm, to_end-to, , __l);
-#endif
+size_t n = __libcpp_wcsnrtombs_l(to, _nxt, static_cast(fend-frm),
+ static_cast(to_end-to), , __l);
 if (n == size_t(-1))
 {
 // need to recover to_nxt
 for (to_nxt = to; frm != frm_nxt; ++frm)
 {
-#ifdef _LIBCPP_LOCALE__L_EXTENSIONS
-n = wcrtomb_l(to_nxt, *frm, _state, __l);
-#else
-n = __wcrtomb_l(to_nxt, *frm, _state, __l);
-#endif
+n = __libcpp_wcrtomb_l(to_nxt, *frm, _state, __l);
 if (n == size_t(-1))
 break;
 to_nxt += n;
@@ -1581,11 +1557,7 @@
 {
 // Try to write the terminating null
 extern_type tmp[MB_LEN_MAX];
-#ifdef _LIBCPP_LOCALE__L_EXTENSIONS
-n = wcrtomb_l(tmp, intern_type(), , __l);
-#else
-n = __wcrtomb_l(tmp, intern_type(), , __l);
-#endif
+n = __libcpp_wcrtomb_l(tmp, intern_type(), , __l);
 if (n == size_t(-1))  // on error
 return error;
 if (n > static_cast(to_end-to_nxt))  // is there room?
@@ -1618,23 +1590,15 @@
 {
 // save state in case it is needed to recover to_nxt on error
 mbstate_t save_state = st;
-#ifdef _LIBCPP_LOCALE__L_EXTENSIONS
-size_t n = mbsnrtowcs_l(to, _nxt, static_cast(fend-frm),
-static_cast(to_end-to), , __l);
-#else
-size_t n = __mbsnrtowcs_l(to, _nxt, fend-frm, to_end-to, , __l);
-#endif
+size_t n = __libcpp_mbsnrtowcs_l(to, _nxt, static_cast(fend-frm),
+ static_cast(to_end-to), , __l);
 if (n == size_t(-1))
 {
 // need to recover to_nxt
 for (to_nxt = to; frm != frm_nxt; ++to_nxt)
 {
-#ifdef _LIBCPP_LOCALE__L_EXTENSIONS
-n = mbrtowc_l(to_nxt, frm, static_cast(fend-frm),
-  _state, __l);
-#else
-n = __mbrtowc_l(to_nxt, frm, fend-frm, _state, __l);
-#endif
+n = __libcpp_mbrtowc_l(to_nxt, frm, static_cast(fend-frm),
+   _state, __l);
 switch (n)
 {
 case 0:
@@ -1662,11 +1626,7 @@
 if (fend != frm_end)  // set up next null terminated sequence
 {
 // Try to write the terminating null
-#ifdef _LIBCPP_LOCALE__L_EXTENSIONS
-n = mbrtowc_l(to_nxt, frm_nxt, 1, , __l);
-#else
-n = __mbrtowc_l(to_nxt, frm_nxt, 1, , __l);
-#endif
+n = __libcpp_mbrtowc_l(to_nxt, frm_nxt, 1, , __l);
 if (n != 0)  // on error
 return error;
 ++to_nxt;
@@ -1686,11 +1646,7 @@
 {
 to_nxt = to;
 extern_type tmp[MB_LEN_MAX];
-#ifdef _LIBCPP_LOCALE__L_EXTENSIONS
-size_t n = wcrtomb_l(tmp, intern_type(), , __l);
-#else
-

Re: [PATCH] D17484: [clang-tidy] introduce modernize-deprecated-headers check

2016-02-22 Thread Alexander Kornienko via cfe-commits
alexfh added a comment.

In http://reviews.llvm.org/D17484#358617, @alexfh wrote:

> ... the check in its current form can break the code that uses library 
> symbols from the global namespace. ...


An action item for this is: document this possible issue and add a FIXME 
somewhere in the code to add `std::` qualifiers.


http://reviews.llvm.org/D17484



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


[clang-tools-extra] r261530 - Add a new check, cert-env33-c, that diagnoses uses of system(), popen(), and _popen() to execute a command processor. This check corresponds to the CERT secure coding rul

2016-02-22 Thread Aaron Ballman via cfe-commits
Author: aaronballman
Date: Mon Feb 22 10:01:06 2016
New Revision: 261530

URL: http://llvm.org/viewvc/llvm-project?rev=261530=rev
Log:
Add a new check, cert-env33-c, that diagnoses uses of system(), popen(), and 
_popen() to execute a command processor. This check corresponds to the CERT 
secure coding rule: 
https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=2130132

Added:
clang-tools-extra/trunk/clang-tidy/cert/CommandProcessorCheck.cpp
clang-tools-extra/trunk/clang-tidy/cert/CommandProcessorCheck.h
clang-tools-extra/trunk/docs/clang-tidy/checks/cert-env33-c.rst
clang-tools-extra/trunk/test/clang-tidy/cert-env33-c.c
Modified:
clang-tools-extra/trunk/clang-tidy/cert/CERTTidyModule.cpp
clang-tools-extra/trunk/clang-tidy/cert/CMakeLists.txt
clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst

Modified: clang-tools-extra/trunk/clang-tidy/cert/CERTTidyModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/cert/CERTTidyModule.cpp?rev=261530=261529=261530=diff
==
--- clang-tools-extra/trunk/clang-tidy/cert/CERTTidyModule.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/cert/CERTTidyModule.cpp Mon Feb 22 
10:01:06 2016
@@ -16,6 +16,7 @@
 #include "../misc/NonCopyableObjects.h"
 #include "../misc/StaticAssertCheck.h"
 #include "../misc/ThrowByValueCatchByReferenceCheck.h"
+#include "CommandProcessorCheck.h"
 #include "FloatLoopCounter.h"
 #include "SetLongJmpCheck.h"
 #include "StaticObjectExceptionCheck.h"
@@ -54,6 +55,9 @@ public:
 // DCL
 CheckFactories.registerCheck(
 "cert-dcl03-c");
+// ENV
+CheckFactories.registerCheck(
+"cert-env33-c");
 // FLP
 CheckFactories.registerCheck(
 "cert-flp30-c");

Modified: clang-tools-extra/trunk/clang-tidy/cert/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/cert/CMakeLists.txt?rev=261530=261529=261530=diff
==
--- clang-tools-extra/trunk/clang-tidy/cert/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clang-tidy/cert/CMakeLists.txt Mon Feb 22 10:01:06 
2016
@@ -2,6 +2,7 @@ set(LLVM_LINK_COMPONENTS support)
 
 add_clang_library(clangTidyCERTModule
   CERTTidyModule.cpp
+  CommandProcessorCheck.cpp
   FloatLoopCounter.cpp
   SetLongJmpCheck.cpp
   StaticObjectExceptionCheck.cpp

Added: clang-tools-extra/trunk/clang-tidy/cert/CommandProcessorCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/cert/CommandProcessorCheck.cpp?rev=261530=auto
==
--- clang-tools-extra/trunk/clang-tidy/cert/CommandProcessorCheck.cpp (added)
+++ clang-tools-extra/trunk/clang-tidy/cert/CommandProcessorCheck.cpp Mon Feb 
22 10:01:06 2016
@@ -0,0 +1,45 @@
+//===--- Env33CCheck.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 "CommandProcessorCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+namespace cert {
+
+void CommandProcessorCheck::registerMatchers(MatchFinder *Finder) {
+  Finder->addMatcher(
+  callExpr(
+  callee(functionDecl(anyOf(hasName("::system"), hasName("::popen"),
+hasName("::_popen")))
+ .bind("func")),
+  // Do not diagnose when the call expression passes a null pointer
+  // constant to system(); that only checks for the presence of a
+  // command processor, which is not a security risk by itself.
+  unless(callExpr(callee(functionDecl(hasName("::system"))),
+  argumentCountIs(1),
+  hasArgument(0, nullPointerConstant()
+  .bind("expr"),
+  this);
+}
+
+void CommandProcessorCheck::check(const MatchFinder::MatchResult ) {
+  const auto *Fn = Result.Nodes.getNodeAs("func");
+  const auto *E = Result.Nodes.getNodeAs("expr");
+
+  diag(E->getExprLoc(), "calling %0 uses a command processor") << Fn;
+}
+
+} // namespace cert
+} // namespace tidy
+} // namespace clang

Added: clang-tools-extra/trunk/clang-tidy/cert/CommandProcessorCheck.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/cert/CommandProcessorCheck.h?rev=261530=auto
==
--- clang-tools-extra/trunk/clang-tidy/cert/CommandProcessorCheck.h (added)
+++ clang-tools-extra/trunk/clang-tidy/cert/CommandProcessorCheck.h 

Re: [PATCH] D17447: Add check for CERT ENV33-C

2016-02-22 Thread Aaron Ballman via cfe-commits
aaron.ballman closed this revision.
aaron.ballman added a comment.

Thanks! I've commit in r261530.


http://reviews.llvm.org/D17447



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


Re: [PATCH] D17335: [clang-tidy] Fix a crash issue when clang-tidy runs with compilation database.

2016-02-22 Thread Haojian Wu via cfe-commits
hokein marked 2 inline comments as done.


Comment at: clang-tidy/ClangTidyDiagnosticConsumer.cpp:122
@@ -121,3 +121,3 @@
   IsWarningAsError(IsWarningAsError) {}
 
 // Returns true if GlobList starts with the negative indicator ('-'), removes 
it

Done. Now there is no need to add `BuildDirectory` in each `ClangTidyError`.


http://reviews.llvm.org/D17335



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


Re: [PATCH] D17335: [clang-tidy] Fix a crash issue when clang-tidy runs with compilation database.

2016-02-22 Thread Haojian Wu via cfe-commits
hokein updated this revision to Diff 48686.
hokein marked an inline comment as done.
hokein added a comment.

Address one comment.


http://reviews.llvm.org/D17335

Files:
  clang-tidy/ClangTidy.cpp
  clang-tidy/ClangTidy.h
  clang-tidy/ClangTidyDiagnosticConsumer.cpp
  clang-tidy/ClangTidyDiagnosticConsumer.h
  clang-tidy/tool/ClangTidyMain.cpp
  test/clang-tidy/Inputs/compilation-database/header.h
  test/clang-tidy/Inputs/compilation-database/template.json
  test/clang-tidy/clang-tidy-run-with-database.cpp

Index: test/clang-tidy/clang-tidy-run-with-database.cpp
===
--- /dev/null
+++ test/clang-tidy/clang-tidy-run-with-database.cpp
@@ -0,0 +1,6 @@
+// REQUIRES: shell
+// RUN: sed 's|test_dir|%S|g' %S/Inputs/compilation-database/template.json > %T/compile_commands.json
+// RUN: clang-tidy --checks=-*,modernize-use-nullptr -p %T %s -header-filter=.* | FileCheck %s -implicit-check-not="{{warning:}}"
+
+#include "./Inputs/compilation-database/header.h"
+// CHECK: warning: use nullptr [modernize-use-nullptr]
Index: test/clang-tidy/Inputs/compilation-database/template.json
===
--- /dev/null
+++ test/clang-tidy/Inputs/compilation-database/template.json
@@ -0,0 +1,7 @@
+[
+{
+  "directory": "test_dir",
+  "command": "clang++ -o test.o clang-tidy-run-with-database.cpp",
+  "file": "test_dir/clang-tidy-run-with-database.cpp"
+}
+]
Index: test/clang-tidy/Inputs/compilation-database/header.h
===
--- /dev/null
+++ test/clang-tidy/Inputs/compilation-database/header.h
@@ -0,0 +1,3 @@
+#define NULL 0
+
+int *a = NULL;
Index: clang-tidy/tool/ClangTidyMain.cpp
===
--- clang-tidy/tool/ClangTidyMain.cpp
+++ clang-tidy/tool/ClangTidyMain.cpp
@@ -357,7 +357,8 @@
   unsigned WErrorCount = 0;
 
   // -fix-errors implies -fix.
-  handleErrors(Errors, (FixErrors || Fix) && !DisableFixes, WErrorCount);
+  handleErrors(Errors, (FixErrors || Fix) && !DisableFixes, WErrorCount,
+   Stats.BuildDirectory);
 
   if (!ExportFixes.empty() && !Errors.empty()) {
 std::error_code EC;
Index: clang-tidy/ClangTidyDiagnosticConsumer.h
===
--- clang-tidy/ClangTidyDiagnosticConsumer.h
+++ clang-tidy/ClangTidyDiagnosticConsumer.h
@@ -101,6 +101,14 @@
   unsigned ErrorsIgnoredNOLINT;
   unsigned ErrorsIgnoredNonUserCode;
   unsigned ErrorsIgnoredLineFilter;
+  // A build directory of the source file containing the error.
+  //
+  // It's an absolute path which is `directory` field of the source file in
+  // compilation database. If users don't specify the compilation database
+  // directory, it is the current directory where clang-tidy runs.
+  //
+  // It can be empty in some cases, e.g. the source file does not exist.
+  std::string BuildDirectory;
 
   unsigned errorsIgnored() const {
 return ErrorsIgnoredNOLINT + ErrorsIgnoredCheckFilter +
@@ -185,6 +193,8 @@
   /// counters.
   const ClangTidyStats () const { return Stats; }
 
+  void setBuildDirectoryForStats(StringRef BuildDirectory);
+
   /// \brief Returns all collected errors.
   const std::vector () const { return Errors; }
 
Index: clang-tidy/ClangTidyDiagnosticConsumer.cpp
===
--- clang-tidy/ClangTidyDiagnosticConsumer.cpp
+++ clang-tidy/ClangTidyDiagnosticConsumer.cpp
@@ -229,6 +229,10 @@
   OptionsProvider->getOptions(File));
 }
 
+void ClangTidyContext::setBuildDirectoryForStats(StringRef BuildDirectory) {
+  Stats.BuildDirectory = BuildDirectory;
+}
+
 void ClangTidyContext::setCheckProfileData(ProfileData *P) { Profile = P; }
 
 GlobList ::getChecksFilter() {
Index: clang-tidy/ClangTidy.h
===
--- clang-tidy/ClangTidy.h
+++ clang-tidy/ClangTidy.h
@@ -223,7 +223,8 @@
 /// \brief Displays the found \p Errors to the users. If \p Fix is true, \p
 /// Errors containing fixes are automatically applied.
 void handleErrors(const std::vector , bool Fix,
-  unsigned );
+  unsigned ,
+  StringRef BuildDirectory);
 
 /// \brief Serializes replacements into YAML and writes them to the specified
 /// output stream.
Index: clang-tidy/ClangTidy.cpp
===
--- clang-tidy/ClangTidy.cpp
+++ clang-tidy/ClangTidy.cpp
@@ -95,14 +95,20 @@
 
 class ErrorReporter {
 public:
-  ErrorReporter(bool ApplyFixes)
+  ErrorReporter(bool ApplyFixes, StringRef BuildDirectory)
   : Files(FileSystemOptions()), DiagOpts(new DiagnosticOptions()),
 DiagPrinter(new TextDiagnosticPrinter(llvm::outs(), &*DiagOpts)),
 Diags(IntrusiveRefCntPtr(new DiagnosticIDs), &*DiagOpts,
   DiagPrinter),
 SourceMgr(Diags, 

Re: [PATCH] D17484: [clang-tidy] introduce modernize-deprecated-headers check

2016-02-22 Thread Alexander Kornienko via cfe-commits
alexfh added a comment.

Thank you for this check! Mostly looks good, but there are a number of style 
nits.

The most important question to this check is that the standard doesn't 
guarantee that the C++ headers declare all the same functions **in the global 
namespace** (at least, this is how I understand the section of the standard you 
quoted). This means that the check in its current form can break the code that 
uses library symbols from the global namespace. The check could add `std::` 
wherever it's needed (though it may be not completely trivial) to mitigate the 
risk. It's not what needs to be addressed in the first iteration, but it's 
definitely worth a look at in order to make the check actually useful. It also 
could be a separate check or a separate mode (configurable via parameters) of 
this check, while someone could have reasons to do the migration in two stages 
(add `std::` qualifiers and then switch to new headers).



Comment at: clang-tidy/modernize/DeprecatedHeadersCheck.cpp:15
@@ +14,3 @@
+
+#include 
+#include 

Is this header used?


Comment at: clang-tidy/modernize/DeprecatedHeadersCheck.cpp:36
@@ +35,3 @@
+private:
+  std::map CStyledHeaderToCxx;
+

There's a more effective container in LLVM: `llvm::StringMap`. If 
your code guarantees that only string literals be used to initialize this map, 
this can be a `llvm::StringMap`.


Comment at: clang-tidy/modernize/DeprecatedHeadersCheck.cpp:54
@@ +53,3 @@
+: Check(Check), LangOpts(LangOpts) {
+  CStyledHeaderToCxx = {
+  {"assert.h", "cassert"},

It should be possible to initialize this in the constructor initializer list.


Comment at: clang-tidy/modernize/DeprecatedHeadersCheck.cpp:77
@@ +76,3 @@
+
+  // Add C++ 11 headers
+  if (LangOpts.CPlusPlus11) {

nit: Please add a trailing period.


Comment at: clang-tidy/modernize/DeprecatedHeadersCheck.cpp:94
@@ +93,3 @@
+StringRef SearchPath, StringRef RelativePath, const Module *Imported) {
+  if (CStyledHeaderToCxx.count(std::string(FileName)) != 0) {
+std::string Replacement =

1. s/`std::string(FileName)`/`FileName.str()`/
2. no need for this, if `llvm::StringMap` is used


Comment at: clang-tidy/modernize/DeprecatedHeadersCheck.cpp:96
@@ +95,3 @@
+std::string Replacement =
+"<" + CStyledHeaderToCxx[std::string(FileName)] + ">";
+Check.diag(FilenameRange.getBegin(), "including deprecated C++ header")

`FileName.str()`


Comment at: docs/clang-tidy/checks/modernize-deprecated-headers.rst:8
@@ +7,3 @@
+
+  Annex D (normative)
+  Compatibility features [depr]

This quote from the standard is too long for my taste. A simple reference to 
the relevant section should be enough (`[depr.c.headers]`).


Comment at: test/clang-tidy/modernize-deprecated-headers-cxx03.cpp:1
@@ +1,2 @@
+// RUN: %check_clang_tidy %s modernize-deprecated-headers %t -- -- -std=c++03 
-isystem %S/Inputs/Headers
+

You seem to have forgotten to add these headers to `Inputs/Headers`. Or doesn't 
the check care about them actually being present?


Comment at: test/clang-tidy/modernize-deprecated-headers-cxx03.cpp:25
@@ +24,3 @@
+
+// Headers deprecated since C++11; expect no diagnostics
+#include 

Trailing period.


Comment at: test/clang-tidy/modernize-deprecated-headers-cxx03.cpp:32
@@ +31,3 @@
+
+// CHECK-FIXES: #include 
+// CHECK-FIXES-NEXT: #include 

Please also check diagnostic messages (`// CHECK-MESSAGES: ...`).


http://reviews.llvm.org/D17484



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


Re: [PATCH] D17335: [clang-tidy] Fix a crash issue when clang-tidy runs with compilation database.

2016-02-22 Thread Haojian Wu via cfe-commits
hokein updated this revision to Diff 48684.
hokein added a comment.

Remove an extra blank line.


http://reviews.llvm.org/D17335

Files:
  clang-tidy/ClangTidy.cpp
  clang-tidy/ClangTidy.h
  clang-tidy/ClangTidyDiagnosticConsumer.cpp
  clang-tidy/ClangTidyDiagnosticConsumer.h
  clang-tidy/tool/ClangTidyMain.cpp
  test/clang-tidy/Inputs/compilation-database/header.h
  test/clang-tidy/Inputs/compilation-database/template.json
  test/clang-tidy/clang-tidy-run-with-database.cpp

Index: test/clang-tidy/clang-tidy-run-with-database.cpp
===
--- /dev/null
+++ test/clang-tidy/clang-tidy-run-with-database.cpp
@@ -0,0 +1,6 @@
+// REQUIRES: shell
+// RUN: sed 's|test_dir|%S|g' %S/Inputs/compilation-database/template.json > %T/compile_commands.json
+// RUN: clang-tidy --checks=-*,modernize-use-nullptr -p %T %s -header-filter=.* | FileCheck %s -implicit-check-not="{{warning:}}"
+
+#include "./Inputs/compilation-database/header.h"
+// CHECK: warning: use nullptr [modernize-use-nullptr]
Index: test/clang-tidy/Inputs/compilation-database/template.json
===
--- /dev/null
+++ test/clang-tidy/Inputs/compilation-database/template.json
@@ -0,0 +1,7 @@
+[
+{
+  "directory": "test_dir",
+  "command": "clang++ -o test.o clang-tidy-run-with-database.cpp",
+  "file": "test_dir/clang-tidy-run-with-database.cpp"
+}
+]
Index: test/clang-tidy/Inputs/compilation-database/header.h
===
--- /dev/null
+++ test/clang-tidy/Inputs/compilation-database/header.h
@@ -0,0 +1,3 @@
+#define NULL 0
+
+int *a = NULL;
Index: clang-tidy/tool/ClangTidyMain.cpp
===
--- clang-tidy/tool/ClangTidyMain.cpp
+++ clang-tidy/tool/ClangTidyMain.cpp
@@ -357,7 +357,8 @@
   unsigned WErrorCount = 0;
 
   // -fix-errors implies -fix.
-  handleErrors(Errors, (FixErrors || Fix) && !DisableFixes, WErrorCount);
+  handleErrors(Errors, (FixErrors || Fix) && !DisableFixes, WErrorCount,
+   Stats.BuildDirectory);
 
   if (!ExportFixes.empty() && !Errors.empty()) {
 std::error_code EC;
Index: clang-tidy/ClangTidyDiagnosticConsumer.h
===
--- clang-tidy/ClangTidyDiagnosticConsumer.h
+++ clang-tidy/ClangTidyDiagnosticConsumer.h
@@ -101,6 +101,14 @@
   unsigned ErrorsIgnoredNOLINT;
   unsigned ErrorsIgnoredNonUserCode;
   unsigned ErrorsIgnoredLineFilter;
+  // A build directory of the source file containing the error.
+  //
+  // It's an absolute path which is `directory` field of the source file in
+  // compilation database. If users don't specify compilation database
+  // directory, it is the current directory where clang-tidy runs.
+  //
+  // It can be empty in some cases, e.g. the source file does not exist.
+  std::string BuildDirectory;
 
   unsigned errorsIgnored() const {
 return ErrorsIgnoredNOLINT + ErrorsIgnoredCheckFilter +
@@ -185,6 +193,8 @@
   /// counters.
   const ClangTidyStats () const { return Stats; }
 
+  void setBuildDirectoryForStats(StringRef BuildDirectory);
+
   /// \brief Returns all collected errors.
   const std::vector () const { return Errors; }
 
Index: clang-tidy/ClangTidyDiagnosticConsumer.cpp
===
--- clang-tidy/ClangTidyDiagnosticConsumer.cpp
+++ clang-tidy/ClangTidyDiagnosticConsumer.cpp
@@ -229,6 +229,10 @@
   OptionsProvider->getOptions(File));
 }
 
+void ClangTidyContext::setBuildDirectoryForStats(StringRef BuildDirectory) {
+  Stats.BuildDirectory = BuildDirectory;
+}
+
 void ClangTidyContext::setCheckProfileData(ProfileData *P) { Profile = P; }
 
 GlobList ::getChecksFilter() {
Index: clang-tidy/ClangTidy.h
===
--- clang-tidy/ClangTidy.h
+++ clang-tidy/ClangTidy.h
@@ -223,7 +223,8 @@
 /// \brief Displays the found \p Errors to the users. If \p Fix is true, \p
 /// Errors containing fixes are automatically applied.
 void handleErrors(const std::vector , bool Fix,
-  unsigned );
+  unsigned ,
+  StringRef BuildDirectory);
 
 /// \brief Serializes replacements into YAML and writes them to the specified
 /// output stream.
Index: clang-tidy/ClangTidy.cpp
===
--- clang-tidy/ClangTidy.cpp
+++ clang-tidy/ClangTidy.cpp
@@ -95,14 +95,20 @@
 
 class ErrorReporter {
 public:
-  ErrorReporter(bool ApplyFixes)
+  ErrorReporter(bool ApplyFixes, StringRef BuildDirectory)
   : Files(FileSystemOptions()), DiagOpts(new DiagnosticOptions()),
 DiagPrinter(new TextDiagnosticPrinter(llvm::outs(), &*DiagOpts)),
 Diags(IntrusiveRefCntPtr(new DiagnosticIDs), &*DiagOpts,
   DiagPrinter),
 SourceMgr(Diags, Files), Rewrite(SourceMgr, LangOpts),
  

Re: [PATCH] D17163: [ASTMatchers] Add matcher hasAnyName.

2016-02-22 Thread Alexander Kornienko via cfe-commits
alexfh accepted this revision.
alexfh added a comment.
This revision is now accepted and ready to land.

Looks good. Thanks!

(I suppose, Manuel has no substantial comments on this, since he has already 
seen the patch).


http://reviews.llvm.org/D17163



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


[PATCH] D17507: The controlling expression for _Generic is unevaluated

2016-02-22 Thread Aaron Ballman via cfe-commits
aaron.ballman created this revision.
aaron.ballman added a reviewer: rsmith.
aaron.ballman added a subscriber: cfe-commits.

In r252104, I fixed a _Generic bug so that the controlling expression has its 
type decayed and qualifiers stripped. However, this caused a diagnostic 
regression because the controlling expression is not evaluated, and my fix 
triggered diagnostics (like null pointer dereferences) that it should not have. 
This patch fixes the regression by putting the evaluation of the controlling 
expression into an unevaluated context before decaying and stripping qualifiers.

Assuming this patch is acceptable, I think it should go into 3.8 as well.

http://reviews.llvm.org/D17507

Files:
  lib/Sema/SemaExpr.cpp
  test/Sema/generic-selection.c

Index: test/Sema/generic-selection.c
===
--- test/Sema/generic-selection.c
+++ test/Sema/generic-selection.c
@@ -31,4 +31,8 @@
 
   const int i = 12;
   int a9[_Generic(i, int: 1, default: 2) == 1 ? 1 : -1];
+
+  // This is expected to not trigger any diagnostics because the controlling
+  // expression is not evaluated.
+  (void)_Generic(*(int *)0, int: 1);
 }
Index: lib/Sema/SemaExpr.cpp
===
--- lib/Sema/SemaExpr.cpp
+++ lib/Sema/SemaExpr.cpp
@@ -1373,10 +1373,13 @@
 
   // Decay and strip qualifiers for the controlling expression type, and handle
   // placeholder type replacement. See committee discussion from WG14 DR423.
-  ExprResult R = DefaultFunctionArrayLvalueConversion(ControllingExpr);
-  if (R.isInvalid())
-return ExprError();
-  ControllingExpr = R.get();
+  {
+EnterExpressionEvaluationContext Unevaluated(*this, Sema::Unevaluated);
+ExprResult R = DefaultFunctionArrayLvalueConversion(ControllingExpr);
+if (R.isInvalid())
+  return ExprError();
+ControllingExpr = R.get();
+  }
 
   // The controlling expression is an unevaluated operand, so side effects are
   // likely unintended.


Index: test/Sema/generic-selection.c
===
--- test/Sema/generic-selection.c
+++ test/Sema/generic-selection.c
@@ -31,4 +31,8 @@
 
   const int i = 12;
   int a9[_Generic(i, int: 1, default: 2) == 1 ? 1 : -1];
+
+  // This is expected to not trigger any diagnostics because the controlling
+  // expression is not evaluated.
+  (void)_Generic(*(int *)0, int: 1);
 }
Index: lib/Sema/SemaExpr.cpp
===
--- lib/Sema/SemaExpr.cpp
+++ lib/Sema/SemaExpr.cpp
@@ -1373,10 +1373,13 @@
 
   // Decay and strip qualifiers for the controlling expression type, and handle
   // placeholder type replacement. See committee discussion from WG14 DR423.
-  ExprResult R = DefaultFunctionArrayLvalueConversion(ControllingExpr);
-  if (R.isInvalid())
-return ExprError();
-  ControllingExpr = R.get();
+  {
+EnterExpressionEvaluationContext Unevaluated(*this, Sema::Unevaluated);
+ExprResult R = DefaultFunctionArrayLvalueConversion(ControllingExpr);
+if (R.isInvalid())
+  return ExprError();
+ControllingExpr = R.get();
+  }
 
   // The controlling expression is an unevaluated operand, so side effects are
   // likely unintended.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D17335: [clang-tidy] Fix a crash issue when clang-tidy runs with compilation database.

2016-02-22 Thread Haojian Wu via cfe-commits
hokein updated this revision to Diff 48683.
hokein added a comment.

Some cleanup.


http://reviews.llvm.org/D17335

Files:
  clang-tidy/ClangTidy.cpp
  clang-tidy/ClangTidy.h
  clang-tidy/ClangTidyDiagnosticConsumer.cpp
  clang-tidy/ClangTidyDiagnosticConsumer.h
  clang-tidy/tool/ClangTidyMain.cpp
  test/clang-tidy/Inputs/compilation-database/header.h
  test/clang-tidy/Inputs/compilation-database/template.json
  test/clang-tidy/clang-tidy-run-with-database.cpp

Index: test/clang-tidy/clang-tidy-run-with-database.cpp
===
--- /dev/null
+++ test/clang-tidy/clang-tidy-run-with-database.cpp
@@ -0,0 +1,6 @@
+// REQUIRES: shell
+// RUN: sed 's|test_dir|%S|g' %S/Inputs/compilation-database/template.json > %T/compile_commands.json
+// RUN: clang-tidy --checks=-*,modernize-use-nullptr -p %T %s -header-filter=.* | FileCheck %s -implicit-check-not="{{warning:}}"
+
+#include "./Inputs/compilation-database/header.h"
+// CHECK: warning: use nullptr [modernize-use-nullptr]
Index: test/clang-tidy/Inputs/compilation-database/template.json
===
--- /dev/null
+++ test/clang-tidy/Inputs/compilation-database/template.json
@@ -0,0 +1,7 @@
+[
+{
+  "directory": "test_dir",
+  "command": "clang++ -o test.o clang-tidy-run-with-database.cpp",
+  "file": "test_dir/clang-tidy-run-with-database.cpp"
+}
+]
Index: test/clang-tidy/Inputs/compilation-database/header.h
===
--- /dev/null
+++ test/clang-tidy/Inputs/compilation-database/header.h
@@ -0,0 +1,3 @@
+#define NULL 0
+
+int *a = NULL;
Index: clang-tidy/tool/ClangTidyMain.cpp
===
--- clang-tidy/tool/ClangTidyMain.cpp
+++ clang-tidy/tool/ClangTidyMain.cpp
@@ -357,7 +357,8 @@
   unsigned WErrorCount = 0;
 
   // -fix-errors implies -fix.
-  handleErrors(Errors, (FixErrors || Fix) && !DisableFixes, WErrorCount);
+  handleErrors(Errors, (FixErrors || Fix) && !DisableFixes, WErrorCount,
+   Stats.BuildDirectory);
 
   if (!ExportFixes.empty() && !Errors.empty()) {
 std::error_code EC;
Index: clang-tidy/ClangTidyDiagnosticConsumer.h
===
--- clang-tidy/ClangTidyDiagnosticConsumer.h
+++ clang-tidy/ClangTidyDiagnosticConsumer.h
@@ -101,6 +101,14 @@
   unsigned ErrorsIgnoredNOLINT;
   unsigned ErrorsIgnoredNonUserCode;
   unsigned ErrorsIgnoredLineFilter;
+  // A build directory of the source file containing the error.
+  //
+  // It's an absolute path which is `directory` field of the source file in
+  // compilation database. If users don't specify compilation database
+  // directory, it is the current directory where clang-tidy runs.
+  //
+  // It can be empty in some cases, e.g. the source file does not exist.
+  std::string BuildDirectory;
 
   unsigned errorsIgnored() const {
 return ErrorsIgnoredNOLINT + ErrorsIgnoredCheckFilter +
@@ -185,6 +193,8 @@
   /// counters.
   const ClangTidyStats () const { return Stats; }
 
+  void setBuildDirectoryForStats(StringRef BuildDirectory);
+
   /// \brief Returns all collected errors.
   const std::vector () const { return Errors; }
 
Index: clang-tidy/ClangTidyDiagnosticConsumer.cpp
===
--- clang-tidy/ClangTidyDiagnosticConsumer.cpp
+++ clang-tidy/ClangTidyDiagnosticConsumer.cpp
@@ -229,6 +229,10 @@
   OptionsProvider->getOptions(File));
 }
 
+void ClangTidyContext::setBuildDirectoryForStats(StringRef BuildDirectory) {
+  Stats.BuildDirectory = BuildDirectory;
+}
+
 void ClangTidyContext::setCheckProfileData(ProfileData *P) { Profile = P; }
 
 GlobList ::getChecksFilter() {
@@ -335,6 +339,7 @@
 bool IsWarningAsError =
 DiagLevel == DiagnosticsEngine::Warning &&
 Context.getWarningAsErrorFilter().contains(CheckName);
+
 Errors.push_back(ClangTidyError(CheckName, Level, IsWarningAsError));
   }
 
Index: clang-tidy/ClangTidy.h
===
--- clang-tidy/ClangTidy.h
+++ clang-tidy/ClangTidy.h
@@ -223,7 +223,8 @@
 /// \brief Displays the found \p Errors to the users. If \p Fix is true, \p
 /// Errors containing fixes are automatically applied.
 void handleErrors(const std::vector , bool Fix,
-  unsigned );
+  unsigned ,
+  StringRef BuildDirectory);
 
 /// \brief Serializes replacements into YAML and writes them to the specified
 /// output stream.
Index: clang-tidy/ClangTidy.cpp
===
--- clang-tidy/ClangTidy.cpp
+++ clang-tidy/ClangTidy.cpp
@@ -95,14 +95,20 @@
 
 class ErrorReporter {
 public:
-  ErrorReporter(bool ApplyFixes)
+  ErrorReporter(bool ApplyFixes, StringRef BuildDirectory)
   : Files(FileSystemOptions()), DiagOpts(new DiagnosticOptions()),
 

Re: [PATCH] D17335: [clang-tidy] Fix a crash issue when clang-tidy runs with compilation database.

2016-02-22 Thread Haojian Wu via cfe-commits
hokein updated this revision to Diff 48682.
hokein marked an inline comment as done.
hokein added a comment.

- Don't save BuildDirectory for every error in each check.


http://reviews.llvm.org/D17335

Files:
  clang-tidy/ClangTidy.cpp
  clang-tidy/ClangTidy.h
  clang-tidy/ClangTidyDiagnosticConsumer.cpp
  clang-tidy/ClangTidyDiagnosticConsumer.h
  clang-tidy/tool/ClangTidyMain.cpp
  test/clang-tidy/Inputs/compilation-database/header.h
  test/clang-tidy/Inputs/compilation-database/template.json
  test/clang-tidy/clang-tidy-run-with-database.cpp

Index: test/clang-tidy/clang-tidy-run-with-database.cpp
===
--- /dev/null
+++ test/clang-tidy/clang-tidy-run-with-database.cpp
@@ -0,0 +1,6 @@
+// REQUIRES: shell
+// RUN: sed 's|test_dir|%S|g' %S/Inputs/compilation-database/template.json > %T/compile_commands.json
+// RUN: clang-tidy --checks=-*,modernize-use-nullptr -p %T %s -header-filter=.* | FileCheck %s -implicit-check-not="{{warning:}}"
+
+#include "./Inputs/compilation-database/header.h"
+// CHECK: warning: use nullptr [modernize-use-nullptr]
Index: test/clang-tidy/Inputs/compilation-database/template.json
===
--- /dev/null
+++ test/clang-tidy/Inputs/compilation-database/template.json
@@ -0,0 +1,7 @@
+[
+{
+  "directory": "test_dir",
+  "command": "clang++ -o test.o clang-tidy-run-with-database.cpp",
+  "file": "test_dir/clang-tidy-run-with-database.cpp"
+}
+]
Index: test/clang-tidy/Inputs/compilation-database/header.h
===
--- /dev/null
+++ test/clang-tidy/Inputs/compilation-database/header.h
@@ -0,0 +1,3 @@
+#define NULL 0
+
+int *a = NULL;
Index: clang-tidy/tool/ClangTidyMain.cpp
===
--- clang-tidy/tool/ClangTidyMain.cpp
+++ clang-tidy/tool/ClangTidyMain.cpp
@@ -357,7 +357,8 @@
   unsigned WErrorCount = 0;
 
   // -fix-errors implies -fix.
-  handleErrors(Errors, (FixErrors || Fix) && !DisableFixes, WErrorCount);
+  handleErrors(Errors, (FixErrors || Fix) && !DisableFixes, WErrorCount,
+   Stats.BuildDirectory);
 
   if (!ExportFixes.empty() && !Errors.empty()) {
 std::error_code EC;
Index: clang-tidy/ClangTidyDiagnosticConsumer.h
===
--- clang-tidy/ClangTidyDiagnosticConsumer.h
+++ clang-tidy/ClangTidyDiagnosticConsumer.h
@@ -101,6 +101,14 @@
   unsigned ErrorsIgnoredNOLINT;
   unsigned ErrorsIgnoredNonUserCode;
   unsigned ErrorsIgnoredLineFilter;
+  // A build directory of the source file containing the error.
+  //
+  // It's an absolute path which is `directory` field of the source file in
+  // compilation database. If users don't specify compilation database
+  // directory, it is the current directory where clang-tidy runs.
+  //
+  // It can be empty in some cases, e.g. the source file does not exist.
+  std::string BuildDirectory;
 
   unsigned errorsIgnored() const {
 return ErrorsIgnoredNOLINT + ErrorsIgnoredCheckFilter +
@@ -185,6 +193,8 @@
   /// counters.
   const ClangTidyStats () const { return Stats; }
 
+  void setBuildDirectoryForStats(StringRef BuildDirectory);
+
   /// \brief Returns all collected errors.
   const std::vector () const { return Errors; }
 
Index: clang-tidy/ClangTidyDiagnosticConsumer.cpp
===
--- clang-tidy/ClangTidyDiagnosticConsumer.cpp
+++ clang-tidy/ClangTidyDiagnosticConsumer.cpp
@@ -229,6 +229,10 @@
   OptionsProvider->getOptions(File));
 }
 
+void ClangTidyContext::setBuildDirectoryForStats(StringRef BuildDirectory) {
+  Stats.BuildDirectory = BuildDirectory;
+}
+
 void ClangTidyContext::setCheckProfileData(ProfileData *P) { Profile = P; }
 
 GlobList ::getChecksFilter() {
@@ -335,6 +339,15 @@
 bool IsWarningAsError =
 DiagLevel == DiagnosticsEngine::Warning &&
 Context.getWarningAsErrorFilter().contains(CheckName);
+
+std::string BuildDirectory;
+if (Info.hasSourceManager()) {
+  auto WorkingDir = Info.getSourceManager()
+.getFileManager().getVirtualFileSystem()
+->getCurrentWorkingDirectory();
+  if (WorkingDir)
+BuildDirectory = WorkingDir.get();
+}
 Errors.push_back(ClangTidyError(CheckName, Level, IsWarningAsError));
   }
 
Index: clang-tidy/ClangTidy.h
===
--- clang-tidy/ClangTidy.h
+++ clang-tidy/ClangTidy.h
@@ -223,7 +223,8 @@
 /// \brief Displays the found \p Errors to the users. If \p Fix is true, \p
 /// Errors containing fixes are automatically applied.
 void handleErrors(const std::vector , bool Fix,
-  unsigned );
+  unsigned ,
+  StringRef BuildDirectory);
 
 /// \brief Serializes replacements into YAML and writes them to the 

Re: [PATCH] D17507: The controlling expression for _Generic is unevaluated

2016-02-22 Thread Aaron Ballman via cfe-commits
On Mon, Feb 22, 2016 at 10:52 AM, Aaron Ballman  wrote:
> aaron.ballman created this revision.
> aaron.ballman added a reviewer: rsmith.
> aaron.ballman added a subscriber: cfe-commits.
>
> In r252104, I fixed a _Generic bug so that the controlling expression has its 
> type decayed and qualifiers stripped. However, this caused a diagnostic 
> regression because the controlling expression is not evaluated, and my fix 
> triggered diagnostics (like null pointer dereferences) that it should not 
> have. This patch fixes the regression by putting the evaluation of the 
> controlling expression into an unevaluated context before decaying and 
> stripping qualifiers.

I should point out that this addresses PR26398
(https://llvm.org/bugs/show_bug.cgi?id=26398).

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


Re: [PATCH] D17456: [libcxx] Reorganize _LIBCPP_LOCALE__L_EXTENSIONS

2016-02-22 Thread Marshall Clow via cfe-commits
mclow.lists added a comment.

Actually, the prefix we use in the rest of libc++ for private functions is 
`__libcpp_`  Take a look in type_traits for a bunch of examples.

In general, I'm liking the way this is going. I suspect I will have more 
comments later today.


http://reviews.llvm.org/D17456



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


Re: [PATCH] D17456: [libcxx] Reorganize _LIBCPP_LOCALE__L_EXTENSIONS

2016-02-22 Thread Joerg Sonnenberger via cfe-commits
On Mon, Feb 22, 2016 at 08:25:56AM -0600, Craig, Ben via cfe-commits wrote:
> On 2/19/2016 3:32 PM, Joerg Sonnenberger via cfe-commits wrote:
> >On Fri, Feb 19, 2016 at 06:14:18PM +, Ben Craig via cfe-commits wrote:
> >>Instead of checking _LIBCPP_LOCALE__L_EXTENSIONS all over, instead
> >>check it once, and define the various *_l symbols once.
> >If you want to rename using macros, please use the argument form. I find
> >that to provide better self-documentation.
> >
> >Joerg
> Would the following form address your concerns?
> #define __libcxx_sscanf_l(...) sscanf_l(__VA_ARGS__)
> 
> I think that getting more elaborate than that general form would be more
> effort and more buggy without significant customer benefit.

For variadic functions, the above is fine. I don't think it is more
complicated for the fixed argument-number versions.

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


Re: [PATCH] D17416: [libcxx] Reorganize locale extension fallbacks. NFCI

2016-02-22 Thread Marshall Clow via cfe-commits
mclow.lists added a comment.

This looks fine to me; but I want to hear from @danalbert.


http://reviews.llvm.org/D17416



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


  1   2   >