r282056 - clang-format: [JS] do not wrapp @returns tags.

2016-09-21 Thread Martin Probst via cfe-commits
Author: mprobst
Date: Wed Sep 21 01:56:38 2016
New Revision: 282056

URL: http://llvm.org/viewvc/llvm-project?rev=282056&view=rev
Log:
clang-format: [JS] do not wrapp @returns tags.

Summary: @returns is incorrect code, the standard is @return. However wrapping 
it can still confuse users.

Reviewers: djasper

Subscribers: klimek, cfe-commits

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

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

Modified: cfe/trunk/lib/Format/Format.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/Format.cpp?rev=282056&r1=282055&r2=282056&view=diff
==
--- cfe/trunk/lib/Format/Format.cpp (original)
+++ cfe/trunk/lib/Format/Format.cpp Wed Sep 21 01:56:38 2016
@@ -613,7 +613,8 @@ FormatStyle getGoogleStyle(FormatStyle::
 GoogleStyle.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_Empty;
 GoogleStyle.AlwaysBreakBeforeMultilineStrings = false;
 GoogleStyle.BreakBeforeTernaryOperators = false;
-GoogleStyle.CommentPragmas = 
"(taze:|@(export|requirecss|return|see|visibility)) ";
+GoogleStyle.CommentPragmas =
+"(taze:|@(export|requirecss|return|returns|see|visibility)) ";
 GoogleStyle.MaxEmptyLinesToKeep = 3;
 GoogleStyle.NamespaceIndentation = FormatStyle::NI_All;
 GoogleStyle.SpacesInContainerLiterals = false;


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


Re: [PATCH] D24767: clang-format: [JS] do not wrapp @returns tags.

2016-09-21 Thread Martin Probst via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL282056: clang-format: [JS] do not wrapp @returns tags. 
(authored by mprobst).

Changed prior to commit:
  https://reviews.llvm.org/D24767?vs=71938&id=72010#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D24767

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

Index: cfe/trunk/lib/Format/Format.cpp
===
--- cfe/trunk/lib/Format/Format.cpp
+++ cfe/trunk/lib/Format/Format.cpp
@@ -613,7 +613,8 @@
 GoogleStyle.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_Empty;
 GoogleStyle.AlwaysBreakBeforeMultilineStrings = false;
 GoogleStyle.BreakBeforeTernaryOperators = false;
-GoogleStyle.CommentPragmas = 
"(taze:|@(export|requirecss|return|see|visibility)) ";
+GoogleStyle.CommentPragmas =
+"(taze:|@(export|requirecss|return|returns|see|visibility)) ";
 GoogleStyle.MaxEmptyLinesToKeep = 3;
 GoogleStyle.NamespaceIndentation = FormatStyle::NI_All;
 GoogleStyle.SpacesInContainerLiterals = false;


Index: cfe/trunk/lib/Format/Format.cpp
===
--- cfe/trunk/lib/Format/Format.cpp
+++ cfe/trunk/lib/Format/Format.cpp
@@ -613,7 +613,8 @@
 GoogleStyle.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_Empty;
 GoogleStyle.AlwaysBreakBeforeMultilineStrings = false;
 GoogleStyle.BreakBeforeTernaryOperators = false;
-GoogleStyle.CommentPragmas = "(taze:|@(export|requirecss|return|see|visibility)) ";
+GoogleStyle.CommentPragmas =
+"(taze:|@(export|requirecss|return|returns|see|visibility)) ";
 GoogleStyle.MaxEmptyLinesToKeep = 3;
 GoogleStyle.NamespaceIndentation = FormatStyle::NI_All;
 GoogleStyle.SpacesInContainerLiterals = false;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D24792: [analyzer] Fix crash in RetainCountChecker::checkEndFunction

2016-09-21 Thread Alexander Shaposhnikov via cfe-commits
alexshap added a comment.

Without the changes:
F2438373: Screen Shot 2016-09-21 at 12.38.22 AM.png 

With the patch the tests are green.


Repository:
  rL LLVM

https://reviews.llvm.org/D24792



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


Re: [PATCH] D24192: [clang-refactor] introducing clang-refactor

2016-09-21 Thread Eric Liu via cfe-commits
ioeric added inline comments.


Comment at: clang-refactor/driver/Driver.cpp:36
@@ +35,3 @@
+argv[1] = (llvm::Twine(argv[0]) + " " + 
llvm::Twine(argv[1])).str().c_str();
+Manager.dispatch(Command, argc - 1, argv + 1);
+  } else {

arphaman wrote:
> Is there a particular reason why you don't return a value that's returned by 
> Manager.dispatch here? It seems odd to me that Manager.dispatch returns an 
> integer value that's not actually used here.
BTW, isn't `argv[1]` pointing to a temp string above?


https://reviews.llvm.org/D24192



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


r282059 - PR30401: Fix substitutions for functions with abi_tag

2016-09-21 Thread Dmitry Polukhin via cfe-commits
Author: dpolukhin
Date: Wed Sep 21 03:27:03 2016
New Revision: 282059

URL: http://llvm.org/viewvc/llvm-project?rev=282059&view=rev
Log:
PR30401: Fix substitutions for functions with abi_tag

Modified:
cfe/trunk/lib/AST/ItaniumMangle.cpp
cfe/trunk/test/CodeGenCXX/mangle-abi-tag.cpp

Modified: cfe/trunk/lib/AST/ItaniumMangle.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ItaniumMangle.cpp?rev=282059&r1=282058&r2=282059&view=diff
==
--- cfe/trunk/lib/AST/ItaniumMangle.cpp (original)
+++ cfe/trunk/lib/AST/ItaniumMangle.cpp Wed Sep 21 03:27:03 2016
@@ -405,12 +405,14 @@ public:
   CXXNameMangler(CXXNameMangler &Outer, raw_ostream &Out_)
   : Context(Outer.Context), Out(Out_), NullOut(false),
 Structor(Outer.Structor), StructorType(Outer.StructorType),
-SeqID(Outer.SeqID), AbiTagsRoot(AbiTags) {}
+SeqID(Outer.SeqID), AbiTagsRoot(AbiTags),
+Substitutions(Outer.Substitutions) {}
 
   CXXNameMangler(CXXNameMangler &Outer, llvm::raw_null_ostream &Out_)
   : Context(Outer.Context), Out(Out_), NullOut(true),
 Structor(Outer.Structor), StructorType(Outer.StructorType),
-SeqID(Outer.SeqID), AbiTagsRoot(AbiTags) {}
+SeqID(Outer.SeqID), AbiTagsRoot(AbiTags),
+Substitutions(Outer.Substitutions) {}
 
 #if MANGLE_CHECKER
   ~CXXNameMangler() {
@@ -458,6 +460,8 @@ private:
   void addSubstitution(QualType T);
   void addSubstitution(TemplateName Template);
   void addSubstitution(uintptr_t Ptr);
+  // Destructive copy substitutions from other mangler.
+  void extendSubstitutions(CXXNameMangler* Other);
 
   void mangleUnresolvedPrefix(NestedNameSpecifier *qualifier,
   bool recursive = false);
@@ -685,6 +689,10 @@ void CXXNameMangler::mangleFunctionEncod
   // Output name with implicit tags and function encoding from temporary 
buffer.
   mangleNameWithAbiTags(FD, &AdditionalAbiTags);
   Out << FunctionEncodingStream.str().substr(EncodingPositionStart);
+
+  // Function encoding could create new substitutions so we have to add
+  // temp mangled substitutions to main mangler.
+  extendSubstitutions(&FunctionEncodingMangler);
 }
 
 void CXXNameMangler::mangleFunctionEncodingBareType(const FunctionDecl *FD) {
@@ -4426,6 +4434,14 @@ void CXXNameMangler::addSubstitution(uin
   Substitutions[Ptr] = SeqID++;
 }
 
+void CXXNameMangler::extendSubstitutions(CXXNameMangler* Other) {
+  assert(Other->SeqID >= SeqID && "Must be superset of substitutions!");
+  if (Other->SeqID > SeqID) {
+Substitutions.swap(Other->Substitutions);
+SeqID = Other->SeqID;
+  }
+}
+
 CXXNameMangler::AbiTagList
 CXXNameMangler::makeFunctionReturnTypeTags(const FunctionDecl *FD) {
   // When derived abi tags are disabled there is no need to make any list.

Modified: cfe/trunk/test/CodeGenCXX/mangle-abi-tag.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/mangle-abi-tag.cpp?rev=282059&r1=282058&r2=282059&view=diff
==
--- cfe/trunk/test/CodeGenCXX/mangle-abi-tag.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/mangle-abi-tag.cpp Wed Sep 21 03:27:03 2016
@@ -203,3 +203,19 @@ void f18_test() {
 }
 // A18::operator A[abi:A][abi:B]() but GCC adds the same tags twice!
 // CHECK-DAG: define linkonce_odr {{.+}} @_ZN3A18cv1AB1AB1BEv(
+
+namespace N19 {
+  class A {};
+  class __attribute__((abi_tag("B"))) B {};
+  class D {};
+  class F {};
+
+  template
+  class C {};
+
+  B foo(A, D);
+}
+void f19_test(N19::C, N19::F, N19::D) {
+}
+// f19_test(N19::C, N19::F, N19::D)
+// CHECK-DAG: define void 
@_Z8f19_testN3N191CINS_1AEXadL_ZNS_3fooB1BES1_NS_1DENS_1FES2_(


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


Re: [PATCH] D24704: PR30401: Fix substitutions for functions with abi_tag

2016-09-21 Thread Dmitry Polukhin via cfe-commits
DmitryPolukhin closed this revision.
DmitryPolukhin added a comment.

Committed as https://reviews.llvm.org/rL282059


https://reviews.llvm.org/D24704



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


[libcxxabi] r282062 - [libcxxabi] cleanup the use of LIBCXXABI_HAS_NO_THREADS macro (NFC)

2016-09-21 Thread Asiri Rathnayake via cfe-commits
Author: asiri
Date: Wed Sep 21 04:09:32 2016
New Revision: 282062

URL: http://llvm.org/viewvc/llvm-project?rev=282062&view=rev
Log:
[libcxxabi] cleanup the use of LIBCXXABI_HAS_NO_THREADS macro (NFC)

Align the naming / use of the macro LIBCXXABI_HAS_NO_THREADS to follow what we
have in libcxx. NFC.

Modified:
libcxxabi/trunk/CMakeLists.txt
libcxxabi/trunk/src/config.h
libcxxabi/trunk/src/cxa_exception.cpp
libcxxabi/trunk/src/cxa_exception_storage.cpp
libcxxabi/trunk/src/cxa_guard.cpp
libcxxabi/trunk/src/fallback_malloc.ipp
libcxxabi/trunk/test/libcxxabi/test/config.py
libcxxabi/trunk/test/test_exception_storage.pass.cpp
libcxxabi/trunk/test/test_guard.pass.cpp

Modified: libcxxabi/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/CMakeLists.txt?rev=282062&r1=282061&r2=282062&view=diff
==
--- libcxxabi/trunk/CMakeLists.txt (original)
+++ libcxxabi/trunk/CMakeLists.txt Wed Sep 21 04:09:32 2016
@@ -326,7 +326,7 @@ if (NOT LIBCXXABI_ENABLE_THREADS)
 " be set to ON when LIBCXXABI_ENABLE_THREADS"
 " is also set to ON.")
   endif()
-  add_definitions(-DLIBCXXABI_HAS_NO_THREADS=1)
+  add_definitions(-D_LIBCXXABI_HAS_NO_THREADS)
 endif()
 
 if (LIBCXXABI_HAS_PTHREAD_API)

Modified: libcxxabi/trunk/src/config.h
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/src/config.h?rev=282062&r1=282061&r2=282062&view=diff
==
--- libcxxabi/trunk/src/config.h (original)
+++ libcxxabi/trunk/src/config.h Wed Sep 21 04:09:32 2016
@@ -16,11 +16,6 @@
 
 #include 
 
-// Set this in the CXXFLAGS when you need it
-#if !defined(LIBCXXABI_HAS_NO_THREADS)
-#  define LIBCXXABI_HAS_NO_THREADS 0
-#endif
-
 // Set this in the CXXFLAGS when you need it, because otherwise we'd have to
 // #if !defined(__linux__) && !defined(__APPLE__) && ...
 // and so-on for *every* platform.

Modified: libcxxabi/trunk/src/cxa_exception.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/src/cxa_exception.cpp?rev=282062&r1=282061&r2=282062&view=diff
==
--- libcxxabi/trunk/src/cxa_exception.cpp (original)
+++ libcxxabi/trunk/src/cxa_exception.cpp Wed Sep 21 04:09:32 2016
@@ -17,7 +17,7 @@
 #include // for std::terminate
 #include   // for malloc, free
 #include   // for memset
-#if !LIBCXXABI_HAS_NO_THREADS
+#ifndef _LIBCXXABI_HAS_NO_THREADS
 #  include   // for fallback_malloc.ipp's mutexes
 #endif
 #include "cxa_exception.hpp"

Modified: libcxxabi/trunk/src/cxa_exception_storage.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/src/cxa_exception_storage.cpp?rev=282062&r1=282061&r2=282062&view=diff
==
--- libcxxabi/trunk/src/cxa_exception_storage.cpp (original)
+++ libcxxabi/trunk/src/cxa_exception_storage.cpp Wed Sep 21 04:09:32 2016
@@ -15,7 +15,7 @@
 
 #include "config.h"
 
-#if LIBCXXABI_HAS_NO_THREADS
+#if defined(_LIBCXXABI_HAS_NO_THREADS)
 
 namespace __cxxabiv1 {
 extern "C" {

Modified: libcxxabi/trunk/src/cxa_guard.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxxabi/trunk/src/cxa_guard.cpp?rev=282062&r1=282061&r2=282062&view=diff
==
--- libcxxabi/trunk/src/cxa_guard.cpp (original)
+++ libcxxabi/trunk/src/cxa_guard.cpp Wed Sep 21 04:09:32 2016
@@ -12,7 +12,7 @@
 #include "abort_message.h"
 #include "config.h"
 
-#if !LIBCXXABI_HAS_NO_THREADS
+#ifndef _LIBCXXABI_HAS_NO_THREADS
 #  include 
 #endif
 #include 
@@ -50,7 +50,7 @@ void set_initialized(guard_type* guard_o
 }
 #endif
 
-#if LIBCXXABI_HAS_NO_THREADS || (defined(__APPLE__) && !defined(__arm__))
+#if defined(_LIBCXXABI_HAS_NO_THREADS) || (defined(__APPLE__) && 
!defined(__arm__))
 #ifdef __arm__
 
 // Test the lowest bit.
@@ -68,7 +68,7 @@ bool is_initialized(guard_type* guard_ob
 #endif
 #endif
 
-#if !LIBCXXABI_HAS_NO_THREADS
+#ifndef _LIBCXXABI_HAS_NO_THREADS
 pthread_mutex_t guard_mut = PTHREAD_MUTEX_INITIALIZER;
 pthread_cond_t  guard_cv  = PTHREAD_COND_INITIALIZER;
 #endif
@@ -172,22 +172,7 @@ set_lock(uint32_t& x, lock_type y)
 extern "C"
 {
 
-#if LIBCXXABI_HAS_NO_THREADS
-_LIBCXXABI_FUNC_VIS int __cxa_guard_acquire(guard_type *guard_object) {
-return !is_initialized(guard_object);
-}
-
-_LIBCXXABI_FUNC_VIS void __cxa_guard_release(guard_type *guard_object) {
-*guard_object = 0;
-set_initialized(guard_object);
-}
-
-_LIBCXXABI_FUNC_VIS void __cxa_guard_abort(guard_type *guard_object) {
-*guard_object = 0;
-}
-
-#else // !LIBCXXABI_HAS_NO_THREADS
-
+#ifndef _LIBCXXABI_HAS_NO_THREADS
 _LIBCXXABI_FUNC_VIS int __cxa_guard_acquire(guard_type *guard_object) {
 char* initialized = (char*)guard_object;
 if (pthread_mutex_loc

Re: [PATCH] D24784: [change-namespace] fix name qualifiers in UsingShadowDecl and NestedNameSpecifier.

2016-09-21 Thread Haojian Wu via cfe-commits
hokein added a comment.

Looks almost good. A few comments.



Comment at: change-namespace/ChangeNamespace.cpp:467
@@ +466,3 @@
+  const NamedDecl *TargetDecl =
+  UsingDeclaration->shadow_begin()->getTargetDecl();
+  std::string TargetDeclName = TargetDecl->getQualifiedNameAsString();

It is not always accurate to use the first using-decls. It's fine now since 
don't have better solution for this. Add a `FIXME`.


Comment at: unittests/change-namespace/ChangeNamespaceTests.cpp:243
@@ +242,3 @@
+ "typedef nc::SAME IDENTICAL;\n"
+ "void f(nd::SAME Same) {}\n"
+ "} // namespace nb\n"

How about the case `void f2(SAME Same){}`? Is it changed to `::na::nc::SAME` 
too? Make sense to add it to the test.

BTW, does the patch cover using alias ("using A = x::y::z;") case? If yes, also 
add to the test.




https://reviews.llvm.org/D24784



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


Re: [PATCH] D24784: [change-namespace] fix name qualifiers in UsingShadowDecl and NestedNameSpecifier.

2016-09-21 Thread Eric Liu via cfe-commits
ioeric updated this revision to Diff 72018.
ioeric marked 2 inline comments as done.
ioeric added a comment.

- Addressed review comments.


https://reviews.llvm.org/D24784

Files:
  change-namespace/ChangeNamespace.cpp
  change-namespace/ChangeNamespace.h
  unittests/change-namespace/ChangeNamespaceTests.cpp

Index: unittests/change-namespace/ChangeNamespaceTests.cpp
===
--- unittests/change-namespace/ChangeNamespaceTests.cpp
+++ unittests/change-namespace/ChangeNamespaceTests.cpp
@@ -229,6 +229,91 @@
   EXPECT_EQ(format(Expected), runChangeNamespaceOnCode(Code));
 }
 
+TEST_F(ChangeNamespaceTest, FixUsingShadowDecl) {
+  std::string Code = "namespace na {\n"
+ "namespace nc {\n"
+ "class SAME {};\n"
+ "}\n"
+ "namespace nd {\n"
+ "class SAME {};\n"
+ "}\n"
+ "namespace nb {\n"
+ "using nc::SAME;\n"
+ "using YO = nc::SAME;\n"
+ "typedef nc::SAME IDENTICAL;\n"
+ "void f(nd::SAME Same) {}\n"
+ "} // namespace nb\n"
+ "} // namespace na\n";
+
+  std::string Expected = "namespace na {\n"
+ "namespace nc {\n"
+ "class SAME {};\n"
+ "}\n"
+ "namespace nd {\n"
+ "class SAME {};\n"
+ "}\n"
+ "\n"
+ "} // namespace na\n"
+ "namespace x {\n"
+ "namespace y {\n"
+ "using ::na::nc::SAME;\n"
+ "using YO = na::nc::SAME;\n"
+ "typedef na::nc::SAME IDENTICAL;\n"
+ "void f(na::nd::SAME Same) {}\n"
+ "} // namespace y\n"
+ "} // namespace x\n";
+  EXPECT_EQ(format(Expected), runChangeNamespaceOnCode(Code));
+}
+
+TEST_F(ChangeNamespaceTest, TypeInNestedNameSpecifier) {
+  std::string Code =
+  "namespace na {\n"
+  "class C_A {\n"
+  "public:\n"
+  "  class Nested {\n"
+  "public:\n"
+  "  static int NestedX;\n"
+  "  static void nestedFunc() {}\n"
+  "  };\n"
+  "};\n"
+  "namespace nb {\n"
+  "class C_X {\n"
+  "  C_A na;\n"
+  "  C_A::Nested nested;\n"
+  "  void f() {\n"
+  "C_A::Nested::nestedFunc();\n"
+  "int X = C_A::Nested::NestedX;\n"
+  "  }\n"
+  "};\n"
+  "}  // namespace nb\n"
+  "}  // namespace na\n";
+  std::string Expected =
+  "namespace na {\n"
+  "class C_A {\n"
+  "public:\n"
+  "  class Nested {\n"
+  "public:\n"
+  "  static int NestedX;\n"
+  "  static void nestedFunc() {}\n"
+  "  };\n"
+  "};\n"
+  "\n"
+  "}  // namespace na\n"
+  "namespace x {\n"
+  "namespace y {\n"
+  "class C_X {\n"
+  "  na::C_A na;\n"
+  "  na::C_A::Nested nested;\n"
+  "  void f() {\n"
+  "na::C_A::Nested::nestedFunc();\n"
+  "int X = na::C_A::Nested::NestedX;\n"
+  "  }\n"
+  "};\n"
+  "}  // namespace y\n"
+  "}  // namespace x\n";
+  EXPECT_EQ(format(Expected), runChangeNamespaceOnCode(Code));
+}
+
 } // anonymous namespace
 } // namespace change_namespace
 } // namespace clang
Index: change-namespace/ChangeNamespace.h
===
--- change-namespace/ChangeNamespace.h
+++ change-namespace/ChangeNamespace.h
@@ -73,6 +73,9 @@
   void fixTypeLoc(const ast_matchers::MatchFinder::MatchResult &Result,
   SourceLocation Start, SourceLocation End, TypeLoc Type);
 
+  void fixUsingShadowDecl(const ast_matchers::MatchFinder::MatchResult &Result,
+  const UsingDecl *UsingDeclaration);
+
   // Information about moving an old namespace.
   struct MoveNamespace {
 // The start offset of the namespace block being moved in the original
Index: change-namespace/ChangeNamespace.cpp
===
--- change-namespace/ChangeNamespace.cpp
+++ change-namespace/ChangeNamespace.cpp
@@ -231,9 +231,6 @@
 }
 
 // FIXME: handle the following symbols:
-//   - Types in `UsingShadowDecl` (e.g. `using a::b::c;`) which are not matched
-//   by `typeLoc`.
-//   - Types in nested name specifier, e.g. "na::X" in "na::X::Nested".
 //   - Function references.
 //   - Variable references.
 void ChangeNamespaceTool::registerMatchers(ast_matchers::MatchFinder *Finder) {
@@ -266,7 +263,6 @@
   // Match TypeLocs on the declaration. Carefully match only the outermost
   // TypeLoc that's directly linked to the old class and don't handle nested
   // name specifier locs.
-  // FIXME: match and handle nested n

Re: [PATCH] D24792: [analyzer] Fix crash in RetainCountChecker::checkEndFunction

2016-09-21 Thread Artem Dergachev via cfe-commits
NoQ added inline comments.


Comment at: lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp:3866
@@ -3865,3 +3865,3 @@
   if (LCtx->getAnalysisDeclContext()->isBodyAutosynthesized()) {
-assert(LCtx->getParent());
+assert(LCtx->inTopFrame() || LCtx->getParent()); 
 return;

Hmm. This assert is trivially true and can be omitted.

However, the assert here has a reason: we clearly shouldn't be trying to 
analyze synthesized bodies as top-level functions. Because any errors we find 
this way would never have any tiniest thing to do with the code we've been 
asked to analyze by the user.

So i think this problem could use a little bit more attention.

Also, i think the correct way to write this assert would be 
`!LCtx->inTopFrame()` (which would be compatible with `ScopeContext` whenever 
we have it).


Repository:
  rL LLVM

https://reviews.llvm.org/D24792



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


Re: [PATCH] D22910: Add support for CXXOperatorCallExpr in Expr::HasSideEffects

2016-09-21 Thread Andi via cfe-commits
Abpostelnicu updated this revision to Diff 72026.

https://reviews.llvm.org/D22910

Files:
  include/clang/AST/ExprCXX.h
  lib/AST/Expr.cpp

Index: lib/AST/Expr.cpp
===
--- lib/AST/Expr.cpp
+++ lib/AST/Expr.cpp
@@ -2863,8 +2863,20 @@
 // These never have a side-effect.
 return false;
 
+  case CXXOperatorCallExprClass: {
+// When looking for potential side-effects, we assume that an overloaded
+// assignment operator is intended to have a side-effect and other 
overloaded
+// operators are not. Otherwise fall through the logic of call expression.
+OverloadedOperatorKind Op = cast(this)->getOperator();
+if (CXXOperatorCallExpr::isAssignmentOp(Op)) {
+  const Decl *FD = cast(this)->getCalleeDecl();
+  bool IsPure = FD && (FD->hasAttr() || 
FD->hasAttr());
+  if (!IsPure)
+return true;
+}
+LLVM_FALLTHROUGH;
+  }
   case CallExprClass:
-  case CXXOperatorCallExprClass:
   case CXXMemberCallExprClass:
   case CUDAKernelCallExprClass:
   case UserDefinedLiteralClass: {
Index: include/clang/AST/ExprCXX.h
===
--- include/clang/AST/ExprCXX.h
+++ include/clang/AST/ExprCXX.h
@@ -106,6 +106,16 @@
   // operations on floating point types.
   bool isFPContractable() const { return FPContractable; }
 
+  // Check to see if a given overloaded operator is of assignment kind
+  static bool isAssignmentOp(OverloadedOperatorKind Opc) {
+return Opc == OO_Equal || Opc == OO_StarEqual ||
+   Opc == OO_SlashEqual || Opc == OO_PercentEqual ||
+   Opc == OO_PlusEqual || Opc == OO_MinusEqual ||
+   Opc == OO_LessLessEqual || Opc == OO_GreaterGreaterEqual ||
+   Opc == OO_AmpEqual || Opc == OO_CaretEqual ||
+   Opc == OO_PipeEqual;
+  }
+  
   friend class ASTStmtReader;
   friend class ASTStmtWriter;
 };


Index: lib/AST/Expr.cpp
===
--- lib/AST/Expr.cpp
+++ lib/AST/Expr.cpp
@@ -2863,8 +2863,20 @@
 // These never have a side-effect.
 return false;
 
+  case CXXOperatorCallExprClass: {
+// When looking for potential side-effects, we assume that an overloaded
+// assignment operator is intended to have a side-effect and other overloaded
+// operators are not. Otherwise fall through the logic of call expression.
+OverloadedOperatorKind Op = cast(this)->getOperator();
+if (CXXOperatorCallExpr::isAssignmentOp(Op)) {
+  const Decl *FD = cast(this)->getCalleeDecl();
+  bool IsPure = FD && (FD->hasAttr() || FD->hasAttr());
+  if (!IsPure)
+return true;
+}
+LLVM_FALLTHROUGH;
+  }
   case CallExprClass:
-  case CXXOperatorCallExprClass:
   case CXXMemberCallExprClass:
   case CUDAKernelCallExprClass:
   case UserDefinedLiteralClass: {
Index: include/clang/AST/ExprCXX.h
===
--- include/clang/AST/ExprCXX.h
+++ include/clang/AST/ExprCXX.h
@@ -106,6 +106,16 @@
   // operations on floating point types.
   bool isFPContractable() const { return FPContractable; }
 
+  // Check to see if a given overloaded operator is of assignment kind
+  static bool isAssignmentOp(OverloadedOperatorKind Opc) {
+return Opc == OO_Equal || Opc == OO_StarEqual ||
+   Opc == OO_SlashEqual || Opc == OO_PercentEqual ||
+   Opc == OO_PlusEqual || Opc == OO_MinusEqual ||
+   Opc == OO_LessLessEqual || Opc == OO_GreaterGreaterEqual ||
+   Opc == OO_AmpEqual || Opc == OO_CaretEqual ||
+   Opc == OO_PipeEqual;
+  }
+  
   friend class ASTStmtReader;
   friend class ASTStmtWriter;
 };
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D24609: [ARM] Add missing Interlocked intrinsics

2016-09-21 Thread Martin Storsjö via cfe-commits
mstorsjo updated the summary for this revision.
mstorsjo updated this revision to Diff 72025.
mstorsjo added a comment.

Rebased on top of the latest master


https://reviews.llvm.org/D24609

Files:
  lib/Headers/intrin.h

Index: lib/Headers/intrin.h
===
--- lib/Headers/intrin.h
+++ lib/Headers/intrin.h
@@ -490,6 +490,23 @@
   long _PrevVal = __atomic_fetch_or(_BitBase, 1l << _BitPos, __ATOMIC_SEQ_CST);
   return (_PrevVal >> _BitPos) & 1;
 }
+#if defined(__arm__) || defined(__aarch64__)
+static __inline__ unsigned char __DEFAULT_FN_ATTRS
+_interlockedbittestandset_acq(long volatile *_BitBase, long _BitPos) {
+  long _PrevVal = __atomic_fetch_or(_BitBase, 1l << _BitPos, __ATOMIC_ACQUIRE);
+  return (_PrevVal >> _BitPos) & 1;
+}
+static __inline__ unsigned char __DEFAULT_FN_ATTRS
+_interlockedbittestandset_nf(long volatile *_BitBase, long _BitPos) {
+  long _PrevVal = __atomic_fetch_or(_BitBase, 1l << _BitPos, __ATOMIC_RELAXED);
+  return (_PrevVal >> _BitPos) & 1;
+}
+static __inline__ unsigned char __DEFAULT_FN_ATTRS
+_interlockedbittestandset_rel(long volatile *_BitBase, long _BitPos) {
+  long _PrevVal = __atomic_fetch_or(_BitBase, 1l << _BitPos, __ATOMIC_RELEASE);
+  return (_PrevVal >> _BitPos) & 1;
+}
+#endif
 #ifdef __x86_64__
 static __inline__ unsigned char __DEFAULT_FN_ATTRS
 _BitScanForward64(unsigned long *_Index, unsigned __int64 _Mask) {
@@ -533,64 +550,521 @@
   __atomic_fetch_or(_BitBase, 1ll << _BitPos, __ATOMIC_SEQ_CST);
   return (_PrevVal >> _BitPos) & 1;
 }
+#endif
 /**\
 |* Interlocked Exchange Add
 \**/
+#if defined(__arm__) || defined(__aarch64__)
+static __inline__ char __DEFAULT_FN_ATTRS
+_InterlockedExchangeAdd8_acq(char volatile *_Addend, char _Value) {
+  return __atomic_fetch_add(_Addend, _Value, __ATOMIC_ACQUIRE);
+}
+static __inline__ char __DEFAULT_FN_ATTRS
+_InterlockedExchangeAdd8_nf(char volatile *_Addend, char _Value) {
+  return __atomic_fetch_add(_Addend, _Value, __ATOMIC_RELAXED);
+}
+static __inline__ char __DEFAULT_FN_ATTRS
+_InterlockedExchangeAdd8_rel(char volatile *_Addend, char _Value) {
+  return __atomic_fetch_add(_Addend, _Value, __ATOMIC_RELAXED);
+}
+static __inline__ short __DEFAULT_FN_ATTRS
+_InterlockedExchangeAdd16_acq(short volatile *_Addend, short _Value) {
+  return __atomic_fetch_add(_Addend, _Value, __ATOMIC_ACQUIRE);
+}
+static __inline__ short __DEFAULT_FN_ATTRS
+_InterlockedExchangeAdd16_nf(short volatile *_Addend, short _Value) {
+  return __atomic_fetch_add(_Addend, _Value, __ATOMIC_RELAXED);
+}
+static __inline__ short __DEFAULT_FN_ATTRS
+_InterlockedExchangeAdd16_rel(short volatile *_Addend, short _Value) {
+  return __atomic_fetch_add(_Addend, _Value, __ATOMIC_RELEASE);
+}
+static __inline__ long __DEFAULT_FN_ATTRS
+_InterlockedExchangeAdd_acq(long volatile *_Addend, long _Value) {
+  return __atomic_fetch_add(_Addend, _Value, __ATOMIC_ACQUIRE);
+}
+static __inline__ long __DEFAULT_FN_ATTRS
+_InterlockedExchangeAdd_nf(long volatile *_Addend, long _Value) {
+  return __atomic_fetch_add(_Addend, _Value, __ATOMIC_RELAXED);
+}
+static __inline__ long __DEFAULT_FN_ATTRS
+_InterlockedExchangeAdd_rel(long volatile *_Addend, long _Value) {
+  return __atomic_fetch_add(_Addend, _Value, __ATOMIC_RELEASE);
+}
+#endif
+#if defined(__x86_64__) || defined(__arm__) || defined(__aarch64__)
 static __inline__ __int64 __DEFAULT_FN_ATTRS
 _InterlockedExchangeAdd64(__int64 volatile *_Addend, __int64 _Value) {
 	return __atomic_fetch_add(_Addend, _Value, __ATOMIC_SEQ_CST);
 }
+#endif
+#if defined(__arm__) || defined(__aarch64__)
+static __inline__ __int64 __DEFAULT_FN_ATTRS
+_InterlockedExchangeAdd64_acq(__int64 volatile *_Addend, __int64 _Value) {
+  return __atomic_fetch_add(_Addend, _Value, __ATOMIC_ACQUIRE);
+}
+static __inline__ __int64 __DEFAULT_FN_ATTRS
+_InterlockedExchangeAdd64_nf(__int64 volatile *_Addend, __int64 _Value) {
+  return __atomic_fetch_add(_Addend, _Value, __ATOMIC_RELAXED);
+}
+static __inline__ __int64 __DEFAULT_FN_ATTRS
+_InterlockedExchangeAdd64_rel(__int64 volatile *_Addend, __int64 _Value) {
+  return __atomic_fetch_add(_Addend, _Value, __ATOMIC_RELEASE);
+}
+#endif
 /**\
 |* Interlocked Exchange Sub
 \**/
+#if defined(__x86_64__) || defined(__arm__) || defined(__aarch64__)
 static __inline__ __int64 __DEFAULT_FN_ATTRS
 _InterlockedExchangeSub64(__int64 volatile *_Subend, __int64 _Value) {
 	return __atomic_fetch_sub(_Subend, _Value, __ATOMIC_SEQ_CST);
 }
+#endif
 /**\
 |* Interlocked Increment
 \**/
+#if defined(__ar

Re: [PATCH] D24243: [clang-move] A prototype tool for moving class definition to new file.

2016-09-21 Thread Haojian Wu via cfe-commits
hokein updated this revision to Diff 72027.
hokein added a comment.

Update dependency.


https://reviews.llvm.org/D24243

Files:
  CMakeLists.txt
  clang-move/CMakeLists.txt
  clang-move/ClangMove.cpp
  clang-move/ClangMove.h
  clang-move/tool/CMakeLists.txt
  clang-move/tool/ClangMoveMain.cpp
  unittests/CMakeLists.txt
  unittests/clang-move/CMakeLists.txt
  unittests/clang-move/ClangMoveTests.cpp

Index: unittests/clang-move/ClangMoveTests.cpp
===
--- /dev/null
+++ unittests/clang-move/ClangMoveTests.cpp
@@ -0,0 +1,226 @@
+//===-- ClangMoveTest.cpp - clang-move unit tests -===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "ClangMove.h"
+#include "unittests/Tooling/RewriterTestContext.h"
+#include "clang/Format/Format.h"
+#include "clang/Frontend/FrontendActions.h"
+#include "clang/Frontend/TextDiagnosticPrinter.h"
+#include "clang/Rewrite/Core/Rewriter.h"
+#include "clang/Tooling/Refactoring.h"
+#include "clang/Tooling/Tooling.h"
+#include "llvm/ADT/StringRef.h"
+#include "gtest/gtest.h"
+#include 
+#include 
+
+namespace clang {
+namespace move {
+namespace {
+
+const char TestHeaderName[] = "foo.h";
+
+const char TestCCName[] = "foo.cc";
+
+const char TestHeader[] = "namespace a {\n"
+  "class C1;\n"
+  "namespace b {\n"
+  "class Foo {\n"
+  "public:\n"
+  "  void f();\n"
+  "\n"
+  "private:\n"
+  "  C1 *c1;\n"
+  "  static int b;\n"
+  "};\n"
+  "\n"
+  "class Foo2 {\n"
+  "public:\n"
+  "  int f();\n"
+  "};\n"
+  "} // namespace b\n"
+  "} // namespace a\n";
+
+const char TestCC[] = "#include \"foo.h\"\n"
+  "namespace a {\n"
+  "namespace b {\n"
+  "namespace {\n"
+  "void f1() {}\n"
+  "int kConstInt1 = 0;\n"
+  "} // namespace\n"
+  "\n"
+  "static int kConstInt2 = 1;\n"
+  "\n"
+  "static int help() {\n"
+  "  int a = 0;\n"
+  "  return a;\n"
+  "}\n"
+  "\n"
+  "void Foo::f() { f1(); }\n"
+  "\n"
+  "int Foo::b = 2;\n"
+  "int Foo2::f() {\n"
+  "  f1();\n"
+  "  return 1;\n"
+  "}\n"
+  "} // namespace b\n"
+  "} // namespace a\n";
+
+const char ExpectedTestHeader[] = "namespace a {\n"
+  "class C1;\n"
+  "namespace b {\n"
+  "\n"
+  "class Foo2 {\n"
+  "public:\n"
+  "  int f();\n"
+  "};\n"
+  "} // namespace b\n"
+  "} // namespace a\n";
+
+const char ExpectedTestCC[] = "#include \"foo.h\"\n"
+  "namespace a {\n"
+  "namespace b {\n"
+  "namespace {\n"
+  "void f1() {}\n"
+  "int kConstInt1 = 0;\n"
+  "} // namespace\n"
+  "\n"
+  "static int kConstInt2 = 1;\n"
+  "\n"
+  "static int help() {\n"
+  "  int a = 0;\n"
+  "  return a;\n"
+  "}\n"
+  "\n"
+  "int Foo2::f() {\n"
+  "  f1();\n"
+  "  return 1;\n"
+  "}\n"
+  "} // namespace b\n"
+  "} // namespace a\n";
+
+const char ExpectedNewHeader[] = "namespace a {\n"
+ "class C1;\n"
+ "namespace b {\n"
+ "class Foo {\n"
+ "public:\n"
+ "  void f();\n"
+   

[PATCH] D24791: Use checktime when reloading vim buffer after applying clang-rename

2016-09-21 Thread Kai Wolf via cfe-commits
NewProggie created this revision.
NewProggie added a subscriber: cfe-commits.

After applying `clang-rename` to a vim buffer (using `clang-rename.py` as part 
of the vim integration) the buffer gets reloaded using `bufdo`. This solution 
is suboptimal, since syntax highlighting is turned off for performance reasons 
and never turned on, after all changes to the source file have been applied. 

A better solution to this is using `checktime`. It is exactly designed for this 
kind of task and doesn't have the syntax highlighting issue.

https://reviews.llvm.org/D24791

Files:
  clang-rename/tool/clang-rename.py

Index: clang-rename/tool/clang-rename.py
===
--- clang-rename/tool/clang-rename.py
+++ clang-rename/tool/clang-rename.py
@@ -54,7 +54,7 @@
 print stderr
 
 # Reload all buffers in Vim.
-vim.command("bufdo edit")
+vim.command("checktime")
 
 
 if __name__ == '__main__':


Index: clang-rename/tool/clang-rename.py
===
--- clang-rename/tool/clang-rename.py
+++ clang-rename/tool/clang-rename.py
@@ -54,7 +54,7 @@
 print stderr
 
 # Reload all buffers in Vim.
-vim.command("bufdo edit")
+vim.command("checktime")
 
 
 if __name__ == '__main__':
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D24319: clang-format: Add an option to git-clang-format to diff between to commits

2016-09-21 Thread Mark Lodato via cfe-commits
lodato added a comment.

Could you add a note to the commit description to say that there is a backwards 
incompatibility: if a filename matches a branch name or other commit-ish, then 
`git clang-format  ` will no longer work as expected; use `git 
clang-format  -- ` instead.



Comment at: tools/clang-format/git-clang-format:35
@@ -34,3 +34,3 @@
 
 usage = 'git clang-format [OPTIONS] [] [--] [...]'
 

add a second `[]`


Comment at: tools/clang-format/git-clang-format:38
@@ -37,4 +37,3 @@
 desc = '''
-Run clang-format on all lines that differ between the working directory
-and , which defaults to HEAD.  Changes are only applied to the working
-directory.
+Run clang-format on all lines that differ between the working directory and
+ (which defaults to HEAD), or all lines that changed in a specific

suggestion:

> If zero or one commits are given, .
> 
> If two commits are given (requires --diff), run clang-format on all lines in 
> the second  that differ from the first .



Comment at: tools/clang-format/git-clang-format:127
@@ +126,3 @@
+if len(commits) > 1:
+  die('at most one commit allowed; %d given' % len(commits))
+  else:

This error message is a bit confusing.  I think it would be clearer to do:

```
if len(commits) > 1:
  if not opts.diff:
die('--diff is required when two commits are given')
elif len(commits) > 2:
  die('at most two ...
```


Comment at: tools/clang-format/git-clang-format:198
@@ -184,2 +197,3 @@
 def interpret_args(args, dash_dash, default_commit):
-  """Interpret `args` as "[commit] [--] [files...]" and return (commit, files).
+  """Interpret `args` as "[commits...] [--] [files...]" and return (commits,
+  files).

nit: Python style is to put the whole thing on a single line.  Maybe remove the 
two `...`s or the `[--]`?


Comment at: tools/clang-format/git-clang-format:333
@@ -313,1 +332,3 @@
 
+def get_tree_from_commit(commit):
+  """Returns the object ID (SHA-1) of the tree associated with `commit`"""

I don't think this function is necessary.  All git commands that take a tree 
actually take a "tree-ish", which is a tree, commit, tag, or branch.  I just 
tried removing this function and it appeared to work.

(If it ends up this function is necessary, I think the proper thing to do is 
`git rev-parse ^{tree}` since `git-show` is a porcelain command.)


Comment at: tools/clang-format/git-clang-format:385
@@ -358,1 +384,3 @@
 
+  If `revision` is empty, clang-format will be run on the file in the working
+  directory.

```
Runs on the file in `revision` if not None, or on the file in the working 
directory if `revision` is None.
```


Comment at: tools/clang-format/git-clang-format:397
@@ +396,3 @@
+clang_format_cmd.extend(['-assume-filename='+filename])
+git_show_cmd = ['git', 'show', '%s:%s' % (revision, filename)]
+git_show = subprocess.Popen(git_show_cmd, stdin=subprocess.PIPE,

Should use `cat-file` instead of `show` - the former is plumbing while the 
latter is porcelain (see `man git`).  That is, `git cat-file blob %s:%s`.


Comment at: tools/clang-format/git-clang-format:466
@@ -421,3 +465,3 @@
   # like color and pagination.
   subprocess.check_call(['git', 'diff', old_tree, new_tree, '--'])
 

Add `--diff-filter=M`. Without this, the command prints all unmodified files as 
deleted since `old_tree` has all the files in the case of multi-commit mode, 
but `new_tree` only has modified files.  I suggest adding a comment explaining 
this.

To test, try running `git clang-format --diff HEAD~30 HEAD` on the LLVM repo.  
You'll see that without the diff filter, you get a 100MB+ diff! :)


Comment at: tools/clang-format/git-clang-format:474
@@ -429,3 +473,3 @@
   `patch_mode`, runs `git checkout --patch` to select hunks interactively."""
   changed_files = run('git', 'diff-tree', '-r', '-z', '--name-only', old_tree,
   new_tree).rstrip('\0').split('\0')

Might as well add `--diff-filter=M` here too


https://reviews.llvm.org/D24319



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


Re: [PATCH] D24674: [mips] MSA intrinsics header file

2016-09-21 Thread Simon Dardis via cfe-commits
sdardis added a comment.

Checking the generated IR for the incorrect uses of v8f16 shows that clang is 
silently generating bitcasts from <8 x i16> to <4 x float>. There are some 
other cases where the type of the operands is incorrect w.r.t. the builtin used.

I'm not familiar with the type checking machinery, so I'm unsure if the silent 
conversion is a bug or feature.


https://reviews.llvm.org/D24674



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


Re: [PATCH] D24243: [clang-move] A prototype tool for moving class definition to new file.

2016-09-21 Thread Haojian Wu via cfe-commits
hokein updated this revision to Diff 72031.
hokein added a comment.

Improve the way of detecting whether #include in old_header.


https://reviews.llvm.org/D24243

Files:
  CMakeLists.txt
  clang-move/CMakeLists.txt
  clang-move/ClangMove.cpp
  clang-move/ClangMove.h
  clang-move/tool/CMakeLists.txt
  clang-move/tool/ClangMoveMain.cpp
  unittests/CMakeLists.txt
  unittests/clang-move/CMakeLists.txt
  unittests/clang-move/ClangMoveTests.cpp

Index: unittests/clang-move/ClangMoveTests.cpp
===
--- /dev/null
+++ unittests/clang-move/ClangMoveTests.cpp
@@ -0,0 +1,226 @@
+//===-- ClangMoveTest.cpp - clang-move unit tests -===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "ClangMove.h"
+#include "unittests/Tooling/RewriterTestContext.h"
+#include "clang/Format/Format.h"
+#include "clang/Frontend/FrontendActions.h"
+#include "clang/Frontend/TextDiagnosticPrinter.h"
+#include "clang/Rewrite/Core/Rewriter.h"
+#include "clang/Tooling/Refactoring.h"
+#include "clang/Tooling/Tooling.h"
+#include "llvm/ADT/StringRef.h"
+#include "gtest/gtest.h"
+#include 
+#include 
+
+namespace clang {
+namespace move {
+namespace {
+
+const char TestHeaderName[] = "foo.h";
+
+const char TestCCName[] = "foo.cc";
+
+const char TestHeader[] = "namespace a {\n"
+  "class C1;\n"
+  "namespace b {\n"
+  "class Foo {\n"
+  "public:\n"
+  "  void f();\n"
+  "\n"
+  "private:\n"
+  "  C1 *c1;\n"
+  "  static int b;\n"
+  "};\n"
+  "\n"
+  "class Foo2 {\n"
+  "public:\n"
+  "  int f();\n"
+  "};\n"
+  "} // namespace b\n"
+  "} // namespace a\n";
+
+const char TestCC[] = "#include \"foo.h\"\n"
+  "namespace a {\n"
+  "namespace b {\n"
+  "namespace {\n"
+  "void f1() {}\n"
+  "int kConstInt1 = 0;\n"
+  "} // namespace\n"
+  "\n"
+  "static int kConstInt2 = 1;\n"
+  "\n"
+  "static int help() {\n"
+  "  int a = 0;\n"
+  "  return a;\n"
+  "}\n"
+  "\n"
+  "void Foo::f() { f1(); }\n"
+  "\n"
+  "int Foo::b = 2;\n"
+  "int Foo2::f() {\n"
+  "  f1();\n"
+  "  return 1;\n"
+  "}\n"
+  "} // namespace b\n"
+  "} // namespace a\n";
+
+const char ExpectedTestHeader[] = "namespace a {\n"
+  "class C1;\n"
+  "namespace b {\n"
+  "\n"
+  "class Foo2 {\n"
+  "public:\n"
+  "  int f();\n"
+  "};\n"
+  "} // namespace b\n"
+  "} // namespace a\n";
+
+const char ExpectedTestCC[] = "#include \"foo.h\"\n"
+  "namespace a {\n"
+  "namespace b {\n"
+  "namespace {\n"
+  "void f1() {}\n"
+  "int kConstInt1 = 0;\n"
+  "} // namespace\n"
+  "\n"
+  "static int kConstInt2 = 1;\n"
+  "\n"
+  "static int help() {\n"
+  "  int a = 0;\n"
+  "  return a;\n"
+  "}\n"
+  "\n"
+  "int Foo2::f() {\n"
+  "  f1();\n"
+  "  return 1;\n"
+  "}\n"
+  "} // namespace b\n"
+  "} // namespace a\n";
+
+const char ExpectedNewHeader[] = "namespace a {\n"
+ "class C1;\n"
+ "namespace b {\n"
+ "class Foo {\n"
+ "public:\n"
+ "  voi

Re: [PATCH] D22910: Add support for CXXOperatorCallExpr in Expr::HasSideEffects

2016-09-21 Thread Aaron Ballman via cfe-commits
aaron.ballman added a comment.

The other thing this patch is missing are tests, btw.



Comment at: lib/AST/Expr.cpp:2869
@@ +2868,3 @@
+// assignment operator is intended to have a side-effect and other 
overloaded
+// operators are not. Otherwise fall through the logic of call expression.
+OverloadedOperatorKind Op = cast(this)->getOperator();

I think that `operator++()` and `operator--()` should be handled as well as the 
assignment operators. @rsmith, thoughts?


https://reviews.llvm.org/D22910



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


Re: [PATCH] D24513: [AMDGPU] Expose flat work group size, register and wave control attributes

2016-09-21 Thread Aaron Ballman via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM, thank you!


https://reviews.llvm.org/D24513



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


[clang-tools-extra] r282070 - [clang-move] A prototype tool for moving class definition to new file.

2016-09-21 Thread Haojian Wu via cfe-commits
Author: hokein
Date: Wed Sep 21 08:18:19 2016
New Revision: 282070

URL: http://llvm.org/viewvc/llvm-project?rev=282070&view=rev
Log:
[clang-move] A prototype tool for moving class definition to new file.

Summary:
This patch introduces a new tool which moves a specific class definition
from files (.h, .cc) to new files (.h, .cc), which mostly acts like
"Extract class defintion". In the long term, this tool should be
merged in to clang-refactoring as a subtool.

clang-move not only moves class definition, but also moves all the
forward declarations, functions defined in anonymous namespace and #include
headers to new files, to make sure the new files are compliable as much
as possible.

To move `Foo` from old.[h/cc] to new.[h/cc], use:

```
clang-move -name=Foo -old_header=old.h -old_cc=old.cc -new_header=new.h
-new_cc=new.cc old.cc
```

To move `Foo` from old.h to new.h, use:

```
clang-move -name=Foo -old_header=old.h -new_header=new.h old.cc
```

Reviewers: klimek, djasper, ioeric

Subscribers: mgorny, beanz, Eugene.Zelenko, bkramer, omtcyfz, cfe-commits

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

Added:
clang-tools-extra/trunk/clang-move/
clang-tools-extra/trunk/clang-move/CMakeLists.txt
clang-tools-extra/trunk/clang-move/ClangMove.cpp
clang-tools-extra/trunk/clang-move/ClangMove.h
clang-tools-extra/trunk/clang-move/tool/
clang-tools-extra/trunk/clang-move/tool/CMakeLists.txt
clang-tools-extra/trunk/clang-move/tool/ClangMoveMain.cpp
clang-tools-extra/trunk/unittests/clang-move/
clang-tools-extra/trunk/unittests/clang-move/CMakeLists.txt
clang-tools-extra/trunk/unittests/clang-move/ClangMoveTests.cpp
Modified:
clang-tools-extra/trunk/CMakeLists.txt
clang-tools-extra/trunk/unittests/CMakeLists.txt

Modified: clang-tools-extra/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/CMakeLists.txt?rev=282070&r1=282069&r2=282070&view=diff
==
--- clang-tools-extra/trunk/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/CMakeLists.txt Wed Sep 21 08:18:19 2016
@@ -9,6 +9,7 @@ endif()
 
 add_subdirectory(change-namespace)
 add_subdirectory(clang-query)
+add_subdirectory(clang-move)
 add_subdirectory(include-fixer)
 add_subdirectory(pp-trace)
 add_subdirectory(tool-template)

Added: clang-tools-extra/trunk/clang-move/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-move/CMakeLists.txt?rev=282070&view=auto
==
--- clang-tools-extra/trunk/clang-move/CMakeLists.txt (added)
+++ clang-tools-extra/trunk/clang-move/CMakeLists.txt Wed Sep 21 08:18:19 2016
@@ -0,0 +1,19 @@
+set(LLVM_LINK_COMPONENTS
+  support
+  )
+
+add_clang_library(clangMove
+  ClangMove.cpp
+
+  LINK_LIBS
+  clangAST
+  clangASTMatchers
+  clangBasic
+  clangFormat
+  clangFrontend
+  clangLex
+  clangTooling
+  clangToolingCore
+  )
+
+add_subdirectory(tool)

Added: clang-tools-extra/trunk/clang-move/ClangMove.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-move/ClangMove.cpp?rev=282070&view=auto
==
--- clang-tools-extra/trunk/clang-move/ClangMove.cpp (added)
+++ clang-tools-extra/trunk/clang-move/ClangMove.cpp Wed Sep 21 08:18:19 2016
@@ -0,0 +1,339 @@
+//===-- ClangMove.cpp - Implement ClangMove functationalities ---*- C++ 
-*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "ClangMove.h"
+#include "clang/ASTMatchers/ASTMatchers.h"
+#include "clang/Basic/SourceManager.h"
+#include "clang/Format/Format.h"
+#include "clang/Frontend/CompilerInstance.h"
+#include "clang/Lex/Lexer.h"
+#include "clang/Lex/Preprocessor.h"
+#include "clang/Rewrite/Core/Rewriter.h"
+#include "clang/Tooling/Core/Replacement.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace move {
+namespace {
+
+// FIXME: Move to ASTMatcher.
+AST_POLYMORPHIC_MATCHER(isStatic, AST_POLYMORPHIC_SUPPORTED_TYPES(FunctionDecl,
+  VarDecl)) {
+  return Node.getStorageClass() == SC_Static;
+}
+
+class FindAllIncludes : public clang::PPCallbacks {
+public:
+  explicit FindAllIncludes(SourceManager *SM, ClangMoveTool *const MoveTool)
+  : SM(*SM), MoveTool(MoveTool) {}
+
+  void InclusionDirective(clang::SourceLocation HashLoc,
+  const clang::Token & /*IncludeTok*/,
+  StringRef FileName, bool IsAngled,
+  clang::CharSourceRange /*FilenameRange*/,
+  const clang::FileEntry * /*File*/,
+   

Re: [PATCH] D24243: [clang-move] A prototype tool for moving class definition to new file.

2016-09-21 Thread Haojian Wu via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL282070: [clang-move] A prototype tool for moving class 
definition to new file. (authored by hokein).

Changed prior to commit:
  https://reviews.llvm.org/D24243?vs=72031&id=72033#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D24243

Files:
  clang-tools-extra/trunk/CMakeLists.txt
  clang-tools-extra/trunk/clang-move/CMakeLists.txt
  clang-tools-extra/trunk/clang-move/ClangMove.cpp
  clang-tools-extra/trunk/clang-move/ClangMove.h
  clang-tools-extra/trunk/clang-move/tool/CMakeLists.txt
  clang-tools-extra/trunk/clang-move/tool/ClangMoveMain.cpp
  clang-tools-extra/trunk/unittests/CMakeLists.txt
  clang-tools-extra/trunk/unittests/clang-move/CMakeLists.txt
  clang-tools-extra/trunk/unittests/clang-move/ClangMoveTests.cpp

Index: clang-tools-extra/trunk/CMakeLists.txt
===
--- clang-tools-extra/trunk/CMakeLists.txt
+++ clang-tools-extra/trunk/CMakeLists.txt
@@ -9,6 +9,7 @@
 
 add_subdirectory(change-namespace)
 add_subdirectory(clang-query)
+add_subdirectory(clang-move)
 add_subdirectory(include-fixer)
 add_subdirectory(pp-trace)
 add_subdirectory(tool-template)
Index: clang-tools-extra/trunk/unittests/CMakeLists.txt
===
--- clang-tools-extra/trunk/unittests/CMakeLists.txt
+++ clang-tools-extra/trunk/unittests/CMakeLists.txt
@@ -7,6 +7,7 @@
 
 add_subdirectory(change-namespace)
 add_subdirectory(clang-apply-replacements)
+add_subdirectory(clang-move)
 add_subdirectory(clang-query)
 add_subdirectory(clang-tidy)
 add_subdirectory(include-fixer)
Index: clang-tools-extra/trunk/unittests/clang-move/ClangMoveTests.cpp
===
--- clang-tools-extra/trunk/unittests/clang-move/ClangMoveTests.cpp
+++ clang-tools-extra/trunk/unittests/clang-move/ClangMoveTests.cpp
@@ -0,0 +1,226 @@
+//===-- ClangMoveTest.cpp - clang-move unit tests -===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "ClangMove.h"
+#include "unittests/Tooling/RewriterTestContext.h"
+#include "clang/Format/Format.h"
+#include "clang/Frontend/FrontendActions.h"
+#include "clang/Frontend/TextDiagnosticPrinter.h"
+#include "clang/Rewrite/Core/Rewriter.h"
+#include "clang/Tooling/Refactoring.h"
+#include "clang/Tooling/Tooling.h"
+#include "llvm/ADT/StringRef.h"
+#include "gtest/gtest.h"
+#include 
+#include 
+
+namespace clang {
+namespace move {
+namespace {
+
+const char TestHeaderName[] = "foo.h";
+
+const char TestCCName[] = "foo.cc";
+
+const char TestHeader[] = "namespace a {\n"
+  "class C1;\n"
+  "namespace b {\n"
+  "class Foo {\n"
+  "public:\n"
+  "  void f();\n"
+  "\n"
+  "private:\n"
+  "  C1 *c1;\n"
+  "  static int b;\n"
+  "};\n"
+  "\n"
+  "class Foo2 {\n"
+  "public:\n"
+  "  int f();\n"
+  "};\n"
+  "} // namespace b\n"
+  "} // namespace a\n";
+
+const char TestCC[] = "#include \"foo.h\"\n"
+  "namespace a {\n"
+  "namespace b {\n"
+  "namespace {\n"
+  "void f1() {}\n"
+  "int kConstInt1 = 0;\n"
+  "} // namespace\n"
+  "\n"
+  "static int kConstInt2 = 1;\n"
+  "\n"
+  "static int help() {\n"
+  "  int a = 0;\n"
+  "  return a;\n"
+  "}\n"
+  "\n"
+  "void Foo::f() { f1(); }\n"
+  "\n"
+  "int Foo::b = 2;\n"
+  "int Foo2::f() {\n"
+  "  f1();\n"
+  "  return 1;\n"
+  "}\n"
+  "} // namespace b\n"
+  "} // namespace a\n";
+
+const char ExpectedTestHeader[] = "namespace a {\n"
+  "class C1;\n"
+  "namespace b {\n"
+  "\n"
+  "class Foo2 {\n"
+  "public:\n"
+  "  int f();\n"
+  "};\n"
+  "} // namespac

Re: [PATCH] D24669: {Sema] Gcc compatibility of vector shift.

2016-09-21 Thread Aaron Ballman via cfe-commits
aaron.ballman added a comment.

In clang 3.8, your test code already produces a diagnostic for me: 
http://coliru.stacked-crooked.com/a/752a4ea34123bdae


Repository:
  rL LLVM

https://reviews.llvm.org/D24669



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


[PATCH] D24798: [mips] Fix msa builtins test

2016-09-21 Thread Simon Dardis via cfe-commits
sdardis created this revision.
sdardis added reviewers: vkalintiris, zoran.jovanovic.
sdardis added a subscriber: cfe-commits.
Herald added a subscriber: sdardis.

This test was using the wrong types in several places.

https://reviews.llvm.org/D24798

Files:
  test/CodeGen/builtins-mips-msa.c

Index: test/CodeGen/builtins-mips-msa.c
===
--- test/CodeGen/builtins-mips-msa.c
+++ test/CodeGen/builtins-mips-msa.c
@@ -387,11 +387,11 @@
   v4i32_r = __msa_fill_w(3); // CHECK: call <4  x i32> @llvm.mips.fill.w(
   v2i64_r = __msa_fill_d(3); // CHECK: call <2  x i64> @llvm.mips.fill.d(
 
-  v4f32_r = __msa_flog2_w(v8f16_a); // CHECK: call <4 x float>  
@llvm.mips.flog2.w(
-  v2f64_r = __msa_flog2_d(v4f32_a); // CHECK: call <2 x double> 
@llvm.mips.flog2.d(
+  v4f32_r = __msa_flog2_w(v4f32_a); // CHECK: call <4 x float>  
@llvm.mips.flog2.w(
+  v2f64_r = __msa_flog2_d(v2f64_a); // CHECK: call <2 x double> 
@llvm.mips.flog2.d(
 
-  v4f32_r = __msa_fmadd_w(v8f16_r, v8f16_a, v8f16_b); // CHECK: call <4 x 
float>  @llvm.mips.fmadd.w(
-  v2f64_r = __msa_fmadd_d(v4f32_r, v4f32_a, v4f32_b); // CHECK: call <2 x 
double> @llvm.mips.fmadd.d(
+  v4f32_r = __msa_fmadd_w(v4f32_r, v4f32_a, v4f32_b); // CHECK: call <4 x 
float>  @llvm.mips.fmadd.w(
+  v2f64_r = __msa_fmadd_d(v2f64_r, v2f64_a, v2f64_b); // CHECK: call <2 x 
double> @llvm.mips.fmadd.d(
 
   v4f32_r = __msa_fmax_w(v4f32_a, v4f32_b); // CHECK: call <4 x float>  
@llvm.mips.fmax.w(
   v2f64_r = __msa_fmax_d(v2f64_a, v2f64_b); // CHECK: call <2 x double> 
@llvm.mips.fmax.d(
@@ -405,20 +405,20 @@
   v4f32_r = __msa_fmin_a_w(v4f32_a, v4f32_b); // CHECK: call <4 x float>  
@llvm.mips.fmin.a.w(
   v2f64_r = __msa_fmin_a_d(v2f64_a, v2f64_b); // CHECK: call <2 x double> 
@llvm.mips.fmin.a.d(
 
-  v4f32_r = __msa_fmsub_w(v8f16_r, v8f16_a, v8f16_b); // CHECK: call <4 x 
float>  @llvm.mips.fmsub.w(
-  v2f64_r = __msa_fmsub_d(v4f32_r, v4f32_a, v4f32_b); // CHECK: call <2 x 
double> @llvm.mips.fmsub.d(
+  v4f32_r = __msa_fmsub_w(v4f32_r, v4f32_a, v4f32_b); // CHECK: call <4 x 
float>  @llvm.mips.fmsub.w(
+  v2f64_r = __msa_fmsub_d(v2f64_r, v2f64_a, v2f64_b); // CHECK: call <2 x 
double> @llvm.mips.fmsub.d(
 
   v4f32_r = __msa_fmul_w(v4f32_a, v4f32_b); // CHECK: call <4 x float>  
@llvm.mips.fmul.w(
   v2f64_r = __msa_fmul_d(v2f64_a, v2f64_b); // CHECK: call <2 x double> 
@llvm.mips.fmul.d(
 
-  v4f32_r = __msa_frint_w(v8f16_a); // CHECK: call <4 x float>  
@llvm.mips.frint.w(
-  v2f64_r = __msa_frint_d(v4f32_a); // CHECK: call <2 x double> 
@llvm.mips.frint.d(
+  v4f32_r = __msa_frint_w(v4f32_a); // CHECK: call <4 x float>  
@llvm.mips.frint.w(
+  v2f64_r = __msa_frint_d(v2f64_a); // CHECK: call <2 x double> 
@llvm.mips.frint.d(
 
-  v4f32_r = __msa_frcp_w(v8f16_a); // CHECK: call <4 x float>  
@llvm.mips.frcp.w(
-  v2f64_r = __msa_frcp_d(v4f32_a); // CHECK: call <2 x double> 
@llvm.mips.frcp.d(
+  v4f32_r = __msa_frcp_w(v4f32_a); // CHECK: call <4 x float>  
@llvm.mips.frcp.w(
+  v2f64_r = __msa_frcp_d(v2f64_a); // CHECK: call <2 x double> 
@llvm.mips.frcp.d(
 
-  v4f32_r = __msa_frsqrt_w(v8f16_a); // CHECK: call <4 x float>  
@llvm.mips.frsqrt.w(
-  v2f64_r = __msa_frsqrt_d(v4f32_a); // CHECK: call <2 x double> 
@llvm.mips.frsqrt.d(
+  v4f32_r = __msa_frsqrt_w(v4f32_a); // CHECK: call <4 x float>  
@llvm.mips.frsqrt.w(
+  v2f64_r = __msa_frsqrt_d(v2f64_a); // CHECK: call <2 x double> 
@llvm.mips.frsqrt.d(
 
   v4i32_r = __msa_fseq_w(v4f32_a, v4f32_b); // CHECK: call <4 x i32> 
@llvm.mips.fseq.w(
   v2i64_r = __msa_fseq_d(v2f64_a, v2f64_b); // CHECK: call <2 x i64> 
@llvm.mips.fseq.d(
@@ -438,8 +438,8 @@
   v4i32_r = __msa_fsor_w(v4f32_a, v4f32_b); // CHECK: call <4 x i32> 
@llvm.mips.fsor.w(
   v2i64_r = __msa_fsor_d(v2f64_a, v2f64_b); // CHECK: call <2 x i64> 
@llvm.mips.fsor.d(
 
-  v4f32_r = __msa_fsqrt_w(v8f16_a); // CHECK: call <4 x float>  
@llvm.mips.fsqrt.w(
-  v2f64_r = __msa_fsqrt_d(v4f32_a); // CHECK: call <2 x double> 
@llvm.mips.fsqrt.d(
+  v4f32_r = __msa_fsqrt_w(v4f32_a); // CHECK: call <4 x float>  
@llvm.mips.fsqrt.w(
+  v2f64_r = __msa_fsqrt_d(v2f64_a); // CHECK: call <2 x double> 
@llvm.mips.fsqrt.d(
 
   v4f32_r = __msa_fsub_w(v4f32_a, v4f32_b); // CHECK: call <4 x float>  
@llvm.mips.fsub.w(
   v2f64_r = __msa_fsub_d(v2f64_a, v2f64_b); // CHECK: call <2 x double> 
@llvm.mips.fsub.d(


Index: test/CodeGen/builtins-mips-msa.c
===
--- test/CodeGen/builtins-mips-msa.c
+++ test/CodeGen/builtins-mips-msa.c
@@ -387,11 +387,11 @@
   v4i32_r = __msa_fill_w(3); // CHECK: call <4  x i32> @llvm.mips.fill.w(
   v2i64_r = __msa_fill_d(3); // CHECK: call <2  x i64> @llvm.mips.fill.d(
 
-  v4f32_r = __msa_flog2_w(v8f16_a); // CHECK: call <4 x float>  @llvm.mips.flog2.w(
-  v2f64_r = __msa_flog2_d(v4f32_a); // CHECK: call <2 x double> @llvm.mips.flog2.d(
+  v4f32_r = __msa_flog2_w(v4f32_a); // CHECK: call <4 x float>  @llvm.mips.flog2.w(
+  v2f64

Re: [PATCH] D24784: [change-namespace] fix name qualifiers in UsingShadowDecl and NestedNameSpecifier.

2016-09-21 Thread Haojian Wu via cfe-commits
hokein accepted this revision.
hokein added a comment.
This revision is now accepted and ready to land.

LGTM.


https://reviews.llvm.org/D24784



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


Re: [PATCH] D24792: [analyzer] Fix crash in RetainCountChecker::checkEndFunction

2016-09-21 Thread Devin Coughlin via cfe-commits
dcoughlin added a comment.

I suspect I introduced this regression in r264687.


Repository:
  rL LLVM

https://reviews.llvm.org/D24792



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


Re: [PATCH] D24481: make “#pragma STDC FP_CONTRACT” on by default

2016-09-21 Thread Yaxun Liu via cfe-commits
yaxunl added inline comments.


Comment at: 
clang/test/CodeGen/fp-contract-pragma___on-by-default___-O1...3___aarch64-backend.c:8
@@ +7,3 @@
+// CHECK: fmadd d0, d{{[0-7]}}, d{{[0-7]}}, d{{[0-7]}}
+// CHECK-NEXT: ret
+double fmadd_double(double a, double b, double c) {

This check seems unnecessary and can be removed. The same as below. Then this 
test can be merged with 
fp-contract-pragma___on-by-default___-O0___aarch64-backend.c


https://reviews.llvm.org/D24481



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


Re: [PATCH] D24472: [Sema] Support lax conversions for compound assignments

2016-09-21 Thread Akira Hatanaka via cfe-commits
ahatanak added a comment.

Thanks Bruno. I have a couple more questions.



Comment at: lib/Sema/SemaExpr.cpp:8090
@@ +8089,3 @@
+  *RHSExpr = ImpCastExprToType(RHSExpr->get(), LHSType, CK_BitCast);
+  return VecType;
+}

Sorry I wasn't clear, but I was asking whether you were planning to  allow the 
following conversions for compound statements.

```
typedef short s4 __attribute__ ((vector_size(8)));
typedef int i2 __attribute__ ((vector_size(8)));
s4 a;
i2 b;
a = a + b; // clang accepts this.
a += b; // currently clang rejects this.
```

Also, I feel clang is inconsistent in warning about incompatible types. In the 
following example, it issues a warning for the first line, but is silent about 
the second line:

```
a = b + a; // incompatible vector types warning
a = a + b; // no warning
```

I don't think we have to fix everything in this patch, but just wanted to know 
what your thoughts were.


https://reviews.llvm.org/D24472



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


Re: [PATCH] D24800: Merge conflicting replacements when they are order-independent.

2016-09-21 Thread Eric Liu via cfe-commits
ioeric updated this revision to Diff 72045.
ioeric added a comment.

- Provide order-independent replacements examples in comments.


https://reviews.llvm.org/D24800

Files:
  include/clang/Tooling/Core/Replacement.h
  lib/Tooling/Core/Replacement.cpp
  unittests/Tooling/RefactoringTest.cpp

Index: unittests/Tooling/RefactoringTest.cpp
===
--- unittests/Tooling/RefactoringTest.cpp
+++ unittests/Tooling/RefactoringTest.cpp
@@ -101,18 +101,56 @@
 
 TEST_F(ReplacementTest, FailAddReplacements) {
   Replacements Replaces;
-  auto Err = Replaces.add(Replacement("x.cc", 0, 10, "3"));
+  Replacement Deletion("x.cc", 0, 10, "3");
+  auto Err = Replaces.add(Deletion);
   EXPECT_TRUE(!Err);
   llvm::consumeError(std::move(Err));
-  Err = Replaces.add(Replacement("x.cc", 0, 2, ""));
+  Err = Replaces.add(Replacement("x.cc", 0, 2, "a"));
   EXPECT_TRUE((bool)Err);
   llvm::consumeError(std::move(Err));
-  Err = Replaces.add(Replacement("x.cc", 2, 2, ""));
+  Err = Replaces.add(Replacement("x.cc", 2, 2, "a"));
   EXPECT_TRUE((bool)Err);
   llvm::consumeError(std::move(Err));
   Err = Replaces.add(Replacement("y.cc", 20, 2, ""));
   EXPECT_TRUE((bool)Err);
   llvm::consumeError(std::move(Err));
+  EXPECT_EQ(1u, Replaces.size());
+  EXPECT_EQ(Deletion, *Replaces.begin());
+}
+
+TEST_F(ReplacementTest, DeletionInReplacements) {
+  Replacements Replaces;
+  Replacement R("x.cc", 0, 10, "3");
+  auto Err = Replaces.add(R);
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+  Err = Replaces.add(Replacement("x.cc", 0, 2, ""));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+  Err = Replaces.add(Replacement("x.cc", 2, 2, ""));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+  EXPECT_EQ(1u, Replaces.size());
+  EXPECT_EQ(R, *Replaces.begin());
+}
+
+TEST_F(ReplacementTest, OverlappingReplacements) {
+  Replacements Replaces;
+  auto Err = Replaces.add(Replacement("x.cc", 0, 3, "345"));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+  Err = Replaces.add(Replacement("x.cc", 2, 3, "543"));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  EXPECT_EQ(1u, Replaces.size());
+  EXPECT_EQ(Replacement("x.cc", 0, 5, "34543"), *Replaces.begin());
+
+  Err = Replaces.add(Replacement("x.cc", 2, 1, "5"));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+  EXPECT_EQ(1u, Replaces.size());
+  EXPECT_EQ(Replacement("x.cc", 0, 5, "34543"), *Replaces.begin());
 }
 
 TEST_F(ReplacementTest, AddAdjacentInsertionAndReplacement) {
@@ -137,6 +175,116 @@
   EXPECT_EQ(Replaces.size(), 2u);
 }
 
+TEST_F(ReplacementTest, MergeNewDeletions) {
+  Replacements Replaces;
+  Replacement ContainingReplacement("x.cc", 0, 10, "");
+  auto Err = Replaces.add(ContainingReplacement);
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  Err = Replaces.add(Replacement("x.cc", 5, 3, ""));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  Err = Replaces.add(Replacement("x.cc", 0, 10, ""));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  Err = Replaces.add(Replacement("x.cc", 5, 5, ""));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  EXPECT_EQ(1u, Replaces.size());
+  EXPECT_EQ(*Replaces.begin(), ContainingReplacement);
+}
+
+TEST_F(ReplacementTest, MergeOverlappingButNotAdjacentReplacement) {
+  Replacements Replaces;
+  auto Err = Replaces.add(Replacement("x.cc", 0, 2, ""));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  Err = Replaces.add(Replacement("x.cc", 5, 5, ""));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  Replacement After = Replacement("x.cc", 10, 5, "");
+  Err = Replaces.add(After);
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  Replacement ContainingReplacement("x.cc", 0, 10, "");
+  Err = Replaces.add(ContainingReplacement);
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  EXPECT_EQ(2u, Replaces.size());
+  EXPECT_EQ(*Replaces.begin(), ContainingReplacement);
+  EXPECT_EQ(*(++Replaces.begin()), After);
+}
+
+TEST_F(ReplacementTest, InsertionBeforeMergedDeletions) {
+  Replacements Replaces;
+
+  Replacement Insertion("x.cc", 0, 0, "123");
+  auto Err = Replaces.add(Insertion);
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  Err = Replaces.add(Replacement("x.cc", 5, 5, ""));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  Replacement Deletion("x.cc", 0, 10, "");
+  Err = Replaces.add(Deletion);
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  EXPECT_EQ(2u, Replaces.size());
+  EXPECT_EQ(*Replaces.begin(), Insertion);
+  EXPECT_EQ(*(++Replaces.begin()), Deletion);
+}
+
+TEST_F(ReplacementTest, MergeOverlappingDeletions) {
+  Replacements Replaces;
+  auto Err = Replaces.add(Replacement("x.cc", 0, 2, ""));
+  EXPECT_TRUE(!Err);
+  llvm::consumeError(std::move(Err));
+
+  Err = Replaces.add(Replacement("x.cc", 0, 5, ""));
+ 

[clang-tools-extra] r282073 - [change-namespace] fix name qualifiers in UsingShadowDecl and NestedNameSpecifier.

2016-09-21 Thread Eric Liu via cfe-commits
Author: ioeric
Date: Wed Sep 21 10:06:12 2016
New Revision: 282073

URL: http://llvm.org/viewvc/llvm-project?rev=282073&view=rev
Log:
[change-namespace] fix name qualifiers in UsingShadowDecl and 
NestedNameSpecifier.

Reviewers: hokein

Subscribers: cfe-commits

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

Modified:
clang-tools-extra/trunk/change-namespace/ChangeNamespace.cpp
clang-tools-extra/trunk/change-namespace/ChangeNamespace.h
clang-tools-extra/trunk/unittests/change-namespace/ChangeNamespaceTests.cpp

Modified: clang-tools-extra/trunk/change-namespace/ChangeNamespace.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/change-namespace/ChangeNamespace.cpp?rev=282073&r1=282072&r2=282073&view=diff
==
--- clang-tools-extra/trunk/change-namespace/ChangeNamespace.cpp (original)
+++ clang-tools-extra/trunk/change-namespace/ChangeNamespace.cpp Wed Sep 21 
10:06:12 2016
@@ -231,9 +231,6 @@ ChangeNamespaceTool::ChangeNamespaceTool
 }
 
 // FIXME: handle the following symbols:
-//   - Types in `UsingShadowDecl` (e.g. `using a::b::c;`) which are not matched
-//   by `typeLoc`.
-//   - Types in nested name specifier, e.g. "na::X" in "na::X::Nested".
 //   - Function references.
 //   - Variable references.
 void ChangeNamespaceTool::registerMatchers(ast_matchers::MatchFinder *Finder) {
@@ -266,7 +263,6 @@ void ChangeNamespaceTool::registerMatche
   // Match TypeLocs on the declaration. Carefully match only the outermost
   // TypeLoc that's directly linked to the old class and don't handle nested
   // name specifier locs.
-  // FIXME: match and handle nested name specifier locs.
   Finder->addMatcher(
   typeLoc(IsInMovedNs,
   loc(qualType(hasDeclaration(DeclMatcher.bind("from_decl",
@@ -276,6 +272,17 @@ void ChangeNamespaceTool::registerMatche
   hasAncestor(decl().bind("dc")))
   .bind("type"),
   this);
+  // Types in `UsingShadowDecl` is not matched by `typeLoc` above, so we need 
to
+  // special case it.
+  Finder->addMatcher(
+  usingDecl(hasAnyUsingShadowDecl(IsInMovedNs)).bind("using_decl"), this);
+  // Handle types in nested name specifier.
+  Finder->addMatcher(nestedNameSpecifierLoc(
+ hasAncestor(decl(IsInMovedNs).bind("dc")),
+ loc(nestedNameSpecifier(specifiesType(
+ hasDeclaration(DeclMatcher.bind("from_decl"))
+ .bind("nested_specifier_loc"),
+ this);
 }
 
 void ChangeNamespaceTool::run(
@@ -285,6 +292,15 @@ void ChangeNamespaceTool::run(
   } else if (const auto *FwdDecl =
  Result.Nodes.getNodeAs("fwd_decl")) {
 moveClassForwardDeclaration(Result, FwdDecl);
+  } else if (const auto *UsingDeclaration =
+ Result.Nodes.getNodeAs("using_decl")) {
+fixUsingShadowDecl(Result, UsingDeclaration);
+  } else if (const auto *Specifier =
+ Result.Nodes.getNodeAs(
+ "nested_specifier_loc")) {
+SourceLocation Start = Specifier->getBeginLoc();
+SourceLocation End = EndLocationForType(Specifier->getTypeLoc());
+fixTypeLoc(Result, Start, End, Specifier->getTypeLoc());
   } else {
 const auto *TLoc = Result.Nodes.getNodeAs("type");
 assert(TLoc != nullptr && "Expecting callback for TypeLoc");
@@ -439,6 +455,26 @@ void ChangeNamespaceTool::fixTypeLoc(
   FromDecl->getQualifiedNameAsString());
 }
 
+void ChangeNamespaceTool::fixUsingShadowDecl(
+const ast_matchers::MatchFinder::MatchResult &Result,
+const UsingDecl *UsingDeclaration) {
+  SourceLocation Start = UsingDeclaration->getLocStart();
+  SourceLocation End = UsingDeclaration->getLocEnd();
+  if (Start.isInvalid() || End.isInvalid()) return;
+
+  assert(UsingDeclaration->shadow_size() > 0);
+  // FIXME: it might not be always accurate to use the first using-decl.
+  const NamedDecl *TargetDecl =
+  UsingDeclaration->shadow_begin()->getTargetDecl();
+  std::string TargetDeclName = TargetDecl->getQualifiedNameAsString();
+  // FIXME: check if target_decl_name is in moved ns, which doesn't make much
+  // sense. If this happens, we need to use name with the new namespace.
+  // Use fully qualified name in UsingDecl for now.
+  auto R = createReplacement(Start, End, "using ::" + TargetDeclName,
+ *Result.SourceManager);
+  addOrMergeReplacement(R, &FileToReplacements[R.getFilePath()]);
+}
+
 void ChangeNamespaceTool::onEndOfTranslationUnit() {
   // Move namespace blocks and insert forward declaration to old namespace.
   for (const auto &FileAndNsMoves : MoveNamespaces) {

Modified: clang-tools-extra/trunk/change-namespace/ChangeNamespace.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/change-namespace/ChangeNamespace.h?rev=282073&r1=282072&r2=282073&view=diff
=

Re: [PATCH] D24784: [change-namespace] fix name qualifiers in UsingShadowDecl and NestedNameSpecifier.

2016-09-21 Thread Eric Liu via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL282073: [change-namespace] fix name qualifiers in 
UsingShadowDecl and… (authored by ioeric).

Changed prior to commit:
  https://reviews.llvm.org/D24784?vs=72018&id=72046#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D24784

Files:
  clang-tools-extra/trunk/change-namespace/ChangeNamespace.cpp
  clang-tools-extra/trunk/change-namespace/ChangeNamespace.h
  clang-tools-extra/trunk/unittests/change-namespace/ChangeNamespaceTests.cpp

Index: clang-tools-extra/trunk/change-namespace/ChangeNamespace.h
===
--- clang-tools-extra/trunk/change-namespace/ChangeNamespace.h
+++ clang-tools-extra/trunk/change-namespace/ChangeNamespace.h
@@ -73,6 +73,9 @@
   void fixTypeLoc(const ast_matchers::MatchFinder::MatchResult &Result,
   SourceLocation Start, SourceLocation End, TypeLoc Type);
 
+  void fixUsingShadowDecl(const ast_matchers::MatchFinder::MatchResult &Result,
+  const UsingDecl *UsingDeclaration);
+
   // Information about moving an old namespace.
   struct MoveNamespace {
 // The start offset of the namespace block being moved in the original
Index: clang-tools-extra/trunk/change-namespace/ChangeNamespace.cpp
===
--- clang-tools-extra/trunk/change-namespace/ChangeNamespace.cpp
+++ clang-tools-extra/trunk/change-namespace/ChangeNamespace.cpp
@@ -231,9 +231,6 @@
 }
 
 // FIXME: handle the following symbols:
-//   - Types in `UsingShadowDecl` (e.g. `using a::b::c;`) which are not matched
-//   by `typeLoc`.
-//   - Types in nested name specifier, e.g. "na::X" in "na::X::Nested".
 //   - Function references.
 //   - Variable references.
 void ChangeNamespaceTool::registerMatchers(ast_matchers::MatchFinder *Finder) {
@@ -266,7 +263,6 @@
   // Match TypeLocs on the declaration. Carefully match only the outermost
   // TypeLoc that's directly linked to the old class and don't handle nested
   // name specifier locs.
-  // FIXME: match and handle nested name specifier locs.
   Finder->addMatcher(
   typeLoc(IsInMovedNs,
   loc(qualType(hasDeclaration(DeclMatcher.bind("from_decl",
@@ -276,6 +272,17 @@
   hasAncestor(decl().bind("dc")))
   .bind("type"),
   this);
+  // Types in `UsingShadowDecl` is not matched by `typeLoc` above, so we need to
+  // special case it.
+  Finder->addMatcher(
+  usingDecl(hasAnyUsingShadowDecl(IsInMovedNs)).bind("using_decl"), this);
+  // Handle types in nested name specifier.
+  Finder->addMatcher(nestedNameSpecifierLoc(
+ hasAncestor(decl(IsInMovedNs).bind("dc")),
+ loc(nestedNameSpecifier(specifiesType(
+ hasDeclaration(DeclMatcher.bind("from_decl"))
+ .bind("nested_specifier_loc"),
+ this);
 }
 
 void ChangeNamespaceTool::run(
@@ -285,6 +292,15 @@
   } else if (const auto *FwdDecl =
  Result.Nodes.getNodeAs("fwd_decl")) {
 moveClassForwardDeclaration(Result, FwdDecl);
+  } else if (const auto *UsingDeclaration =
+ Result.Nodes.getNodeAs("using_decl")) {
+fixUsingShadowDecl(Result, UsingDeclaration);
+  } else if (const auto *Specifier =
+ Result.Nodes.getNodeAs(
+ "nested_specifier_loc")) {
+SourceLocation Start = Specifier->getBeginLoc();
+SourceLocation End = EndLocationForType(Specifier->getTypeLoc());
+fixTypeLoc(Result, Start, End, Specifier->getTypeLoc());
   } else {
 const auto *TLoc = Result.Nodes.getNodeAs("type");
 assert(TLoc != nullptr && "Expecting callback for TypeLoc");
@@ -439,6 +455,26 @@
   FromDecl->getQualifiedNameAsString());
 }
 
+void ChangeNamespaceTool::fixUsingShadowDecl(
+const ast_matchers::MatchFinder::MatchResult &Result,
+const UsingDecl *UsingDeclaration) {
+  SourceLocation Start = UsingDeclaration->getLocStart();
+  SourceLocation End = UsingDeclaration->getLocEnd();
+  if (Start.isInvalid() || End.isInvalid()) return;
+
+  assert(UsingDeclaration->shadow_size() > 0);
+  // FIXME: it might not be always accurate to use the first using-decl.
+  const NamedDecl *TargetDecl =
+  UsingDeclaration->shadow_begin()->getTargetDecl();
+  std::string TargetDeclName = TargetDecl->getQualifiedNameAsString();
+  // FIXME: check if target_decl_name is in moved ns, which doesn't make much
+  // sense. If this happens, we need to use name with the new namespace.
+  // Use fully qualified name in UsingDecl for now.
+  auto R = createReplacement(Start, End, "using ::" + TargetDeclName,
+ *Result.SourceManager);
+  addOrMergeReplacement(R, &FileToReplacements[R.getFilePath()]);
+}
+
 void ChangeNamespaceTool::onEndOfTranslationUnit() {
   // Move namespace blocks an

[PATCH] D24799: [XRay] Check in Clang whether XRay supports the target when -fxray-instrument is passed

2016-09-21 Thread Serge Rogatch via cfe-commits
rSerge created this revision.
rSerge added reviewers: rsmith, dberris.
rSerge added subscribers: cfe-commits, iid_iunknown.
Herald added a subscriber: dberris.

Added the code which explicitly emits an error in Clang in case 
`-fxray-instrument` is passed, but XRay is not supported for the selected 
target.

https://reviews.llvm.org/D24799

Files:
  lib/Driver/Tools.cpp

Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -4767,6 +4767,17 @@
 
   if (Args.hasFlag(options::OPT_fxray_instrument,
options::OPT_fnoxray_instrument, false)) {
+switch(getToolChain().getArch()) {
+case llvm::Triple::arm:
+case llvm::Triple::x86_64:
+  break;
+default:
+{
+  std::string feature("XRay for ");
+  feature += Triple.getArchName().data();
+  D.Diag(diag::err_drv_clang_unsupported) << feature;
+  break;
+} }
 CmdArgs.push_back("-fxray-instrument");
 if (const Arg *A =
 Args.getLastArg(options::OPT_fxray_instruction_threshold_,


Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -4767,6 +4767,17 @@
 
   if (Args.hasFlag(options::OPT_fxray_instrument,
options::OPT_fnoxray_instrument, false)) {
+switch(getToolChain().getArch()) {
+case llvm::Triple::arm:
+case llvm::Triple::x86_64:
+  break;
+default:
+{
+  std::string feature("XRay for ");
+  feature += Triple.getArchName().data();
+  D.Diag(diag::err_drv_clang_unsupported) << feature;
+  break;
+} }
 CmdArgs.push_back("-fxray-instrument");
 if (const Arg *A =
 Args.getLastArg(options::OPT_fxray_instruction_threshold_,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang-tools-extra] r282074 - Fix compiler warnings.

2016-09-21 Thread Haojian Wu via cfe-commits
Author: hokein
Date: Wed Sep 21 10:19:04 2016
New Revision: 282074

URL: http://llvm.org/viewvc/llvm-project?rev=282074&view=rev
Log:
Fix compiler warnings.

Modified:
clang-tools-extra/trunk/unittests/clang-move/ClangMoveTests.cpp

Modified: clang-tools-extra/trunk/unittests/clang-move/ClangMoveTests.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/unittests/clang-move/ClangMoveTests.cpp?rev=282074&r1=282073&r2=282074&view=diff
==
--- clang-tools-extra/trunk/unittests/clang-move/ClangMoveTests.cpp (original)
+++ clang-tools-extra/trunk/unittests/clang-move/ClangMoveTests.cpp Wed Sep 21 
10:19:04 2016
@@ -194,7 +194,7 @@ TEST(ClangMove, MoveHeaderOnly) {
   Spec.OldHeader = "foo.h";
   Spec.NewHeader = "new_foo.h";
   auto Results = runClangMoveOnCode(Spec);
-  EXPECT_EQ(2, Results.size());
+  EXPECT_EQ(2u, Results.size());
   EXPECT_EQ(ExpectedTestHeader, Results[Spec.OldHeader]);
   EXPECT_EQ(ExpectedNewHeader, Results[Spec.NewHeader]);
 }
@@ -205,7 +205,7 @@ TEST(ClangMove, MoveCCOnly) {
   Spec.OldCC = "foo.cc";
   Spec.NewCC = "new_foo.cc";
   auto Results = runClangMoveOnCode(Spec);
-  EXPECT_EQ(2, Results.size());
+  EXPECT_EQ(2u, Results.size());
   EXPECT_EQ(ExpectedTestCC, Results[Spec.OldCC]);
   EXPECT_EQ(ExpectedNewCC, Results[Spec.NewCC]);
 }
@@ -218,7 +218,7 @@ TEST(ClangMove, MoveNonExistClass) {
   Spec.NewHeader = "new_foo.h";
   Spec.NewCC = "new_foo.cc";
   auto Results = runClangMoveOnCode(Spec);
-  EXPECT_EQ(0, Results.size());
+  EXPECT_EQ(0u, Results.size());
 }
 
 } // namespace


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


Re: [PATCH] D24693: [CodeGen] Don't emit lifetime intrinsics for some local variables

2016-09-21 Thread Akira Hatanaka via cfe-commits
ahatanak added a comment.

Do we want to remove lifetime intrinsics when we aren't doing the 
asan-use-after-scope check? Since this isn't a mis-compile caused by inaccurate 
lifetime intrinsics, I was wondering whether we should do this only when 
asan-use-after-scope is on to minimize the impact on compile time.


https://reviews.llvm.org/D24693



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


[PATCH] D24804: clang-format: [JS] reserved words in method names.

2016-09-21 Thread Martin Probst via cfe-commits
mprobst created this revision.
mprobst added a reviewer: djasper.
mprobst added a subscriber: cfe-commits.
Herald added a subscriber: klimek.

Before:
class X {
  delete () {
...
  }
}

After:
class X {
  delete() {
...
  }
}

https://reviews.llvm.org/D24804

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

Index: unittests/Format/FormatTestJS.cpp
===
--- unittests/Format/FormatTestJS.cpp
+++ unittests/Format/FormatTestJS.cpp
@@ -147,6 +147,18 @@
   verifyFormat("x = interface instanceof y;");
 }
 
+TEST_F(FormatTestJS, ReservedWordsMethods) {
+  verifyFormat(
+  "class X {\n"
+  "  delete() {\n"
+  "x();\n"
+  "  }\n"
+  "  interface() {\n"
+  "x();\n"
+  "  }\n"
+  "}\n");
+}
+
 TEST_F(FormatTestJS, CppKeywords) {
   // Make sure we don't mess stuff up because of C++ keywords.
   verifyFormat("return operator && (aa);");
Index: lib/Format/TokenAnnotator.cpp
===
--- lib/Format/TokenAnnotator.cpp
+++ lib/Format/TokenAnnotator.cpp
@@ -2158,6 +2158,10 @@
 tok::r_square, tok::r_brace) ||
Left.Tok.isLiteral()))
   return false;
+// JS methods can use some keywords as names (e.g. `delete()`).
+if (Right.is(tok::l_paren) && Line.MustBeDeclaration &&
+Left.Tok.getIdentifierInfo())
+  return false;
 if (Left.is(tok::exclaim) && Right.is(Keywords.kw_as))
   return true; // "x! as string"
   } else if (Style.Language == FormatStyle::LK_Java) {


Index: unittests/Format/FormatTestJS.cpp
===
--- unittests/Format/FormatTestJS.cpp
+++ unittests/Format/FormatTestJS.cpp
@@ -147,6 +147,18 @@
   verifyFormat("x = interface instanceof y;");
 }
 
+TEST_F(FormatTestJS, ReservedWordsMethods) {
+  verifyFormat(
+  "class X {\n"
+  "  delete() {\n"
+  "x();\n"
+  "  }\n"
+  "  interface() {\n"
+  "x();\n"
+  "  }\n"
+  "}\n");
+}
+
 TEST_F(FormatTestJS, CppKeywords) {
   // Make sure we don't mess stuff up because of C++ keywords.
   verifyFormat("return operator && (aa);");
Index: lib/Format/TokenAnnotator.cpp
===
--- lib/Format/TokenAnnotator.cpp
+++ lib/Format/TokenAnnotator.cpp
@@ -2158,6 +2158,10 @@
 tok::r_square, tok::r_brace) ||
Left.Tok.isLiteral()))
   return false;
+// JS methods can use some keywords as names (e.g. `delete()`).
+if (Right.is(tok::l_paren) && Line.MustBeDeclaration &&
+Left.Tok.getIdentifierInfo())
+  return false;
 if (Left.is(tok::exclaim) && Right.is(Keywords.kw_as))
   return true; // "x! as string"
   } else if (Style.Language == FormatStyle::LK_Java) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D22910: Add support for CXXOperatorCallExpr in Expr::HasSideEffects

2016-09-21 Thread Richard Smith via cfe-commits
On 21 Sep 2016 6:10 am, "Aaron Ballman"  wrote:

aaron.ballman added a comment.

The other thing this patch is missing are tests, btw.



Comment at: lib/AST/Expr.cpp:2869
@@ +2868,3 @@
+// assignment operator is intended to have a side-effect and other
overloaded
+// operators are not. Otherwise fall through the logic of call
expression.
+OverloadedOperatorKind Op = cast(
this)->getOperator();

I think that `operator++()` and `operator--()` should be handled as well as
the assignment operators. @rsmith, thoughts?


I agree; if we're going to assume that overloaded operators are intended to
mutate the object in the cases where the builtin form does, that should
apply to all such operators -- assignment, compound assignment, increment
and decrement.

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


[PATCH] D24803: [change-namespace] fix qualifier of function references.

2016-09-21 Thread Eric Liu via cfe-commits
ioeric created this revision.
ioeric added a reviewer: hokein.
ioeric added a subscriber: cfe-commits.

https://reviews.llvm.org/D24803

Files:
  change-namespace/ChangeNamespace.cpp
  unittests/change-namespace/ChangeNamespaceTests.cpp

Index: unittests/change-namespace/ChangeNamespaceTests.cpp
===
--- unittests/change-namespace/ChangeNamespaceTests.cpp
+++ unittests/change-namespace/ChangeNamespaceTests.cpp
@@ -314,6 +314,29 @@
   EXPECT_EQ(format(Expected), runChangeNamespaceOnCode(Code));
 }
 
+TEST_F(ChangeNamespaceTest, FixFunctionNameSpecifiers) {
+  std::string Code =
+  "namespace na {\n"
+  "void a_f() {}\n"
+  "namespace nb {\n"
+  "void f() { a_f(); }\n"
+  "void g() { f(); }\n"
+  "}  // namespace nb\n"
+  "}  // namespace na\n";
+  std::string Expected =
+  "namespace na {\n"
+  "void a_f() {}\n"
+  "\n"
+  "}  // namespace na\n"
+  "namespace x {\n"
+  "namespace y {\n"
+  "void f() { na::a_f(); }\n"
+  "void g() { f(); }\n"
+  "}  // namespace y\n"
+  "}  // namespace x\n";
+  EXPECT_EQ(format(Expected), runChangeNamespaceOnCode(Code));
+}
+
 } // anonymous namespace
 } // namespace change_namespace
 } // namespace clang
Index: change-namespace/ChangeNamespace.cpp
===
--- change-namespace/ChangeNamespace.cpp
+++ change-namespace/ChangeNamespace.cpp
@@ -231,7 +231,6 @@
 }
 
 // FIXME: handle the following symbols:
-//   - Function references.
 //   - Variable references.
 void ChangeNamespaceTool::registerMatchers(ast_matchers::MatchFinder *Finder) {
   // Match old namespace blocks.
@@ -283,6 +282,22 @@
  hasDeclaration(DeclMatcher.bind("from_decl"))
  .bind("nested_specifier_loc"),
  this);
+
+  // Handle function.
+  // Only handle functions that are defined in a namespace excluding static
+  // methods (qualified by nested specifier) and functions defined in the 
global
+  // namespace.
+  // Note that the matcher does not exlude calls to out-of-line static method
+  // definitions, so we need to exclude them in the callback handler.
+  auto FuncMatcher = functionDecl(
+  hasParent(namespaceDecl()),
+  unless(anyOf(IsInMovedNs, hasAncestor(namespaceDecl(isAnonymous())),
+   hasAncestor(cxxRecordDecl();
+  Finder->addMatcher(
+  decl(forEachDescendant(callExpr(callee(FuncMatcher)).bind("call")),
+   IsInMovedNs)
+  .bind("dc"),
+  this);
 }
 
 void ChangeNamespaceTool::run(
@@ -301,11 +316,25 @@
 SourceLocation Start = Specifier->getBeginLoc();
 SourceLocation End = EndLocationForType(Specifier->getTypeLoc());
 fixTypeLoc(Result, Start, End, Specifier->getTypeLoc());
-  } else {
-const auto *TLoc = Result.Nodes.getNodeAs("type");
-assert(TLoc != nullptr && "Expecting callback for TypeLoc");
+  } else if (const auto *TLoc = Result.Nodes.getNodeAs("type")) {
 fixTypeLoc(Result, startLocationForType(*TLoc), EndLocationForType(*TLoc),
*TLoc);
+  } else {
+const auto* Call = Result.Nodes.getNodeAs("call");
+assert(Call != nullptr &&"Expecting callback for CallExpr.");
+const clang::FunctionDecl* Func = Call->getDirectCallee();
+assert(Func != nullptr);
+// Ignore static methods since they will be handled by nested name
+// specifiers.
+if (Func->getCanonicalDecl()->getStorageClass() ==
+clang::StorageClass::SC_Static)
+  return;
+std::string Name = Func->getQualifiedNameAsString();
+const clang::Decl *Context = Result.Nodes.getNodeAs("dc");
+assert(Context && "Empty decl context.");
+clang::SourceRange CalleeRange = Call->getCallee()->getSourceRange();
+replaceQualifiedSymbolInDeclContext(Result, Context, 
CalleeRange.getBegin(),
+CalleeRange.getEnd(), Name);
   }
 }
 


Index: unittests/change-namespace/ChangeNamespaceTests.cpp
===
--- unittests/change-namespace/ChangeNamespaceTests.cpp
+++ unittests/change-namespace/ChangeNamespaceTests.cpp
@@ -314,6 +314,29 @@
   EXPECT_EQ(format(Expected), runChangeNamespaceOnCode(Code));
 }
 
+TEST_F(ChangeNamespaceTest, FixFunctionNameSpecifiers) {
+  std::string Code =
+  "namespace na {\n"
+  "void a_f() {}\n"
+  "namespace nb {\n"
+  "void f() { a_f(); }\n"
+  "void g() { f(); }\n"
+  "}  // namespace nb\n"
+  "}  // namespace na\n";
+  std::string Expected =
+  "namespace na {\n"
+  "void a_f() {}\n"
+  "\n"
+  "}  // namespace na\n"
+  "namespace x {\n"
+  "namespace y {\n"
+  "void f() { na::a_f(); }\n"
+  "void g() { f(); }\n"
+  "}  // namespace y\n"
+  "}  // namespace x\n";
+  EXPECT_EQ(format(Expected), runChangeNamespaceOnCode(Code));
+}
+
 } // anonymous na

Re: [PATCH] D24319: clang-format: Add an option to git-clang-format to diff between to commits

2016-09-21 Thread Luis Héctor Chávez via cfe-commits
lhchavez updated this revision to Diff 72064.
lhchavez added a comment.

Addressed lovato's comments


https://reviews.llvm.org/D24319

Files:
  tools/clang-format/git-clang-format

Index: tools/clang-format/git-clang-format
===
--- tools/clang-format/git-clang-format
+++ tools/clang-format/git-clang-format
@@ -32,12 +32,15 @@
 import subprocess
 import sys
 
-usage = 'git clang-format [OPTIONS] [] [--] [...]'
+usage = 'git clang-format [OPTIONS] [] [] [--] [...]'
 
 desc = '''
-Run clang-format on all lines that differ between the working directory
-and , which defaults to HEAD.  Changes are only applied to the working
-directory.
+If zero or one commits are given, run clang-format on all lines that differ
+between the working directory and , which defaults to HEAD.  Changes are
+only applied to the working directory.
+
+If two commits are given (requires --diff), run clang-format on all lines in the
+second  that differ from the first .
 
 The following git-config settings set the default of the corresponding option:
   clangFormat.binary
@@ -121,8 +124,14 @@
   opts.verbose -= opts.quiet
   del opts.quiet
 
-  commit, files = interpret_args(opts.args, dash_dash, opts.commit)
-  changed_lines = compute_diff_and_extract_lines(commit, files)
+  commits, files = interpret_args(opts.args, dash_dash, opts.commit)
+  if len(commits) > 1:
+if not opts.diff:
+  die('--diff is required when two commits are given')
+  else:
+if len(commits) > 2:
+  die('at most two commits allowed; %d given' % len(commits))
+  changed_lines = compute_diff_and_extract_lines(commits, files)
   if opts.verbose >= 1:
 ignored_files = set(changed_lines)
   filter_by_extension(changed_lines, opts.extensions.lower().split(','))
@@ -142,10 +151,17 @@
   # The computed diff outputs absolute paths, so we must cd before accessing
   # those files.
   cd_to_toplevel()
-  old_tree = create_tree_from_workdir(changed_lines)
-  new_tree = run_clang_format_and_save_to_tree(changed_lines,
-   binary=opts.binary,
-   style=opts.style)
+  if len(commits) > 1:
+old_tree = commits[1]
+new_tree = run_clang_format_and_save_to_tree(changed_lines,
+ revision=commits[1],
+ binary=opts.binary,
+ style=opts.style)
+  else:
+old_tree = create_tree_from_workdir(changed_lines)
+new_tree = run_clang_format_and_save_to_tree(changed_lines,
+ binary=opts.binary,
+ style=opts.style)
   if opts.verbose >= 1:
 print 'old tree:', old_tree
 print 'new tree:', new_tree
@@ -182,40 +198,41 @@
 
 
 def interpret_args(args, dash_dash, default_commit):
-  """Interpret `args` as "[commit] [--] [files...]" and return (commit, files).
+  """Interpret `args` as "[commits] [--] [files]" and return (commits, files).
 
   It is assumed that "--" and everything that follows has been removed from
   args and placed in `dash_dash`.
 
-  If "--" is present (i.e., `dash_dash` is non-empty), the argument to its
-  left (if present) is taken as commit.  Otherwise, the first argument is
-  checked if it is a commit or a file.  If commit is not given,
-  `default_commit` is used."""
+  If "--" is present (i.e., `dash_dash` is non-empty), the arguments to its
+  left (if present) are taken as commits.  Otherwise, the arguments are checked
+  from left to right if they are commits or files.  If commits are not given,
+  a list with `default_commit` is used."""
   if dash_dash:
 if len(args) == 0:
-  commit = default_commit
-elif len(args) > 1:
-  die('at most one commit allowed; %d given' % len(args))
+  commits = [default_commit]
 else:
-  commit = args[0]
-object_type = get_object_type(commit)
-if object_type not in ('commit', 'tag'):
-  if object_type is None:
-die("'%s' is not a commit" % commit)
-  else:
-die("'%s' is a %s, but a commit was expected" % (commit, object_type))
+  commits = args
+for commit in commits:
+  object_type = get_object_type(commit)
+  if object_type not in ('commit', 'tag'):
+if object_type is None:
+  die("'%s' is not a commit" % commit)
+else:
+  die("'%s' is a %s, but a commit was expected" % (commit, object_type))
 files = dash_dash[1:]
   elif args:
-if disambiguate_revision(args[0]):
-  commit = args[0]
-  files = args[1:]
-else:
-  commit = default_commit
-  files = args
+commits = []
+while args:
+  if not disambiguate_revision(args[0]):
+break
+  commits.append(args.pop(0))
+if not commits:
+  commits = [default_commit]
+files = args
   else:
-commit = def

Re: [PATCH] D24804: clang-format: [JS] reserved words in method names.

2016-09-21 Thread Martin Probst via cfe-commits
mprobst updated this revision to Diff 72061.
mprobst added a comment.

- move up to support let in methods.


https://reviews.llvm.org/D24804

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

Index: unittests/Format/FormatTestJS.cpp
===
--- unittests/Format/FormatTestJS.cpp
+++ unittests/Format/FormatTestJS.cpp
@@ -147,6 +147,21 @@
   verifyFormat("x = interface instanceof y;");
 }
 
+TEST_F(FormatTestJS, ReservedWordsMethods) {
+  verifyFormat(
+  "class X {\n"
+  "  delete() {\n"
+  "x();\n"
+  "  }\n"
+  "  interface() {\n"
+  "x();\n"
+  "  }\n"
+  "  let() {\n"
+  "x();\n"
+  "  }\n"
+  "}\n");
+}
+
 TEST_F(FormatTestJS, CppKeywords) {
   // Make sure we don't mess stuff up because of C++ keywords.
   verifyFormat("return operator && (aa);");
Index: lib/Format/TokenAnnotator.cpp
===
--- lib/Format/TokenAnnotator.cpp
+++ lib/Format/TokenAnnotator.cpp
@@ -2125,6 +2125,10 @@
 if (Right.is(tok::star) &&
 Left.isOneOf(Keywords.kw_function, Keywords.kw_yield))
   return false;
+// JS methods can use some keywords as names (e.g. `delete()`).
+if (Right.is(tok::l_paren) && Line.MustBeDeclaration &&
+Left.Tok.getIdentifierInfo())
+  return false;
 if (Left.isOneOf(Keywords.kw_let, Keywords.kw_var, Keywords.kw_in,
  Keywords.kw_of, tok::kw_const) &&
 (!Left.Previous || !Left.Previous->is(tok::period)))


Index: unittests/Format/FormatTestJS.cpp
===
--- unittests/Format/FormatTestJS.cpp
+++ unittests/Format/FormatTestJS.cpp
@@ -147,6 +147,21 @@
   verifyFormat("x = interface instanceof y;");
 }
 
+TEST_F(FormatTestJS, ReservedWordsMethods) {
+  verifyFormat(
+  "class X {\n"
+  "  delete() {\n"
+  "x();\n"
+  "  }\n"
+  "  interface() {\n"
+  "x();\n"
+  "  }\n"
+  "  let() {\n"
+  "x();\n"
+  "  }\n"
+  "}\n");
+}
+
 TEST_F(FormatTestJS, CppKeywords) {
   // Make sure we don't mess stuff up because of C++ keywords.
   verifyFormat("return operator && (aa);");
Index: lib/Format/TokenAnnotator.cpp
===
--- lib/Format/TokenAnnotator.cpp
+++ lib/Format/TokenAnnotator.cpp
@@ -2125,6 +2125,10 @@
 if (Right.is(tok::star) &&
 Left.isOneOf(Keywords.kw_function, Keywords.kw_yield))
   return false;
+// JS methods can use some keywords as names (e.g. `delete()`).
+if (Right.is(tok::l_paren) && Line.MustBeDeclaration &&
+Left.Tok.getIdentifierInfo())
+  return false;
 if (Left.isOneOf(Keywords.kw_let, Keywords.kw_var, Keywords.kw_in,
  Keywords.kw_of, tok::kw_const) &&
 (!Left.Previous || !Left.Previous->is(tok::period)))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D24319: clang-format: Add an option to git-clang-format to diff between to commits

2016-09-21 Thread Luis Héctor Chávez via cfe-commits
lhchavez marked 9 inline comments as done.
lhchavez added a comment.

Addressed all comments. PTAAL.


https://reviews.llvm.org/D24319



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


Re: [PATCH] D24770: [libcxxabi] cleanup the use of LIBCXXABI_HAS_NO_THREADS macro (NFC)

2016-09-21 Thread Asiri Rathnayake via cfe-commits
rmaprath closed this revision.
rmaprath added a comment.

In https://reviews.llvm.org/D24770#547701, @jroelofs wrote:

> LGTM


Thanks!

Committed as r282062.

/ Asiri


https://reviews.llvm.org/D24770



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


[PATCH] D24806: [docs] Add ThinLTO user documentation

2016-09-21 Thread Teresa Johnson via cfe-commits
tejohnson created this revision.
tejohnson added a reviewer: mehdi_amini.
tejohnson added a subscriber: cfe-commits.
Herald added a subscriber: mehdi_amini.

Add some user facing documentation on ThinLTO and how to use it.

https://reviews.llvm.org/D24806

Files:
  docs/CommandGuide/clang.rst
  docs/ThinLTO.rst
  docs/index.rst

Index: docs/index.rst
===
--- docs/index.rst
+++ docs/index.rst
@@ -37,6 +37,7 @@
SourceBasedCodeCoverage
Modules
MSVCCompatibility
+   ThinLTO
CommandGuide/index
FAQ
 
Index: docs/ThinLTO.rst
===
--- /dev/null
+++ docs/ThinLTO.rst
@@ -0,0 +1,146 @@
+===
+ThinLTO
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+*ThinLTO* compilation is a new type of LTO that is both scalable and
+incremental. *LTO* (Link Time Optimization) achieves better
+runtime performance through whole-program analysis and cross-module
+optimization. However, regular LTO implements this by merging all
+input into a single monolithic module, which is not scalable
+in time or memory, and also prevents fast incremental compiles.
+
+In ThinLTO mode, as with regular LTO, clang emits LLVM bitcode after the
+compile phase. The ThinLTO bitcode is augmented with a compact summary
+of the module. During the link step, only the summaries are read and
+merged into a combined summary index, which includes an index of function
+locations for later cross-module function importing. Fast and efficient
+whole-program analysis is then performed on the combined summary index.
+
+However, all transformations, including function importing, occur
+later when the modules are optimized in fully parallel backends.
+By default, linkers_ that support ThinLTO are set up to launch
+the ThinLTO backends in threads. So the usage model is not affected
+as the distinction between the fast serial thin link step and the backends
+is transparent to the user.
+
+For more information on the ThinLTO design and current performance,
+see the LLVM blog post `ThinLTO: Scalable and Incremental LTO
+`_.
+While tuning is still in progress, results in the blog post show that
+ThinLTO already performs well compared to LTO, in many cases matching
+the performance improvement.
+
+Current Status
+==
+
+Clang/LLVM
+--
+.. _compiler:
+
+The 3.9 release of clang includes ThinLTO support. However, ThinLTO
+is under active development, and new features, improvements and bugfixes
+are being added for the next release. For the latest ThinLTO support,
+`build a recent version of clang and LLVM
+`_.
+
+Linkers
+---
+.. _linkers:
+.. _linker:
+
+ThinLTO is currently supported for the following linkers:
+
+- **gold (via the gold-plugin)**:
+  Similar to regular LTO, this requires using
+  a `gold linker configured with plugins enabled
+  `_.
+- **ld64**:
+  Starting with `Xcode 8 `_.
+
+Additionally, support is being added to the *lld* linker.
+
+Usage
+=
+
+Basic
+-
+
+To utilize ThinLTO, simply add the -flto=thin option to compile and link. E.g.
+
+.. code-block:: console
+
+  % clang -flto=thin -O2 file1.c file2.c -c
+  % clang -flto=thin -O2 file1.o file2.o -o a.out
+
+As mentioned earlier, by default the linkers will launch the ThinLTO backend
+threads in parallel, passing the resulting native object files back to the
+linker for the final native link.  As such, the usage model the same as
+non-LTO.
+
+Controlling Backend Parallelism
+---
+.. _parallelism:
+
+By default, the ThinLTO link step will launch up to
+``std::thread::hardware_concurrency`` number of threads in parallel.
+For machines with hyper-threading, this is the total number of
+virtual cores. For some applications and machine configurations this
+may be too aggressive, in which case the amount of parallelism can
+be reduced to ``N`` via:
+
+- gold:
+  ``-Wl,-plugin-opt,jobs=N``
+- ld64:
+  ``-Wl,-mllvm,-threads=N``
+
+Incremental
+---
+.. _incremental:
+
+ThinLTO supports fast incremental builds through the use of a cache,
+which currently must be enabled through a linker option.
+
+- gold (as of LLVM r279883):
+  ``-Wl,-plugin-opt,cache-dir=/path/to/cache``
+- ld64 (support in clang 3.9 and Xcode 8):
+  ``-Wl,-cache_path_lto,/path/to/cache``
+
+Clang Bootstrap
+---
+
+To bootstrap clang/LLVM with ThinLTO, follow these steps:
+
+1. The host compiler_ must be a version of clang that supports ThinLTO.
+#. The host linker_ must support ThinLTO (and in the case of gold, must be
+   `configured with plugins enabled `_.
+#. Use the following additional `CMake variables
+   `_
+   when configur

[PATCH] D24807: [Serialization] ArrayTypeTraitExpr: serialize sub-expression to avoid keeping it undefined

2016-09-21 Thread Aleksei Sidorin via cfe-commits
a.sidorin created this revision.
a.sidorin added reviewers: aaron.ballman, doug.gregor.
a.sidorin added a subscriber: cfe-commits.

I have encountered a segfault when I tried to get sub-expression of serialized 
ArrayTypeTraitExpr. The fix is simple but I have no idea about nice test. Maybe 
you have any suggestions?

https://reviews.llvm.org/D24807

Files:
  lib/Serialization/ASTReaderStmt.cpp
  lib/Serialization/ASTWriterStmt.cpp

Index: lib/Serialization/ASTWriterStmt.cpp
===
--- lib/Serialization/ASTWriterStmt.cpp
+++ lib/Serialization/ASTWriterStmt.cpp
@@ -1576,6 +1576,7 @@
   Record.push_back(E->getValue());
   Record.AddSourceRange(E->getSourceRange());
   Record.AddTypeSourceInfo(E->getQueriedTypeSourceInfo());
+  Record.AddStmt(E->getDimensionExpression());
   Code = serialization::EXPR_ARRAY_TYPE_TRAIT;
 }
 
Index: lib/Serialization/ASTReaderStmt.cpp
===
--- lib/Serialization/ASTReaderStmt.cpp
+++ lib/Serialization/ASTReaderStmt.cpp
@@ -1575,6 +1575,7 @@
   E->Loc = Range.getBegin();
   E->RParen = Range.getEnd();
   E->QueriedType = GetTypeSourceInfo(Record, Idx);
+  E->Dimension = Reader.ReadSubExpr();
 }
 
 void ASTStmtReader::VisitExpressionTraitExpr(ExpressionTraitExpr *E) {


Index: lib/Serialization/ASTWriterStmt.cpp
===
--- lib/Serialization/ASTWriterStmt.cpp
+++ lib/Serialization/ASTWriterStmt.cpp
@@ -1576,6 +1576,7 @@
   Record.push_back(E->getValue());
   Record.AddSourceRange(E->getSourceRange());
   Record.AddTypeSourceInfo(E->getQueriedTypeSourceInfo());
+  Record.AddStmt(E->getDimensionExpression());
   Code = serialization::EXPR_ARRAY_TYPE_TRAIT;
 }
 
Index: lib/Serialization/ASTReaderStmt.cpp
===
--- lib/Serialization/ASTReaderStmt.cpp
+++ lib/Serialization/ASTReaderStmt.cpp
@@ -1575,6 +1575,7 @@
   E->Loc = Range.getBegin();
   E->RParen = Range.getEnd();
   E->QueriedType = GetTypeSourceInfo(Record, Idx);
+  E->Dimension = Reader.ReadSubExpr();
 }
 
 void ASTStmtReader::VisitExpressionTraitExpr(ExpressionTraitExpr *E) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D24806: [docs] Add ThinLTO user documentation

2016-09-21 Thread Teresa Johnson via cfe-commits
tejohnson updated this revision to Diff 72078.
tejohnson added a comment.

Add some troubleshooting info for gold plugin misconfigurations


https://reviews.llvm.org/D24806

Files:
  docs/CommandGuide/clang.rst
  docs/ThinLTO.rst
  docs/index.rst

Index: docs/index.rst
===
--- docs/index.rst
+++ docs/index.rst
@@ -37,6 +37,7 @@
SourceBasedCodeCoverage
Modules
MSVCCompatibility
+   ThinLTO
CommandGuide/index
FAQ
 
Index: docs/ThinLTO.rst
===
--- /dev/null
+++ docs/ThinLTO.rst
@@ -0,0 +1,157 @@
+===
+ThinLTO
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+*ThinLTO* compilation is a new type of LTO that is both scalable and
+incremental. *LTO* (Link Time Optimization) achieves better
+runtime performance through whole-program analysis and cross-module
+optimization. However, regular LTO implements this by merging all
+input into a single monolithic module, which is not scalable
+in time or memory, and also prevents fast incremental compiles.
+
+In ThinLTO mode, as with regular LTO, clang emits LLVM bitcode after the
+compile phase. The ThinLTO bitcode is augmented with a compact summary
+of the module. During the link step, only the summaries are read and
+merged into a combined summary index, which includes an index of function
+locations for later cross-module function importing. Fast and efficient
+whole-program analysis is then performed on the combined summary index.
+
+However, all transformations, including function importing, occur
+later when the modules are optimized in fully parallel backends.
+By default, linkers_ that support ThinLTO are set up to launch
+the ThinLTO backends in threads. So the usage model is not affected
+as the distinction between the fast serial thin link step and the backends
+is transparent to the user.
+
+For more information on the ThinLTO design and current performance,
+see the LLVM blog post `ThinLTO: Scalable and Incremental LTO
+`_.
+While tuning is still in progress, results in the blog post show that
+ThinLTO already performs well compared to LTO, in many cases matching
+the performance improvement.
+
+Current Status
+==
+
+Clang/LLVM
+--
+.. _compiler:
+
+The 3.9 release of clang includes ThinLTO support. However, ThinLTO
+is under active development, and new features, improvements and bugfixes
+are being added for the next release. For the latest ThinLTO support,
+`build a recent version of clang and LLVM
+`_.
+
+Linkers
+---
+.. _linkers:
+.. _linker:
+
+ThinLTO is currently supported for the following linkers:
+
+- **gold (via the gold-plugin)**:
+  Similar to regular LTO, this requires using
+  a `gold linker configured with plugins enabled
+  `_.
+- **ld64**:
+  Starting with `Xcode 8 `_.
+
+Additionally, support is being added to the *lld* linker.
+
+Usage
+=
+
+Basic
+-
+
+To utilize ThinLTO, simply add the -flto=thin option to compile and link. E.g.
+
+.. code-block:: console
+
+  % clang -flto=thin -O2 file1.c file2.c -c
+  % clang -flto=thin -O2 file1.o file2.o -o a.out
+
+As mentioned earlier, by default the linkers will launch the ThinLTO backend
+threads in parallel, passing the resulting native object files back to the
+linker for the final native link.  As such, the usage model the same as
+non-LTO.
+
+With gold, if you see an error during the link of the form:
+
+.. code-block:: console
+
+  /usr/bin/ld: error: /path/to/clang/bin/../lib/LLVMgold.so: could not load plugin library: /path/to/clang/bin/../lib/LLVMgold.so: cannot open shared object file: No such file or directory
+
+Then either gold was not configured with plugins enabled, or clang
+was not built with ``-DLLVM_BINUTILS_INCDIR`` set properly. See
+the instructions for the
+`LLVM gold plugin `_.
+
+Controlling Backend Parallelism
+---
+.. _parallelism:
+
+By default, the ThinLTO link step will launch up to
+``std::thread::hardware_concurrency`` number of threads in parallel.
+For machines with hyper-threading, this is the total number of
+virtual cores. For some applications and machine configurations this
+may be too aggressive, in which case the amount of parallelism can
+be reduced to ``N`` via:
+
+- gold:
+  ``-Wl,-plugin-opt,jobs=N``
+- ld64:
+  ``-Wl,-mllvm,-threads=N``
+
+Incremental
+---
+.. _incremental:
+
+ThinLTO supports fast incremental builds through the use of a cache,
+which currently must be enabled through a linker option.
+
+- gold (as of LLVM r279883):
+  ``-Wl,-plugin-opt,cache-dir=/path/to/cache``
+- ld64 (support in clang 3.9 and Xcode 8):
+  ``-Wl,-cache_path_lto,/path/to/cache``
+
+Clang Bootstrap

[PATCH] D24809: [libcxx] [cmake] Stop stripping -m32 from compiler flags

2016-09-21 Thread Michał Górny via cfe-commits
mgorny created this revision.
mgorny added a reviewer: EricWF.
mgorny added a subscriber: cfe-commits.
Herald added subscribers: mgorny, beanz.

Stop stripping -m32 from the user-supplied flags. There is no valid reason to 
do that, stripping it silently is thoroughly confusing and makes it impossible 
to do distribution multi-ABI builds without resorting to ugly hacks.

Otherwise, in order to perform 32-bit builds the build scripts would have to 
use LIBCXX_BUILD_32_BITS. However, -m32 is only one of the many different ABI 
flags for different targets, and it really makes no sense to add separate CMake 
options for each possible -m* flag and then keep a mapping from well-known 
flags to the custom CMake options.


https://reviews.llvm.org/D24809

Files:
  CMakeLists.txt

Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -309,7 +309,7 @@
 
 # Remove flags that may have snuck in.
 remove_flags(-DNDEBUG -UNDEBUG -D_DEBUG
- -stdlib=libc++ -stdlib=libstdc++ -lc++abi -m32)
+ -stdlib=libc++ -stdlib=libstdc++ -lc++abi)
 
 # FIXME(EricWF): See the FIXME on LIBCXX_ENABLE_PEDANTIC.
 # Remove the -pedantic flag and -Wno-pedantic and -pedantic-errors


Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -309,7 +309,7 @@
 
 # Remove flags that may have snuck in.
 remove_flags(-DNDEBUG -UNDEBUG -D_DEBUG
- -stdlib=libc++ -stdlib=libstdc++ -lc++abi -m32)
+ -stdlib=libc++ -stdlib=libstdc++ -lc++abi)
 
 # FIXME(EricWF): See the FIXME on LIBCXX_ENABLE_PEDANTIC.
 # Remove the -pedantic flag and -Wno-pedantic and -pedantic-errors
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D24806: [docs] Add ThinLTO user documentation

2016-09-21 Thread Mehdi AMINI via cfe-commits
mehdi_amini accepted this revision.
mehdi_amini added a comment.
This revision is now accepted and ready to land.

Great! Thanks for writing it :)



Comment at: docs/CommandGuide/clang.rst:339
@@ +338,3 @@
+  The default for :option:`-flto` is :option:`-flto=full`, in which the
+  LLVM bitcode is suitable for regular Link Time Optimization (LTO), where
+  the linker merges all such modules into a single combined module for

What about using "monolithic" instead of "regular"?



Comment at: docs/ThinLTO.rst:14
@@ +13,3 @@
+runtime performance through whole-program analysis and cross-module
+optimization. However, regular LTO implements this by merging all
+input into a single monolithic module, which is not scalable

Same :)


https://reviews.llvm.org/D24806



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


Re: [PATCH] D24806: [docs] Add ThinLTO user documentation

2016-09-21 Thread Teresa Johnson via cfe-commits
tejohnson updated this revision to Diff 72081.
tejohnson added a comment.

Replace 'regular LTO' with 'monolithic LTO' to be more descriptive.


https://reviews.llvm.org/D24806

Files:
  docs/CommandGuide/clang.rst
  docs/ThinLTO.rst
  docs/index.rst

Index: docs/index.rst
===
--- docs/index.rst
+++ docs/index.rst
@@ -37,6 +37,7 @@
SourceBasedCodeCoverage
Modules
MSVCCompatibility
+   ThinLTO
CommandGuide/index
FAQ
 
Index: docs/ThinLTO.rst
===
--- /dev/null
+++ docs/ThinLTO.rst
@@ -0,0 +1,157 @@
+===
+ThinLTO
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+*ThinLTO* compilation is a new type of LTO that is both scalable and
+incremental. *LTO* (Link Time Optimization) achieves better
+runtime performance through whole-program analysis and cross-module
+optimization. However, monolithic LTO implements this by merging all
+input into a single module, which is not scalable
+in time or memory, and also prevents fast incremental compiles.
+
+In ThinLTO mode, as with regular LTO, clang emits LLVM bitcode after the
+compile phase. The ThinLTO bitcode is augmented with a compact summary
+of the module. During the link step, only the summaries are read and
+merged into a combined summary index, which includes an index of function
+locations for later cross-module function importing. Fast and efficient
+whole-program analysis is then performed on the combined summary index.
+
+However, all transformations, including function importing, occur
+later when the modules are optimized in fully parallel backends.
+By default, linkers_ that support ThinLTO are set up to launch
+the ThinLTO backends in threads. So the usage model is not affected
+as the distinction between the fast serial thin link step and the backends
+is transparent to the user.
+
+For more information on the ThinLTO design and current performance,
+see the LLVM blog post `ThinLTO: Scalable and Incremental LTO
+`_.
+While tuning is still in progress, results in the blog post show that
+ThinLTO already performs well compared to LTO, in many cases matching
+the performance improvement.
+
+Current Status
+==
+
+Clang/LLVM
+--
+.. _compiler:
+
+The 3.9 release of clang includes ThinLTO support. However, ThinLTO
+is under active development, and new features, improvements and bugfixes
+are being added for the next release. For the latest ThinLTO support,
+`build a recent version of clang and LLVM
+`_.
+
+Linkers
+---
+.. _linkers:
+.. _linker:
+
+ThinLTO is currently supported for the following linkers:
+
+- **gold (via the gold-plugin)**:
+  Similar to monolithic LTO, this requires using
+  a `gold linker configured with plugins enabled
+  `_.
+- **ld64**:
+  Starting with `Xcode 8 `_.
+
+Additionally, support is being added to the *lld* linker.
+
+Usage
+=
+
+Basic
+-
+
+To utilize ThinLTO, simply add the -flto=thin option to compile and link. E.g.
+
+.. code-block:: console
+
+  % clang -flto=thin -O2 file1.c file2.c -c
+  % clang -flto=thin -O2 file1.o file2.o -o a.out
+
+As mentioned earlier, by default the linkers will launch the ThinLTO backend
+threads in parallel, passing the resulting native object files back to the
+linker for the final native link.  As such, the usage model the same as
+non-LTO.
+
+With gold, if you see an error during the link of the form:
+
+.. code-block:: console
+
+  /usr/bin/ld: error: /path/to/clang/bin/../lib/LLVMgold.so: could not load plugin library: /path/to/clang/bin/../lib/LLVMgold.so: cannot open shared object file: No such file or directory
+
+Then either gold was not configured with plugins enabled, or clang
+was not built with ``-DLLVM_BINUTILS_INCDIR`` set properly. See
+the instructions for the
+`LLVM gold plugin `_.
+
+Controlling Backend Parallelism
+---
+.. _parallelism:
+
+By default, the ThinLTO link step will launch up to
+``std::thread::hardware_concurrency`` number of threads in parallel.
+For machines with hyper-threading, this is the total number of
+virtual cores. For some applications and machine configurations this
+may be too aggressive, in which case the amount of parallelism can
+be reduced to ``N`` via:
+
+- gold:
+  ``-Wl,-plugin-opt,jobs=N``
+- ld64:
+  ``-Wl,-mllvm,-threads=N``
+
+Incremental
+---
+.. _incremental:
+
+ThinLTO supports fast incremental builds through the use of a cache,
+which currently must be enabled through a linker option.
+
+- gold (as of LLVM r279883):
+  ``-Wl,-plugin-opt,cache-dir=/path/to/cache``
+- ld64 (support in clang 3.9 and Xcode 8):
+  ``-Wl,-cache_path_lto,/path/to/cache``
+
+Clang Bootstrap
+

r282089 - [docs] Add ThinLTO user documentation

2016-09-21 Thread Teresa Johnson via cfe-commits
Author: tejohnson
Date: Wed Sep 21 11:57:03 2016
New Revision: 282089

URL: http://llvm.org/viewvc/llvm-project?rev=282089&view=rev
Log:
[docs] Add ThinLTO user documentation

Summary: Add some user facing documentation on ThinLTO and how to use it.

Reviewers: mehdi_amini

Subscribers: mehdi_amini, cfe-commits

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

Added:
cfe/trunk/docs/ThinLTO.rst
Modified:
cfe/trunk/docs/CommandGuide/clang.rst
cfe/trunk/docs/index.rst

Modified: cfe/trunk/docs/CommandGuide/clang.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/CommandGuide/clang.rst?rev=282089&r1=282088&r2=282089&view=diff
==
--- cfe/trunk/docs/CommandGuide/clang.rst (original)
+++ cfe/trunk/docs/CommandGuide/clang.rst Wed Sep 21 11:57:03 2016
@@ -328,13 +328,19 @@ Code Generation Options
   model can be overridden with the tls_model attribute. The compiler will try
   to choose a more efficient model if possible.
 
-.. option:: -flto, -emit-llvm
+.. option:: -flto[=full,thin], -emit-llvm
 
   Generate output files in LLVM formats, suitable for link time optimization.
   When used with :option:`-S` this generates LLVM intermediate language
   assembly files, otherwise this generates LLVM bitcode format object files
   (which may be passed to the linker depending on the stage selection options).
 
+  The default for :option:`-flto` is :option:`-flto=full`, in which the
+  LLVM bitcode is suitable for monolithic Link Time Optimization (LTO), where
+  the linker merges all such modules into a single combined module for
+  optimization. With :option:`-flto=thin`, :doc:`ThinLTO <../ThinLTO>`
+  compilation is invoked instead.
+
 Driver Options
 ~~
 

Added: cfe/trunk/docs/ThinLTO.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ThinLTO.rst?rev=282089&view=auto
==
--- cfe/trunk/docs/ThinLTO.rst (added)
+++ cfe/trunk/docs/ThinLTO.rst Wed Sep 21 11:57:03 2016
@@ -0,0 +1,157 @@
+===
+ThinLTO
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+*ThinLTO* compilation is a new type of LTO that is both scalable and
+incremental. *LTO* (Link Time Optimization) achieves better
+runtime performance through whole-program analysis and cross-module
+optimization. However, monolithic LTO implements this by merging all
+input into a single module, which is not scalable
+in time or memory, and also prevents fast incremental compiles.
+
+In ThinLTO mode, as with regular LTO, clang emits LLVM bitcode after the
+compile phase. The ThinLTO bitcode is augmented with a compact summary
+of the module. During the link step, only the summaries are read and
+merged into a combined summary index, which includes an index of function
+locations for later cross-module function importing. Fast and efficient
+whole-program analysis is then performed on the combined summary index.
+
+However, all transformations, including function importing, occur
+later when the modules are optimized in fully parallel backends.
+By default, linkers_ that support ThinLTO are set up to launch
+the ThinLTO backends in threads. So the usage model is not affected
+as the distinction between the fast serial thin link step and the backends
+is transparent to the user.
+
+For more information on the ThinLTO design and current performance,
+see the LLVM blog post `ThinLTO: Scalable and Incremental LTO
+`_.
+While tuning is still in progress, results in the blog post show that
+ThinLTO already performs well compared to LTO, in many cases matching
+the performance improvement.
+
+Current Status
+==
+
+Clang/LLVM
+--
+.. _compiler:
+
+The 3.9 release of clang includes ThinLTO support. However, ThinLTO
+is under active development, and new features, improvements and bugfixes
+are being added for the next release. For the latest ThinLTO support,
+`build a recent version of clang and LLVM
+`_.
+
+Linkers
+---
+.. _linkers:
+.. _linker:
+
+ThinLTO is currently supported for the following linkers:
+
+- **gold (via the gold-plugin)**:
+  Similar to monolithic LTO, this requires using
+  a `gold linker configured with plugins enabled
+  `_.
+- **ld64**:
+  Starting with `Xcode 8 `_.
+
+Additionally, support is being added to the *lld* linker.
+
+Usage
+=
+
+Basic
+-
+
+To utilize ThinLTO, simply add the -flto=thin option to compile and link. E.g.
+
+.. code-block:: console
+
+  % clang -flto=thin -O2 file1.c file2.c -c
+  % clang -flto=thin -O2 file1.o file2.o -o a.out
+
+As mentioned earlier, by default the linkers will launch the ThinLTO backend
+threads in parallel, passing the resulting native object files back to the
+linker for the final nativ

Re: [PATCH] D24806: [docs] Add ThinLTO user documentation

2016-09-21 Thread Teresa Johnson via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL282089: [docs] Add ThinLTO user documentation (authored by 
tejohnson).

Changed prior to commit:
  https://reviews.llvm.org/D24806?vs=72081&id=72082#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D24806

Files:
  cfe/trunk/docs/CommandGuide/clang.rst
  cfe/trunk/docs/ThinLTO.rst
  cfe/trunk/docs/index.rst

Index: cfe/trunk/docs/ThinLTO.rst
===
--- cfe/trunk/docs/ThinLTO.rst
+++ cfe/trunk/docs/ThinLTO.rst
@@ -0,0 +1,157 @@
+===
+ThinLTO
+===
+
+.. contents::
+   :local:
+
+Introduction
+
+
+*ThinLTO* compilation is a new type of LTO that is both scalable and
+incremental. *LTO* (Link Time Optimization) achieves better
+runtime performance through whole-program analysis and cross-module
+optimization. However, monolithic LTO implements this by merging all
+input into a single module, which is not scalable
+in time or memory, and also prevents fast incremental compiles.
+
+In ThinLTO mode, as with regular LTO, clang emits LLVM bitcode after the
+compile phase. The ThinLTO bitcode is augmented with a compact summary
+of the module. During the link step, only the summaries are read and
+merged into a combined summary index, which includes an index of function
+locations for later cross-module function importing. Fast and efficient
+whole-program analysis is then performed on the combined summary index.
+
+However, all transformations, including function importing, occur
+later when the modules are optimized in fully parallel backends.
+By default, linkers_ that support ThinLTO are set up to launch
+the ThinLTO backends in threads. So the usage model is not affected
+as the distinction between the fast serial thin link step and the backends
+is transparent to the user.
+
+For more information on the ThinLTO design and current performance,
+see the LLVM blog post `ThinLTO: Scalable and Incremental LTO
+`_.
+While tuning is still in progress, results in the blog post show that
+ThinLTO already performs well compared to LTO, in many cases matching
+the performance improvement.
+
+Current Status
+==
+
+Clang/LLVM
+--
+.. _compiler:
+
+The 3.9 release of clang includes ThinLTO support. However, ThinLTO
+is under active development, and new features, improvements and bugfixes
+are being added for the next release. For the latest ThinLTO support,
+`build a recent version of clang and LLVM
+`_.
+
+Linkers
+---
+.. _linkers:
+.. _linker:
+
+ThinLTO is currently supported for the following linkers:
+
+- **gold (via the gold-plugin)**:
+  Similar to monolithic LTO, this requires using
+  a `gold linker configured with plugins enabled
+  `_.
+- **ld64**:
+  Starting with `Xcode 8 `_.
+
+Additionally, support is being added to the *lld* linker.
+
+Usage
+=
+
+Basic
+-
+
+To utilize ThinLTO, simply add the -flto=thin option to compile and link. E.g.
+
+.. code-block:: console
+
+  % clang -flto=thin -O2 file1.c file2.c -c
+  % clang -flto=thin -O2 file1.o file2.o -o a.out
+
+As mentioned earlier, by default the linkers will launch the ThinLTO backend
+threads in parallel, passing the resulting native object files back to the
+linker for the final native link.  As such, the usage model the same as
+non-LTO.
+
+With gold, if you see an error during the link of the form:
+
+.. code-block:: console
+
+  /usr/bin/ld: error: /path/to/clang/bin/../lib/LLVMgold.so: could not load plugin library: /path/to/clang/bin/../lib/LLVMgold.so: cannot open shared object file: No such file or directory
+
+Then either gold was not configured with plugins enabled, or clang
+was not built with ``-DLLVM_BINUTILS_INCDIR`` set properly. See
+the instructions for the
+`LLVM gold plugin `_.
+
+Controlling Backend Parallelism
+---
+.. _parallelism:
+
+By default, the ThinLTO link step will launch up to
+``std::thread::hardware_concurrency`` number of threads in parallel.
+For machines with hyper-threading, this is the total number of
+virtual cores. For some applications and machine configurations this
+may be too aggressive, in which case the amount of parallelism can
+be reduced to ``N`` via:
+
+- gold:
+  ``-Wl,-plugin-opt,jobs=N``
+- ld64:
+  ``-Wl,-mllvm,-threads=N``
+
+Incremental
+---
+.. _incremental:
+
+ThinLTO supports fast incremental builds through the use of a cache,
+which currently must be enabled through a linker option.
+
+- gold (as of LLVM r279883):
+  ``-Wl,-plugin-opt,cache-dir=/path/to/cache``
+- ld64 (support in clang 3.9 and Xcode 8):
+  ``-Wl,-cache_path_lto,/path/to/cache``
+
+Clang Bootstrap
+---
+
+To bootstrap clang/LLVM with ThinLTO, fol

Re: r282089 - [docs] Add ThinLTO user documentation

2016-09-21 Thread Teresa Johnson via cfe-commits
Anyone know how to get these changes on http://clang.llvm.org/docs/? Is
that site periodically refreshed or do I need to do something explicit?

Thanks,
Teresa

On Wed, Sep 21, 2016 at 9:57 AM, Teresa Johnson via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: tejohnson
> Date: Wed Sep 21 11:57:03 2016
> New Revision: 282089
>
> URL: http://llvm.org/viewvc/llvm-project?rev=282089&view=rev
> Log:
> [docs] Add ThinLTO user documentation
>
> Summary: Add some user facing documentation on ThinLTO and how to use it.
>
> Reviewers: mehdi_amini
>
> Subscribers: mehdi_amini, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D24806
>
> Added:
> cfe/trunk/docs/ThinLTO.rst
> Modified:
> cfe/trunk/docs/CommandGuide/clang.rst
> cfe/trunk/docs/index.rst
>
> Modified: cfe/trunk/docs/CommandGuide/clang.rst
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/
> CommandGuide/clang.rst?rev=282089&r1=282088&r2=282089&view=diff
> 
> ==
> --- cfe/trunk/docs/CommandGuide/clang.rst (original)
> +++ cfe/trunk/docs/CommandGuide/clang.rst Wed Sep 21 11:57:03 2016
> @@ -328,13 +328,19 @@ Code Generation Options
>model can be overridden with the tls_model attribute. The compiler will
> try
>to choose a more efficient model if possible.
>
> -.. option:: -flto, -emit-llvm
> +.. option:: -flto[=full,thin], -emit-llvm
>
>Generate output files in LLVM formats, suitable for link time
> optimization.
>When used with :option:`-S` this generates LLVM intermediate language
>assembly files, otherwise this generates LLVM bitcode format object
> files
>(which may be passed to the linker depending on the stage selection
> options).
>
> +  The default for :option:`-flto` is :option:`-flto=full`, in which the
> +  LLVM bitcode is suitable for monolithic Link Time Optimization (LTO),
> where
> +  the linker merges all such modules into a single combined module for
> +  optimization. With :option:`-flto=thin`, :doc:`ThinLTO <../ThinLTO>`
> +  compilation is invoked instead.
> +
>  Driver Options
>  ~~
>
>
> Added: cfe/trunk/docs/ThinLTO.rst
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/
> ThinLTO.rst?rev=282089&view=auto
> 
> ==
> --- cfe/trunk/docs/ThinLTO.rst (added)
> +++ cfe/trunk/docs/ThinLTO.rst Wed Sep 21 11:57:03 2016
> @@ -0,0 +1,157 @@
> +===
> +ThinLTO
> +===
> +
> +.. contents::
> +   :local:
> +
> +Introduction
> +
> +
> +*ThinLTO* compilation is a new type of LTO that is both scalable and
> +incremental. *LTO* (Link Time Optimization) achieves better
> +runtime performance through whole-program analysis and cross-module
> +optimization. However, monolithic LTO implements this by merging all
> +input into a single module, which is not scalable
> +in time or memory, and also prevents fast incremental compiles.
> +
> +In ThinLTO mode, as with regular LTO, clang emits LLVM bitcode after the
> +compile phase. The ThinLTO bitcode is augmented with a compact summary
> +of the module. During the link step, only the summaries are read and
> +merged into a combined summary index, which includes an index of function
> +locations for later cross-module function importing. Fast and efficient
> +whole-program analysis is then performed on the combined summary index.
> +
> +However, all transformations, including function importing, occur
> +later when the modules are optimized in fully parallel backends.
> +By default, linkers_ that support ThinLTO are set up to launch
> +the ThinLTO backends in threads. So the usage model is not affected
> +as the distinction between the fast serial thin link step and the backends
> +is transparent to the user.
> +
> +For more information on the ThinLTO design and current performance,
> +see the LLVM blog post `ThinLTO: Scalable and Incremental LTO
> + >`_.
> +While tuning is still in progress, results in the blog post show that
> +ThinLTO already performs well compared to LTO, in many cases matching
> +the performance improvement.
> +
> +Current Status
> +==
> +
> +Clang/LLVM
> +--
> +.. _compiler:
> +
> +The 3.9 release of clang includes ThinLTO support. However, ThinLTO
> +is under active development, and new features, improvements and bugfixes
> +are being added for the next release. For the latest ThinLTO support,
> +`build a recent version of clang and LLVM
> +`_.
> +
> +Linkers
> +---
> +.. _linkers:
> +.. _linker:
> +
> +ThinLTO is currently supported for the following linkers:
> +
> +- **gold (via the gold-plugin)**:
> +  Similar to monolithic LTO, this requires using
> +  a `gold linker configured with plugins enabled
> +  `_.
> +- **ld64**:
> +  Starting with `Xcode 8 

Re: r282089 - [docs] Add ThinLTO user documentation

2016-09-21 Thread Mehdi Amini via cfe-commits
It is automatically refreshed frequently I believe.

If it is not there tomorrow, we should start being worried :)

— 
Mehdi
> On Sep 21, 2016, at 10:57 AM, Teresa Johnson  wrote:
> 
> Anyone know how to get these changes on http://clang.llvm.org/docs/ 
> ? Is that site periodically refreshed or do I 
> need to do something explicit?
> 
> Thanks,
> Teresa
> 
> On Wed, Sep 21, 2016 at 9:57 AM, Teresa Johnson via cfe-commits 
> mailto:cfe-commits@lists.llvm.org>> wrote:
> Author: tejohnson
> Date: Wed Sep 21 11:57:03 2016
> New Revision: 282089
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=282089&view=rev 
> 
> Log:
> [docs] Add ThinLTO user documentation
> 
> Summary: Add some user facing documentation on ThinLTO and how to use it.
> 
> Reviewers: mehdi_amini
> 
> Subscribers: mehdi_amini, cfe-commits
> 
> Differential Revision: https://reviews.llvm.org/D24806 
> 
> 
> Added:
> cfe/trunk/docs/ThinLTO.rst
> Modified:
> cfe/trunk/docs/CommandGuide/clang.rst
> cfe/trunk/docs/index.rst
> 
> Modified: cfe/trunk/docs/CommandGuide/clang.rst
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/CommandGuide/clang.rst?rev=282089&r1=282088&r2=282089&view=diff
>  
> 
> ==
> --- cfe/trunk/docs/CommandGuide/clang.rst (original)
> +++ cfe/trunk/docs/CommandGuide/clang.rst Wed Sep 21 11:57:03 2016
> @@ -328,13 +328,19 @@ Code Generation Options
>model can be overridden with the tls_model attribute. The compiler will try
>to choose a more efficient model if possible.
> 
> -.. option:: -flto, -emit-llvm
> +.. option:: -flto[=full,thin], -emit-llvm
> 
>Generate output files in LLVM formats, suitable for link time optimization.
>When used with :option:`-S` this generates LLVM intermediate language
>assembly files, otherwise this generates LLVM bitcode format object files
>(which may be passed to the linker depending on the stage selection 
> options).
> 
> +  The default for :option:`-flto` is :option:`-flto=full`, in which the
> +  LLVM bitcode is suitable for monolithic Link Time Optimization (LTO), where
> +  the linker merges all such modules into a single combined module for
> +  optimization. With :option:`-flto=thin`, :doc:`ThinLTO <../ThinLTO>`
> +  compilation is invoked instead.
> +
>  Driver Options
>  ~~
> 
> 
> Added: cfe/trunk/docs/ThinLTO.rst
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ThinLTO.rst?rev=282089&view=auto
>  
> 
> ==
> --- cfe/trunk/docs/ThinLTO.rst (added)
> +++ cfe/trunk/docs/ThinLTO.rst Wed Sep 21 11:57:03 2016
> @@ -0,0 +1,157 @@
> +===
> +ThinLTO
> +===
> +
> +.. contents::
> +   :local:
> +
> +Introduction
> +
> +
> +*ThinLTO* compilation is a new type of LTO that is both scalable and
> +incremental. *LTO* (Link Time Optimization) achieves better
> +runtime performance through whole-program analysis and cross-module
> +optimization. However, monolithic LTO implements this by merging all
> +input into a single module, which is not scalable
> +in time or memory, and also prevents fast incremental compiles.
> +
> +In ThinLTO mode, as with regular LTO, clang emits LLVM bitcode after the
> +compile phase. The ThinLTO bitcode is augmented with a compact summary
> +of the module. During the link step, only the summaries are read and
> +merged into a combined summary index, which includes an index of function
> +locations for later cross-module function importing. Fast and efficient
> +whole-program analysis is then performed on the combined summary index.
> +
> +However, all transformations, including function importing, occur
> +later when the modules are optimized in fully parallel backends.
> +By default, linkers_ that support ThinLTO are set up to launch
> +the ThinLTO backends in threads. So the usage model is not affected
> +as the distinction between the fast serial thin link step and the backends
> +is transparent to the user.
> +
> +For more information on the ThinLTO design and current performance,
> +see the LLVM blog post `ThinLTO: Scalable and Incremental LTO
> + >`_.
> +While tuning is still in progress, results in the blog post show that
> +ThinLTO already performs well compared to LTO, in many cases matching
> +the performance improvement.
> +
> +Current Status
> +==
> +
> +Clang/LLVM
> +--
> +.. _compiler:
> +
> +The 3.9 release of clang includes ThinLTO support.

LLVM buildmaster will be restarted tonight

2016-09-21 Thread Galina Kistanova via cfe-commits
Hello everyone,

LLVM buildmaster will be updated and restarted after 6 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


Re: [PATCH] D24669: {Sema] Gcc compatibility of vector shift.

2016-09-21 Thread Vladimir Yakovlev via cfe-commits
vbyakovlcl added a comment.

Clang 3.8 balances vector shift operand erroneous using CheckVectorOperands 
which converts one of operand to the type of another. In 
https://reviews.llvm.org/D21678 it was fixed by using checkVectorShift instead. 
As result clang does not emit error if shift operands have different element 
sizes (bat gcc does).


Repository:
  rL LLVM

https://reviews.llvm.org/D24669



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


r282082 - [AVX512] Fix return types on __builtin_ia32_gather3XivXdi builtins

2016-09-21 Thread Cameron McInally via cfe-commits
Author: mcinally
Date: Wed Sep 21 11:07:40 2016
New Revision: 282082

URL: http://llvm.org/viewvc/llvm-project?rev=282082&view=rev
Log:
[AVX512] Fix return types on __builtin_ia32_gather3XivXdi builtins

The return types on the AVX512 __builtin_ia32_gather3XivXdi builtins are 
incorrect. The return type should match the type of the pass through vector.

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

-This line, and those below, will be ignored--

Minclude/clang/Basic/BuiltinsX86.def

Modified:
cfe/trunk/include/clang/Basic/BuiltinsX86.def

Modified: cfe/trunk/include/clang/Basic/BuiltinsX86.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsX86.def?rev=282082&r1=282081&r2=282082&view=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsX86.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsX86.def Wed Sep 21 11:07:40 2016
@@ -1037,17 +1037,17 @@ TARGET_BUILTIN(__builtin_ia32_extractf64
 TARGET_BUILTIN(__builtin_ia32_extractf32x4_mask, "V4fV16fIiV4fUc", "", 
"avx512f")
 
 TARGET_BUILTIN(__builtin_ia32_gather3div2df, "V2dV2ddC*V2LLiUci","","avx512vl")
-TARGET_BUILTIN(__builtin_ia32_gather3div2di, 
"V4iV2LLiLLiC*V2LLiUci","","avx512vl")
+TARGET_BUILTIN(__builtin_ia32_gather3div2di, 
"V2LLiV2LLiLLiC*V2LLiUci","","avx512vl")
 TARGET_BUILTIN(__builtin_ia32_gather3div4df, "V4dV4ddC*V4LLiUci","","avx512vl")
-TARGET_BUILTIN(__builtin_ia32_gather3div4di, 
"V8iV4LLiLLiC*V4LLiUci","","avx512vl")
+TARGET_BUILTIN(__builtin_ia32_gather3div4di, 
"V4LLiV4LLiLLiC*V4LLiUci","","avx512vl")
 TARGET_BUILTIN(__builtin_ia32_gather3div4sf, "V4fV4ffC*V2LLiUci","","avx512vl")
 TARGET_BUILTIN(__builtin_ia32_gather3div4si, "V4iV4iiC*V2LLiUci","","avx512vl")
 TARGET_BUILTIN(__builtin_ia32_gather3div8sf, "V4fV4ffC*V4LLiUci","","avx512vl")
 TARGET_BUILTIN(__builtin_ia32_gather3div8si, "V4iV4iiC*V4LLiUci","","avx512vl")
 TARGET_BUILTIN(__builtin_ia32_gather3siv2df, "V2dV2ddC*V4iUci","","avx512vl")
-TARGET_BUILTIN(__builtin_ia32_gather3siv2di, 
"V4iV2LLiLLiC*V4iUci","","avx512vl")
+TARGET_BUILTIN(__builtin_ia32_gather3siv2di, 
"V2LLiV2LLiLLiC*V4iUci","","avx512vl")
 TARGET_BUILTIN(__builtin_ia32_gather3siv4df, "V4dV4ddC*V4iUci","","avx512vl")
-TARGET_BUILTIN(__builtin_ia32_gather3siv4di, 
"V8iV4LLiLLiC*V4iUci","","avx512vl")
+TARGET_BUILTIN(__builtin_ia32_gather3siv4di, 
"V4LLiV4LLiLLiC*V4iUci","","avx512vl")
 TARGET_BUILTIN(__builtin_ia32_gather3siv4sf, "V4fV4ffC*V4iUci","","avx512vl")
 TARGET_BUILTIN(__builtin_ia32_gather3siv4si, "V4iV4iiC*V4iUci","","avx512vl")
 TARGET_BUILTIN(__builtin_ia32_gather3siv8sf, "V8fV8ffC*V8iUci","","avx512vl")


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


Re: [PATCH] D24693: [CodeGen] Don't emit lifetime intrinsics for some local variables

2016-09-21 Thread Vitaly Buka via cfe-commits
Intrinsics are invalid there, code is generated in such way that variable
is being accessed after lifetime.end.
I suspect that optimizer can make invalid code because of this, but I can't
reproduce.
So I think it's safer to remove them at all and don't wait for miscompile
reports.

Still if performance is greater concern then potential miscompiles, I can
limit this only to asan-use-after-scope.



On Wed, Sep 21, 2016 at 8:49 AM Akira Hatanaka  wrote:

> ahatanak added a comment.
>
> Do we want to remove lifetime intrinsics when we aren't doing the
> asan-use-after-scope check? Since this isn't a mis-compile caused by
> inaccurate lifetime intrinsics, I was wondering whether we should do this
> only when asan-use-after-scope is on to minimize the impact on compile time.
>
>
> https://reviews.llvm.org/D24693
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D24693: [CodeGen] Don't emit lifetime intrinsics for some local variables

2016-09-21 Thread Vitaly Buka via cfe-commits
vitalybuka added a comment.

Intrinsics are invalid there, code is generated in such way that variable is 
being accessed after lifetime.end.
I suspect that optimizer can make invalid code because of this, but I can't 
reproduce.
So I think it's safer to remove them at all and don't wait for miscompile 
reports.

Still if performance is greater concern than potential miscompiles, I can limit 
this only to asan-use-after-scope.


https://reviews.llvm.org/D24693



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


[PATCH] D24812: Lit C++11 Compatibility Patch #11

2016-09-21 Thread Charles Li via cfe-commits
tigerleapgorge created this revision.
tigerleapgorge added a reviewer: rsmith.
tigerleapgorge added a subscriber: cfe-commits.
Herald added a subscriber: aemerson.

Hi Everyone,


Here is the 11th Lit C++11 compatibility patch.
This will most likely be my final Lit patch.
I have updated 16 tests this time.
Here are the explanations for each test.


CodeGenCXX/exceptions.cpp
  Implicit destructors are noexcept (nothrow) in C++11.
  The LLVM IR invocation for these destructors changed from “invoke” to “call”.

  This is related to C++11’s standard 15.4\14 and 15.4\15 in [except.spec] 
  In C++11, Clang marks implicit destructors as “nothrow” in the AST and 
“nounwind” in the LLVM IR.

[except.spec] 15.4\14 
  An implicitly declared special member function shall have an 
exception-specification. 
  If f is an implicitly declared default constructor, copy constructor, 
move constructor, 
  destructor, copy assignment operator, or move assignment operator, 
  its implicit exception-specification specifies the type-id T if and only 
if T is allowed 
  by the exception-specification of a function directly invoked by f’s 
implicit definition; 
  f shall allow all exceptions if any function it directly invokes allows 
all exceptions,
  and f shall allow no exceptions if every function it directly invokes 
allows no exceptions.

[except.spec] 15.4\15
  A deallocation function (3.7.4.2) with no explicit exception-specification
  is treated as if it were specified with noexcept(true).


  IR changes are as follows:

test1::B::~B() is nothrow in C++11. IR for its invocation changed from 
invoke to call.
  C++98:  invoke void @_ZN5test11BD1Ev(%"struct.test1::B"* %temp.lvalue)
  C++98:  to label %invoke.cont4 unwind label %terminate.lpad

  C++11:  call void @_ZN5test11BD1Ev(%"struct.test1::B"* %temp.lvalue) #8

The landing pad and its associated attribute no longer exists in C++11.

  C++98:  ; Function Attrs: noinline noreturn nounwind
  C++98:  define linkonce_odr hidden void @__clang_call_terminate(i8*) #4 
comdat {
  C++98:%2 = call i8* @__cxa_begin_catch(i8* %0) #8
  C++98:call void @_ZSt9terminatev() #12
  C++98:unreachable
  C++98:  }

  C++98:  attributes #4 = { noinline noreturn nounwind }

  C++11: 

  test2::A::operator delete(void*, unsigned long) is nothrow in C++11.
  test3::A::operator delete(void*, void*, double) is nothrow in C++11.
  test5::T::~T()  is nothrow in C++11.
  test7::A::~A()  is nothrow in C++11.
  test10::C::~C() is nothrow in C++11.
  test11::A::~A() is nothrow in C++11


CodeGenCXX/lpad-linetable.cpp
  The purpose of this test is to verify landingpad line numbers when catching
  any exceptions thrown by the destructors for “longs” and “shorts” as they go 
out of scope.
  However, in C++11, “longs” and “short”’s destructors are noexcept (nothrow).
   ~std::_Vector_base >() noexcept
   ~std::_Vector_base >() noexcept 

  Because these destructors no longer throw any exceptions in C++11, there is 
no need to generate the landingpads.
  And since the purpose of this test is to verify for landingpad line table, I 
have restricted this test to C++98.


CodeGenCXX/mangle-unnamed.cpp
  Test section f6() verifies the mangled name of the variable b that is inside 
  the static anonymous union along with an anonymous union of a unnamed bit 
field.

  Running this test in C++11 results in the following error.
error: call to implicitly-deleted default constructor of '(anonymous union 
at t.cpp:2:10)'
note: default constructor of '' is implicitly deleted because field '' has 
a deleted default constructor
note: default constructor of '' is implicitly deleted because all data 
members are const-qualified

  This is most likely due to interaction between three parts of the C++11 
standard:
1. Unnamed bit-field cannot be initialized.
 C++ Standard section 9.6.2 [class.bit]
A declaration for a bit-field that omits the identifier declares an 
unnamed bit-field.
Unnamed bit-fields are not members and cannot be initialized.
2. Introduction of keyword “delete”. 
3. Change in rules regarding Unions.
 http://www.stroustrup.com/C++11FAQ.html#unions
   If a union has a member with a user-defined constructor, copy, or 
destructor
   then that special function is deleted;
   that is, it cannot be used for an object of the union type. This is 
new.

  For f6(), Since the unnamed bitfield “int : 1;” can not be initialized, 
  its constructor is considered “deleted”, therefore it cannot be used inside a 
union.
  Hence f6() would be an invalid test for C++11.

  Since this test verifies for name managling, I have restricted f6() to C++98.


CodeGenCXX/arm.cpp
  test3::A::~A() is noexcept (nothrow) in C++11.
  LLVM IR invocation for this destructor has changed from “invoke” to “call”.


CodeGenCXX/eh-aggregate-copy-des

Re: [PATCH] D21698: [OpenCL] Allow disabling types and declarations associated with extensions

2016-09-21 Thread Anastasia Stulova via cfe-commits
Anastasia added a comment.

In https://reviews.llvm.org/D21698#546733, @yaxunl wrote:

> In https://reviews.llvm.org/D21698#540237, @Anastasia wrote:
>
> > I have made an experiment with a simple kernel:
> >
> >   void foo1(void);
> >   void foo2(void);
> >   void foo3(void);
> >   void foo4(void);
> >   void foo5(void);
> >   void foo6(void);
> >   void foo7(void);
> >   void foo8(void);
> >   void foo9(void);
> >   void foo10(void);
> >  
> >   void test(){
> > foo1();
> > foo2();
> > foo3();
> > foo4();
> > foo5();
> > foo6();
> > foo7();
> > foo8();
> > foo9();
> > foo10();
> >   }
> >   
> >
> > I am using time utility of linux to measure the compile time running Clang 
> > in CL2.0 mode and average over 100 samples. It shows me around 7% overhead 
> > with your approach.
>
>
> Since the program is very small, it is difficult to measure the compilation 
> time accurately. I compile the program 1000 times and measure its time in a 
> script:
>
>$ cat run.sh
>run() {
>i=1
>while [[ $i -le 1000 ]]; do
>  ./$1 -cc1 -emit-llvm tmp.cl
>  i=$((i+1))
>done
>}
>   
>   time -p run $1
>
>
>
> Even so, I found large variations in the measured compilation time. I ran the 
> script 10 times for clang before my change and I got the real time
>
>   real 8.96
>   real 9.01
>   real 8.99
>   real 9.07
>   real 9.03
>   real 8.99
>   real 9.03
>   real 9.01
>   real 8.99
>   real 9.01
>  
>
>
> and the average time is 9.009s.
>
> For clang after my change, I got
>
>   real 9.06
>   real 9.09
>   real 9.10
>   real 9.03
>   real 9.05
>   real 9.17
>   real 9.08
>   real 9.08
>   real 9.07
>   real 9.08
>  
>
>
> And the average time is 9.081s.
>
> The increase of compilation time is 0.8%. Considering this program consists 
> mostly of function declarations, which emphasized the cost of evaluating 
> disabled function declarations unrealistically. In real programs this 
> increment in compilation time should be even smaller.
>
> Since the increment of compilation time is less than 1% even for exaggerated 
> cases, I think it is reasonable to accept the cost for the improved 
> diagnostics for extensions.
>
> If there are concerns that the newly added diagnostics may break applications 
> which use builtin functions associated with an extension without enabling it, 
> we can make the diagnostic msg a warning which can be turned off.


Ok. Sure. I will profile a few more benchmarks and let you know.


https://reviews.llvm.org/D21698



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


Re: [PATCH] D24792: [analyzer] Fix crash in RetainCountChecker::checkEndFunction

2016-09-21 Thread Anna Zaks via cfe-commits
zaks.anna added a comment.

> However, the assert here has a reason: we clearly shouldn't be trying to 
> analyze synthesized bodies as top-level functions.


Yes, seems like we should update r264687 so that we use the available body when 
analyzing as top level.

Another possible issue is that we will use the synthesized body if the function 
name **starts with** "OSAtomicCompareAndSwap" since we do not match the full 
function name. If the function body is available, there is a higher chance it 
is implementing something other than the standard compare and swap. We might 
want to start matching the full names of the functions are are synthesizing. 
@alexshap is that a problem for your codebase?


Repository:
  rL LLVM

https://reviews.llvm.org/D24792



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


Re: [PATCH] D24513: [AMDGPU] Expose flat work group size, register and wave control attributes

2016-09-21 Thread Konstantin Zhuravlyov via cfe-commits
kzhuravl added a comment.

Thanks for the review Aaron!

Tom, would you be able to do a final glance over?


https://reviews.llvm.org/D24513



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


Re: [PATCH] D24693: [CodeGen] Don't emit lifetime intrinsics for some local variables

2016-09-21 Thread David Majnemer via cfe-commits
majnemer added a subscriber: majnemer.
majnemer added a comment.

In https://reviews.llvm.org/D24693#548739, @ahatanak wrote:

> Do we want to remove lifetime intrinsics when we aren't doing the 
> asan-use-after-scope check? Since this isn't a mis-compile caused by 
> inaccurate lifetime intrinsics, I was wondering whether we should do this 
> only when asan-use-after-scope is on to minimize the impact on compile time.


This doesn't sound right.  Given the example in the description, we are 
accessing the memory location after end has been called: this seems like a real 
miscompile.  It would appear unsafe to only do this for asan.


https://reviews.llvm.org/D24693



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


Re: [PATCH] D24792: [analyzer] Fix crash in RetainCountChecker::checkEndFunction

2016-09-21 Thread Alexander Shaposhnikov via cfe-commits
alexshap added a comment.

> is that a problem for your codebase?


@zaks.anna  - yes it is.

> Another possible issue is that we will use the synthesized body if the 
> function name starts with "OSAtomicCompareAndSwap" since ?>we do not match 
> the full function name. If the function body is available, there is a higher 
> chance it is implementing something other >than the standard compare and 
> swap. We might want to start matching the full names of the functions are are 
> synthesizing.


yeah - i've just wanted to post a comment about it - btw - 
OSAtomicCompareAndSwap is not the only example (dispatch_sync, dispatch_async 
etc also create a problem). But in my case i ran into issue on the exact match 
(but on the other function).

I have not updated this patch yet because I have not found a good solution - 
still thinking (any suggestions appreciated). I probably understand the 
motivation behind the changes introduced in r264687 but yes, it causes several 
issues.


Repository:
  rL LLVM

https://reviews.llvm.org/D24792



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


[PATCH] D24813: Driver: Add a test for triple with opencl environment

2016-09-21 Thread Tom Stellard via cfe-commits
tstellarAMD created this revision.
tstellarAMD added a reviewer: Anastasia.
tstellarAMD added a subscriber: cfe-commits.
Herald added subscribers: yaxunl, nhaehnle, wdng.

https://reviews.llvm.org/D24813

Files:
  test/Driver/amdgpu-toolchain.c

Index: test/Driver/amdgpu-toolchain.c
===
--- test/Driver/amdgpu-toolchain.c
+++ test/Driver/amdgpu-toolchain.c
@@ -4,3 +4,6 @@
 
 // RUN: %clang -### -g -target amdgcn--amdhsa -mcpu=kaveri %s 2>&1 | FileCheck 
-check-prefix=DWARF_VER %s
 // DWARF_VER: "-dwarf-version=2"
+
+// RUN: %clang -### -target amdgcn--amdhsa-opencl %s 2>&1 | FileCheck 
--check-prefix=OPENCL-ENV %s
+// OPENCL-ENV: "-triple" "amdgcn--amdhsa-opencl"


Index: test/Driver/amdgpu-toolchain.c
===
--- test/Driver/amdgpu-toolchain.c
+++ test/Driver/amdgpu-toolchain.c
@@ -4,3 +4,6 @@
 
 // RUN: %clang -### -g -target amdgcn--amdhsa -mcpu=kaveri %s 2>&1 | FileCheck -check-prefix=DWARF_VER %s
 // DWARF_VER: "-dwarf-version=2"
+
+// RUN: %clang -### -target amdgcn--amdhsa-opencl %s 2>&1 | FileCheck --check-prefix=OPENCL-ENV %s
+// OPENCL-ENV: "-triple" "amdgcn--amdhsa-opencl"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[libclc] r282106 - Provide vstore_half helper to workaround clc restrictions

2016-09-21 Thread Jan Vesely via cfe-commits
Author: jvesely
Date: Wed Sep 21 15:15:55 2016
New Revision: 282106

URL: http://llvm.org/viewvc/llvm-project?rev=282106&view=rev
Log:
Provide vstore_half helper to workaround clc restrictions

clang won't accept half precision loads and stores without cl_khr_fp16 since 
r281904

Added:
libclc/trunk/generic/lib/shared/vstore_half_helpers.ll
Modified:
libclc/trunk/generic/lib/SOURCES
libclc/trunk/generic/lib/shared/vstore.cl
libclc/trunk/generic/lib/shared/vstore_half.inc

Modified: libclc/trunk/generic/lib/SOURCES
URL: 
http://llvm.org/viewvc/llvm-project/libclc/trunk/generic/lib/SOURCES?rev=282106&r1=282105&r2=282106&view=diff
==
--- libclc/trunk/generic/lib/SOURCES (original)
+++ libclc/trunk/generic/lib/SOURCES Wed Sep 21 15:15:55 2016
@@ -142,6 +142,7 @@ shared/max.cl
 shared/min.cl
 shared/vload.cl
 shared/vstore.cl
+shared/vstore_half_helpers.ll
 workitem/get_global_id.cl
 workitem/get_global_size.cl
 image/get_image_dim.cl

Modified: libclc/trunk/generic/lib/shared/vstore.cl
URL: 
http://llvm.org/viewvc/llvm-project/libclc/trunk/generic/lib/shared/vstore.cl?rev=282106&r1=282105&r2=282106&view=diff
==
--- libclc/trunk/generic/lib/shared/vstore.cl (original)
+++ libclc/trunk/generic/lib/shared/vstore.cl Wed Sep 21 15:15:55 2016
@@ -52,32 +52,45 @@ VSTORE_TYPES()
 #endif
 
 /* vstore_half are legal even without cl_khr_fp16 */
+#define DECLARE_HELPER(STYPE, AS) void 
__clc_vstore_half_##STYPE##_helper##AS(STYPE, AS half *);
 
-#define VEC_STORE1(val) mem[offset++] = val;
-#define VEC_STORE2(val) \
-   VEC_STORE1(val.lo) \
-   VEC_STORE1(val.hi)
-#define VEC_STORE3(val) \
-   VEC_STORE1(val.s0) \
-   VEC_STORE1(val.s1) \
-   VEC_STORE1(val.s2)
-#define VEC_STORE4(val) \
-   VEC_STORE2(val.lo) \
-   VEC_STORE2(val.hi)
-#define VEC_STORE8(val) \
-   VEC_STORE4(val.lo) \
-   VEC_STORE4(val.hi)
-#define VEC_STORE16(val) \
-   VEC_STORE8(val.lo) \
-   VEC_STORE8(val.hi)
+DECLARE_HELPER(float, __private);
+DECLARE_HELPER(float, __global);
+DECLARE_HELPER(float, __local);
 
-#define __FUNC(SUFFIX, VEC_SIZE, TYPE, AS) \
+#ifdef cl_khr_fp64
+#pragma OPENCL EXTENSION cl_khr_fp64 : enable
+DECLARE_HELPER(double, __private);
+DECLARE_HELPER(double, __global);
+DECLARE_HELPER(double, __local);
+#endif
+
+
+#define VEC_STORE1(STYPE, AS, val) __clc_vstore_half_##STYPE##_helper##AS 
(val, &mem[offset++]);
+#define VEC_STORE2(STYPE, AS, val) \
+   VEC_STORE1(STYPE, AS, val.lo) \
+   VEC_STORE1(STYPE, AS, val.hi)
+#define VEC_STORE3(STYPE, AS, val) \
+   VEC_STORE1(STYPE, AS, val.s0) \
+   VEC_STORE1(STYPE, AS, val.s1) \
+   VEC_STORE1(STYPE, AS, val.s2)
+#define VEC_STORE4(STYPE, AS, val) \
+   VEC_STORE2(STYPE, AS, val.lo) \
+   VEC_STORE2(STYPE, AS, val.hi)
+#define VEC_STORE8(STYPE, AS, val) \
+   VEC_STORE4(STYPE, AS, val.lo) \
+   VEC_STORE4(STYPE, AS, val.hi)
+#define VEC_STORE16(STYPE, AS, val) \
+   VEC_STORE8(STYPE, AS, val.lo) \
+   VEC_STORE8(STYPE, AS, val.hi)
+
+#define __FUNC(SUFFIX, VEC_SIZE, TYPE, STYPE, AS) \
   _CLC_OVERLOAD _CLC_DEF void vstore_half##SUFFIX(TYPE vec, size_t offset, AS 
half *mem) { \
 offset *= VEC_SIZE; \
-VEC_STORE##VEC_SIZE(vec) \
+VEC_STORE##VEC_SIZE(STYPE, AS, vec) \
   }
 
-#define FUNC(SUFFIX, VEC_SIZE, TYPE, AS) __FUNC(SUFFIX, VEC_SIZE, TYPE, AS)
+#define FUNC(SUFFIX, VEC_SIZE, TYPE, STYPE, AS) __FUNC(SUFFIX, VEC_SIZE, TYPE, 
STYPE, AS)
 
 #define __CLC_BODY "vstore_half.inc"
 #include 

Modified: libclc/trunk/generic/lib/shared/vstore_half.inc
URL: 
http://llvm.org/viewvc/llvm-project/libclc/trunk/generic/lib/shared/vstore_half.inc?rev=282106&r1=282105&r2=282106&view=diff
==
--- libclc/trunk/generic/lib/shared/vstore_half.inc (original)
+++ libclc/trunk/generic/lib/shared/vstore_half.inc Wed Sep 21 15:15:55 2016
@@ -1,10 +1,10 @@
 
 #ifdef __CLC_VECSIZE
-  FUNC(__CLC_VECSIZE, __CLC_VECSIZE, __CLC_GENTYPE, __private);
-  FUNC(__CLC_VECSIZE, __CLC_VECSIZE, __CLC_GENTYPE, __local);
-  FUNC(__CLC_VECSIZE, __CLC_VECSIZE, __CLC_GENTYPE, __global);
+  FUNC(__CLC_VECSIZE, __CLC_VECSIZE, __CLC_GENTYPE, __CLC_SCALAR_GENTYPE, 
__private);
+  FUNC(__CLC_VECSIZE, __CLC_VECSIZE, __CLC_GENTYPE, __CLC_SCALAR_GENTYPE, 
__local);
+  FUNC(__CLC_VECSIZE, __CLC_VECSIZE, __CLC_GENTYPE, __CLC_SCALAR_GENTYPE, 
__global);
 #else
-  FUNC(, 1, __CLC_GENTYPE, __private);
-  FUNC(, 1, __CLC_GENTYPE, __local);
-  FUNC(, 1, __CLC_GENTYPE, __global);
+  FUNC(, 1, __CLC_GENTYPE, __CLC_SCALAR_GENTYPE, __private);
+  FUNC(, 1, __CLC_GENTYPE, __CLC_SCALAR_GENTYPE, __local);
+  FUNC(, 1, __CLC_GENTYPE, __CLC_SCALAR_GENTYPE, __global);
 #endif

Added: libclc/trunk/generic/lib/shared/vstore_half_helpers.ll
URL: 
http://llvm.org/viewvc/llvm-project/libclc/trunk/generic/lib/share

r282108 - Add -Wignored-pragma-intrinsic flag

2016-09-21 Thread Albert Gutowski via cfe-commits
Author: agutowski
Date: Wed Sep 21 15:19:21 2016
New Revision: 282108

URL: http://llvm.org/viewvc/llvm-project?rev=282108&view=rev
Log:
Add -Wignored-pragma-intrinsic flag

Summary: People might want to receive warnings about pragmas but not about 
intrinsics that are implemented in intrin.h.

Reviewers: thakis, hans

Subscribers: cfe-commits

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

Modified:
cfe/trunk/include/clang/Basic/DiagnosticGroups.td
cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
cfe/trunk/test/Preprocessor/pragma_microsoft.c

Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticGroups.td?rev=282108&r1=282107&r2=282108&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Wed Sep 21 15:19:21 2016
@@ -439,8 +439,9 @@ def UninitializedSometimes : DiagGroup<"
 def UninitializedStaticSelfInit : DiagGroup<"static-self-init">;
 def Uninitialized  : DiagGroup<"uninitialized", [UninitializedSometimes,
  UninitializedStaticSelfInit]>;
+def IgnoredPragmaIntrinsic : DiagGroup<"ignored-pragma-intrinsic">;
 def UnknownPragmas : DiagGroup<"unknown-pragmas">;
-def IgnoredPragmas : DiagGroup<"ignored-pragmas">;
+def IgnoredPragmas : DiagGroup<"ignored-pragmas", [IgnoredPragmaIntrinsic]>;
 def Pragmas : DiagGroup<"pragmas", [UnknownPragmas, IgnoredPragmas]>;
 def UnknownWarningOption : DiagGroup<"unknown-warning-option">;
 def NSobjectAttribute : DiagGroup<"NSObject-attribute">;

Modified: cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td?rev=282108&r1=282107&r2=282108&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td Wed Sep 21 15:19:21 
2016
@@ -914,7 +914,7 @@ def warn_pragma_pack_malformed : Warning
 // - #pragma intrinsic
 def warn_pragma_intrinsic_builtin : Warning<
   "%0 is not a recognized builtin%select{|; consider including  to 
access non-builtin intrinsics}1">,
-  InGroup;
+  InGroup;
 // - #pragma unused
 def warn_pragma_unused_expected_var : Warning<
   "expected '#pragma unused' argument to be a variable name">,

Modified: cfe/trunk/test/Preprocessor/pragma_microsoft.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Preprocessor/pragma_microsoft.c?rev=282108&r1=282107&r2=282108&view=diff
==
--- cfe/trunk/test/Preprocessor/pragma_microsoft.c (original)
+++ cfe/trunk/test/Preprocessor/pragma_microsoft.c Wed Sep 21 15:19:21 2016
@@ -178,3 +178,15 @@ void g() {}
 #pragma intrinsic(memset) // no-warning
 #undef __INTRIN_H
 #pragma intrinsic(asdf) // expected-warning {{'asdf' is not a recognized 
builtin; consider including }}
+
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wignored-pragma-intrinsic"
+#pragma intrinsic(asdf) // no-warning
+#pragma clang diagnostic pop
+#pragma intrinsic(asdf) // expected-warning {{'asdf' is not a recognized 
builtin; consider including }}
+
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wignored-pragmas"
+#pragma intrinsic(asdf) // no-warning
+#pragma clang diagnostic pop
+#pragma intrinsic(asdf) // expected-warning {{'asdf' is not a recognized 
builtin; consider including }}


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


Re: [PATCH] D24775: Add -Wignored-pragma-intrinsic flag

2016-09-21 Thread Albert Gutowski via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL282108: Add -Wignored-pragma-intrinsic flag (authored by 
agutowski).

Changed prior to commit:
  https://reviews.llvm.org/D24775?vs=71960&id=72102#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D24775

Files:
  cfe/trunk/include/clang/Basic/DiagnosticGroups.td
  cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
  cfe/trunk/test/Preprocessor/pragma_microsoft.c

Index: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
===
--- cfe/trunk/include/clang/Basic/DiagnosticGroups.td
+++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td
@@ -439,8 +439,9 @@
 def UninitializedStaticSelfInit : DiagGroup<"static-self-init">;
 def Uninitialized  : DiagGroup<"uninitialized", [UninitializedSometimes,
  UninitializedStaticSelfInit]>;
+def IgnoredPragmaIntrinsic : DiagGroup<"ignored-pragma-intrinsic">;
 def UnknownPragmas : DiagGroup<"unknown-pragmas">;
-def IgnoredPragmas : DiagGroup<"ignored-pragmas">;
+def IgnoredPragmas : DiagGroup<"ignored-pragmas", [IgnoredPragmaIntrinsic]>;
 def Pragmas : DiagGroup<"pragmas", [UnknownPragmas, IgnoredPragmas]>;
 def UnknownWarningOption : DiagGroup<"unknown-warning-option">;
 def NSobjectAttribute : DiagGroup<"NSObject-attribute">;
Index: cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
===
--- cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
+++ cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
@@ -914,7 +914,7 @@
 // - #pragma intrinsic
 def warn_pragma_intrinsic_builtin : Warning<
   "%0 is not a recognized builtin%select{|; consider including  to 
access non-builtin intrinsics}1">,
-  InGroup;
+  InGroup;
 // - #pragma unused
 def warn_pragma_unused_expected_var : Warning<
   "expected '#pragma unused' argument to be a variable name">,
Index: cfe/trunk/test/Preprocessor/pragma_microsoft.c
===
--- cfe/trunk/test/Preprocessor/pragma_microsoft.c
+++ cfe/trunk/test/Preprocessor/pragma_microsoft.c
@@ -178,3 +178,15 @@
 #pragma intrinsic(memset) // no-warning
 #undef __INTRIN_H
 #pragma intrinsic(asdf) // expected-warning {{'asdf' is not a recognized 
builtin; consider including }}
+
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wignored-pragma-intrinsic"
+#pragma intrinsic(asdf) // no-warning
+#pragma clang diagnostic pop
+#pragma intrinsic(asdf) // expected-warning {{'asdf' is not a recognized 
builtin; consider including }}
+
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wignored-pragmas"
+#pragma intrinsic(asdf) // no-warning
+#pragma clang diagnostic pop
+#pragma intrinsic(asdf) // expected-warning {{'asdf' is not a recognized 
builtin; consider including }}


Index: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
===
--- cfe/trunk/include/clang/Basic/DiagnosticGroups.td
+++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td
@@ -439,8 +439,9 @@
 def UninitializedStaticSelfInit : DiagGroup<"static-self-init">;
 def Uninitialized  : DiagGroup<"uninitialized", [UninitializedSometimes,
  UninitializedStaticSelfInit]>;
+def IgnoredPragmaIntrinsic : DiagGroup<"ignored-pragma-intrinsic">;
 def UnknownPragmas : DiagGroup<"unknown-pragmas">;
-def IgnoredPragmas : DiagGroup<"ignored-pragmas">;
+def IgnoredPragmas : DiagGroup<"ignored-pragmas", [IgnoredPragmaIntrinsic]>;
 def Pragmas : DiagGroup<"pragmas", [UnknownPragmas, IgnoredPragmas]>;
 def UnknownWarningOption : DiagGroup<"unknown-warning-option">;
 def NSobjectAttribute : DiagGroup<"NSObject-attribute">;
Index: cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
===
--- cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
+++ cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
@@ -914,7 +914,7 @@
 // - #pragma intrinsic
 def warn_pragma_intrinsic_builtin : Warning<
   "%0 is not a recognized builtin%select{|; consider including  to access non-builtin intrinsics}1">,
-  InGroup;
+  InGroup;
 // - #pragma unused
 def warn_pragma_unused_expected_var : Warning<
   "expected '#pragma unused' argument to be a variable name">,
Index: cfe/trunk/test/Preprocessor/pragma_microsoft.c
===
--- cfe/trunk/test/Preprocessor/pragma_microsoft.c
+++ cfe/trunk/test/Preprocessor/pragma_microsoft.c
@@ -178,3 +178,15 @@
 #pragma intrinsic(memset) // no-warning
 #undef __INTRIN_H
 #pragma intrinsic(asdf) // expected-warning {{'asdf' is not a recognized builtin; consider including }}
+
+#pragma clang diagnostic push
+#pragma clang diagnostic ignored "-Wignored-pragma-intrinsic"
+#pragma intrinsic(asdf) // no-warning
+#pragma cla

Re: [PATCH] D24688: Introduce "hosted" module flag.

2016-09-21 Thread Tom Stellard via cfe-commits
tstellarAMD added a comment.

What does  "hosted mode" mean?


https://reviews.llvm.org/D24688



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


Re: [PATCH] D24775: Add -Wignored-pragma-intrinsic flag

2016-09-21 Thread Nico Weber via cfe-commits
On Tue, Sep 20, 2016 at 4:21 PM, Albert Gutowski 
wrote:

> OK, thanks for the note about referring to Chromium, I fixed that.
> As to -Wunknown-pragma, I feel that it would be inconsistent with other
> pragmas unless I moved whole pragma to lexer instead of parser - I've just
> discovered that I can do that, how should I decide if it's supposed to be
> here or there?
>

Your commit reminds me that I forgot to reply to this thread. For the
lexer/parser split, I think about it like this: If clang doesn't know about
a certain pragma at all, it can't do anything with it, so all it does is
emit 'unknown pragma', skip it, and move on. If it does know the pragma, it
can parse it -- but then it might have to ignore it for some reason, which
is why the parser prints that diagnostic.

So you're right that this doesn't fit in well in -Wunknown-pragma.

But -Wignored-pragma doesn't quite fit either imho, since we're not
ignoring the pragma, we're looking at its context.

Applying the same idea for pragmas to `#pragma intrinsic`, it feels to me
that we don't know some intrinsics at all, so they're more unknown than
ignored (as in -Wunkown-pragma-intrinsic, but in the sense of as "unknown
(pragma intrinsic)" not "(unknown pragma) intrinsic" -- but since this
shouldn't be in -Wunknown-pragma as you correctly say, that's not a good
name for this flag.)

So I think -Wmicrosoft-pragma-intrinsic might be a better fit. (But as I
said, it's bikeshedding, and up to you.)


>
> On Tue, Sep 20, 2016 at 12:30 PM, Nico Weber  wrote:
>
>> Thanks! Some bikesheddy comments, ignore as you see fit:
>>
>> - I think it's good to keep Chromium's bug tracker out of LLVM as far as
>> possible (most LLVM devs don't need to care about Chromium, and since
>> Chromium's bug tracker refers to LLVM's bug tracker frequently since
>> chromium depends on llvm, adding links the other way round adds a
>> dependency cycle of sorts), so maybe describe the motivation in your own
>> words instead of linking ("People might want to receive warnings about
>> pragmas but not about intrinsics we don't yet implement")
>>
>> - Should this be part of -Wunknown-pragma instead of -Wignored-pragma?
>> (Or maybe even in -Wmicrosoft somewhere?) That seems to fit a tiny bit
>> better imho (but as I said, feel free to disagree and ignore)
>>
>> On Tue, Sep 20, 2016 at 2:38 PM, Albert Gutowski 
>> wrote:
>>
>>> agutowski created this revision.
>>> agutowski added reviewers: thakis, hans.
>>> agutowski added a subscriber: cfe-commits.
>>>
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=644841#c9
>>>
>>> https://reviews.llvm.org/D24775
>>>
>>> Files:
>>>   include/clang/Basic/DiagnosticGroups.td
>>>   include/clang/Basic/DiagnosticParseKinds.td
>>>   test/Preprocessor/pragma_microsoft.c
>>>
>>> Index: include/clang/Basic/DiagnosticParseKinds.td
>>> ===
>>> --- include/clang/Basic/DiagnosticParseKinds.td
>>> +++ include/clang/Basic/DiagnosticParseKinds.td
>>> @@ -914,7 +914,7 @@
>>>  // - #pragma intrinsic
>>>  def warn_pragma_intrinsic_builtin : Warning<
>>>"%0 is not a recognized builtin%select{|; consider including
>>>  to access non-builtin intrinsics}1">,
>>> -  InGroup;
>>> +  InGroup;
>>>  // - #pragma unused
>>>  def warn_pragma_unused_expected_var : Warning<
>>>"expected '#pragma unused' argument to be a variable name">,
>>> Index: include/clang/Basic/DiagnosticGroups.td
>>> ===
>>> --- include/clang/Basic/DiagnosticGroups.td
>>> +++ include/clang/Basic/DiagnosticGroups.td
>>> @@ -439,8 +439,9 @@
>>>  def UninitializedStaticSelfInit : DiagGroup<"static-self-init">;
>>>  def Uninitialized  : DiagGroup<"uninitialized", [UninitializedSometimes,
>>>
>>> UninitializedStaticSelfInit]>;
>>> +def IgnoredPragmaIntrinsic : DiagGroup<"ignored-pragma-intrinsic">;
>>>  def UnknownPragmas : DiagGroup<"unknown-pragmas">;
>>> -def IgnoredPragmas : DiagGroup<"ignored-pragmas">;
>>> +def IgnoredPragmas : DiagGroup<"ignored-pragmas",
>>> [IgnoredPragmaIntrinsic]>;
>>>  def Pragmas : DiagGroup<"pragmas", [UnknownPragmas, IgnoredPragmas]>;
>>>  def UnknownWarningOption : DiagGroup<"unknown-warning-option">;
>>>  def NSobjectAttribute : DiagGroup<"NSObject-attribute">;
>>> Index: test/Preprocessor/pragma_microsoft.c
>>> ===
>>> --- test/Preprocessor/pragma_microsoft.c
>>> +++ test/Preprocessor/pragma_microsoft.c
>>> @@ -178,3 +178,15 @@
>>>  #pragma intrinsic(memset) // no-warning
>>>  #undef __INTRIN_H
>>>  #pragma intrinsic(asdf) // expected-warning {{'asdf' is not a
>>> recognized builtin; consider including }}
>>> +
>>> +#pragma clang diagnostic push
>>> +#pragma clang diagnostic ignored "-Wignored-pragma-intrinsic"
>>> +#pragma intrinsic(asdf) // no-warning
>>> +#pragma clang diagnostic pop
>>> +#pragma intrinsic(asdf) // expected-warning {{'asdf' is not a
>>> recognized buil

Re: [PATCH] D24688: Introduce "hosted" module flag.

2016-09-21 Thread Peter Collingbourne via cfe-commits
pcc added a comment.

The word "hosted" takes its meaning from the C/C++ standards. It refers to a 
build environment where the standard library is guaranteed to be available.

Note that we've been rethinking this approach on the mailing list, see 
http://lists.llvm.org/pipermail/llvm-dev/2016-September/105035.html


https://reviews.llvm.org/D24688



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


Re: [PATCH] D24792: [analyzer] Fix crash in RetainCountChecker::checkEndFunction

2016-09-21 Thread Anna Zaks via cfe-commits
zaks.anna added a comment.

Can you give a bit more context? Do you see the crash on a redefinition of the 
OSAtomicCompareAndSwapPtr or one of the other standard functions or do you have 
another similarly named function that should not be modeled?


Repository:
  rL LLVM

https://reviews.llvm.org/D24792



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


Re: [PATCH] D24775: Add -Wignored-pragma-intrinsic flag

2016-09-21 Thread Albert Gutowski via cfe-commits
Thanks for clarification!
You are right that it doesn't really fit in -Wignored-pragma, but I
also don't like the idea of getting warning about ignored "#pragma
intrinsic" after setting -Wno-ignored-pragma, so I think I'll leave it
as it is.

On Wed, Sep 21, 2016 at 1:35 PM, Nico Weber  wrote:
> On Tue, Sep 20, 2016 at 4:21 PM, Albert Gutowski 
> wrote:
>>
>> OK, thanks for the note about referring to Chromium, I fixed that.
>> As to -Wunknown-pragma, I feel that it would be inconsistent with other
>> pragmas unless I moved whole pragma to lexer instead of parser - I've just
>> discovered that I can do that, how should I decide if it's supposed to be
>> here or there?
>
>
> Your commit reminds me that I forgot to reply to this thread. For the
> lexer/parser split, I think about it like this: If clang doesn't know about
> a certain pragma at all, it can't do anything with it, so all it does is
> emit 'unknown pragma', skip it, and move on. If it does know the pragma, it
> can parse it -- but then it might have to ignore it for some reason, which
> is why the parser prints that diagnostic.
>
> So you're right that this doesn't fit in well in -Wunknown-pragma.
>
> But -Wignored-pragma doesn't quite fit either imho, since we're not ignoring
> the pragma, we're looking at its context.
>
> Applying the same idea for pragmas to `#pragma intrinsic`, it feels to me
> that we don't know some intrinsics at all, so they're more unknown than
> ignored (as in -Wunkown-pragma-intrinsic, but in the sense of as "unknown
> (pragma intrinsic)" not "(unknown pragma) intrinsic" -- but since this
> shouldn't be in -Wunknown-pragma as you correctly say, that's not a good
> name for this flag.)
>
> So I think -Wmicrosoft-pragma-intrinsic might be a better fit. (But as I
> said, it's bikeshedding, and up to you.)
>
>>
>>
>> On Tue, Sep 20, 2016 at 12:30 PM, Nico Weber  wrote:
>>>
>>> Thanks! Some bikesheddy comments, ignore as you see fit:
>>>
>>> - I think it's good to keep Chromium's bug tracker out of LLVM as far as
>>> possible (most LLVM devs don't need to care about Chromium, and since
>>> Chromium's bug tracker refers to LLVM's bug tracker frequently since
>>> chromium depends on llvm, adding links the other way round adds a dependency
>>> cycle of sorts), so maybe describe the motivation in your own words instead
>>> of linking ("People might want to receive warnings about pragmas but not
>>> about intrinsics we don't yet implement")
>>>
>>> - Should this be part of -Wunknown-pragma instead of -Wignored-pragma?
>>> (Or maybe even in -Wmicrosoft somewhere?) That seems to fit a tiny bit
>>> better imho (but as I said, feel free to disagree and ignore)
>>>
>>> On Tue, Sep 20, 2016 at 2:38 PM, Albert Gutowski 
>>> wrote:

 agutowski created this revision.
 agutowski added reviewers: thakis, hans.
 agutowski added a subscriber: cfe-commits.

 https://bugs.chromium.org/p/chromium/issues/detail?id=644841#c9

 https://reviews.llvm.org/D24775

 Files:
   include/clang/Basic/DiagnosticGroups.td
   include/clang/Basic/DiagnosticParseKinds.td
   test/Preprocessor/pragma_microsoft.c

 Index: include/clang/Basic/DiagnosticParseKinds.td
 ===
 --- include/clang/Basic/DiagnosticParseKinds.td
 +++ include/clang/Basic/DiagnosticParseKinds.td
 @@ -914,7 +914,7 @@
  // - #pragma intrinsic
  def warn_pragma_intrinsic_builtin : Warning<
"%0 is not a recognized builtin%select{|; consider including
  to access non-builtin intrinsics}1">,
 -  InGroup;
 +  InGroup;
  // - #pragma unused
  def warn_pragma_unused_expected_var : Warning<
"expected '#pragma unused' argument to be a variable name">,
 Index: include/clang/Basic/DiagnosticGroups.td
 ===
 --- include/clang/Basic/DiagnosticGroups.td
 +++ include/clang/Basic/DiagnosticGroups.td
 @@ -439,8 +439,9 @@
  def UninitializedStaticSelfInit : DiagGroup<"static-self-init">;
  def Uninitialized  : DiagGroup<"uninitialized",
 [UninitializedSometimes,

 UninitializedStaticSelfInit]>;
 +def IgnoredPragmaIntrinsic : DiagGroup<"ignored-pragma-intrinsic">;
  def UnknownPragmas : DiagGroup<"unknown-pragmas">;
 -def IgnoredPragmas : DiagGroup<"ignored-pragmas">;
 +def IgnoredPragmas : DiagGroup<"ignored-pragmas",
 [IgnoredPragmaIntrinsic]>;
  def Pragmas : DiagGroup<"pragmas", [UnknownPragmas, IgnoredPragmas]>;
  def UnknownWarningOption : DiagGroup<"unknown-warning-option">;
  def NSobjectAttribute : DiagGroup<"NSObject-attribute">;
 Index: test/Preprocessor/pragma_microsoft.c
 ===
 --- test/Preprocessor/pragma_microsoft.c
 +++ test/Preprocessor/pragma_microsoft.c
 @@ -178,3 +178,15 @@
  #pragma intrinsic(mems

r282109 - [CMake] Pass CLANG_VERSION_* variables into later stages

2016-09-21 Thread Chris Bieneman via cfe-commits
Author: cbieneman
Date: Wed Sep 21 15:43:43 2016
New Revision: 282109

URL: http://llvm.org/viewvc/llvm-project?rev=282109&view=rev
Log:
[CMake] Pass CLANG_VERSION_* variables into later stages

When supporting overriding clang versions we also need to pass those through to 
the next stage so they remain overridden.

Modified:
cfe/trunk/CMakeLists.txt

Modified: cfe/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/CMakeLists.txt?rev=282109&r1=282108&r2=282109&view=diff
==
--- cfe/trunk/CMakeLists.txt (original)
+++ cfe/trunk/CMakeLists.txt Wed Sep 21 15:43:43 2016
@@ -549,6 +549,9 @@ if (CLANG_ENABLE_BOOTSTRAP)
 LLVM_VERSION_MAJOR
 LLVM_VERSION_MINOR
 LLVM_VERSION_PATCH
+CLANG_VERSION_MAJOR
+CLANG_VERSION_MINOR
+CLANG_VERSION_PATCHLEVEL
 LLVM_VERSION_SUFFIX
 LLVM_BINUTILS_INCDIR
 CLANG_REPOSITORY_STRING


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


Re: [PATCH] D24792: [analyzer] Fix crash in RetainCountChecker::checkEndFunction

2016-09-21 Thread Alexander Shaposhnikov via cfe-commits
alexshap added a comment.

@zaks.anna: it happens on one of the ports of libdispatch, but probably i also 
can reproduce this crash with OSAtomicCompareAndSwap.


Repository:
  rL LLVM

https://reviews.llvm.org/D24792



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


Re: [PATCH] D24481: make “#pragma STDC FP_CONTRACT” on by default

2016-09-21 Thread Abe Skolnik via cfe-commits
Abe updated this revision to Diff 72103.
Abe added a comment.

Combined "fp-contract-pragma___on-by-default___-O0___aarch64-backend.c" and 
"fp-contract-pragma___on-by-default___-O1...3___aarch64-backend.c" into a 
single file ["fp-contract-pragma___on-by-default.c"].


https://reviews.llvm.org/D24481

Files:
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/aarch64-neon-fma.c
  clang/test/CodeGen/aarch64-scalar-fma.c
  clang/test/CodeGen/fp-contract-pragma.cpp
  clang/test/CodeGen/fp-contract-pragma___on-by-default.c
  clang/test/Driver/clang_f_opts.c

Index: clang/test/Driver/clang_f_opts.c
===
--- clang/test/Driver/clang_f_opts.c
+++ clang/test/Driver/clang_f_opts.c
@@ -34,10 +34,13 @@
 // DEPRECATED-OFF-CHECK-NOT: -fdeprecated-macro
 
 // RUN: %clang -### -S -ffp-contract=fast %s 2>&1 | FileCheck -check-prefix=FP-CONTRACT-FAST-CHECK %s
-// RUN: %clang -### -S -ffast-math %s 2>&1 | FileCheck -check-prefix=FP-CONTRACT-FAST-CHECK %s
-// RUN: %clang -### -S -ffp-contract=off %s 2>&1 | FileCheck -check-prefix=FP-CONTRACT-OFF-CHECK %s
+// RUN: %clang -### -S -ffast-math%s 2>&1 | FileCheck -check-prefix=FP-CONTRACT-FAST-CHECK %s
+// RUN: %clang -### -S -ffp-contract=off  %s 2>&1 | FileCheck -check-prefix=FP-CONTRACT-OFF-CHECK  %s
+// RUN: %clang -### -S -ffp-contract=on   %s 2>&1 | FileCheck -check-prefix=FP-CONTRACT-ON-CHECK   %s
+
 // FP-CONTRACT-FAST-CHECK: -ffp-contract=fast
-// FP-CONTRACT-OFF-CHECK: -ffp-contract=off
+// FP-CONTRACT-OFF-CHECK:  -ffp-contract=off
+// FP-CONTRACT-ON-CHECK:   -ffp-contract=on
 
 // RUN: %clang -### -S -funroll-loops %s 2>&1 | FileCheck -check-prefix=CHECK-UNROLL-LOOPS %s
 // RUN: %clang -### -S -fno-unroll-loops %s 2>&1 | FileCheck -check-prefix=CHECK-NO-UNROLL-LOOPS %s
Index: clang/test/CodeGen/fp-contract-pragma___on-by-default.c
===
--- /dev/null
+++ clang/test/CodeGen/fp-contract-pragma___on-by-default.c
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 -triple aarch64 -O0 -S -o - %s | FileCheck %s --check-prefix   ALL_BUILDS
+// RUN: %clang_cc1 -triple aarch64 -O1 -S -o - %s | FileCheck %s --check-prefixes ALL_BUILDS,NON_O0
+// RUN: %clang_cc1 -triple aarch64 -O2 -S -o - %s | FileCheck %s --check-prefixes ALL_BUILDS,NON_O0
+// RUN: %clang_cc1 -triple aarch64 -O3 -S -o - %s | FileCheck %s --check-prefixes ALL_BUILDS,NON_O0
+
+// REQUIRES: aarch64-registered-target
+
+// ALL_BUILDS-LABEL: fmadd_double:
+// ALL_BUILDS: fmadd d0, d{{[0-7]}}, d{{[0-7]}}, d{{[0-7]}}
+// NON_O0-NEXT: ret
+double fmadd_double(double a, double b, double c) {
+  return a*b+c;
+}
+
+// ALL_BUILDS: fmadd_single:
+// ALL_BUILDS: fmadd s0, s{{[0-7]}}, s{{[0-7]}}, s{{[0-7]}}
+// NON_O0-NEXT: ret
+float  fmadd_single(float  a, float  b, float  c) {
+  return a*b+c;
+}
+
Index: clang/test/CodeGen/fp-contract-pragma.cpp
===
--- clang/test/CodeGen/fp-contract-pragma.cpp
+++ clang/test/CodeGen/fp-contract-pragma.cpp
@@ -1,27 +1,25 @@
 // RUN: %clang_cc1 -O3 -triple %itanium_abi_triple -emit-llvm -o - %s | FileCheck %s
 
-// Is FP_CONTRACT honored in a simple case?
-float fp_contract_1(float a, float b, float c) {
-// CHECK: _Z13fp_contract_1fff
+// Is FP_CONTRACT on by default, at least at -O3?
+float fp_contract_8(float a, float b, float c) {
+// CHECK: _Z13fp_contract_8fff
 // CHECK: tail call float @llvm.fmuladd
-  #pragma STDC FP_CONTRACT ON
   return a * b + c;
 }
 
 // Is FP_CONTRACT state cleared on exiting compound statements?
 float fp_contract_2(float a, float b, float c) {
 // CHECK: _Z13fp_contract_2fff
 // CHECK: %[[M:.+]] = fmul float %a, %b
 // CHECK-NEXT: fadd float %[[M]], %c
+  #pragma STDC FP_CONTRACT OFF
   {
 #pragma STDC FP_CONTRACT ON
   }
   return a * b + c;  
 }
 
 // Does FP_CONTRACT survive template instantiation?
-class Foo {};
-Foo operator+(Foo, Foo);
 
 template 
 T template_muladd(T a, T b, T c) {
@@ -62,15 +60,23 @@
   return a * b + c;
 }
 
+// Does FP_CONTRACT inside a function override the same in the file scope?
+float fp_contract_1(float a, float b, float c) {
+// CHECK: _Z13fp_contract_1fff
+// CHECK: tail call float @llvm.fmuladd
+  #pragma STDC FP_CONTRACT ON
+  return a * b + c;
+}
+
+
 // If the multiply has multiple uses, don't produce fmuladd.
 // This used to assert (PR25719):
 // https://llvm.org/bugs/show_bug.cgi?id=25719
 
-float fp_contract_7(float a, float b, float c) {
+float fp_contract_7(float a, float b, float c, float& d_passed_by_ref) {
 // CHECK: _Z13fp_contract_7fff
 // CHECK:  %[[M:.+]] = fmul float %b, 2.00e+00
-// CHECK-NEXT: fsub float %[[M]], %c
   #pragma STDC FP_CONTRACT ON
-  return (a = 2 * b) - c;
+  return (d_passed_by_ref = 2 * b) - c;
 }
 
Index: clang/test/CodeGen/aarch64-scalar-fma.c
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-scalar-fma.c
@@ -0,0 +1,177 @@

Re: [PATCH] D24481: make “#pragma STDC FP_CONTRACT” on by default

2016-09-21 Thread Yaxun Liu via cfe-commits
yaxunl added inline comments.


Comment at: clang/lib/Frontend/CompilerInvocation.cpp:2441
@@ +2440,3 @@
+
+  if ((LangOpts.C11 || LangOpts.C99 || LangOpts.CPlusPlus)
+   && ( CodeGenOptions::FPC_On == Res.getCodeGenOpts().getFPContractMode() 
)

The format of this line looks strange. Did you check with clang-format-diff.py 
if it is OK?


https://reviews.llvm.org/D24481



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


Re: [PATCH] D24319: clang-format: Add an option to git-clang-format to diff between to commits

2016-09-21 Thread Mark Lodato via cfe-commits
lodato accepted this revision.
lodato added a reviewer: lodato.
lodato added a comment.
This revision is now accepted and ready to land.

Nice feature. Thanks for the patch!


https://reviews.llvm.org/D24319



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


Re: [PATCH] D24792: [analyzer] Fix crash in RetainCountChecker::checkEndFunction

2016-09-21 Thread Anna Zaks via cfe-commits
zaks.anna added a comment.

One approach would be to skip analyzing the functions which we model as top 
level.

- a/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp

+++ b/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
@@ -688,6 +688,9 @@ void AnalysisConsumer::ActionExprEngine(Decl *D, bool 
ObjCGCEnabled,

  if (!Mgr->getAnalysisDeclContext(D)->getAnalysis())
return;
   

+  if (Mgr->getAnalysisDeclContext(D)->isBodyAutosynthesized())
+return;
+

  ExprEngine Eng(*Mgr, ObjCGCEnabled, VisitedCallees, &FunctionSummaries,IMode);

The main downside is that we will not be analyzing the bodies of functions that 
are being modeled at all, so we won't find bugs in them. On the other hand, 
those definitions should be coming from system headers anyway.

Another approach is along the lines of changing the 
AnalysisDeclContext::getBody() so that it does not choose model over a real 
body depending on context. It might be less clean and maintainable.


Repository:
  rL LLVM

https://reviews.llvm.org/D24792



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


[PATCH] D24815: [clang] make reciprocal estimate codegen a function attribute

2016-09-21 Thread Sanjay Patel via cfe-commits
spatel created this revision.
spatel added reviewers: echristo, evandro, hfinkel.
spatel added a subscriber: cfe-commits.
Herald added subscribers: mehdi_amini, mcrosier.

Technically, I suppose this patch is independent of the upcoming llvm sibling 
patch because we can still pass 'check-all' with this alone. But this patch 
should be tightly coupled with that patch when committed because there's 
nothing currently in llvm to read this new function attribute string.

The motivation for the change is that we can't have pseudo-global settings for 
codegen living in TargetOptions because that doesn't work with LTO. And yet, 
there are so many others there...

Ideally, these reciprocal attributes will be moved to the instruction-level via 
FMF, metadata, or something else. But making them function attributes is at 
least an improvement over the current mess.

https://reviews.llvm.org/D24815

Files:
  lib/CodeGen/BackendUtil.cpp
  lib/CodeGen/CGCall.cpp
  test/CodeGen/attr-mrecip.c

Index: test/CodeGen/attr-mrecip.c
===
--- test/CodeGen/attr-mrecip.c
+++ test/CodeGen/attr-mrecip.c
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -mrecip=!sqrtf,vec-divf:3 -disable-llvm-optzns -emit-llvm 
%s -o - | FileCheck %s
+
+int baz(int a) { return 4; }
+
+// CHECK: baz{{.*}} #0
+// CHECK: #0 = {{.*}}"mrecip"="!sqrtf,vec-divf:3"
+
Index: lib/CodeGen/CGCall.cpp
===
--- lib/CodeGen/CGCall.cpp
+++ lib/CodeGen/CGCall.cpp
@@ -1730,6 +1730,9 @@
 
 FuncAttrs.addAttribute("no-trapping-math",
llvm::toStringRef(CodeGenOpts.NoTrappingMath));
+
+// TODO: Are these all needed?
+// unsafe/inf/nan/nsz are handled by instruction-level FastMathFlags.
 FuncAttrs.addAttribute("no-infs-fp-math",
llvm::toStringRef(CodeGenOpts.NoInfsFPMath));
 FuncAttrs.addAttribute("no-nans-fp-math",
@@ -1746,6 +1749,12 @@
 "correctly-rounded-divide-sqrt-fp-math",
 llvm::toStringRef(CodeGenOpts.CorrectlyRoundedDivSqrt));
 
+// TODO: Reciprocal estimate codegen options should apply to instructions?
+std::vector &Recips = getTarget().getTargetOpts().Reciprocals;
+if (!Recips.empty())
+  FuncAttrs.addAttribute("mrecip",
+ llvm::join(Recips.begin(), Recips.end(), ","));
+
 if (CodeGenOpts.StackRealignment)
   FuncAttrs.addAttribute("stackrealign");
 if (CodeGenOpts.Backchain)
Index: lib/CodeGen/BackendUtil.cpp
===
--- lib/CodeGen/BackendUtil.cpp
+++ lib/CodeGen/BackendUtil.cpp
@@ -529,9 +529,6 @@
 
   llvm::TargetOptions Options;
 
-  if (!TargetOpts.Reciprocals.empty())
-Options.Reciprocals = TargetRecip(TargetOpts.Reciprocals);
-
   Options.ThreadModel =
 llvm::StringSwitch(CodeGenOpts.ThreadModel)
   .Case("posix", llvm::ThreadModel::POSIX)


Index: test/CodeGen/attr-mrecip.c
===
--- test/CodeGen/attr-mrecip.c
+++ test/CodeGen/attr-mrecip.c
@@ -0,0 +1,7 @@
+// RUN: %clang_cc1 -mrecip=!sqrtf,vec-divf:3 -disable-llvm-optzns -emit-llvm %s -o - | FileCheck %s
+
+int baz(int a) { return 4; }
+
+// CHECK: baz{{.*}} #0
+// CHECK: #0 = {{.*}}"mrecip"="!sqrtf,vec-divf:3"
+
Index: lib/CodeGen/CGCall.cpp
===
--- lib/CodeGen/CGCall.cpp
+++ lib/CodeGen/CGCall.cpp
@@ -1730,6 +1730,9 @@
 
 FuncAttrs.addAttribute("no-trapping-math",
llvm::toStringRef(CodeGenOpts.NoTrappingMath));
+
+// TODO: Are these all needed?
+// unsafe/inf/nan/nsz are handled by instruction-level FastMathFlags.
 FuncAttrs.addAttribute("no-infs-fp-math",
llvm::toStringRef(CodeGenOpts.NoInfsFPMath));
 FuncAttrs.addAttribute("no-nans-fp-math",
@@ -1746,6 +1749,12 @@
 "correctly-rounded-divide-sqrt-fp-math",
 llvm::toStringRef(CodeGenOpts.CorrectlyRoundedDivSqrt));
 
+// TODO: Reciprocal estimate codegen options should apply to instructions?
+std::vector &Recips = getTarget().getTargetOpts().Reciprocals;
+if (!Recips.empty())
+  FuncAttrs.addAttribute("mrecip",
+ llvm::join(Recips.begin(), Recips.end(), ","));
+
 if (CodeGenOpts.StackRealignment)
   FuncAttrs.addAttribute("stackrealign");
 if (CodeGenOpts.Backchain)
Index: lib/CodeGen/BackendUtil.cpp
===
--- lib/CodeGen/BackendUtil.cpp
+++ lib/CodeGen/BackendUtil.cpp
@@ -529,9 +529,6 @@
 
   llvm::TargetOptions Options;
 
-  if (!TargetOpts.Reciprocals.empty())
-Options.Reciprocals = TargetRecip(TargetOpts.Reciprocals);
-
   Options.ThreadModel =
 llvm::StringSwitch(CodeGenOpts.ThreadModel)
   .Case("posix", llvm::ThreadModel::POSIX)
___

Re: [PATCH] D24693: [CodeGen] Don't emit lifetime intrinsics for some local variables

2016-09-21 Thread Akira Hatanaka via cfe-commits
ahatanak added a comment.

In https://reviews.llvm.org/D24693#549095, @majnemer wrote:

> This doesn't sound right.  Given the example in the description, we are 
> accessing the memory location after end has been called: this seems like a 
> real miscompile.  It would appear unsafe to only do this for asan.


My impression was that this wasn't a miscompile, but I'm not so sure now. Do 
you have a concrete example where any of the optimization passes miscompile the 
code like that shown in PR28267 because of missing or misplaced lifetime 
intrinsics? I spent some time looking at how StackColoring (which is the 
primary user of this intrinsic) transforms the code in PR28267, and it didn't 
look like this would cause any miscompile (it seemed like it was able to 
compute the lifetime interval for %tmp correctly). I'm not sure whether other 
optimization passes are handling it correctly though.


https://reviews.llvm.org/D24693



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


Re: [PATCH] D18172: [CUDA][OpenMP] Add a generic offload action builder

2016-09-21 Thread Samuel Antao via cfe-commits
sfantao updated this revision to Diff 72117.
sfantao added a comment.

- Rebase.


https://reviews.llvm.org/D18172

Files:
  include/clang/Driver/Compilation.h
  lib/Driver/Driver.cpp
  lib/Driver/Types.cpp
  test/Driver/cuda-bindings.cu
  test/Driver/cuda-phases.cu

Index: test/Driver/cuda-phases.cu
===
--- test/Driver/cuda-phases.cu
+++ test/Driver/cuda-phases.cu
@@ -13,194 +13,189 @@
 //
 // RUN: %clang -target powerpc64le-ibm-linux-gnu -ccc-print-phases --cuda-gpu-arch=sm_30 %s 2>&1 \
 // RUN: | FileCheck -check-prefix=BIN %s
-// BIN: 0: input, "{{.*}}cuda-phases.cu", cuda, (host-cuda)
-// BIN: 1: preprocessor, {0}, cuda-cpp-output, (host-cuda)
-// BIN: 2: compiler, {1}, ir, (host-cuda)
-// BIN: 3: input, "{{.*}}cuda-phases.cu", cuda, (device-cuda, sm_30)
-// BIN: 4: preprocessor, {3}, cuda-cpp-output, (device-cuda, sm_30)
-// BIN: 5: compiler, {4}, ir, (device-cuda, sm_30)
-// BIN: 6: backend, {5}, assembler, (device-cuda, sm_30)
-// BIN: 7: assembler, {6}, object, (device-cuda, sm_30)
-// BIN: 8: offload, "device-cuda (nvptx64-nvidia-cuda:sm_30)" {7}, object
-// BIN: 9: offload, "device-cuda (nvptx64-nvidia-cuda:sm_30)" {6}, assembler
-// BIN: 10: linker, {8, 9}, cuda-fatbin, (device-cuda)
-// BIN: 11: offload, "host-cuda (powerpc64le-ibm-linux-gnu)" {2}, "device-cuda (nvptx64-nvidia-cuda)" {10}, ir
-// BIN: 12: backend, {11}, assembler, (host-cuda)
-// BIN: 13: assembler, {12}, object, (host-cuda)
-// BIN: 14: linker, {13}, image, (host-cuda)
+// BIN-DAG: [[P0:[0-9]+]]: input, "{{.*}}cuda-phases.cu", cuda, (host-cuda)
+// BIN-DAG: [[P1:[0-9]+]]: preprocessor, {[[P0]]}, cuda-cpp-output, (host-cuda)
+// BIN-DAG: [[P2:[0-9]+]]: compiler, {[[P1]]}, ir, (host-cuda)
+// BIN-DAG: [[P3:[0-9]+]]: input, "{{.*}}cuda-phases.cu", cuda, (device-cuda, sm_30)
+// BIN-DAG: [[P4:[0-9]+]]: preprocessor, {[[P3]]}, cuda-cpp-output, (device-cuda, sm_30)
+// BIN-DAG: [[P5:[0-9]+]]: compiler, {[[P4]]}, ir, (device-cuda, sm_30)
+// BIN-DAG: [[P6:[0-9]+]]: backend, {[[P5]]}, assembler, (device-cuda, sm_30)
+// BIN-DAG: [[P7:[0-9]+]]: assembler, {[[P6]]}, object, (device-cuda, sm_30)
+// BIN-DAG: [[P8:[0-9]+]]: offload, "device-cuda (nvptx64-nvidia-cuda:sm_30)" {[[P7]]}, object
+// BIN-DAG: [[P9:[0-9]+]]: offload, "device-cuda (nvptx64-nvidia-cuda:sm_30)" {[[P6]]}, assembler
+// BIN-DAG: [[P10:[0-9]+]]: linker, {[[P8]], [[P9]]}, cuda-fatbin, (device-cuda)
+// BIN-DAG: [[P11:[0-9]+]]: offload, "host-cuda (powerpc64le-ibm-linux-gnu)" {[[P2]]}, "device-cuda (nvptx64-nvidia-cuda)" {[[P10]]}, ir
+// BIN-DAG: [[P12:[0-9]+]]: backend, {[[P11]]}, assembler, (host-cuda)
+// BIN-DAG: [[P13:[0-9]+]]: assembler, {[[P12]]}, object, (host-cuda)
+// BIN-DAG: [[P14:[0-9]+]]: linker, {[[P13]]}, image, (host-cuda)
 
 //
 // Test single gpu architecture up to the assemble phase.
 //
 // RUN: %clang -target powerpc64le-ibm-linux-gnu -ccc-print-phases --cuda-gpu-arch=sm_30 %s -S 2>&1 \
 // RUN: | FileCheck -check-prefix=ASM %s
-// ASM: 0: input, "{{.*}}cuda-phases.cu", cuda, (device-cuda, sm_30)
-// ASM: 1: preprocessor, {0}, cuda-cpp-output, (device-cuda, sm_30)
-// ASM: 2: compiler, {1}, ir, (device-cuda, sm_30)
-// ASM: 3: backend, {2}, assembler, (device-cuda, sm_30)
-// ASM: 4: offload, "device-cuda (nvptx64-nvidia-cuda:sm_30)" {3}, assembler
-// ASM: 5: input, "{{.*}}cuda-phases.cu", cuda, (host-cuda)
-// ASM: 6: preprocessor, {5}, cuda-cpp-output, (host-cuda)
-// ASM: 7: compiler, {6}, ir, (host-cuda)
-// ASM: 8: backend, {7}, assembler, (host-cuda)
+// ASM-DAG: [[P0:[0-9]+]]: input, "{{.*}}cuda-phases.cu", cuda, (device-cuda, sm_30)
+// ASM-DAG: [[P1:[0-9]+]]: preprocessor, {[[P0]]}, cuda-cpp-output, (device-cuda, sm_30)
+// ASM-DAG: [[P2:[0-9]+]]: compiler, {[[P1]]}, ir, (device-cuda, sm_30)
+// ASM-DAG: [[P3:[0-9]+]]: backend, {[[P2]]}, assembler, (device-cuda, sm_30)
+// ASM-DAG: [[P4:[0-9]+]]: offload, "device-cuda (nvptx64-nvidia-cuda:sm_30)" {[[P3]]}, assembler
+// ASM-DAG: [[P5:[0-9]+]]: input, "{{.*}}cuda-phases.cu", cuda, (host-cuda)
+// ASM-DAG: [[P6:[0-9]+]]: preprocessor, {[[P5]]}, cuda-cpp-output, (host-cuda)
+// ASM-DAG: [[P7:[0-9]+]]: compiler, {[[P6]]}, ir, (host-cuda)
+// ASM-DAG: [[P8:[0-9]+]]: backend, {[[P7]]}, assembler, (host-cuda)
 
 //
 // Test two gpu architectures with complete compilation.
 //
 // RUN: %clang -target powerpc64le-ibm-linux-gnu -ccc-print-phases --cuda-gpu-arch=sm_30 --cuda-gpu-arch=sm_35 %s 2>&1 \
 // RUN: | FileCheck -check-prefix=BIN2 %s
-// BIN2: 0: input, "{{.*}}cuda-phases.cu", cuda, (host-cuda)
-// BIN2: 1: preprocessor, {0}, cuda-cpp-output, (host-cuda)
-// BIN2: 2: compiler, {1}, ir, (host-cuda)
-// BIN2: 3: input, "{{.*}}cuda-phases.cu", cuda, (device-cuda, sm_30)
-// BIN2: 4: preprocessor, {3}, cuda-cpp-output, (device-cuda, sm_30)
-// BIN2: 5: compiler, {4}, ir, (device-cuda, sm_30)
-// BIN2: 6: backend, {5}, assembler, (device-cuda, sm_30)
-// BIN2: 7: assembler, {6}, object, (device-cuda, sm_30)
-// BIN2: 8: offload, "d

Re: [PATCH] D21840: [Driver][CUDA][OpenMP] Reimplement tool selection in the driver.

2016-09-21 Thread Samuel Antao via cfe-commits
sfantao updated this revision to Diff 72118.
sfantao added a comment.

- Rebase.


https://reviews.llvm.org/D21840

Files:
  include/clang/Driver/Action.h
  lib/Driver/Driver.cpp

Index: lib/Driver/Driver.cpp
===
--- lib/Driver/Driver.cpp
+++ lib/Driver/Driver.cpp
@@ -1922,7 +1922,7 @@
 
 // Create the offload action with all dependences. When an offload action
 // is created the kinds are propagated to the host action, so we don't have
-// to do that explicitely here.
+// to do that explicitly here.
 OffloadAction::HostDependence HDep(
 *HostAction, *C.getSingleOffloadToolChain(),
 /*BoundArch*/ nullptr, ActiveOffloadKinds);
@@ -2360,142 +2360,293 @@
 }
   }
 }
-/// Collapse an offloading action looking for a job of the given type. The input
-/// action is changed to the input of the collapsed sequence. If we effectively
-/// had a collapse return the corresponding offloading action, otherwise return
-/// null.
-template 
-static OffloadAction *collapseOffloadingAction(Action *&CurAction) {
-  if (!CurAction)
-return nullptr;
-  if (auto *OA = dyn_cast(CurAction)) {
-if (OA->hasHostDependence())
-  if (auto *HDep = dyn_cast(OA->getHostDependence())) {
-CurAction = HDep;
-return OA;
-  }
-if (OA->hasSingleDeviceDependence())
-  if (auto *DDep = dyn_cast(OA->getSingleDeviceDependence())) {
-CurAction = DDep;
-return OA;
+
+namespace {
+/// Utility class to control the collapse of dependent actions and select the
+/// tools accordingly.
+class ToolSelector final {
+  /// The tool chain this selector refers to.
+  const ToolChain &TC;
+
+  /// The compilation this selector refers to.
+  const Compilation &C;
+
+  /// The base action this selector refers to.
+  const JobAction *BaseAction;
+
+  /// Set to true if the current toolchain refers to host actions.
+  bool IsHostSelector;
+
+  /// Set to true if save-temps and embed-bitcode functionalities are active.
+  bool SaveTemps;
+  bool EmbedBitcode;
+
+  /// Get dependence action or null if that does not exist. If \a CanBeCollapsed
+  /// is false, that action must be legal to collapse or null will be returned.
+  const JobAction *getDependenceAction(const ActionList &Inputs,
+   ActionList &SavedOffloadAction,
+   bool CanBeCollapsed = true) {
+// An option can be collapsed only if it has a single input.
+if (Inputs.size() != 1)
+  return nullptr;
+
+Action *CurAction = *Inputs.begin();
+if (!CurAction->isCollapsingWithDependingActionLegal() && CanBeCollapsed)
+  return nullptr;
+
+// If the input action is an offload action. Look through it and save any
+// offload action that can be dropped in the event of a collapse.
+if (auto *OA = dyn_cast(CurAction)) {
+  // If the depending action is a device action, we will attempt to collapse
+  // only with other device actions. Otherwise, we would do the same but
+  // with host actions only.
+  if (!IsHostSelector) {
+if (OA->hasSingleDeviceDependence(/*DoNotConsiderHostActions=*/true)) {
+  CurAction =
+  OA->getSingleDeviceDependence(/*DoNotConsiderHostActions=*/true);
+  if (!CurAction->isCollapsingWithDependingActionLegal() &&
+  CanBeCollapsed)
+return nullptr;
+  SavedOffloadAction.push_back(OA);
+  return dyn_cast(CurAction);
+}
+  } else if (OA->hasHostDependence()) {
+CurAction = OA->getHostDependence();
+if (!CurAction->isCollapsingWithDependingActionLegal() &&
+CanBeCollapsed)
+  return nullptr;
+SavedOffloadAction.push_back(OA);
+return dyn_cast(CurAction);
   }
+  return nullptr;
+}
+
+return dyn_cast(CurAction);
   }
-  return nullptr;
-}
-// Returns a Tool for a given JobAction.  In case the action and its
-// predecessors can be combined, updates Inputs with the inputs of the
-// first combined action. If one of the collapsed actions is a
-// CudaHostAction, updates CollapsedCHA with the pointer to it so the
-// caller can deal with extra handling such action requires.
-static const Tool *selectToolForJob(Compilation &C, bool SaveTemps,
-bool EmbedBitcode, const ToolChain *TC,
-const JobAction *JA,
-const ActionList *&Inputs,
-ActionList &CollapsedOffloadAction) {
-  const Tool *ToolForJob = nullptr;
-  CollapsedOffloadAction.clear();
-
-  // See if we should look for a compiler with an integrated assembler. We match
-  // bottom up, so what we are actually looking for is an assembler job with a
-  // compiler input.
-
-  // Look through offload actions between assembler and backend actions.
-  Action *BackendJA = (isa(JA) 

Re: [PATCH] D21845: [Driver][OpenMP] Add specialized action builder for OpenMP offloading actions.

2016-09-21 Thread Samuel Antao via cfe-commits
sfantao updated this revision to Diff 72120.
sfantao added a comment.

- Rebase.


https://reviews.llvm.org/D21845

Files:
  lib/Driver/Driver.cpp
  test/Driver/openmp-offload.c

Index: test/Driver/openmp-offload.c
===
--- test/Driver/openmp-offload.c
+++ test/Driver/openmp-offload.c
@@ -35,3 +35,106 @@
 // RUN:   %clang -### -ccc-print-phases -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu,powerpc64le-ibm-linux-gnu  %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHK-DUPLICATES %s
 // CHK-DUPLICATES: warning: The OpenMP offloading target 'powerpc64le-ibm-linux-gnu' is similar to target 'powerpc64le-ibm-linux-gnu' already specified - will be ignored.
+
+/// ###
+
+/// Check the phases graph when using a single target, different from the host.
+/// We should have an offload action joining the host compile and device
+/// preprocessor and another one joining the device linking outputs to the host
+/// action.
+// RUN:   %clang -ccc-print-phases -fopenmp -target powerpc64le-ibm-linux-gnu -fopenmp-targets=x86_64-pc-linux-gnu %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-PHASES %s
+// CHK-PHASES: 0: input, "[[INPUT:.+\.c]]", c, (host-openmp)
+// CHK-PHASES: 1: preprocessor, {0}, cpp-output, (host-openmp)
+// CHK-PHASES: 2: compiler, {1}, ir, (host-openmp)
+// CHK-PHASES: 3: backend, {2}, assembler, (host-openmp)
+// CHK-PHASES: 4: assembler, {3}, object, (host-openmp)
+// CHK-PHASES: 5: linker, {4}, image, (host-openmp)
+// CHK-PHASES: 6: input, "[[INPUT]]", c, (device-openmp)
+// CHK-PHASES: 7: preprocessor, {6}, cpp-output, (device-openmp)
+// CHK-PHASES: 8: compiler, {7}, ir, (device-openmp)
+// CHK-PHASES: 9: offload, "host-openmp (powerpc64le-ibm-linux-gnu)" {2}, "device-openmp (x86_64-pc-linux-gnu)" {8}, ir
+// CHK-PHASES: 10: backend, {9}, assembler, (device-openmp)
+// CHK-PHASES: 11: assembler, {10}, object, (device-openmp)
+// CHK-PHASES: 12: linker, {11}, image, (device-openmp)
+// CHK-PHASES: 13: offload, "host-openmp (powerpc64le-ibm-linux-gnu)" {5}, "device-openmp (x86_64-pc-linux-gnu)" {12}, image
+
+/// ###
+
+/// Check the phases when using multiple targets. Here we also add a library to
+/// make sure it is treated as input by the device.
+// RUN:   %clang -ccc-print-phases -lsomelib -fopenmp -target powerpc64-ibm-linux-gnu -fopenmp-targets=x86_64-pc-linux-gnu,powerpc64-ibm-linux-gnu %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-PHASES-LIB %s
+// CHK-PHASES-LIB: 0: input, "somelib", object, (host-openmp)
+// CHK-PHASES-LIB: 1: input, "[[INPUT:.+\.c]]", c, (host-openmp)
+// CHK-PHASES-LIB: 2: preprocessor, {1}, cpp-output, (host-openmp)
+// CHK-PHASES-LIB: 3: compiler, {2}, ir, (host-openmp)
+// CHK-PHASES-LIB: 4: backend, {3}, assembler, (host-openmp)
+// CHK-PHASES-LIB: 5: assembler, {4}, object, (host-openmp)
+// CHK-PHASES-LIB: 6: linker, {0, 5}, image, (host-openmp)
+// CHK-PHASES-LIB: 7: input, "somelib", object, (device-openmp)
+// CHK-PHASES-LIB: 8: input, "[[INPUT]]", c, (device-openmp)
+// CHK-PHASES-LIB: 9: preprocessor, {8}, cpp-output, (device-openmp)
+// CHK-PHASES-LIB: 10: compiler, {9}, ir, (device-openmp)
+// CHK-PHASES-LIB: 11: offload, "host-openmp (powerpc64-ibm-linux-gnu)" {3}, "device-openmp (x86_64-pc-linux-gnu)" {10}, ir
+// CHK-PHASES-LIB: 12: backend, {11}, assembler, (device-openmp)
+// CHK-PHASES-LIB: 13: assembler, {12}, object, (device-openmp)
+// CHK-PHASES-LIB: 14: linker, {7, 13}, image, (device-openmp)
+// CHK-PHASES-LIB: 15: input, "somelib", object, (device-openmp)
+// CHK-PHASES-LIB: 16: input, "[[INPUT]]", c, (device-openmp)
+// CHK-PHASES-LIB: 17: preprocessor, {16}, cpp-output, (device-openmp)
+// CHK-PHASES-LIB: 18: compiler, {17}, ir, (device-openmp)
+// CHK-PHASES-LIB: 19: offload, "host-openmp (powerpc64-ibm-linux-gnu)" {3}, "device-openmp (powerpc64-ibm-linux-gnu)" {18}, ir
+// CHK-PHASES-LIB: 20: backend, {19}, assembler, (device-openmp)
+// CHK-PHASES-LIB: 21: assembler, {20}, object, (device-openmp)
+// CHK-PHASES-LIB: 22: linker, {15, 21}, image, (device-openmp)
+// CHK-PHASES-LIB: 23: offload, "host-openmp (powerpc64-ibm-linux-gnu)" {6}, "device-openmp (x86_64-pc-linux-gnu)" {14}, "device-openmp (powerpc64-ibm-linux-gnu)" {22}, image
+
+
+/// ###
+
+/// Check the phases when using multiple targets and multiple source files
+// RUN:   echo " " > %t.c
+// RUN:   %clang -ccc-print-phases -lsomelib -fopenmp -target powerpc64-ibm-linux-gnu -fopenmp-targets=x86_64-pc-linux-gnu,powerpc64-ibm-linux-gnu %s %t.c 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-PHASES-FILES %s
+// CHK-PHASES-FILES: 0: input, "somelib", object, (host-openmp)
+// CHK-PHASES-FILES: 1: input, "[[INPUT1:.+\.c]]", c, (host-openmp)
+// CHK-PHASES-FILES: 2: preprocessor, {1}, cpp-output, (host-

Re: [PATCH] D21843: [Driver][OpenMP] Create tool chains for OpenMP offloading kind.

2016-09-21 Thread Samuel Antao via cfe-commits
sfantao updated this revision to Diff 72119.
sfantao added a comment.

- Rebase.


https://reviews.llvm.org/D21843

Files:
  include/clang/Basic/DiagnosticDriverKinds.td
  include/clang/Driver/Action.h
  include/clang/Driver/Driver.h
  lib/Driver/Action.cpp
  lib/Driver/Driver.cpp
  lib/Driver/Tools.cpp
  test/Driver/openmp-offload.c

Index: test/Driver/openmp-offload.c
===
--- /dev/null
+++ test/Driver/openmp-offload.c
@@ -0,0 +1,37 @@
+///
+/// Perform several driver tests for OpenMP offloading
+///
+
+/// ###
+
+/// Check whether an invalid OpenMP target is specified:
+// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=aaa-bbb-ccc-ddd %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-INVALID-TARGET %s
+// RUN:   %clang -### -fopenmp -fopenmp-targets=aaa-bbb-ccc-ddd %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-INVALID-TARGET %s
+// CHK-INVALID-TARGET: error: OpenMP target is invalid: 'aaa-bbb-ccc-ddd'
+
+/// ###
+
+/// Check warning for empty -fopenmp-targets
+// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=  %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-EMPTY-OMPTARGETS %s
+// RUN:   %clang -### -fopenmp -fopenmp-targets=  %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-EMPTY-OMPTARGETS %s
+// CHK-EMPTY-OMPTARGETS: warning: joined argument expects additional value: '-fopenmp-targets='
+
+/// ###
+
+/// Check error for no -fopenmp option
+// RUN:   %clang -### -fopenmp-targets=powerpc64le-ibm-linux-gnu  %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-NO-FOPENMP %s
+// RUN:   %clang -### -fopenmp=libgomp -fopenmp-targets=powerpc64le-ibm-linux-gnu  %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-NO-FOPENMP %s
+// CHK-NO-FOPENMP: error: The option -fopenmp-targets must be used in conjunction with a -fopenmp option compatible with offloading.
+
+/// ###
+
+/// Check warning for duplicate offloading targets.
+// RUN:   %clang -### -ccc-print-phases -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu,powerpc64le-ibm-linux-gnu  %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-DUPLICATES %s
+// CHK-DUPLICATES: warning: The OpenMP offloading target 'powerpc64le-ibm-linux-gnu' is similar to target 'powerpc64le-ibm-linux-gnu' already specified - will be ignored.
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -2978,72 +2978,23 @@
   CmdArgs.push_back(TC.getCompilerRTArgString(Args, "builtins"));
 }
 
-namespace {
-enum OpenMPRuntimeKind {
-  /// An unknown OpenMP runtime. We can't generate effective OpenMP code
-  /// without knowing what runtime to target.
-  OMPRT_Unknown,
-
-  /// The LLVM OpenMP runtime. When completed and integrated, this will become
-  /// the default for Clang.
-  OMPRT_OMP,
-
-  /// The GNU OpenMP runtime. Clang doesn't support generating OpenMP code for
-  /// this runtime but can swallow the pragmas, and find and link against the
-  /// runtime library itself.
-  OMPRT_GOMP,
-
-  /// The legacy name for the LLVM OpenMP runtime from when it was the Intel
-  /// OpenMP runtime. We support this mode for users with existing dependencies
-  /// on this runtime library name.
-  OMPRT_IOMP5
-};
-}
-
-/// Compute the desired OpenMP runtime from the flag provided.
-static OpenMPRuntimeKind getOpenMPRuntime(const ToolChain &TC,
-  const ArgList &Args) {
-  StringRef RuntimeName(CLANG_DEFAULT_OPENMP_RUNTIME);
-
-  const Arg *A = Args.getLastArg(options::OPT_fopenmp_EQ);
-  if (A)
-RuntimeName = A->getValue();
-
-  auto RT = llvm::StringSwitch(RuntimeName)
-.Case("libomp", OMPRT_OMP)
-.Case("libgomp", OMPRT_GOMP)
-.Case("libiomp5", OMPRT_IOMP5)
-.Default(OMPRT_Unknown);
-
-  if (RT == OMPRT_Unknown) {
-if (A)
-  TC.getDriver().Diag(diag::err_drv_unsupported_option_argument)
-  << A->getOption().getName() << A->getValue();
-else
-  // FIXME: We could use a nicer diagnostic here.
-  TC.getDriver().Diag(diag::err_drv_unsupported_opt) << "-fopenmp";
-  }
-
-  return RT;
-}
-
 static void addOpenMPRuntime(ArgStringList &CmdArgs, const ToolChain &TC,
   const ArgList &Args) {
   if (!Args.hasFlag(options::OPT_fopenmp, options::OPT_fopenmp_EQ,
 options::OPT_fno_openmp, false))
 return;
 
-  switch (getOpenMPRuntime(TC, Args)) {
-  case OMPRT_OMP:
+  switch (TC.getDriver().getOpenMPRuntime(Args)) {
+  case Driver::OMPRT_OMP:
 CmdArgs.push_back("-lomp");
 break;
-  case OMPRT_GOMP:
+  case Driver::OMPRT_GOMP:
 CmdArgs.push_back("-lgomp

Re: [PATCH] D21847: [Driver][OpenMP] Build jobs for OpenMP offloading actions for targets using gcc tool chains.

2016-09-21 Thread Samuel Antao via cfe-commits
sfantao updated this revision to Diff 72121.
sfantao added a comment.

- Rebase.


https://reviews.llvm.org/D21847

Files:
  include/clang/Driver/Options.td
  lib/Driver/Driver.cpp
  lib/Driver/Tools.cpp
  test/Driver/openmp-offload.c

Index: test/Driver/openmp-offload.c
===
--- test/Driver/openmp-offload.c
+++ test/Driver/openmp-offload.c
@@ -138,3 +138,104 @@
 // CHK-PHASES-FILES: 38: assembler, {37}, object, (device-openmp)
 // CHK-PHASES-FILES: 39: linker, {26, 32, 38}, image, (device-openmp)
 // CHK-PHASES-FILES: 40: offload, "host-openmp (powerpc64-ibm-linux-gnu)" {11}, "device-openmp (x86_64-pc-linux-gnu)" {25}, "device-openmp (powerpc64-ibm-linux-gnu)" {39}, image
+
+
+/// ###
+
+/// Check of the commands passed to each tool when using valid OpenMP targets.
+/// Here we also check that offloading does not break the use of integrated
+/// assembler. It does however preclude the merge of the host compile and
+/// backend phases. There are also two offloading specific options:
+/// -fopenmp-is-device: will tell the frontend that it will generate code for a
+/// target.
+/// -fopenmp-host-ir-file-path: specifies the host IR file that can be loaded by
+/// the target code generation to gather information about which declaration
+/// really need to be emitted.
+/// We use -fopenmp-dump-offload-linker-script to dump the linker script and
+/// check its contents.
+///
+// RUN:   %clang -### -fopenmp -o %t.out -target powerpc64le-linux -fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu %s -fopenmp-dump-offload-linker-script 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-COMMANDS -check-prefix=CHK-LKS -check-prefix=CHK-LKS-REG %s
+// RUN:   %clang -### -fopenmp -o %t.out -target powerpc64le-linux -fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu %s -save-temps -fopenmp-dump-offload-linker-script 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-COMMANDS-ST -check-prefix=CHK-LKS -check-prefix=CHK-LKS-ST %s
+
+// Make sure we are not dumping the script unless the user requested it.
+// RUN:   %clang -### -fopenmp -o %t.out -target powerpc64le-linux -fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-LKS-NODUMP %s
+// RUN:   %clang -### -fopenmp -o %t.out -target powerpc64le-linux -fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu %s -save-temps 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-LKS-NODUMP %s
+
+//
+// Check the linker script contains what we expect.
+//
+// CHK-LKS: /*
+// CHK-LKS: OpenMP Offload Linker Script.
+// CHK-LKS-NODUMP-NOT:  OpenMP Offload Linker Script.
+// CHK-LKS: */
+// CHK-LKS: TARGET(binary)
+// CHK-LKS-REG: INPUT([[T1BIN:.+\.out]])
+// CHK-LKS-REG: INPUT([[T2BIN:.+\.out]])
+// CHK-LKS-ST: INPUT([[T1BIN:.+\.out-device-openmp-powerpc64le-ibm-linux-gnu]])
+// CHK-LKS-ST: INPUT([[T2BIN:.+\.out-device-openmp-x86_64-pc-linux-gnu]])
+// CHK-LKS: SECTIONS
+// CHK-LKS: {
+// CHK-LKS:   .omp_offloading :
+// CHK-LKS:   ALIGN(0x10)
+// CHK-LKS:   {
+// CHK-LKS: . = ALIGN(0x10);
+// CHK-LKS: PROVIDE_HIDDEN(.omp_offloading.img_start.powerpc64le-ibm-linux-gnu = .);
+// CHK-LKS: [[T1BIN]]
+// CHK-LKS: PROVIDE_HIDDEN(.omp_offloading.img_end.powerpc64le-ibm-linux-gnu = .);
+// CHK-LKS: . = ALIGN(0x10);
+// CHK-LKS: PROVIDE_HIDDEN(.omp_offloading.img_start.x86_64-pc-linux-gnu = .);
+// CHK-LKS: [[T2BIN]]
+// CHK-LKS: PROVIDE_HIDDEN(.omp_offloading.img_end.x86_64-pc-linux-gnu = .);
+// CHK-LKS:   }
+// CHK-LKS:   .omp_offloading.entries :
+// CHK-LKS:   ALIGN(0x10)
+// CHK-LKS:   SUBALIGN(0x01)
+// CHK-LKS:   {
+// CHK-LKS: PROVIDE_HIDDEN(.omp_offloading.entries_begin = .);
+// CHK-LKS: *(.omp_offloading.entries)
+// CHK-LKS: PROVIDE_HIDDEN(.omp_offloading.entries_end = .);
+// CHK-LKS:   }
+// CHK-LKS: }
+// CHK-LKS: INSERT BEFORE .data
+
+//
+// Generate host BC file.
+//
+// CHK-COMMANDS: clang{{.*}}" "-cc1" "-triple" "powerpc64le--linux" "-emit-llvm-bc" {{.*}}"-o" "[[HOSTBC:.+\.bc]]" "-x" "c" "[[INPUT:.+\.c]]" "-fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu"
+// CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le--linux" "-E" {{.*}}"-fopenmp" {{.*}}"-o" "[[HOSTPP:.+\.i]]" "-x" "c" "[[INPUT:.+\.c]]"
+// CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le--linux" "-emit-llvm-bc" {{.*}}"-fopenmp" {{.*}}"-o" "[[HOSTBC:.+\.bc]]" "-x" "cpp-output" "[[HOSTPP]]" "-fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu"
+
+//
+// Compile for the powerpc device.
+//
+// CHK-COMMANDS: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-emit-obj" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1OBJ:.+\.o]]" "-x" "c" "[[INPUT]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
+// CHK-COMMANDS: ld" {{.*}}"-o" "[[T1BIN]]" {{.*}}"[[T1OBJ]]"
+// CHK-COMMANDS-ST: clang{{.*}}" "-cc1

Re: [PATCH] D21848: [Driver][OpenMP] Add logic for offloading-specific argument translation.

2016-09-21 Thread Samuel Antao via cfe-commits
sfantao updated this revision to Diff 72122.
sfantao added a comment.

- Rebase.


https://reviews.llvm.org/D21848

Files:
  include/clang/Driver/Compilation.h
  include/clang/Driver/ToolChain.h
  lib/Driver/Compilation.cpp
  lib/Driver/Driver.cpp
  lib/Driver/MSVCToolChain.cpp
  lib/Driver/ToolChains.cpp
  lib/Driver/ToolChains.h
  test/Driver/openmp-offload.c

Index: test/Driver/openmp-offload.c
===
--- test/Driver/openmp-offload.c
+++ test/Driver/openmp-offload.c
@@ -212,24 +212,24 @@
 //
 // Compile for the powerpc device.
 //
-// CHK-COMMANDS: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-emit-obj" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1OBJ:.+\.o]]" "-x" "c" "[[INPUT]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
+// CHK-COMMANDS: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-emit-obj" {{.*}}"-pic-level" "2" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1OBJ:.+\.o]]" "-x" "c" "[[INPUT]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
 // CHK-COMMANDS: ld" {{.*}}"-o" "[[T1BIN]]" {{.*}}"[[T1OBJ]]"
 // CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-E" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1PP:.+\.i]]" "-x" "c" "[[INPUT]]"
-// CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-emit-llvm-bc" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1BC:.+\.bc]]" "-x" "cpp-output" "[[T1PP]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
+// CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-emit-llvm-bc" {{.*}}"-pic-level" "2" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1BC:.+\.bc]]" "-x" "cpp-output" "[[T1PP]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
 // CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-S" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1ASM:.+\.s]]" "-x" "ir" "[[T1BC]]"
 // CHK-COMMANDS-ST: clang{{.*}}" "-cc1as" "-triple" "powerpc64le-ibm-linux-gnu" "-filetype" "obj" {{.*}}"-o" "[[T1OBJ:.+\.o]]" "[[T1ASM]]"
-// CHK-COMMANDS-ST: ld" {{.*}}"-o" "[[T1BIN]]" {{.*}}[[T1OBJ]]
+// CHK-COMMANDS-ST: ld" {{.*}}"-shared" {{.*}}"-o" "[[T1BIN]]" {{.*}}[[T1OBJ]]
 
 //
 // Compile for the x86 device.
 //
-// CHK-COMMANDS: clang{{.*}}" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-emit-obj"  {{.*}}"-fopenmp"  {{.*}}"-o" "[[T2OBJ:.+\.o]]" "-x" "c" "[[INPUT]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
+// CHK-COMMANDS: clang{{.*}}" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-emit-obj" {{.*}}"-pic-level" "2" {{.*}}"-fopenmp"  {{.*}}"-o" "[[T2OBJ:.+\.o]]" "-x" "c" "[[INPUT]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
 // CHK-COMMANDS: ld" {{.*}}"-o" "[[T2BIN]]" {{.*}}"[[T2OBJ]]"
 // CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-E" {{.*}}"-fopenmp" {{.*}}"-o" "[[T2PP:.+\.i]]" "-x" "c" "[[INPUT]]"
-// CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-emit-llvm-bc" {{.*}}"-fopenmp" {{.*}}"-o" "[[T2BC:.+\.bc]]" "-x" "cpp-output" "[[T2PP]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
+// CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-emit-llvm-bc" {{.*}}"-pic-level" "2" {{.*}}"-fopenmp" {{.*}}"-o" "[[T2BC:.+\.bc]]" "-x" "cpp-output" "[[T2PP]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
 // CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-S" {{.*}}"-fopenmp" {{.*}}"-o" "[[T2ASM:.+\.s]]" "-x" "ir" "[[T2BC]]"
 // CHK-COMMANDS-ST: clang{{.*}}" "-cc1as" "-triple" "x86_64-pc-linux-gnu" "-filetype" "obj" {{.*}}"-o" "[[T2OBJ:.+\.o]]" "[[T2ASM]]"
-// CHK-COMMANDS-ST: ld" {{.*}}"-o" "[[T2BIN]]" {{.*}}[[T2OBJ]]
+// CHK-COMMANDS-ST: ld" {{.*}}"-shared" {{.*}}"-o" "[[T2BIN]]" {{.*}}[[T2OBJ]]
 
 //
 // Generate host object from the BC file and link using the linker script.
Index: lib/Driver/ToolChains.h
===
--- lib/Driver/ToolChains.h
+++ lib/Driver/ToolChains.h
@@ -222,6 +222,9 @@
   bool isPIEDefault() const override;
   bool isPICDefaultForced() const override;
   bool IsIntegratedAssemblerDefault() const override;
+  llvm::opt::DerivedArgList *
+  TranslateArgs(const llvm::opt::DerivedArgList &Args, const char *BoundArch,
+Action::OffloadKind DeviceOffloadKind) const override;
 
 protected:
   Tool *getTool(Action::ActionClass AC) const override;
@@ -317,8 +320,8 @@
   bool HasNativeLLVMSupport() const override;
 
   llvm::opt::DerivedArgList *
-  TranslateArgs(const llvm::opt::DerivedArgList &Args,
-const char *BoundArch) const override;
+  TranslateArgs(const llvm::opt::DerivedArgList &Args, const char *BoundArch,
+Action::OffloadKind DeviceOffloadKind) const override;
 
   bool IsBlocksDefault() const override {
 // Always allow blocks on Apple; users interested in versioning are
@@ -522,8 +525,8 @@
   bool isCrossCompiling() const override { return fa

Re: [PATCH] D21853: [Driver][OpenMP] Update actions builder to create unbundling action when necessary.

2016-09-21 Thread Samuel Antao via cfe-commits
sfantao updated this revision to Diff 72124.
sfantao added a comment.

- Rebase.


https://reviews.llvm.org/D21853

Files:
  include/clang/Driver/Action.h
  include/clang/Driver/Types.h
  lib/Driver/Action.cpp
  lib/Driver/Driver.cpp
  lib/Driver/ToolChain.cpp
  lib/Driver/Types.cpp
  test/Driver/openmp-offload.c

Index: test/Driver/openmp-offload.c
===
--- test/Driver/openmp-offload.c
+++ test/Driver/openmp-offload.c
@@ -267,3 +267,56 @@
 // CHK-BUACTIONS: 17: backend, {2}, assembler, (host-openmp)
 // CHK-BUACTIONS: 18: assembler, {17}, object, (host-openmp)
 // CHK-BUACTIONS: 19: clang-offload-bundler, {9, 16, 18}, object, (host-openmp)
+
+/// ###
+
+/// Check separate compilation with offloading - unbundling actions
+// RUN:   touch %t.i
+// RUN:   %clang -### -ccc-print-phases -fopenmp -o %t.out -lsomelib -target powerpc64le-linux -fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu %t.i 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-UBACTIONS %s
+
+// CHK-UBACTIONS: 0: input, "somelib", object, (host-openmp)
+// CHK-UBACTIONS: 1: input, "[[INPUT:.+\.i]]", cpp-output, (host-openmp)
+// CHK-UBACTIONS: 2: clang-offload-unbundler, {1}, cpp-output, (host-openmp)
+// CHK-UBACTIONS: 3: compiler, {2}, ir, (host-openmp)
+// CHK-UBACTIONS: 4: backend, {3}, assembler, (host-openmp)
+// CHK-UBACTIONS: 5: assembler, {4}, object, (host-openmp)
+// CHK-UBACTIONS: 6: linker, {0, 5}, image, (host-openmp)
+// CHK-UBACTIONS: 7: input, "somelib", object, (device-openmp)
+// CHK-UBACTIONS: 8: compiler, {2}, ir, (device-openmp)
+// CHK-UBACTIONS: 9: offload, "host-openmp (powerpc64le--linux)" {3}, "device-openmp (powerpc64le-ibm-linux-gnu)" {8}, ir
+// CHK-UBACTIONS: 10: backend, {9}, assembler, (device-openmp)
+// CHK-UBACTIONS: 11: assembler, {10}, object, (device-openmp)
+// CHK-UBACTIONS: 12: linker, {7, 11}, image, (device-openmp)
+// CHK-UBACTIONS: 13: input, "somelib", object, (device-openmp)
+// CHK-UBACTIONS: 14: compiler, {2}, ir, (device-openmp)
+// CHK-UBACTIONS: 15: offload, "host-openmp (powerpc64le--linux)" {3}, "device-openmp (x86_64-pc-linux-gnu)" {14}, ir
+// CHK-UBACTIONS: 16: backend, {15}, assembler, (device-openmp)
+// CHK-UBACTIONS: 17: assembler, {16}, object, (device-openmp)
+// CHK-UBACTIONS: 18: linker, {13, 17}, image, (device-openmp)
+// CHK-UBACTIONS: 19: offload, "host-openmp (powerpc64le--linux)" {6}, "device-openmp (powerpc64le-ibm-linux-gnu)" {12}, "device-openmp (x86_64-pc-linux-gnu)" {18}, image
+
+/// ###
+
+/// Check separate compilation with offloading - unbundling/bundling actions
+// RUN:   touch %t.i
+// RUN:   %clang -### -ccc-print-phases -fopenmp -c -o %t.o -lsomelib -target powerpc64le-linux -fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu %t.i 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-UBUACTIONS %s
+
+// CHK-UBUACTIONS: 0: input, "[[INPUT:.+\.i]]", cpp-output, (host-openmp)
+// CHK-UBUACTIONS: 1: clang-offload-unbundler, {0}, cpp-output, (host-openmp)
+// CHK-UBUACTIONS: 2: compiler, {1}, ir, (host-openmp)
+// CHK-UBUACTIONS: 3: compiler, {1}, ir, (device-openmp)
+// CHK-UBUACTIONS: 4: offload, "host-openmp (powerpc64le--linux)" {2}, "device-openmp (powerpc64le-ibm-linux-gnu)" {3}, ir
+// CHK-UBUACTIONS: 5: backend, {4}, assembler, (device-openmp)
+// CHK-UBUACTIONS: 6: assembler, {5}, object, (device-openmp)
+// CHK-UBUACTIONS: 7: offload, "device-openmp (powerpc64le-ibm-linux-gnu)" {6}, object
+// CHK-UBUACTIONS: 8: compiler, {1}, ir, (device-openmp)
+// CHK-UBUACTIONS: 9: offload, "host-openmp (powerpc64le--linux)" {2}, "device-openmp (x86_64-pc-linux-gnu)" {8}, ir
+// CHK-UBUACTIONS: 10: backend, {9}, assembler, (device-openmp)
+// CHK-UBUACTIONS: 11: assembler, {10}, object, (device-openmp)
+// CHK-UBUACTIONS: 12: offload, "device-openmp (x86_64-pc-linux-gnu)" {11}, object
+// CHK-UBUACTIONS: 13: backend, {2}, assembler, (host-openmp)
+// CHK-UBUACTIONS: 14: assembler, {13}, object, (host-openmp)
+// CHK-UBUACTIONS: 15: clang-offload-bundler, {7, 12, 14}, object, (host-openmp)
+
Index: lib/Driver/Types.cpp
===
--- lib/Driver/Types.cpp
+++ lib/Driver/Types.cpp
@@ -163,6 +163,10 @@
   }
 }
 
+bool types::isSrcFile(ID Id) {
+  return Id != TY_Object && getPreprocessedType(Id) != TY_INVALID;
+}
+
 types::ID types::lookupTypeForExtension(const char *Ext) {
   return llvm::StringSwitch(Ext)
.Case("c", TY_C)
Index: lib/Driver/ToolChain.cpp
===
--- lib/Driver/ToolChain.cpp
+++ lib/Driver/ToolChain.cpp
@@ -265,6 +265,7 @@
 return getClang();
 
   case Action::OffloadBundlingJobClass:
+  case Action::OffloadUnbundlingJobClass:
 // FIXME: Add a tool for the bundling actions.
 return nullptr;
   }
I

Re: [PATCH] D21852: [Driver][OpenMP] Update actions builder to create bundling action when necessary.

2016-09-21 Thread Samuel Antao via cfe-commits
sfantao updated this revision to Diff 72123.
sfantao added a comment.

- Rebase.


https://reviews.llvm.org/D21852

Files:
  include/clang/Driver/Action.h
  lib/Driver/Action.cpp
  lib/Driver/Driver.cpp
  lib/Driver/ToolChain.cpp
  test/Driver/openmp-offload.c

Index: test/Driver/openmp-offload.c
===
--- test/Driver/openmp-offload.c
+++ test/Driver/openmp-offload.c
@@ -239,3 +239,31 @@
 // CHK-COMMANDS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le--linux" "-S" {{.*}}"-fopenmp" {{.*}}"-o" "[[HOSTASM:.+\.s]]" "-x" "ir" "[[HOSTBC]]"
 // CHK-COMMANDS-ST: clang{{.*}}" "-cc1as" "-triple" "powerpc64le--linux" "-filetype" "obj" {{.*}}"-o" [[HOSTOBJ:.+\.o]]" [[HOSTASM:.+\.s]]
 // CHK-COMMANDS-ST: ld" {{.*}}"-o" "[[HOSTBIN:.+\.out]]"  {{.*}}"-lomptarget" {{.*}}"-T" "[[HOSTLK:.+\.lk]]"
+
+
+/// ###
+
+/// Check separate compilation with offloading - bundling actions
+// RUN:   %clang -### -ccc-print-phases -fopenmp -c -o %t.o -lsomelib -target powerpc64le-linux -fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-BUACTIONS %s
+
+// CHK-BUACTIONS: 0: input, "[[INPUT:.+\.c]]", c, (host-openmp)
+// CHK-BUACTIONS: 1: preprocessor, {0}, cpp-output, (host-openmp)
+// CHK-BUACTIONS: 2: compiler, {1}, ir, (host-openmp)
+// CHK-BUACTIONS: 3: input, "[[INPUT]]", c, (device-openmp)
+// CHK-BUACTIONS: 4: preprocessor, {3}, cpp-output, (device-openmp)
+// CHK-BUACTIONS: 5: compiler, {4}, ir, (device-openmp)
+// CHK-BUACTIONS: 6: offload, "host-openmp (powerpc64le--linux)" {2}, "device-openmp (powerpc64le-ibm-linux-gnu)" {5}, ir
+// CHK-BUACTIONS: 7: backend, {6}, assembler, (device-openmp)
+// CHK-BUACTIONS: 8: assembler, {7}, object, (device-openmp)
+// CHK-BUACTIONS: 9: offload, "device-openmp (powerpc64le-ibm-linux-gnu)" {8}, object
+// CHK-BUACTIONS: 10: input, "[[INPUT]]", c, (device-openmp)
+// CHK-BUACTIONS: 11: preprocessor, {10}, cpp-output, (device-openmp)
+// CHK-BUACTIONS: 12: compiler, {11}, ir, (device-openmp)
+// CHK-BUACTIONS: 13: offload, "host-openmp (powerpc64le--linux)" {2}, "device-openmp (x86_64-pc-linux-gnu)" {12}, ir
+// CHK-BUACTIONS: 14: backend, {13}, assembler, (device-openmp)
+// CHK-BUACTIONS: 15: assembler, {14}, object, (device-openmp)
+// CHK-BUACTIONS: 16: offload, "device-openmp (x86_64-pc-linux-gnu)" {15}, object
+// CHK-BUACTIONS: 17: backend, {2}, assembler, (host-openmp)
+// CHK-BUACTIONS: 18: assembler, {17}, object, (host-openmp)
+// CHK-BUACTIONS: 19: clang-offload-bundler, {9, 16, 18}, object, (host-openmp)
Index: lib/Driver/ToolChain.cpp
===
--- lib/Driver/ToolChain.cpp
+++ lib/Driver/ToolChain.cpp
@@ -263,6 +263,10 @@
   case Action::VerifyPCHJobClass:
   case Action::BackendJobClass:
 return getClang();
+
+  case Action::OffloadBundlingJobClass:
+// FIXME: Add a tool for the bundling actions.
+return nullptr;
   }
 
   llvm_unreachable("Invalid tool kind.");
Index: lib/Driver/Driver.cpp
===
--- lib/Driver/Driver.cpp
+++ lib/Driver/Driver.cpp
@@ -1562,6 +1562,9 @@
 /// found.
 virtual bool initialize() { return false; }
 
+/// Return true if the builder can use bundling/unbundling.
+virtual bool canUseBundlerUnbundler() const { return false; }
+
 /// Return true if this builder is valid. We have a valid builder if we have
 /// associated device tool chains.
 bool isValid() { return !ToolChains.empty(); }
@@ -1898,6 +1901,26 @@
   return ABRT_Success;
 }
 
+void appendTopLevelActions(ActionList &AL) override {
+  if (OpenMPDeviceActions.empty())
+return;
+
+  // We should always have an action for each input.
+  assert(OpenMPDeviceActions.size() == ToolChains.size() &&
+ "Number of OpenMP actions and toolchains do not match.");
+
+  // Append all device actions followed by the proper offload action.
+  auto TI = ToolChains.begin();
+  for (auto *A : OpenMPDeviceActions) {
+OffloadAction::DeviceDependences Dep;
+Dep.add(*A, **TI, /*BoundArch=*/nullptr, Action::OFK_OpenMP);
+AL.push_back(C.MakeAction(Dep, A->getType()));
+++TI;
+  }
+  // We no longer need the action stored in this builder.
+  OpenMPDeviceActions.clear();
+}
+
 void appendLinkDependences(OffloadAction::DeviceDependences &DA) override {
   assert(ToolChains.size() == DeviceLinkerInputs.size() &&
  "Toolchains and linker inputs sizes do not match.");
@@ -1924,6 +1947,11 @@
   DeviceLinkerInputs.resize(ToolChains.size());
   return false;
 }
+
+bool canUseBundlerUnbundler() const override {
+  // OpenMP should use bundled files whenever possible.
+  return true;
+}
   };
 
   ///
@@ -1933,6 +1961,9 @@
   /// Speciali

Re: [PATCH] D21856: [Driver][OpenMP] Add support to create jobs for bundling actions.

2016-09-21 Thread Samuel Antao via cfe-commits
sfantao updated this revision to Diff 72125.
sfantao added a comment.

- Rebase.


https://reviews.llvm.org/D21856

Files:
  include/clang/Driver/Action.h
  include/clang/Driver/ToolChain.h
  lib/Driver/Action.cpp
  lib/Driver/ToolChain.cpp
  lib/Driver/Tools.cpp
  lib/Driver/Tools.h
  test/Driver/openmp-offload.c

Index: test/Driver/openmp-offload.c
===
--- test/Driver/openmp-offload.c
+++ test/Driver/openmp-offload.c
@@ -320,3 +320,37 @@
 // CHK-UBUACTIONS: 14: assembler, {13}, object, (host-openmp)
 // CHK-UBUACTIONS: 15: clang-offload-bundler, {7, 12, 14}, object, (host-openmp)
 
+/// ###
+
+/// Check separate compilation with offloading - bundling jobs construct
+// RUN:   %clang -### -fopenmp -c -o %t.o -lsomelib -target powerpc64le-linux -fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-BUJOBS %s
+// RUN:   %clang -### -fopenmp -c -o %t.o -lsomelib -target powerpc64le-linux -fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu %s -save-temps 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-BUJOBS-ST %s
+
+// Create host BC.
+// CHK-BUJOBS: clang{{.*}}" "-cc1" "-triple" "powerpc64le--linux" "-emit-llvm-bc"  {{.*}}"-fopenmp" {{.*}}"-o" "[[HOSTBC:.+\.bc]]" "-x" "c" "[[INPUT:.+\.c]]" "-fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu"
+
+// CHK-BUJOBS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le--linux" "-E"  {{.*}}"-fopenmp" {{.*}}"-o" "[[HOSTPP:.+\.i]]" "-x" "c" "[[INPUT:.+\.c]]"
+// CHK-BUJOBS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le--linux" "-emit-llvm-bc"  {{.*}}"-fopenmp" {{.*}}"-o" "[[HOSTBC:.+\.bc]]" "-x" "cpp-output" "[[HOSTPP]]" "-fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu"
+
+// Create target 1 object.
+// CHK-BUJOBS: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-emit-obj" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1OBJ:.+\.o]]" "-x" "c" "[[INPUT]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
+// CHK-BUJOBS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-E" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1PP:.+\.i]]" "-x" "c" "[[INPUT]]"
+// CHK-BUJOBS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-emit-llvm-bc" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1BC:.+\.bc]]" "-x" "cpp-output" "[[T1PP]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
+// CHK-BUJOBS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-S" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1ASM:.+\.s]]" "-x" "ir" "[[T1BC]]"
+// CHK-BUJOBS-ST: clang{{.*}}" "-cc1as" "-triple" "powerpc64le-ibm-linux-gnu" "-filetype" "obj" {{.*}}"-o" "[[T1OBJ:.+\.o]]" "[[T1ASM]]"
+
+// Create target 2 object.
+// CHK-BUJOBS: clang{{.*}}" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-emit-obj" {{.*}}"-fopenmp" {{.*}}"-o" "[[T2OBJ:.+\.o]]" "-x" "c" "[[INPUT]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
+// CHK-BUJOBS-ST: clang{{.*}}" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-E" {{.*}}"-fopenmp" {{.*}}"-o" "[[T2PP:.+\.i]]" "-x" "c" "[[INPUT]]"
+// CHK-BUJOBS-ST: clang{{.*}}" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-emit-llvm-bc" {{.*}}"-fopenmp" {{.*}}"-o" "[[T2BC:.+\.bc]]" "-x" "cpp-output" "[[T2PP]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
+// CHK-BUJOBS-ST: clang{{.*}}" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-S" {{.*}}"-fopenmp" {{.*}}"-o" "[[T2ASM:.+\.s]]" "-x" "ir" "[[T2BC]]"
+// CHK-BUJOBS-ST: clang{{.*}}" "-cc1as" "-triple" "x86_64-pc-linux-gnu" "-filetype" "obj" {{.*}}"-o" "[[T2OBJ:.+\.o]]" "[[T2ASM]]"
+
+// Create host object and bundle.
+// CHK-BUJOBS: clang{{.*}}" "-cc1" "-triple" "powerpc64le--linux" "-emit-obj" {{.*}}"-fopenmp" {{.*}}"-o" "[[HOSTOBJ:.+\.o]]" "-x" "ir" "[[HOSTBC]]"
+// CHK-BUJOBS: clang-offload-bundler" "-type=o" "-targets=openmp-powerpc64le-ibm-linux-gnu,openmp-x86_64-pc-linux-gnu,host-powerpc64le--linux" "-outputs=[[RES:.+\.o]]" "-inputs=[[T1OBJ]],[[T2OBJ]],[[HOSTOBJ]]"
+// CHK-BUJOBS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le--linux" "-S" {{.*}}"-fopenmp" {{.*}}"-o" "[[HOSTASM:.+\.s]]" "-x" "ir" "[[HOSTBC]]"
+// CHK-BUJOBS-ST: clang{{.*}}" "-cc1as" "-triple" "powerpc64le--linux" "-filetype" "obj" {{.*}}"-o" "[[HOSTOBJ:.+\.o]]" "[[HOSTASM]]"
+// CHK-BUJOBS-ST: clang-offload-bundler" "-type=o" "-targets=openmp-powerpc64le-ibm-linux-gnu,openmp-x86_64-pc-linux-gnu,host-powerpc64le--linux" "-outputs=[[RES:.+\.o]]" "-inputs=[[T1OBJ]],[[T2OBJ]],[[HOSTOBJ]]"
Index: lib/Driver/Tools.h
===
--- lib/Driver/Tools.h
+++ lib/Driver/Tools.h
@@ -137,6 +137,19 @@
 const char *LinkingOutput) const override;
 };
 
+/// Offload bundler tool.
+class LLVM_LIBRARY_VISIBILITY OffloadBundler final : public Tool {
+public:
+  OffloadBundler(const ToolChain &TC)
+  : Tool("offload bundler", "clang-offload-bundler", TC) {}
+
+  bool h

Re: [PATCH] D21857: [Driver][OpenMP] Add support to create jobs for unbundling actions.

2016-09-21 Thread Samuel Antao via cfe-commits
sfantao updated this revision to Diff 72126.
sfantao added a comment.

- Rebase.


https://reviews.llvm.org/D21857

Files:
  include/clang/Driver/Action.h
  include/clang/Driver/Driver.h
  include/clang/Driver/Tool.h
  lib/Driver/Action.cpp
  lib/Driver/Driver.cpp
  lib/Driver/Tool.cpp
  lib/Driver/Tools.cpp
  lib/Driver/Tools.h
  test/Driver/cuda-bindings.cu
  test/Driver/openmp-offload.c

Index: test/Driver/openmp-offload.c
===
--- test/Driver/openmp-offload.c
+++ test/Driver/openmp-offload.c
@@ -175,8 +175,8 @@
 // CHK-LKS: TARGET(binary)
 // CHK-LKS-REG: INPUT([[T1BIN:.+\.out]])
 // CHK-LKS-REG: INPUT([[T2BIN:.+\.out]])
-// CHK-LKS-ST: INPUT([[T1BIN:.+\.out-device-openmp-powerpc64le-ibm-linux-gnu]])
-// CHK-LKS-ST: INPUT([[T2BIN:.+\.out-device-openmp-x86_64-pc-linux-gnu]])
+// CHK-LKS-ST: INPUT([[T1BIN:.+\.out-openmp-powerpc64le-ibm-linux-gnu]])
+// CHK-LKS-ST: INPUT([[T2BIN:.+\.out-openmp-x86_64-pc-linux-gnu]])
 // CHK-LKS: SECTIONS
 // CHK-LKS: {
 // CHK-LKS:   .omp_offloading :
@@ -354,3 +354,92 @@
 // CHK-BUJOBS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le--linux" "-S" {{.*}}"-fopenmp" {{.*}}"-o" "[[HOSTASM:.+\.s]]" "-x" "ir" "[[HOSTBC]]"
 // CHK-BUJOBS-ST: clang{{.*}}" "-cc1as" "-triple" "powerpc64le--linux" "-filetype" "obj" {{.*}}"-o" "[[HOSTOBJ:.+\.o]]" "[[HOSTASM]]"
 // CHK-BUJOBS-ST: clang-offload-bundler" "-type=o" "-targets=openmp-powerpc64le-ibm-linux-gnu,openmp-x86_64-pc-linux-gnu,host-powerpc64le--linux" "-outputs=[[RES:.+\.o]]" "-inputs=[[T1OBJ]],[[T2OBJ]],[[HOSTOBJ]]"
+
+/// ###
+
+/// Check separate compilation with offloading - unbundling jobs construct
+// RUN:   touch %t.i
+// RUN:   %clang -###  -fopenmp -o %t.out -lsomelib -target powerpc64le-linux -fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu %t.i 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-UBJOBS %s
+// RUN:   %clang -### -fopenmp -o %t.out -lsomelib -target powerpc64le-linux -fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu %t.i -save-temps 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-UBJOBS-ST %s
+// RUN:   touch %t.o
+// RUN:   %clang -###  -fopenmp -o %t.out -lsomelib -target powerpc64le-linux -fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu %t.o 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-UBJOBS2 %s
+// RUN:   %clang -### -fopenmp -o %t.out -lsomelib -target powerpc64le-linux -fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu %t.o -save-temps 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-UBJOBS2-ST %s
+
+// Unbundle and create host BC.
+// CHK-UBJOBS: clang-offload-bundler" "-type=i" "-targets=host-powerpc64le--linux,openmp-powerpc64le-ibm-linux-gnu,openmp-x86_64-pc-linux-gnu" "-inputs=[[INPUT:.+\.i]]" "-outputs=[[HOSTPP:.+\.i]],[[T1PP:.+\.i]],[[T2PP:.+\.i]]" "-unbundle"
+// CHK-UBJOBS: clang{{.*}}" "-cc1" "-triple" "powerpc64le--linux" "-emit-llvm-bc"  {{.*}}"-fopenmp" {{.*}}"-o" "[[HOSTBC:.+\.bc]]" "-x" "cpp-output" "[[HOSTPP]]" "-fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu"
+// CHK-UBJOBS-ST: clang-offload-bundler" "-type=i" "-targets=host-powerpc64le--linux,openmp-powerpc64le-ibm-linux-gnu,openmp-x86_64-pc-linux-gnu" "-inputs=[[INPUT:.+\.i]]" "-outputs=[[HOSTPP:.+\.i]],[[T1PP:.+\.i]],[[T2PP:.+\.i]]" "-unbundle"
+// CHK-UBJOBS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le--linux" "-emit-llvm-bc"  {{.*}}"-fopenmp" {{.*}}"-o" "[[HOSTBC:.+\.bc]]" "-x" "cpp-output" "[[HOSTPP]]" "-fopenmp-targets=powerpc64le-ibm-linux-gnu,x86_64-pc-linux-gnu"
+
+// Create target 1 object.
+// CHK-UBJOBS: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-emit-obj" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1OBJ:.+\.o]]" "-x" "cpp-output" "[[T1PP]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
+// CHK-UBJOBS: ld" {{.*}}"-o" "[[T1BIN:.+\.out]]" {{.*}}"[[T1OBJ]]"
+// CHK-UBJOBS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-emit-llvm-bc" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1BC:.+\.bc]]" "-x" "cpp-output" "[[T1PP]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
+// CHK-UBJOBS-ST: clang{{.*}}" "-cc1" "-triple" "powerpc64le-ibm-linux-gnu" "-S" {{.*}}"-fopenmp" {{.*}}"-o" "[[T1ASM:.+\.s]]" "-x" "ir" "[[T1BC]]"
+// CHK-UBJOBS-ST: clang{{.*}}" "-cc1as" "-triple" "powerpc64le-ibm-linux-gnu" "-filetype" "obj" {{.*}}"-o" "[[T1OBJ:.+\.o]]" "[[T1ASM]]"
+// CHK-UBJOBS-ST: ld" {{.*}}"-o" "[[T1BIN:.+\.out-openmp-powerpc64le-ibm-linux-gnu]]" {{.*}}"[[T1OBJ]]"
+
+// Create target 2 object.
+// CHK-UBJOBS: clang{{.*}}" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-emit-obj" {{.*}}"-fopenmp" {{.*}}"-o" "[[T2OBJ:.+\.o]]" "-x" "cpp-output" "[[T2PP]]" "-fopenmp-is-device" "-fopenmp-host-ir-file-path" "[[HOSTBC]]"
+// CHK-UBJOBS: ld" {{.*}}"-o" "[[T2BIN:.+\.out]]" {{.*}}"[[T2OBJ]]"
+// CHK-UBJOBS-ST: clang{{.*}}" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-emit-llvm-bc" {{.*}}"-fopenmp" {{.*}}"-o" "[[T2BC:.

r282122 - [CMake] Check if passthrough variables are defined

2016-09-21 Thread Chris Bieneman via cfe-commits
Author: cbieneman
Date: Wed Sep 21 18:24:15 2016
New Revision: 282122

URL: http://llvm.org/viewvc/llvm-project?rev=282122&view=rev
Log:
[CMake] Check if passthrough variables are defined

Checking if they evaluate to true cases prevents passing values that evaluate 
to false cases. Instead we should check if the variables are defined.

Modified:
cfe/trunk/CMakeLists.txt

Modified: cfe/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/CMakeLists.txt?rev=282122&r1=282121&r2=282122&view=diff
==
--- cfe/trunk/CMakeLists.txt (original)
+++ cfe/trunk/CMakeLists.txt Wed Sep 21 18:24:15 2016
@@ -610,7 +610,7 @@ if (CLANG_ENABLE_BOOTSTRAP)
 
   # Populate the passthrough variables
   foreach(variableName ${CLANG_BOOTSTRAP_PASSTHROUGH} 
${_BOOTSTRAP_DEFAULT_PASSTHROUGH})
-if(${variableName})
+if(DEFINED ${variableName})
   string(REPLACE ";" "\;" value ${${variableName}})
   list(APPEND PASSTHROUGH_VARIABLES
 -D${variableName}=${value})


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


Re: [PATCH] D10857: Update documentation for unroll pragmas on loops with runtime trip counts

2016-09-21 Thread Eugene Zelenko via cfe-commits
Eugene.Zelenko added a subscriber: Eugene.Zelenko.
Eugene.Zelenko closed this revision.
Eugene.Zelenko added a comment.

Committed in r242048.


https://reviews.llvm.org/D10857



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


Re: [PATCH] D24792: [analyzer] Fix crash in RetainCountChecker::checkEndFunction

2016-09-21 Thread Alexander Shaposhnikov via cfe-commits
alexshap updated the summary for this revision.
alexshap updated this revision to Diff 72132.
alexshap added a comment.

Address the comments


Repository:
  rL LLVM

https://reviews.llvm.org/D24792

Files:
  lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
  lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
  test/Analysis/NSString.m

Index: test/Analysis/NSString.m
===
--- test/Analysis/NSString.m
+++ test/Analysis/NSString.m
@@ -289,7 +289,11 @@
 _Bool OSAtomicCompareAndSwapPtr( void *__oldValue, void *__newValue, void * 
volatile *__theValue ) {
   return opaque_OSAtomicCompareAndSwapPtr(__oldValue, __newValue, __theValue);
 }
-
+// Test that the analyzer doesn't crash when the farm model is used. 
+// The analyzer ignores the autosynthesized code.
+_Bool OSAtomicCompareAndSwapEmptyFunction( void *__oldValue, void *__newValue, 
void * volatile *__theValue ) {
+  return 0;
+}
 extern BOOL opaque_objc_atomicCompareAndSwapPtr(id predicate, id replacement, 
volatile id *objectLocation);
 extern BOOL objc_atomicCompareAndSwapPtr(id predicate, id replacement, 
volatile id *objectLocation) {
   return opaque_objc_atomicCompareAndSwapPtr(predicate, replacement, 
objectLocation);
@@ -441,4 +445,4 @@
 - (void)callValue {
   [self _value];
 }
-@end
\ No newline at end of file
+@end
Index: lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
===
--- lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
+++ lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
@@ -688,6 +688,10 @@
   if (!Mgr->getAnalysisDeclContext(D)->getAnalysis())
 return;
 
+  // Ignore autosynthesized code.
+  if (Mgr->getAnalysisDeclContext(D)->isBodyAutosynthesized())
+return;
+
   ExprEngine Eng(*Mgr, ObjCGCEnabled, VisitedCallees, 
&FunctionSummaries,IMode);
 
   // Set the graph auditor.
Index: lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
+++ lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
@@ -3863,7 +3863,7 @@
   // Don't process anything within synthesized bodies.
   const LocationContext *LCtx = Pred->getLocationContext();
   if (LCtx->getAnalysisDeclContext()->isBodyAutosynthesized()) {
-assert(LCtx->getParent());
+assert(!LCtx->inTopFrame()); 
 return;
   }
 


Index: test/Analysis/NSString.m
===
--- test/Analysis/NSString.m
+++ test/Analysis/NSString.m
@@ -289,7 +289,11 @@
 _Bool OSAtomicCompareAndSwapPtr( void *__oldValue, void *__newValue, void * volatile *__theValue ) {
   return opaque_OSAtomicCompareAndSwapPtr(__oldValue, __newValue, __theValue);
 }
-
+// Test that the analyzer doesn't crash when the farm model is used. 
+// The analyzer ignores the autosynthesized code.
+_Bool OSAtomicCompareAndSwapEmptyFunction( void *__oldValue, void *__newValue, void * volatile *__theValue ) {
+  return 0;
+}
 extern BOOL opaque_objc_atomicCompareAndSwapPtr(id predicate, id replacement, volatile id *objectLocation);
 extern BOOL objc_atomicCompareAndSwapPtr(id predicate, id replacement, volatile id *objectLocation) {
   return opaque_objc_atomicCompareAndSwapPtr(predicate, replacement, objectLocation);
@@ -441,4 +445,4 @@
 - (void)callValue {
   [self _value];
 }
-@end
\ No newline at end of file
+@end
Index: lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
===
--- lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
+++ lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
@@ -688,6 +688,10 @@
   if (!Mgr->getAnalysisDeclContext(D)->getAnalysis())
 return;
 
+  // Ignore autosynthesized code.
+  if (Mgr->getAnalysisDeclContext(D)->isBodyAutosynthesized())
+return;
+
   ExprEngine Eng(*Mgr, ObjCGCEnabled, VisitedCallees, &FunctionSummaries,IMode);
 
   // Set the graph auditor.
Index: lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
===
--- lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
+++ lib/StaticAnalyzer/Checkers/RetainCountChecker.cpp
@@ -3863,7 +3863,7 @@
   // Don't process anything within synthesized bodies.
   const LocationContext *LCtx = Pred->getLocationContext();
   if (LCtx->getAnalysisDeclContext()->isBodyAutosynthesized()) {
-assert(LCtx->getParent());
+assert(!LCtx->inTopFrame()); 
 return;
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D24754: [cleanup] Remove excessive padding from RedeclarableResult

2016-09-21 Thread Vedant Kumar via cfe-commits
vsk added inline comments.


Comment at: lib/Serialization/ASTReaderDecl.cpp:154
@@ -153,3 +153,3 @@
 public:
-  RedeclarableResult(GlobalDeclID FirstID, Decl *MergeWith, bool IsKeyDecl)
-  : FirstID(FirstID), MergeWith(MergeWith), IsKeyDecl(IsKeyDecl) {}
+  RedeclarableResult(Decl *MergeWith, GlobalDeclID FirstID, bool IsKeyDecl)
+  : MergeWith(MergeWith), FirstID(FirstID), IsKeyDecl(IsKeyDecl) {}

Why do you need to change the order of the parameters in the constructor?


Repository:
  rL LLVM

https://reviews.llvm.org/D24754



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


r282124 - [Sema] Fix PR30481: crash on checking printf args.

2016-09-21 Thread George Burgess IV via cfe-commits
Author: gbiv
Date: Wed Sep 21 19:00:26 2016
New Revision: 282124

URL: http://llvm.org/viewvc/llvm-project?rev=282124&view=rev
Log:
[Sema] Fix PR30481: crash on checking printf args.

We were falling through from one case to another in a switch statement.
Oops.

Modified:
cfe/trunk/lib/Sema/SemaChecking.cpp
cfe/trunk/test/Sema/format-strings.c

Modified: cfe/trunk/lib/Sema/SemaChecking.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaChecking.cpp?rev=282124&r1=282123&r2=282124&view=diff
==
--- cfe/trunk/lib/Sema/SemaChecking.cpp (original)
+++ cfe/trunk/lib/Sema/SemaChecking.cpp Wed Sep 21 19:00:26 2016
@@ -4194,9 +4194,9 @@ checkFormatStringExpr(Sema &S, const Exp
   goto tryAgain;
 }
   }
-
-  return SLCT_NotALiteral;
 }
+
+return SLCT_NotALiteral;
   }
   case Stmt::UnaryOperatorClass: {
 const UnaryOperator *UnaOp = cast(E);

Modified: cfe/trunk/test/Sema/format-strings.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/format-strings.c?rev=282124&r1=282123&r2=282124&view=diff
==
--- cfe/trunk/test/Sema/format-strings.c (original)
+++ cfe/trunk/test/Sema/format-strings.c Wed Sep 21 19:00:26 2016
@@ -687,3 +687,8 @@ void test_char_pointer_arithmetic(int b)
   printf(s7 + 3, "");  // expected-warning{{more '%' conversions than data 
arguments}}
   // expected-note@-2{{format string is defined here}}
 }
+
+void PR30481() {
+  // This caused crashes due to invalid casts.
+  printf(1 > 0); // expected-warning{{format string is not a string literal}} 
expected-warning{{incompatible integer to pointer conversion}} 
expected-note@format-strings.c:*{{passing argument to parameter here}} 
expected-note{{to avoid this}}
+}


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


Re: [PATCH] D24693: [CodeGen] Don't emit lifetime intrinsics for some local variables

2016-09-21 Thread Vitaly Buka via cfe-commits
vitalybuka added a comment.

Miscompile.
Here assert fails without the patch.

int* p1;
int* p2;

int use2() {

  assert(p1 != p2 || !"reuse");
  return p1 == p2;

}

void f3(int cond) {

  {
int tmp[1024];
p1 = tmp;
goto l2;
  l1:
int tmp2[1024];
p2 = tmp2;
exit(use2());
  }

l2:

  goto l1;

}


https://reviews.llvm.org/D24693



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


r282125 - [CMake] More robust handling for bootstrap variables

2016-09-21 Thread Chris Bieneman via cfe-commits
Author: cbieneman
Date: Wed Sep 21 19:18:12 2016
New Revision: 282125

URL: http://llvm.org/viewvc/llvm-project?rev=282125&view=rev
Log:
[CMake] More robust handling for bootstrap variables

Checking defined isn't good enough we also need to handle defined to empty 
string.

Modified:
cfe/trunk/CMakeLists.txt

Modified: cfe/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/CMakeLists.txt?rev=282125&r1=282124&r2=282125&view=diff
==
--- cfe/trunk/CMakeLists.txt (original)
+++ cfe/trunk/CMakeLists.txt Wed Sep 21 19:18:12 2016
@@ -611,7 +611,11 @@ if (CLANG_ENABLE_BOOTSTRAP)
   # Populate the passthrough variables
   foreach(variableName ${CLANG_BOOTSTRAP_PASSTHROUGH} 
${_BOOTSTRAP_DEFAULT_PASSTHROUGH})
 if(DEFINED ${variableName})
-  string(REPLACE ";" "\;" value ${${variableName}})
+  if("${${variableName}}" STREQUAL "")
+set(value "")
+  else()
+string(REPLACE ";" "\;" value ${${variableName}})
+  endif()
   list(APPEND PASSTHROUGH_VARIABLES
 -D${variableName}=${value})
 endif()


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


[libcxx] r282126 - Add missing _v traits. is_bind_expression_v, is_placeholder_v and uses_allocator_v

2016-09-21 Thread Marshall Clow via cfe-commits
Author: marshall
Date: Wed Sep 21 19:23:15 2016
New Revision: 282126

URL: http://llvm.org/viewvc/llvm-project?rev=282126&view=rev
Log:
Add missing _v traits. is_bind_expression_v, is_placeholder_v and 
uses_allocator_v

Modified:
libcxx/trunk/include/__functional_base
libcxx/trunk/include/functional

libcxx/trunk/test/std/utilities/function.objects/bind/func.bind/func.bind.isbind/is_bind_expression.pass.cpp

libcxx/trunk/test/std/utilities/function.objects/bind/func.bind/func.bind.isbind/is_placeholder.pass.cpp

libcxx/trunk/test/std/utilities/memory/allocator.uses/allocator.uses.trait/uses_allocator.pass.cpp

Modified: libcxx/trunk/include/__functional_base
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__functional_base?rev=282126&r1=282125&r2=282126&view=diff
==
--- libcxx/trunk/include/__functional_base (original)
+++ libcxx/trunk/include/__functional_base Wed Sep 21 19:23:15 2016
@@ -625,6 +625,11 @@ struct _LIBCPP_TYPE_VIS_ONLY uses_alloca
 {
 };
 
+#if _LIBCPP_STD_VER > 14
+template 
+constexpr size_t uses_allocator_v = uses_allocator<_Tp, _Alloc>::value;
+#endif
+
 #ifndef _LIBCPP_HAS_NO_VARIADICS
 
 // allocator construction

Modified: libcxx/trunk/include/functional
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/functional?rev=282126&r1=282125&r2=282126&view=diff
==
--- libcxx/trunk/include/functional (original)
+++ libcxx/trunk/include/functional Wed Sep 21 19:23:15 2016
@@ -212,6 +212,13 @@ template  unspecified not_fn(F&
 template struct is_bind_expression;
 template struct is_placeholder;
 
+// See C++14 20.9.9, Function object binders
+template  constexpr bool is_bind_expression_v
+  = is_bind_expression::value; // C++17
+template  constexpr int is_placeholder_v
+  = is_placeholder::value; // C++17
+
+
 template
   unspecified bind(Fn&&, BoundArgs&&...);
 template
@@ -1970,10 +1977,20 @@ template struct __is_bind_exp
 template struct _LIBCPP_TYPE_VIS_ONLY is_bind_expression
 : public __is_bind_expression::type> {};
 
+#if _LIBCPP_STD_VER > 14
+template 
+constexpr size_t is_bind_expression_v = is_bind_expression<_Tp>::value;
+#endif
+
 template struct __is_placeholder : public integral_constant 
{};
 template struct _LIBCPP_TYPE_VIS_ONLY is_placeholder
 : public __is_placeholder::type> {};
 
+#if _LIBCPP_STD_VER > 14
+template 
+constexpr size_t is_placeholder_v = is_placeholder<_Tp>::value;
+#endif
+
 namespace placeholders
 {
 

Modified: 
libcxx/trunk/test/std/utilities/function.objects/bind/func.bind/func.bind.isbind/is_bind_expression.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/function.objects/bind/func.bind/func.bind.isbind/is_bind_expression.pass.cpp?rev=282126&r1=282125&r2=282126&view=diff
==
--- 
libcxx/trunk/test/std/utilities/function.objects/bind/func.bind/func.bind.isbind/is_bind_expression.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/utilities/function.objects/bind/func.bind/func.bind.isbind/is_bind_expression.pass.cpp
 Wed Sep 21 19:23:15 2016
@@ -14,12 +14,16 @@
 // template struct is_bind_expression
 
 #include 
+#include "test_macros.h"
 
 template 
 void
 test(const T&)
 {
 static_assert(std::is_bind_expression::value == Expected, "");
+#if TEST_STD_VER > 14
+static_assert(std::is_bind_expression_v == Expected, "");
+#endif
 }
 
 struct C {};

Modified: 
libcxx/trunk/test/std/utilities/function.objects/bind/func.bind/func.bind.isbind/is_placeholder.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/function.objects/bind/func.bind/func.bind.isbind/is_placeholder.pass.cpp?rev=282126&r1=282125&r2=282126&view=diff
==
--- 
libcxx/trunk/test/std/utilities/function.objects/bind/func.bind/func.bind.isbind/is_placeholder.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/utilities/function.objects/bind/func.bind/func.bind.isbind/is_placeholder.pass.cpp
 Wed Sep 21 19:23:15 2016
@@ -12,12 +12,16 @@
 // struct is_placeholder
 
 #include 
+#include "test_macros.h"
 
 template 
 void
 test(const T&)
 {
 static_assert(std::is_placeholder::value == Expected, "");
+#if TEST_STD_VER > 14
+static_assert(std::is_placeholder_v == Expected, "");
+#endif
 }
 
 struct C {};

Modified: 
libcxx/trunk/test/std/utilities/memory/allocator.uses/allocator.uses.trait/uses_allocator.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/memory/allocator.uses/allocator.uses.trait/uses_allocator.pass.cpp?rev=282126&r1=282125&r2=282126&view=diff
==
--- 
libcxx/trunk/test/std/utilities/memory/allocator.uses/allocator.uses.trait/uses_allocator.pass.cpp
 (orig

Re: [PATCH] D24799: [XRay] Check in Clang whether XRay supports the target when -fxray-instrument is passed

2016-09-21 Thread Dean Michael Berris via cfe-commits
dberris added a comment.

What does the error actually look like? Can you add a test for it? It's unclear 
to me how this would read... for example does it say "XRay for arm is 
unsupported"?


https://reviews.llvm.org/D24799



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


Re: [PATCH] D24373: [Coroutines] Adding builtins for coroutine intrinsics and backendutil support.

2016-09-21 Thread Richard Smith via cfe-commits
rsmith added inline comments.


Comment at: include/clang/Basic/Builtins.def:1293
@@ +1292,3 @@
+
+BUILTIN(__builtin_coro_id, "v*Iiv*v*v*", "n")
+BUILTIN(__builtin_coro_alloc, "bv*", "n")

I don't really like having builtins which will result in errors from the 
middle-end in some cases; there are a bunch of side-conditions on llvm.coro.id 
that aren't being enforced here. In particular, this call must be present in 
any function that also calls coro.alloc and friends, and must dominate those 
other calls.

Modeling the 'token' value as a `void*` also seems problematic. If the user 
uses that value for anything other than the argument to a builtin that wants 
the token, bad things are going to happen.

(From dinner discussion:) one possible way to deal with this would be to 
generate the call to @llvm.coro.id implicitly in the entry block, in a function 
that uses the other builtins. The challenge then is communicating the promise 
object to the intrinsic, which is problematic if we allow an arbitrary pointer 
value to be passed in.

However, we're only interested in supporting a stack variable as the promise 
object, so here's one possible approach:

- add an attribute that can be applied to a local variable to mark it as the 
promise object for the current function
- remove the `__builtin_coro_id` builtin, and instead implicitly generate the 
`llvm.coro.id` intrinsic call in the entry block when we need its token or see 
a promise object
- when we emit a local variable with the promise-object attribute, update the 
`llvm.coro.id` call to pass its alloca as the promise object
- remove the 'token' parameter from `__builtin_coro_alloc` etc, and instead 
implicitly provide it from the result of the implicit `llvm.coro.id` call


Comment at: test/Coroutines/coro.c:1
@@ +1,2 @@
+// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -fcoroutines -emit-llvm %s 
-o - -O3 | FileCheck %s
+#include "Inputs/coro.h"

Please just check the IR generated by the frontend is correct for each of the 
intrinsics rather than using an end-to-end test that depends on the LLVM IR 
optimizations. You can use `-disable-llvm-optzns` to see the IR coming out of 
clang before the mandatory coroutine passes monkey with it.


https://reviews.llvm.org/D24373



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


[PATCH] D24820: Add -stats-file option

2016-09-21 Thread Matthias Braun via cfe-commits
MatzeB created this revision.
MatzeB added reviewers: bruno, rsmith, aprantl.
MatzeB added a subscriber: cfe-commits.
MatzeB set the repository for this revision to rL LLVM.
Herald added a subscriber: mcrosier.

This option behaves in a similar spirit as -save-temps and writes out
llvm statistics in json format.

Repository:
  rL LLVM

https://reviews.llvm.org/D24820

Files:
  include/clang/Basic/DiagnosticFrontendKinds.td
  include/clang/Driver/CC1Options.td
  include/clang/Driver/Options.td
  include/clang/Frontend/FrontendOptions.h
  lib/Driver/Tools.cpp
  lib/Frontend/CompilerInstance.cpp
  lib/Frontend/CompilerInvocation.cpp
  lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
  test/Driver/save-stats.c
  test/Frontend/stats-file.c
  test/Misc/warning-flags.c

Index: test/Misc/warning-flags.c
===
--- test/Misc/warning-flags.c
+++ test/Misc/warning-flags.c
@@ -18,7 +18,7 @@
 
 The list of warnings below should NEVER grow.  It should gradually shrink to 0.
 
-CHECK: Warnings without flags (84):
+CHECK: Warnings without flags (85):
 CHECK-NEXT:   ext_excess_initializers
 CHECK-NEXT:   ext_excess_initializers_in_char_array_initializer
 CHECK-NEXT:   ext_expected_semi_decl_list
@@ -66,6 +66,7 @@
 CHECK-NEXT:   warn_fe_cc_log_diagnostics_failure
 CHECK-NEXT:   warn_fe_cc_print_header_failure
 CHECK-NEXT:   warn_fe_macro_contains_embedded_newline
+CHECK-NEXT:   warn_fe_unable_to_open_stats_file
 CHECK-NEXT:   warn_file_asm_volatile
 CHECK-NEXT:   warn_ignoring_ftabstop_value
 CHECK-NEXT:   warn_implements_nscopying
Index: test/Frontend/stats-file.c
===
--- /dev/null
+++ test/Frontend/stats-file.c
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -emit-llvm -o /dev/null -stats-file=%t %s
+// RUN: FileCheck -input-file=%t %s
+// CHECK: {
+//  ... here come some json values ...
+// CHECK: }
+
+// RUN: %clang_cc1 -emit-llvm -o %t -stats-file=%S/doesnotexist/bla %s 2>&1 | FileCheck -check-prefix=OUTPUTFAIL %s
+// OUTPUTFAIL: warning: unable to open statistic output file '{{.*}}{{[/\\]}}doesnotexist{{[/\\]}}bla': '{{[Nn]}}o such file or directory'
Index: test/Driver/save-stats.c
===
--- /dev/null
+++ test/Driver/save-stats.c
@@ -0,0 +1,17 @@
+// RUN: %clang -target x86_64-apple-darwin -save-stats %s -### 2>&1 | FileCheck %s
+// RUN: %clang -target x86_64-apple-darwin -save-stats=cwd %s -### 2>&1 | FileCheck %s
+// CHECK: "-stats-file=save-stats.stats"
+// CHECK: "{{.*}}save-stats.c"
+
+// RUN: %clang -target x86_64-apple-darwin -S %s -### 2>&1 | FileCheck %s -check-prefix=NO-STATS
+// NO-STATS-NO: -stats-file
+// NO-STATS: "{{.*}}save-stats.c"
+// NO-STATS-NO: -stats-file
+
+// RUN: %clang -target x86_64-apple-darwin -save-stats=obj -c -o obj/dir/save-stats.o %s -### 2>&1 | FileCheck %s -check-prefix=CHECK-OBJ
+// CHECK-OBJ: "-stats-file=obj/dir{{/|}}save-stats.stats"
+// CHECK-OBJ: "-o" "obj/dir{{/|}}save-stats.o"
+
+// RUN: %clang -target x86_64-apple-darwin -save-stats=obj -c %s -### 2>&1 | FileCheck %s -check-prefix=CHECK-OBJ-NOO
+// CHECK-OBJ-NOO: "-stats-file=save-stats.stats"
+// CHECK-OBJ-NOO: "-o" "save-stats.o"
Index: lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
===
--- lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
+++ lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
@@ -194,8 +194,10 @@
   }
 
   ~AnalysisConsumer() override {
-if (Opts->PrintStats)
+if (Opts->PrintStats) {
   delete TUTotalTimer;
+  llvm::PrintStatistics();
+}
   }
 
   void DigestAnalyzerOptions() {
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -1252,6 +1252,7 @@
   Opts.AuxTriple =
   llvm::Triple::normalize(Args.getLastArgValue(OPT_aux_triple));
   Opts.FindPchSource = Args.getLastArgValue(OPT_find_pch_source_EQ);
+  Opts.StatsFile = Args.getLastArgValue(OPT_stats_file);
 
   if (const Arg *A = Args.getLastArg(OPT_arcmt_check,
  OPT_arcmt_modify,
Index: lib/Frontend/CompilerInstance.cpp
===
--- lib/Frontend/CompilerInstance.cpp
+++ lib/Frontend/CompilerInstance.cpp
@@ -858,7 +858,7 @@
   if (getFrontendOpts().ShowTimers)
 createFrontendTimer();
 
-  if (getFrontendOpts().ShowStats)
+  if (getFrontendOpts().ShowStats || !getFrontendOpts().StatsFile.empty())
 llvm::EnableStatistics();
 
   for (const FrontendInputFile &FIF : getFrontendOpts().Inputs) {
@@ -892,9 +892,24 @@
   OS << " generated.\n";
   }
 
-  if (getFrontendOpts().ShowStats && hasFileManager()) {
-getFileManager().PrintStats();
-OS << "\n";
+  if (getFrontendOpts().ShowStats) {
+if (hasFileManager()) {
+  getFileManager().Pr

[libcxx] r282134 - Fix failure on 03 bot

2016-09-21 Thread Marshall Clow via cfe-commits
Author: marshall
Date: Wed Sep 21 22:25:22 2016
New Revision: 282134

URL: http://llvm.org/viewvc/llvm-project?rev=282134&view=rev
Log:
Fix failure on 03 bot

Modified:

libcxx/trunk/test/std/utilities/memory/allocator.uses/allocator.uses.trait/uses_allocator.pass.cpp

Modified: 
libcxx/trunk/test/std/utilities/memory/allocator.uses/allocator.uses.trait/uses_allocator.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/utilities/memory/allocator.uses/allocator.uses.trait/uses_allocator.pass.cpp?rev=282134&r1=282133&r2=282134&view=diff
==
--- 
libcxx/trunk/test/std/utilities/memory/allocator.uses/allocator.uses.trait/uses_allocator.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/utilities/memory/allocator.uses/allocator.uses.trait/uses_allocator.pass.cpp
 Wed Sep 21 22:25:22 2016
@@ -42,9 +42,9 @@ template ::value == Expected, "");
+static_assert((std::uses_allocator::value == Expected), "");
 #if TEST_STD_VER > 14
-static_assert(std::uses_allocator_v == Expected, "");
+static_assert((std::uses_allocator_v == Expected), "");
 #endif
 }
 


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


  1   2   >