[PATCH] D26015: Correctly classify main file includes if there is a prefix added

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

LG. Thank you for the fix!


https://reviews.llvm.org/D26015



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


[PATCH] D26082: Support for Python 3 in libclang python bindings

2017-01-11 Thread Mathieu Duponchelle via Phabricator via cfe-commits
MathieuDuponchelle added a comment.

In https://reviews.llvm.org/D26082#621496, @jbcoe wrote:

> Hi Mathieu,
>  What platform did you run the tests on? How did you run them? I don't get 
> any failures when running tests on macOS 10.12.1.


Hey @jbcoe, do you think you can have a look at this issue? Please see my 
earlier comment for a way to reproduce this 
(`LD_LIBRARY_PATH=/home/meh/devel/sandbox/llvm/build/lib valgrind python3 -m 
nose tests.cindex.test_cursor:test_get_template_argument_value` is a valid way 
to reproduce this issue)


Repository:
  rL LLVM

https://reviews.llvm.org/D26082



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


[PATCH] D28080: [Docs][OpenCL] Added OpenCL feature description to user manual.

2017-01-11 Thread Alexey Bader via Phabricator via cfe-commits
bader added a comment.

Thanks for working on this!
Looks good, except a few pedantic notes.




Comment at: docs/UsersManual.rst:44
 -  :ref:`Objective C++ Language `
+-  :ref:`OpenCL Language `: v1.0, v1.1, v1.2, v2.0.
 

It should and to be perfectly clear we might consider using term "OpenCL C 
kernel language" to avoid confusion with OpenCL host code language or OpenCL 
C++ kernel language.



Comment at: docs/UsersManual.rst:2009
+
+ $ clang test.cl -c -emit-llvm
+

Just for the sake of consistency it would be nice to switch input file name 
with the options:

   clang -c -emit-llvm test.cl



Comment at: docs/UsersManual.rst:2014
+
+Clang currently supports OpenCL standards up to v2.0.
+

I suggest specifying that Clang support OpenCL C kernel language standards up 
to v2.0.
For instance OpenCL v2.1 doesn't introduce new OpenCL C kernel language 
standard - it still uses v2.0. So existing clang is sufficient enough to serve 
as front-end compiler in OpenCL 2.1 driver.



Comment at: docs/UsersManual.rst:2120
+  that can be used across GPU toolchains. The implementation follows `the SPIR
+  specification `_. There are two flavors 
available
+  for 32 and 64 bits.

pekka.jaaskelainen wrote:
> Which version of SPIR is generated?
For -cl-std=CL1.x (where x is 0, 1 or 2), SPIR version is 1.2.
For -cl-std=CL2.0, SPIR version is 2.0.



Comment at: docs/UsersManual.rst:2142-2143
+
+By default Clang will not include standard headers and therefore OpenCL builtin
+functions are unknown. The default CL header is, however, provided in the Clang
+installation and can be enabled by passing the ``-finclude-default-header`` 
flag

Not sure it's worth to mention, but even built-in vector types are defined in 
the opencl-c.h.


https://reviews.llvm.org/D28080



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


[PATCH] D28467: [Sema] Add warning for unused lambda captures

2017-01-11 Thread Malcolm Parsons via Phabricator via cfe-commits
malcolm.parsons marked an inline comment as done.
malcolm.parsons added inline comments.



Comment at: include/clang/Sema/ScopeInfo.h:457
+/// lambda.
+bool Used = false;
+

aaron.ballman wrote:
> arphaman wrote:
> > malcolm.parsons wrote:
> > > Should this be moved into one of the `PointerIntPair`s?
> > I'm not sure.. If we needed other capturing information in the future I 
> > would say that this should be its own field, but I'm not aware of anything 
> > else that's needed for this class. So I guess it would be better to pack it 
> > into `VarAndNestedAndThis`, but I wouldn't say it's a deal breaker.
> I'm not keen on inconsistently initializating data members; can you perform 
> this initialization in the constructor instead?
I'm not keen on repeating the initialization in every constructor.



Comment at: lib/Sema/SemaLambda.cpp:1479
 for (unsigned I = 0, N = LSI->Captures.size(); I != N; ++I, ++CurField) {
-  LambdaScopeInfo::Capture From = LSI->Captures[I];
+  LambdaScopeInfo::Capture &From = LSI->Captures[I];
   assert(!From.isBlockCapture() && "Cannot capture __block variables");

aaron.ballman wrote:
> Why does `From` need to be a non-const reference?
It's not related to the warning; it looks like an unnecessary copy.



Comment at: test/SemaCXX/warn-unused-lambda-capture.cpp:17
+  auto explicit_by_value_unused = [i] {}; // expected-warning{{lambda capture 
'i' is not used}}
+  auto explicit_by_value_unused_sizeof = [i] { return sizeof(i); }; // 
expected-warning{{lambda capture 'i' is not used}}
+

Quuxplusone wrote:
> aaron.ballman wrote:
> > This does not match the behavior for other -Wunused flags. e.g.,
> > ```
> > void f() {
> >   int i;
> >   (void)sizeof(i);
> > }
> > ```
> > I don't think diagnosing this test case is correct.
> I see some value to maybe diagnosing *something* here. For example, `[] { 
> return sizeof(i); }` would produce the same result as `[i] { return 
> sizeof(i); }` but with one fewer capture, so removing the `i` might be seen 
> as an improvement.
> 
> But I'm not sure how to convey this information to the user. You could say 
> "variable `i` used in unevaluated context refers to the `i` in the outer 
> scope, not the captured `i`"... except that I think that would be false. 
> Given that you *have* captured an `i`, `sizeof(i)` definitely refers to the 
> captured one AFAIK. The fact that the captured `i` shadows an `i` in the 
> outer scope is irrelevant --- in fact the user is *expecting* to shadow the 
> outer `i`.
> 
> Perhaps it would be appropriate to reword the diagnostic to "lambda captures 
> variable `i` unnecessarily".  I would also lean toward splitting it into two 
> diagnostics — one for "this capture is unnecessary" (as in this example) and 
> one for "this capture doesn't even appear lexically in the body of the 
> lambda". Not sure how other people would feel about that.
> 
> You should add some test cases with `decltype(i)` for the same reason as 
> `sizeof(i)`.
Does "lambda capture 'i' is not odr-used" make more sense?



Comment at: test/SemaCXX/warn-unused-lambda-capture.cpp:26
+  auto explicit_initialized_value_used = [j = 1] { return j + 1; };
+  auto explicit_initialized_value_unused = [j = 1] {}; // 
expected-warning{{lambda capture 'j' is not used}}
+

Quuxplusone wrote:
> Would this still produce a diagnostic if `decltype(j)` were something 
> complicated like `lock_guard` or `string`? Presumably it should do the same 
> thing, more or less, as the other -Wunused diagnostics, which I think is 
> "don't warn if the constructor/destructor might actually do important work".
I was planning to check for that; thanks for the reminder.


https://reviews.llvm.org/D28467



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


[PATCH] D28548: Improve include fixer's ranking by taking the paths into account.

2017-01-11 Thread Manuel Klimek via Phabricator via cfe-commits
klimek created this revision.
klimek added a reviewer: bkramer.
klimek added a subscriber: cfe-commits.

Instead of just using popularity, we also take into account how similar the
path of the current file is to the path of the header.
Our first approach is to get popularity into a reasonably small scale by taking
log2 (which is roughly intuitive to how humans would bucket popularity), and
multiply that with the number of matching prefix path fragments of the included
header with the current file.
Note that currently we do not take special care for unclean paths containing
"../" or "./".


https://reviews.llvm.org/D28548

Files:
  include-fixer/IncludeFixer.cpp
  include-fixer/SymbolIndexManager.cpp
  include-fixer/SymbolIndexManager.h
  include-fixer/tool/ClangIncludeFixer.cpp
  test/include-fixer/Inputs/fake_yaml_db.yaml
  test/include-fixer/ranking.cpp

Index: test/include-fixer/ranking.cpp
===
--- test/include-fixer/ranking.cpp
+++ test/include-fixer/ranking.cpp
@@ -1,6 +1,9 @@
 // RUN: clang-include-fixer -db=yaml -input=%S/Inputs/fake_yaml_db.yaml -output-headers %s -- | FileCheck %s
+// RUN: clang-include-fixer -query-symbol bar -db=yaml -input=%S/Inputs/fake_yaml_db.yaml -output-headers %s -- | FileCheck %s
 
 // CHECK: "HeaderInfos": [
+// CHECK-NEXT:  {"Header": "\"test/include-fixer/baz.h\"",
+// CHECK-NEXT:   "QualifiedName": "c::bar"},
 // CHECK-NEXT:  {"Header": "\"../include/bar.h\"",
 // CHECK-NEXT:   "QualifiedName": "b::a::bar"},
 // CHECK-NEXT:  {"Header": "\"../include/zbar.h\"",
Index: test/include-fixer/Inputs/fake_yaml_db.yaml
===
--- test/include-fixer/Inputs/fake_yaml_db.yaml
+++ test/include-fixer/Inputs/fake_yaml_db.yaml
@@ -9,7 +9,6 @@
 LineNumber:  1
 Type:Class
 NumOccurrences:  1
-...
 ---
 Name:   bar
 Contexts:
@@ -21,7 +20,7 @@
 LineNumber:  1
 Type:Class
 NumOccurrences:  1
-...
+---
 Name:   bar
 Contexts:
   - ContextType: Namespace
@@ -32,7 +31,7 @@
 LineNumber:  2
 Type:Class
 NumOccurrences:  3
-...
+---
 Name:   bar
 Contexts:
   - ContextType: Namespace
@@ -50,4 +49,12 @@
 LineNumber:  1
 Type:Variable
 NumOccurrences:  1
-...
+---
+Name:bar
+Contexts:
+  - ContextType:Namespace
+ContextName:c
+FilePath:test/include-fixer/baz.h
+LineNumber:  1
+Type:Class
+NumOccurrences:  1
Index: include-fixer/tool/ClangIncludeFixer.cpp
===
--- include-fixer/tool/ClangIncludeFixer.cpp
+++ include-fixer/tool/ClangIncludeFixer.cpp
@@ -332,7 +332,8 @@
 
   // Query symbol mode.
   if (!QuerySymbol.empty()) {
-auto MatchedSymbols = SymbolIndexMgr->search(QuerySymbol);
+auto MatchedSymbols = SymbolIndexMgr->search(
+QuerySymbol, /*IsNestedSearch=*/true, SourceFilePath);
 for (auto &Symbol : MatchedSymbols) {
   std::string HeaderPath = Symbol.getFilePath().str();
   Symbol.SetFilePath(((HeaderPath[0] == '"' || HeaderPath[0] == '<')
Index: include-fixer/SymbolIndexManager.h
===
--- include-fixer/SymbolIndexManager.h
+++ include-fixer/SymbolIndexManager.h
@@ -42,7 +42,8 @@
   ///
   /// \returns A list of symbol candidates.
   std::vector
-  search(llvm::StringRef Identifier, bool IsNestedSearch = true) const;
+  search(llvm::StringRef Identifier, bool IsNestedSearch = true,
+ llvm::StringRef FileName = "") const;
 
 private:
   std::vector>> SymbolIndices;
Index: include-fixer/SymbolIndexManager.cpp
===
--- include-fixer/SymbolIndexManager.cpp
+++ include-fixer/SymbolIndexManager.cpp
@@ -12,38 +12,66 @@
 #include "llvm/ADT/DenseMap.h"
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/Support/Debug.h"
+#include "llvm/Support/Path.h"
 
 #define DEBUG_TYPE "include-fixer"
 
 namespace clang {
 namespace include_fixer {
 
 using clang::find_all_symbols::SymbolInfo;
 
-/// Sorts SymbolInfos based on the popularity info in SymbolInfo.
-static void rankByPopularity(std::vector &Symbols) {
-  // First collect occurrences per header file.
-  llvm::DenseMap HeaderPopularity;
-  for (const SymbolInfo &Symbol : Symbols) {
-unsigned &Popularity = HeaderPopularity[Symbol.getFilePath()];
-Popularity = std::max(Popularity, Symbol.getNumOccurrences());
+// Calculate a score based on whether we think the given header is closely
+// related to the given source file.
+static double similarityScore(llvm::StringRef FileName,
+  llvm::StringRef Header) {
+  // Compute the maximum number of common path segements between Header and
+  // a suffix of FileName.
+  // We do not do a full longest common substring computation, as Header
+  // specifies the path we would directly #incl

[PATCH] D28467: [Sema] Add warning for unused lambda captures

2017-01-11 Thread Arthur O'Dwyer via Phabricator via cfe-commits
Quuxplusone added inline comments.



Comment at: test/SemaCXX/warn-unused-lambda-capture.cpp:17
+  auto explicit_by_value_unused = [i] {}; // expected-warning{{lambda capture 
'i' is not used}}
+  auto explicit_by_value_unused_sizeof = [i] { return sizeof(i); }; // 
expected-warning{{lambda capture 'i' is not used}}
+

malcolm.parsons wrote:
> Quuxplusone wrote:
> > aaron.ballman wrote:
> > > This does not match the behavior for other -Wunused flags. e.g.,
> > > ```
> > > void f() {
> > >   int i;
> > >   (void)sizeof(i);
> > > }
> > > ```
> > > I don't think diagnosing this test case is correct.
> > I see some value to maybe diagnosing *something* here. For example, `[] { 
> > return sizeof(i); }` would produce the same result as `[i] { return 
> > sizeof(i); }` but with one fewer capture, so removing the `i` might be seen 
> > as an improvement.
> > 
> > But I'm not sure how to convey this information to the user. You could say 
> > "variable `i` used in unevaluated context refers to the `i` in the outer 
> > scope, not the captured `i`"... except that I think that would be false. 
> > Given that you *have* captured an `i`, `sizeof(i)` definitely refers to the 
> > captured one AFAIK. The fact that the captured `i` shadows an `i` in the 
> > outer scope is irrelevant --- in fact the user is *expecting* to shadow the 
> > outer `i`.
> > 
> > Perhaps it would be appropriate to reword the diagnostic to "lambda 
> > captures variable `i` unnecessarily".  I would also lean toward splitting 
> > it into two diagnostics — one for "this capture is unnecessary" (as in this 
> > example) and one for "this capture doesn't even appear lexically in the 
> > body of the lambda". Not sure how other people would feel about that.
> > 
> > You should add some test cases with `decltype(i)` for the same reason as 
> > `sizeof(i)`.
> Does "lambda capture 'i' is not odr-used" make more sense?
> Does "lambda capture 'i' is not odr-used" make more sense?

That would completely satisfy *me*, for what that's worth. It admittedly 
doesn't match the other -Wunused diagnostics, but it is concise and correct — 
at least I assume it's correct. :)


https://reviews.llvm.org/D28467



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


[PATCH] D28148: [Sema] Suppress warnings for C's zero initializer

2017-01-11 Thread Daniel Marjamäki via Phabricator via cfe-commits
danielmarjamaki accepted this revision.
danielmarjamaki added a reviewer: danielmarjamaki.
danielmarjamaki added a comment.
This revision is now accepted and ready to land.

LGTM


https://reviews.llvm.org/D28148



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


[PATCH] D28399: PR31469: Don't add friend template class decls to redecl chain in dependent contexts.

2017-01-11 Thread Vassil Vassilev via Phabricator via cfe-commits
v.g.vassilev removed rL LLVM as the repository for this revision.
v.g.vassilev updated this revision to Diff 83936.
v.g.vassilev marked an inline comment as done.
v.g.vassilev added a comment.

Address comments.


https://reviews.llvm.org/D28399

Files:
  include/clang/AST/DeclTemplate.h
  lib/AST/ASTImporter.cpp
  lib/AST/DeclTemplate.cpp
  lib/Sema/SemaTemplate.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  test/Misc/ast-dump-decl.cpp
  test/Modules/Inputs/PR31469/empty.h
  test/Modules/Inputs/PR31469/module.modulemap
  test/Modules/Inputs/PR31469/textual.h
  test/Modules/Inputs/PR31469/textual_file_shadow.h
  test/Modules/pr31469.cpp

Index: test/Modules/pr31469.cpp
===
--- /dev/null
+++ test/Modules/pr31469.cpp
@@ -0,0 +1,15 @@
+// RUN: rm -rf %t
+// RUN: %clang_cc1 -std=c++11 -I%S/Inputs/PR31469 -verify %s
+// RUN: %clang_cc1 -std=c++11 -I%S/Inputs/PR31469 -fmodules -fmodules-local-submodule-visibility \
+// RUN:-fimplicit-module-maps -fmodules-cache-path=%t  -verify %s
+
+#include "textual.h"
+#include "empty.h"
+
+namespace A {
+  template  void f();
+}
+
+A::list use;
+
+// expected-no-diagnostics
Index: test/Modules/Inputs/PR31469/textual_file_shadow.h
===
--- /dev/null
+++ test/Modules/Inputs/PR31469/textual_file_shadow.h
@@ -0,0 +1,2 @@
+#include "textual.h"
+
Index: test/Modules/Inputs/PR31469/textual.h
===
--- /dev/null
+++ test/Modules/Inputs/PR31469/textual.h
@@ -0,0 +1,17 @@
+namespace A {
+inline
+namespace __1 {
+  template  class allocator;
+  template > class list;
+  template  class __list_iterator {
+//template  friend class list; // causes another crash in ASTDeclReader::attachPreviousDecl
+template  friend class list;
+  };
+  template  class __list_imp {};
+  template  class list : __list_imp<_Tp, _Alloc> {
+  public:
+list() {}
+  };
+  template  void f(list<_Tp>);
+}
+}
Index: test/Modules/Inputs/PR31469/module.modulemap
===
--- /dev/null
+++ test/Modules/Inputs/PR31469/module.modulemap
@@ -0,0 +1,5 @@
+module M {
+  module "textual_shadow" { header "textual_file_shadow.h" export *}
+  module "trigger" { header "empty.h" export * }
+  export *
+}
Index: test/Modules/Inputs/PR31469/empty.h
===
--- /dev/null
+++ test/Modules/Inputs/PR31469/empty.h
@@ -0,0 +1 @@
+// This file is triggers loading of module M.
Index: test/Misc/ast-dump-decl.cpp
===
--- test/Misc/ast-dump-decl.cpp
+++ test/Misc/ast-dump-decl.cpp
@@ -336,7 +336,6 @@
   // CHECK-NEXT:   ClassTemplateDecl{{.*}} TestClassTemplate
   // CHECK-NEXT: TemplateTypeParmDecl
   // CHECK-NEXT: CXXRecordDecl{{.*}} class TestClassTemplate
-  // CHECK-NEXT: ClassTemplateSpecialization{{.*}} 'TestClassTemplate'
   // CHECK-NEXT:   ClassTemplateSpecializationDecl{{.*}} class TestClassTemplate
   // CHECK-NEXT: TemplateArgument{{.*}}A
   // CHECK-NEXT: CXXRecordDecl{{.*}} class TestClassTemplate
Index: lib/Sema/SemaTemplateInstantiateDecl.cpp
===
--- lib/Sema/SemaTemplateInstantiateDecl.cpp
+++ lib/Sema/SemaTemplateInstantiateDecl.cpp
@@ -1193,8 +1193,10 @@
 
   ClassTemplateDecl *Inst
 = ClassTemplateDecl::Create(SemaRef.Context, DC, D->getLocation(),
-D->getIdentifier(), InstParams, RecordInst,
-PrevClassTemplate);
+D->getIdentifier(), InstParams, RecordInst);
+  assert(!(isFriend && Owner->isDependentContext()));
+  Inst->setPreviousDecl(PrevClassTemplate);
+
   RecordInst->setDescribedClassTemplate(Inst);
 
   if (isFriend) {
Index: lib/Sema/SemaTemplate.cpp
===
--- lib/Sema/SemaTemplate.cpp
+++ lib/Sema/SemaTemplate.cpp
@@ -1224,9 +1224,17 @@
 }
   }
 
+  // If this is a templated friend in a dependent context we should not put it
+  // on the redecl chain. In some cases, the templated friend can be the most
+  // recent declaration tricking the template instantiator to make substitutions
+  // there.
+  // FIXME: Figure out how to combine with shouldLinkDependentDeclWithPrevious
+  bool ShouldAddRedecl
+= !(TUK == TUK_Friend && CurContext->isDependentContext());
+
   CXXRecordDecl *NewClass =
 CXXRecordDecl::Create(Context, Kind, SemanticContext, KWLoc, NameLoc, Name,
-  PrevClassTemplate?
+  PrevClassTemplate && ShouldAddRedecl ?
 PrevClassTemplate->getTemplatedDecl() : nullptr,
   /*DelayTypeCreation=*/true);
   SetNestedNameSpecifier(NewClass, SS);
@@ -1245,7 +1253

[PATCH] D28467: [Sema] Add warning for unused lambda captures

2017-01-11 Thread Malcolm Parsons via Phabricator via cfe-commits
malcolm.parsons added inline comments.



Comment at: test/SemaCXX/warn-unused-lambda-capture.cpp:17
+  auto explicit_by_value_unused = [i] {}; // expected-warning{{lambda capture 
'i' is not used}}
+  auto explicit_by_value_unused_sizeof = [i] { return sizeof(i); }; // 
expected-warning{{lambda capture 'i' is not used}}
+

Quuxplusone wrote:
> malcolm.parsons wrote:
> > Quuxplusone wrote:
> > > aaron.ballman wrote:
> > > > This does not match the behavior for other -Wunused flags. e.g.,
> > > > ```
> > > > void f() {
> > > >   int i;
> > > >   (void)sizeof(i);
> > > > }
> > > > ```
> > > > I don't think diagnosing this test case is correct.
> > > I see some value to maybe diagnosing *something* here. For example, `[] { 
> > > return sizeof(i); }` would produce the same result as `[i] { return 
> > > sizeof(i); }` but with one fewer capture, so removing the `i` might be 
> > > seen as an improvement.
> > > 
> > > But I'm not sure how to convey this information to the user. You could 
> > > say "variable `i` used in unevaluated context refers to the `i` in the 
> > > outer scope, not the captured `i`"... except that I think that would be 
> > > false. Given that you *have* captured an `i`, `sizeof(i)` definitely 
> > > refers to the captured one AFAIK. The fact that the captured `i` shadows 
> > > an `i` in the outer scope is irrelevant --- in fact the user is 
> > > *expecting* to shadow the outer `i`.
> > > 
> > > Perhaps it would be appropriate to reword the diagnostic to "lambda 
> > > captures variable `i` unnecessarily".  I would also lean toward splitting 
> > > it into two diagnostics — one for "this capture is unnecessary" (as in 
> > > this example) and one for "this capture doesn't even appear lexically in 
> > > the body of the lambda". Not sure how other people would feel about that.
> > > 
> > > You should add some test cases with `decltype(i)` for the same reason as 
> > > `sizeof(i)`.
> > Does "lambda capture 'i' is not odr-used" make more sense?
> > Does "lambda capture 'i' is not odr-used" make more sense?
> 
> That would completely satisfy *me*, for what that's worth. It admittedly 
> doesn't match the other -Wunused diagnostics, but it is concise and correct — 
> at least I assume it's correct. :)
C++14 [expr.prim.lambda]p18:

> [ Note: An id-expression that is not an odr-use refers to the original 
> entity, never to a member
> of the closure type. Furthermore, such an id-expression does not cause the 
> implicit capture of the entity.
> — end note ]


https://reviews.llvm.org/D28467



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


[PATCH] D28399: PR31469: Don't add friend template class decls to redecl chain in dependent contexts.

2017-01-11 Thread Vassil Vassilev via Phabricator via cfe-commits
v.g.vassilev added a comment.

@yaron.keren, it seems that  http://llvm.org/pr30994 concerns friend function 
declarations. My current patch focuses on friend class templates. Perhaps we 
should open another review item for a fix of http://llvm.org/pr30994.


https://reviews.llvm.org/D28399



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


[PATCH] D27920: [find-all-symbols] Index partial template specializations.

2017-01-11 Thread Benjamin Kramer via Phabricator via cfe-commits
bkramer accepted this revision.
bkramer added a comment.
This revision is now accepted and ready to land.

The reason why we disallowed specializations is that there are type-trait 
classes that get specialized all over the place (DenseMapInfo in LLVM is one 
example). I think we can get away with allowing partial specializations though. 
Those should be much less common and we can give the user a choice between the 
headers that contain them.




Comment at: include-fixer/find-all-symbols/FindAllSymbols.cpp:39
+  if (Node.getTemplateSpecializationKind() == TSK_ExplicitSpecialization) {
+bool is_partial_specialization =
+llvm::isa(Node) ||

PascalCase for variable names.


https://reviews.llvm.org/D27920



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


[PATCH] D26082: Support for Python 3 in libclang python bindings

2017-01-11 Thread Jonathan B Coe via Phabricator via cfe-commits
jbcoe added a comment.

@MathieuDuponchelle I'm still keen to get to the bottom of this failure. I've 
not had time to reproduce it yet.

I'm thankful for you taking a look at this and reporting the issue. We need to 
get this working well for everyone.


Repository:
  rL LLVM

https://reviews.llvm.org/D26082



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


[PATCH] D28235: [clang-format cleanup] merge continuous deleted lines into one deletion.

2017-01-11 Thread Eric Liu via Phabricator via cfe-commits
ioeric added a comment.

post-vacation ping :)


https://reviews.llvm.org/D28235



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


[clang-tools-extra] r291664 - Improve include fixer's ranking by taking the paths into account.

2017-01-11 Thread Manuel Klimek via cfe-commits
Author: klimek
Date: Wed Jan 11 04:32:47 2017
New Revision: 291664

URL: http://llvm.org/viewvc/llvm-project?rev=291664&view=rev
Log:
Improve include fixer's ranking by taking the paths into account.

Instead of just using popularity, we also take into account how similar the
path of the current file is to the path of the header.
Our first approach is to get popularity into a reasonably small scale by taking
log2 (which is roughly intuitive to how humans would bucket popularity), and
multiply that with the number of matching prefix path fragments of the included
header with the current file.
Note that currently we do not take special care for unclean paths containing
"../" or "./".

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

Modified:
clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp
clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp
clang-tools-extra/trunk/include-fixer/SymbolIndexManager.h
clang-tools-extra/trunk/include-fixer/tool/ClangIncludeFixer.cpp
clang-tools-extra/trunk/test/include-fixer/Inputs/fake_yaml_db.yaml
clang-tools-extra/trunk/test/include-fixer/ranking.cpp

Modified: clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp?rev=291664&r1=291663&r2=291664&view=diff
==
--- clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp (original)
+++ clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp Wed Jan 11 04:32:47 
2017
@@ -365,6 +365,9 @@ IncludeFixerSemaSource::query(StringRef
 .getLocWithOffset(Range.getOffset())
 .print(llvm::dbgs(), CI->getSourceManager()));
   DEBUG(llvm::dbgs() << " ...");
+  llvm::StringRef FileName = CI->getSourceManager().getFilename(
+  CI->getSourceManager().getLocForStartOfFile(
+  CI->getSourceManager().getMainFileID()));
 
   QuerySymbolInfos.push_back({Query.str(), ScopedQualifiers, Range});
 
@@ -385,9 +388,10 @@ IncludeFixerSemaSource::query(StringRef
   // context, it might treat the identifier as a nested class of the scoped
   // namespace.
   std::vector MatchedSymbols =
-  SymbolIndexMgr.search(QueryString, /*IsNestedSearch=*/false);
+  SymbolIndexMgr.search(QueryString, /*IsNestedSearch=*/false, FileName);
   if (MatchedSymbols.empty())
-MatchedSymbols = SymbolIndexMgr.search(Query);
+MatchedSymbols =
+SymbolIndexMgr.search(Query, /*IsNestedSearch=*/true, FileName);
   DEBUG(llvm::dbgs() << "Having found " << MatchedSymbols.size()
  << " symbols\n");
   // We store a copy of MatchedSymbols in a place where it's globally 
reachable.

Modified: clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp?rev=291664&r1=291663&r2=291664&view=diff
==
--- clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp (original)
+++ clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp Wed Jan 11 
04:32:47 2017
@@ -12,6 +12,7 @@
 #include "llvm/ADT/DenseMap.h"
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/Support/Debug.h"
+#include "llvm/Support/Path.h"
 
 #define DEBUG_TYPE "include-fixer"
 
@@ -20,30 +21,57 @@ namespace include_fixer {
 
 using clang::find_all_symbols::SymbolInfo;
 
-/// Sorts SymbolInfos based on the popularity info in SymbolInfo.
-static void rankByPopularity(std::vector &Symbols) {
-  // First collect occurrences per header file.
-  llvm::DenseMap HeaderPopularity;
-  for (const SymbolInfo &Symbol : Symbols) {
-unsigned &Popularity = HeaderPopularity[Symbol.getFilePath()];
-Popularity = std::max(Popularity, Symbol.getNumOccurrences());
+// Calculate a score based on whether we think the given header is closely
+// related to the given source file.
+static double similarityScore(llvm::StringRef FileName,
+  llvm::StringRef Header) {
+  // Compute the maximum number of common path segements between Header and
+  // a suffix of FileName.
+  // We do not do a full longest common substring computation, as Header
+  // specifies the path we would directly #include, so we assume it is rooted
+  // relatively to a subproject of the repository.
+  int MaxSegments = 1;
+  for (auto FileI = llvm::sys::path::begin(FileName),
+FileE = llvm::sys::path::end(FileName);
+   FileI != FileE; ++FileI) {
+int Segments = 0;
+for (auto HeaderI = llvm::sys::path::begin(Header),
+  HeaderE = llvm::sys::path::end(Header), I = FileI;
+ HeaderI != HeaderE && *I == *HeaderI && I != FileE; ++I, ++HeaderI) {
+  ++Segments;
+}
+MaxSegments = std::max(Segments, MaxSegments);
   }
+  return MaxSegments;
+}
 
-  // Sort by the gathered popularities. Use file name as a tie breaker so we 
can
+sta

[PATCH] D28548: Improve include fixer's ranking by taking the paths into account.

2017-01-11 Thread Manuel Klimek via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL291664: Improve include fixer's ranking by taking the paths 
into account. (authored by klimek).

Changed prior to commit:
  https://reviews.llvm.org/D28548?vs=83930&id=83937#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D28548

Files:
  clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp
  clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp
  clang-tools-extra/trunk/include-fixer/SymbolIndexManager.h
  clang-tools-extra/trunk/include-fixer/tool/ClangIncludeFixer.cpp
  clang-tools-extra/trunk/test/include-fixer/Inputs/fake_yaml_db.yaml
  clang-tools-extra/trunk/test/include-fixer/ranking.cpp

Index: clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp
===
--- clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp
+++ clang-tools-extra/trunk/include-fixer/IncludeFixer.cpp
@@ -365,6 +365,9 @@
 .getLocWithOffset(Range.getOffset())
 .print(llvm::dbgs(), CI->getSourceManager()));
   DEBUG(llvm::dbgs() << " ...");
+  llvm::StringRef FileName = CI->getSourceManager().getFilename(
+  CI->getSourceManager().getLocForStartOfFile(
+  CI->getSourceManager().getMainFileID()));
 
   QuerySymbolInfos.push_back({Query.str(), ScopedQualifiers, Range});
 
@@ -385,9 +388,10 @@
   // context, it might treat the identifier as a nested class of the scoped
   // namespace.
   std::vector MatchedSymbols =
-  SymbolIndexMgr.search(QueryString, /*IsNestedSearch=*/false);
+  SymbolIndexMgr.search(QueryString, /*IsNestedSearch=*/false, FileName);
   if (MatchedSymbols.empty())
-MatchedSymbols = SymbolIndexMgr.search(Query);
+MatchedSymbols =
+SymbolIndexMgr.search(Query, /*IsNestedSearch=*/true, FileName);
   DEBUG(llvm::dbgs() << "Having found " << MatchedSymbols.size()
  << " symbols\n");
   // We store a copy of MatchedSymbols in a place where it's globally reachable.
Index: clang-tools-extra/trunk/include-fixer/SymbolIndexManager.h
===
--- clang-tools-extra/trunk/include-fixer/SymbolIndexManager.h
+++ clang-tools-extra/trunk/include-fixer/SymbolIndexManager.h
@@ -42,7 +42,8 @@
   ///
   /// \returns A list of symbol candidates.
   std::vector
-  search(llvm::StringRef Identifier, bool IsNestedSearch = true) const;
+  search(llvm::StringRef Identifier, bool IsNestedSearch = true,
+ llvm::StringRef FileName = "") const;
 
 private:
   std::vector>> SymbolIndices;
Index: clang-tools-extra/trunk/include-fixer/tool/ClangIncludeFixer.cpp
===
--- clang-tools-extra/trunk/include-fixer/tool/ClangIncludeFixer.cpp
+++ clang-tools-extra/trunk/include-fixer/tool/ClangIncludeFixer.cpp
@@ -332,7 +332,8 @@
 
   // Query symbol mode.
   if (!QuerySymbol.empty()) {
-auto MatchedSymbols = SymbolIndexMgr->search(QuerySymbol);
+auto MatchedSymbols = SymbolIndexMgr->search(
+QuerySymbol, /*IsNestedSearch=*/true, SourceFilePath);
 for (auto &Symbol : MatchedSymbols) {
   std::string HeaderPath = Symbol.getFilePath().str();
   Symbol.SetFilePath(((HeaderPath[0] == '"' || HeaderPath[0] == '<')
Index: clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp
===
--- clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp
+++ clang-tools-extra/trunk/include-fixer/SymbolIndexManager.cpp
@@ -12,38 +12,66 @@
 #include "llvm/ADT/DenseMap.h"
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/Support/Debug.h"
+#include "llvm/Support/Path.h"
 
 #define DEBUG_TYPE "include-fixer"
 
 namespace clang {
 namespace include_fixer {
 
 using clang::find_all_symbols::SymbolInfo;
 
-/// Sorts SymbolInfos based on the popularity info in SymbolInfo.
-static void rankByPopularity(std::vector &Symbols) {
-  // First collect occurrences per header file.
-  llvm::DenseMap HeaderPopularity;
-  for (const SymbolInfo &Symbol : Symbols) {
-unsigned &Popularity = HeaderPopularity[Symbol.getFilePath()];
-Popularity = std::max(Popularity, Symbol.getNumOccurrences());
+// Calculate a score based on whether we think the given header is closely
+// related to the given source file.
+static double similarityScore(llvm::StringRef FileName,
+  llvm::StringRef Header) {
+  // Compute the maximum number of common path segements between Header and
+  // a suffix of FileName.
+  // We do not do a full longest common substring computation, as Header
+  // specifies the path we would directly #include, so we assume it is rooted
+  // relatively to a subproject of the repository.
+  int MaxSegments = 1;
+  for (auto FileI = llvm::sys::path::begin(FileName),
+FileE = llvm::sys::path::end(FileName);
+   FileI != FileE; ++FileI) {
+int Segments = 0;
+for (a

[PATCH] D28365: [Driver] Updated for Visual Studio 2017

2017-01-11 Thread Hamza Sood via Phabricator via cfe-commits
hamzasood updated this revision to Diff 83941.
hamzasood added a comment.

- Rephrased the diagnostic message (and fixed an embarrassing typo).
- Reverted the linker environment change for now; building for x86 with VS2017 
won't work in the meantime. I'll submit it for review separately after this one 
has (hopefully) been accepted, as it relies on a few functions introduced in 
this patch.


https://reviews.llvm.org/D28365

Files:
  include/clang/Basic/DiagnosticDriverKinds.td
  lib/Driver/MSVCToolChain.cpp
  lib/Driver/ToolChains.h
  lib/Driver/Tools.cpp

Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -10807,19 +10807,12 @@
 // making sure that whatever executable that's found is not a same-named exe
 // from clang itself to prevent clang from falling back to itself.
 static std::string FindVisualStudioExecutable(const ToolChain &TC,
-  const char *Exe,
-  const char *ClangProgramPath) {
+  const char *Exe) {
   const auto &MSVC = static_cast(TC);
-  std::string visualStudioBinDir;
-  if (MSVC.getVisualStudioBinariesFolder(ClangProgramPath,
- visualStudioBinDir)) {
-SmallString<128> FilePath(visualStudioBinDir);
-llvm::sys::path::append(FilePath, Exe);
-if (llvm::sys::fs::can_execute(FilePath.c_str()))
-  return FilePath.str();
-  }
-
-  return Exe;
+  SmallString<128> FilePath(MSVC.getSubDirectoryPath(toolchains::MSVCToolChain
+ ::SubDirectoryType::Bin));
+  llvm::sys::path::append(FilePath, Exe);
+  return (llvm::sys::fs::can_execute(FilePath) ? FilePath.str() : Exe);
 }
 
 void visualstudio::Linker::ConstructJob(Compilation &C, const JobAction &JA,
@@ -10828,7 +10821,7 @@
 const ArgList &Args,
 const char *LinkingOutput) const {
   ArgStringList CmdArgs;
-  const ToolChain &TC = getToolChain();
+  auto &TC = static_cast(getToolChain());
 
   assert((Output.isFilename() || Output.isNothing()) && "invalid output");
   if (Output.isFilename())
@@ -10844,37 +10837,20 @@
 // did not run vcvarsall), try to build a consistent link environment.  If
 // the environment variable is set however, assume the user knows what
 // they're doing.
-std::string VisualStudioDir;
-const auto &MSVC = static_cast(TC);
-if (MSVC.getVisualStudioInstallDir(VisualStudioDir)) {
-  SmallString<128> LibDir(VisualStudioDir);
-  llvm::sys::path::append(LibDir, "VC", "lib");
-  switch (MSVC.getArch()) {
-  case llvm::Triple::x86:
-// x86 just puts the libraries directly in lib
-break;
-  case llvm::Triple::x86_64:
-llvm::sys::path::append(LibDir, "amd64");
-break;
-  case llvm::Triple::arm:
-llvm::sys::path::append(LibDir, "arm");
-break;
-  default:
-break;
-  }
-  CmdArgs.push_back(
-  Args.MakeArgString(std::string("-libpath:") + LibDir.c_str()));
+CmdArgs.push_back(Args.MakeArgString(
+  std::string("-libpath:")
+  + TC.getSubDirectoryPath(toolchains::MSVCToolChain
+   ::SubDirectoryType::Lib)));
 
-  if (MSVC.useUniversalCRT(VisualStudioDir)) {
-std::string UniversalCRTLibPath;
-if (MSVC.getUniversalCRTLibraryPath(UniversalCRTLibPath))
-  CmdArgs.push_back(Args.MakeArgString(std::string("-libpath:") +
-   UniversalCRTLibPath));
-  }
+if (TC.useUniversalCRT()) {
+  std::string UniversalCRTLibPath;
+  if (TC.getUniversalCRTLibraryPath(UniversalCRTLibPath))
+CmdArgs.push_back(Args.MakeArgString(std::string("-libpath:")
+ + UniversalCRTLibPath));
 }
 
 std::string WindowsSdkLibPath;
-if (MSVC.getWindowsSDKLibraryPath(WindowsSdkLibPath))
+if (TC.getWindowsSDKLibraryPath(WindowsSdkLibPath))
   CmdArgs.push_back(
   Args.MakeArgString(std::string("-libpath:") + WindowsSdkLibPath));
   }
@@ -10989,8 +10965,7 @@
 // If we're using the MSVC linker, it's not sufficient to just use link
 // from the program PATH, because other environments like GnuWin32 install
 // their own link.exe which may come first.
-linkPath = FindVisualStudioExecutable(TC, "link.exe",
-  C.getDriver().getClangProgramPath());
+linkPath = FindVisualStudioExecutable(TC, "link.exe");
   } else {
 linkPath = Linker;
 llvm::sys::path::replace_extension(linkPath, "exe");
@@ -11123,9 +11098,7 @@
   Args.MakeArgString(std::string("/Fo") + Output.getFilename());
   CmdArgs.push_back(Fo);
 
-  const Driver 

[PATCH] D28467: [Sema] Add warning for unused lambda captures

2017-01-11 Thread Malcolm Parsons via Phabricator via cfe-commits
malcolm.parsons updated this revision to Diff 83942.
malcolm.parsons marked 9 inline comments as done.
malcolm.parsons added a comment.

Change warning message.
Check for side effects.
Add tests for side effects.
Add tests for decltype.
Use const reference.
Add . to comment.
Remove unrelated comment fix.


https://reviews.llvm.org/D28467

Files:
  include/clang/Basic/DiagnosticGroups.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Sema/ScopeInfo.h
  include/clang/Sema/Sema.h
  lib/Sema/SemaExpr.cpp
  lib/Sema/SemaExprCXX.cpp
  lib/Sema/SemaLambda.cpp
  test/CXX/expr/expr.prim/expr.prim.lambda/p12.cpp
  test/CXX/expr/expr.prim/expr.prim.lambda/p13.cpp
  test/CXX/expr/expr.prim/expr.prim.lambda/p16.cpp
  test/CXX/expr/expr.prim/expr.prim.lambda/p18.cpp
  test/CXX/expr/expr.prim/expr.prim.lambda/p19.cpp
  test/SemaCXX/uninitialized.cpp
  test/SemaCXX/warn-unused-lambda-capture.cpp

Index: test/SemaCXX/warn-unused-lambda-capture.cpp
===
--- /dev/null
+++ test/SemaCXX/warn-unused-lambda-capture.cpp
@@ -0,0 +1,110 @@
+// RUN: %clang_cc1 -fsyntax-only -Wunused-lambda-capture -Wused-but-marked-unused -Wno-uninitialized -verify -std=c++14 %s
+
+class NonTrivialConstructor {
+public:
+  NonTrivialConstructor() {}
+};
+
+class NonTrivialDestructor {
+public:
+  ~NonTrivialDestructor() {}
+};
+
+class Trivial {
+public:
+  Trivial() = default;
+  Trivial(int a) {}
+};
+
+int side_effect() {
+  return 42;
+}
+
+void test() {
+  int i = 0;
+
+  auto captures_nothing = [] {};
+
+  auto captures_nothing_by_value = [=] {};
+  auto captures_nothing_by_reference = [&] {};
+
+  auto implicit_by_value = [=]() mutable { i++; };
+  auto implicit_by_reference = [&] { i++; };
+
+  auto explicit_by_value_used = [i] { return i + 1; };
+  auto explicit_by_value_used_void = [i] { (void)i; };
+  auto explicit_by_value_unused = [i] {}; // expected-warning{{lambda capture 'i' is not odr-used}}
+  auto explicit_by_value_unused_sizeof = [i] { return sizeof(i); }; // expected-warning{{lambda capture 'i' is not odr-used}}
+  auto explicit_by_value_unused_decltype = [i] { decltype(i) j = 0; }; // expected-warning{{lambda capture 'i' is not odr-used}}
+
+  auto explicit_by_reference_used = [&i] { i++; };
+  auto explicit_by_reference_unused = [&i] {}; // expected-warning{{lambda capture 'i' is not odr-used}}
+
+  auto explicit_initialized_reference_used = [&j = i] { return j + 1; };
+  auto explicit_initialized_reference_unused = [&j = i]{}; // expected-warning{{lambda capture 'j' is not odr-used}}
+
+  auto explicit_initialized_value_used = [j = 1] { return j + 1; };
+  auto explicit_initialized_value_unused = [j = 1] {}; // expected-warning{{lambda capture 'j' is not odr-used}}
+  auto explicit_initialized_value_non_trivial_constructor = [j = NonTrivialConstructor()]{};
+  auto explicit_initialized_value_non_trivial_destructor = [j = NonTrivialDestructor()]{};
+  auto explicit_initialized_value_trivial_init = [j = Trivial()]{}; // expected-warning{{lambda capture 'j' is not odr-used}}
+  auto explicit_initialized_value_non_trivial_init = [j = Trivial(42)]{};
+  auto explicit_initialized_value_with_side_effect = [j = side_effect()]{};
+
+  auto nested = [&i] {
+auto explicit_by_value_used = [i] { return i + 1; };
+auto explicit_by_value_unused = [i] {}; // expected-warning{{lambda capture 'i' is not odr-used}}
+  };
+}
+
+class Foo
+{
+  void test() {
+auto explicit_this_used = [this] { return i; };
+auto explicit_this_used_void = [this] { (void)this; };
+auto explicit_this_unused = [this] {}; // expected-warning{{lambda capture 'this' is not odr-used}}
+  }
+  int i;
+};
+
+template 
+void test_templated() {
+  int i = 0;
+
+  auto captures_nothing = [] {};
+
+  auto captures_nothing_by_value = [=] {};
+  auto captures_nothing_by_reference = [&] {};
+
+  auto implicit_by_value = [=]() mutable { i++; };
+  auto implicit_by_reference = [&] { i++; };
+
+  auto explicit_by_value_used = [i] { return i + 1; };
+  auto explicit_by_value_used_void = [i] { (void)i; };
+  auto explicit_by_value_unused = [i] {}; // expected-warning{{lambda capture 'i' is not odr-used}}
+  auto explicit_by_value_unused_sizeof = [i] { return sizeof(i); }; // expected-warning{{lambda capture 'i' is not odr-used}}
+  auto explicit_by_value_unused_decltype = [i] { decltype(i) j = 0; }; // expected-warning{{lambda capture 'i' is not odr-used}}
+
+  auto explicit_by_reference_used = [&i] { i++; };
+  auto explicit_by_reference_unused = [&i] {}; // expected-warning{{lambda capture 'i' is not odr-used}}
+
+  auto explicit_initialized_reference_used = [&j = i] { return j + 1; };
+  auto explicit_initialized_reference_unused = [&j = i]{}; // expected-warning{{lambda capture 'j' is not odr-used}}
+
+  auto explicit_initialized_value_used = [j = 1] { return j + 1; };
+  auto explicit_initialized_value_unused = [j = 1] {}; // expected-warning{{lambda capture 'j' is not odr-used}}
+  a

[PATCH] D28365: [Driver] Updated for Visual Studio 2017

2017-01-11 Thread Hamza Sood via Phabricator via cfe-commits
hamzasood updated this revision to Diff 83943.
hamzasood added a comment.

Uploaded the correct diff this time (yes, really)...
Not sure how to delete the previous one, but it's very incorrect.


https://reviews.llvm.org/D28365

Files:
  include/clang/Basic/DiagnosticDriverKinds.td
  lib/Driver/MSVCToolChain.cpp
  lib/Driver/ToolChains.h
  lib/Driver/Tools.cpp

Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -10807,19 +10807,12 @@
 // making sure that whatever executable that's found is not a same-named exe
 // from clang itself to prevent clang from falling back to itself.
 static std::string FindVisualStudioExecutable(const ToolChain &TC,
-  const char *Exe,
-  const char *ClangProgramPath) {
+  const char *Exe) {
   const auto &MSVC = static_cast(TC);
-  std::string visualStudioBinDir;
-  if (MSVC.getVisualStudioBinariesFolder(ClangProgramPath,
- visualStudioBinDir)) {
-SmallString<128> FilePath(visualStudioBinDir);
-llvm::sys::path::append(FilePath, Exe);
-if (llvm::sys::fs::can_execute(FilePath.c_str()))
-  return FilePath.str();
-  }
-
-  return Exe;
+  SmallString<128> FilePath(MSVC.getSubDirectoryPath(toolchains::MSVCToolChain
+ ::SubDirectoryType::Bin));
+  llvm::sys::path::append(FilePath, Exe);
+  return (llvm::sys::fs::can_execute(FilePath) ? FilePath.str() : Exe);
 }
 
 void visualstudio::Linker::ConstructJob(Compilation &C, const JobAction &JA,
@@ -10828,7 +10821,7 @@
 const ArgList &Args,
 const char *LinkingOutput) const {
   ArgStringList CmdArgs;
-  const ToolChain &TC = getToolChain();
+  auto &TC = static_cast(getToolChain());
 
   assert((Output.isFilename() || Output.isNothing()) && "invalid output");
   if (Output.isFilename())
@@ -10844,37 +10837,20 @@
 // did not run vcvarsall), try to build a consistent link environment.  If
 // the environment variable is set however, assume the user knows what
 // they're doing.
-std::string VisualStudioDir;
-const auto &MSVC = static_cast(TC);
-if (MSVC.getVisualStudioInstallDir(VisualStudioDir)) {
-  SmallString<128> LibDir(VisualStudioDir);
-  llvm::sys::path::append(LibDir, "VC", "lib");
-  switch (MSVC.getArch()) {
-  case llvm::Triple::x86:
-// x86 just puts the libraries directly in lib
-break;
-  case llvm::Triple::x86_64:
-llvm::sys::path::append(LibDir, "amd64");
-break;
-  case llvm::Triple::arm:
-llvm::sys::path::append(LibDir, "arm");
-break;
-  default:
-break;
-  }
-  CmdArgs.push_back(
-  Args.MakeArgString(std::string("-libpath:") + LibDir.c_str()));
+CmdArgs.push_back(Args.MakeArgString(
+  std::string("-libpath:")
+  + TC.getSubDirectoryPath(toolchains::MSVCToolChain
+   ::SubDirectoryType::Lib)));
 
-  if (MSVC.useUniversalCRT(VisualStudioDir)) {
-std::string UniversalCRTLibPath;
-if (MSVC.getUniversalCRTLibraryPath(UniversalCRTLibPath))
-  CmdArgs.push_back(Args.MakeArgString(std::string("-libpath:") +
-   UniversalCRTLibPath));
-  }
+if (TC.useUniversalCRT()) {
+  std::string UniversalCRTLibPath;
+  if (TC.getUniversalCRTLibraryPath(UniversalCRTLibPath))
+CmdArgs.push_back(Args.MakeArgString(std::string("-libpath:")
+ + UniversalCRTLibPath));
 }
 
 std::string WindowsSdkLibPath;
-if (MSVC.getWindowsSDKLibraryPath(WindowsSdkLibPath))
+if (TC.getWindowsSDKLibraryPath(WindowsSdkLibPath))
   CmdArgs.push_back(
   Args.MakeArgString(std::string("-libpath:") + WindowsSdkLibPath));
   }
@@ -10989,8 +10965,7 @@
 // If we're using the MSVC linker, it's not sufficient to just use link
 // from the program PATH, because other environments like GnuWin32 install
 // their own link.exe which may come first.
-linkPath = FindVisualStudioExecutable(TC, "link.exe",
-  C.getDriver().getClangProgramPath());
+linkPath = FindVisualStudioExecutable(TC, "link.exe");
   } else {
 linkPath = Linker;
 llvm::sys::path::replace_extension(linkPath, "exe");
@@ -11123,9 +11098,7 @@
   Args.MakeArgString(std::string("/Fo") + Output.getFilename());
   CmdArgs.push_back(Fo);
 
-  const Driver &D = getToolChain().getDriver();
-  std::string Exec = FindVisualStudioExecutable(getToolChain(), "cl.exe",
-D.getClangProgramPath());
+  std::string Exe

[PATCH] D28297: [StaticAnalyzer] Fix crash in CastToStructChecker

2017-01-11 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a subscriber: zaks.anna.
NoQ added a comment.

Looks good. I assume the crash is in `getTypeInfo()`; do you have any idea what 
are exact prerequisites for using this method? So that there were no more 
crashes here.


Repository:
  rL LLVM

https://reviews.llvm.org/D28297



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


r291667 - Remove repeated word in comment (NFC)

2017-01-11 Thread Malcolm Parsons via cfe-commits
Author: malcolm.parsons
Date: Wed Jan 11 05:23:22 2017
New Revision: 291667

URL: http://llvm.org/viewvc/llvm-project?rev=291667&view=rev
Log:
Remove repeated word in comment (NFC)

Modified:
cfe/trunk/lib/Parse/ParseExprCXX.cpp

Modified: cfe/trunk/lib/Parse/ParseExprCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseExprCXX.cpp?rev=291667&r1=291666&r2=291667&view=diff
==
--- cfe/trunk/lib/Parse/ParseExprCXX.cpp (original)
+++ cfe/trunk/lib/Parse/ParseExprCXX.cpp Wed Jan 11 05:23:22 2017
@@ -735,7 +735,7 @@ ExprResult Parser::TryParseLambdaExpress
 ///sometimes skip the initializers for init-captures and not fully
 ///populate \p Intro. This flag will be set to \c true if we do so.
 /// \return A DiagnosticID if it hit something unexpected. The location for
-/// for the diagnostic is that of the current token.
+/// the diagnostic is that of the current token.
 Optional Parser::ParseLambdaIntroducer(LambdaIntroducer &Intro,
  bool *SkippedInits) {
   typedef Optional DiagResult;


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


[PATCH] D27920: [find-all-symbols] Index partial template specializations.

2017-01-11 Thread Haojian Wu via Phabricator via cfe-commits
hokein updated this revision to Diff 83944.
hokein marked an inline comment as done.
hokein added a comment.

Fix code style nit.


https://reviews.llvm.org/D27920

Files:
  include-fixer/find-all-symbols/FindAllSymbols.cpp
  unittests/include-fixer/find-all-symbols/FindAllSymbolsTests.cpp


Index: unittests/include-fixer/find-all-symbols/FindAllSymbolsTests.cpp
===
--- unittests/include-fixer/find-all-symbols/FindAllSymbolsTests.cpp
+++ unittests/include-fixer/find-all-symbols/FindAllSymbolsTests.cpp
@@ -229,6 +229,28 @@
   EXPECT_TRUE(hasSymbol(Symbol));
 }
 
+TEST_F(FindAllSymbolsTest, DontIgnoreTemplatePartialSpecialization) {
+  static const char Code[] = R"(
+  template class Class; // undefined
+  template
+  class Class {
+  };
+
+  template void f() {};
+  template<> void f() {};
+  )";
+  runFindAllSymbols(Code);
+  SymbolInfo Symbol =
+  SymbolInfo("Class", SymbolInfo::SymbolKind::Class, HeaderName, 4, {});
+  EXPECT_TRUE(hasSymbol(Symbol));
+  Symbol =
+  SymbolInfo("f", SymbolInfo::SymbolKind::Function, HeaderName, 7, {});
+  EXPECT_TRUE(hasSymbol(Symbol));
+  Symbol =
+  SymbolInfo("f", SymbolInfo::SymbolKind::Function, HeaderName, 8, {});
+  EXPECT_FALSE(hasSymbol(Symbol));
+}
+
 TEST_F(FindAllSymbolsTest, FunctionSymbols) {
   static const char Code[] = R"(
   namespace na {
Index: include-fixer/find-all-symbols/FindAllSymbols.cpp
===
--- include-fixer/find-all-symbols/FindAllSymbols.cpp
+++ include-fixer/find-all-symbols/FindAllSymbols.cpp
@@ -32,6 +32,18 @@
   return false;
 }
 
+AST_POLYMORPHIC_MATCHER(isFullySpecialized,
+AST_POLYMORPHIC_SUPPORTED_TYPES(FunctionDecl, VarDecl,
+CXXRecordDecl)) {
+  if (Node.getTemplateSpecializationKind() == TSK_ExplicitSpecialization) {
+bool IsPartialSpecialization =
+llvm::isa(Node) ||
+llvm::isa(Node);
+return !IsPartialSpecialization;
+  }
+  return false;
+}
+
 std::vector GetContexts(const NamedDecl *ND) {
   std::vector Contexts;
   for (const auto *Context = ND->getDeclContext(); Context;
@@ -126,8 +138,7 @@
   auto CCMatcher =
   allOf(HasNSOrTUCtxMatcher, unless(IsInSpecialization),
 unless(ast_matchers::isTemplateInstantiation()),
-unless(isInstantiated()), 
unless(classTemplateSpecializationDecl()),
-unless(isExplicitTemplateSpecialization()));
+unless(isInstantiated()), unless(isFullySpecialized()));
 
   // Matchers specific to code in extern "C" {...}.
   auto ExternCMatcher = hasDeclContext(linkageSpecDecl());
@@ -156,8 +167,7 @@
 
   // Matchers for C++ record declarations.
   auto CxxRecordDecl =
-  cxxRecordDecl(CommonFilter, CCMatcher, isDefinition(),
-unless(isExplicitTemplateSpecialization()));
+  cxxRecordDecl(CommonFilter, CCMatcher, isDefinition());
   MatchFinder->addMatcher(CxxRecordDecl.bind("decl"), this);
 
   // Matchers for function declarations.


Index: unittests/include-fixer/find-all-symbols/FindAllSymbolsTests.cpp
===
--- unittests/include-fixer/find-all-symbols/FindAllSymbolsTests.cpp
+++ unittests/include-fixer/find-all-symbols/FindAllSymbolsTests.cpp
@@ -229,6 +229,28 @@
   EXPECT_TRUE(hasSymbol(Symbol));
 }
 
+TEST_F(FindAllSymbolsTest, DontIgnoreTemplatePartialSpecialization) {
+  static const char Code[] = R"(
+  template class Class; // undefined
+  template
+  class Class {
+  };
+
+  template void f() {};
+  template<> void f() {};
+  )";
+  runFindAllSymbols(Code);
+  SymbolInfo Symbol =
+  SymbolInfo("Class", SymbolInfo::SymbolKind::Class, HeaderName, 4, {});
+  EXPECT_TRUE(hasSymbol(Symbol));
+  Symbol =
+  SymbolInfo("f", SymbolInfo::SymbolKind::Function, HeaderName, 7, {});
+  EXPECT_TRUE(hasSymbol(Symbol));
+  Symbol =
+  SymbolInfo("f", SymbolInfo::SymbolKind::Function, HeaderName, 8, {});
+  EXPECT_FALSE(hasSymbol(Symbol));
+}
+
 TEST_F(FindAllSymbolsTest, FunctionSymbols) {
   static const char Code[] = R"(
   namespace na {
Index: include-fixer/find-all-symbols/FindAllSymbols.cpp
===
--- include-fixer/find-all-symbols/FindAllSymbols.cpp
+++ include-fixer/find-all-symbols/FindAllSymbols.cpp
@@ -32,6 +32,18 @@
   return false;
 }
 
+AST_POLYMORPHIC_MATCHER(isFullySpecialized,
+AST_POLYMORPHIC_SUPPORTED_TYPES(FunctionDecl, VarDecl,
+CXXRecordDecl)) {
+  if (Node.getTemplateSpecializationKind() == TSK_ExplicitSpecialization) {
+bool IsPartialSpecialization =
+llvm::isa(Node) ||
+llvm::isa(Node);
+return !IsPartialSpecialization;
+  }
+  return false;
+}
+
 std::vector GetContexts(co

[PATCH] D27918: [analyzer] OStreamChecker

2017-01-11 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a comment.

Hello,

Thanks for the patch, and for the impressing amount of work you put into this. 
Because the patch is huge, so it's going to take some time for somebody to 
understand how everything works.

I'd probably like to learn a bit more about the motivation behind the checker. 
You must be working on a project that uses a lot of `std` streams, and the 
checker seems to verify a particular coding guideline you're following (revert 
all changes to the stream locally). I wonder how universally useful this 
guideline is. For instance, there might exist a project that enjoys writing 
code like this:

  void set_my_favorite_format_specifiers() {
std::cout << std::setprecision(12) << std::hex; // warning?
  }
  
  void revert_my_favorite_format_specifiers() {
std::cout << std::setprecision(6) << std::dec;
  }
  
  void foo() {
set_my_favorite_format_specifiers();
std::cout << 100 << std::endl;
revert_my_favorite_format_specifiers();
  }

Do you expect such pattern to be common? If we enable the checker by default, 
would positives on such code cause annoyance, and would there be a way to 
suppress them?


https://reviews.llvm.org/D27918



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


[PATCH] D26015: Correctly classify main file includes if there is a prefix added

2017-01-11 Thread Alexander Kornienko via Phabricator via cfe-commits
alexfh added a comment.

Tests don't pass with this patch applied:

  $ ninja check-clang-tools 
 
  [22/23] Running the Clang extra tools' regression tests
  FAIL: Extra Tools Unit Tests :: 
clang-tidy/ClangTidyTests/IncludeInserterTest.DontInsertDuplicateIncludeEvenIfMiscategorized
 (427 of 489)
   TEST 'Extra Tools Unit Tests :: 
clang-tidy/ClangTidyTests/IncludeInserterTest.DontInsertDuplicateIncludeEvenIfMiscategorized'
 FAILED 
  Note: Google Test filter = 
IncludeInserterTest.DontInsertDuplicateIncludeEvenIfMiscategorized
  [==] Running 1 test from 1 test case.
  [--] Global test environment set-up.
  [--] 1 test from IncludeInserterTest
  [ RUN  ] 
IncludeInserterTest.DontInsertDuplicateIncludeEvenIfMiscategorized
  1 warning and 1 error generated.
  LLVM ERROR: 'a/header.h' file not found
  foo, bar
  
  
  
  Testing Time: 5.32s
  
  Failing Tests (1):
  Extra Tools Unit Tests :: 
clang-tidy/ClangTidyTests/IncludeInserterTest.DontInsertDuplicateIncludeEvenIfMiscategorized
  
Expected Passes: 487
Expected Failures  : 1
Unexpected Failures: 1
  FAILED: tools/clang/tools/extra/test/CMakeFiles/check-clang-tools 
  cd /build/tools/clang/tools/extra/test && /usr/bin/python2.7 
/src/utils/lit/lit.py -sv /build/tools/clang/tools/extra/test
  ninja: build stopped: subcommand failed.


https://reviews.llvm.org/D26015



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


[PATCH] D27920: [find-all-symbols] Index partial template specializations.

2017-01-11 Thread Haojian Wu via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL291669: [find-all-symbols] Index partial template 
specializations. (authored by hokein).

Changed prior to commit:
  https://reviews.llvm.org/D27920?vs=83944&id=83951#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D27920

Files:
  clang-tools-extra/trunk/include-fixer/find-all-symbols/FindAllSymbols.cpp
  
clang-tools-extra/trunk/unittests/include-fixer/find-all-symbols/FindAllSymbolsTests.cpp


Index: 
clang-tools-extra/trunk/unittests/include-fixer/find-all-symbols/FindAllSymbolsTests.cpp
===
--- 
clang-tools-extra/trunk/unittests/include-fixer/find-all-symbols/FindAllSymbolsTests.cpp
+++ 
clang-tools-extra/trunk/unittests/include-fixer/find-all-symbols/FindAllSymbolsTests.cpp
@@ -229,6 +229,28 @@
   EXPECT_TRUE(hasSymbol(Symbol));
 }
 
+TEST_F(FindAllSymbolsTest, DontIgnoreTemplatePartialSpecialization) {
+  static const char Code[] = R"(
+  template class Class; // undefined
+  template
+  class Class {
+  };
+
+  template void f() {};
+  template<> void f() {};
+  )";
+  runFindAllSymbols(Code);
+  SymbolInfo Symbol =
+  SymbolInfo("Class", SymbolInfo::SymbolKind::Class, HeaderName, 4, {});
+  EXPECT_TRUE(hasSymbol(Symbol));
+  Symbol =
+  SymbolInfo("f", SymbolInfo::SymbolKind::Function, HeaderName, 7, {});
+  EXPECT_TRUE(hasSymbol(Symbol));
+  Symbol =
+  SymbolInfo("f", SymbolInfo::SymbolKind::Function, HeaderName, 8, {});
+  EXPECT_FALSE(hasSymbol(Symbol));
+}
+
 TEST_F(FindAllSymbolsTest, FunctionSymbols) {
   static const char Code[] = R"(
   namespace na {
Index: clang-tools-extra/trunk/include-fixer/find-all-symbols/FindAllSymbols.cpp
===
--- clang-tools-extra/trunk/include-fixer/find-all-symbols/FindAllSymbols.cpp
+++ clang-tools-extra/trunk/include-fixer/find-all-symbols/FindAllSymbols.cpp
@@ -32,6 +32,18 @@
   return false;
 }
 
+AST_POLYMORPHIC_MATCHER(isFullySpecialized,
+AST_POLYMORPHIC_SUPPORTED_TYPES(FunctionDecl, VarDecl,
+CXXRecordDecl)) {
+  if (Node.getTemplateSpecializationKind() == TSK_ExplicitSpecialization) {
+bool IsPartialSpecialization =
+llvm::isa(Node) ||
+llvm::isa(Node);
+return !IsPartialSpecialization;
+  }
+  return false;
+}
+
 std::vector GetContexts(const NamedDecl *ND) {
   std::vector Contexts;
   for (const auto *Context = ND->getDeclContext(); Context;
@@ -126,8 +138,7 @@
   auto CCMatcher =
   allOf(HasNSOrTUCtxMatcher, unless(IsInSpecialization),
 unless(ast_matchers::isTemplateInstantiation()),
-unless(isInstantiated()), 
unless(classTemplateSpecializationDecl()),
-unless(isExplicitTemplateSpecialization()));
+unless(isInstantiated()), unless(isFullySpecialized()));
 
   // Matchers specific to code in extern "C" {...}.
   auto ExternCMatcher = hasDeclContext(linkageSpecDecl());
@@ -156,8 +167,7 @@
 
   // Matchers for C++ record declarations.
   auto CxxRecordDecl =
-  cxxRecordDecl(CommonFilter, CCMatcher, isDefinition(),
-unless(isExplicitTemplateSpecialization()));
+  cxxRecordDecl(CommonFilter, CCMatcher, isDefinition());
   MatchFinder->addMatcher(CxxRecordDecl.bind("decl"), this);
 
   // Matchers for function declarations.


Index: clang-tools-extra/trunk/unittests/include-fixer/find-all-symbols/FindAllSymbolsTests.cpp
===
--- clang-tools-extra/trunk/unittests/include-fixer/find-all-symbols/FindAllSymbolsTests.cpp
+++ clang-tools-extra/trunk/unittests/include-fixer/find-all-symbols/FindAllSymbolsTests.cpp
@@ -229,6 +229,28 @@
   EXPECT_TRUE(hasSymbol(Symbol));
 }
 
+TEST_F(FindAllSymbolsTest, DontIgnoreTemplatePartialSpecialization) {
+  static const char Code[] = R"(
+  template class Class; // undefined
+  template
+  class Class {
+  };
+
+  template void f() {};
+  template<> void f() {};
+  )";
+  runFindAllSymbols(Code);
+  SymbolInfo Symbol =
+  SymbolInfo("Class", SymbolInfo::SymbolKind::Class, HeaderName, 4, {});
+  EXPECT_TRUE(hasSymbol(Symbol));
+  Symbol =
+  SymbolInfo("f", SymbolInfo::SymbolKind::Function, HeaderName, 7, {});
+  EXPECT_TRUE(hasSymbol(Symbol));
+  Symbol =
+  SymbolInfo("f", SymbolInfo::SymbolKind::Function, HeaderName, 8, {});
+  EXPECT_FALSE(hasSymbol(Symbol));
+}
+
 TEST_F(FindAllSymbolsTest, FunctionSymbols) {
   static const char Code[] = R"(
   namespace na {
Index: clang-tools-extra/trunk/include-fixer/find-all-symbols/FindAllSymbols.cpp
===
--- clang-tools-extra/trunk/include-fixer/find-all-symbols/FindAllSymbols.cpp
+++ clang-tools-extra/trunk/include-fixer/find-all-symbols/FindAllSymbols.cpp
@@ 

[PATCH] D28081: Make GetStyle return Expected instead of FormatStyle

2017-01-11 Thread Antonio Maiorano via Phabricator via cfe-commits
amaiorano updated this revision to Diff 83949.
amaiorano added a comment.

Fixed Format/style-on-command-line.cpp test to match new expected output.


https://reviews.llvm.org/D28081

Files:
  include/clang/Format/Format.h
  lib/Format/Format.cpp
  lib/Tooling/Refactoring.cpp
  test/Format/style-on-command-line.cpp
  tools/clang-format/ClangFormat.cpp
  unittests/Format/FormatTest.cpp
  unittests/Format/FormatTestObjC.cpp

Index: unittests/Format/FormatTestObjC.cpp
===
--- unittests/Format/FormatTestObjC.cpp
+++ unittests/Format/FormatTestObjC.cpp
@@ -68,17 +68,21 @@
   FormatStyle Style;
 };
 
-TEST_F(FormatTestObjC, DetectsObjCInHeaders) {
-  Style = getStyle("LLVM", "a.h", "none", "@interface\n"
-  "- (id)init;");
-  EXPECT_EQ(FormatStyle::LK_ObjC, Style.Language);
+TEST(FormatTestObjCStyle, DetectsObjCInHeaders) {
+  auto Style = getStyle("LLVM", "a.h", "none", "@interface\n"
+   "- (id)init;");
+  ASSERT_TRUE((bool)Style);
+  EXPECT_EQ(FormatStyle::LK_ObjC, Style->Language);
+
   Style = getStyle("LLVM", "a.h", "none", "@interface\n"
   "+ (id)init;");
-  EXPECT_EQ(FormatStyle::LK_ObjC, Style.Language);
+  ASSERT_TRUE((bool)Style);
+  EXPECT_EQ(FormatStyle::LK_ObjC, Style->Language);
 
   // No recognizable ObjC.
   Style = getStyle("LLVM", "a.h", "none", "void f() {}");
-  EXPECT_EQ(FormatStyle::LK_Cpp, Style.Language);
+  ASSERT_TRUE((bool)Style);
+  EXPECT_EQ(FormatStyle::LK_Cpp, Style->Language);
 }
 
 TEST_F(FormatTestObjC, FormatObjCTryCatch) {
Index: unittests/Format/FormatTest.cpp
===
--- unittests/Format/FormatTest.cpp
+++ unittests/Format/FormatTest.cpp
@@ -10949,22 +10949,51 @@
   ASSERT_TRUE(
   FS.addFile("/a/test.cpp", 0, llvm::MemoryBuffer::getMemBuffer("int i;")));
   auto Style1 = getStyle("file", "/a/.clang-format", "Google", "", &FS);
-  ASSERT_EQ(Style1, getLLVMStyle());
+  ASSERT_TRUE((bool)Style1);
+  ASSERT_EQ(*Style1, getLLVMStyle());
 
   // Test 2: fallback to default.
   ASSERT_TRUE(
   FS.addFile("/b/test.cpp", 0, llvm::MemoryBuffer::getMemBuffer("int i;")));
   auto Style2 = getStyle("file", "/b/test.cpp", "Mozilla", "", &FS);
-  ASSERT_EQ(Style2, getMozillaStyle());
+  ASSERT_TRUE((bool)Style2);
+  ASSERT_EQ(*Style2, getMozillaStyle());
 
   // Test 3: format file in parent directory.
   ASSERT_TRUE(
   FS.addFile("/c/.clang-format", 0,
  llvm::MemoryBuffer::getMemBuffer("BasedOnStyle: Google")));
   ASSERT_TRUE(FS.addFile("/c/sub/sub/sub/test.cpp", 0,
  llvm::MemoryBuffer::getMemBuffer("int i;")));
   auto Style3 = getStyle("file", "/c/sub/sub/sub/test.cpp", "LLVM", "", &FS);
-  ASSERT_EQ(Style3, getGoogleStyle());
+  ASSERT_TRUE((bool)Style3);
+  ASSERT_EQ(*Style3, getGoogleStyle());
+
+  // Test 4: error on invalid fallback style
+  auto Style4 = getStyle("file", "a.h", "KungFu", "", &FS);
+  ASSERT_FALSE((bool)Style4);
+  llvm::consumeError(Style4.takeError());
+
+  // Test 5: error on invalid yaml on command line
+  auto Style5 = getStyle("{invalid_key=invalid_value}", "a.h", "LLVM", "", &FS);
+  ASSERT_FALSE((bool)Style5);
+  llvm::consumeError(Style5.takeError());
+
+  // Test 6: error on invalid style
+  auto Style6 = getStyle("KungFu", "a.h", "LLVM", "", &FS);
+  ASSERT_FALSE((bool)Style6);
+  llvm::consumeError(Style6.takeError());
+
+  // Test 7: found config file, error on parsing it
+  ASSERT_TRUE(
+  FS.addFile("/d/.clang-format", 0,
+ llvm::MemoryBuffer::getMemBuffer("BasedOnStyle: LLVM\n"
+  "InvalidKey: InvalidValue")));
+  ASSERT_TRUE(
+  FS.addFile("/d/test.cpp", 0, llvm::MemoryBuffer::getMemBuffer("int i;")));
+  auto Style7 = getStyle("file", "/d/.clang-format", "LLVM", "", &FS);
+  ASSERT_FALSE((bool)Style7);
+  llvm::consumeError(Style7.takeError());
 }
 
 TEST_F(ReplacementTest, FormatCodeAfterReplacements) {
Index: tools/clang-format/ClangFormat.cpp
===
--- tools/clang-format/ClangFormat.cpp
+++ tools/clang-format/ClangFormat.cpp
@@ -249,12 +249,17 @@
   if (fillRanges(Code.get(), Ranges))
 return true;
   StringRef AssumedFileName = (FileName == "-") ? AssumeFileName : FileName;
-  FormatStyle FormatStyle =
+
+  llvm::Expected FormatStyle =
   getStyle(Style, AssumedFileName, FallbackStyle, Code->getBuffer());
+  if (!FormatStyle) {
+llvm::errs() << llvm::toString(FormatStyle.takeError()) << "\n";
+return true;
+  }
   if (SortIncludes.getNumOccurrences() != 0)
-FormatStyle.SortIncludes = SortIncludes;
+FormatStyle->SortIncludes = SortIncludes;
   unsigned CursorPosition = Cursor;
-  Replacements Replaces = sortIncludes(FormatStyle, Code->getBuffer(), Ranges,
+  Replacements Replaces = sortI

[clang-tools-extra] r291669 - [find-all-symbols] Index partial template specializations.

2017-01-11 Thread Haojian Wu via cfe-commits
Author: hokein
Date: Wed Jan 11 05:47:44 2017
New Revision: 291669

URL: http://llvm.org/viewvc/llvm-project?rev=291669&view=rev
Log:
[find-all-symbols] Index partial template specializations.

Summary:
Fix no std::function index.

Previously, we don't index all the template specialization declarations of 
functions and classes (Because we assume that template functions/classes are 
indexed by their template declarations), but this is not always true in some 
cases like `std::function` which only has a partial template specialization 
declaration.

Reviewers: ioeric, bkramer

Subscribers: cfe-commits

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

Modified:
clang-tools-extra/trunk/include-fixer/find-all-symbols/FindAllSymbols.cpp

clang-tools-extra/trunk/unittests/include-fixer/find-all-symbols/FindAllSymbolsTests.cpp

Modified: 
clang-tools-extra/trunk/include-fixer/find-all-symbols/FindAllSymbols.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/include-fixer/find-all-symbols/FindAllSymbols.cpp?rev=291669&r1=291668&r2=291669&view=diff
==
--- clang-tools-extra/trunk/include-fixer/find-all-symbols/FindAllSymbols.cpp 
(original)
+++ clang-tools-extra/trunk/include-fixer/find-all-symbols/FindAllSymbols.cpp 
Wed Jan 11 05:47:44 2017
@@ -32,6 +32,18 @@ AST_MATCHER(EnumConstantDecl, isInScoped
   return false;
 }
 
+AST_POLYMORPHIC_MATCHER(isFullySpecialized,
+AST_POLYMORPHIC_SUPPORTED_TYPES(FunctionDecl, VarDecl,
+CXXRecordDecl)) {
+  if (Node.getTemplateSpecializationKind() == TSK_ExplicitSpecialization) {
+bool IsPartialSpecialization =
+llvm::isa(Node) ||
+llvm::isa(Node);
+return !IsPartialSpecialization;
+  }
+  return false;
+}
+
 std::vector GetContexts(const NamedDecl *ND) {
   std::vector Contexts;
   for (const auto *Context = ND->getDeclContext(); Context;
@@ -126,8 +138,7 @@ void FindAllSymbols::registerMatchers(Ma
   auto CCMatcher =
   allOf(HasNSOrTUCtxMatcher, unless(IsInSpecialization),
 unless(ast_matchers::isTemplateInstantiation()),
-unless(isInstantiated()), 
unless(classTemplateSpecializationDecl()),
-unless(isExplicitTemplateSpecialization()));
+unless(isInstantiated()), unless(isFullySpecialized()));
 
   // Matchers specific to code in extern "C" {...}.
   auto ExternCMatcher = hasDeclContext(linkageSpecDecl());
@@ -156,8 +167,7 @@ void FindAllSymbols::registerMatchers(Ma
 
   // Matchers for C++ record declarations.
   auto CxxRecordDecl =
-  cxxRecordDecl(CommonFilter, CCMatcher, isDefinition(),
-unless(isExplicitTemplateSpecialization()));
+  cxxRecordDecl(CommonFilter, CCMatcher, isDefinition());
   MatchFinder->addMatcher(CxxRecordDecl.bind("decl"), this);
 
   // Matchers for function declarations.

Modified: 
clang-tools-extra/trunk/unittests/include-fixer/find-all-symbols/FindAllSymbolsTests.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/unittests/include-fixer/find-all-symbols/FindAllSymbolsTests.cpp?rev=291669&r1=291668&r2=291669&view=diff
==
--- 
clang-tools-extra/trunk/unittests/include-fixer/find-all-symbols/FindAllSymbolsTests.cpp
 (original)
+++ 
clang-tools-extra/trunk/unittests/include-fixer/find-all-symbols/FindAllSymbolsTests.cpp
 Wed Jan 11 05:47:44 2017
@@ -229,6 +229,28 @@ TEST_F(FindAllSymbolsTest, CXXRecordSymb
   EXPECT_TRUE(hasSymbol(Symbol));
 }
 
+TEST_F(FindAllSymbolsTest, DontIgnoreTemplatePartialSpecialization) {
+  static const char Code[] = R"(
+  template class Class; // undefined
+  template
+  class Class {
+  };
+
+  template void f() {};
+  template<> void f() {};
+  )";
+  runFindAllSymbols(Code);
+  SymbolInfo Symbol =
+  SymbolInfo("Class", SymbolInfo::SymbolKind::Class, HeaderName, 4, {});
+  EXPECT_TRUE(hasSymbol(Symbol));
+  Symbol =
+  SymbolInfo("f", SymbolInfo::SymbolKind::Function, HeaderName, 7, {});
+  EXPECT_TRUE(hasSymbol(Symbol));
+  Symbol =
+  SymbolInfo("f", SymbolInfo::SymbolKind::Function, HeaderName, 8, {});
+  EXPECT_FALSE(hasSymbol(Symbol));
+}
+
 TEST_F(FindAllSymbolsTest, FunctionSymbols) {
   static const char Code[] = R"(
   namespace na {


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


[PATCH] D28315: Update tools to use new getStyle API

2017-01-11 Thread Antonio Maiorano via Phabricator via cfe-commits
amaiorano updated this revision to Diff 83952.
amaiorano added a comment.

Fixed code in ClangApplyReplacementsMain.cpp so that we only handle the 
Expected

[PATCH] D28080: [Docs][OpenCL] Added OpenCL feature description to user manual.

2017-01-11 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia updated this revision to Diff 83962.
Anastasia added a comment.

Addressed comments from Alexey, Pekka, and Sam!


https://reviews.llvm.org/D28080

Files:
  docs/UsersManual.rst
  www/index.html

Index: www/index.html
===
--- www/index.html
+++ www/index.html
@@ -15,10 +15,10 @@
   clang: a C language family frontend for LLVM
   
   
-  The goal of the Clang project is to create a new C, C++, Objective C and
-  Objective C++ front-end for the http://www.llvm.org/";>LLVM
-  compiler.  You can get and build the source
-  today.
+  The goal of the Clang project is to create a new C based language
+  front-end: C, C++, Objective C/C++, OpenCL C and others for the
+  http://www.llvm.org/";>LLVM compiler.  You can
+  get and build the source  today.
   
   
   Features and Goals
Index: docs/UsersManual.rst
===
--- docs/UsersManual.rst
+++ docs/UsersManual.rst
@@ -41,6 +41,7 @@
variants depending on base language.
 -  :ref:`C++ Language `
 -  :ref:`Objective C++ Language `
+-  :ref:`OpenCL C Language `: v1.0, v1.1, v1.2, v2.0.
 
 In addition to these base languages and their dialects, Clang supports a
 broad variety of language extensions, which are documented in the
@@ -1973,6 +1974,361 @@
  is provided or target does not support TLS, code generation for threadprivate
  variables relies on OpenMP runtime library.
 
+.. _opencl:
+
+OpenCL Features
+===
+
+Clang can be used to compile OpenCL kernels for execution on a device
+(e.g. GPU). It is possible to compile the kernel into a binary (e.g. for AMD or
+Nvidia targets) that can be uploaded to run directly on a device (e.g. using
+`clCreateProgramWithBinary
+`_) or
+into generic bitcode files loadable into other toolchains.
+
+Compiling to a binary using the default target from the installation can be done
+as follows:
+
+   .. code-block:: console
+
+ $ echo "kernel void k(){}" > test.cl
+ $ clang test.cl
+
+Compiling for a specific target can be done by specifying the triple corresponding
+to the target, for example:
+
+   .. code-block:: console
+
+ $ clang -target nvptx64-unknown-unknown test.cl
+ $ clang -target amdgcn-amd-amdhsa-opencl test.cl
+
+Compiling to bitcode can be done as follows:
+
+   .. code-block:: console
+
+ $ clang -c -emit-llvm test.cl
+
+This will produce a generic test.bc file that can be used in vendor toolchains
+to perform machine code generation.
+
+Clang currently supports OpenCL C language standards up to v2.0.
+
+OpenCL Specific Options
+---
+
+Most of the OpenCL build options from `the specification v2.0 section 5.8.4
+`_ are available.
+
+Examples:
+
+   .. code-block:: console
+
+ $ clang -cl-std=CL2.0 -cl-single-precision-constant test.cl
+
+Some extra options are available to support special OpenCL features.
+
+.. option:: -finclude-default-header
+
+Loads standard includes during compilations. By default OpenCL headers are not
+loaded and therefore standard library includes are not available. To load them
+automatically a flag has been added to the frontend (see also OpenCL Header
+section):
+
+   .. code-block:: console
+
+ $ clang -Xclang -finclude-default-header test.cl
+
+Alternatively ``-include`` or ``-I`` followed by the path to the header location
+can be given manually.
+
+   .. code-block:: console
+
+ $ clang -I/lib/Headers/opencl-c.h test.cl
+
+In this case the kernel code should contain ``#include `` just as a
+regular C include.
+
+.. option:: -cl-ext
+
+Disables support of OpenCL extensions. All OpenCL targets provide a list
+of extensions that they support. Clang allows to amend this using the ``-cl-ext``
+flag with a comma-separated list of extensions prefixed with ``'+'`` or ``'-'``.
+The syntax: ``-cl-ext=<(['-'|'+'][,])+>``,  where extensions
+can be either one of `the OpenCL specification extensions
+`_
+or any known vendor extension. Alternatively, ``'all'`` can be used to enable
+or disable all known extensions.
+Example disabling double support for the 64-bit SPIR target:
+
+   .. code-block:: console
+
+ $ clang -cc1 -triple spir64-unknown-unknown -cl-ext=-cl_khr_fp64 test.cl
+
+Enabling all extensions except double support in R600 AMD GPU can be done using:
+
+   .. code-block:: console
+
+ $ clang -cc1 -triple r600-unknown-unknown -cl-ext=-all,+cl_khr_fp16 test.cl
+
+.. _opencl_fake_address_space_map:
+
+.. option:: -ffake-address-space-map
+
+Overrides the target address space map with a fake map.
+This allows adding explicit address space IDs to the bitcode for non-segmented
+memory architectures that don't have separate IDs for each of the OpenCL
+logical address spaces by defaul

Re: Patch for Bug 22877

2017-01-11 Thread Arthur Eubanks via cfe-commits
Test updated.

patch.diff
Description: Binary data
On 9 Jan 2017, at 3:48 PM, Akira Hatanaka  wrote:Perhaps you can check more explicitly that the destructor is called inside the loop?// CHECK: [[regex for LOOP_BODY]]:// CHECK: call void @_ZN3fooC1Ev// CHECK-NOT: br// CHECK: call void @_ZN3barC1E3foo// CHECK-NOT: br// CHECK: call void @_ZN3fooD1Ev// CHECK: br [[LOOP_BODY]]On Jan 8, 2017, at 11:34 PM, Arthur Eubanks via cfe-commits  wrote:Hi,This is my first commit, please feel free to critique any of the code/new test since I'm not quite sure if this is in the correct format.The patch is for the bug https://llvm.org/bugs/show_bug.cgi?id=22877 regarding cleaning up default arguments in constructors while initializing an array.It doesn't break any old tests.Thanks,Arthur Eubanks___cfe-commits mailing listcfe-commits@lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D28080: [Docs][OpenCL] Added OpenCL feature description to user manual.

2017-01-11 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia marked 16 inline comments as done.
Anastasia added inline comments.



Comment at: docs/UsersManual.rst:2013
+to perform machine code generation.
+
+Clang currently supports OpenCL standards up to v2.0.

pekka.jaaskelainen wrote:
> I'd like to add a sentence or two for instructing how to use it for non-SPMD 
> targets and of course advertise pocl here too ;) 
> 
> Something along the lines of:
> 
> "For "non-SPMD" targets which cannot spawn multiple work-items on the fly 
> using hardware, which covers practically all non-GPU devices such as CPUs and 
> DSPs, additional processing is needed for the kernels to support multiple WI 
> execution. For this, a 3rd party project such as `pocl 
> `_ can be used."
Cool! I have added this later in the description of x86 target use for OpenCL. 
:)



Comment at: docs/UsersManual.rst:2053
+
+Disables standard target extensions. All OpenCL targets provide a list
+of extensions that they support. Clang allows to amend this using the 
``-cl-ext``

yaxunl wrote:
> Maybe rephrase as "Disables support of OpenCL extensions" instead of "Disable 
> standard target extensions" since "standard target extension" is confusing 
> and also to avoid confusion with the effect of disabling OpenCL extension as 
> in '#pragam OPENCL EXTENSION X: disable'. Disabling support of an extension 
> means that they cannot be enabled by pragmas in the OpenCL kernels since they 
> are deemed as non-supported.
Good point!



Comment at: docs/UsersManual.rst:2114
+ $ clang -target nvptx64-unknown-unknown test.cl
+
+Generic Targets

pekka.jaaskelainen wrote:
> This is an alternative location for my pocl advertisement above with a 
> subtitle:
> 
> - For CPU/DSP architectures such as x86, ARM or TCE:
> ...
> 
Added later in the x86 description. 



Comment at: docs/UsersManual.rst:2120
+  that can be used across GPU toolchains. The implementation follows `the SPIR
+  specification `_. There are two flavors 
available
+  for 32 and 64 bits.

bader wrote:
> pekka.jaaskelainen wrote:
> > Which version of SPIR is generated?
> For -cl-std=CL1.x (where x is 0, 1 or 2), SPIR version is 1.2.
> For -cl-std=CL2.0, SPIR version is 2.0.
Is it worth mentioning this in this doc?



Comment at: docs/UsersManual.rst:2130
+
+- x86 is used by some implementations that are x86 compatible
+  (e.g. `POCL `_) and currently remains for backwards

pekka.jaaskelainen wrote:
> This is a bit confusing paragraph, probably due to my confusing explanations 
> of the problems with pocl. Currently pocl tries not to use FASM for 
> preserving logical AS IDs to LLVM IR due to the bunch of problems it 
> constantly produces with seemingly little benefits for common CPUs. My patch 
> related to this considered only the argument info switch. Now pocl only 
> derives the logical iDS from kernel arguments (and all other IDs within the 
> body of the IR function are lost for flat machines).  In my patch, the 
> argument info's address space IDs were made constant and identical to SPIR's 
> as previously they were the target's (which meant losing the AS IDs 
> altogether for flat AS machines).
> 
> You seem to document the arg-info md switch later, so this paragraph might be 
> removed or converted to my pocl blurb which mentions the need for further 
> processing for CPUs.
Yes, it's perhaps a bit confusing indeed. I find the usage of the x86 backend 
for OpenCL is generally a bit confusing. Also there are a lot of program paths 
even in Clang that don't play well for OpenCL purposes or are not handled 
properly and are therefore a source of bugs.

I was just wondering whether it would be possible to switch to using SPIR as a 
generic target at some point in the future and "deprecate" the x86 target for 
OpenCL . Do you think this might work for POCL? At the same time we have 
upcoming SPIR-V support as a new feature that might reshape things.

Regarding the address space I just know that it's common to use fake address 
space map with the x86 backend for some out of tree implementations to add 
missing memory segments to this target. That's why I added this text here.





Comment at: docs/UsersManual.rst:2142-2143
+
+By default Clang will not include standard headers and therefore OpenCL builtin
+functions are unknown. The default CL header is, however, provided in the Clang
+installation and can be enabled by passing the ``-finclude-default-header`` 
flag

bader wrote:
> Not sure it's worth to mention, but even built-in vector types are defined in 
> the opencl-c.h.
Good point!



Comment at: www/index.html:19
+  The goal of the Clang project is to create a new C based language
+  front-end: C, C++, Objective C/C++, OpenCL and others for the
+ 

[PATCH] D28315: Update tools to use new getStyle API

2017-01-11 Thread Antonio Maiorano via Phabricator via cfe-commits
amaiorano added inline comments.



Comment at: change-namespace/ChangeNamespace.cpp:892
+  llvm::errs() << llvm::toString(Style.takeError()) << "\n";
+  continue;
+}

amaiorano wrote:
> ioeric wrote:
> > I'd still like to apply replacements that are not cleaned up. Could you add 
> > the following line before continue, thanks! :)
> > ```
> > FileToReplacements[FilePath] = Replaces;
> > ```
> Will do.
Ah darn, just realized that I forgot to make this change you asked for @ioeric. 
Let me know if everything else is okay, and I'll be sure to add this in before 
submitting. 


https://reviews.llvm.org/D28315



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


[PATCH] D22452: [libcxx] Fix last_write_time tests for filesystems that don't support negative and very large times.

2017-01-11 Thread Jonas Hahnfeld via Phabricator via cfe-commits
Hahnfeld added a comment.

@EricWF ?


https://reviews.llvm.org/D22452



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


[PATCH] D28080: [Docs][OpenCL] Added OpenCL feature description to user manual.

2017-01-11 Thread Alexey Bader via Phabricator via cfe-commits
bader accepted this revision.
bader added a comment.

LGTM.
Thanks!


https://reviews.llvm.org/D28080



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


[PATCH] D28058: [OpenCL] Correct ndrange_t implementation

2017-01-11 Thread Dmitry Borisenkov via Phabricator via cfe-commits
dmitry added a comment.

Ping!


https://reviews.llvm.org/D28058



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


[PATCH] D27700: [clang-tidy] refactor ExprSequence out of misc-use-after-move check

2017-01-11 Thread Alexander Kornienko via Phabricator via cfe-commits
alexfh added a comment.

One late comment.




Comment at: clang-tools-extra/trunk/clang-tidy/utils/ExprSequence.cpp:154-155
+const Stmt *ExprSequence::resolveSyntheticStmt(const Stmt *S) const {
+  if (SyntheticStmtSourceMap.count(S))
+return SyntheticStmtSourceMap.lookup(S);
+  return S;

Use `.find` and store the iterator to avoid duplicate lookups.


Repository:
  rL LLVM

https://reviews.llvm.org/D27700



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


[PATCH] D27680: [CodeGen] Move lifetime.start of a variable when goto jumps back past its declaration

2017-01-11 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

Interesting.  That's a pretty heavyweight solution, and you're still missing 
switches, which have exactly the same "can jump into an arbitrary variable's 
scope" behavior.

I think maybe an easier solution would be to just remove the begin-lifetime 
marker completely when there's a label or case statement in its scope.  If we 
want to improve on that, there's already a jump analysis in Sema that could 
pretty easily be made to mark variables that have jumps into their lifetimes; 
we would just need to guarantee that that analysis is done.




Comment at: lib/CodeGen/LifetimeExtend.cpp:11
+
+class AnalyzeAST : public RecursiveASTVisitor {
+public:

A RecursiveASTVisitor is a rather large thing to instantiate, and we don't need 
most of its functionality.  Stmt already has a children() accessor that returns 
the range of child statements, which should be sufficient.


https://reviews.llvm.org/D27680



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


[PATCH] D28080: [Docs][OpenCL] Added OpenCL feature description to user manual.

2017-01-11 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl accepted this revision.
yaxunl added a comment.

Great work. LGTM. Thanks!


https://reviews.llvm.org/D28080



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


[PATCH] D27257: [CodeCompletion] Ensure that ObjC root class completes instance methods from protocols and categories as well

2017-01-11 Thread Alex Lorenz via Phabricator via cfe-commits
arphaman added a comment.

Ping.


Repository:
  rL LLVM

https://reviews.llvm.org/D27257



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


[PATCH] D28058: [OpenCL] Correct ndrange_t implementation

2017-01-11 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

I am thinking whether we should restrict ndrange_t to be struct type only, 
otherwise a user could typedef anything as ndrange_t and we may lose the 
ndrange_t type in the IR, which will cause issue if we want to translate the IR 
to SPIRV.


https://reviews.llvm.org/D28058



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


r291681 - Unbreak the clang-fuzzer build after r291184.

2017-01-11 Thread Benjamin Kramer via cfe-commits
Author: d0k
Date: Wed Jan 11 10:42:26 2017
New Revision: 291681

URL: http://llvm.org/viewvc/llvm-project?rev=291681&view=rev
Log:
Unbreak the clang-fuzzer build after r291184.

Modified:
cfe/trunk/tools/clang-fuzzer/ClangFuzzer.cpp

Modified: cfe/trunk/tools/clang-fuzzer/ClangFuzzer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-fuzzer/ClangFuzzer.cpp?rev=291681&r1=291680&r2=291681&view=diff
==
--- cfe/trunk/tools/clang-fuzzer/ClangFuzzer.cpp (original)
+++ cfe/trunk/tools/clang-fuzzer/ClangFuzzer.cpp Wed Jan 11 10:42:26 2017
@@ -42,7 +42,7 @@ extern "C" int LLVMFuzzerTestOneInput(ui
   tooling::newFrontendActionFactory());
   std::shared_ptr PCHContainerOps =
   std::make_shared();
-  action->runInvocation(Invocation.release(), Files.get(), PCHContainerOps,
+  action->runInvocation(std::move(Invocation), Files.get(), PCHContainerOps,
 &Diags);
   return 0;
 }


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


[PATCH] D28297: [StaticAnalyzer] Fix crash in CastToStructChecker

2017-01-11 Thread Anna Zaks via Phabricator via cfe-commits
zaks.anna added a comment.

Please, subscribe cfe-commits list on the patches as described in 
http://llvm.org/docs/Phabricator.html.

Thanks!
Anna


Repository:
  rL LLVM

https://reviews.llvm.org/D28297



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


[PATCH] D27689: Module: hash the pcm content and use it as SIGNATURE for implicit modules.

2017-01-11 Thread Manman Ren via Phabricator via cfe-commits
manmanren updated this revision to Diff 83999.
manmanren added a comment.

Rebase on top of r291686.


https://reviews.llvm.org/D27689

Files:
  include/clang/AST/ExternalASTSource.h
  include/clang/Basic/Module.h
  include/clang/Frontend/PCHContainerOperations.h
  include/clang/Serialization/ASTBitCodes.h
  include/clang/Serialization/ASTReader.h
  include/clang/Serialization/ASTWriter.h
  include/clang/Serialization/Module.h
  lib/Basic/Module.cpp
  lib/CodeGen/CGDebugInfo.cpp
  lib/CodeGen/ObjectFilePCHContainerOperations.cpp
  lib/Frontend/ASTUnit.cpp
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTWriter.cpp
  lib/Serialization/GeneratePCH.cpp
  lib/Serialization/GlobalModuleIndex.cpp
  lib/Serialization/Module.cpp
  lib/Serialization/ModuleManager.cpp
  test/Modules/diagnostic-options-out-of-date.m
  test/Modules/explicit-build.cpp
  test/Modules/module_file_info.m
  test/Modules/rebuild.m

Index: test/Modules/rebuild.m
===
--- test/Modules/rebuild.m
+++ test/Modules/rebuild.m
@@ -19,11 +19,10 @@
 // RUN: diff %t/Module.size %t/Module.size.saved
 // RUN: cp %t/Module.pcm %t/Module.pcm.saved.2
 
-// But the signature at least is expected to change, so we rebuild DependsOnModule.
-// NOTE: if we change how the signature is created, this test may need updating.
+// The signature is the hash of the PCM content, we will not rebuild rebuild DependsOnModule.
 // RUN: %clang_cc1 -fmodules -fimplicit-module-maps -fmodules-cache-path=%t -fdisable-module-hash -fsyntax-only -F %S/Inputs %s
 // RUN: diff %t/Module.pcm %t/Module.pcm.saved.2
-// RUN: not diff %t/DependsOnModule.pcm %t/DependsOnModule.pcm.saved
+// RUN: diff %t/DependsOnModule.pcm %t/DependsOnModule.pcm.saved
 
 // Rebuild Module, reset its timestamp, and verify its size hasn't changed
 // RUN: rm %t/Module.pcm
@@ -34,10 +33,9 @@
 // RUN: cp %t/Module.pcm %t/Module.pcm.saved.2
 
 // Verify again with Module pre-imported.
-// NOTE: if we change how the signature is created, this test may need updating.
 // RUN: %clang_cc1 -fmodules -fimplicit-module-maps -fmodules-cache-path=%t -fdisable-module-hash -fsyntax-only -F %S/Inputs %s
 // RUN: diff %t/Module.pcm %t/Module.pcm.saved.2
-// RUN: not diff %t/DependsOnModule.pcm %t/DependsOnModule.pcm.saved
+// RUN: diff %t/DependsOnModule.pcm %t/DependsOnModule.pcm.saved
 
 #ifdef PREIMPORT
 @import Module;
Index: test/Modules/module_file_info.m
===
--- test/Modules/module_file_info.m
+++ test/Modules/module_file_info.m
@@ -29,11 +29,6 @@
 // CHECK: CPU:
 // CHECK: ABI:
 
-// CHECK: Diagnostic options:
-// CHECK:   IgnoreWarnings: Yes
-// CHECK:   Diagnostic flags:
-// CHECK: -Wunused
-
 // CHECK: Header search options:
 // CHECK:   System root [-isysroot=]: '/'
 // CHECK:   Use builtin include directories [-nobuiltininc]: Yes
@@ -47,3 +42,8 @@
 // CHECK:   Predefined macros:
 // CHECK: -DBLARG
 // CHECK: -DWIBBLE=WOBBLE
+
+// CHECK: Diagnostic options:
+// CHECK:   IgnoreWarnings: Yes
+// CHECK:   Diagnostic flags:
+// CHECK: -Wunused
Index: test/Modules/explicit-build.cpp
===
--- test/Modules/explicit-build.cpp
+++ test/Modules/explicit-build.cpp
@@ -199,6 +199,6 @@
 // RUN:-fmodule-file=%t/c.pcm \
 // RUN:%s -DHAVE_A -DHAVE_B -DHAVE_C 2>&1 | FileCheck --check-prefix=CHECK-MISMATCHED-B %s
 //
-// CHECK-MISMATCHED-B:  fatal error: module file '{{.*}}b.pcm' is out of date and needs to be rebuilt: module file out of date
+// CHECK-MISMATCHED-B:  fatal error: module file '{{.*}}b.pcm' is out of date and needs to be rebuilt: signature mismatch
 // CHECK-MISMATCHED-B-NEXT: note: imported by module 'c'
 // CHECK-MISMATCHED-B-NOT:  note:
Index: test/Modules/diagnostic-options-out-of-date.m
===
--- test/Modules/diagnostic-options-out-of-date.m
+++ test/Modules/diagnostic-options-out-of-date.m
@@ -7,6 +7,16 @@
 // RUN: %clang_cc1 -Werror -Wconversion -fmodules-cache-path=%t -fmodules -fimplicit-module-maps -I %S/Inputs %s -fmodules-disable-diagnostic-validation
 // Make sure we don't error out when using the pch
 // RUN: %clang_cc1 -Werror -Wno-conversion -fmodules-cache-path=%t -fmodules -fimplicit-module-maps -fsyntax-only -I %S/Inputs -include-pch %t.pch %s -verify -fmodules-disable-diagnostic-validation
+
+// Build A.pcm
+// RUN: %clang_cc1 -Werror -Wno-conversion -fmodules-cache-path=%t -fmodules -fimplicit-module-maps -I %S/Inputs %s
+// Build pch that imports A.pcm
+// RUN: %clang_cc1 -Werror -Wno-conversion -emit-pch -fmodules-cache-path=%t -fmodules -fimplicit-module-maps -o %t.pch -I %S/Inputs -x objective-c-header %S/Inputs/pch-import-module-out-of-date.pch
+// We will rebuild A.pcm and overwrite the original A.pcm that the pch imports, but the two versions have the same hash.
+// RUN: %clang

[PATCH] D26015: Correctly classify main file includes if there is a prefix added

2017-01-11 Thread Julian Bangert via Phabricator via cfe-commits
jbangert updated this revision to Diff 84001.
jbangert updated the summary for this revision.
jbangert added a comment.

- Add header to unit test fixture.


https://reviews.llvm.org/D26015

Files:
  clang-tidy/utils/IncludeSorter.cpp
  unittests/clang-tidy/IncludeInserterTest.cpp

Index: unittests/clang-tidy/IncludeInserterTest.cpp
===
--- unittests/clang-tidy/IncludeInserterTest.cpp
+++ unittests/clang-tidy/IncludeInserterTest.cpp
@@ -73,6 +73,17 @@
   bool IsAngledInclude() const override { return false; }
 };
 
+class EarlyInAlphabetHeaderInserterCheck : public IncludeInserterCheckBase {
+public:
+  EarlyInAlphabetHeaderInserterCheck(StringRef CheckName, ClangTidyContext *Context)
+  : IncludeInserterCheckBase(CheckName, Context) {}
+
+  std::vector HeadersToInclude() const override {
+return {"a/header.h"};
+  }
+  bool IsAngledInclude() const override { return false; }
+};
+
 class MultipleHeaderInserterCheck : public IncludeInserterCheckBase {
 public:
   MultipleHeaderInserterCheck(StringRef CheckName, ClangTidyContext *Context)
@@ -114,6 +125,7 @@
"insert_includes_test_header.h",
"\n"},
   // Non system headers
+  {"a/header.h", "\n"},
   {"path/to/a/header.h", "\n"},
   {"path/to/z/header.h", "\n"},
   {"path/to/header.h", "\n"},
@@ -522,6 +534,77 @@
"insert_includes_test_header.cc"));
 }
 
+TEST(IncludeInserterTest, DontInsertDuplicateIncludeEvenIfMiscategorized) {
+  const char *PreCode = R"(
+#include "clang_tidy/tests/insert_includes_test_header.h"
+
+#include 
+#include 
+#include 
+
+#include "a/header.h"
+#include "path/to/a/header.h"
+#include "path/to/header.h"
+
+void foo() {
+  int a = 0;
+})";
+
+  const char *PostCode = R"(
+#include "clang_tidy/tests/insert_includes_test_header.h"
+
+#include 
+#include 
+#include 
+
+#include "a/header.h"
+#include "path/to/a/header.h"
+#include "path/to/header.h"
+
+void foo() {
+  int a = 0;
+})";
+
+  EXPECT_EQ(PostCode, runCheckOnCode(
+  PreCode, "workspace_folder/clang_tidy/tests/"
+   "insert_includes_test_header.cc"));
+}
+
+TEST(IncludeInserterTest, HandleOrderInSubdirectory) {
+  const char *PreCode = R"(
+#include "clang_tidy/tests/insert_includes_test_header.h"
+
+#include 
+#include 
+#include 
+
+#include "path/to/a/header.h"
+#include "path/to/header.h"
+
+void foo() {
+  int a = 0;
+})";
+
+  const char *PostCode = R"(
+#include "clang_tidy/tests/insert_includes_test_header.h"
+
+#include 
+#include 
+#include 
+
+#include "a/header.h"
+#include "path/to/a/header.h"
+#include "path/to/header.h"
+
+void foo() {
+  int a = 0;
+})";
+
+  EXPECT_EQ(PostCode, runCheckOnCode(
+  PreCode, "workspace_folder/clang_tidy/tests/"
+   "insert_includes_test_header.cc"));
+}
+
 } // anonymous namespace
 } // namespace tidy
 } // namespace clang
Index: clang-tidy/utils/IncludeSorter.cpp
===
--- clang-tidy/utils/IncludeSorter.cpp
+++ clang-tidy/utils/IncludeSorter.cpp
@@ -61,7 +61,8 @@
   : IncludeSorter::IK_CXXSystemInclude;
   }
   StringRef CanonicalInclude = MakeCanonicalName(IncludeFile, Style);
-  if (CanonicalFile.equals(CanonicalInclude)) {
+  if (CanonicalFile.endswith(CanonicalInclude)
+  || CanonicalInclude.endswith(CanonicalFile)) {
 return IncludeSorter::IK_MainTUInclude;
   }
   if (Style == IncludeSorter::IS_Google) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r291688 - This reverts r291628. As suggested by Richard, we can simply

2017-01-11 Thread Manman Ren via cfe-commits
Author: mren
Date: Wed Jan 11 12:32:30 2017
New Revision: 291688

URL: http://llvm.org/viewvc/llvm-project?rev=291688&view=rev
Log:
This reverts r291628. As suggested by Richard, we can simply
filter out the implicilty imported modules at CodeGen instead of removing the
implicit ImportDecl when an implementation TU of a module imports a header of
that same module.

Removed:
cfe/trunk/test/Modules/Inputs/module-impl-with-link/
cfe/trunk/test/Modules/module-impl-with-link.c
Modified:
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Sema/SemaDecl.cpp

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=291688&r1=291687&r2=291688&view=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Wed Jan 11 12:32:30 2017
@@ -1905,8 +1905,7 @@ public:
   /// \brief The parser has processed a module import translated from a
   /// #include or similar preprocessing directive.
   void ActOnModuleInclude(SourceLocation DirectiveLoc, Module *Mod);
-  void BuildModuleInclude(SourceLocation DirectiveLoc, Module *Mod,
-  bool NoImport);
+  void BuildModuleInclude(SourceLocation DirectiveLoc, Module *Mod);
 
   /// \brief The parsed has entered a submodule.
   void ActOnModuleBegin(SourceLocation DirectiveLoc, Module *Mod);

Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=291688&r1=291687&r2=291688&view=diff
==
--- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDecl.cpp Wed Jan 11 12:32:30 2017
@@ -15652,11 +15652,10 @@ DeclResult Sema::ActOnModuleImport(Sourc
 
 void Sema::ActOnModuleInclude(SourceLocation DirectiveLoc, Module *Mod) {
   checkModuleImportContext(*this, Mod, DirectiveLoc, CurContext, true);
-  BuildModuleInclude(DirectiveLoc, Mod, false/*NoImport*/);
+  BuildModuleInclude(DirectiveLoc, Mod);
 }
 
-void Sema::BuildModuleInclude(SourceLocation DirectiveLoc, Module *Mod,
-  bool NoImport) {
+void Sema::BuildModuleInclude(SourceLocation DirectiveLoc, Module *Mod) {
   // Determine whether we're in the #include buffer for a module. The #includes
   // in that buffer do not qualify as module imports; they're just an
   // implementation detail of us building the module.
@@ -15666,7 +15665,7 @@ void Sema::BuildModuleInclude(SourceLoca
   TUKind == TU_Module &&
   getSourceManager().isWrittenInMainFile(DirectiveLoc);
 
-  bool ShouldAddImport = !IsInModuleIncludes && !NoImport;
+  bool ShouldAddImport = !IsInModuleIncludes;
 
   // If this module import was due to an inclusion directive, create an
   // implicit import declaration to capture it in the AST.
@@ -15714,11 +15713,7 @@ void Sema::ActOnModuleEnd(SourceLocation
   assert(File != getSourceManager().getMainFileID() &&
  "end of submodule in main source file");
   SourceLocation DirectiveLoc = getSourceManager().getIncludeLoc(File);
-  // Do not create implicit ImportDecl if we are building the implementation
-  // of a module.
-  bool NoImport = Mod->getTopLevelModuleName() == getLangOpts().CurrentModule 
&&
-  !getLangOpts().isCompilingModule();
-  BuildModuleInclude(DirectiveLoc, Mod, NoImport);
+  BuildModuleInclude(DirectiveLoc, Mod);
 }
 
 void Sema::createImplicitModuleImportForErrorRecovery(SourceLocation Loc,

Removed: cfe/trunk/test/Modules/module-impl-with-link.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/module-impl-with-link.c?rev=291687&view=auto
==
--- cfe/trunk/test/Modules/module-impl-with-link.c (original)
+++ cfe/trunk/test/Modules/module-impl-with-link.c (removed)
@@ -1,7 +0,0 @@
-// RUN: rm -rf %t
-// RUN: %clang_cc1 -fmodules-cache-path=%t -fmodules -fimplicit-module-maps 
-fmodule-name=Clib %s -I %S/Inputs/module-impl-with-link -emit-llvm -o -
-#include "foo.h"
-// CHECK: !{{[0-9]+}} = !{i32 6, !"Linker Options", ![[LINK_OPTIONS:[0-9]+]]}
-// Make sure we don't generate linker option for module Clib since this TU is
-// an implementation of Clib.
-// CHECK: ![[LINK_OPTIONS]] = !{}


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


r291689 - Module: Do not add any link flags when an implementation TU of a module imports

2017-01-11 Thread Manman Ren via cfe-commits
Author: mren
Date: Wed Jan 11 12:47:38 2017
New Revision: 291689

URL: http://llvm.org/viewvc/llvm-project?rev=291689&view=rev
Log:
Module: Do not add any link flags when an implementation TU of a module imports
a header of that same module.

This fixes a regression caused by r280409.
rdar://problem/29930553

This is an updated version for r291628 (which was reverted in r291688).

Added:
cfe/trunk/test/Modules/Inputs/module-impl-with-link/
cfe/trunk/test/Modules/Inputs/module-impl-with-link/foo.h
cfe/trunk/test/Modules/Inputs/module-impl-with-link/module.modulemap
cfe/trunk/test/Modules/module-impl-with-link.c
Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=291689&r1=291688&r2=291689&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Wed Jan 11 12:47:38 2017
@@ -1243,9 +1243,15 @@ void CodeGenModule::EmitModuleLinkOption
   SmallVector Stack;
 
   // Seed the stack with imported modules.
-  for (Module *M : ImportedModules)
+  for (Module *M : ImportedModules) {
+// Do not add any link flags when an implementation TU of a module imports
+// a header of that same module.
+if (M->getTopLevelModuleName() == getLangOpts().CurrentModule &&
+!getLangOpts().isCompilingModule())
+  continue;
 if (Visited.insert(M).second)
   Stack.push_back(M);
+  }
 
   // Find all of the modules to import, making a little effort to prune
   // non-leaf modules.

Added: cfe/trunk/test/Modules/Inputs/module-impl-with-link/foo.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/module-impl-with-link/foo.h?rev=291689&view=auto
==
--- cfe/trunk/test/Modules/Inputs/module-impl-with-link/foo.h (added)
+++ cfe/trunk/test/Modules/Inputs/module-impl-with-link/foo.h Wed Jan 11 
12:47:38 2017
@@ -0,0 +1 @@
+//empty

Added: cfe/trunk/test/Modules/Inputs/module-impl-with-link/module.modulemap
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/module-impl-with-link/module.modulemap?rev=291689&view=auto
==
--- cfe/trunk/test/Modules/Inputs/module-impl-with-link/module.modulemap (added)
+++ cfe/trunk/test/Modules/Inputs/module-impl-with-link/module.modulemap Wed 
Jan 11 12:47:38 2017
@@ -0,0 +1,4 @@
+module Clib {
+  header "foo.h"
+  link "Clib"
+}

Added: cfe/trunk/test/Modules/module-impl-with-link.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/module-impl-with-link.c?rev=291689&view=auto
==
--- cfe/trunk/test/Modules/module-impl-with-link.c (added)
+++ cfe/trunk/test/Modules/module-impl-with-link.c Wed Jan 11 12:47:38 2017
@@ -0,0 +1,7 @@
+// RUN: rm -rf %t
+// RUN: %clang_cc1 -fmodules-cache-path=%t -fmodules -fimplicit-module-maps 
-fmodule-name=Clib %s -I %S/Inputs/module-impl-with-link -emit-llvm -o -
+#include "foo.h"
+// CHECK: !{{[0-9]+}} = !{i32 6, !"Linker Options", ![[LINK_OPTIONS:[0-9]+]]}
+// Make sure we don't generate linker option for module Clib since this TU is
+// an implementation of Clib.
+// CHECK: ![[LINK_OPTIONS]] = !{}


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


[PATCH] D28404: IRGen: Add optnone attribute on function during O0

2017-01-11 Thread Paul Robinson via Phabricator via cfe-commits
probinson added a comment.

@rsmith could you say whether it seems reasonable to have a LangOpts flag that 
basically means "`pragma clang optimize off` is always in effect."  I think it 
would make the other optnone-related logic simpler.  It would not be the only 
sort-of-codegen-related flag in LangOpts (e.g. the PIC/PIE stuff).

In https://reviews.llvm.org/D28404#641538, @probinson wrote:

> There is another way to make use of the attribute, which I think will be more 
> robust:
>
> Have Sema pretend the pragma is in effect at all times, at -O0.  Then all the 
> existing conflict detection/resolution logic Just Works, and there's no need 
> to spend 4 lines of code hoping to replicate the correct conditions in 
> CodeGenModule.
>
> Because Sema does not have a handle on CodeGenOptions and therefore does not 
> a-priori know the optimization level, probably the right thing to do is move 
> the flag to LangOpts and set it under the correct conditions in 
> CompilerInvocation.  It wouldn't be the first codegen-like option in LangOpts.



https://reviews.llvm.org/D28404



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


[PATCH] D24991: Inline hot functions in libcxx shared_ptr implementation.

2017-01-11 Thread Kevin Hu via Phabricator via cfe-commits
hxy9243 updated this revision to Diff 84004.
hxy9243 added a comment.

Minor changes on function names. Rename __libcpp_atomic_* to 
__libcpp_atomic_refcount_*.


Repository:
  rL LLVM

https://reviews.llvm.org/D24991

Files:
  libcxx/include/memory
  libcxx/src/memory.cpp

Index: libcxx/src/memory.cpp
===
--- libcxx/src/memory.cpp
+++ libcxx/src/memory.cpp
@@ -17,28 +17,6 @@
 
 _LIBCPP_BEGIN_NAMESPACE_STD
 
-namespace
-{
-
-// NOTE: Relaxed and acq/rel atomics (for increment and decrement respectively)
-// should be sufficient for thread safety.
-// See https://llvm.org/bugs/show_bug.cgi?id=22803
-template 
-inline T
-increment(T& t) _NOEXCEPT
-{
-return __libcpp_atomic_add(&t, 1, _AO_Relaxed);
-}
-
-template 
-inline T
-decrement(T& t) _NOEXCEPT
-{
-return __libcpp_atomic_add(&t, -1, _AO_Acq_Rel);
-}
-
-}  // namespace
-
 const allocator_arg_t allocator_arg = allocator_arg_t();
 
 bad_weak_ptr::~bad_weak_ptr() _NOEXCEPT {}
@@ -53,27 +31,27 @@
 {
 }
 
+__shared_weak_count::~__shared_weak_count()
+{
+}
+
 void
 __shared_count::__add_shared() _NOEXCEPT
 {
-increment(__shared_owners_);
+__libcpp_atomic_refcount_increment(__shared_owners_);
 }
 
 bool
 __shared_count::__release_shared() _NOEXCEPT
 {
-if (decrement(__shared_owners_) == -1)
+if (__libcpp_atomic_refcount_decrement(__shared_owners_) == -1)
 {
 __on_zero_shared();
 return true;
 }
 return false;
 }
 
-__shared_weak_count::~__shared_weak_count()
-{
-}
-
 void
 __shared_weak_count::__add_shared() _NOEXCEPT
 {
@@ -83,7 +61,7 @@
 void
 __shared_weak_count::__add_weak() _NOEXCEPT
 {
-increment(__shared_weak_owners_);
+__libcpp_atomic_refcount_increment(__shared_weak_owners_);
 }
 
 void
@@ -124,7 +102,7 @@
 //__libcpp_atomic_store(&__shared_weak_owners_, -1, _AO_Release);
 __on_zero_shared_weak();
 }
-else if (decrement(__shared_weak_owners_) == -1)
+else if (__libcpp_atomic_refcount_decrement(__shared_weak_owners_) == -1)
 __on_zero_shared_weak();
 }
 
Index: libcxx/include/memory
===
--- libcxx/include/memory
+++ libcxx/include/memory
@@ -3681,6 +3681,44 @@
 
 #endif // _LIBCPP_STD_VER > 14
 
+// NOTE: Relaxed and acq/rel atomics (for increment and decrement respectively)
+// should be sufficient for thread safety.
+// See https://llvm.org/bugs/show_bug.cgi?id=22803
+#if defined(__clang__) && __has_builtin(__atomic_load_n) \
+   && __has_builtin(__atomic_store_n)\
+   && __has_builtin(__atomic_add_fetch)  \
+   && __has_builtin(__atomic_compare_exchange_n) \
+   && defined(__ATOMIC_RELAXED)  \
+   && defined(__ATOMIC_CONSUME)  \
+   && defined(__ATOMIC_ACQUIRE)  \
+   && defined(__ATOMIC_RELEASE)  \
+   && defined(__ATOMIC_ACQ_REL)  \
+   && defined(__ATOMIC_SEQ_CST)
+#   define _LIBCPP_HAS_ATOMIC_BUILTINS
+#endif
+
+template 
+inline T
+__libcpp_atomic_refcount_increment(T& t) _NOEXCEPT
+{
+#if defined(_LIBCPP_HAS_ATOMIC_BUILTINS) && !defined(_LIBCPP_HAS_NO_THREADS)
+return __atomic_add_fetch(&t, 1, __ATOMIC_RELAXED);
+#else
+return t += 1;
+#endif
+}
+
+template 
+inline T
+__libcpp_atomic_refcount_decrement(T& t) _NOEXCEPT
+{
+#if defined(_LIBCPP_HAS_ATOMIC_BUILTINS) && !defined(_LIBCPP_HAS_NO_THREADS)
+return __atomic_add_fetch(&t, -1, __ATOMIC_ACQ_REL);
+#else
+return t -= 1;
+#endif
+}
+
 class _LIBCPP_EXCEPTION_ABI bad_weak_ptr
 : public std::exception
 {
@@ -3717,8 +3755,23 @@
 explicit __shared_count(long __refs = 0) _NOEXCEPT
 : __shared_owners_(__refs) {}
 
-void __add_shared() _NOEXCEPT;
-bool __release_shared() _NOEXCEPT;
+#ifdef _LIBCPP_BUILDING_MEMORY
+void _LIBCPP_FUNC_VIS __add_shared() _NOEXCEPT;
+bool _LIBCPP_FUNC_VIS __release_shared() _NOEXCEPT;
+#else
+_LIBCPP_INLINE_VISIBILITY
+void __add_shared() _NOEXCEPT {
+  __libcpp_atomic_refcount_increment(__shared_owners_);
+}
+_LIBCPP_INLINE_VISIBILITY
+bool __release_shared() _NOEXCEPT {
+  if (__libcpp_atomic_refcount_decrement(__shared_owners_) == -1) {
+__on_zero_shared();
+return true;
+  }
+  return false;
+}
+#endif
 _LIBCPP_INLINE_VISIBILITY
 long use_count() const _NOEXCEPT {
 return __libcpp_relaxed_load(&__shared_owners_) + 1;
@@ -3739,9 +3792,25 @@
 virtual ~__shared_weak_count();
 
 public:
-void __add_shared() _NOEXCEPT;
-void __add_weak() _NOEXCEPT;
-void __release_shared() _NOEXCEPT;
+#ifdef _LIBCPP_BUILDING_MEMORY
+void _LIBCPP_FUNC_VIS __add_shared() _NOEXCEPT;
+void _LIBCPP_FUNC_VIS __add_weak() _NOEXCEPT;
+void _LI

[PATCH] D28528: [PowerPC] Fix the wrong implementation of builtin vec_rlnm.

2017-01-11 Thread Nemanja Ivanovic via Phabricator via cfe-commits
nemanjai accepted this revision.
nemanjai added a comment.
This revision is now accepted and ready to land.

Please fix the minor issue with the test case and then commit.
LGTM.




Comment at: test/CodeGen/builtins-ppc-p9vector.c:871
 vector unsigned int test77(void) {
+// CHECK-BE: %shl.i = shl <4 x i32
+// CHECK-BE: %or.i = or <4 x i32> %shl.i

Don't hard-code the names of intermediate results. I imagine this will fail 
even now on some build bot. Rather specify it as something like:
`// CHECK-BE: %[[RES1:.+]] = shl <4 x i32`

And feel free to use the saved result as the operand to the next instruction. 
Like:
`// CHECK-BE: %[[RES2:.+]] = or <4 x i32> %[[RES1]]`


https://reviews.llvm.org/D28528



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


[PATCH] D28503: Documentation for the newly added x86 intrinsics.

2017-01-11 Thread Paul Robinson via Phabricator via cfe-commits
probinson added inline comments.



Comment at: emmintrin.h:1607
+///
+/// This intrinsic corresponds to the  VMOVSD / MOVSD  instruction.
+///

should this be VMOVQ/MOVQ instead?


Repository:
  rL LLVM

https://reviews.llvm.org/D28503



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


r291700 - [index] Add 'contained-by' relation between references and their lexical container.

2017-01-11 Thread Argyrios Kyrtzidis via cfe-commits
Author: akirtzidis
Date: Wed Jan 11 14:51:10 2017
New Revision: 291700

URL: http://llvm.org/viewvc/llvm-project?rev=291700&view=rev
Log:
[index] Add 'contained-by' relation between references and their lexical 
container.

Modified:
cfe/trunk/include/clang/Index/IndexSymbol.h
cfe/trunk/lib/Index/IndexSymbol.cpp
cfe/trunk/lib/Index/IndexingContext.cpp
cfe/trunk/test/Index/Core/designated-inits.c
cfe/trunk/test/Index/Core/index-source.cpp
cfe/trunk/test/Index/Core/index-source.m
cfe/trunk/test/Index/Core/index-subkinds.m
cfe/trunk/test/Index/Core/index-with-module.m

Modified: cfe/trunk/include/clang/Index/IndexSymbol.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Index/IndexSymbol.h?rev=291700&r1=291699&r2=291700&view=diff
==
--- cfe/trunk/include/clang/Index/IndexSymbol.h (original)
+++ cfe/trunk/include/clang/Index/IndexSymbol.h Wed Jan 11 14:51:10 2017
@@ -80,7 +80,7 @@ static const unsigned SymbolPropertyBitN
 typedef unsigned SymbolPropertySet;
 
 /// Set of roles that are attributed to symbol occurrences.
-enum class SymbolRole : uint16_t {
+enum class SymbolRole : uint32_t {
   Declaration = 1 << 0,
   Definition  = 1 << 1,
   Reference   = 1 << 2,
@@ -99,8 +99,9 @@ enum class SymbolRole : uint16_t {
   RelationCalledBy= 1 << 13,
   RelationExtendedBy  = 1 << 14,
   RelationAccessorOf  = 1 << 15,
+  RelationContainedBy = 1 << 16,
 };
-static const unsigned SymbolRoleBitNum = 16;
+static const unsigned SymbolRoleBitNum = 17;
 typedef unsigned SymbolRoleSet;
 
 /// Represents a relation to another symbol for a symbol occurrence.

Modified: cfe/trunk/lib/Index/IndexSymbol.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Index/IndexSymbol.cpp?rev=291700&r1=291699&r2=291700&view=diff
==
--- cfe/trunk/lib/Index/IndexSymbol.cpp (original)
+++ cfe/trunk/lib/Index/IndexSymbol.cpp Wed Jan 11 14:51:10 2017
@@ -289,6 +289,7 @@ void index::applyForEachSymbolRole(Symbo
   APPLY_FOR_ROLE(RelationCalledBy);
   APPLY_FOR_ROLE(RelationExtendedBy);
   APPLY_FOR_ROLE(RelationAccessorOf);
+  APPLY_FOR_ROLE(RelationContainedBy);
 
 #undef APPLY_FOR_ROLE
 }
@@ -317,6 +318,7 @@ void index::printSymbolRoles(SymbolRoleS
 case SymbolRole::RelationCalledBy: OS << "RelCall"; break;
 case SymbolRole::RelationExtendedBy: OS << "RelExt"; break;
 case SymbolRole::RelationAccessorOf: OS << "RelAcc"; break;
+case SymbolRole::RelationContainedBy: OS << "RelCont"; break;
 }
   });
 }

Modified: cfe/trunk/lib/Index/IndexingContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Index/IndexingContext.cpp?rev=291700&r1=291699&r2=291700&view=diff
==
--- cfe/trunk/lib/Index/IndexingContext.cpp (original)
+++ cfe/trunk/lib/Index/IndexingContext.cpp Wed Jan 11 14:51:10 2017
@@ -312,9 +312,14 @@ bool IndexingContext::handleDeclOccurren
 Roles |= Rel.Roles;
   };
 
-  if (!IsRef && Parent && !cast(Parent)->isFunctionOrMethod()) {
-addRelation(SymbolRelation{(unsigned)SymbolRole::RelationChildOf, Parent});
+  if (Parent) {
+if (IsRef) {
+  addRelation(SymbolRelation{(unsigned)SymbolRole::RelationContainedBy, 
Parent});
+} else if (!cast(Parent)->isFunctionOrMethod()) {
+  addRelation(SymbolRelation{(unsigned)SymbolRole::RelationChildOf, 
Parent});
+}
   }
+
   for (auto &Rel : Relations) {
 addRelation(SymbolRelation(Rel.Roles,
Rel.RelatedSymbol->getCanonicalDecl()));

Modified: cfe/trunk/test/Index/Core/designated-inits.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/Core/designated-inits.c?rev=291700&r1=291699&r2=291700&view=diff
==
--- cfe/trunk/test/Index/Core/designated-inits.c (original)
+++ cfe/trunk/test/Index/Core/designated-inits.c Wed Jan 11 14:51:10 2017
@@ -5,7 +5,7 @@ struct MyStruct {
 };
 
 enum {
-  MyValToSet;
+  MyValToSet
 };
 
 // CHECK: [[@LINE+1]]:14 | struct/C | MyStruct |
@@ -20,7 +20,7 @@ const struct MyStruct _MyStruct[]
   [0] = {
 [0][0] = {
   [0] = {
-// CHECK: [[@LINE+2]]:14 | field/C | myfield | {{.*}} | Ref |
+// CHECK: [[@LINE+2]]:14 | field/C | myfield | {{.*}} | 
Ref,RelCont |
 // CHECK: [[@LINE+1]]:24 | enumerator/C | MyValToSet |
 .myfield = MyValToSet,
 // CHECK-NOT: | field/C | myfield |

Modified: cfe/trunk/test/Index/Core/index-source.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/Core/index-source.cpp?rev=291700&r1=291699&r2=291700&view=diff
==
--- cfe/trunk/test/Index/Core/index-source.cpp (original)
+++ cfe/trunk/test/Index/Core/index-source.cpp Wed Ja

r291702 - [PowerPC] Fix the wrong implementation of builtin vec_rlnm.

2017-01-11 Thread Tony Jiang via cfe-commits
Author: jtony
Date: Wed Jan 11 14:59:42 2017
New Revision: 291702

URL: http://llvm.org/viewvc/llvm-project?rev=291702&view=rev
Log:
[PowerPC] Fix the wrong implementation of builtin vec_rlnm.

Modified:
cfe/trunk/lib/Headers/altivec.h
cfe/trunk/test/CodeGen/builtins-ppc-p9vector.c

Modified: cfe/trunk/lib/Headers/altivec.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/altivec.h?rev=291702&r1=291701&r2=291702&view=diff
==
--- cfe/trunk/lib/Headers/altivec.h (original)
+++ cfe/trunk/lib/Headers/altivec.h Wed Jan 11 14:59:42 2017
@@ -7664,13 +7664,15 @@ vec_rlmi(vector unsigned long long __a,
 static __inline__ vector unsigned int __ATTRS_o_ai
 vec_rlnm(vector unsigned int __a, vector unsigned int __b,
  vector unsigned int __c) {
-  return __builtin_altivec_vrlwnm(__a, __b) & __c;
+  vector unsigned int OneByte = { 0x8, 0x8, 0x8, 0x8 };
+  return __builtin_altivec_vrlwnm(__a, ((__c << OneByte) | __b));
 }
 
 static __inline__ vector unsigned long long __ATTRS_o_ai
 vec_rlnm(vector unsigned long long __a, vector unsigned long long __b,
  vector unsigned long long __c) {
-  return __builtin_altivec_vrldnm(__a, __b) & __c;
+  vector unsigned long long OneByte = { 0x8, 0x8 };
+  return __builtin_altivec_vrldnm(__a, ((__c << OneByte) | __b));
 }
 #endif
 

Modified: cfe/trunk/test/CodeGen/builtins-ppc-p9vector.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/builtins-ppc-p9vector.c?rev=291702&r1=291701&r2=291702&view=diff
==
--- cfe/trunk/test/CodeGen/builtins-ppc-p9vector.c (original)
+++ cfe/trunk/test/CodeGen/builtins-ppc-p9vector.c Wed Jan 11 14:59:42 2017
@@ -868,20 +868,24 @@ vector unsigned long long test76(void) {
   return vec_rlmi(vula, vula, vula);
 }
 vector unsigned int test77(void) {
+// CHECK-BE: %[[RES1:.+]] = shl <4 x i32
+// CHECK-BE: %[[RES2:.+]] = or <4 x i32> %[[RES1]]
 // CHECK-BE: @llvm.ppc.altivec.vrlwnm(<4 x i32
-// CHECK-BE: and <4 x i32
 // CHECK-BE: ret <4 x i32>
+// CHECK: %[[RES1:.+]] = shl <4 x i32
+// CHECK: %[[RES2:.+]] = or <4 x i32> %[[RES1]]
 // CHECK: @llvm.ppc.altivec.vrlwnm(<4 x i32
-// CHECK: and <4 x i32
 // CHECK: ret <4 x i32>
   return vec_rlnm(vuia, vuia, vuia);
 }
 vector unsigned long long test78(void) {
+// CHECK-BE: %[[RES1:.+]] = shl <2 x i64
+// CHECK-BE: %[[RES2:.+]] = or <2 x i64> %[[RES1]]
 // CHECK-BE: @llvm.ppc.altivec.vrldnm(<2 x i64
-// CHECK-BE: and <2 x i64
 // CHECK-BE-NEXT: ret <2 x i64>
+// CHECK: %[[RES1:.+]] = shl <2 x i64
+// CHECK: %[[RES2:.+]] = or <2 x i64> %[[RES1]]
 // CHECK: @llvm.ppc.altivec.vrldnm(<2 x i64
-// CHECK: and <2 x i64
 // CHECK-NEXT: ret <2 x i64>
   return vec_rlnm(vula, vula, vula);
 }


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


r291703 - [index] Add 'IBTypeOf' relation for ObjC methods marked with IBAction and properties with IBOutletCollection.

2017-01-11 Thread Argyrios Kyrtzidis via cfe-commits
Author: akirtzidis
Date: Wed Jan 11 15:01:07 2017
New Revision: 291703

URL: http://llvm.org/viewvc/llvm-project?rev=291703&view=rev
Log:
[index] Add 'IBTypeOf' relation for ObjC methods marked with IBAction and 
properties with IBOutletCollection.

Modified:
cfe/trunk/include/clang/Index/IndexSymbol.h
cfe/trunk/lib/Index/IndexDecl.cpp
cfe/trunk/lib/Index/IndexSymbol.cpp
cfe/trunk/lib/Index/IndexTypeSourceInfo.cpp
cfe/trunk/lib/Index/IndexingContext.cpp
cfe/trunk/lib/Index/IndexingContext.h
cfe/trunk/test/Index/Core/index-source.m

Modified: cfe/trunk/include/clang/Index/IndexSymbol.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Index/IndexSymbol.h?rev=291703&r1=291702&r2=291703&view=diff
==
--- cfe/trunk/include/clang/Index/IndexSymbol.h (original)
+++ cfe/trunk/include/clang/Index/IndexSymbol.h Wed Jan 11 15:01:07 2017
@@ -100,8 +100,9 @@ enum class SymbolRole : uint32_t {
   RelationExtendedBy  = 1 << 14,
   RelationAccessorOf  = 1 << 15,
   RelationContainedBy = 1 << 16,
+  RelationIBTypeOf= 1 << 17,
 };
-static const unsigned SymbolRoleBitNum = 17;
+static const unsigned SymbolRoleBitNum = 18;
 typedef unsigned SymbolRoleSet;
 
 /// Represents a relation to another symbol for a symbol occurrence.

Modified: cfe/trunk/lib/Index/IndexDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Index/IndexDecl.cpp?rev=291703&r1=291702&r2=291703&view=diff
==
--- cfe/trunk/lib/Index/IndexDecl.cpp (original)
+++ cfe/trunk/lib/Index/IndexDecl.cpp Wed Jan 11 15:01:07 2017
@@ -46,10 +46,13 @@ public:
   }
 
   void handleDeclarator(const DeclaratorDecl *D,
-const NamedDecl *Parent = nullptr) {
+const NamedDecl *Parent = nullptr,
+bool isIBType = false) {
 if (!Parent) Parent = D;
 
-IndexCtx.indexTypeSourceInfo(D->getTypeSourceInfo(), Parent);
+IndexCtx.indexTypeSourceInfo(D->getTypeSourceInfo(), Parent,
+ Parent->getLexicalDeclContext(),
+ /*isBase=*/false, isIBType);
 IndexCtx.indexNestedNameSpecifierLoc(D->getQualifierLoc(), Parent);
 if (IndexCtx.shouldIndexFunctionLocalSymbols()) {
   // Only index parameters in definitions, parameters in declarations are
@@ -92,8 +95,11 @@ public:
 if (!IndexCtx.handleDecl(D, (unsigned)SymbolRole::Dynamic, Relations))
   return false;
 IndexCtx.indexTypeSourceInfo(D->getReturnTypeSourceInfo(), D);
-for (const auto *I : D->parameters())
-  handleDeclarator(I, D);
+bool hasIBActionAndFirst = D->hasAttr();
+for (const auto *I : D->parameters()) {
+  handleDeclarator(I, D, /*isIBType=*/hasIBActionAndFirst);
+  hasIBActionAndFirst = false;
+}
 
 if (D->isThisDeclarationADefinition()) {
   const Stmt *Body = D->getBody();
@@ -333,6 +339,9 @@ public:
 handleObjCMethod(MD, D);
 if (!IndexCtx.handleDecl(D))
   return false;
+if (IBOutletCollectionAttr *attr = D->getAttr())
+  IndexCtx.indexTypeSourceInfo(attr->getInterfaceLoc(), D,
+   D->getLexicalDeclContext(), false, true);
 IndexCtx.indexTypeSourceInfo(D->getTypeSourceInfo(), D);
 return true;
   }

Modified: cfe/trunk/lib/Index/IndexSymbol.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Index/IndexSymbol.cpp?rev=291703&r1=291702&r2=291703&view=diff
==
--- cfe/trunk/lib/Index/IndexSymbol.cpp (original)
+++ cfe/trunk/lib/Index/IndexSymbol.cpp Wed Jan 11 15:01:07 2017
@@ -290,6 +290,7 @@ void index::applyForEachSymbolRole(Symbo
   APPLY_FOR_ROLE(RelationExtendedBy);
   APPLY_FOR_ROLE(RelationAccessorOf);
   APPLY_FOR_ROLE(RelationContainedBy);
+  APPLY_FOR_ROLE(RelationIBTypeOf);
 
 #undef APPLY_FOR_ROLE
 }
@@ -319,6 +320,7 @@ void index::printSymbolRoles(SymbolRoleS
 case SymbolRole::RelationExtendedBy: OS << "RelExt"; break;
 case SymbolRole::RelationAccessorOf: OS << "RelAcc"; break;
 case SymbolRole::RelationContainedBy: OS << "RelCont"; break;
+case SymbolRole::RelationIBTypeOf: OS << "RelIBType"; break;
 }
   });
 }

Modified: cfe/trunk/lib/Index/IndexTypeSourceInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Index/IndexTypeSourceInfo.cpp?rev=291703&r1=291702&r2=291703&view=diff
==
--- cfe/trunk/lib/Index/IndexTypeSourceInfo.cpp (original)
+++ cfe/trunk/lib/Index/IndexTypeSourceInfo.cpp Wed Jan 11 15:01:07 2017
@@ -26,12 +26,16 @@ class TypeIndexer : public RecursiveASTV
 
 public:
   TypeIndexer(IndexingContext &indexCtx, const NamedDecl *parent,
-  const DeclContext *DC, bool isBase)
+  const DeclContext *DC, bool isBase, bool i

r291705 - [index] Ignore invalid ObjC categories.

2017-01-11 Thread Argyrios Kyrtzidis via cfe-commits
Author: akirtzidis
Date: Wed Jan 11 15:08:31 2017
New Revision: 291705

URL: http://llvm.org/viewvc/llvm-project?rev=291705&view=rev
Log:
[index] Ignore invalid ObjC categories.

We currently are unable to get a USR for those and it doesn't seem useful to 
try to index them.

Modified:
cfe/trunk/lib/Index/IndexDecl.cpp
cfe/trunk/test/Index/Core/index-source.m

Modified: cfe/trunk/lib/Index/IndexDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Index/IndexDecl.cpp?rev=291705&r1=291704&r2=291705&view=diff
==
--- cfe/trunk/lib/Index/IndexDecl.cpp (original)
+++ cfe/trunk/lib/Index/IndexDecl.cpp Wed Jan 11 15:08:31 2017
@@ -289,11 +289,12 @@ public:
 
   bool VisitObjCCategoryDecl(const ObjCCategoryDecl *D) {
 const ObjCInterfaceDecl *C = D->getClassInterface();
-if (C)
-  TRY_TO(IndexCtx.handleReference(C, D->getLocation(), D, D,
-  SymbolRoleSet(), SymbolRelation{
-(unsigned)SymbolRole::RelationExtendedBy, D
-  }));
+if (!C)
+  return true;
+TRY_TO(IndexCtx.handleReference(C, D->getLocation(), D, D, SymbolRoleSet(),
+   SymbolRelation{
+ (unsigned)SymbolRole::RelationExtendedBy, 
D
+   }));
 SourceLocation CategoryLoc = D->getCategoryNameLoc();
 if (!CategoryLoc.isValid())
   CategoryLoc = D->getLocation();

Modified: cfe/trunk/test/Index/Core/index-source.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/Core/index-source.m?rev=291705&r1=291704&r2=291705&view=diff
==
--- cfe/trunk/test/Index/Core/index-source.m (original)
+++ cfe/trunk/test/Index/Core/index-source.m Wed Jan 11 15:08:31 2017
@@ -159,7 +159,7 @@ extern int setjmp(jmp_buf);
 @implementation I3(bar)
 @end
 
-// CHECK: [[@LINE+1]]:12 | extension/ObjC |  |  |  
| Decl | rel: 0
+// CHECK-NOT: [[@LINE+1]]:12 | extension/ObjC |
 @interface NonExistent()
 @end
 


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


[PATCH] D28543: Elliminates uninitialized warning for volitile varibles.

2017-01-11 Thread CJ DiMeglio via Phabricator via cfe-commits
lethalantidote updated this revision to Diff 84016.
lethalantidote marked an inline comment as done.
lethalantidote added a comment.

Addresses thakis' comments and adds a test.


https://reviews.llvm.org/D28543

Files:
  clang/lib/Sema/AnalysisBasedWarnings.cpp
  clang/test/Sema/uninit-variables.c


Index: clang/test/Sema/uninit-variables.c
===
--- clang/test/Sema/uninit-variables.c
+++ clang/test/Sema/uninit-variables.c
@@ -22,7 +22,7 @@
 int test4() {
   int x; // expected-note{{initialize the variable 'x' to silence this 
warning}}
   ++x; // expected-warning{{variable 'x' is uninitialized when used here}}
-  return x; 
+  return x;
 }
 
 int test5() {
@@ -442,6 +442,11 @@
 struct { struct { void *p; } a; } test55 = { { &test55.a }}; // no-warning
 struct { struct { void *p; } a; } test56 = { { &(test56.a) }}; // no-warning
 
+int test57() {
+  volatile int x;
+  return x; // no-warning
+}
+
 void uninit_in_loop() {
   int produce(void);
   void consume(int);
Index: clang/lib/Sema/AnalysisBasedWarnings.cpp
===
--- clang/lib/Sema/AnalysisBasedWarnings.cpp
+++ clang/lib/Sema/AnalysisBasedWarnings.cpp
@@ -80,7 +80,7 @@
   }
 
   S.Diag(L, diag) << R1 << R2;
-  
+
   SourceLocation Open = SilenceableCondVal.getBegin();
   if (Open.isValid()) {
 SourceLocation Close = SilenceableCondVal.getEnd();
@@ -696,6 +696,9 @@
 
   switch (Use.getKind()) {
   case UninitUse::Always:
+if (VD->getType().isVolatileQualified()) {
+  return;
+}
 S.Diag(Use.getUser()->getLocStart(), diag::warn_uninit_var)
 << VD->getDeclName() << IsCapturedByBlock
 << Use.getUser()->getSourceRange();
@@ -864,7 +867,7 @@
 /// false.
 static bool DiagnoseUninitializedUse(Sema &S, const VarDecl *VD,
  const UninitUse &Use,
- bool alwaysReportSelfInit = false) {
+ bool alwaysReportSelfInit = false) { 
   if (const DeclRefExpr *DRE = dyn_cast(Use.getUser())) {
 // Inspect the initializer of the variable declaration which is
 // being referenced prior to its initialization. We emit


Index: clang/test/Sema/uninit-variables.c
===
--- clang/test/Sema/uninit-variables.c
+++ clang/test/Sema/uninit-variables.c
@@ -22,7 +22,7 @@
 int test4() {
   int x; // expected-note{{initialize the variable 'x' to silence this warning}}
   ++x; // expected-warning{{variable 'x' is uninitialized when used here}}
-  return x; 
+  return x;
 }
 
 int test5() {
@@ -442,6 +442,11 @@
 struct { struct { void *p; } a; } test55 = { { &test55.a }}; // no-warning
 struct { struct { void *p; } a; } test56 = { { &(test56.a) }}; // no-warning
 
+int test57() {
+  volatile int x;
+  return x; // no-warning
+}
+
 void uninit_in_loop() {
   int produce(void);
   void consume(int);
Index: clang/lib/Sema/AnalysisBasedWarnings.cpp
===
--- clang/lib/Sema/AnalysisBasedWarnings.cpp
+++ clang/lib/Sema/AnalysisBasedWarnings.cpp
@@ -80,7 +80,7 @@
   }
 
   S.Diag(L, diag) << R1 << R2;
-  
+
   SourceLocation Open = SilenceableCondVal.getBegin();
   if (Open.isValid()) {
 SourceLocation Close = SilenceableCondVal.getEnd();
@@ -696,6 +696,9 @@
 
   switch (Use.getKind()) {
   case UninitUse::Always:
+if (VD->getType().isVolatileQualified()) {
+  return;
+}
 S.Diag(Use.getUser()->getLocStart(), diag::warn_uninit_var)
 << VD->getDeclName() << IsCapturedByBlock
 << Use.getUser()->getSourceRange();
@@ -864,7 +867,7 @@
 /// false.
 static bool DiagnoseUninitializedUse(Sema &S, const VarDecl *VD,
  const UninitUse &Use,
- bool alwaysReportSelfInit = false) {
+ bool alwaysReportSelfInit = false) { 
   if (const DeclRefExpr *DRE = dyn_cast(Use.getUser())) {
 // Inspect the initializer of the variable declaration which is
 // being referenced prior to its initialization. We emit
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D28543: Elliminates uninitialized warning for volitile varibles.

2017-01-11 Thread CJ DiMeglio via Phabricator via cfe-commits
lethalantidote added inline comments.



Comment at: clang/lib/Sema/AnalysisBasedWarnings.cpp:907
 else
   DiagUninitUse(S, VD, Use, true);
   }

thakis wrote:
> Should the check be in DiagUninitUse()? Or is there a reason this one should 
> happen for volatiles?
Good point. Thanks for catching that.  I hoped I understood this use case 
correctly, lemme know if the update makes sense. 


https://reviews.llvm.org/D28543



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


[PATCH] D21675: New ODR checker for modules

2017-01-11 Thread Richard Smith via Phabricator via cfe-commits
rsmith added a comment.

Thanks! I assume there's still no measurable performance impact?




Comment at: include/clang/AST/ODRHash.h:54
+  // in Pointers.
+  size_type NextFreeIndex;
+

Is this always the same as `Pointers.size()`?



Comment at: lib/AST/ODRHash.cpp:35
+  for (auto base : Record->bases()) {
+ID.AddInteger(base.isVirtual());
+AddQualType(base.getType());

AddBoolean for clarity maybe?



Comment at: lib/AST/ODRHash.cpp:335-337
+  llvm::SmallVector Decls(DC->decls_begin(),
+DC->decls_end());
+  ID.AddInteger(Decls.size());

You will presumably need to filter out the implicit declarations before you 
emit the size of the list, otherwise a `DeclContext` with an implicit 
declaration will hash differently from one without.



Comment at: lib/AST/ODRHash.cpp:493-495
+ID.AddBoolean(hasDefaultArgument);
+if (hasDefaultArgument)
+  AddStmt(D->getDefaultArgument());

Given that `AddStmt` already writes out an "is null" flag, could you use 
`AddStmt(hasDefaultArgument ? D->getDefaultArgument() : nullptr)` here?



Comment at: lib/Serialization/ASTReader.cpp:9015-9027
+if (FirstEnum->getName() != SecondEnum->getName()) {
+  Diag(FirstEnum->getLocStart(),
+   diag::err_module_odr_violation_mismatch_decl_diff)
+  << Merge.first << FirstModule.empty()
+  << FirstEnum->getSourceRange() << FirstModule << EnumName
+  << FirstEnum;
+  Diag(SecondEnum->getLocStart(),

Can you factor this out into a local lambda or helper class? These dozen lines 
are repeated quite a lot of times here with only small variations.


https://reviews.llvm.org/D21675



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


[PATCH] D28543: Elliminates uninitialized warning for volitile varibles.

2017-01-11 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

Thanks for the test!




Comment at: clang/lib/Sema/AnalysisBasedWarnings.cpp:907
 else
   DiagUninitUse(S, VD, Use, true);
   }

lethalantidote wrote:
> thakis wrote:
> > Should the check be in DiagUninitUse()? Or is there a reason this one 
> > should happen for volatiles?
> Good point. Thanks for catching that.  I hoped I understood this use case 
> correctly, lemme know if the update makes sense. 
Is it possible to test that both branches have this early return now?



Comment at: clang/lib/Sema/AnalysisBasedWarnings.cpp:699
   case UninitUse::Always:
+if (VD->getType().isVolatileQualified()) {
+  return;

What about the other cases in this switch? Does a volatile still warn in those 
cases? Should it? (Probably not?)

Right now the approach is to add an early return when the warning is emitted. 
Maybe this change should instead be somewhere where we compute if a var could 
be uninitialized, and that should always be false for volatile variables? Then 
future other warnings looking at that bit would get volatiles right for free.


https://reviews.llvm.org/D28543



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


r291707 - [index] Introduce symbol subkinds to mark an accessor getter or setter.

2017-01-11 Thread Argyrios Kyrtzidis via cfe-commits
Author: akirtzidis
Date: Wed Jan 11 15:42:48 2017
New Revision: 291707

URL: http://llvm.org/viewvc/llvm-project?rev=291707&view=rev
Log:
[index] Introduce symbol subkinds to mark an accessor getter or setter.

Modified:
cfe/trunk/include/clang/Index/IndexSymbol.h
cfe/trunk/lib/Index/IndexSymbol.cpp
cfe/trunk/test/Index/Core/index-source.m
cfe/trunk/test/Index/Core/index-subkinds.m

Modified: cfe/trunk/include/clang/Index/IndexSymbol.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Index/IndexSymbol.h?rev=291707&r1=291706&r2=291707&view=diff
==
--- cfe/trunk/include/clang/Index/IndexSymbol.h (original)
+++ cfe/trunk/include/clang/Index/IndexSymbol.h Wed Jan 11 15:42:48 2017
@@ -64,6 +64,8 @@ enum class SymbolSubKind {
   None,
   CXXCopyConstructor,
   CXXMoveConstructor,
+  AccessorGetter,
+  AccessorSetter,
 };
 
 /// Set of properties that provide additional info about a symbol.

Modified: cfe/trunk/lib/Index/IndexSymbol.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Index/IndexSymbol.cpp?rev=291707&r1=291706&r2=291707&view=diff
==
--- cfe/trunk/lib/Index/IndexSymbol.cpp (original)
+++ cfe/trunk/lib/Index/IndexSymbol.cpp Wed Jan 11 15:42:48 2017
@@ -152,10 +152,18 @@ SymbolInfo index::getSymbolInfo(const De
   Info.Lang = SymbolLanguage::ObjC;
   break;
 case Decl::ObjCMethod:
-  if (cast(D)->isInstanceMethod())
+  if (cast(D)->isInstanceMethod()) {
+const ObjCMethodDecl *MD = cast(D);
 Info.Kind = SymbolKind::InstanceMethod;
-  else
+if (MD->isPropertyAccessor()) {
+  if (MD->param_size())
+Info.SubKind = SymbolSubKind::AccessorSetter;
+  else
+Info.SubKind = SymbolSubKind::AccessorGetter;
+}
+  } else {
 Info.Kind = SymbolKind::ClassMethod;
+  }
   Info.Lang = SymbolLanguage::ObjC;
   if (isUnitTest(cast(D)))
 Info.Properties |= (unsigned)SymbolProperty::UnitTest;
@@ -379,6 +387,8 @@ StringRef index::getSymbolSubKindString(
   case SymbolSubKind::None: return "";
   case SymbolSubKind::CXXCopyConstructor: return "cxx-copy-ctor";
   case SymbolSubKind::CXXMoveConstructor: return "cxx-move-ctor";
+  case SymbolSubKind::AccessorGetter: return "acc-get";
+  case SymbolSubKind::AccessorSetter: return "acc-set";
   }
   llvm_unreachable("invalid symbol subkind");
 }

Modified: cfe/trunk/test/Index/Core/index-source.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/Core/index-source.m?rev=291707&r1=291706&r2=291707&view=diff
==
--- cfe/trunk/test/Index/Core/index-source.m (original)
+++ cfe/trunk/test/Index/Core/index-source.m Wed Jan 11 15:42:48 2017
@@ -111,9 +111,9 @@ extern int setjmp(jmp_buf);
 @implementation I2
 // CHECK: [[@LINE+6]]:13 | instance-property/ObjC | prop | 
c:objc(cs)I2(py)prop |  | Ref,RelCont | rel: 1
 // CHECK-NEXT: RelCont | I2 | c:objc(cs)I2
-// CHECK: [[@LINE+4]]:13 | instance-method/ObjC | prop | c:objc(cs)I2(im)prop 
| -[I2 prop] | Def,RelChild | rel: 1
+// CHECK: [[@LINE+4]]:13 | instance-method/acc-get/ObjC | prop | 
c:objc(cs)I2(im)prop | -[I2 prop] | Def,RelChild | rel: 1
 // CHECK-NEXT: RelChild | I2 | c:objc(cs)I2
-// CHECK: [[@LINE+2]]:13 | instance-method/ObjC | setProp: | 
c:objc(cs)I2(im)setProp: | -[I2 setProp:] | Def,RelChild | rel: 1
+// CHECK: [[@LINE+2]]:13 | instance-method/acc-set/ObjC | setProp: | 
c:objc(cs)I2(im)setProp: | -[I2 setProp:] | Def,RelChild | rel: 1
 // CHECK-NEXT: RelChild | I2 | c:objc(cs)I2
 @synthesize prop = _prop;
 
@@ -127,11 +127,11 @@ extern int setjmp(jmp_buf);
 
 @interface I3
 @property (readwrite) id prop;
-// CHECK: [[@LINE+3]]:1 | instance-method/ObjC | prop | c:objc(cs)I3(im)prop | 
-[I3 prop] | Decl,Dyn,RelChild,RelAcc | rel: 2
+// CHECK: [[@LINE+3]]:1 | instance-method/acc-get/ObjC | prop | 
c:objc(cs)I3(im)prop | -[I3 prop] | Decl,Dyn,RelChild,RelAcc | rel: 2
 // CHECK-NEXT: RelChild | I3 | c:objc(cs)I3
 // CHECK-NEXT: RelAcc | prop | c:objc(cs)I3(py)prop
 -(id)prop;
-// CHECK: [[@LINE+3]]:1 | instance-method/ObjC | setProp: | 
c:objc(cs)I3(im)setProp: | -[I3 setProp:] | Decl,Dyn,RelChild,RelAcc | rel: 2
+// CHECK: [[@LINE+3]]:1 | instance-method/acc-set/ObjC | setProp: | 
c:objc(cs)I3(im)setProp: | -[I3 setProp:] | Decl,Dyn,RelChild,RelAcc | rel: 2
 // CHECK-NEXT: RelChild | I3 | c:objc(cs)I3
 // CHECK-NEXT: RelAcc | prop | c:objc(cs)I3(py)prop
 -(void)setProp:(id)p;
@@ -141,8 +141,8 @@ extern int setjmp(jmp_buf);
 @implementation I3
 // CHECK: [[@LINE+4]]:13 | instance-property/ObjC | prop | 
c:objc(cs)I3(py)prop |  | Ref,RelCont | rel: 1
 // CHECK-NEXT: RelCont | I3 | c:objc(cs)I3
-// CHECK: [[@LINE+2]]:13 | instance-method/ObjC | prop | c:objc(cs)I3(im)prop 
| -[I3 prop] | Def,RelChild | rel: 1
-// CHECK: [[@LINE+1

[PATCH] D20428: Tracking exception specification source locations

2017-01-11 Thread don hinton via Phabricator via cfe-commits
hintonda added a comment.

If you want this included in the 4.0 release, it needs to get in before they 
branch tomorrow.


https://reviews.llvm.org/D20428



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


Re: r291689 - Module: Do not add any link flags when an implementation TU of a module imports

2017-01-11 Thread Richard Smith via cfe-commits
Thank you!

On 11 January 2017 at 10:47, Manman Ren via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: mren
> Date: Wed Jan 11 12:47:38 2017
> New Revision: 291689
>
> URL: http://llvm.org/viewvc/llvm-project?rev=291689&view=rev
> Log:
> Module: Do not add any link flags when an implementation TU of a module
> imports
> a header of that same module.
>
> This fixes a regression caused by r280409.
> rdar://problem/29930553
>
> This is an updated version for r291628 (which was reverted in r291688).
>
> Added:
> cfe/trunk/test/Modules/Inputs/module-impl-with-link/
> cfe/trunk/test/Modules/Inputs/module-impl-with-link/foo.h
> cfe/trunk/test/Modules/Inputs/module-impl-with-link/module.modulemap
> cfe/trunk/test/Modules/module-impl-with-link.c
> Modified:
> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/
> CodeGenModule.cpp?rev=291689&r1=291688&r2=291689&view=diff
> 
> ==
> --- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Wed Jan 11 12:47:38 2017
> @@ -1243,9 +1243,15 @@ void CodeGenModule::EmitModuleLinkOption
>SmallVector Stack;
>
>// Seed the stack with imported modules.
> -  for (Module *M : ImportedModules)
> +  for (Module *M : ImportedModules) {
> +// Do not add any link flags when an implementation TU of a module
> imports
> +// a header of that same module.
> +if (M->getTopLevelModuleName() == getLangOpts().CurrentModule &&
> +!getLangOpts().isCompilingModule())
> +  continue;
>  if (Visited.insert(M).second)
>Stack.push_back(M);
> +  }
>
>// Find all of the modules to import, making a little effort to prune
>// non-leaf modules.
>
> Added: cfe/trunk/test/Modules/Inputs/module-impl-with-link/foo.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/
> Modules/Inputs/module-impl-with-link/foo.h?rev=291689&view=auto
> 
> ==
> --- cfe/trunk/test/Modules/Inputs/module-impl-with-link/foo.h (added)
> +++ cfe/trunk/test/Modules/Inputs/module-impl-with-link/foo.h Wed Jan 11
> 12:47:38 2017
> @@ -0,0 +1 @@
> +//empty
>
> Added: cfe/trunk/test/Modules/Inputs/module-impl-with-link/module.
> modulemap
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/
> Modules/Inputs/module-impl-with-link/module.modulemap?rev=291689&view=auto
> 
> ==
> --- cfe/trunk/test/Modules/Inputs/module-impl-with-link/module.modulemap
> (added)
> +++ cfe/trunk/test/Modules/Inputs/module-impl-with-link/module.modulemap
> Wed Jan 11 12:47:38 2017
> @@ -0,0 +1,4 @@
> +module Clib {
> +  header "foo.h"
> +  link "Clib"
> +}
>
> Added: cfe/trunk/test/Modules/module-impl-with-link.c
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/
> Modules/module-impl-with-link.c?rev=291689&view=auto
> 
> ==
> --- cfe/trunk/test/Modules/module-impl-with-link.c (added)
> +++ cfe/trunk/test/Modules/module-impl-with-link.c Wed Jan 11 12:47:38
> 2017
> @@ -0,0 +1,7 @@
> +// RUN: rm -rf %t
> +// RUN: %clang_cc1 -fmodules-cache-path=%t -fmodules
> -fimplicit-module-maps -fmodule-name=Clib %s -I 
> %S/Inputs/module-impl-with-link
> -emit-llvm -o -
> +#include "foo.h"
> +// CHECK: !{{[0-9]+}} = !{i32 6, !"Linker Options",
> ![[LINK_OPTIONS:[0-9]+]]}
> +// Make sure we don't generate linker option for module Clib since this
> TU is
> +// an implementation of Clib.
> +// CHECK: ![[LINK_OPTIONS]] = !{}
>
>
> ___
> 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


LLVM buildmaster will be updated and restarted tonight

2017-01-11 Thread Galina Kistanova via cfe-commits
Hello everyone,

LLVM buildmaster will be updated and restarted after 5 PM Pacific time
today.

Thanks

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


[PATCH] D28543: Elliminates uninitialized warning for volitile varibles.

2017-01-11 Thread CJ DiMeglio via Phabricator via cfe-commits
lethalantidote updated this revision to Diff 84026.
lethalantidote marked an inline comment as done.
lethalantidote added a comment.

Addresses moving check further up, during analysis.
Adds test to check for sometimes branch. Please review.


https://reviews.llvm.org/D28543

Files:
  clang/lib/Analysis/UninitializedValues.cpp
  clang/lib/Sema/AnalysisBasedWarnings.cpp
  clang/test/Sema/uninit-variables.c


Index: clang/test/Sema/uninit-variables.c
===
--- clang/test/Sema/uninit-variables.c
+++ clang/test/Sema/uninit-variables.c
@@ -22,7 +22,7 @@
 int test4() {
   int x; // expected-note{{initialize the variable 'x' to silence this 
warning}}
   ++x; // expected-warning{{variable 'x' is uninitialized when used here}}
-  return x; 
+  return x;
 }
 
 int test5() {
@@ -442,6 +442,21 @@
 struct { struct { void *p; } a; } test55 = { { &test55.a }}; // no-warning
 struct { struct { void *p; } a; } test56 = { { &(test56.a) }}; // no-warning
 
+int test57() {
+  volatile int x;
+  return x; // no-warning
+}
+
+int init(volatile int* num) {
+  return 1;
+}
+
+int test58() {
+  volatile int a, b, c;
+  if (init(&a) || init(&b) || init(&c)) {}
+  return a+b+c;   // no-warning
+}
+
 void uninit_in_loop() {
   int produce(void);
   void consume(int);
Index: clang/lib/Sema/AnalysisBasedWarnings.cpp
===
--- clang/lib/Sema/AnalysisBasedWarnings.cpp
+++ clang/lib/Sema/AnalysisBasedWarnings.cpp
@@ -80,7 +80,7 @@
   }
 
   S.Diag(L, diag) << R1 << R2;
-  
+
   SourceLocation Open = SilenceableCondVal.getBegin();
   if (Open.isValid()) {
 SourceLocation Close = SilenceableCondVal.getEnd();
Index: clang/lib/Analysis/UninitializedValues.cpp
===
--- clang/lib/Analysis/UninitializedValues.cpp
+++ clang/lib/Analysis/UninitializedValues.cpp
@@ -767,7 +767,7 @@
 // appropriately, but we need to continue to analyze subsequent uses
 // of the variable.
 vals[VD] = Uninitialized;
-  } else if (VD->getInit()) {
+  } else if (VD->getInit() || VD->getType().isVolatileQualified()) {
 // Treat the new variable as initialized.
 vals[VD] = Initialized;
   } else {


Index: clang/test/Sema/uninit-variables.c
===
--- clang/test/Sema/uninit-variables.c
+++ clang/test/Sema/uninit-variables.c
@@ -22,7 +22,7 @@
 int test4() {
   int x; // expected-note{{initialize the variable 'x' to silence this warning}}
   ++x; // expected-warning{{variable 'x' is uninitialized when used here}}
-  return x; 
+  return x;
 }
 
 int test5() {
@@ -442,6 +442,21 @@
 struct { struct { void *p; } a; } test55 = { { &test55.a }}; // no-warning
 struct { struct { void *p; } a; } test56 = { { &(test56.a) }}; // no-warning
 
+int test57() {
+  volatile int x;
+  return x; // no-warning
+}
+
+int init(volatile int* num) {
+  return 1;
+}
+
+int test58() {
+  volatile int a, b, c;
+  if (init(&a) || init(&b) || init(&c)) {}
+  return a+b+c;   // no-warning
+}
+
 void uninit_in_loop() {
   int produce(void);
   void consume(int);
Index: clang/lib/Sema/AnalysisBasedWarnings.cpp
===
--- clang/lib/Sema/AnalysisBasedWarnings.cpp
+++ clang/lib/Sema/AnalysisBasedWarnings.cpp
@@ -80,7 +80,7 @@
   }
 
   S.Diag(L, diag) << R1 << R2;
-  
+
   SourceLocation Open = SilenceableCondVal.getBegin();
   if (Open.isValid()) {
 SourceLocation Close = SilenceableCondVal.getEnd();
Index: clang/lib/Analysis/UninitializedValues.cpp
===
--- clang/lib/Analysis/UninitializedValues.cpp
+++ clang/lib/Analysis/UninitializedValues.cpp
@@ -767,7 +767,7 @@
 // appropriately, but we need to continue to analyze subsequent uses
 // of the variable.
 vals[VD] = Uninitialized;
-  } else if (VD->getInit()) {
+  } else if (VD->getInit() || VD->getType().isVolatileQualified()) {
 // Treat the new variable as initialized.
 vals[VD] = Initialized;
   } else {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D28543: Elliminates uninitialized warning for volitile varibles.

2017-01-11 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

Thanks, this is looking pretty good! From clicking around a bit on cs, do you 
think it's better to put the check where you have it, or is maybe 
http://llvm-cs.pcc.me.uk/tools/clang/lib/Analysis/UninitializedValues.cpp#36 
more appropriate? I think having it where you have it means saying "we can 
reason about volatile vars, and we want to treat them as initialized" while the 
other spot means "we can't reason about volatile variables at all". I don't 
know which place is better (of someone else reading this knows, please speak 
up). If the other place makes your test fail, having the check where you have 
it is probably fine. Else I'd say that moving the check up is probably better.




Comment at: clang/lib/Analysis/UninitializedValues.cpp:763
 //
 //   int x = x;
 //

No idea what should happen with `volatile int x = x` -- but I've never seen 
that in practice, so it probably doesn't matter too much either way.


https://reviews.llvm.org/D28543



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


[PATCH] D28503: Documentation for the newly added x86 intrinsics.

2017-01-11 Thread Katya Romanova via Phabricator via cfe-commits
kromanova added inline comments.



Comment at: emmintrin.h:1607
+///
+/// This intrinsic corresponds to the  VMOVSD / MOVSD  instruction.
+///

probinson wrote:
> should this be VMOVQ/MOVQ instead?
Probably yes. Let me know if you have a different opinion.
 
If I use this intrinsic by itself, clang generates VMOVSD instruction. 
It happens because the default domain is chooses to generate smaller 
instruction code. 
I got confused because I couldn't find Intel's documentation about 
_mm_loadu_si64, so I just wrote a test like the one below and looked what 
instructions got generated.

```
__m128i foo22 (void const * __a)
{
  return _mm_loadu_si64 (__a);
}
```

However, if I change the test and use an intrisic to add 2 64-bit integers 
after the load intrinsics, I can see that VMOVQ instruction gets generated.

```
__m128d foo44 (double const * __a)
{
  __m128i first  = _mm_loadu_si64 (__a);
  __m128i second = _mm_loadu_si64 (__a);
  return _mm_add_epi64(first, second);

}
```

So, as you see clang could generate either VMOVSD/MOVSD or VMOVSQ/MOVSQ. I 
think it makes sense to change the documentation as Paul suggested:

/// This intrinsic corresponds to the VMOVSQ/MOVSQ.

Or, alternatively, we could list all the instructions that correspond to this 
intrinsics:

/// This intrinsic corresponds to the VMOVSQ/MOVSQ/VMOVSD/MOVSD.

  



Comment at: emmintrin.h:1607
+///
+/// This intrinsic corresponds to the  VMOVSD / MOVSD  instruction.
+///

kromanova wrote:
> probinson wrote:
> > should this be VMOVQ/MOVQ instead?
> Probably yes. Let me know if you have a different opinion.
>  
> If I use this intrinsic by itself, clang generates VMOVSD instruction. 
> It happens because the default domain is chooses to generate smaller 
> instruction code. 
> I got confused because I couldn't find Intel's documentation about 
> _mm_loadu_si64, so I just wrote a test like the one below and looked what 
> instructions got generated.
> 
> ```
> __m128i foo22 (void const * __a)
> {
>   return _mm_loadu_si64 (__a);
> }
> ```
> 
> However, if I change the test and use an intrisic to add 2 64-bit integers 
> after the load intrinsics, I can see that VMOVQ instruction gets generated.
> 
> ```
> __m128d foo44 (double const * __a)
> {
>   __m128i first  = _mm_loadu_si64 (__a);
>   __m128i second = _mm_loadu_si64 (__a);
>   return _mm_add_epi64(first, second);
> 
> }
> ```
> 
> So, as you see clang could generate either VMOVSD/MOVSD or VMOVSQ/MOVSQ. I 
> think it makes sense to change the documentation as Paul suggested:
> 
> /// This intrinsic corresponds to the VMOVSQ/MOVSQ.
> 
> Or, alternatively, we could list all the instructions that correspond to this 
> intrinsics:
> 
> /// This intrinsic corresponds to the VMOVSQ/MOVSQ/VMOVSD/MOVSD.
> 
>   
It will be interesting to hear Asaf Badoug opinion, since he added this 
intrisic. He probably has access to Intel's documentation for this intrinsic 
too (which I wasn't able to find online).



Comment at: emmintrin.h:1607
+///
+/// This intrinsic corresponds to the  VMOVSD / MOVSD  instruction.
+///

kromanova wrote:
> kromanova wrote:
> > probinson wrote:
> > > should this be VMOVQ/MOVQ instead?
> > Probably yes. Let me know if you have a different opinion.
> >  
> > If I use this intrinsic by itself, clang generates VMOVSD instruction. 
> > It happens because the default domain is chooses to generate smaller 
> > instruction code. 
> > I got confused because I couldn't find Intel's documentation about 
> > _mm_loadu_si64, so I just wrote a test like the one below and looked what 
> > instructions got generated.
> > 
> > ```
> > __m128i foo22 (void const * __a)
> > {
> >   return _mm_loadu_si64 (__a);
> > }
> > ```
> > 
> > However, if I change the test and use an intrisic to add 2 64-bit integers 
> > after the load intrinsics, I can see that VMOVQ instruction gets generated.
> > 
> > ```
> > __m128d foo44 (double const * __a)
> > {
> >   __m128i first  = _mm_loadu_si64 (__a);
> >   __m128i second = _mm_loadu_si64 (__a);
> >   return _mm_add_epi64(first, second);
> > 
> > }
> > ```
> > 
> > So, as you see clang could generate either VMOVSD/MOVSD or VMOVSQ/MOVSQ. I 
> > think it makes sense to change the documentation as Paul suggested:
> > 
> > /// This intrinsic corresponds to the VMOVSQ/MOVSQ.
> > 
> > Or, alternatively, we could list all the instructions that correspond to 
> > this intrinsics:
> > 
> > /// This intrinsic corresponds to the VMOVSQ/MOVSQ/VMOVSD/MOVSD.
> > 
> >   
> It will be interesting to hear Asaf Badoug opinion, since he added this 
> intrisic. He probably has access to Intel's documentation for this intrinsic 
> too (which I wasn't able to find online).
There is a similar situation for one intrisic just a few lines above, namely 
_mm_loadu_pd. It could generate either VMOVUPD / MOVUPD or VMOVUPS/MOVUPS 
instructions. 
I have actually asked Si

[PATCH] D28503: Documentation for the newly added x86 intrinsics.

2017-01-11 Thread Simon Pilgrim via Phabricator via cfe-commits
RKSimon added inline comments.



Comment at: emmintrin.h:1607
+///
+/// This intrinsic corresponds to the  VMOVSD / MOVSD  instruction.
+///

kromanova wrote:
> kromanova wrote:
> > kromanova wrote:
> > > probinson wrote:
> > > > should this be VMOVQ/MOVQ instead?
> > > Probably yes. Let me know if you have a different opinion.
> > >  
> > > If I use this intrinsic by itself, clang generates VMOVSD instruction. 
> > > It happens because the default domain is chooses to generate smaller 
> > > instruction code. 
> > > I got confused because I couldn't find Intel's documentation about 
> > > _mm_loadu_si64, so I just wrote a test like the one below and looked what 
> > > instructions got generated.
> > > 
> > > ```
> > > __m128i foo22 (void const * __a)
> > > {
> > >   return _mm_loadu_si64 (__a);
> > > }
> > > ```
> > > 
> > > However, if I change the test and use an intrisic to add 2 64-bit 
> > > integers after the load intrinsics, I can see that VMOVQ instruction gets 
> > > generated.
> > > 
> > > ```
> > > __m128d foo44 (double const * __a)
> > > {
> > >   __m128i first  = _mm_loadu_si64 (__a);
> > >   __m128i second = _mm_loadu_si64 (__a);
> > >   return _mm_add_epi64(first, second);
> > > 
> > > }
> > > ```
> > > 
> > > So, as you see clang could generate either VMOVSD/MOVSD or VMOVSQ/MOVSQ. 
> > > I think it makes sense to change the documentation as Paul suggested:
> > > 
> > > /// This intrinsic corresponds to the VMOVSQ/MOVSQ.
> > > 
> > > Or, alternatively, we could list all the instructions that correspond to 
> > > this intrinsics:
> > > 
> > > /// This intrinsic corresponds to the VMOVSQ/MOVSQ/VMOVSD/MOVSD.
> > > 
> > >   
> > It will be interesting to hear Asaf Badoug opinion, since he added this 
> > intrisic. He probably has access to Intel's documentation for this 
> > intrinsic too (which I wasn't able to find online).
> There is a similar situation for one intrisic just a few lines above, namely 
> _mm_loadu_pd. It could generate either VMOVUPD / MOVUPD or VMOVUPS/MOVUPS 
> instructions. 
> I have actually asked Simon question about it offline just a couple of days 
> ago. 
> 
> I decided to kept referring to VMOVUPD / MOVUPD as a corresponding 
> instruction for _mm_loadu_pd. However, if we end up doing things differently 
> for _mm_loadu_si64, we need to do a similar change to _mm_loadu_pd (and 
> probably to some other intrinsics).
It should be VMOVQ/MOVQ (note NOT VMOVSQ/MOVSQ!). Whatever the domain fixup 
code does to it, that was the original intent of the code and matches what 
other compilers says it will (probably) be.


Repository:
  rL LLVM

https://reviews.llvm.org/D28503



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


[PATCH] D27486: Correct class-template deprecation behavior

2017-01-11 Thread Richard Smith via Phabricator via cfe-commits
rsmith added inline comments.



Comment at: include/clang/Basic/Attr.td:301
   bit DuplicatesAllowedWhileMerging = 0;
+  // Set to true if this attribute should apply to template declarations,
+  // remains false if this should only be applied to the definition.

I find this confusing -- it seems to suggest the attribute would be applied to 
the template declaration, not the templated declaration. I also think that the 
property we're modelling here is something more general than something about 
templates -- rather, I think the property is "is this attribute only meaningful 
when applied to / inherited into a defintiion?" It would also be useful to make 
clear that this only applies to class templates; for function templates, we 
always instantiate all the attributes with the declaration.

Looking through our current attribute set, it looks like at least `AbiTag` 
should also get this set, and maybe also `Visibility`. (Though I wonder if 
there would be any problem with always instantiating the full attribute set for 
a class declaration.)



Comment at: lib/Sema/SemaTemplate.cpp:2406-2407
+  TemplateArgLists.addOuterTemplateArguments(Converted);
+  InstantiateAttrsForDecl(TemplateArgLists,
+  ClassTemplate->getTemplatedDecl(), Decl);
   ClassTemplate->AddSpecialization(Decl, InsertPos);

You should also presumably do this when instantiating a member `CXXRecordDecl` 
nested within a class template, and when instantiating a local class in a 
function template.

What should happen if more attributes are added between uses of the template? 
Example:

```
template struct A;
A *p;
template struct [[deprecated]] A;
A *q; // warn here?
```


https://reviews.llvm.org/D27486



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


[PATCH] D28503: Documentation for the newly added x86 intrinsics.

2017-01-11 Thread Katya Romanova via Phabricator via cfe-commits
kromanova added inline comments.



Comment at: emmintrin.h:1607
+///
+/// This intrinsic corresponds to the  VMOVSD / MOVSD  instruction.
+///

RKSimon wrote:
> kromanova wrote:
> > kromanova wrote:
> > > kromanova wrote:
> > > > probinson wrote:
> > > > > should this be VMOVQ/MOVQ instead?
> > > > Probably yes. Let me know if you have a different opinion.
> > > >  
> > > > If I use this intrinsic by itself, clang generates VMOVSD instruction. 
> > > > It happens because the default domain is chooses to generate smaller 
> > > > instruction code. 
> > > > I got confused because I couldn't find Intel's documentation about 
> > > > _mm_loadu_si64, so I just wrote a test like the one below and looked 
> > > > what instructions got generated.
> > > > 
> > > > ```
> > > > __m128i foo22 (void const * __a)
> > > > {
> > > >   return _mm_loadu_si64 (__a);
> > > > }
> > > > ```
> > > > 
> > > > However, if I change the test and use an intrisic to add 2 64-bit 
> > > > integers after the load intrinsics, I can see that VMOVQ instruction 
> > > > gets generated.
> > > > 
> > > > ```
> > > > __m128d foo44 (double const * __a)
> > > > {
> > > >   __m128i first  = _mm_loadu_si64 (__a);
> > > >   __m128i second = _mm_loadu_si64 (__a);
> > > >   return _mm_add_epi64(first, second);
> > > > 
> > > > }
> > > > ```
> > > > 
> > > > So, as you see clang could generate either VMOVSD/MOVSD or 
> > > > VMOVSQ/MOVSQ. I think it makes sense to change the documentation as 
> > > > Paul suggested:
> > > > 
> > > > /// This intrinsic corresponds to the VMOVSQ/MOVSQ.
> > > > 
> > > > Or, alternatively, we could list all the instructions that correspond 
> > > > to this intrinsics:
> > > > 
> > > > /// This intrinsic corresponds to the VMOVSQ/MOVSQ/VMOVSD/MOVSD.
> > > > 
> > > >   
> > > It will be interesting to hear Asaf Badoug opinion, since he added this 
> > > intrisic. He probably has access to Intel's documentation for this 
> > > intrinsic too (which I wasn't able to find online).
> > There is a similar situation for one intrisic just a few lines above, 
> > namely _mm_loadu_pd. It could generate either VMOVUPD / MOVUPD or 
> > VMOVUPS/MOVUPS instructions. 
> > I have actually asked Simon question about it offline just a couple of days 
> > ago. 
> > 
> > I decided to kept referring to VMOVUPD / MOVUPD as a corresponding 
> > instruction for _mm_loadu_pd. However, if we end up doing things 
> > differently for _mm_loadu_si64, we need to do a similar change to 
> > _mm_loadu_pd (and probably to some other intrinsics).
> It should be VMOVQ/MOVQ (note NOT VMOVSQ/MOVSQ!). Whatever the domain fixup 
> code does to it, that was the original intent of the code and matches what 
> other compilers says it will (probably) be.
Yep, sorry, inaccurate editing after copy and paste. Thank you for noticing.
I agree should say VMOVQ/MOVQ (similar to what is done for _mm_loadu_pd that we 
discussed a few days ago).

I will do this change and reload the review shortly.


Repository:
  rL LLVM

https://reviews.llvm.org/D28503



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


Proposal for clang-format -r option

2017-01-11 Thread mateusz janek via cfe-commits
Hello,

First of all, I want to say 'Hello' to everyone, I'm new in llvm/clang dev
community.

Today I want to present you a small clang-format proposal.

I want to propose a '-r' option, with which, clang-format will search for
files, which will match regex[s] passed like normal files, down in the
directories tree. Motivation is more user-friendly clang-format. Now when
user want to do such thing, he need to write some scripts/use bash magic.
On Windows, it's even harder. Sample clang-format call, for c++ files,
would look e.g. like this:
clang-format -i -r .\.cpp$

This patch provides strict regex matching, so such call won't work:
'clang-format -i -r *.cpp'

Next thing to implement could be some kind of 'easy regexs' or so, which
would accept '*.cpp', but IMHO this isn't in the scope of this patch, so I
didn't implement it.

I didn't write any test or so. Before, I wanted to write this mail and get
feedback if -r option is even a thing and you will like it. After your
acceptance, I'll write tests, update documentation etc.

Of course, patch is backward compatible.

If you have questions/comments/accepts/rejects feel free (:

Kind Regards,
Stryku


clang_format-r.patch
Description: Binary data
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D28503: Documentation for the newly added x86 intrinsics.

2017-01-11 Thread Katya Romanova via Phabricator via cfe-commits
kromanova updated this revision to Diff 84038.
kromanova added a comment.

Changed the instruction name from  VMOVSD to  VMOVQ for _mm_loadu_si64


Repository:
  rL LLVM

https://reviews.llvm.org/D28503

Files:
  avxintrin.h
  emmintrin.h
  mmintrin.h
  pmmintrin.h
  xmmintrin.h

Index: xmmintrin.h
===
--- xmmintrin.h
+++ xmmintrin.h
@@ -2067,7 +2067,7 @@
 ///_MM_HINT_T1: Move data using the T1 hint. The PREFETCHT1 instruction will
 ///be generated. \n
 ///_MM_HINT_T2: Move data using the T2 hint. The PREFETCHT2 instruction will
-///be generated.   
+///be generated.
 #define _mm_prefetch(a, sel) (__builtin_prefetch((void *)(a), 0, (sel)))
 #endif
 
@@ -2435,17 +2435,17 @@
 ///  For checking exception masks: _MM_MASK_UNDERFLOW, _MM_MASK_OVERFLOW,
 ///  _MM_MASK_INVALID, _MM_MASK_DENORM, _MM_MASK_DIV_ZERO, _MM_MASK_INEXACT.
 ///  There is a convenience wrapper _MM_GET_EXCEPTION_MASK().
-///
+///
 ///
 ///  For checking rounding modes: _MM_ROUND_NEAREST, _MM_ROUND_DOWN,
 ///  _MM_ROUND_UP, _MM_ROUND_TOWARD_ZERO. There is a convenience wrapper
 ///  _MM_GET_ROUNDING_MODE(x) where x is one of these macros.
 ///
-/// 
+///
 ///  For checking flush-to-zero mode: _MM_FLUSH_ZERO_ON, _MM_FLUSH_ZERO_OFF.
 ///  There is a convenience wrapper _MM_GET_FLUSH_ZERO_MODE().
 ///
-/// 
+///
 ///  For checking denormals-are-zero mode: _MM_DENORMALS_ZERO_ON,
 ///  _MM_DENORMALS_ZERO_OFF. There is a convenience wrapper
 ///  _MM_GET_DENORMALS_ZERO_MODE().
@@ -2468,11 +2468,11 @@
 unsigned int _mm_getcsr(void);
 
 /// \brief Sets the MXCSR register with the 32-bit unsigned integer value.
-///   
+///
 ///There are several groups of macros associated with this intrinsic,
 ///including:
 ///
-/// 
+///
 ///  For setting exception states: _MM_EXCEPT_INVALID, _MM_EXCEPT_DIV_ZERO,
 ///  _MM_EXCEPT_DENORM, _MM_EXCEPT_OVERFLOW, _MM_EXCEPT_UNDERFLOW,
 ///  _MM_EXCEPT_INEXACT. There is a convenience wrapper
@@ -2517,7 +2517,7 @@
 ///
 /// \param __i
 ///A 32-bit unsigned integer value to be written to the MXCSR register.
-void _mm_setcsr(unsigned int);
+void _mm_setcsr(unsigned int __i);
 
 #if defined(__cplusplus)
 } // extern "C"
Index: pmmintrin.h
===
--- pmmintrin.h
+++ pmmintrin.h
@@ -115,7 +115,7 @@
 
 /// \brief Moves and duplicates high-order (odd-indexed) values from a 128-bit
 ///vector of [4 x float] to float values stored in a 128-bit vector of
-///[4 x float]. 
+///[4 x float].
 ///
 /// \headerfile 
 ///
@@ -136,7 +136,7 @@
 }
 
 /// \brief Duplicates low-order (even-indexed) values from a 128-bit vector of
-///[4 x float] to float values stored in a 128-bit vector of [4 x float]. 
+///[4 x float] to float values stored in a 128-bit vector of [4 x float].
 ///
 /// \headerfile 
 ///
Index: mmintrin.h
===
--- mmintrin.h
+++ mmintrin.h
@@ -211,7 +211,7 @@
 /// This intrinsic corresponds to the  PUNPCKHBW  instruction.
 ///
 /// \param __m1
-///A 64-bit integer vector of [8 x i8]. \n 
+///A 64-bit integer vector of [8 x i8]. \n
 ///Bits [39:32] are written to bits [7:0] of the result. \n
 ///Bits [47:40] are written to bits [23:16] of the result. \n
 ///Bits [55:48] are written to bits [39:32] of the result. \n
Index: emmintrin.h
===
--- emmintrin.h
+++ emmintrin.h
@@ -1599,6 +1599,17 @@
   return ((struct __loadu_pd*)__dp)->__v;
 }
 
+/// \brief Loads a 64-bit integer value to the low element of a 128-bit integer
+///vector and clears the upper element.
+///
+/// \headerfile 
+///
+/// This intrinsic corresponds to the  VMOVQ / MOVQ  instruction.
+///
+/// \param __dp
+///A pointer to a 64-bit memory location. The address of the memory
+///location does not have to be aligned.
+/// \returns A 128-bit vector of [2 x i64] containing the loaded value.
 static __inline__ __m128i __DEFAULT_FN_ATTRS
 _mm_loadu_si64(void const *__a)
 {
@@ -1609,6 +1620,17 @@
   return (__m128i){__u, 0L};
 }
 
+/// \brief Loads a 64-bit double-precision value to the low element of a
+///128-bit integer vector and clears the upper element.
+///
+/// \headerfile 
+///
+/// This intrinsic corresponds to the  VMOVSD / MOVSD  instruction.
+///
+/// \param __dp
+///An pointer to a memory location containing a double-precision value.
+///The address of the memory location does not have to be aligned.
+/// \returns A 128-bit vector of [2 x double] containing the loaded value.
 static __inline__ __m128d __DEFAULT_FN_ATTRS
 _mm_load_sd(double const *__dp)
 {
@@ -4019,7 +4041,7 @@
 /// \param __p
 ///A pointer to the memory location used to identify the cache line t

[PATCH] D27486: Correct class-template deprecation behavior

2017-01-11 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

Thanks for the feedback Richard!  I'll look into whether instantiating the full 
attribute set upon creation is a possibility.




Comment at: include/clang/Basic/Attr.td:301
   bit DuplicatesAllowedWhileMerging = 0;
+  // Set to true if this attribute should apply to template declarations,
+  // remains false if this should only be applied to the definition.

rsmith wrote:
> I find this confusing -- it seems to suggest the attribute would be applied 
> to the template declaration, not the templated declaration. I also think that 
> the property we're modelling here is something more general than something 
> about templates -- rather, I think the property is "is this attribute only 
> meaningful when applied to / inherited into a defintiion?" It would also be 
> useful to make clear that this only applies to class templates; for function 
> templates, we always instantiate all the attributes with the declaration.
> 
> Looking through our current attribute set, it looks like at least `AbiTag` 
> should also get this set, and maybe also `Visibility`. (Though I wonder if 
> there would be any problem with always instantiating the full attribute set 
> for a class declaration.)
> (Though I wonder if there would be any problem with always instantiating the 
> full attribute set for a class declaration.)

This is definitely a good point.  It seems that just about every other usage of 
instantiating attributes happens right after creation, class template 
specialization is the lone exception it seems.

If I were to simply revert most of this change, then alter my SemaTemplate.cpp 
changes to just call InstantiateAttrs and presumably remove the other call to 
InstantiateAttrs (since it results in 2 sets of attributes), would you consider 
that to be more acceptable?





https://reviews.llvm.org/D27486



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


[libcxx] r291723 - [CMake][libcxx] Check that we have libcxxabi before using it

2017-01-11 Thread Petr Hosek via cfe-commits
Author: phosek
Date: Wed Jan 11 17:11:40 2017
New Revision: 291723

URL: http://llvm.org/viewvc/llvm-project?rev=291723&view=rev
Log:
[CMake][libcxx] Check that we have libcxxabi before using it

When doing standalone build, check that we actually have libcxxabi
before attempting to use it.

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

Modified:
libcxx/trunk/CMakeLists.txt

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=291723&r1=291722&r2=291723&view=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Wed Jan 11 17:11:40 2017
@@ -119,7 +119,8 @@ if (LIBCXX_CXX_ABI STREQUAL "default")
   ${LLVM_MAIN_SRC_DIR}/runtimes/libcxxabi/include
 NO_DEFAULT_PATH
   )
-  if (IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
+  if ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
+  IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
 set(LIBCXX_CXX_ABI_INCLUDE_PATHS "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_INTREE 1)


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


[PATCH] D27680: [CodeGen] Move lifetime.start of a variable when goto jumps back past its declaration

2017-01-11 Thread Akira Hatanaka via Phabricator via cfe-commits
ahatanak added a comment.

In https://reviews.llvm.org/D27680#642770, @rjmccall wrote:

> Interesting.  That's a pretty heavyweight solution, and you're still missing 
> switches, which have exactly the same "can jump into an arbitrary variable's 
> scope" behavior.


In addition to missing the switches, I realized the code in VisitGotoStmt and 
VisitLabelStmt isn't correct. For example, in function move_lifetime_start in 
the test case, it wouldn't move the lifetime markers for "i "if label "label1" 
were enclosed in a block:

  {
   label1:
 p = 0;
  }
  ...
int i = 999;
if (ac != 2) {
  p = &i;
  goto label1;
}
  ...

I fixed both bugs in my local branch.

> I think maybe an easier solution would be to just remove the begin-lifetime 
> marker completely when there's a label or case statement in its scope.  If we 
> want to improve on that, there's already a jump analysis in Sema that could 
> pretty easily be made to mark variables that have jumps into their lifetimes; 
> we would just need to guarantee that that analysis is done.

I suppose you are suggesting we avoid emitting lifetime begin and end during 
IRGen if there is a label preceding the variable declaration (I don't think we 
have to care about case or default statements since we only have to worry about 
backward jumps), rather than running an analysis pass before IRGen and 
stretching the lifetime at IRGen time. If it doesn't have a large impact on 
performance, we can do that, but otherwise we have to come up with another way 
to fix this bug.


https://reviews.llvm.org/D27680



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


[PATCH] D28543: Elliminates uninitialized warning for volitile varibles.

2017-01-11 Thread CJ DiMeglio via Phabricator via cfe-commits
lethalantidote added a comment.

So I tried the update you suggested (moving it up into IsTracked) and it seems 
to work and the reasoning makes sense to me.


https://reviews.llvm.org/D28543



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


[PATCH] D28543: Elliminates uninitialized warning for volitile varibles.

2017-01-11 Thread CJ DiMeglio via Phabricator via cfe-commits
lethalantidote updated this revision to Diff 84045.
lethalantidote added a comment.

Moves check in IsTracked().


https://reviews.llvm.org/D28543

Files:
  clang/lib/Analysis/UninitializedValues.cpp
  clang/lib/Sema/AnalysisBasedWarnings.cpp
  clang/test/Sema/uninit-variables.c


Index: clang/test/Sema/uninit-variables.c
===
--- clang/test/Sema/uninit-variables.c
+++ clang/test/Sema/uninit-variables.c
@@ -22,7 +22,7 @@
 int test4() {
   int x; // expected-note{{initialize the variable 'x' to silence this 
warning}}
   ++x; // expected-warning{{variable 'x' is uninitialized when used here}}
-  return x; 
+  return x;
 }
 
 int test5() {
@@ -442,6 +442,21 @@
 struct { struct { void *p; } a; } test55 = { { &test55.a }}; // no-warning
 struct { struct { void *p; } a; } test56 = { { &(test56.a) }}; // no-warning
 
+int test57() {
+  volatile int x;
+  return x; // no-warning
+}
+
+int init(volatile int* num) {
+  return 1;
+}
+
+int test58() {
+  volatile int a, b, c;
+  if (init(&a) || init(&b) || init(&c)) {}
+  return a+b+c;   // no-warning
+}
+
 void uninit_in_loop() {
   int produce(void);
   void consume(int);
Index: clang/lib/Sema/AnalysisBasedWarnings.cpp
===
--- clang/lib/Sema/AnalysisBasedWarnings.cpp
+++ clang/lib/Sema/AnalysisBasedWarnings.cpp
@@ -80,7 +80,7 @@
   }
 
   S.Diag(L, diag) << R1 << R2;
-  
+
   SourceLocation Open = SilenceableCondVal.getBegin();
   if (Open.isValid()) {
 SourceLocation Close = SilenceableCondVal.getEnd();
Index: clang/lib/Analysis/UninitializedValues.cpp
===
--- clang/lib/Analysis/UninitializedValues.cpp
+++ clang/lib/Analysis/UninitializedValues.cpp
@@ -36,7 +36,8 @@
 static bool isTrackedVar(const VarDecl *vd, const DeclContext *dc) {
   if (vd->isLocalVarDecl() && !vd->hasGlobalStorage() &&
   !vd->isExceptionVariable() && !vd->isInitCapture() &&
-  !vd->isImplicit() && vd->getDeclContext() == dc) {
+  !vd->isImplicit() && !vd->getType().isVolatileQualified() &&
+  vd->getDeclContext() == dc) {
 QualType ty = vd->getType();
 return ty->isScalarType() || ty->isVectorType() || ty->isRecordType();
   }


Index: clang/test/Sema/uninit-variables.c
===
--- clang/test/Sema/uninit-variables.c
+++ clang/test/Sema/uninit-variables.c
@@ -22,7 +22,7 @@
 int test4() {
   int x; // expected-note{{initialize the variable 'x' to silence this warning}}
   ++x; // expected-warning{{variable 'x' is uninitialized when used here}}
-  return x; 
+  return x;
 }
 
 int test5() {
@@ -442,6 +442,21 @@
 struct { struct { void *p; } a; } test55 = { { &test55.a }}; // no-warning
 struct { struct { void *p; } a; } test56 = { { &(test56.a) }}; // no-warning
 
+int test57() {
+  volatile int x;
+  return x; // no-warning
+}
+
+int init(volatile int* num) {
+  return 1;
+}
+
+int test58() {
+  volatile int a, b, c;
+  if (init(&a) || init(&b) || init(&c)) {}
+  return a+b+c;   // no-warning
+}
+
 void uninit_in_loop() {
   int produce(void);
   void consume(int);
Index: clang/lib/Sema/AnalysisBasedWarnings.cpp
===
--- clang/lib/Sema/AnalysisBasedWarnings.cpp
+++ clang/lib/Sema/AnalysisBasedWarnings.cpp
@@ -80,7 +80,7 @@
   }
 
   S.Diag(L, diag) << R1 << R2;
-  
+
   SourceLocation Open = SilenceableCondVal.getBegin();
   if (Open.isValid()) {
 SourceLocation Close = SilenceableCondVal.getEnd();
Index: clang/lib/Analysis/UninitializedValues.cpp
===
--- clang/lib/Analysis/UninitializedValues.cpp
+++ clang/lib/Analysis/UninitializedValues.cpp
@@ -36,7 +36,8 @@
 static bool isTrackedVar(const VarDecl *vd, const DeclContext *dc) {
   if (vd->isLocalVarDecl() && !vd->hasGlobalStorage() &&
   !vd->isExceptionVariable() && !vd->isInitCapture() &&
-  !vd->isImplicit() && vd->getDeclContext() == dc) {
+  !vd->isImplicit() && !vd->getType().isVolatileQualified() &&
+  vd->getDeclContext() == dc) {
 QualType ty = vd->getType();
 return ty->isScalarType() || ty->isVectorType() || ty->isRecordType();
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D28512: [libc++] Pair _aligned_malloc with _aligned_free

2017-01-11 Thread Saleem Abdulrasool via Phabricator via cfe-commits
compnerd accepted this revision.
compnerd added a comment.
This revision is now accepted and ready to land.

Hah, can't believe we missed that.


https://reviews.llvm.org/D28512



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


[libcxx] r291728 - Revert "[CMake][libcxx] Move Python check to main CMake file"

2017-01-11 Thread Petr Hosek via cfe-commits
Author: phosek
Date: Wed Jan 11 17:56:33 2017
New Revision: 291728

URL: http://llvm.org/viewvc/llvm-project?rev=291728&view=rev
Log:
Revert "[CMake][libcxx] Move Python check to main CMake file"

This reverts commit 39441fe9f00a58ffc2fdff92a4b0e8a280a5f444.

Modified:
libcxx/trunk/CMakeLists.txt
libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=291728&r1=291727&r2=291728&view=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Wed Jan 11 17:56:33 2017
@@ -32,15 +32,6 @@ if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURR
   include(HandleOutOfTreeLLVM)
 endif()
 
-if (LIBCXX_STANDALONE_BUILD)
-  include(FindPythonInterp)
-  if( NOT PYTHONINTERP_FOUND )
-message(WARNING "Failed to find python interpreter. "
-"The libc++ test suite will be disabled.")
-set(LLVM_INCLUDE_TESTS OFF)
-  endif()
-endif()
-
 # Require out of source build.
 include(MacroEnsureOutOfSourceBuild)
 MACRO_ENSURE_OUT_OF_SOURCE_BUILD(

Modified: libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake?rev=291728&r1=291727&r2=291728&view=diff
==
--- libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake (original)
+++ libcxx/trunk/cmake/Modules/HandleOutOfTreeLLVM.cmake Wed Jan 11 17:56:33 
2017
@@ -95,6 +95,13 @@ macro(configure_out_of_tree_llvm)
   endif()
 
   # LLVM Options --
+  include(FindPythonInterp)
+  if( NOT PYTHONINTERP_FOUND )
+message(WARNING "Failed to find python interpreter. "
+"The libc++ test suite will be disabled.")
+set(LLVM_INCLUDE_TESTS OFF)
+  endif()
+
   if (NOT DEFINED LLVM_INCLUDE_TESTS)
 set(LLVM_INCLUDE_TESTS ${LLVM_FOUND})
   endif()


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


[libcxx] r291726 - Revert "[CMake][libcxx] Check that we have libcxxabi before using it"

2017-01-11 Thread Petr Hosek via cfe-commits
Author: phosek
Date: Wed Jan 11 17:56:29 2017
New Revision: 291726

URL: http://llvm.org/viewvc/llvm-project?rev=291726&view=rev
Log:
Revert "[CMake][libcxx] Check that we have libcxxabi before using it"

This reverts commit 8c91834411b322ab360eb1f193f489327e719652.

Modified:
libcxx/trunk/CMakeLists.txt

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=291726&r1=291725&r2=291726&view=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Wed Jan 11 17:56:29 2017
@@ -119,8 +119,7 @@ if (LIBCXX_CXX_ABI STREQUAL "default")
   ${LLVM_MAIN_SRC_DIR}/runtimes/libcxxabi/include
 NO_DEFAULT_PATH
   )
-  if ((NOT LIBCXX_STANDALONE_BUILD OR HAVE_LIBCXXABI) AND
-  IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
+  if (IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
 set(LIBCXX_CXX_ABI_INCLUDE_PATHS "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_INTREE 1)


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


[libcxx] r291727 - Revert "[CMake][libcxx] Do not rely on the existence of c++abi or unwind targets"

2017-01-11 Thread Petr Hosek via cfe-commits
Author: phosek
Date: Wed Jan 11 17:56:31 2017
New Revision: 291727

URL: http://llvm.org/viewvc/llvm-project?rev=291727&view=rev
Log:
Revert "[CMake][libcxx] Do not rely on the existence of c++abi or unwind 
targets"

This reverts commit 94fc5a96f58071703d81d14690094dcd266a5e17.

Modified:
libcxx/trunk/CMakeLists.txt
libcxx/trunk/lib/CMakeLists.txt

Modified: libcxx/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/CMakeLists.txt?rev=291727&r1=291726&r2=291727&view=diff
==
--- libcxx/trunk/CMakeLists.txt (original)
+++ libcxx/trunk/CMakeLists.txt Wed Jan 11 17:56:31 2017
@@ -119,7 +119,8 @@ if (LIBCXX_CXX_ABI STREQUAL "default")
   ${LLVM_MAIN_SRC_DIR}/runtimes/libcxxabi/include
 NO_DEFAULT_PATH
   )
-  if (IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
+  if (NOT DEFINED LIBCXX_STANDALONE_BUILD AND
+  IS_DIRECTORY "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi")
 set(LIBCXX_CXX_ABI_INCLUDE_PATHS "${LIBCXX_LIBCXXABI_INCLUDES_INTERNAL}")
 set(LIBCXX_CXX_ABI_INTREE 1)

Modified: libcxx/trunk/lib/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/lib/CMakeLists.txt?rev=291727&r1=291726&r2=291727&view=diff
==
--- libcxx/trunk/lib/CMakeLists.txt (original)
+++ libcxx/trunk/lib/CMakeLists.txt Wed Jan 11 17:56:31 2017
@@ -229,8 +229,7 @@ if (LIBCXX_ENABLE_STATIC)
 if (LIBCXX_CXX_ABI_LIBRARY_PATH)
   set(MERGE_ARCHIVES_SEARCH_PATHS "-L${LIBCXX_CXX_ABI_LIBRARY_PATH}")
 endif()
-if ((TARGET ${LIBCXX_CXX_ABI_LIBRARY}) OR
-(${LIBCXX_CXX_ABI_LIBRARY} STREQUAL "cxxabi(_static|_shared)?" AND 
HAVE_LIBCXXABI))
+if (TARGET ${LIBCXX_CXX_ABI_LIBRARY})
   set(MERGE_ARCHIVES_ABI_TARGET 
"$")
 else()
   set(MERGE_ARCHIVES_ABI_TARGET
@@ -301,9 +300,7 @@ if (LIBCXX_ENABLE_SHARED AND LIBCXX_ENAB
   set(LIBCXX_INTERFACE_LIBRARY_NAMES)
   foreach(lib ${LIBCXX_INTERFACE_LIBRARIES})
 # FIXME: Handle cxxabi_static and unwind_static.
-if (TARGET ${lib} OR
-(${lib} MATCHES "cxxabi(_static|_shared)?" AND HAVE_LIBCXXABI) OR
-(${lib} MATCHES "unwind(_static|_shared)?" AND HAVE_LIBUNWIND))
+if (TARGET ${lib})
   list(APPEND LIBCXX_INTERFACE_LIBRARY_NAMES 
"$")
 else()
   list(APPEND LIBCXX_INTERFACE_LIBRARY_NAMES "${lib}")


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


[PATCH] D28588: Pass -fprofile-sample-use to lto backends.

2017-01-11 Thread Dehao Chen via Phabricator via cfe-commits
danielcdh created this revision.
danielcdh added reviewers: tejohnson, mehdi_amini.
danielcdh added a subscriber: cfe-commits.

LTO backend will not invoke SampleProfileLoader pass even if 
-fprofile-sample-use is specified. This patch passes the flag down so that pass 
manager can add the SampleProfileLoader pass correctly.


https://reviews.llvm.org/D28588

Files:
  lib/CodeGen/BackendUtil.cpp
  test/CodeGen/thinlto_backend.ll


Index: test/CodeGen/thinlto_backend.ll
===
--- test/CodeGen/thinlto_backend.ll
+++ test/CodeGen/thinlto_backend.ll
@@ -8,6 +8,10 @@
 ; RUN: not %clang_cc1 -O2 -o %t1.o -x c %s -c -fthinlto-index=%t.thinlto.bc 
2>&1 | FileCheck %s -check-prefix=CHECK-WARNING
 ; CHECK-WARNING: error: invalid argument '-fthinlto-index={{.*}}' only allowed 
with '-x ir'
 
+; Ensure sample profile pass are passed to backend
+; RUN: %clang -O2 -o %t4.o -x ir %t1.o -c -fthinlto-index=%t.thinlto.bc 
-fprofile-sample-use=%S/Inputs/pgo-sample.prof -mllvm -debug-pass=Structure 
2>&1 | FileCheck %s -check-prefix=CHECK-SAMPLEPGO
+; CHECK-SAMPLEPGO: Sample profile pass
+
 ; Ensure we get expected error for missing index file
 ; RUN: %clang -O2 -o %t4.o -x ir %t1.o -c -fthinlto-index=bad.thinlto.bc 2>&1 
| FileCheck %s -check-prefix=CHECK-ERROR1
 ; CHECK-ERROR1: Error loading index file 'bad.thinlto.bc'
Index: lib/CodeGen/BackendUtil.cpp
===
--- lib/CodeGen/BackendUtil.cpp
+++ lib/CodeGen/BackendUtil.cpp
@@ -862,7 +862,8 @@
 }
 
 static void runThinLTOBackend(ModuleSummaryIndex *CombinedIndex, Module *M,
-  std::unique_ptr OS) {
+  std::unique_ptr OS,
+  std::string SampleProfile) {
   StringMap>
   ModuleToDefinedGVSummaries;
   
CombinedIndex->collectDefinedGVSummariesPerModule(ModuleToDefinedGVSummaries);
@@ -930,6 +931,7 @@
 return llvm::make_unique(std::move(OS));
   };
   lto::Config Conf;
+  Conf.SampleProfile = SampleProfile;
   if (Error E = thinBackend(
   Conf, 0, AddStream, *M, *CombinedIndex, ImportList,
   ModuleToDefinedGVSummaries[M->getModuleIdentifier()], ModuleMap)) {
@@ -965,7 +967,8 @@
 // of an error).
 bool DoThinLTOBackend = CombinedIndex != nullptr;
 if (DoThinLTOBackend) {
-  runThinLTOBackend(CombinedIndex.get(), M, std::move(OS));
+  runThinLTOBackend(CombinedIndex.get(), M, std::move(OS),
+CGOpts.SampleProfileFile);
   return;
 }
   }


Index: test/CodeGen/thinlto_backend.ll
===
--- test/CodeGen/thinlto_backend.ll
+++ test/CodeGen/thinlto_backend.ll
@@ -8,6 +8,10 @@
 ; RUN: not %clang_cc1 -O2 -o %t1.o -x c %s -c -fthinlto-index=%t.thinlto.bc 2>&1 | FileCheck %s -check-prefix=CHECK-WARNING
 ; CHECK-WARNING: error: invalid argument '-fthinlto-index={{.*}}' only allowed with '-x ir'
 
+; Ensure sample profile pass are passed to backend
+; RUN: %clang -O2 -o %t4.o -x ir %t1.o -c -fthinlto-index=%t.thinlto.bc -fprofile-sample-use=%S/Inputs/pgo-sample.prof -mllvm -debug-pass=Structure 2>&1 | FileCheck %s -check-prefix=CHECK-SAMPLEPGO
+; CHECK-SAMPLEPGO: Sample profile pass
+
 ; Ensure we get expected error for missing index file
 ; RUN: %clang -O2 -o %t4.o -x ir %t1.o -c -fthinlto-index=bad.thinlto.bc 2>&1 | FileCheck %s -check-prefix=CHECK-ERROR1
 ; CHECK-ERROR1: Error loading index file 'bad.thinlto.bc'
Index: lib/CodeGen/BackendUtil.cpp
===
--- lib/CodeGen/BackendUtil.cpp
+++ lib/CodeGen/BackendUtil.cpp
@@ -862,7 +862,8 @@
 }
 
 static void runThinLTOBackend(ModuleSummaryIndex *CombinedIndex, Module *M,
-  std::unique_ptr OS) {
+  std::unique_ptr OS,
+  std::string SampleProfile) {
   StringMap>
   ModuleToDefinedGVSummaries;
   CombinedIndex->collectDefinedGVSummariesPerModule(ModuleToDefinedGVSummaries);
@@ -930,6 +931,7 @@
 return llvm::make_unique(std::move(OS));
   };
   lto::Config Conf;
+  Conf.SampleProfile = SampleProfile;
   if (Error E = thinBackend(
   Conf, 0, AddStream, *M, *CombinedIndex, ImportList,
   ModuleToDefinedGVSummaries[M->getModuleIdentifier()], ModuleMap)) {
@@ -965,7 +967,8 @@
 // of an error).
 bool DoThinLTOBackend = CombinedIndex != nullptr;
 if (DoThinLTOBackend) {
-  runThinLTOBackend(CombinedIndex.get(), M, std::move(OS));
+  runThinLTOBackend(CombinedIndex.get(), M, std::move(OS),
+CGOpts.SampleProfileFile);
   return;
 }
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D28590: [Sema] Restrict explicit instantation definition dllexport

2017-01-11 Thread Shoaib Meenai via Phabricator via cfe-commits
smeenai created this revision.
smeenai added reviewers: hans, rnk.
smeenai added subscribers: cfe-commits, steveire.

In the case where the template class itself is already `dllexport`, the
implicit instantiation will have already emitted all members. When we
check the explicit instantiation definition, the `Specialization` will
have inherited the `dllexport` attribute, so we'll attempt to emit all
members for a second time, which causes an assertion failure. Restrict
the exporting to when the `dllexport` attribute is newly introduced by
the explicit instantiation definition.

Fixes PR31608.


https://reviews.llvm.org/D28590

Files:
  lib/Sema/SemaTemplate.cpp
  test/CodeGenCXX/dllexport.cpp


Index: test/CodeGenCXX/dllexport.cpp
===
--- test/CodeGenCXX/dllexport.cpp
+++ test/CodeGenCXX/dllexport.cpp
@@ -732,13 +732,27 @@
 // M32-DAG: define weak_odr dllexport x86_thiscallcc 
%struct.ExplicitInstantiationDeclExportedDefTemplate* 
@"\01??0?$ExplicitInstantiationDeclExportedDefTemplate@H@@QAE@XZ"
 // G32-DAG: define weak_odr x86_thiscallcc void 
@_ZN44ExplicitInstantiationDeclExportedDefTemplateIiE1fEv
 
-template  struct 
ImplicitInstantiationExplicitInstantiationDefExportedTemplate { void f() {} };
+template  struct 
ImplicitInstantiationExportedExplicitInstantiationDefTemplate { virtual void 
f() {} };
+ImplicitInstantiationExportedExplicitInstantiationDefTemplate 
ImplicitInstantiationExportedExplicitInstantiationDefTemplateInstance;
+template struct __declspec(dllexport) 
ImplicitInstantiationExportedExplicitInstantiationDefTemplate;
+USEMEMFUNC(ImplicitInstantiationExportedExplicitInstantiationDefTemplate, 
f);
+// M32-DAG: define weak_odr dllexport x86_thiscallcc void 
@"\01?f@?$ImplicitInstantiationExportedExplicitInstantiationDefTemplate@H@@UAEXXZ"
+// G32-DAG: define weak_odr x86_thiscallcc void 
@_ZN61ImplicitInstantiationExportedExplicitInstantiationDefTemplateIiE1fEv
+
+template  struct __declspec(dllexport) 
ImplicitInstantiationExplicitInstantiationDefExportedTemplate { virtual void 
f() {} };
 ImplicitInstantiationExplicitInstantiationDefExportedTemplate 
ImplicitInstantiationExplicitInstantiationDefExportedTemplateInstance;
-template class __declspec(dllexport) 
ImplicitInstantiationExplicitInstantiationDefExportedTemplate;
+template struct 
ImplicitInstantiationExplicitInstantiationDefExportedTemplate;
 USEMEMFUNC(ImplicitInstantiationExplicitInstantiationDefExportedTemplate, 
f);
-// M32-DAG: define weak_odr dllexport x86_thiscallcc void 
@"\01?f@?$ImplicitInstantiationExplicitInstantiationDefExportedTemplate@H@@QAEXXZ"
+// M32-DAG: define weak_odr dllexport x86_thiscallcc void 
@"\01?f@?$ImplicitInstantiationExplicitInstantiationDefExportedTemplate@H@@UAEXXZ"
 // G32-DAG: define weak_odr x86_thiscallcc void 
@_ZN61ImplicitInstantiationExplicitInstantiationDefExportedTemplateIiE1fEv
 
+template  struct __declspec(dllexport) 
ImplicitInstantiationExportedExplicitInstantiationDefExportedTemplate { virtual 
void f() {} };
+ImplicitInstantiationExportedExplicitInstantiationDefExportedTemplate 
ImplicitInstantiationExportedExplicitInstantiationDefExportedTemplateInstance;
+template struct __declspec(dllexport) 
ImplicitInstantiationExportedExplicitInstantiationDefExportedTemplate;
+USEMEMFUNC(ImplicitInstantiationExportedExplicitInstantiationDefExportedTemplate,
 f);
+// M32-DAG: define weak_odr dllexport x86_thiscallcc void 
@"\01?f@?$ImplicitInstantiationExportedExplicitInstantiationDefExportedTemplate@H@@UAEXXZ"
+// G32-DAG: define weak_odr x86_thiscallcc void 
@_ZN69ImplicitInstantiationExportedExplicitInstantiationDefExportedTemplateIiE1fEv
+
 namespace { struct InternalLinkageType {}; }
 struct __declspec(dllexport) PR23308 {
   void f(InternalLinkageType*);
Index: lib/Sema/SemaTemplate.cpp
===
--- lib/Sema/SemaTemplate.cpp
+++ lib/Sema/SemaTemplate.cpp
@@ -,6 +,7 @@
   Specialization->setTemplateKeywordLoc(TemplateLoc);
   Specialization->setBraceRange(SourceRange());
 
+  bool PreviouslyDLLExported = Specialization->hasAttr();
   if (Attr)
 ProcessDeclAttributeList(S, Specialization, Attr);
 
@@ -7839,8 +7840,9 @@
 
 // Fix a TSK_ImplicitInstantiation followed by a
 // TSK_ExplicitInstantiationDefinition
-if (Old_TSK == TSK_ImplicitInstantiation &&
-Specialization->hasAttr() &&
+bool NewlyDLLExported =
+!PreviouslyDLLExported && Specialization->hasAttr();
+if (Old_TSK == TSK_ImplicitInstantiation && NewlyDLLExported &&
 (Context.getTargetInfo().getCXXABI().isMicrosoft() ||
  Context.getTargetInfo().getTriple().isWindowsItaniumEnvironment())) {
   // In the MS ABI, an explicit instantiation definition can add a dll


Index: test/CodeGenCXX/dllexport.cpp
===
--- test/CodeGenCXX/dllexport.cpp
+++ test/CodeGenCXX/dllexport.cpp
@@ -732,

r291737 - Remove redundant passing around of a "ContainsAutoType" flag.

2017-01-11 Thread Richard Smith via cfe-commits
Author: rsmith
Date: Wed Jan 11 20:27:38 2017
New Revision: 291737

URL: http://llvm.org/viewvc/llvm-project?rev=291737&view=rev
Log:
Remove redundant passing around of a "ContainsAutoType" flag.

This flag serves no purpose other than to prevent us walking through a type to
check whether it contains an 'auto' specifier; this duplication of information
is error-prone, does not appear to provide any performance benefit, and will
become less practical once we support C++1z deduced class template types and
eventually constrained types from the Concepts TS.

No functionality change intended.

Modified:
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Parse/ParseDecl.cpp
cfe/trunk/lib/Parse/ParseDeclCXX.cpp
cfe/trunk/lib/Parse/ParseExprCXX.cpp
cfe/trunk/lib/Parse/Parser.cpp
cfe/trunk/lib/Sema/SemaCoroutine.cpp
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/lib/Sema/SemaDeclObjC.cpp
cfe/trunk/lib/Sema/SemaExprCXX.cpp
cfe/trunk/lib/Sema/SemaOpenMP.cpp
cfe/trunk/lib/Sema/SemaStmt.cpp
cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=291737&r1=291736&r2=291737&view=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Wed Jan 11 20:27:38 2017
@@ -1791,9 +1791,8 @@ public:
   bool SetParamDefaultArgument(ParmVarDecl *Param, Expr *DefaultArg,
SourceLocation EqualLoc);
 
-  void AddInitializerToDecl(Decl *dcl, Expr *init, bool DirectInit,
-bool TypeMayContainAuto);
-  void ActOnUninitializedDecl(Decl *dcl, bool TypeMayContainAuto);
+  void AddInitializerToDecl(Decl *dcl, Expr *init, bool DirectInit);
+  void ActOnUninitializedDecl(Decl *dcl);
   void ActOnInitializerError(Decl *Dcl);
   bool canInitializeWithParenthesizedList(QualType TargetType);
 
@@ -1808,8 +1807,7 @@ public:
   void FinalizeDeclaration(Decl *D);
   DeclGroupPtrTy FinalizeDeclaratorGroup(Scope *S, const DeclSpec &DS,
  ArrayRef Group);
-  DeclGroupPtrTy BuildDeclaratorGroup(MutableArrayRef Group,
-  bool TypeMayContainAuto = true);
+  DeclGroupPtrTy BuildDeclaratorGroup(MutableArrayRef Group);
 
   /// Should be called on all declarations that might have attached
   /// documentation comments.
@@ -4921,8 +4919,7 @@ public:
  TypeSourceInfo *AllocTypeInfo,
  Expr *ArraySize,
  SourceRange DirectInitRange,
- Expr *Initializer,
- bool TypeMayContainAuto = true);
+ Expr *Initializer);
 
   bool CheckAllocatedType(QualType AllocType, SourceLocation Loc,
   SourceRange R);

Modified: cfe/trunk/lib/Parse/ParseDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseDecl.cpp?rev=291737&r1=291736&r2=291737&view=diff
==
--- cfe/trunk/lib/Parse/ParseDecl.cpp (original)
+++ cfe/trunk/lib/Parse/ParseDecl.cpp Wed Jan 11 20:27:38 2017
@@ -1591,7 +1591,7 @@ Parser::ParseSimpleDeclaration(unsigned
 DS.complete(TheDecl);
 if (AnonRecord) {
   Decl* decls[] = {AnonRecord, TheDecl};
-  return Actions.BuildDeclaratorGroup(decls, /*TypeMayContainAuto=*/false);
+  return Actions.BuildDeclaratorGroup(decls);
 }
 return Actions.ConvertDeclToDeclGroup(TheDecl);
   }
@@ -2045,8 +2045,6 @@ Decl *Parser::ParseDeclarationAfterDecla
 }
   }
 
-  bool TypeContainsAuto = D.getDeclSpec().containsPlaceholderType();
-
   // Parse declarator '=' initializer.
   // If a '==' or '+=' is found, suggest a fixit to '='.
   if (isTokenEqualOrEqualTypo()) {
@@ -2106,7 +2104,7 @@ Decl *Parser::ParseDeclarationAfterDecla
 Actions.ActOnInitializerError(ThisDecl);
   } else
 Actions.AddInitializerToDecl(ThisDecl, Init.get(),
- /*DirectInit=*/false, TypeContainsAuto);
+ /*DirectInit=*/false);
 }
   } else if (Tok.is(tok::l_paren)) {
 // Parse C++ direct initializer: '(' expression-list ')'
@@ -2149,7 +2147,7 @@ Decl *Parser::ParseDeclarationAfterDecla
   T.getCloseLocation(),
   Exprs);
   Actions.AddInitializerToDecl(ThisDecl, Initializer.get(),
-   /*DirectInit=*/true, TypeContainsAuto);
+   /*DirectInit=*/true);
 }
   } else if (getLangOpts().CPlusPlus11 && Tok.is(tok::l_brace) &&
  (!CurParsedObjCImpl || !D.isFunctionDeclarator())) {
@@ -2171,11 +2169,10 @@ Decl *Parser::ParseDeclarationAft

[PATCH] D28591: [libcxx] [test] Don't ask whether Incomplete& can be assigned to.

2017-01-11 Thread Stephan T. Lavavej via Phabricator via cfe-commits
STL_MSFT created this revision.
STL_MSFT added reviewers: EricWF, mclow.lists.
STL_MSFT added a subscriber: cfe-commits.

[libcxx] [test] Don't ask whether Incomplete& can be assigned to.

This is the subject of an active NB comment. Regardless of what the Working
Paper currently says, asking this question is morally wrong, because the
answer can change when the type is completed. C1XX now detects such
precondition violations and complains about them; perhaps Clang should too.


https://reviews.llvm.org/D28591

Files:
  test/std/utilities/meta/meta.unary/meta.unary.prop/is_assignable.pass.cpp


Index: test/std/utilities/meta/meta.unary/meta.unary.prop/is_assignable.pass.cpp
===
--- test/std/utilities/meta/meta.unary/meta.unary.prop/is_assignable.pass.cpp
+++ test/std/utilities/meta/meta.unary/meta.unary.prop/is_assignable.pass.cpp
@@ -82,5 +82,4 @@
 
 //  pointer to incomplete template type
test_is_assignable*&, X*> ();
-test_is_not_assignable();
 }


Index: test/std/utilities/meta/meta.unary/meta.unary.prop/is_assignable.pass.cpp
===
--- test/std/utilities/meta/meta.unary/meta.unary.prop/is_assignable.pass.cpp
+++ test/std/utilities/meta/meta.unary/meta.unary.prop/is_assignable.pass.cpp
@@ -82,5 +82,4 @@
 
 //  pointer to incomplete template type
 	test_is_assignable*&, X*> ();
-test_is_not_assignable();
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D28592: [libcxx] [test] Fix MSVC warning C4127 "conditional expression is constant".

2017-01-11 Thread Stephan T. Lavavej via Phabricator via cfe-commits
STL_MSFT created this revision.
STL_MSFT added reviewers: EricWF, mclow.lists.
STL_MSFT added a subscriber: cfe-commits.

[libcxx] [test] Fix MSVC warning C4127 "conditional expression is constant".

MSVC has a compiler warning (enabled at /https://reviews.llvm.org/W4) that's 
potentially useful,
although slightly annoying to library devs who know what they're doing.
In the latest version of the compiler, the warning is suppressed when the
compiler sees simple tests like "if (name_of_thing)", so extracting comparison
expressions into named constants is a workaround. This is useful for ensuring
that libraries are C4127-clean.


https://reviews.llvm.org/D28592

Files:
  
test/std/input.output/iostream.format/output.streams/ostream.formatted/ostream.inserters.arithmetic/minus1.pass.cpp
  test/std/utilities/function.objects/unord.hash/enum.pass.cpp
  test/std/utilities/function.objects/unord.hash/integral.pass.cpp
  test/std/utilities/template.bitset/bitset.members/all.pass.cpp
  test/std/utilities/template.bitset/bitset.members/any.pass.cpp
  test/std/utilities/template.bitset/bitset.members/index.pass.cpp
  test/std/utilities/template.bitset/bitset.members/index_const.pass.cpp
  test/std/utilities/template.bitset/bitset.members/none.pass.cpp
  test/std/utilities/template.bitset/bitset.members/op_eq_eq.pass.cpp

Index: test/std/utilities/template.bitset/bitset.members/op_eq_eq.pass.cpp
===
--- test/std/utilities/template.bitset/bitset.members/op_eq_eq.pass.cpp
+++ test/std/utilities/template.bitset/bitset.members/op_eq_eq.pass.cpp
@@ -36,7 +36,8 @@
 const std::bitset v1 = make_bitset();
 std::bitset v2 = v1;
 assert(v1 == v2);
-if (N > 0)
+const bool greater_than_0 = N > 0;
+if (greater_than_0)
 {
 v2[N/2].flip();
 assert(v1 != v2);
Index: test/std/utilities/template.bitset/bitset.members/none.pass.cpp
===
--- test/std/utilities/template.bitset/bitset.members/none.pass.cpp
+++ test/std/utilities/template.bitset/bitset.members/none.pass.cpp
@@ -20,7 +20,8 @@
 assert(v.none() == true);
 v.set();
 assert(v.none() == (N == 0));
-if (N > 1)
+const bool greater_than_1 = N > 1;
+if (greater_than_1)
 {
 v[N/2] = false;
 assert(v.none() == false);
Index: test/std/utilities/template.bitset/bitset.members/index_const.pass.cpp
===
--- test/std/utilities/template.bitset/bitset.members/index_const.pass.cpp
+++ test/std/utilities/template.bitset/bitset.members/index_const.pass.cpp
@@ -31,7 +31,8 @@
 void test_index_const()
 {
 const std::bitset v1 = make_bitset();
-if (N > 0)
+const bool greater_than_0 = N > 0;
+if (greater_than_0)
 {
 assert(v1[N/2] == v1.test(N/2));
 }
Index: test/std/utilities/template.bitset/bitset.members/index.pass.cpp
===
--- test/std/utilities/template.bitset/bitset.members/index.pass.cpp
+++ test/std/utilities/template.bitset/bitset.members/index.pass.cpp
@@ -31,7 +31,8 @@
 void test_index_const()
 {
 std::bitset v1 = make_bitset();
-if (N > 0)
+const bool greater_than_0 = N > 0;
+if (greater_than_0)
 {
 assert(v1[N/2] == v1.test(N/2));
 typename std::bitset::reference r = v1[N/2];
Index: test/std/utilities/template.bitset/bitset.members/any.pass.cpp
===
--- test/std/utilities/template.bitset/bitset.members/any.pass.cpp
+++ test/std/utilities/template.bitset/bitset.members/any.pass.cpp
@@ -20,7 +20,8 @@
 assert(v.any() == false);
 v.set();
 assert(v.any() == (N != 0));
-if (N > 1)
+const bool greater_than_1 = N > 1;
+if (greater_than_1)
 {
 v[N/2] = false;
 assert(v.any() == true);
Index: test/std/utilities/template.bitset/bitset.members/all.pass.cpp
===
--- test/std/utilities/template.bitset/bitset.members/all.pass.cpp
+++ test/std/utilities/template.bitset/bitset.members/all.pass.cpp
@@ -20,7 +20,8 @@
 assert(v.all() == (N == 0));
 v.set();
 assert(v.all() == true);
-if (N > 1)
+const bool greater_than_1 = N > 1;
+if (greater_than_1)
 {
 v[N/2] = false;
 assert(v.all() == false);
Index: test/std/utilities/function.objects/unord.hash/integral.pass.cpp
===
--- test/std/utilities/function.objects/unord.hash/integral.pass.cpp
+++ test/std/utilities/function.objects/unord.hash/integral.pass.cpp
@@ -36,7 +36,8 @@
 for (int i = 0; i <= 5; ++i)
 {
 T t(static_cast(i));
-if (sizeof(T) <= sizeof(std::size_t))
+const bool small = sizeof(T) <= sizeof(std::size_t);
+if (small)
 {
   

[PATCH] D28588: Pass -fprofile-sample-use to lto backends.

2017-01-11 Thread Teresa Johnson via Phabricator via cfe-commits
tejohnson accepted this revision.
tejohnson added a comment.
This revision is now accepted and ready to land.

LGTM


https://reviews.llvm.org/D28588



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


[PATCH] D28473: Implement http://wg21.link/P0426 Constexpr for std::char_traits

2017-01-11 Thread Marshall Clow via Phabricator via cfe-commits
mclow.lists accepted this revision.
mclow.lists added a reviewer: mclow.lists.
mclow.lists added a comment.
This revision is now accepted and ready to land.

revision 291741


https://reviews.llvm.org/D28473



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


[libcxx] r291741 - Implement P0426: Constexpr for std::char_traits

2017-01-11 Thread Marshall Clow via cfe-commits
Author: marshall
Date: Wed Jan 11 22:37:14 2017
New Revision: 291741

URL: http://llvm.org/viewvc/llvm-project?rev=291741&view=rev
Log:
Implement P0426: Constexpr for std::char_traits

Modified:
libcxx/trunk/include/__string

libcxx/trunk/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char/assign2.pass.cpp

libcxx/trunk/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char/compare.pass.cpp

libcxx/trunk/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char/find.pass.cpp

libcxx/trunk/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char/length.pass.cpp

libcxx/trunk/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char16_t/assign2.pass.cpp

libcxx/trunk/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char16_t/compare.pass.cpp

libcxx/trunk/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char16_t/find.pass.cpp

libcxx/trunk/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char16_t/length.pass.cpp

libcxx/trunk/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char32_t/assign2.pass.cpp

libcxx/trunk/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char32_t/compare.pass.cpp

libcxx/trunk/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char32_t/find.pass.cpp

libcxx/trunk/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.char32_t/length.pass.cpp

libcxx/trunk/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.wchar.t/assign2.pass.cpp

libcxx/trunk/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.wchar.t/compare.pass.cpp

libcxx/trunk/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.wchar.t/find.pass.cpp

libcxx/trunk/test/std/strings/char.traits/char.traits.specializations/char.traits.specializations.wchar.t/length.pass.cpp

Modified: libcxx/trunk/include/__string
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__string?rev=291741&r1=291740&r2=291741&view=diff
==
--- libcxx/trunk/include/__string (original)
+++ libcxx/trunk/include/__string Wed Jan 11 22:37:14 2017
@@ -26,13 +26,14 @@ struct char_traits
 typedef streampos pos_type;
 typedef mbstate_t state_type;
 
-static void assign(char_type& c1, const char_type& c2) noexcept;
+static constexpr void assign(char_type& c1, const char_type& c2) noexcept;
 static constexpr bool eq(char_type c1, char_type c2) noexcept;
 static constexpr bool lt(char_type c1, char_type c2) noexcept;
 
-static int  compare(const char_type* s1, const char_type* s2, 
size_t n);
-static size_t   length(const char_type* s);
-static const char_type* find(const char_type* s, size_t n, const 
char_type& a);
+static constexpr intcompare(const char_type* s1, const char_type* s2, 
size_t n);
+static constexpr size_t length(const char_type* s);
+static constexpr const char_type* 
+find(const char_type* s, size_t n, const 
char_type& a);
 static char_type*   move(char_type* s1, const char_type* s2, size_t n);
 static char_type*   copy(char_type* s1, const char_type* s2, size_t n);
 static char_type*   assign(char_type* s, size_t n, char_type a);
@@ -77,18 +78,19 @@ struct _LIBCPP_TEMPLATE_VIS char_traits
 typedef streampos pos_type;
 typedef mbstate_t state_type;
 
-static inline void assign(char_type& __c1, const char_type& __c2) _NOEXCEPT
-{__c1 = __c2;}
+static inline void _LIBCPP_CONSTEXPR_AFTER_CXX14
+assign(char_type& __c1, const char_type& __c2) _NOEXCEPT {__c1 = __c2;}
 static inline _LIBCPP_CONSTEXPR bool eq(char_type __c1, char_type __c2) 
_NOEXCEPT
 {return __c1 == __c2;}
 static inline _LIBCPP_CONSTEXPR bool lt(char_type __c1, char_type __c2) 
_NOEXCEPT
 {return __c1 < __c2;}
 
-static int  compare(const char_type* __s1, const char_type* 
__s2, size_t __n);
-_LIBCPP_INLINE_VISIBILITY
-static size_t   length(const char_type* __s);
-_LIBCPP_INLINE_VISIBILITY
-static const char_type* find(const char_type* __s, size_t __n, const 
char_type& __a);
+static _LIBCPP_CONSTEXPR_AFTER_CXX14
+int compare(const char_type* __s1, const char_type* __s2, size_t __n);
+_LIBCPP_INLINE_VISIBILITY static _LIBCPP_CONSTEXPR_AFTER_CXX14
+size_t length(const char_type* __s);
+_LIBCPP_INLINE_VISIBILITY static _LIBCPP_CONSTEXPR_AFTER_CXX14
+const char_type* find(const char_type* __s

[libcxx] r291742 - disable use of __builtin_memcmp temporarily to get the tests passing again

2017-01-11 Thread Marshall Clow via cfe-commits
Author: marshall
Date: Wed Jan 11 23:40:58 2017
New Revision: 291742

URL: http://llvm.org/viewvc/llvm-project?rev=291742&view=rev
Log:
disable use of __builtin_memcmp temporarily to get the tests passing again

Modified:
libcxx/trunk/include/__string

Modified: libcxx/trunk/include/__string
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__string?rev=291742&r1=291741&r2=291742&view=diff
==
--- libcxx/trunk/include/__string (original)
+++ libcxx/trunk/include/__string Wed Jan 11 23:40:58 2017
@@ -209,9 +209,8 @@ struct _LIBCPP_TEMPLATE_VIS char_traits<
 static inline _LIBCPP_CONSTEXPR bool lt(char_type __c1, char_type __c2) 
_NOEXCEPT
 {return (unsigned char)__c1 < (unsigned char)__c2;}
 
-static inline _LIBCPP_CONSTEXPR_AFTER_CXX14
-int compare(const char_type* __s1, const char_type* __s2, size_t __n) 
_NOEXCEPT
-{return __n == 0 ? 0 : __builtin_memcmp(__s1, __s2, __n);}
+static _LIBCPP_CONSTEXPR_AFTER_CXX14
+int compare(const char_type* __s1, const char_type* __s2, size_t __n) 
_NOEXCEPT;
 static inline size_t _LIBCPP_CONSTEXPR_AFTER_CXX14
 length(const char_type* __s)  _NOEXCEPT {return __builtin_strlen(__s);}
 static _LIBCPP_CONSTEXPR_AFTER_CXX14
@@ -239,6 +238,28 @@ struct _LIBCPP_TEMPLATE_VIS char_traits<
 };
 
 inline _LIBCPP_CONSTEXPR_AFTER_CXX14
+int
+char_traits::compare(const char_type* __s1, const char_type* __s2, 
size_t __n) _NOEXCEPT
+{
+if (__n == 0)
+return 0;
+#ifdef _LIBCPP_BUILTIN_MEMCMP_ISCONSTEXPR
+return __builtin_memcmp(__s1, __s2, __n);
+#elif _LIBCPP_STD_VER <= 14
+return memcmp(__s1, __s2, __n);
+#else
+for (; __n; --__n, ++__s1, ++__s2)
+{
+if (lt(*__s1, *__s2))
+return -1;
+if (lt(*__s2, *__s1))
+return 1;
+}
+return 0;
+#endif
+}
+
+inline _LIBCPP_CONSTEXPR_AFTER_CXX14
 const char*
 char_traits::find(const char_type* __s, size_t __n, const char_type& 
__a) _NOEXCEPT
 {


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


[PATCH] D28080: [Docs][OpenCL] Added OpenCL feature description to user manual.

2017-01-11 Thread Pekka Jääskeläinen via Phabricator via cfe-commits
pekka.jaaskelainen added inline comments.



Comment at: docs/UsersManual.rst:2120
+  that can be used across GPU toolchains. The implementation follows `the SPIR
+  specification `_. There are two flavors 
available
+  for 32 and 64 bits.

Anastasia wrote:
> bader wrote:
> > pekka.jaaskelainen wrote:
> > > Which version of SPIR is generated?
> > For -cl-std=CL1.x (where x is 0, 1 or 2), SPIR version is 1.2.
> > For -cl-std=CL2.0, SPIR version is 2.0.
> Is it worth mentioning this in this doc?
I think so as SPIR V is now there also.



Comment at: docs/UsersManual.rst:2130
+
+- x86 is used by some implementations that are x86 compatible
+  (e.g. `POCL `_) and currently remains for backwards

Anastasia wrote:
> pekka.jaaskelainen wrote:
> > This is a bit confusing paragraph, probably due to my confusing 
> > explanations of the problems with pocl. Currently pocl tries not to use 
> > FASM for preserving logical AS IDs to LLVM IR due to the bunch of problems 
> > it constantly produces with seemingly little benefits for common CPUs. My 
> > patch related to this considered only the argument info switch. Now pocl 
> > only derives the logical iDS from kernel arguments (and all other IDs 
> > within the body of the IR function are lost for flat machines).  In my 
> > patch, the argument info's address space IDs were made constant and 
> > identical to SPIR's as previously they were the target's (which meant 
> > losing the AS IDs altogether for flat AS machines).
> > 
> > You seem to document the arg-info md switch later, so this paragraph might 
> > be removed or converted to my pocl blurb which mentions the need for 
> > further processing for CPUs.
> Yes, it's perhaps a bit confusing indeed. I find the usage of the x86 backend 
> for OpenCL is generally a bit confusing. Also there are a lot of program 
> paths even in Clang that don't play well for OpenCL purposes or are not 
> handled properly and are therefore a source of bugs.
> 
> I was just wondering whether it would be possible to switch to using SPIR as 
> a generic target at some point in the future and "deprecate" the x86 target 
> for OpenCL . Do you think this might work for POCL? At the same time we have 
> upcoming SPIR-V support as a new feature that might reshape things.
> 
> Regarding the address space I just know that it's common to use fake address 
> space map with the x86 backend for some out of tree implementations to add 
> missing memory segments to this target. That's why I added this text here.
> 
> 
We have considered using SPIR internally, but it is likely to bring the same 
problems as with the FASM as we need to convert to the target bitcode to ensure 
all target specific IR level optimizations (especially vectorization) is 
applied properly. Why do you think using the real target when generating from 
OpenCL C kernels is problematic? 



Comment at: docs/UsersManual.rst:2133
+
+- x86 is used by some implementations that are x86 compatible and currently
+  remains for backwards compatibility (with older implementations prior to

ARM (and others) are treated similarly in pocl: OpenCL C is just yet another 
frontend language in this picture, like C/C++. I would not "deprecate" that 
path as of yet as forcing to another intermediate representation (which SPIR 
basically is, albeit derived from LLVM IR) always loses some information on the 
way.


https://reviews.llvm.org/D28080



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


[libcxx] r291743 - [libc++] Pair _aligned_malloc with _aligned_free

2017-01-11 Thread Shoaib Meenai via cfe-commits
Author: smeenai
Date: Thu Jan 12 00:22:36 2017
New Revision: 291743

URL: http://llvm.org/viewvc/llvm-project?rev=291743&view=rev
Log:
[libc++] Pair _aligned_malloc with _aligned_free

Attempting to pair an `_aligned_malloc` with a regular free causes heap
corruption. Pairing with `_aligned_free` is required instead.

Makes the following libc++ tests pass on Windows:

```
std/language.support/support.dynamic/new.delete/new.delete.array/new_align_val_t.pass.cpp
std/language.support/support.dynamic/new.delete/new.delete.array/new_align_val_t_nothrow.pass.cpp
std/language.support/support.dynamic/new.delete/new.delete.single/new_align_val_t.pass.cpp
std/language.support/support.dynamic/new.delete/new.delete.single/new_align_val_t_nothrow.pass.cpp
```

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

Modified:
libcxx/trunk/src/new.cpp

Modified: libcxx/trunk/src/new.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/src/new.cpp?rev=291743&r1=291742&r2=291743&view=diff
==
--- libcxx/trunk/src/new.cpp (original)
+++ libcxx/trunk/src/new.cpp Thu Jan 12 00:22:36 2017
@@ -198,7 +198,11 @@ void
 operator delete(void* ptr, std::align_val_t) _NOEXCEPT
 {
 if (ptr)
+#if defined(_LIBCPP_MSVCRT)
+::_aligned_free(ptr);
+#else
 ::free(ptr);
+#endif
 }
 
 _LIBCPP_WEAK


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


[PATCH] D28512: [libc++] Pair _aligned_malloc with _aligned_free

2017-01-11 Thread Shoaib Meenai via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL291743: [libc++] Pair _aligned_malloc with _aligned_free 
(authored by smeenai).

Changed prior to commit:
  https://reviews.llvm.org/D28512?vs=83783&id=84075#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D28512

Files:
  libcxx/trunk/src/new.cpp


Index: libcxx/trunk/src/new.cpp
===
--- libcxx/trunk/src/new.cpp
+++ libcxx/trunk/src/new.cpp
@@ -198,7 +198,11 @@
 operator delete(void* ptr, std::align_val_t) _NOEXCEPT
 {
 if (ptr)
+#if defined(_LIBCPP_MSVCRT)
+::_aligned_free(ptr);
+#else
 ::free(ptr);
+#endif
 }
 
 _LIBCPP_WEAK


Index: libcxx/trunk/src/new.cpp
===
--- libcxx/trunk/src/new.cpp
+++ libcxx/trunk/src/new.cpp
@@ -198,7 +198,11 @@
 operator delete(void* ptr, std::align_val_t) _NOEXCEPT
 {
 if (ptr)
+#if defined(_LIBCPP_MSVCRT)
+::_aligned_free(ptr);
+#else
 ::free(ptr);
+#endif
 }
 
 _LIBCPP_WEAK
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D28231: -Wunreachable-code: Avoid multiple diagnostics that are triggered by the same source range and fix the unary operator fixit source range

2017-01-11 Thread Akira Hatanaka via Phabricator via cfe-commits
ahatanak accepted this revision.
ahatanak added a comment.
This revision is now accepted and ready to land.

Thanks, LGTM


Repository:
  rL LLVM

https://reviews.llvm.org/D28231



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